IRC channel logs
2015-03-07.log
back to list of logs
<Sleep_Walker>mark_weaver: grub was installed to the partition but it wasn't copied to the /gnu/store <Sleep_Walker>but grub.cfg relies on loading font from there, so I got no graphics and some KMS intel graphics bug prevent me from booting for a while :) <mark_weaver>Sleep_Walker: can you email bug-guix@gnu.org about it? <Sleep_Walker>I started wicd, but I couldn't use wicd-curses because it seemed that dbus is not running - I couldn't verify as `dbus' or `dbus-service' were unknown to deco <mark_weaver>I would advocate removing the -daemon, -system, -service suffixes. <mark_weaver>it's documented in the "Jump Start" section of the dmd manual <mark_weaver>after a crash, dbus will sometimes fail to start because of a stale /var/run/dbus/pid file <mark_weaver>I have a commit in my private branch to clear out /var/run and /tmp at boot time, but for various reasons I haven't upstreamed it yet. <Sleep_Walker>I guess we should define and maintain some more package sets to ease people's life - like `minimal', `graphical', `enlightenment desktop', `xfce desktop', ... <les>Is guix system distribution viable enough for day to day computing use at present? <jxself>I understand that people do use it for that. <Sleep_Walker>lrwxrwxrwx 1 root root 62 7. bře 03.45 /bin/sh -> /gnu/store/nq6idcqwqc9x6z7g9jxq11a58jqx6w8x-bash-4.3.33/bin/sh <Sleep_Walker>does anyone know how the xsession file should be propagated? <Sleep_Walker>I have found xsessions-directory in gnu/services/xorg.scm, but it is not defined public <Sleep_Walker>iyzsong: you probably had to do that for Xfce, hadn't you... <iyzsong>Sleep_Walker: yes, how about replace it with /run/current-system/profile/share/xsessions? <Sleep_Walker>I can do that, but when my system profile change, how the symlink will be created in new path as well? <iyzsong>Sleep_Walker: I think after do the change it should work <iyzsong>currently, dmd won't reload services when system reconfigure <Sleep_Walker>iyzsong: so you say I should just add `install-xsession' phase after install, where I will create symlink to /run/current-system/profile/share/xsessions? <iyzsong>Sleep_Walker: add phase to what? I mean remove all the xsession handle in xorg.scm, just set 'sessiondir' as '/run/...' for slim.cfg. <Sleep_Walker>and whether such change of slim package will be accepted <iyzsong>I first tempted to follow what NixOS does (to generate xsession files), but it seem not work very well ;-( <Sleep_Walker>I'm thinking if there is hook for adding package into profile <Sleep_Walker>because that is the right place where symlink creation should go <Sleep_Walker>I'd still feel more comfortable with publicly defined function returning xsession directory for future changes <iyzsong>ok, I don't have a strong option anyway <jxself>You're local so maybe you can help. :) <jxself>In looking at the Charles River live feed, is the river frozen? It looks like it. <jxself>Well, as long as it is sufficiently frozen so that it doesn't break under you while you walk across... <taylanub>how can I see whether a package run-time-depends on another? I already have the potential dependencies in the store so "guix package -n -i foo" won't help if I'm not mistaken <davexunit>ice-9/boot-9.scm:106:20: Unbound variable: expat <mark_weaver>the problem was introduced in 246b3437f7015 (gnu: Add ghc.) <mark_weaver>but when doing a git bisect and just "make" at each iteration, that's the one that turned out. <davexunit>gnu: Add python-testlib and python2-testlib. <mark_weaver>(in this case, I needed to do "touch gnu/packages/fontutils.scm && make" instead of just "make" on each commit) <davexunit>;;; note: source file ./gnu/packages/ssh.scm <davexunit>;;; newer than compiled /home/dave/.cache/guile/ccache/2.0-LE-8-2.0/home/dave/Code/guix/gnu/packages/ssh.scm.go <mark_weaver>davexunit: interesting. what do you think is the problem, and how do you intend to fix it? <mark_weaver>bah, this is another instance of the common mistake (and (zero? (system* ...)) (chdir ...)) <davexunit>the problem is that the license field was '(license expat)' <davexunit>we selectively import a bunch and prefix some of them <mark_weaver>yeah, it would be nice if our handling of the license imports were more consistent <davexunit>so we have two '#:use-module (guix licenses)' declarations in (gnu packages python) <davexunit>that threw me off for a minute because I had never seen that done. <mark_weaver>we should probably pick a prefix and change all the package modules to import licenses with that same prefix <mark_weaver>or maybe even put the prefixes right in licenses.scm in the first place <mark_weaver>davexunit: are you going to push that fix, or should I? <taylanub>I sympathize with the license imports issue. prefixing them all right in licenses.scm sounds good IMO. <mark_weaver>davexunit: I went ahead and pushed the fix. sorry for being impatient, but I didn't want to leave 'master' broken for so long. <a_e>A gpg2 question: How do I use it? :-) <a_e>When trying to decrypt a file, it says: <a_e>gpg: public key decryption failed: No pinentry <a_e>I then installed pinentry; but nothing changed. <a_e>Does anyone know what to do? <mark_weaver>hmm, I confess I haven't used gpg2 to do anything that would require me to enter a passphrase. instead I let Emacs Gnus use gpg 1 for me. <mark_weaver>a_e: can you run it in strace and see where it's looking for pinentry? <a_e>I tried strace, it is not very helpful. <a_e>With "pinentry", I see this: <a_e>write(6, "OPTION allow-pinentry-notify", 28) = 28 <a_e>read(6, "ERR 67108949 No pinentry <GPG Ag"..., 1002) = 37 <mark_weaver>a_e: I have a file ~/.gnupg/gpg-agent.conf that contains two lines: first line "no-grab", second line "pinentry-program /home/mhw/.guix-profile/bin/pinentry-gtk-2" <a_e>One can run "gpgconf". This outputs a configuration file. <a_e>But it contains absolute paths /gnu/store/... instead of files in the profile. <a_e>Should then pinentry be a propagated input of gnupg2? Currently it is not an input at all. <mark_weaver>well, part of the problem is that there are multiple pinentry programs, and the user can decide which one to use <a_e>But the package would be needed. By the way, it does not work for me. <a_e>The same as before: gpg: public key decryption failed: No pinentry <a_e>I also tried to run gpgconf, as I am using gpg-2.1.2. <a_e>It suggests a slightly different line: <a_e>pinentry:PIN and Passphrase Entry:/gnu/store/hvv98hbjch4kb710wq0yyxvpk4wp4lyl-gnupg-2.1.2/bin/pinentry <a_e>But this also does not worl. <a_e>Complicated stuff - why does it not simply use a pinentry program in the path? <mark_weaver>but I suppose it would be sensible to make a default choice if you didn't configure one <a_e>Well, if I do not specify any, it could choose the simplest console based one. <a_e>To behave roughly as gpg1. <a_e>Maybe I should go back to the old one... <mark_weaver>I wish we had waited longer to merge core-updates. so much brokenness, and i686 is still way behind <a_e>No, we should have merged more often. <mark_weaver>I realize there's always a risk of 'master' being broken or a little bit behind. <a_e>We made so many changes that now it is unclear which is which. <mark_weaver>well, for those of us who are using GuixSD as our primary system, it's not nice to break 'master' so badly <a_e>For instance, I am now repairing the damage from my freetype update on February 15. <a_e>I agree it is bad to break master. <mark_weaver>a_e: how would merging more often help with that problem? <a_e>If we built _all_ of the distribution after each commit, then one would see more precisely which commit breaks what. And could repair more quickly. <mark_weaver>things have been in bad shape for several days now. I don't dare update. <a_e>Actually, it is not merging more often, but building everything all the time. <mark_weaver>a_e: sounds great, but our build farm isn't up to the task <a_e>Which is of course incredibly demanding. <a_e>At least, if we had merged before, there would have been less breakage. <mark_weaver>if anyone tries to install guix right now, they are going to be disappointed. and anyone who ran "guix pull" is also screwed until things get fixed. <a_e>There was a subtle problem in xpdf: It did not find freetype any more, but still built; except that it did not build the xpdf binary any more... <mark_weaver>all I'm saying is that we shouldn't merge a branch until it is almost entirely built on both intel platforms. <a_e>I found it out after upgrading and deleting all old generations in order to run "guix gc". <a_e>Probably so. But I also think we should merge a bit more often. Maybe once a week. <mark_weaver>we need a bigger build farm to do a once-a-week core-updates merge <a_e>I am afraid so. But this was already a problem this time - mips is unusable right now. <a_e>i686 is a political decision: We just do not use all possible machines. The idea is to get a quick feedback at least on the x86_64 architecture. <a_e>But this could be balanced some more. <a_e>Apart from mips, things are not so bad actually. <a_e>On mips, everything is broken because of patchelf. <a_e>I thought it did not work before either. But apparently I am wrong. <mark_weaver>things are finally getting close to where I'll be able to update my i686 system. <mark_weaver>but it's been several days where I wouldn't have been able to do that without fixing several bugs and having my machine compile for half a day at least, which is not good. <a_e>Right, I forgot i686. I updated my x86_64. <a_e>Then maybe we should use more i686 build machines. <a_e>The problem is that even when x86_64 is finished, these machines do not build i686. <a_e>I wonder if we should not drop mips from hydra. <a_e>One would not be overwhelmed with the many mips failures. <a_e>But this is more psychological than practical indeed. <a_e>I wonder if there is more than 1 person using mips - in which case hydra is pointless. <mark_weaver>a better solution perhaps would be to provide a way to selectively choose which platforms you see in the evaluation page. <a_e>Yes, that would also help. <mark_weaver>having more platforms help us keep our system portable <a_e>Yes, but platforms that are actually used are more motivating! <a_e>davexunit: I had already committed the same solution. <a_e>But for once, not pushed it immediately. <mark_weaver>it would be nice if someone would step up and contribute a good build slave for armhf <a_e>The new raspberry pi has almost the same specs as the novena. I wonder how well it would work. <mark_weaver>I can tell you that current 'master' fails in coreutils on armhf, due to a failed test having to do with locks. <davexunit>a_e: the rpi couldn't possibly build all of guix <davexunit>unless the new one has 8GB of ram or something <davexunit>I also wouldn't like to rely on a machine that requires a blob to function at all <a_e>And a quadcore armv7hf at 900MHz, whereas the novena is at 1.2GHz. <a_e>This looks quite similar. <a_e>Agreed, the blobs are a problem. <davexunit>my novena has finally shipped and I will be receiving it on friday. <a_e>And lucky - they are currently out. <a_e>I wonder if they will produce more. <davexunit>it's too special of a machine for me to dedicate to being a build slave, though. <davexunit>I'm not too familiar with other motherboards that support ARM chips <a_e>Does hydra cope well with temporary build slaves? <a_e>Like machines that only build guix packages at night. <a_e>Which might mean that during the day, there could be zero build machines, and hydra would need to wait. <davexunit>some people host build slaves from their residential internet connection, right? <a_e>Depending on your upstream, that is feasible. <davexunit>if it was cheap enough to build an ARM machine with 8GB+ of RAM, I'd consider hosting it at my house provided that it didn't cost too much in electricity or bandwidth. <mark_weaver>I don't think it needs 8GB. 4GB would be plenty, and even 2GB would probably be fine. <davexunit>I was trying to be on the safe side, since things like icecat require a lot of resources to build <mark_weaver>I can successfully build Guix without substitutes on my YeeLoong, which has only 1GB. it's slow of course, but I think the bottleneck is the CPU, not the RAM. <mark_weaver>but yeah, some things like icecat would need a lot more during the link. <mark_weaver>it seems that we're using patchelf for some core package, where we didn't before. I say that because we still have no working patchelf on ARM, and I worked around that problem for now by eliminating uses of patchelf from the important packages. <a_e>Kernel panic on debian! <mark_weaver>we need to either minimize our use of 'patchelf', or someone needs to step up and get it working properly on ARM. <a_e>What is the alternative to patchelf? Linking explicitly would be an option, but in python-2, the python binaries are linked with the python libraries. <a_e>So at the time of linking, they are not yet in their final location. <mark_weaver>patchelf is unfortunately a tempting crutch to avoid looking into how to add the relevant flags in the build system. <mark_weaver>Sleep_Walker: sriemer extensively reworked the way patchelf works in a fork of his, and I picked up his work for the armhf branch, but unfortunately it didn't work properly. <a_e>Did you try to recompile it by hand? <a_e>In case it is just a non-deterministic failure? <a_e>I rescheduled it on hydra, but it may take a while until it is picked up again. <a_e>Or disable the tests... <mark_weaver>a_e: the alternative is to arrange for the -rpath flags to be passed to the linker <mark_weaver>a_e: if the tests fail, that probably indicates a problem we can't ignore <a_e>Yes, but if binaries of the package need to be linked to libraries, which are still in the build and not yet the output directory? <mark_weaver>a_e: I'm not sure what happens if -rpaths are specified that don't yet exist at link time. it might work anyway, or we might have to arrange to install the library before linking the programs. <a_e>Or relink. In any case, it would mean quite some work. <mark_weaver>a_e: well, the alternatives are: learn a lot about ELF and rework patchelf to work on the platforms we wish to support, or drop armhf. <a_e>I agree we need to do something. <a_e>Where "something" is not "drop armhf" :-) <mark_weaver>would you like to try your hand at fixing patchelf then? :) <a_e>Hehe, definitely not. <davexunit>I wish I knew more about the nitty gritty details of this stuff <a_e>I just started my fuloong. But I think it will take at least an hour, maybe two to "make" guix. <a_e>I wonder how nix builds python-2. I see no reference to patchelf there. <davexunit>might try to make some progress on the ruby build system. I want to avoid all of the wrap-program usage that the python build system uses to get load paths right. <mark_weaver>davexunit: oooh, ambitious! that would be great though :) <davexunit>I *might* be able to patch ruby files to require libraries from absolute paths <a_e>rekado: Congratulations! A long time ago, that had been on my list of things to package. But if I remember well, there were tons of dependencies! <davexunit>requiring ruby libraries via an absolute path seems to be a dead end, and too gross. <davexunit>it's possible, but every single ruby library would have to be patched, but I'd rather just patch the executable ruby programs <davexunit>another strategy: add code to executable files that add ruby libraries to the load path <davexunit>so sort of like wrap-program, but it doesn't mess with environment variables. <rekado>davexunit: this sounds like a good idea. I'm doing something very much like that for solfege. <davexunit>perhaps we could take a similar approach to all python programs? <a_e>Tell me, we do not have /etc/resolv.conf in our chroot, do we? <mark_weaver>a_e: I don't think so. there's no networking anyway, so it would be rather pointless :) <rekado>I packaged the latest stable version 2.18.2. Unfortunately, tests are failing. <a_e>mark_weaver: The failing gnunet test needs it. <a_e>mark_weaver: On my fuloong, patchelf builds! *mark_weaver restarts the build on hydra <a_e>mark_weaver: I have already restarted it on hydra. <a_e>But sorry, I mixed up the installed and the freshly compiled version of guix. <a_e>On old patchelf-0.6 builds. <mark_weaver>a_e: you said you did, but it looked to me like it hadn't yet been restarted. <a_e>Well, it is in the queue. <mark_weaver>(it's status was "failed" and the build steps showed only one build attempt <a_e>Strange. Maybe another mistake. <davexunit>can the 'source' field be an arbitrary derivation? <davexunit>I'm doing some experimentation with scripts and I just want the source code to be a guile string written to a file with the trivial build system <a_e>patchelf-0.8 fails on my mips. <davexunit>which isn't quite what I want. oh well, I think I can make this happen another way. <a_e>If you just want it for a test, you can create a text file and "guix download file:...".