<rekado>bavier1: oh, the sfml build failures. Hmm, I'll take a look. <rekado>we could fetch the sources from their github releases instead. <rekado>pushed a commit to update sfml to 2.3.2, changing the source URL to the latest release on github, and added a comment. <rekado>with the OpenAL fix (just sent to ML) I now have sound in M.A.R.S. ***davi_ is now known as Guest2383
<sneek>Welcome back civodul, you have 1 message. <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. <rekado>good news: we have a Blender package; bad news: three tests fail (related to Python), but there's no additional output, so debugging will take longer. <lfam>Am I right that `guix import nix` requires a working nix package manager installation? <sneek>Welcome back lfam, you have 2 messages. <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: 87lhijykkm.fsf@gmail.com <karhunguixi>Have any of you tried the "reply via email to" button on the archive? <davexunit>umm, gnu mailing lists are not hosted on gmail.com <karhunguixi>and all the users addresses i've seen in there are in clear text <rekado>karhunguixi: that's not an address but a mail id. That's why it's after "In-Reply-To". <rekado>In-Reply-To is a mail header, not a target address. <karhunguixi>ok. But then the only other address is directly to the user. <rekado>just send to guix-devel@gnu.org and make sure your email client adds the appropriate In-Reply-To header. <civodul>lfam: 'guix import nix' requires the 'nix-invalidate' command <civodul>lfam: you can do "guix package -i nix" and that's enough <civodul>mark_weaver: looking at the patch karhunguixi sent, i think we'll just move all of linux-boot.scm to using devtmpfs <civodul>i've just tried and it works perfectly <civodul>so i'll also remove %devtmpfs-file-system <mark_weaver>civodul: if we can't get core-updates merged fairly soon, we'll have to apply the icu4c security update to master, which will entail on the order of 1500 builds <mark_weaver>civodul: also, fyi, on hydra I reduced maxconcurrent for i686 and x86_64 from 8 down to 5, because hydra was too overloaded otherwise. <civodul>well i wanted to look again at this pixman thing <mark_weaver>clearly the glibc developers aren't doing much testing on i686 these days <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 <mark_weaver>if we determined that the problem was in libc, then we could do a git bisect on libc <mark_weaver>but I'm not sure that our current implementation of grafting is good enough. <civodul>it's definitely good enough in a simple case like this <mark_weaver>well, won't it result in multiple versions of libc being linked into the same executable? <mark_weaver>because pixman will try to link to the grafted libc, but also other libraries that are still linked to the ungrafted libc. <mark_weaver>or maybe just one of the libc's will win, if rpaths for both versions of libcs are included, depending on how rpaths are handled. I don't know much about that. <civodul>mark_weaver: my recollection is that it grafts too much rather than not enough <civodul>but i'm a bit fuzzy on the details right now <efraim>what do you pipe guix graph into? <civodul>something that kinda works is: guix graph foo | dot -Tps | gv - <civodul>but then gv gets the bounding box wrong, so sometimes it's no OK <civodul>mark_weaver: "./pre-inst-env guix build pixman -s i686-linux -K" succeeds (with substitutes)... <mark_weaver>civodul: interesting. I did ask for hydra to rebuild all dependency failure <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 <karhunguixi>i was planning to do a "guix pull" after as user, just to be sure <karhunguixi>but is there like no timestamp or last commit id or something i can get after guix pull to compare it with the source code? <civodul>mark_weaver: yes, that happened to me as well, not sure what to do <civodul>mark_weaver: the pixman failure used to be reproducible for me <mark_weaver>karhunguixi: I don't know off-hand. I have never used "guix pull", not even once :) <mark_weaver>on my Guix systems, ~root/.config/guix/latest and ~mhw/.config/guix/latest both point to my git checkout of guix. <mark_weaver>karhunguixi: yeah, the only time it's an issue is when my git checkout is in a bad state and I want to run a guix command. but overall it works well. <civodul>mark_weaver: pixman seems to be using cpuid <mark_weaver>civodul: yes, I believe it does runtime detection of the CPU to choose optimized code. I'm pretty sure it does that for Loongson, at least. <civodul>but since we're building i686 stuff on x86_64 machines, could something go wrong? <mark_weaver>civodul: possibly, although it doesn't seem to have been an issue so far. I've run pixman from hydra on a genuine i686 machine (Libreboot X60), for example. <mark_weaver>my understanding is that it's supposed to do runtime CPU detection. <mark_weaver>also, core-updates has the same version of pixman that's in master, right? <mark_weaver>(or possibly some other library that pixman depends on) <civodul>i'm testing without its libpng dependency, and same problem <civodul>oh, "linux32 -R -B ./stress-test" to reproduce <mark_weaver>civodul: is it possible to override the rpaths to use a different libc at run-time? <mark_weaver>if so, that would greatly facilitate doing a git bisect <mark_weaver>in that case, I guess it would be good to build libc from git and then try 'stress-test' against that libc, and then proceed with a git bisect <mark_weaver>although there might be problems with that approach, if the glibc ABI changed <mark_weaver>fortunately, pixman has such minimal dependencies that rebuilding it against candidate glibc checkouts might not take long <mark_weaver>and of course, pkg-config needn't be rebuilt, if that could hacked somehow <mark_weaver>well, I guess for purposes of git bisect, glibc, zlib and pixman should be built manually, to avoid to much rebuilding.