IRC channel logs


back to list of logs

<mark_weaver>Steap: thanks for pointing out that I was doing patches the wrong way. I've been looking at the core packages for examples, and those packages still use the old way in master.
<mark_weaver>the new way is a lot nicer :)
<mark_weaver>damn, well, the new patch method doesn't seem to work with mit-krb5 anyway, because of the weird unpack method.
<mark_weaver>(krb5 is distributed as a tar file that contains a .tar.gz file and a signature of the .tar.gz file)
<mark_weaver>when I try the new patch method, it seems to try to patch too early, before the inner tar file has been unpacked. or at least that's my guess.
<mark_weaver>I guess I picked the wrong package to try the new method on first :)
<Steap>mark_weaver: np
<mark_weaver>actually, this will be a serious problem when the old method stops working.
<mark_weaver>I better let civodul know about this problem.
<civodul>Hello Guix!
<davexunit>hey civodul
<mark_weaver>hi civodul!
<mark_weaver>ImageMagick and lzip are two projects that don't provide stable URLs for their source releases.
<mark_weaver>lzip only distributes their latest version as tar.gz. older versions are distributed only as tar.lz, which requires that you already have lzip :-(
<mark_weaver>ImageMagick only distributes the latest on their mirror network. older versions are supposedly available on sourceforge, but there I can find ImageMagick-6.8.6-10.tar.gz, but not the ImageMagick-6.8.6-9.tar.gz that we're looking for :-(
<civodul>for lzip we should be able to talk to the author
<civodul>he's an (unhappy) GNU hacker
<civodul>but actually "guix build -S lzip --no-substitutes" works for me
<mark_weaver>oh right, the one who's unhappy with the widespread use of xz?
<civodul>yep :-)
<civodul>are you sure there's a problem with lzip?
<mark_weaver>well, a_e updated our recipe to the latest version, for now.
<mark_weaver>but every time a new release of lzip happens, we'll break under their current release policy.
<mark_weaver>(I was unable to build it until a_e updated it)
<civodul>actually for lzip we can just add /old/xxx as an alternate URL
<civodul>so that's easy
<mark_weaver>I suppose he'll wonder why we include a static bootstrap binary for xz and not for lzip.
<mark_weaver>civodul: a_e was the one who looked into it, but he said that although there was an old releases dir, that all of those were distributed only as .tar.lz
<civodul>aaah right, just realized
<civodul>looks like diplomacy is the only thing we can do
<civodul>but note that in practice, it's OK to use substitutes just for the source (assuming you don't want them for binaries)
<civodul>because that typically works
<mark_weaver>will their hashes be checked locally in that case?
<civodul>yes, of course
<civodul>the hashes are specified in the 'origin'
<civodul>so it's really just a mirror
<mark_weaver>well, is there a way to enable substitutes only for source downloads where the hashes will be independently checked?
<mark_weaver>I'm sorry, but I'm very unhappy about the casual attitude about security regarding substitutes. I generally want that stuff turned off.
<mark_weaver>also, does "guix pull" use any authentication?
<civodul>no, substitutes cannot be enabled just for source downloads
<civodul>and no, "guix pull" doesn't use any authentication :-/
<civodul>i'm very sorry about the security status as well, but i have only two hands
<mark_weaver>of course, I don't mean to blame you for any of this. i appreciate all that you do :)
<civodul>no problem :-)
<mark_weaver>I'll just say thank you for the --no-substitutes options :)
<a_e>civodul: Pulseaudio is again broken on hydra.
<a_e>It is broken more often than not, unfortunately.
<Steap>a_e: #:tests? #f :p
<a_e>Steap: Cheater!
<mark_weaver>on my YeeLoong, pulseaudio fails some tests: they time out.
<mark_weaver>tests/mainloop-test.c:102:E:mainloop:mainloop_test:0: (after this point) Test timeout expired
<mark_weaver>tests/thread-test.c:110:E:thread:thread_test:0: (after this point) Test timeout expired
<mark_weaver>tests/mix-special-test.c:312:E:mix-special 2ch:mix_special_2ch_test:0: (after this point) Test timeout expired
<mark_weaver>I'm not sure if it's just a matter of increasing the timeouts, or whether there's some genuine problem.
<a_e>On hydra, we also have:
<a_e>tests/thread-test.c:110:E:thread:thread_test:0: (after this point) Test timeout expired
<a_e>FAIL: thread-test
<a_e>But only this one.
<a_e>I get a funny message in gstreamer-0.10:
<a_e>configure: WARNING: Sissy ! By asking to not build the tests known to fail, you hereby waive your right to customer support. If you do not agree with this EULA, please press Ctrl-C before the next line is printed. By allowing the next line to be printed, you expressly acknowledge your acceptance of this EULA.
<mark_weaver>I'm going to fiddle with the pulseaudio timeouts on my Yeeloong.
<civodul>a_e: reproducible brokenness means good bug report, yay! :-)
<a_e>Indeed, think positive!
<a_e>All these bugs!
<a_e>The new version of libmicrohttpd fails its test. I reported it.
<civodul>all these opportunities for debugging!
<a_e>The new version of libextractor fails its test. I am waiting for libmicrohttpd to be fixed before reporting it.
<a_e>icecat requires gstreamer-0.10, not any later version.
<a_e>gstreamer-0.10 requires bison-2, not bison-3, or a patch.
<a_e>All this new software requiring obsolete software!
<civodul>ah ah :-)
<civodul>don't be depressed ;-)
<a_e>Bug fixing is good, but spending work on fixing other people's bugs is annoying.
<civodul>Bison 3 is just ~1 month old
<civodul>we can keep Bison 2 around if need be
<a_e>No, I applied the patch. So far it looks good.
<civodul>at some point we should try to somehow provide GNU maintainers more incentive
<a_e>Outch, 1 of 74 tests failed.
<a_e>Running suite(s): GstObject
<a_e>(gstobject:25478): GLib-GObject-ERROR **: cannot create instance of abstract (non-instantiatable) type 'GstObject'
<a_e>87%: Checks: 8, Failures: 0, Errors: 1
<a_e>gst/gstobject.c:77:E:general:test_fail_abstract_new:0: (after this point) Received signal 5 (Trace/breakpoint trap), expected 11 (Segmentation fault)
<a_e>FAIL: gst/gstobject
<civodul>"expected 11", wtf
<a_e>What is wrong with the following inputs:
<a_e> (alist-replace "python-wrapper" python-2
<a_e> (package-inputs gstreamer)))
<a_e>The error message is
<a_e>guix build: error: gnu/packages/gstreamer.scm:35:2: package `gstreamer-0.10.36' has an invalid input: ("python-wrapper" . #<package python-2.7.5 gnu/packages/python.scm:42 2fdeb00>)
<a_e>It looks good to the naked eye!
<a_e>Concerning the test for gstreamer:
<a_e>"Thanks for the bug report. GStreamer 0.10 is not maintained any longer, and
<a_e>there won't be any more releases.
<a_e>This has been fixed in git master and 1.x. It's nothing to worry about, the
<a_e>test was just silly"
<civodul>a_e: good news :-)
<a_e>civodul: Did you see my question on alist-replace above?
<civodul>a_e: about the error above: the invalid input here is a pair, where it should be a 2- or 3-element list
<civodul>it's not really an alist
<a_e>Ah, okay.
<a_e>Because we use alist-delete in other places...
<civodul>heh, yes
<civodul>you could use (alist-replace "python-wrapper" (list python-2) (package-inputs gstreamer))
<civodul>not so nice tho
<a_e>Well, it is getting too complicated - I also need to add an input.
<a_e>I think it is easier to just copy-paste.
<a_e>One test suddenly failed once, something like gst_get_date_time.
<a_e>We will need to observe if it reoccurs on hydra.
<a_e>If yes, I would disable it also. It looks like a problem with the time that advances...
<civodul>i think "guix package" is less ugly now, and probably even works better
<a_e>Is it longer or shorter now?
<civodul>perhaps slightly longer, but hopefully more readable and modular
<civodul>it may have brand new bugs too, so make sure to test it :-)
<a_e>It is difficult to not test "guix package"...
<a_e>So it is long, buggy, and ... beautiful?
<civodul>it does have tests, but incomplete coverage
<civodul>hopefully the modularity will allow us to write more tests
<civodul>a_e: (looking at the libmicrohttpd report) terminology: "the GNU distribution", not "the GNU Guix distribution" :-)
<a_e>Are we the one and only gnu distribution?
<civodul>the one and only, yes
<a_e>Then someone might have to package hurd.
<civodul>you know i explicitly ask them to publish releases before we could do that
<civodul>and they did
<civodul>well, except for that thing called "glibc"
<a_e>Now we have no excuse left.
<gzg>civodul: For network.scm, should I move all network utils out of system.scm and linux.scm (unless strongly tied to Linux like iproute)?
<civodul>gzg: Linux-specific things should remain in linux.scm
<civodul>i don't remember, did we discuss network.scm before?
<civodul>going to bed now, but feel free to email the list
<civodul>good night/day!
<gzg>civodul: I mentioned I was working on it (it started as wireless.scm), but you were on vacation when I wondered about moving related tech.
<gzg>Darn. :^P