IRC channel logs


back to list of logs

<Sleep_Walker>mark_weaver: nope
<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 :)
<Sleep_Walker>lets try another attempt to boot guix :b
<mark_weaver>Sleep_Walker: can you email about it?
<Sleep_Walker>I just came back from guix
<Sleep_Walker>I'm fighting with deco
<Sleep_Walker>I'd love to be able to list known services
<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>Sleep_Walker: deco status dmd
<mark_weaver>it's called 'dbus-system'
<Sleep_Walker>mark_weaver: how you found `deco status dmd' ?
<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
<Sleep_Walker>I'm not that far I'm afraid
<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>nice, dmd has it's info page with Jump Start
<Sleep_Walker>but info is not part of system profile
<Sleep_Walker>another bug report?
<Sleep_Walker>hm, probably not, it need some more thinking
<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>not for me, but I'm still trying ;b
<Sleep_Walker># ls /bin/sh -l
<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>that is not right on my gentoo :E
<zacts>hi guix geeks
<Sleep_Walker>sounds redundant :b
<zacts>heh, hi guix
<zacts>is that better? :-P
<Sleep_Walker>zacts: definitely :b
<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>and it doesn't sound like the right solution anyway
<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>hmmm, that would be probably the best
<Sleep_Walker>the question is why it is implemented like it is
<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
<iyzsong>Sleep_Walker: under discuss, but let services read configurations from /run/current-system does feel easy for me.
<Sleep_Walker>I'd still feel more comfortable with publicly defined function returning xsession directory for future changes
<Sleep_Walker>thanks for pointer
<iyzsong>ok, I don't have a strong option anyway
<davexunit>hello #guix
<jxself>Oh ahoy there davexunit.
<jxself>You're local so maybe you can help. :)
<jxself>I've been looking at Boston weather. I found a live camera:
<jxself>In looking at the Charles River live feed, is the river frozen? It looks like it.
<davexunit>yeah it's frozen
<davexunit>I haven't really see it recently, though
<davexunit>I just heard about people walking across 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
<mark_weaver>taylanub: "guix gc --requisites" I believe
<taylanub>thanks, that seems to do :-)
<mark_weaver><NNNN> also has a "Runtime dependencies" tab
<mark_weaver>but hydra is overloaded right now
<davexunit>hmm guix master fails to build for me...
<mark_weaver>davexunit: details?
<davexunit>trying to fix right now, one sec.
<davexunit>I'll send the backtrace
<mark_weaver>well, it fails for me too
<davexunit>ice-9/boot-9.scm:106:20: Unbound variable: expat
<davexunit>same sort of error?
<davexunit>my backtrace:
<davexunit>the backtrace is a bit hard to decipher?
<davexunit>is the error in gnu/packages/python.scm ?
<davexunit>yeah, seems to be
<davexunit>in python-testlib
<mark_weaver>the problem was introduced in 246b3437f7015 (gnu: Add ghc.)
<mark_weaver>well, I'm not sure that's quite right
<davexunit>yeah, I don't think that's it.
<mark_weaver>but when doing a git bisect and just "make" at each iteration, that's the one that turned out.
<davexunit>I think it's a1920bc
<davexunit>gnu: Add python-testlib and python2-testlib.
<mark_weaver>yes, you're right
<davexunit>I'll push a fix real soon.
<mark_weaver>(in this case, I needed to do "touch gnu/packages/fontutils.scm && make" instead of just "make" on each commit)
<mark_weaver>davexunit: cool, thanks!
<davexunit>ah, I see
<davexunit>guix takes so long to compile for me
<davexunit>and I see a lot of:
<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?
<davexunit>the slowness?
<mark_weaver>no, I mean the problem with a1920bc
<davexunit>yes, sorry.
<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)'
<mark_weaver>oh, right!
<davexunit>instead of '(license license:expat)'
<davexunit>our (guix licenses) imports are odd
<davexunit>but they make sense
<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>ugh :)
<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>it might be that something is broken there
<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>and later
<a_e>read(6, "ERR 67108949 No pinentry <GPG Ag"..., 1002) = 37
<mark_weaver>ah, this rings a bell
<mark_weaver>I remember looking into this at one point
<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>Ah okay.
<mark_weaver>obviously we should make this nicer...
<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.
<mark_weaver>what happens now?
<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.
<mark_weaver>oh, I haven't tried gpg-2.1 yet
<mark_weaver>but it works for me with gpg-2.0
<a_e>Complicated stuff - why does it not simply use a pinentry program in the path?
<mark_weaver>well, it has to know which one you want to use
<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.
<mark_weaver>maybe based on whether DISPLAY is yet
<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.
<mark_weaver>libgnomeprint is also broken
<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>well, mips will be permanently hosed then
<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.
<mark_weaver>I don't think i686 could keep up with that either
<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.
<mark_weaver>how would that help anything?
<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.
<davexunit>mark_weaver: no worries.
<mark_weaver>having more platforms help us keep our system portable
<davexunit>I had to do a chore, so I was afk.
<mark_weaver>davexunit: thanks for figuring out the problem!
<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.
<a_e>Hm, ugly!
<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>It has 1GB of ram.
<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.
<mark_weaver>davexunit: that's good news!
<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 could also host another build box.
<mark_weaver>I've got the MIPS build slave at my residence.
<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>I've built icecat on i686 with 2GB of RAM.
<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.
<mark_weaver>oh, python-2 depends on patchelf now :-(
<mark_weaver>hmm, that's actually from last May
<a_e>Kernel panic on debian!
<a_e>This is original.
<mark_weaver>heh :)
<mark_weaver>wheezy, jessie, sid ?
<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.
<Sleep_Walker>what problem can be with patchelf on ARM?
<Sleep_Walker>ELF should be the same, shouldn't it?
<mark_weaver>Sleep_Walker: I don't really understand the problem, but see
<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.
<mark_weaver>his forked 'patchelf' was corrupting ELF files.
<mark_weaver>and the original 'patchelf' doesn't work at all.
<Sleep_Walker>interesting topic
<mark_weaver>and now patchelf is broken on MIPS too :-(
<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.
<mark_weaver>a_e: sure, it's worth a try
<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>I'm glad we can agree on that :)
<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.
<mark_weaver>heh :)
*davexunit updates fish
<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
<mark_weaver>that would be great!
<zacts>hi guix
<rekado>yay, just built lilypond :)
<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.
<rekado>(that's python, though)
<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 :)
<mark_weaver>rekado: ooh, that's great news about lilypond!
<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>a_e: interesting
<mark_weaver>with latest master?
<mark_weaver>so maybe it's a non-deterministic failure
<mark_weaver>that would be nice
<mark_weaver>or it might be related to 64K pages
*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.
<mark_weaver>davexunit: yes, I believe so
<davexunit>it accepts a string to a store path
<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:...".
<davexunit>a_e: ah, that's a good idea! thanks