<jgrant>I got a "guix system: error: build failed: unexpected end-of-file" when running system init. Is this due to my config file? <jgrant>Ran the same command again, doesn't seem to be a problem anymore. Odd. <jgrant>Why would the same command work right after, then? With no edits anywhere. :^P <jgrant>So Linode seems to use /dev/xvdaXY as for disks. <jgrant>Grub refuses to install itself there, it seems. <jgrant>"guix system error: failed to install GRUB on device /dev/xvda" *jgrant makes sure that this filesystem is not gpt. *jgrant is thinking it might just be easier and nicer for anyone wanting to do this, if he just provides a prebuilt binary himself going onwards... *jgrant will look into it more tomorrow when he has a full night of sleep. :^) <taylanub>moreutils is strange. source tarball only available from packages.debian.org. <jgrant>Hm, trying to compile 0.8.1 of Guix on GSD and it complains about "checking whether the compiler works ... no" and then says it can't create excutables therafter. <jgrant>Yeah, giving up for tonight. I'm sure it's a dumb mistake from being tired. <davexunit>pretty straightforward talk, used a lot of material from previous talks <davexunit>the good stuff will be the actual words ludo said along with these slides. *davexunit notices that ludo chose to use "guix web" instead of "guix-web" in the slides. <davexunit>I think that I can just make make the entry point to guix-web in the (guix scripts ...) namespace and things will indeed work like that, despite it not being in the tree proper. <toxemicsquire4>yea, first of all, I downloaded the guix source tree from git and I extracted it and copied my wicd.scm to the gnu/packages folder. I tried to run ./bootstrap before the "make && ./pre-inst-env guix build wicd <toxemicsquire4>but ./bootstrap failed because of undefined macro : PKG-CHECK-MODULES <davexunit>make sure you have installed everything that the HACKING file mentions <davexunit>in addition to the things in the installation instructions for releases <toxemicsquire4>I have made sure that I have everything needed installed. But maybe we need a meta package for that too, because it's a long list <toxemicsquire4>now it gives me an error when I run make, Makefile:106: *** missing seperator. Stop <davexunit>toxemicsquire4: if you already running a guix system, you can run 'guix environment guix' to spawn a new shell with all dependencies. <jgrant>davexunit: Yeah, Linode's resuce image fails to build Guix. <davexunit>toxemicsquire4: I haven't seen that error before. have you run './bootstrap' and then './configure'? <toxemicsquire4>Though now ./configure gives me some error about not finding makeinfo <davexunit>toxemicsquire4: do you have texinfo installed? <toxemicsquire4>Now I do, so Guix finally builds. Wow, so much work for the preliminary part of it. I can't imagine what it'll take to port wicd <jgrant>toxemicsquire4: Are you on GSD, or using Guix on a host system? <davexunit>toxemicsquire4: when you are more comfortable using guix, you should try running 'guix environment guix' to quickly setup a development environment. <jgrant>toxemicsquire4: Yeah, setting up a dev environment even with Guix Environment is not ideal atm. I really want a "guix devel" that will create a seperate development profile -- and clone into the latest repo. :^P <jgrant>Guix environment is devent in-route though. <davexunit>guix environment does exactly what you want to do, sans the profile. <toxemicsquire4>davexunit: I'll try to learn more about it, but for the mean time, I'll stick to what I'll already know. <davexunit>because, really, the profile is unnecessary in this case. especially now that guix environment runs pretty fast. <jgrant>davexunit: Doesn't it not stay as-is, once you leave the shell you used to call it? <davexunit>environment variables are the only thing that change. <toxemicsquire4>ok, once the guix building finishes, I could finally start finding out what's wrong in my messed up recipe http://pastebin.com/2q7LCv2i I filled in most of the things that I need, though I don't know how to add dependencies yet <davexunit>using a profile would work, but it's more of a burden. <davexunit>profiles protect the included packages from the GC, so you have to take care to prune old generations. <davexunit>how would guix environment stay deterministic if the user added/removed a package from the profile that it was using? <jgrant>Yeah, this is obnoxious trying to set up guix on finnix, might try to rebuild the binary again. <toxemicsquire4>ok, when I run ./pre-inst-env guix build wicd, it returns a build error guix build:error: failed to connect to '/usr/local/daemon-socket/socket': No such file or directory <jgrant>toxemicsquire4: If you are GSD, the Daemon should already be running...? <jgrant>davexunit: I'll look into it a bit more, regardless. <davexunit>toxemicsquire4: please see "installing guix from guix" in the README <davexunit>toxemicsquire4 configured guix to use /usr/local as $PREFIX (the default) <davexunit>so it's looking in /usr/local for the daemon socket <davexunit>I can't remember exactly where it is on the system (using debian right now), but the prefix must be changed to point there. <davexunit>toxemicsquire4: you'll want to tweak the --localstatedir flag <davexunit>search for a file called 'socket' on your filesystem <toxemicsquire4>there are /var/guix/daemon-socket/socket /var/run/dmd/socket /var/run/nscf/socket <davexunit>so try running './configure --localstatedir=/var' <toxemicsquire4>k, that finally allows me to build. but as expected, guix:build returns an error guix build: error: wicd: uknown package <davexunit>can you paste the contents of that file on paste.lisp.org? <davexunit>toxemicsquire4: so, the first question: does the file compile? <toxemicsquire4>I didn't know your supposed to compile it. are you supposed to use guile <davexunit>toxemicsquire4: since you've added a new module, you need add the file to the GNU_SYSTEM_MODULES list in gnu-system.am. <davexunit>one it's added, run 'make' and make sure it finishes successfully. <toxemicsquire4>guix fails to compile when adding wicd.scm to gnu-system.am make[2] *** No rule to make target 'gnu/system/wicd.scm', needed by 'all-am'. Stop. <davexunit>'gnu/system/wicd.scm' should be 'gnu/packages/wicd.scm' <jcca>Hi, I have added a new package distcc.scm, compiled and run successfully so now I want inject distcc in gnu-build-system. Any idea how do it? <davexunit>jcca: what is distcc and what do you mean by 'inject'? <jcca>davexunit: I mean how can I add some like this 'make CC=distcc' <davexunit>jcca: in a package that uses distcc, add an 'arguments' field <davexunit>the value is a list, and inside that you'll specify something like #:make-flags (list (string-append "CC=" (assoc-ref %build-inputs "distcc"))) <davexunit>look at the other packages for examples of using 'arguments' <davexunit>perhaps an unmatched double-quote to close a string, judging by the message. <davexunit>I have to go to sleep now. happy hacking everyone. if you find yourself banging your head into a wall and no one's around to help, send mail to the list. <jcca>I know but it only work for distcc I want some like this: <jcca>server side is working but I don't know how do client side. <jcca>toxemicsquire4: change '(define-public hello' to '(define-public wicd' <toxemicsquire4>jcca: That didn't change the compile fail error. I'll just work on it tomorrow <mark_weaver>jcca: using distcc is not really compatible with the fundamental principles of how Guix works. <mark_weaver>Guix goes to great lengths to make sure that builds are deterministic; that everything that is accessible from the build environment is identical every time. <mark_weaver>zykotick9: did you know that we have a command to generate VM images? <zykotick9>mark_weaver: i did not. i saw you had the previous version available as a pre-built image. but to be honest, that didn't work for either (i don't remember the issue), so i set my mind to trying the install with the new one ;) i might check the "vm generator" out sometime, thanks. <jcca>mark_weaver: got it. Thanks. finally I am compiling guix on ARM qemu this will take some days if not fault anything. <mark_weaver>jcca: okay. hopefully we can get an ARM build slave set up for our build farm soon. <zykotick9>mark_weaver: just so i'm clear - the vm command, you speak of, would require a running guix package manager installed on a currently running gnu/linux system correct? <mark_weaver>jcca: http://hydra.gnu.org/ is our build farm. it's a bunch of machines that compile all the packages in guix so that users don't have to compile things themselves. they can download pre-compiled binaries. <mark_weaver>but we don't have any ARM machines in the build farm yet, so no pre-compiled binaries for ARM. <mark_weaver>zykotick9: if you are worried about guix infecting the host system, it should be noted that guix only puts things in /gnu/store, $PREFIX/var/guix and $PREFIX/var/log/guix <mark_weaver>and if you install packages in your user profile, then it makes a ~/.guix-profile symlink <mark_weaver>so it's effectively invisible unless you set your environment variables (e.g. PATH) to point to things in ~/.guix-profile <mark_weaver>you don't have to run "make install". just prefix the commands with "/path/to/build-dir/pre-inst-env" and it will run out of the build directory <zykotick9>mark_weaver: you seemed to read my mind. i've been avoiding installing guix as a package manager, due to hesitations of having a 3rd party package manager on my system. i think you just laid those to rest. thanks! sounds like something i'd be willing to try :) ***kmic is now known as kmicu
***aurelien` is now known as aurelien
<DusXMT>If a gexp is in a quasiquoted list, if I want to ungexp a variable in it that's outside the quasiquote, I have to also unquasiquote it, right? (just making sure) <DusXMT>ignore the last line, chais in my mind <DusXMT>Yup, I do. One thing I really like about Guix and Guile is that I can test almost everything out in an interactive shell, I think it makes the learning quite a bit easier <taylanub>can Emacs's indentation of quoted lists be fixed? if it has the form '(foo bar <newline> baz) then baz is aligned with bar. <DusXMT>Sleep_Walker: it is, as foo isn't a procedure, it's just a regular item <Sleep_Walker>so you need to know all the procedure names to have correct indentation? <taylanub>specifically consider (#:foo bar <newline #:baz qux) <taylanub>Sleep_Walker: special-casing '( and `( would be a start <taylanub>indentation and syntax highlighting is always somewhat heuristic in Emacs from what I can tell. <Sleep_Walker>(not that I complain - I wasn't aware that WiFi can work this good with so many devices around) <Sleep_Walker>do I understand correctly that ldconfig is not available on Guix by design? <davexunit>Sleep_Walker: can you remind me what ldconfig does? <davexunit>Sleep_Walker: did you catch ludo's talk yesterday? *DusXMT thinks he saw Ludo in the microkernel room during the hurd talk, he saw someone with a Guix bag crossing by, but he only watched the stream <davexunit>Sleep_Walker: did the audience seem interested? <davexunit>I saw a decent amount of buzz on twitter about NixOS, but nothing about Guix. <Sleep_Walker>and I'm sitting in computer room so one guy near noticed it and asked about that <davexunit>some of the stickers need to make it to the US <taylanub>Some expect (.e) scripts in this test suite fail, but it doesn't give me any more details. how could I get more detailed output?.. V flag to make? <DusXMT>Sleep_Walker: You should've quickly switched to KVM, put it fullscreen, and said: Of course :) <davexunit>I guess I could just ask ludo for the dimensions of the sticker and the image file he used and print a bunch myself. <Morgawr>davexunit: I was super interested in Ludo's talk, it was really nice <Morgawr>it built nicely on top of the other talk I saw last year at FOSDEM <Morgawr>I really need to get my hands on guix and start hacking on it <Morgawr>I think the most interesting talks I've seen here at FOSDEM this year (at least within my interests) are the LFE (lisp on erlang) talk and the guix one <Morgawr>but there are so many concurrent talks and devrooms that it's so hard to follow everything <Morgawr>davexunit: You should totally, I'd buy you a beer for sure <Morgawr>the only annoying thing is that the timing of talks sometimes overlaps in uncomfortable ways, like a talk ends at 11:15 am and another starts at 11:00 am so you either miss the end of one or the beginning of the other <davexunit>yeah, there's a lot of cool hacker folks I've never met in person because the atlantic ocean is in the way. <Morgawr>I also spotted RMS talking with people around the hall of the K building yesterday <Morgawr>first time I saw him irl, it was nice <davexunit>a lot of people did, according to Twitter haha <Morgawr>I didn't want to look like a fanboy so I didn't ask for one, but I totally regret it now :P <Sleep_Walker>davexunit: btw. EFL/luajit problem finally solved - patch sent to the ML <davexunit>I must confess I know nothing about ldconfig. <Sleep_Walker>I only know that it is run when new dynamic library gets into system <davexunit>yeah, we refer to the libs explicitly via runpath and such. *davexunit experimenting with FRP libraries for use with 'guix web' <davexunit>with a tiny bit of glue, I was able to integrate a new FRP library called Kefir with the MVC library Mithril. <davexunit>I'm at the point where I *really* want to wrangle callback hell, so I'm going to use FRP to do it. <DusXMT>hmm, just found out: a cross compiled gcc keeps a symlink to the appropriate ld program... <DusXMT>Probably the only thing I dislike about Guix is the long waiting times you have to wait to test out a small change, I remember that was a great PITA with abiword... but I guess we now have `guix environment', which can cut off most of that time in most cases... <taylanub>anyone know whether lookups for 'localhost' work in the build worker environment? <paroneayea>my last talk at fosdem touched a litttttle bit on guix <DusXMT>paroneayea: Samuel's talk on how to contribute to the Hurd? <paroneayea>we had some good talks on what's needed socould solve part of the user configuration management problem <DusXMT>And so we're diving into hurd portability issues :D <DusXMT>the cross compiler's now working <DusXMT>Although I'm not sure if a change I did can be done. <DusXMT>I've made cross compilers use a ld-wrapper, so the paths to libraries get embedded into the binaries just like with native programs, although that means that they're bound to the cross compiler, since they have its library path (for libgcc) in their RPATH field. <DusXMT>mark_weaver: Do you think the change I did may be problematic? <DusXMT>alimiracle: each has its advantages and disadvantages, package manager wars is not something we want here <mark_weaver>taylanub: I have a hack that civodul and I use to fix the auto-indentation of keyword lists. <mark_weaver>taylanub: as for normal quoted lists, there's no good way to do it, because sometimes quoted lists are code, and thus should be indented as usual, and sometimes they are data. emacs has no way of knowing which it is. <mark_weaver>DusXMT: regarding the ld-wrapper thing, that's a question for civodul. <DusXMT>mark_weaver: ok, I'll ask him once he's available... <mark_weaver>taylanub: the build environment has an /etc/hosts file with an entry for localhost, so yes, lookups for 'localhost' should workd. <toxemicsquire4>I'm attempting to pkg wicd, and so far I have my environment setup and everything, and my recipe is correct, except that I don't know how to properly add dependencies <rekado>have you looked at other package definitions for inspiration? <rekado>a dependency is added as an input <rekado>a native input is something that is used at build time on the build machine. <rekado>regular dependencies at runtime are (inputs ...) <rekado>a common native-input is pkg-config, which is used at configure / build time, but it's not needed to run the application. <rekado>try without any native inputs first and try building the package. <rekado>I often start building without any inputs and I only add whatever the configure output tells me is missing. <davexunit>native inputs are important for cross-compilation, where the packages need to be built for the architecture of the build machine, not the architecture of the package being built. <toxemicsquire4>is there a way to only require python2 without depending on python3 <rekado>there are two packages: python (for the latest) and python-2. <rekado>the variable you can use as an input is called python-2. <rekado>try guix package -i python-2.7.6 <toxemicsquire4>yep, that works, thanks. So do I put that in the input declaration or just python-2 <rekado>in packages you have to use the variable names. <rekado>in python.scm there is only a variable named "python-2", so you use that. <davexunit>toxemicsquire4: when you use the guix CLI, you type in the name (and optionally version) of the package, not the Scheme variable name. <toxemicsquire4>davexunit: I'll remember that. Ok. Also, does the isc-dhcp package have dhclient <mark_weaver>in a package definition (define-public <variable-name> (package (name "<package-name>") ...)) <mark_weaver>you use <variable-name> to refer to it from 'inputs', 'native-inputs', etc. <mark_weaver>and you use <package-name> to refer to it in things like 'guix build' and 'guix package' <davexunit>toxemicsquire4: I believe our dhclient is a program of our own, written in Guile. <mark_weaver>I didn't know of any such wishlist item, but dhclient is just another program, written in C I suspect <davexunit>I'm pretty sure I read that in something ludo wrote awhile back. <toxemicsquire4>mark_weaver: so since the dhclient is in the isc-dhcp package would I declare it like this ("dhclient" ,isc-dhcp <davexunit>ah yes, it's in ROADMAP. "+ include a DHCP client written in Scheme" <davexunit>I had that mixed up in my head as something that ludo had already done. <davexunit>toxemicsquire4: just checked. no, we don't have it. <rekado>taylanub: I've got Ardour ready. Maybe some of its dependencies may be useful for Audacity. May be worth checking. <toxemicsquire4>davexunit: Would it be a bad idea to leave ncurses support out of wicd? <davexunit>toxemicsquire4: since it's a python package, you can run './pre-inst-env guix import pypi urwid' to generate the basic boilerplate <davexunit>toxemicsquire4: having wicd at all would be better than not having it. <davexunit>having curses support would be good, but if you decide not to go for it, make sure you leave a ';; TODO: Add urwid for ncurses interface' comment in the code. <toxemicsquire4>I'll have to make a recipe for urwid first, then make sure it can compile, then try to compile wicd. <davexunit>toxemicsquire4: is urwid not an optional dependency? <toxemicsquire4>It is, but it doesn't feel right to leave it out. Most network managers are very difficult to use from the command line, nm and wicd are 2 of them. the ncurses interface makes everything so much easier <taylanub>apparently it's really "localhost" that causes some issues in the ngircd test suite. the test sends "who localhos*" to the server and doesn't get the expected answer <taylanub>while localhost is mapped to 127.0.0.1, it also requires 127.0.0.1 to be mapped to localhost somehow? <taylanub>indeed. no idea how this reverse DNS works, but the server responds with 127.0.0.1 where the test suite expects "localhost" <alexshendi>Good evening! I have a package (ecl-13.5.1.tar.gz) that I can compile as a user with the usual "./configure; make" command. Can someone tell me how to get a build receipe skeleton for guix? <jxself>Look at a basic package like GNU Hello? <jxself>The (build-system gnu-build-system) thing is the key part. <jxself>Everything else is hopefully self explanatory. <toxemicsquire4>davexunit: I wrote up a recipe for urwid, add it to gnu-system.am, make, ./pre-inst-env guix build urwid, and it gives me back the error "gnu/packages/urwid.scm:35:12: In procedure module-lookup: Unbound variable: python-2" even though I entered (inputs `(("python-2" ,python-2))) <davexunit>toxemicsquire4: okay, so a couple of things: <davexunit>1) please put urwid in gnu/packages/python.scm <davexunit>one module per package is bad for organization. <davexunit>2) I'm guessing your current urwid module doesn't import (gnu packages python) <davexunit>the python-2 variable is defined in that module. <davexunit>alexshendi: yw. let us know if you have further questions. <davexunit>packaging a programming language implementation can be difficult. <taylanub>can I use a git repo as source, referring to a specific commit? <davexunit>the inconvenient part right now is generating the hash. <davexunit>someone needs to add git repo support to 'guix download' <toxemicsquire4>davexunit: Once I can get urwid.scm to package urwid property, then I'll put it in python.scm <davexunit>taylanub: in the meantime, clone the relevant repo yourself, delete the '.git' directory, and take a hash of the directory with 'guix hash' <taylanub>ok. what should I use as the source/origin in the package description? <davexunit>toxemicsquire4: okay, but it will be easier to just put it there. <davexunit>taylanub: checkout the 'git-flow' package in gnu/packages/version-control.scm <toxemicsquire4>davexunit: I'm getting ERROR: Bad qstring header component: ********************** <davexunit>that looks an error with the urwid build process <davexunit>I'm not familiar with it, so I cannot provide much help. <DusXMT>toxemicsquire4: A full tail log would be useful, in a paste for example <davexunit>that one line isn't enough context for me to guess at anything. <davexunit>toxemicsquire4: paste the log on paste.lisp.org or something <davexunit>(please don't use pastebin because they block Tor) <rekado>toxemicsquire4: that's an error with some web servers AFAIK. <mark_weaver>toxemicsquire4: normally we would write ("isc-dhcp" ,isc-dhcp) <mark_weaver>toxemicsquire4: I would like to keep ncurses support in wicd. any compelling reason to omit it? <mark_weaver>oh, I see. we need urwid. well, let's not delay wicd because of that. we can add ncurses support later *mark_weaver catches up on the backlog <mark_weaver>taylanub: there is no nameserver running in the build environment. just /etc/hosts, which the glibc name resolver will consult, but some other software might not look in /etc/hosts and instead insist on a real nameserver. <toxemicsquire4>Actually, I think itll only take a bit more than 2 weeks to get everything done. I'm still a newbie, so this is all very new for me, but I'll be able to finish it. I think an ncurses interface is very important for wicd, its very hard to use without it. <mark_weaver>most users will probably use a GUI interface for wicd, no? <davexunit>toxemicsquire4: but we can get the package into the distro sooner without it, and then just add the urwid input when it's ready. <mark_weaver>toxemicsquire4: I'd much rather have wicd sooner and add ncurses later. <mark_weaver>especially if it will take on the order of weeks, and we could have wicd today :) <mark_weaver>taylanub: what package do you want to use a git checkout for? <mark_weaver>toxemicsquire4: is that "bad qstring header component" error happening while it's trying to download the source tarball? <mark_weaver>that sounds like an issue I've seen before, with some web servers sending headers that violate the relevant RFCs, and Guile is strict about that sort of thing. <davexunit>you could send email to the people that maintain pypi and let them know of the issue <toxemicsquire4>wicd needs 1.2.4 or higher. They say it might work, but they don't garantee it <mark_weaver>and add a comment with the canonical source URL and explaining why we can't use it at present. <taylanub>mark_weaver: apparently ngircd removed tests depending on 127.0.0.1 resolving to "localhost", after the v22 release <taylanub>I could use the git commit, or patch the test suite myself; it shouldn't be difficult I think <mark_weaver>taylanub: can you find the relevant upstream patch and include it? <mark_weaver>our policy is to strongly prefer tarball releases. it's better to cherry-pick a patch from the repo than to use some random git commit. <mark_weaver>toxemicsquire4: btw, for that fedora URL, just include it verbatim. that big hash value will change in some unpredictable way when the next version comes out, so there's no point in doing the 'string-append' thing to construct the URL automatically based on the version, as we usually use. <taylanub>is there documentation on the format of the 'patches' field of the 'origin'? <taylanub>hm, I can just grep other files to find an example <mark_weaver>taylanub: (patches (list (search-patch "<filename>"))) <mark_weaver>where <filename> is the base name of a file in gnu/packages/patches <mark_weaver>and that filename should start with the name of the package <mark_weaver>and you'll also need to add that file to dist_patch_DATA in gnu-system.am <toxemicsquire4>ok, now urwid downloads from the fedoraproject mirror, but there is still an error about not having the proper sha256 hash <mark_weaver>i said "base name", but that's not quite right. it should include ".patch" at the end, but no directory names. <mark_weaver>toxemicsquire4: after downloading the file, run "guix hash <filename>" <toxemicsquire4>ok, now it starts building to an extent, but complains about no module called setup-tools <taylanub>hm, looks like the commit is on top even more changes in-between. this one removes DNS related things entirely from the test suite; I might add the patch which attempts to fix DNS related problems <mark_weaver>toxemicsquire4: are you using the python-build-system ? *mark_weaver is almost completely ignorant of python build systems <davexunit>setuptools is not an implicit input to the python build system <davexunit>since nearly every python package seems to use it. <mark_weaver>looks like you need to add ("python-setuptools" ,python-setuptools) to inputs <toxemicsquire4>and I also did add ("python-setuptools" ,python-setuptools) to the input declaration <davexunit>are you building with python 2 by any chance? <mark_weaver>davexunit: that looks like a good reason not to include python-setuptools by default <mark_weaver>also, i see quite a few packages that use python-build-system but don't need python-setuptools <davexunit>I wish there were a way for the right setuptools to be used automatically, based on python version. <davexunit>I stand corrected, then. I kept finding that setuptools was used a lot in the python packages I made. <mark_weaver>actually, the python2-setuptools should technically be in 'native-inputs' I think <mark_weaver>though the difference between them only matters when cross-compiling <davexunit>mark_weaver: I seem to remember there being a discussion about that... <mark_weaver>davexunit: several packages in python.scm put it in native-inputs, anyway <mark_weaver>and it definitely sounds like something that belongs there <davexunit>well then the pypi importer will need to be fixed, along with a bunch of python packages. <mark_weaver>I suppose if setuptools doesn't include any architecture-specific files, maybe it doesn't matter <mark_weaver>(e.g. a mips build of setuptools may be identical to an intel build) <mark_weaver>we have: lgpl2.0 lgpl2.0+ lgpl2.1 lgpl2.1+ lgpl3 lgpl3+ <toxemicsquire4>after I put it in the python.scm file, it gives me alot of warnings about possibly unbound variables <mark_weaver>toxemicsquire4: at the top of python.scm, where (guix licenses) is imported, only selected bindings are imported. maybe it's missing the one you need? <toxemicsquire4>I got it. I accidentally included urwid.scm #:import-modules statement. I took it out and it's good now. <DusXMT>toxemicsquire4: you have to create a patch using `git format-patch', add changelog entries to the generated file, and send it to the mailing list. <mark_weaver>toxemicsquire4: you don't add changelog entries to the generated file <mark_weaver>use "git commit -a" to commit it to your local git repo, with a suitable changelog entry. <mark_weaver>then "guix format-patch -1" will put the commit into a file, including the commit entry you wrote <rekado>"guix format-patch -1" should be "git format-patch -1" :) <toxemicsquire4>by local git repo do you mean the guix source tree that I got off git? *DusXMT never really got a hang of git... <taylanub>is there a reason a kill(1) command would fail in the build environment, on a process that was started by the builder? the test suite starts then tries to kill a process, failing if "kill -0" on the PID still returns 0 (success) after 5 seconds; so the problem could also be related to rapid re-use of the PID... <taylanub>hm, the line using kill is 'kill > /dev/null 2>&1 || exit 1' meaning the kill command itself does succeed, otherwise the script wouldn't continue (which it does) <taylanub>it works if I run the script manually outside the build environment. could it be that kill -0 doesn't work right in the build environment for some reason? <mark_weaver>taylanub: what does kill -0 do? I've never heard of that. <taylanub>mark_weaver: returns success if a signal can be sent to the PID *mark_weaver learned something new today :) <mark_weaver>I don't know why it would fail in the build environment <rekado>Any ideas which existing module should contain GNU Stow (tool for managing symlink forests)? Or a good general name for a module containing Stow? <rekado>it's not really a package manager, though, is it? <rekado>ok, package-management.scm it is. <ryuslash>is anybody here using a different keyboard layout than the default in X11 or any TTY? I'm having trouble switching (using GSD) <ryuslash>I'm trying to use xkbcomp, but it doesn't seem to be doing anything (X11 specific) <davexunit>I have never used xkbcomp, so I'm afraid that I can't answer your question. someone else here might know. <mark_weaver>ryuslash: I've successfully used "setxkbmap -option ctrl:nocaps" to put the control key where it belongs, and I guess that "setxkbmap -keymap" or "setxkbmap -layout" might help, but since I use qwerty myself I haven't tried. <mark_weaver>ryuslash: some web searches turned up example commands like "setxkbmap us -variant dvorak" but I dare not try it myself or I might not be able to fix it :) <ryuslash>thanks! ah that's much better already :) <ryuslash>would you also happen to know where the keymaps are stored on GSD? I've got a customized keymap and I don't know currently where to put it :) <mark_weaver>almost everything is stored in immutable directories, so you can't just put it there. <toxemicsquire4>mark_weaver: Sorry, but still not getting how to make a patch file. So I got my source tree that I got from git with my modified gnu/packages/python.scm, then I run "git format-patch", and after that "git commit -a", then "git format-patch -1", is that it? <mark_weaver>better to figure out a way to have setxkbmap find it where you put it <ryuslash>yeah, and there's no /usr/share or anything it seems <davexunit>toxemicsquire4: commit first, then run 'git format-patch -1' <mark_weaver>ryuslash: setxkbmap has a "-rules <filename>" option that may help <rekado>toxemicsquire4: 'git format-patch -1' means "take the last (1) commit and format it as a patch". So you need to commit your changes first. <rekado>"git commit -a" means: "stage all changes and commit them" <rekado>(if you have many unrelated changes that you don't want to commit you should use "git add -p" first to only stage the desired changes, then "git commit") <mark_weaver>toxemicsquire4: set the EDITOR environment variable to a command that exists on your system :) <rekado>"git commit" opens an editor in which you write your commit message. <DusXMT>(shameless advertisement: guix package -i nvi) <ryuslash>mark_weaver: hmm, damn, just keep getting "Error loading new keyboard description" <mark_weaver>what do you use to make a custom keyboard layout on other systems? <Morgawr>Does anybody know where to get the slides from the fosdem talk from this year? <rekado>toxemicsquire4: take a look at other commit messages with "git log" <ryuslash>mark_weaver: I've put it somewhere in /usr/share/xkb/ and loaded it using X11 configuration file <mark_weaver>toxemicsquire4: we have a set of conventions for the changelogs. <rekado>toxemicsquire4: the message should be in ChangeLog format <mark_weaver>it's not quite the same as ChangeLog format, but based on the same principles. <mark_weaver>toxemicsquire4: the first line should be something like "gnu: Add urwid." <mark_weaver>and then a blank line, and then something like "* gnu/packages/python.scm (urwid): New variable." <ryuslash>I just put my custom file next to the other keyboard layouts and it worked <taylanub>aha, the process turns into a zombie ("defunct") after killed <toxemicsquire4>ok, thanks I got that. But the patch file is telling me that I changed 16 files. I guess that's because I compiled <mark_weaver>it might be that the -I is overriding the default search path (not merely augmenting it), in which case you might need to add some directory in $(guix build xkeyboard-config) as well *mark_weaver goes afk for a bit <ryuslash>mark_weaver: thanks, that does sound plausible, I'll try that <mark_weaver>toxemicsquire4: run 'git add <files>' manually on the files you changed. then run "git commit" without the -a <mark_weaver>(you can abort by exiting the editor without saving) <toxemicsquire4>can't I just redownload the source tree and stick the modified python.scm in there, then run git commit -a, and git format patch -1 <rekado>toxemicsquire4: possible but rather unorthodox. In the long run there is no way around learning the few basics of git. <mark_weaver>toxemicsquire4: did you already commit it, is that the problem? <mark_weaver>toxemicsquire4: okay, type "git reset HEAD^" and it will undo the commit. <mark_weaver>but yeah, if you want to contribute to guix, you'll have to learn some basics of git. no getting around it. <toxemicsquire4>I'm just in a real hurry right now because I wanna finish this and be free to watch the superbowl <mark_weaver>toxemicsquire4: well, you can do the equivalent of redownloading the source tree by doing "git reset --hard origin/master" <mark_weaver>that's why I suggested omitting the --hard option, so it doesn't actually change any files, just undoes the commit itself. <DusXMT>toxemicsquire4: congratulations! *mark_weaver sometimes forgets the irc-nick <--> email mapping :) <mark_weaver>well, nevermind, in this case the mapping is pretty obvious, heh <taylanub>it looks like our build environment somehow causes lots of zombie processes <taylanub>(they disappear after the build process) <mark_weaver>taylanub: when a build is done, guix-daemon kills all processes by that build user <mark_weaver>taylanub: do you think this zombie problem happens with most/many builds, or is it specific to one package? <DusXMT>toxemicsquire4: I think you forgot to attach the actual patch to your email