IRC channel logs


back to list of logs

<jxself>Ah, communication.
<civodul>Hello Guix!
<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>nice, thanks!
<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>it's in (gnu system)
<civodul>i guess you may need to write something similar?
<Sleep_Walker>yes, I'm trying to make something for LVM
<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
<Sleep_Walker>this makes sense
<Sleep_Walker>but where from is luks-device-mapping called?
<civodul>where is it called?
<civodul>'base-initrd' takes a list of <mapped-device>
<civodul>see 'device-mapping-commands' there
<Sleep_Walker>I've been there
<Sleep_Walker>after that the link is not obvious
<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
<civodul>but all this is transparent
<Sleep_Walker>open is (mapped-device-kind-open (mapped-device-type md))
<Sleep_Walker>luks-device-mapping is used in configuration
<Sleep_Walker>now it makes sense
<Sleep_Walker>so type will return it and open returns proper function
<civodul>'open' returns a gexp to be precise, so a code snippet to run in the initrd
<Sleep_Walker>yeah, I'm still not used to terminology, sorry :)
<civodul>heheh, np
*civodul has a fix for Qt4, yay!
<civodul>now re-building with doc split out
<civodul>260 MiB of docs, that's crazy
<iyzsong>civodul: that's great!
<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_>new openjdk released, will update.
<davexunit>whoa we have openjdk now?
<davexunit>I didn't realize icedtea was the openjdk
<rekado_>icedtea is actually just the build framework to clean up the openjdk and make it buildable with free software.
<davexunit>I see
<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>taylanub: well, you don't.
<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
<iyzsong>I want jdk7 too
<taylanub>hm, ok. I guess one could just create a profile stashed some place for this purpose though.
<davexunit>it's much less convenient
<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_>iyzsong: me too. But I cannot get past this linker error:
<davexunit>it also doesn't consider native inputs
<davexunit>well, nvm
<rekado_>I will post an updated recipe for 2.5.5 later.
<davexunit>you are manually specifying dependencies
<iyzsong>rekado_: sure, thanks your works!
<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/ 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/")
<mark_weaver>(readlink* "/home/mhw/.guix-profile/lib/") fails
<mark_weaver>the loop does (readlink "/home/mhw/.guix-profile/lib/")
<mark_weaver>which leads to (readlink "/gnu/store/p4z0rhhll9lmm5fnwgcz9w81cy0vj12i-libgcrypt-1.6.3/lib/") => ""
<mark_weaver>and then is tries (readlink "") 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>civodul: ^^
<mark_weaver>looks like it's time to rebuild the world again :-(
<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/"), which 'pure-file-name?' says is impure, and the link fails.
<mark_weaver>civodul: ^^
<civodul>note that there's an env var to work around it
<civodul>but yeah...
*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/") would return #true before that commit, and #false after.
<mark_weaver>it certainly returns #false now
<civodul>yes, i've tested that
<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>aaaah, i see
<civodul>damn it
<mark_weaver>we should add a test to our test suite for that
<mark_weaver>it's okay, these things happen
<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
<civodul>and merge again when it's done
<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>and then fix it up in the next cycle?
<civodul>that's feasible
<civodul>is it much better?
<mark_weaver>well, I'd rather not turn off impurity checking altogether.
<mark_weaver>so it would be my preference. but it's not crucial.
<mark_weaver>it also wouldn't force users to put this workaround into their environment. the workaround would be confined to guix itself.
<civodul>yes, it's better
<rekado_>icedtea6 1.13.7 just finished building. Will commit/push the package update directly.
<civodul>to master?
<rekado_>contains a couple of security fixes that were released today
<civodul>nice that you were so fast, then!
<civodul>rekado_: i ediff'd the two build logs you posted but i don't find any clue :-/
<davexunit>hello henk