IRC channel logs
2015-04-15.log
back to list of logs
<sneek>Welcome back civodul, you have 1 message. <sneek>civodul, mark_weaver says: jxself says "Indeed! CONFIG_DEVMEM is not set." regarding his new linux-libre-4.0 configuration <civodul>we still have a scary qt4 build failure <wingo>those last four patches i just mailed are the only pending ones i have <civodul>will look into it if nobody beats me <civodul>iyzsong: thanks for helping out on core-updates! <civodul>we're getting there, slowly but surely ;-) *civodul is testing a patch for Qt 4 <Sleep_Walker>which lines are responsible for generating init script in initrd? <Sleep_Walker>I'm trying to follow device mapper code but with no success <Sleep_Walker>I got to device-mapping-commands and then it doesn't make sense at all <civodul>Sleep_Walker: did you look at luks-device-mapping? <civodul>i guess you may need to write something similar? <civodul>(and the 'init' script comes from 'expression->initrd' in (gnu system linux-initrd)) <civodul>Sleep_Walker: so for LVM i think you just need to define something similar to luks-device-mapping <civodul>essentially an 'open' and a 'close' method <civodul>'base-initrd' takes a list of <mapped-device> <civodul>it basically inserts the gexps returned by 'open' into the #:pre-mount argument passed to 'boot-system' <civodul>so for instance if you use luks-device-mapping for an "early-boot" file system, cryptsetup is automagically added to the initrd <civodul>i use luks-device-mapping for /home, so in that case i just get a dmd service and the initrd doesn't have cryptsetup <Sleep_Walker>open is (mapped-device-kind-open (mapped-device-type md)) <civodul>'open' returns a gexp to be precise, so a code snippet to run in the initrd *civodul has a fix for Qt4, yay! <civodul>grr still building but i have to go for a while *davexunit loves guix environment more every day <davexunit>I keep my user profile lean and mean with just my day to day user applications like emacs and icecat <davexunit>no gcc-toolchain or autotools. I just spawn the appropriate environment when I want to build stuff. <rekado_>icedtea is actually just the build framework to clean up the openjdk and make it buildable with free software. <rekado_>too bad: even icedtea 2.5.5 fails to build :( same error as before. <taylanub>davexunit: how do you prevent frequently-used environment items from being garbage collected when they're not in your ~/.guix-profile ? <davexunit>if the environment is active, they won't be gc'd, though. <davexunit>the connection to the daemon is held upon for this purpose <taylanub>hm, ok. I guess one could just create a profile stashed some place for this purpose though. <davexunit>then you have to deal with cleaning up generations <davexunit>perhaps 'guix environment' could have an option to stash things in a profile <taylanub>I mean just something like 'guix package -p ~/.data/guix-profiles/foobar-deps -i dep1 dep2 ...' <davexunit>you can see that that is much less convenient <rekado_>I will post an updated recipe for 2.5.5 later. <taylanub>is a profile registered as a GC root when it's created by 'guix package -p foo' ? <mark_weaver>civodul: I'm sorry to say that 'ld-wrapper' has a problem in core-updates. it thinks that /home/mhw/.guix-profile/lib/libgcrypt.so is impure. the symlink following code seems buggy. <mark_weaver>as a result, I can't build 'guix' from the git repo using the new ld-wrapper <mark_weaver>'configure' fails while doing a test link with libgcrypt. <mark_weaver>I guess this is related to 41fc0eb90056c1f0aad41a971bf0c5eff5a72c97 <mark_weaver>looking at the output of ,trace (pure-file-name? "/home/mhw/.guix-profile/lib/libgcrypt.so") <mark_weaver>(readlink* "/home/mhw/.guix-profile/lib/libgcrypt.so") fails <mark_weaver>the loop does (readlink "/home/mhw/.guix-profile/lib/libgcrypt.so") <mark_weaver>which leads to (readlink "/gnu/store/p4z0rhhll9lmm5fnwgcz9w81cy0vj12i-libgcrypt-1.6.3/lib/libgcrypt.so") => "libgcrypt.so.20.0.3" <mark_weaver>and then is tries (readlink "libgcrypt.so.20.0.3") from the cwd which doesn't exist. <mark_weaver>so, the problem seems to be that when the symlink contains a relative file name, the relative file name is not interpreted properly. <mark_weaver>the loop before 41fc0eb90056c1f0aad41a971bf0c5eff5a72c97 worked because it would stop as soon as it found something in /gnu/store without continuing to read the symlinks. <mark_weaver>but the new code uses 'readlink*' which now continues the loop until it's no longer a link, leading to a relative file name. <mark_weaver>so 'readlink*' throws an error, and 'dereference-symlinks' returns the file name that was passed to it ("/home/mhw/.guix-profile/lib/libgcrypt.so"), which 'pure-file-name?' says is impure, and the link fails. <civodul>note that there's an env var to work around it *civodul goes on vacation <civodul>mark_weaver: looking at 41fc0eb90056c1f0aad41a971bf0c5eff5a72c97, it doesn't seem to be a regression <mark_weaver>civodul: looking at the code, I would expect that (pure-file-name? "/home/mhw/.guix-profile/lib/libgcrypt.so") would return #true before that commit, and #false after. <civodul>damn, why doesn't vc-log follow renames? <mark_weaver>before, the loop in 'pure-file-name?' would stop as soon as it found something in the store. <civodul>soooo, one way to handle this would be to merge core-updates (when it reaches a reasonable state), and advise people to use GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yes <civodul>then we would do the full rebuild in the background <mark_weaver>how about making a fixed ld-wrapper that's the one users would get from installing 'ld-wrapper' or 'gcc-toolchain' ? <mark_weaver>well, I'd rather not turn off impurity checking altogether. <mark_weaver>it also wouldn't force users to put this workaround into their environment. the workaround would be confined to guix itself. <rekado_>icedtea6 1.13.7 just finished building. Will commit/push the package update directly. <rekado_>contains a couple of security fixes that were released today <civodul>rekado_: i ediff'd the two build logs you posted but i don't find any clue :-/