testing brl fetch exherbo-musl
 

No problems during `brl fetch`, but when I executed first command
Above output gone after add the 'paludisbuild' user to group 5 in /etc/group file.
Seems something went wrong during step '[11/18 ( 61%)] Modifying paludisbuild'

I can reproduce the issue, and I think I see the associated bug. The code step you correctly called out as problematic is:

That chroot at the front makes the usermod update the local copy of /etc/group rather than the proper global one. Once the new stratum is enabled the global one takes precedence and the changes to the local one are ignored.

Fixing it should just entail making the group change outside of the chroot on the actual /etc/group and swapping usermod out for some busybox utility such as addgroup.

Catching this kind of thing is exactly what the beta releases are for, many thanks for being proactive here.

I'll see if I can fix it and push another beta this weekend.

Maintainer of the Exherbo fetcher here: This issue is fixed in git. Thanks for catching it!

@Philantrop Thanks for Exherbo fetcher, nice to try Exherbo using bedrock linux.

I've just checked how cave command works with latest Exherbo commits on github.
User paludisbuild is in group 5 now. Above issue is fixed, but next one appeared.

Why my void-musl stratum is used in this case?

Looks to me like:

• cave is changing directory to /var/db/paludis/repositories/arbor
• cave is calling some program which exherbo-musl does not provide. Bedrock assumes if this situation occurs, the specific build of the command doesn't matter and it should just forward one from another stratum. In this case, the void-musl stratum.
• void-musl does not have a local /var/db/paludis/repositories/arbor. This is why you get that warning and probably why you get the following error.

To debug what the command that's being forwarded is, install `strace` in some stratum then run as root:

and provide /tmp/log (e.g. pastebin/bay/gist/whatever). Hopefully those logs will include execution of something from /bedrock/cross/bin.

I can think of two short-term work arounds:

1. Install whatever the missing item is in exherbo-musl so it gets it from exherbo-musl rather than reaching across strata to void.
2. Run `strat -r exherbo-musl cave sync` where that `-r` instructs strat to restrict the stratum to its own files; i.e., don't forward missing items from void-musl.

And two corresponding longer term solutions:

1. See if this is a missing dependency that exherbo should have come with. If so, work with exherbo to include it and/or get `brl fetch exerbo` to add it.
2. Add cave to the list of restricted programs in /bedrock/strata/bedrock.conf to which Bedrock automatically utilizes the aforementioned -r flag.

Philantrop would be know better than I do if it's a missing dependency that exherbo should have come with or not.

Please provide the logs ParadigmComplex mentioned. I can't reproduce your issue.

Seems I found the reason. I had pinned bin/git to void-musl, when I commented this line in bedrock.conf the problem gone.

Excellent! Should you run into issues with Exherbo itself, you'll find us on Freenode in #exherbo.

Ah, that's interesting. I guess we need to fine-tune Bedrock's rules a bit for your situation. I see a number of possible workflows to consider which might help:

• Retain your pinned git and restrict cave so it only uses its own tools, ignoring pinning.
• Remove your pinned git and configure whatever programs you explicitly want to call out to void's git to be from void. They'll prioritize the local git by default, which will then be void's.
• Remove your pinned git, uninstall git from the non-void strata you want to call out to void's git, and put void higher than exherbo or whatever else has to retain git in your bedrock.conf [cross]/priority. This way exherbo's commands will call exherbo's git, but the other situations will either be void processes which prioritize their local git or non-void, non-exherbo processes which lack a local git and fall back to void's.
• Remove your pinned git and explicitly call `strat void git` in the situations you want void's git. If it's only from your shell, you might be able to `alias git="strat void git"` which should hold in your interactive shell but not in other environments such as cave's internal calls.

None of these are perfect, sadly. There issues where you may have to play wack-a-mole where you may run into other programs that will need to be restricted, pinned to avoid, or have their local git uninstalled.

I'll put some time into thinking of a way to improve the Bedrock to handle this situation better.

What do you think about extend pin configuration, e.g.:

As described, that will add both non-trivial amount of complexity and a non-trivial runtime performance hit. It could be worthwhile if the use case was strong enough, but I don't really understand the use case here at all.

You could get a similar effect by creating a file with

at /bedrock/strata/arch/usr/local/bin/git.

If that's insufficient for your needs, can you elaborate on what you're trying to do here? It's hard to provide a solution when I don't actually know what you're trying to do.

I want to pin some apps from other strata than hijacked.
e.g. I have hijacked artix, but I prefer to use firefox-esr from void strata. Create a file at /bedrock/strata/artix/usr/local/bin/firefox with proper content is sufficient for me. Thanks for the tip.

This stuff is definitely confusing if you're not used to thinking in this manner. One can make relatively complex webs of what-from-where.

There's nothing special about the hijacked stratum that gives it priority over anything else. Once the hijack is over, it's the same as all the other strata. If the local stratum provides something, that takes precedence over non-pinned cross-stratum stuff. If you get bash from the hijacked stratum, then launching stuff from the bash will prioritize the hijacked stratum's stuff, but that's not because it's the hijacked stratum. I think my current install was a hijacked Fedora, but I get zsh from Debian, so when I run `ls` I get Debian's `ls`. Also everything from Fedora has since been removed. This is the second thing you've mentioned that you want to come from Void. If you want most things to come from Void, consider making it your shell provider.

If you don't need another firefox around, the easiest solution is to just only have one firefox.

If you have multiple instances of firefox but want Void's to be the default, pinning should be fine. Something like this should get the job done:

There were issues with git, but git operates very differently for these purposes. It's very unlikely you'll have something call firefox under-the-hood such that it matters that it's a cross firefox.

If you always want processes from artix to use void's firefox while processes from other strata could default to another, the /bedrock/strata/<stratum>/usr/local/bin/ thing would work, but I'm having difficulty imagining a workflow which would have this specific requirement. What you described here:

doesn't really cover the need, at least not as I'm interpreting it.

That having been said, if it gets the job done for you, do feel free to use it. As long as you have something that works for you here, I'm happy.