Conversation
|
I'm seeing the following error when buildstream tries to call bubblewrap to run a build |
|
@abderrahim Yeah I ran into that and various other errors when I was still using bubblewrap in mkosi as well. I consider it to be a totally broken check in bubblewrap. It should not fail when running unprivileged with capabilities, it's a totally valid use case. But the upstream is pretty much dead unfortunately. We can avoid the check by pretending we're root (while still setting HOME to the user home directory to reuse the cache). I'll push an update to that effect, please try again then. |
7519755 to
0496128
Compare
|
Hi, I was asked to look into this and give it a go as I have been looking into working on something very similar. 👍 I was wondering what the ultimate goal is here. As I understand in here we are only changing the need for having a script such as: into just calling It also occurs to me this means we are relying on |
In a way, maybe. https://gitlab.com/freedesktop-sdk/mkbstosi was an attempt at such a script. Ultimately, it would be nice to have things directly in mkosi and not have to install a third project. There are also a few complications with trying to call mkosi on a directory structure.
Do you often need to call Either way, if it's something that's useful I guess it can be added.
Yeah, mkosi would be another dependency in addition to buildstream.
That would be nice, but
So in a way, it's a trade off and we (GNOME OS) are pretty happy with it. I thought it might be useful to you too :) |
Since we don't require the version to be in the kernel image filename anymore, let's not insist on the - anymore.
In weird CI setups or such, there might be stuff in non-canonical directories in /. This stuff only has a minimal chance to affect the image build accidentally, so let's mount them in by default in case the image build actually does need to look up stuff in these directories.
The GnomeOS folks are looking into mkosi to build their images instead of BuildStream. While BuildStream will still take care of providing the rootfs tree, mkosi would take over the responsibility of packaging that directory tree into a disk image. Let's add support for BuildStream to mkosi to make this possible. Unlike the other supported distributions, BuildStream is not intended to be consumed by installing individual packages. Instead, BuildStream elements should be exposed which provide the full rootfs that should go into the image. That's why we limit the number of packages that can be specified to a single one, which should always provide all contents that should go into the image.
0496128 to
6744421
Compare
|
@daandemeyer I'm noticing a weird behaviour with this MR. When I set |
| ) -> None: | ||
| options = [ | ||
| "--same-dir", | ||
| *context.rootoptions(), | ||
| # bst might need to lookup files/paths across the user's home directory so make sure it is |
There was a problem hiding this comment.
| ) -> None: | |
| options = [ | |
| "--same-dir", | |
| *context.rootoptions(), | |
| # bst might need to lookup files/paths across the user's home directory so make sure it is | |
| ) -> None: | |
| options = [ | |
| "--same-dir", | |
| *context.rootoptions(), | |
| # we are passing --same-dir. Ensure the current working directory to make chdir() reliable. | |
| "--bind", Path.cwd(), Path.cwd(), | |
| # bst might need to lookup files/paths across the user's home directory so make sure it is |
I needed this to run it properly, I'm running it from distrobox and it does weird things to the home directory. Regardless, passing the directory we run it from seems sound.
| [Content] | ||
| # BuildStream is a generic distribution so we don't know which package to install, hence override to the | ||
| # empty list. | ||
| Packages= |
There was a problem hiding this comment.
I found the issue: this file gets loaded last (after mkosi-initrd/mkosi.conf and after the user provided mkosi.conf and mkosi.initrd.conf) so it overrides the packages to the empty list.
(as I workaround I removed this line, and the Packages list from mkosi-initrd/mkosi.conf, which obviously breaks other distros)
This will stay in draft until gnomeos has the necessary elements in place to allow properly integrating with mkosi so I can test this end-to-end.
cc @AdrianVovk