IRC channel logs


back to list of logs

<taylanub>mark_weaver: the test suite uses simple shell and 'expect' scripts, putting processes in the background with '&' and such; not sure if there's anything out of the ordinary. the parent process of the zombies is all PID 1, which is apparently the builder process in the jailed environment (don't know any details on how this works).
<mark_weaver>I wouldn't worry about it
<mark_weaver>I think it's probably specific to that package
<mark_weaver>a zombie process is just a process that has exited, but its parent has not yet called 'waitpid' on it.
<taylanub>ISTR an init process is expected to handle the 'wait' call necessary for exited processes, if their parent disowned the process. perhaps we need to implement such a thing?
<mark_weaver>and if its parent is PID 1, that's probably because its parent exited without ever calling waitpid
<mark_weaver>taylanub: I just don't see a need though.
<mark_weaver>does it cause any actual problems?
<taylanub>it's the reason 'kill -0' continues to return success
<mark_weaver>if our 'dmd' doesn't implement it, that would be a problem, I agree.
<mark_weaver>taylanub: what package is this again?
<mark_weaver>I think it would be okay to just disable the test suite for now, with a comment explaining the problem.
<mark_weaver>I'm open to adding functionality to guix-daemon to clean up orphaned processes, but since this is the only package that we've yet run into with this issue, it may not be worth it.
<mark_weaver>and it might be better to propose a patch to the package itself to clean up its own zombies
<mark_weaver>or we can just omit the test suite of this package
<ryuslash>mark_weaver: hmm, just copying my custom layout file into `$(guix build xkeyboard-config)/share/X11/xkb/symbols/' makes `setxkbmap' work. I know this isn't a fix though...
<mark_weaver>ryuslash: okay. those directories are supposed to be immutable though. that's needed for reproducable builds. but I suppose I can sympathize with you wanting your keyboard the way you like it ASAP :)
<mark_weaver>a slightly less bad hack would be to make a copy of $(guix build xkeyboard-config) somewhere else, make the mod there, and then run 'setxkbmap' with -I pointing there.
<mark_weaver>but at some point we should find a better solution, of course :)
<ryuslash>mark_weaver: I understand, I just wanted to know if there was something wrong with my understanding of where the file should go and what should be done to load it. or if it was because I use xorg.conf on Archlinux instead of setxkbmap
*mark_weaver looks at the setxkbmap source
<ryuslash>yeah, but so far I haven't been able to make it work with the -I switch
<ryuslash>and setting verbose to 10 doesn't present me with a lot of info either
<mark_weaver>-I adds to the end of the search path, so my earlier theory can't be right.
<ryuslash>yeah, discovered that, I used -I and set it to plain `us' and everything went as it should
<ryuslash>but does it look inside the directory passed to -I or some directory inside the one passed along? can you see that?
<mark_weaver>ryuslash: if you paste your file somewhere, along with instructions of where you put it and what commands you use to load it successfully, I could investigate further
<mark_weaver>please don't use though, because they block tor users.
<mark_weaver> works
*mark_weaver looks
<ryuslash>to make it work `cp ryuk $(guix build xkeyboard-config)/share/X11/xkb/symbols; setxbkmap ryuk' and to get back to us qwerty just `setxkbmap us'. my keymap is basically colemak, but with changed number keys, just so you know.
<mark_weaver>okay, I'll take a look.
<ryuslash>after seeing Ludovic's talk at Fosdem yesterday I just had to try guix :) it looked awesome!
<mark_weaver>it seems to be ignoring the -I altogether, based on looking at strace output.
<mark_weaver>ryuslash: I'm glad you stopped by! and this is how we work through problems, but having people show up that do something we haven't yet tried to do :)
<ryuslash>I'm glad I did too, thanks for your help :)
<grasshopprWhoppr>Can I substitute UUID for label in config.scm?
<mark_weaver>grasshopprWhoppr: search for 'title' in section 6.2.3 of the manual (File Systems)
*mark_weaver goes afk for a while
<grasshopprWhoppr>got it, mark_weaver. thanks
<ryuslash>mark_weaver: hmm, the error seems to be caused by a failing `XkbGetKeyboardByName' in setxkbmap.c
<grasshopprWhoppr>Is Alex Kost here?
<grasshopprWhoppr>loadkeys en-latin9 worked. thanks
<mark_weaver>ryuslash: I ran "strace -o trace.out setxkbmap -I/home/mhw/xkb ryuk" and there were no occurrences of "mhw" in the resulting trace, except in the 'execve' call at the top.
<ryuslash>mark_weaver: looking at the source, it seems that -I is only used for configuration files, not symbols or rules.
<mark_weaver>maybe a config file is needed to tell it where to look for symbols
<ryuslash>yes, I'm trying to find what it's supposed to look like right now
<mark_weaver>ryuslash: what you wrote contradicts what the man page says about -I though.
<mark_weaver>and also, since the -config option specifies a filename, I don't see why it would need a search path.
*mark_weaver wonders if -I is so seldom used that it's just broken and no one noticed
<ryuslash>I know, I thought so too, but anything passed to `-I' is added to `inclPath', `inclPath' is only used in `findFileInPath', `findFileInPath' is only used in `applyConfig' and `applyConfig' is only used in `main'. or at least as far as I can tell right now
<ryuslash>not true also, `inclPath' is also used in `applyRules'
<ryuslash>but that doesn't seem to help, as far as I can tell I can't do anything useful with rules.
<mark_weaver>this is terrible. unless there's some nice solution we're missing, we may end up proposing some patches for setxkbmap
<ryuslash>I think it may be X that's causing the problem, not setxkbmap.
<mark_weaver>at the very least, the setxkbmap is wrong, because it claims that -I specifies directories to search for layouts, and this is a layout
<ryuslash>since it's `XkbGetKeyboardByName' that actually causes the error and I don't think it takes any load-path-like arguments and it doesn't seem to be part of setxkbmap
<ryuslash>it all seemed so easy when I started :)
<mark_weaver>it is true that we arrange to pass -xkbdir $(guix build xkeyboard-config)/share/X11/xkb to X
<mark_weaver>so you may be right
<ryuslash>could other paths be added to this as well, by configuration or other packages perhaps?
*mark_weaver looks into it
<mark_weaver>it's not helpful that the X server only accepts one of those options :-(
<ryuslash>and not even a comma-separated list or something by any chance?
<ryuslash>that's too bad
<mark_weaver>ryuslash: we'll find a way to make this configurable
<mark_weaver>ryuslash: for now, you could modify gnu/services/xorg.scm
<ryuslash>could something be done with /usr/share/X11/xkb and symlinks to files in the package store?
<mark_weaver>search for -xkbdir in that file
<ryuslash>is there an Emacs command to view a certain package file definition? I forgot
<mark_weaver>you could replace (string-append #$xkeyboard-config "/share/X11/xkb") with some mutable directory, and then copy $(guix build xkeyboard-config) there.
<mark_weaver>the relevant code is not in a package, but rather in a service.
<mark_weaver>guix package -A <pattern> will tell you the locations of the matching packages.
<mark_weaver>there might be an emacs command, but I confess I don't know off hand.
<mark_weaver>we'll want a solution that allows us to update the system xkb files while allowing you to add your own. and that strongly points toward supporting a search path, like the setxkbmap man page claims is supported with -I
<ryuslash>thanks, sorry if this is a silly question, but what is the base directory for that? or should I download/clone something first?
<mark_weaver>the base is the guix source directory
<ryuslash>that would be best, yes.
<mark_weaver>i.e. the tarball or git repo.
<mark_weaver>I like to build and run guix out of a git checkout
<ryuslash>I just downloaded the USB install image and went from there
<mark_weaver>among other things, it allows me to make local modifications anywhere in the tree, and then I rebase my local patches onto upstream master frequently
<mark_weaver>working out of a git repo is definitely the way to go if you intend to hack on guix at all
<ryuslash>and you run GSD is just guix on top of something else?
<mark_weaver>and then I run guix directly out of the build source directory without ever running "make install", but prefixing the commands with "/path/to/git-checkout/pre-inst-env"
<ryuslash>My intentions for today were just to see how close I could get it to my Archlinux install for daily use :)
<DusXMT>Hmmm... It seems that something's wrong with the cross-compilation:!flGTemkuO6v1t20FNHajkOShH4MpWgOVqZCIy4ob
<mark_weaver>I installed GSD from the usb installer, and then used it to build guix from git, and then I run "/path/to/git-checkout/pre-inst-env guix system reconfigure <config>"
<ryuslash>cool :)
<mark_weaver>and that's how I update my system now. I never use "guix pull". instead I "git pull --rebase"
<ryuslash>couldn't something similar be accomplished with using guix build for changed packages? if you only want to change a few?
<mark_weaver>we have a GUIX_PACKAGE_PATH environment variable, but IMO it's a far inferior method, and I don't think it would work for a changed service.
<mark_weaver>and if you want to contribute to Guix, then working out of git is essential.
<ryuslash>I understand
<ryuslash>I can't commit to anything yet though :)
<grasshopprWhoppr>GSD could not find UUID, so I changed it back to label; but it's still looking for UUID.
<mark_weaver>of course not :)
<mark_weaver>grasshopprWhoppr: ah, I see that although the docs claim that uuid works, it's not yet implemented.
<ryuslash>mark_weaver: still have to mount my home disk before I can really start working, though :) anything I clone/download today is likely to be lost in the future when I finally get it mounted :)
<mark_weaver>see 'canonical-title' in gnu/build/file-systems.scm
<mark_weaver>ryuslash: *nod*
<ryuslash>mark_weaver: I feel almost completely new to GNU/Linux again :P
<mark_weaver>most of the problems we have boil down to our break from the FHS
<ryuslash>perhaps, though I'm more worried (and excited) about getting software installed than anything else
*mark_weaver goes afk for a while
<ryuslash>for example, (a worry) I just searched for SBCL and it's not available. And I'm not afraid of compiling software, but SBCL needs a working common lisp implementation to compile itself, so that'll be interesting to figure out :P
<mark_weaver>we have gcl
<mark_weaver>not sure if it can compile sbcl though
<ryuslash>that's my worry, I haven't tried gcl before yet either :)
<mark_weaver>if there's no other way, we can start by bootstrapping from an sbcl binary, although I hate to do it that way because it's yet another place that thompson viruses could hide.
<mark_weaver>compilers that need a binary of themselves to compile themselves make me grumpy :-(
<ryuslash>my thoughts exactly, although I've never heard the term thompson virus before :)
<ryuslash>hehe, it was a surprise to me the first time I saw it. it's the first application I ran into that needed itself to compile
<mark_weaver>here's the original talk about it:
<ryuslash>yes I think I've read that one not too long ago
*mark_weaver really goes afk this time...
<ryuslash>that was very interesting to read, I'd never considered it before that. freaked me out a little too :P
<ryuslash>well I have to go. it's 2AM here now, I'm getting sleepy and it's going to be difficult to keep my concentration at work tomorrow.
<ryuslash>mark_weaver: Thanks for your help, I've made a change to `gnu/services/xorg.scm' and I'll see if I can get to testing it tomorrow. Have a good day, evening or night, depending on your time!
<ryuslash>davexunit: thanks for your attention before. you have a good day, evening or night as well.
<Sleep_Walker>cannot read potential root `/var/guix/manifests'
<Sleep_Walker>cannot read potential root `/var/guix/manifests'
<Sleep_Walker>what can I do with this?
<Sleep_Walker>and can that be related to ?
<Sleep_Walker>(I cannot remove luajit even though there are no other referrers)
<mark_weaver>I don't think the /var/guix/manifests error is important. it doesn't even exist, right?
<mark_weaver>out of curiosity, why do you need to delete it?
<mark_weaver>(still curious what's keeping it alive, but also curious why you care :)
*mark_weaver wishes that civodul was here to answer the questions that I cannot
<mark_weaver>it might be that --referrers only finds referfers that are in /gnu/store, whereas there can be GC roots elsewhere in some cases (e.g. if a package is currently being built using it)
<mark_weaver>Sleep_Walker: ^^
*jgrant checked the depen list for XBMC. Wowzers.
<jgrant>Well, "Kodi".
<DusXMT>hmm, it seems that not even static binaries for the hurd from guix work... I'm guessing some missing obligatory patches...
<DusXMT>to glibc
<rekado>DusXMT: are you trying vanilla hurd? I was told that most of the Debian patches really should be applied (they just haven't made it upstream yet).
<DusXMT>rekado: I don't know _yet_, I just visited the hurd branch a couple days ago, but I'll look into it. I know there's a lot of obligaroty patches, but for right now, there's a real life issue I have to solve... (nothing big)
<taylanub>would Audacity belong in audio.scm?
<Sleep_Walker>good morning
<Sleep_Walker>mark_weaver: yes, the manifest file doesn't exist
<Sleep_Walker>2] I was cleaning all luajit versions after making changes to the receipt
<Sleep_Walker>3] if it wasn't running without my knowledge, it wasn't running at all
<taylanub>ugh, audacity is a beast
<taylanub>hm, I'll go back to nmap for now. no low-hanging fruits left from my personal software selection
*mark_weaver --> zzz
<Sleep_Walker>yay, Liberated X200 is available
<Sleep_Walker>this looks almost usable
<rekado_>I think I'm going to order the X200 from gluglug this week.
<Sleep_Walker>"Don't feed the troll" :D
<Sleep_Walker>interesting, I'm not able to find that mail in mailing list archive
<jgrant>messaging.scm is a bit of an odd choice for ngircd. :^P I would have thought a general ircd.scm would be better suited -- that being said, not sure if there are enough interest to package the other big 3-4, etc, to get make that worthwhile. :^P
<jgrant>In any case, such a move (as per my suggestion) is trivial and is more aesthetic if anything.
<Sleep_Walker>maybe irc.scm could be even better to have there clients as well...
<jgrant>Sleep_Walker: True.
<jgrant>What's irssi in, it's own module?
<jgrant>I suspect so, but too lazy to confirm.
<alimiracle>hi all
<alimiracle>I'm new in guex
<jgrant>alimiracle: Hody.
<alimiracle>I installed guix
<alimiracle>Its so good
<Sleep_Walker>whole distribution or just package manager ?
<alimiracle>package manager
<alimiracle>for me I cant install whole distribution
<Sleep_Walker>yeah, I'm using the same for now :)
<Sleep_Walker>and what distribution are you using Guix with?
<Sleep_Walker>I'm pretty sure people would like to hear some success stories ;)
<alimiracle>Because I am blind
<alimiracle>i'm useing trisquel
<Sleep_Walker>I'm afraid that Guix has not much work in accessibility areas yet
<alimiracle>no its so good
<Sleep_Walker>(I mean as distribution)
<Sleep_Walker>alimiracle: and you build it from source or someone made packages for Trisquel?
<alimiracle>I'm build it from source
<Sleep_Walker>good good
<alimiracle>and you??
<Sleep_Walker>I'm running Gentoo with Guix on top - I made ebuild for that
<Sleep_Walker>and I'm running Guix on top of openSUSE as well - I made package for that too
<Sleep_Walker>I'm preparing my second partition for Guix distribution but linux-libre is causing me most of the trouble
<Sleep_Walker>(My Thinkpad x230 requires some blobs)
<Sleep_Walker>but I'm trying to put all the packages I use inside the Guix so I can install them later anywhere regardless the underlaying distribution :)
<Sleep_Walker>and I take it as opportunity to learn some Scheme in the meantime
<civodul>Hello Guix!
<DusXMT>Welcome back, Ludo
<civodul>damn it, 92 unread messages in guix-devel
<iyzsong>Hi! XD
<Sleep_Walker>hello :)
<Sleep_Walker>"guix package: error: build failed: directory `/homeless-shelter' exists; please remove it" wtf of the day :b
<davexunit>civodul: did you demo anything new during your presentation?
<davexunit>I read the slides, a lot of the material was familiar, so I'm guessing the real coolness was in the demos and whatever the audience asked.
<civodul>hey, Sleep_Walker
<civodul>Sleep_Walker: you're not doing chroot builds, are you?
<Sleep_Walker>good question
<civodul>davexunit: yes, most of the talk was demos
<civodul>davexunit: so the usual command-line demo, guix.el, guix-web, a bit of Geiser, guix system vm, etc.
<civodul>and i wanted to show 'guix environment' briefly, and i forgot
<Sleep_Walker>civodul: --disable-chroot is not passed to guix-daemon if you mean this
<civodul>Sleep_Walker: either that or the configure-time setting
<civodul>but chroot support is definitely disabled on your system, see
<civodul>could you check what config.log has to say?
<Sleep_Walker>after rebuild of guix
<Sleep_Walker>well, I have installed 0.8 anyway so I should update it :)
<jgrant>This was the first Fosdem I was actively paying attention to; Are they usually this disjointed/disorganized?
<davexunit>every conference is
<jgrant>I mean, to the degree where the possibility of talks weren't recorded?
<jgrant>DusXMT: Is that a native install? :^)
<DusXMT>(We now have a Hurd cross-compiler, but there are still some issues with it... probably some missing obligatory patches)
<DusXMT>jgrant: nope, far from it, just a cross-compiled GNU Hello
<jgrant>DusXMT: Ah, okay.
*jgrant forgets if the Hurd 0.5 even has x64 support. His feeling is no.
<DusXMT>jgrant: the kernel has been ported to x86_64, it's just the userland now, which is a trickier dieal
<jgrant>DusXMT: Oh, it has? Did this happen in 0.5?
<DusXMT>jgrant: Mach is the kernel, and it's an unofficial port, yet
<jgrant>Yeah, the userland doesn't use upstream libc and other stuff -- right, or am I way off?
<DusXMT>jgrant: It's not that, it's just that tne interfaces expect types of set sizes, and going 64bits will change those sizes, breaking a lot of code
<DusXMT>The current plan is to build an emulation layer, so there can be a 32bit userland and 64bit kernel (but I guess that's off topic on #guix)
<civodul>DusXMT: nooooo, is this reaaaal?!
<DusXMT>civodul: I know, it sucks... we'll have to determine which patches are needed to get it to work...
<civodul>DusXMT: actually that was a positive comment, i hadn't noticed the "Killed" message
<civodul>now i see ;-)
<jgrant>Did derivations name get changed to "things" or am I just to tired to skim this commit?
*civodul has a big backlog
<jgrant>Ah, I see. Just general restructuring add general adding of build-things.
<civodul>DusXMT: you have a clever $PS1
<DusXMT>Thanks :)
<DusXMT>It's practical, you know when an error occured, and you know which code it is right away
<jgrant>Oh cool, someone packaged Sawfish. I wonder if this is the version that uses Guile 2.x.
<rekado_>I'm not sure how to use offloading.
<rekado_>I have a workstation and a shiny new build machine with lots of memory.
<rekado_>I created /etc/guix/machines.scm on the workstation.
<rekado_>the list only contains one entry: that of the build host.
<rekado_>I installed guix on the build host with empty prefix (same as on the workstation).
<rekado_>I also generated a key pair on the workstation with "guix archive" and let the build host import it (guix archive --authorize <
<rekado_>when I run "guix build" should I see some information about the build being offloaded?
<civodul>rekado_: the slave's key must be register on the master, and the master's key must be registered on the slave
<civodul>so they can exchange things
<rekado_>then it's just the build host's key that I still need to authorize.
<civodul>rekado_: but you can run "guix-daemon -M 0" on the master if you want to offload everything
<rekado_>ah, good.
<civodul>otherwise it will only offload when the master has reached the max number of jobs
<rekado_>(too bad generating a key takes so long. The build host is a VM and it takes a very long time...)
<civodul>i think that's because of lack of entropy
<jgrant>Is it likely that /gnu/packages/ will eventually get modularized from the main code base as the case with NixPkgs? I think we have some ways to go, but if the code base grows by like 3x for pkgs -- I think it makes sense. That's where a lot of the time it takes cloning appears to be coming from.
<civodul>there are advantages to having everything in one place
<civodul>initially Nix* was 3 different repos
<civodul>now it's only 2
<civodul>and sometimes it would help to have just 1
<davexunit>yesh, I don't mind that it's all bundled together.
<civodul>(in our case it definitely helps)
<DusXMT>civodul: One thing I'm not sure of is that, because of linking issues, I made cross compilers use an ld-wrapper. I don't understand why the Hurd cross-linker has trouble finding libraries that aren't in a specified RPATH, and I don't know if such a change is feasable, that's why I linked the email earlier
<civodul>i'll check your message but right now i need to catch up with other things
<jgrant>What are the two Nix repos now? Just Nix and Nixpkgs?
<jgrant>NixOPs being what was merged in?
<jgrant>Ah, NixOps is not what I thought it was.
<civodul>one is Nix, the other is NixOS+Nixpkgs
<jgrant>I assumed NixOps wat DevOps stuff.
<civodul>that's correct
<davexunit>I need to read the NixOps code sometime.
<davexunit>I imagine it's perl + c++ like everything else.
<civodul>Python this time :-)
<davexunit>oh my god.
*jgrant wonders how much of the depend list for Guix would shrink, if Nix deamon does get the mythical rewrite in Guile.
<davexunit>not by much.
<jgrant>G++ is gone.
<davexunit>if any.
<mark_weaver>civodul: btw, I was pleased and surprised to see your name mentioned in the acknowledgements of <> alongside Laura Poitras and Dan Bernstein :)
<mark_weaver>(and Luca Saiu also :)
<mark_weaver>jgrant: first, we should replace hydra
<jgrant>mark_weaver: Before Nix Daemon?
<mark_weaver>it has a lot of problems and none of us are enthusiastic about brushing up on our perl
<mark_weaver>jgrant: yes
<jgrant>Yeah, probably so.
<Sleep_Walker>checking for chroot... yes
<rekado_>hmm, offloading still doesn't work for me.
<jgrant>Is there any intention for "Guix publish" to be able to handle any of this workload as I seem to recall being eluded to on the ML somewhere -- or would this be allocated to a complete 3rd party, such as I understand how Hydra works now?
<rekado_>the pubkey of the workstation daemon has been imported on the build host and vice versa.
<rekado_>on the workstation I run the daemon like so: TMPDIR=/buildtmp guix-daemon --build-users-group=guix-builder -M 0
<rekado_>the daemon on the build host is up.
<rekado_>when I run ./pre-inst-env guix build <package> on the workstation, however, it's built by my workstation's daemon, not the build host.
<davexunit>replacing hydra will be nice.
<rekado_>(this package consumes all of my memory and a couple of GBs of swap on the workstation, so I really need to build it on the build host with 64GB memory)
<davexunit>the first piece, 'guix publish', is getting close. just a few blockers.
<mark_weaver>rekado_: and /etc/guix/machines.scm is set up?
<mark_weaver>I also want to set up offloading, but I've not yet tried.
<rekado_>shouldn't "-M 0" prevent anything to be built on my local guix-daemon?
<Sleep_Walker>civodul: config.log is here:
<rekado_>I wonder why the build process starts in spite of that.
<mark_weaver>rekado_: good question
<Sleep_Walker>it seems to be enabled, both chroot, unshare
<mark_weaver>Sleep_Walker: you are running guix-daemon as root?
<Sleep_Walker>mark_weaver: yes
<mark_weaver>rekado_: have you verified that the guix-daemon you launched with -M 0 is the only guix daemon running on the system? also what --prefix= did you use when building guix-daemon?
<Sleep_Walker>I'll try to run some build and check it's root settings through proc
<rekado_>mark_weaver: it's the only guix-daemon running. I reconfigured it with "--prefix=" (empty).
*jgrant will brb.
*mark_weaver defers to civodul
<mark_weaver>I really have to package up hdparm. I've never had a system that so aggressively spun down the hard disk all the time, even when plugged into the mains power. it's bad for the hard disk and my GSD system frequently hangs for a second or so while waiting for the disk to spin back up
<mark_weaver>the timeout has to be less than 20 seconds
<mark_weaver>maybe more like 10
<civodul>Sleep_Walker: what does "./guix-daemon --help|grep -A3 chroot" say?
<civodul>rekado: could you add a pk in machines.scm to make sure it's actually read?
<civodul>rekado: also, was 'guix offload' actually built? (try "guix offload --help")
<Sleep_Walker>hm, I haven't set chroot directory thoug
<Sleep_Walker># tr '\\0' ' ' < /proc/$(pidof guix-daemon)/cmdline; echo
<Sleep_Walker>/usr/bin/guix-daemon --cores 1 --build-users-group guix-builders
<civodul>Sleep_Walker: it seems that chroot support is built in, so i'm not sure what's happening there
<civodul>i don't see how /homeless-shelter would suddenly appear in the chroot
<jxself>It's a home for the homeless? Perhaps for zombie processes that have nowhere else to go?
<Sleep_Walker>I may know :)
<Sleep_Walker>is `guix environment' setting this?
<davexunit>Sleep_Walker: test with 'guix environment --search-paths'
<Sleep_Walker>it seems that I got set HOME=/homeless-shelter in environment and then run emacs, which created it's history files
<davexunit>I suspect the answer is "no", but I really don't know.
<Sleep_Walker># cat /tmp/nix-build-efl-1.12.2.drv-1/environment-variables | grep HOME
<Sleep_Walker>export HOME="/homeless-shelter"
<Sleep_Walker>here it is
<Sleep_Walker>so when I was trying to figure what the problem with EFL is I sourced this file to have the proper *PATHs and got to this
<Sleep_Walker>and again, completely my fault and no error on guix side
<Sleep_Walker>I even had to add {,/usr}/bin into my PATH manually to be able to run emacs
<davexunit>Sleep_Walker: well that is from 'guix build', I thought we were talking about 'guix environment'. my mistake.
<Sleep_Walker>davexunit: I was thinking loud, you read it correctly
<Sleep_Walker>OK, if I have time, I should write example of fixing broken code for Guix packagers guide
<DusXMT>ph4nt0mas: Hi, what do you think about the patches I sent you? (I'm Marek)
<ph4nt0mas>hey DusXMT just got back home from fosdem
<mark_weaver>DusXMT: I really appreciate your recent work on our Hurd port, btw.
*mark_weaver would like to use the Hurd more in the future
<ph4nt0mas>give me some time and I will answer tomorrow :P
<DusXMT>Of course :)
<DusXMT>It's a busy time indeed
<jxself>OR if you like having multiple kernels, include L4 as well as Linux and HURD?
*ph4nt0mas needs to get some sleep, too tired from the airplanes
<mark_weaver>jxself: huh?
<jxself>Just a thought :)
<jxself>If you've not heard of it.
<mark_weaver>I know about L4
<mark_weaver>a decade or so ago, the Hurd developers were considering replacing Gnumach with L4.
<ph4nt0mas>but they gave up on it
<ph4nt0mas>and after my suggestion they removed some traces of the l4 code from their codebase
<ph4nt0mas>in the libpthread lib if I remeber correctly
<DusXMT>From what I recall, l4 didn't have any sort of port seciruty, while that's a vital feature of mach
<ph4nt0mas>because it was causing us problems during the glibc build procedure
<ph4nt0mas>Thomas told me yesterday that he will try to fix some of the circular dependencies in their glibc
<ph4nt0mas>so our package recipe can become simpler
<ph4nt0mas>and I hope, that someday, the hurd glibc will be merged with the linux glibc
<DusXMT>ph4nt0mas: The cross compiler builds now, with the patches I sent you, but the executables it produces don't seem to work on my Hurd machine,!flGTemkuO6v1t20FNHajkOShH4MpWgOVqZCIy4ob ; my guess is that there are some patches missing... and the linker behaves strangely as well, as you can see, but I get the same thing with statically-compiled binaries
<ph4nt0mas>DusXMT: hm..will investigate and report back
<davexunit>another day, another person saying "just use conf files" when they see that guix packages are Scheme code.
<DusXMT>I used to think similarly, but I quickly discovered how empowering the Scheme packaging scheme is
<taylanub>so .pth files in PYTHONPATH aren't parsed it seems. what is the correct way to wrap a program for the right PYTHONPATH?
<taylanub>my approach was adding e.g. /gnu/store/...pygtk.../lib/python-2.7/site-packages to PYTHONPATH, but that contains pygtk.pth which points to a gtk-2.0 subdirectory which is the actual path I need. I could hardcode the gtk-2.0 part too, but it seems wrong
<taylanub>well, hardcoding the lib/python-2.7/site-packages part is probably wrong as well
<bavier`>taylanub: the .pth is not read by python?
<taylanub>bavier`: #python told me .pth files in PYTHONPATH aren't read
<bavier`>I see, but they are read when loading the module, correct?
<taylanub>no module is found in first place
<taylanub>I'm trying to use `wrap-program' to get zenmap to find pygtk
<bavier`>interesting. That pygtk.pth is created in the package recipe specifically for that purpose
<taylanub>I'm probably doing something wrong because I don't see any other packages using PYTHONPATH :P
<taylanub>or maybe we have no programs using pygtk yet
<bavier`>the python-build-system automatically wraps programs and sets PYTHONPATH
<bavier`>the gourmet package in gnu/packages/nutrition.scm uses pygtk
<davexunit>that reminds me, I packaged pip, but never made the modifications to make it actually download packages in practice.
<davexunit>a task for any interested python people :)
<taylanub>nmap is primarily a C program; can I somehow still utilize python-build-system?
<bavier`>taylanub: is it just the program-wrapping part you need?
<taylanub>I think so
<mark_weaver>in most cases, it's preferable to have programs look for the things they need directly in the relevant /gnu/store directory
<mark_weaver>e.g. in this case, to have zenmap use the absolute pathname to launch pygtk
<mark_weaver>taylanub: ^^
<mark_weaver>wrappers are an inferior method, IMO
<taylanub>so, I could patch .py files to use absolute paths to pygtk and such?
<bavier`>mark_weaver: I won't disagree, but patching a lot of source with references to /gnu/store quickly defeats the store compressor.
<mark_weaver>bavier`: I doubt it will make a big difference in practice
<mark_weaver>the problem with setting environment variables is that they propagate to all subprocesses
<mark_weaver>bavier`: thanks for fixing python-pillo!
<bavier`>mark_weaver: np
<davexunit>I wonder what can be done for guile to automatically replace the argument passed to a dynamic-link call with an absolute path to the relevant library.
<davexunit>yeah, I don't know if that's really possible.
<mark_weaver>how would that work?
<davexunit>I don't think it could.
<davexunit>but it can be a pain to do manually.
<davexunit>guix has a --with-libgcrypt-prefix configure flag, but for guile-opengl I had to regexp replace.
<bavier`>mark_weaver: my comment about patching source and the store compressor comes from the context of the perl module packaging I've been doing for hydra.
<mark_weaver>I believe (but am not 100% sure) that if the argument passed to 'dynamic-link' is an absolute pathname, it just uses that and doesn't search.
<bavier`>I think I ran into a size limit for the environment, having to propagate so many inputs
<davexunit>mark_weaver: yes, that's why for the guile-opengl guix package I patched it to use an absolute path to the relevant GL shared libraries.
<mark_weaver>ah, good
<davexunit>I guess in the short term a simple procedure could be made to abstract the regexp away
<davexunit>for other guile library packages that use the ffi
<mark_weaver>davexunit: maybe we could add a pass that looks for calls to 'dynamic-link' with literal string arguments, and replaces the argument with an absolute path
<davexunit>mark_weaver: how would you propose looking up a matching library? using the relevant search path env var?
<davexunit>put another way, searching the /lib dirs for the various inputs
<mark_weaver>right, something like that
*mark_weaver goes afk
<mark_weaver>LIBRARY_PATH would be the one
<mark_weaver>davexunit: regarding the inkscape update: is there no better URI than "" ?
<davexunit>mark_weaver: unfortunately, no. I asked the devs in #inkscape about it.
<davexunit>they did not upload this release to sourceforge.
<a_e>I just tried it with wget.
<a_e>It translates to
<mark_weaver>davexunit: you should probably add a 'file-name' field to the 'origin' form
<a_e>Would it make sense to use this? Or is it a cdn with changing addresses?
<davexunit>a_e: that I don't know. would have to ask #inkscape.
<mark_weaver>davexunit: what filename does "guix build -S inkscape" yield?
<a_e>Or does the "3854" characterise this release?
<mark_weaver>if it doesn't end with inkscape-0.91.tar.gz then you should add a file-name field, or use the URL a_e suggested if it turns out to be stable.
<a_e>I feel uneasy that the address might simply resolve to the latest available version, and when they switch to 0.92, we "lose" the package.
<mark_weaver>3854 is probably some dynamically allocated number by the web app, or some crap like that :-(
<davexunit>I think that is a unique id for the file upload on their website
*mark_weaver goes afk
<taylanub>I seem to have gotten the paths right, but now starting zenmap errors saying module object gtk has no attribute Box...
<davexunit>a_e: apparently the tarball will go up on launchpad sometime soon.
<davexunit>so I can just wait for that and resubmit the patch then.
<a_e>As you wish, you could also just push it now as it is and update later.
<taylanub>I guess I'll leave it be for now. I'm ignorant on python and pygtk and don't really get how I'm supposed to get this working.
<bavier`>taylanub: I wonder if it's a versioning thing
<taylanub>I dunno; zenmap ships as a python 2.7 library (with a main .py program) so I used python-2 and python2-foo packages for the inputs
<davexunit>what is a good source of information for the common sources of nondeterminism in software builds?
<mark_weaver>taylanub: did you use gtk-build-system or gnu-build-system ?
<a_e>davexunit: I went to the corresponding debian talk at fosdem, they said they wrote a wiki page.
<a_e>I did not look it up yet, though.
<davexunit>bavier`: thanks!
<taylanub>mark_weaver: oops, I used gnu-build-system. let me try.
<taylanub>that made the build phase fail pretty quickly:
<mark_weaver>I meant to write glib-or-gtk-build-system of course
<mark_weaver>taylanub: so simply changing from gnu-build-system to glib-or-gtk-build-system caused all of those failures, whereas it compiled successfully before?
<taylanub>glib-or-gtk-build-system by the way
<mark_weaver>that's surprising. it seems that glib-or-gtk-build-system is just gnu-build-system with some extra phases added to the end
<taylanub>hm, let me triple-check
<mark_weaver>btw, both (guix build gnu-build-system) and (guix build glib-or-gtk-build-system) export the same identifier %standard-phases, so if you import them both into the same module, one of them will have to be prefixed, and if you make changes to the phases, make sure to use the right one.
<mark_weaver>hmm, I see that we don't do this in bittorrent.scm
<mark_weaver>that's a bug
<mark_weaver>we don't do it anywhere :-(*
<taylanub>I change the (guix build-system gnu) import to (guix build-system glib-or-gtk), and the gnu-build-system variable reference to glib-or-gtk-build-system, and apparently that's enough to make the build phase fail as above
<mark_weaver>taylanub: can you paste your patch somewhere?
<mark_weaver>civodul: both (guix build gnu-build-system) and (guix build glib-or-gtk-build-system) export the same identifier %standard-phases. and yet, in all the package modules that use both (bittorrent.scm, emacs.scm, and gnome.scm), we import both build systems without any renaming.
<taylanub>the import is e.g. (guix build-system gnu) though...
<mark_weaver>e.g. in emacs.scm, there are two packages that use two different build systems, and they each refer to %standard-phases
<mark_weaver>so, one of them is using the wrong %standard-phases for the build system they requested.
<bavier`>mark_weaver: %standard-phases is evaluated by the builder, right?
<taylanub>.oO( the builder imports (guix build foo-build-system)? )
<civodul>iyzsong: what's the status of the 'xfce' meta-package?
<mark_weaver>bavier`: ah yes, you may be right.
<civodul>right, i don't think we use-modules both
<mark_weaver>it's still a bit discomforting. we shouldn't be importing two different bindings for the same identifier into the same module.
<mark_weaver>well, whatever. I guess it's not that important, it just seems sloppy to me
<taylanub>civodul: you replied 'OK to push' to a patch of mine; I don't have push access :)
<davexunit>cool, there's a better inkscape 0.91 url on launchpad now.
<davexunit>I'll fix up my patch.
<davexunit>but first... time to dig out from a foot of snow.
<mark_weaver>heh :)
<mark_weaver>taylanub: I pushed it for you
<mark_weaver>taylanub: I can reproduce the nmap problem. investigating now
<civodul>taylanub: oooh, good point!
<civodul>taylanub: we need to fix it, can you tell me what your SV account is? :-)
<mark_weaver>civodul: does glib-or-gtk-build-system build out of the source directory by default? (it seems to be so)
<mark_weaver>if so, where is the code that makes that happen?
<taylanub>civodul: TaylanUB
<mark_weaver>nevermind, I see
<civodul>taylanub: done, welcome aboard!
<civodul>taylanub: please read "Commit Access" in 'HACKING'
<mark_weaver>taylanub: the problem turned out to be that glib-or-gtk-build-system defaults to #:out-of-source? #t, whereas gnu-build-system defaults to #:out-of-source? #f, and nmap doesn't cope well with that.
<mark_weaver>taylanub: so, just add #:out-of-source? #f to arguments.
<mark_weaver>taylanub: and welcome aboard!
<civodul>good night/day, Guix!
<mark_weaver>g'night civodul!
<mark_weaver>nmap doesn't cope with #:out-of-source? #t, that is
<taylanub>thanks for looking into it!
<mark_weaver>np! thanks for all the new packages :)
<mark_weaver>taylanub: does it fix the "module object gtk has no attribute Box" error?
<taylanub>just tested; sadly, no
<mark_weaver>bavier`: the sipwitch builds are now fixed. it seems to ultimately be related to fixing python-pillow
<mark_weaver>yay for unexpected cascading fixes :)
<bavier`>mark_weaver: I'm surprised at that, since sipwitch doesn't use openjpeg or python-pillow at all
<mark_weaver>that would indeed be surprising :)
<bavier`>might be a coincidence
<mark_weaver>oh, nevermind. it was because a_e updated it
<mark_weaver>updated sipwitch to a newer version, that is
<bavier`>ah, truly coincidental ;)
<mark_weaver>or maybe it was his update of ucommon
<a_e>In fact, I updated its input ucommon.
<mark_weaver>a_e: thanks for fixing it!
<mark_weaver>so many broken python packages
<a_e>Well, I still have the hope that some day, we will reach 0 failed packages on hydra.
<mark_weaver>heh, dream on!
<mark_weaver>near the end of 2014, I saw a perfect evaluation of a core-only core-updates evaluation. I think that's the first time I saw a 100% evaluation
<mark_weaver>*100% successful evaluation
<a_e>We can always drop a bunch of python packages ;-)
<bavier`>I wanted to see if python-matplotlib was alright with the fixed python-pillow, but was scared off when I noticed I'd have to download texlive.
<mark_weaver>one request: let's not try to achieve that by removing MIPS from supported-platforms on packages unless we have good reason to believe that it would be a huge job to get it working.
<mark_weaver>it would be nice to split texlive into multiple outputs
<a_e>I just suggested it for one package on the bug tracker...
<a_e>I have been working on texlive for a while.
<a_e>It is impossible to split, I think.
<a_e>But I aim at having a full and a small texlive package.