<sneek>civodul, rekado_ says: I don't think we do. If the same mistakes are made over and over again (e.g. wrong case in synopsis, unexplained acronyms, unhelpful descriptions, bad indentation) I don't think we should just shrug and fix this for the contributor.
<sneek>lfam, mark_weaver says: in case of collisions between two packages in a profile, the package that was installed more recently via guix package -i takes precedence. when using "guix package --manifest" (recommended), then I believe packages listed earlier in the manifest take precedence.
<sneek>lfam, mark_weaver says: prehaps in the future we'll have another mechanism to specify precedence explicitly, dunno.
<lfam>mark_weaver: Thanks for clarifying how collisions are resolved! I can't find anything about it in the manual. I'm wondering where this information should be included... definitely under section 3: Package Management
<lfam>But within that, I am not sure. I'd like to update the manual to include this info.
<karhunguixi>I'm having some issue with guix-devel mailing list web archive. I clicked a "reply via email to" button and yanked out the "In-Reply-To" address, and tried sending a response.
<karhunguixi>But i get the mail in return. The address i sent to was: email@example.com
<mark_weaver>maybe some changes to thread synchronization primitives or something like that?
<mark_weaver>this is one of those cases where andreas's wish to do a full rebuild for each package update would be helpful
<mark_weaver>it might be worth trying to rebuild pixman against the old glibc, and see if it passes.
<civodul>most likely it would, since that's the only significant change we made
<mark_weaver>or more generally, find the set of libraries that pixman depends on that we think might be related to this problem, and then do some kind of binary search in the space of subsets of that set.
<civodul>but i'm not sure it would really help find a fix
<karhunguixi>I want to do a "guix system reconfigure" to test the new encryption commits. But can i verify that i have these new commits after doing "guix pull"?
<mark_weaver>karhunguixi: look at 'mount-essential-file-systems' in ~/.config/guix/latest/gnu/build/linux-boot.scm and see if mounts devtmpfs on /dev
<mark_weaver>karhunguixi: one more thing: it might be necessary to also run 'guix pull' as root, since 'guix system reconfigure' will be run as root. that seems to have tripped up several people.
<mark_weaver>civodul: a number of people have been tripped up by doing "guix pull" as their normal user and then finding that "guix system reconfigure" uses an old guix because root's account doesn't have an updated guix. I wonder what we can do about this?
<mark_weaver>karhunguixi: one hack would be to make ~root/.config/guix/latest be a symlink to ~<YOUR-NORMAL-USER>/.config/guix/latest
<mark_weaver>then, root would always use the same version of guix as your normal user
<karhunguixi>yes, thanks, i'm using sudo, well, "sudo -i" actually