IRC channel logs


back to list of logs

<Sleep_Walker>good news is that shortening the path really works and only one test is failing due to sandbox
<rgc>I guess any recipe addition commit message should be prepended by 'gnu:' right?
<Steap_>rgc: we usually do that, indeed
<rgc>oks, thanks
<rgc>gnight. hope my 3rd try at luajit recipe is good to be merged :)
<mark_weaver>Steap_: if I remember correct, use 'wget' (or something else) and then "guix download file://..."
<Steap_>oh, guix download would work ?
<Steap_>I ended up doing
<Steap_> guile -c '(use-modules (guix)) \\
<Steap_> (add-to-store (open-connection) "foo.tgz" #f "sha256" "foo.tgz")'
<Steap_>which worked like a charm
<mark_weaver>I might be mistaken. anyway, glad to got it done.
<mark_weaver>too tired :)
<Steap_>I'm going through some Python craziness right now
<Steap_>for some reason, people write tests but do not include them in their tarballs
<Steap_>I can never remember what we call the MIT license
<Steap_>is it bsd-style ?
<guest`>Steap_: ambiguous, see and
<Steap_>guest`: yes, but I think we have a policy
<Steap_>permissive licences are getting so permissive we can't even know their names for sure!
<guest`>Steap_: there's expat, x11 and x11-style in guix/licenses.scm, so the difference seems to matter
<Steap_>guest`: indeed :(
<mark_weaver>Steap_: MIT license == X11 license.
<Steap_>mark_weaver: thanks
<civodul>Hello Guix!
<dhamidi>Good morning!
*civodul tried Guile-WM 1.0, but stumbled upon a few glitches
<Sleep_Walker>civodul: hi, I met similar issue to the one - this time not related to socket
<Sleep_Walker>I don't think it's duplicate issue
<civodul>"/var/tmp/portage/app-admin/guix-0.5/work/guix-0.5/test-tmp/store/nlpig1pgdgk6: bad interpreter: No such file or directory"
<civodul>Sleep_Walker: looks like you hit the shebang length limitation :-/
<civodul>i can't think of any nice workaround, other than choosing a shorter directory name
<civodul>or you could change the value GUIX_TEST_ROOT in
<guest`>about linux.scm, "XXX: For some reason, some virtio modules need to be explicitly added", .config uses dependencies, so the other entries will only appear after oldconfig. substitute* invocation relies on the entries already existing, so it relies on defconfig output and can break in other releases
<civodul>guest`: yeah, you may be right, i'm really no expert here :-/
<civodul>however, i thought "make config" would create a .config containing all the CONFIG_ entries, commented or not
<civodul>would you like to help in that area?
<civodul>that would be more than welcome :-)
<guest`>civodul: I think the most reliable way is just append all configs like you did bellow, and just get rid o substitute*
<civodul>but there could be duplicates, no?
<guest`>civodul: it uses the last
<guest`>BTW, I use "CONFIG_SATA_SIS=y\\n" and "CONFIG_SIS190=y\\n"
<civodul>for the VM?
<guest`>to my hardware
<civodul>you're running it on the bare metal? :-)
<civodul>hmm, the system built with Guix?
<guest`>no, just the kernel :P
<civodul>like operating-system-derivation and all that?
<civodul>i thought you were the earliest adopter ;-)
<civodul>well we need a way to parameterize kernel builds
<guest`>commit 882f034fa88361c703f382f08e158e15ce330c1d doesn't follow
<civodul>guest`: hmm in what sense?
<civodul>(re commit log)
<guest`>you shouldn't use e.g. CONFIG_VIRTIO_{NET,BLK,BALLOON}, you can't search for e.g. CONFIG_VIRTIO_NET
<civodul>right, good point
<Sleep_Walker>civodul: with shebang you mean first line with '#!/path/to/interpreter' ? I didn't know that it's limited, but what about invocation '/path/to/interpreter' ?
<guest`>Sleep_Walker: bash has limits too, but it is thousands not hundreds
<Sleep_Walker>I believe it would at least workaround the issue for most build environment
<guest`>Sleep_Walker: but you would need a bash shebang within limits, so it would not be in the same store
<guest`>or you would already need to be running bash, a limitation
<civodul>Sleep_Walker: Linux has this: #define BINPRM_BUF_SIZE 128
<civodul>anyway, for the purpose of running the test suite, you could try setting GUIX_TEST_ROOT=/tmp/guix-tests for instance
<Sleep_Walker>ok, I'll try
*civodul thinks these arbitrary limits should double every two years, to match Moore's law
<guest`>hurd doesn't have so many arbitrary limits, but until then, we can make a procedure to patch them and change the value with each guix release
<civodul>heh, indeed ;-)
<Sleep_Walker>I'm afraid that GUIX_TEST_ROOT wasn't respected, is it enough to have that set {for,right before} calling `make check' ?
<guest`>we can download python2-pysqlite from
<mark_weaver>there are to variants of pysqlite-2.6.3.tar.gz, with the exact same filename, but with a 20 kilobyte diff between them. *grump*
<mark_weaver>when he switched from to, I guess he decided to make a bunch of fixes and changes, but couldn't be bothered to change the version number. I sent him email about it, but he never replied.
<mark_weaver>this doesn't exactly play nice with a purely-functional distro like ours. we'll have to invent our own new version number, I guess.
<guest`>mark_weaver: what about changing the name to pysqlite-pypi-2.6.3.tar.gz?
<mark_weaver>well, that means changing the package name, which is even more radical.
<mark_weaver>I was hoping that if we waited a while, 2.6.4 would come out, and we could avoid having to deal with this.
<mark_weaver>would you like to try emailing him? maybe if we hears from more than one person, he could be convinced to bump the version number.
<mark_weaver>I can send you the diff if you like. it's quite extensive.
<guest`>mark_weaver: I think I'll wait and try other packages first
<civodul>Sleep_Walker: it has to be set directly in, and then you need to have autoconf & co. around
<civodul>guest`: you may be able to get the original tarball from, by running "guix build -S pysqlite"
<civodul>assuming you have substitutes enabled
<civodul>not a fix, but a workaround until it's actually fixed
<guest`>civodul: the same error, how I can enable substitutes?
<mark_weaver>they should be enabled by default, unless you passed --no-substitutes to either guix or guix-daemon.
<guest`>mark_weaver: no, maybe guix/pre-inst-env?
<mark_weaver>I've never actually used substitutes (for security reasons), and I don't know much about how they work, so I can't verify that civodul's suggested command should work. but he's the most knowledgable person on Guix by far :)
<civodul>guest`: are you on x86_64?
<civodul>then there's a bug preventing you to use them
<civodul>lemme check
<mark_weaver>I vaguely recall that the bug was that they substitutes couldn't be _disabled_ on i686, no?
<mark_weaver>s/they //
<civodul>oh right:
<civodul>guest`: is your store prefix "/nix/store"?
<mark_weaver>does the hash of a downloaded tarball depend on anything other than the tarball's contents?
<civodul>it depends on the output file name
<civodul>guest`: actually it has vanished from, so that's the reason
<civodul>so maybe we should just go ahead and update to use the latest tarball, no?
<mark_weaver>maybe we should just give it version number 2.6.3a or something.
<civodul>mark_weaver: you had a chance to review the diff, right?
<mark_weaver>wuold that be considered newer?
<mark_weaver>civodul: well, I didn't exactly "review" it. I'm not familiar with the code at all, so I couldn't competently review it.
<mark_weaver>but it looks vaguely like what I'd expect from a 2.6.3 -> 2.6.4 diff.
<mark_weaver>would you like me to send you or post the diff?
<civodul>i mean you did see the diff
<civodul>no obvious NSA backdoor? ;-)
<mark_weaver>well, I doubt they would be obvious. all a backdoor requires is the most subtle flaw in the new code.
<viric>mh in every channel I am, there are talks about NSA backdoors now :)
<viric>(talking about the bitcoin client, somewhere else)
<mark_weaver>but yeah, at a casual glance, it looks like a typical set of fixes and improvements. nothing obviously malicious.
<mark_weaver>but the unified diff is nearly 21 kilobytes.
<zacts>is that a linux kernel backdoor?
<mark_weaver>I'll post the diff to guix-devel.
<civodul>mark_weaver: ok, good
<mark_weaver>going afk for a bit.
<guest`>mark_weaver: but the next upstream version can be 2.6.3a, I think 2.6.3.pypi is more descriptive and unlikely to clash
<civodul>jmd: i just tried Inkscape and it works like a charm!
<jmd>Did you try any of the extensions. I think they rely on python.
<civodul>i'm pretty much an Inkscape newbie
<civodul>gotta go, ttyl!
<guest`>what about making the garbage collector preserve sources?
<civodul>well, it's not always desirable, and when it is, it seems hard
<mark_weaver>I need an alternative mode of GC in Guix, one that preserves everything that's needed to rebuild the reachable packages. I'll implement it at some point, if no one beats me to it.
<mark_weaver>I think the build machines need this too.
<mark_weaver>or at least a build machine that doesn't download substitutes needs it.
<guest`>mark_weaver: this is what I meant, would prevent the pysqlite missing from hydra...
<civodul>we could expose gc-keep-outputs (see <>)
<mark_weaver>(I don't want the MIPS build machine to download substitutes)
<civodul>actually gc-keep-outputs would do what you want, IIUC
<mark_weaver>civodul: I really don't see how it would.
<mark_weaver>but maybe I'm confused.
<civodul>well, sources are outputs of download derivations
<civodul>so in that sense it would
<civodul>but it may also retain too much stuff
<mark_weaver>yeah, but it only keeps the outputs of _non-garbage_ derivations.
<civodul>now, that's not optimal, i agree
<mark_weaver>suppose that GNU hello is the only reachable package.
<mark_weaver>I want it to keep everything that was needed to build hello, and everything that was needed to build those things, back to the bootstrap packages.
<civodul>right, but if you set both gc-keep-outputs and gc-keep-derivations, then you get to keep everything that was built, AIUI
<jmd>Can we add a "nogroup" group to the chroot's /etc/group ?
<civodul>alternately, we could imagine an option to keep the outputs of fixed-output derivations (i.e., sources)
<mark_weaver>oh, perhaps you're right.
<civodul>jmd: why? :-)
<jmd>Because I have a test which relies on it.
<jmd>(and it would be consistent with the "nobody" in /etc/passwd)
<civodul>good point
<civodul>assuming this is a standard convention, we could submit that change for Nix (the daemon)
<jmd>I dunno if it is "standard" but it is common.
<mark_weaver>civodul: how hard would it be to expose 'gc-keep-outputs'? I'd be grateful if you could cook up a patch.
<jmd>The default install rule should be changed to have a DESTDIR
*davexunit wishes he was still a student that could apply for GSoC
*Steap_ thinks davexunit is right
*Steap_ can still remember one of his friends getting a lot of money from Google to work on Compiz
<davexunit>I'll have been out of college for 2 years in may. I like not being broke but I want to go back.
<civodul>mark_weaver: it's actually quite simple, i'll look into it
<mark_weaver>my disks are running out of space, and I'd rather not try to figure it out by hand :)
<Steap_>davexunit: hahaha, 3 years in September. Time flies when you're doing crap instead of studying.
<davexunit>Steap_: it sure does. I miss just doing research and learning about theory instead of worrying about shipping on time.
<Steap_>davexunit: do you have a cool job, though ?
<Steap_>I was lucky enough to find jobs in Free Software, so working isn't as bad as I expected
<civodul>Steap_: you didn't do crap over the last couple of years, did you? :-)
<davexunit>Steap_: I am jealous. :)
<Steap_>civodul: well, I've met nice people and good hackers :)
<Steap_>civodul: but university was much better
<Steap_>civodul: and studying math was orgasmic
<jmd>Steap_: That's ironic, because for me orgasms are mathematical.
<Steap_>jmd: I guess I fail to understand this, since English is not my mother tongue
<viric>Steap_: I take it as "denoted a clear regular pattern"
<jmd>(It's fortunate that jemarch isn't here)
<civodul>Steap_: ah right, maths :-)
<civodul>which reminds me that jemarch sort-of offered to port Guix to SPARC :-)
*mark_weaver going offline for a bit
<jeffrin>hello all
<zerwas>Hello jeffrin
<jeffrin>zerwas : hello
<jeffrin>how are you ?
<zerwas>I'm ok, thanks. Looking for the FOSDEM guix video
<jeffrin>is the video available
<zerwas>not yet :-(