<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).
<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
<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>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>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?
<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
<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)
<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>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
<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?
<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
<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
<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, https://img.bi/#/L2E76tT!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?
<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.
<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>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?
<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.