IRC channel logs


back to list of logs

<civodul>mark_weaver: WDYT about using kernel 4.0 by default?
<mark_weaver>civodul: I don't feel strongly about it, but I'll note that there will be no more point releases for 4.0.x (or maybe just one more, I forget)
<mark_weaver>and fwiw, I've not had any problems with 4.1.2
<mark_weaver>we will have to drop 4.0.x soon though, because it will not be getting any more security updates.
<civodul>mark_weaver: yes, i see it really as an interim solution
<sprang>hello, I just installed the guix binary on my arch system... whenever I run any guix command I see "warning: failed to install locale: Invalid argument"... any tips?
<sprang>it seems to be working fine other than that message
<mark_weaver>civodul: the GC finished. I just merged master into core-updates and asked for another evaluation or core-updates.
<yenda>sprang: I had this on arch with a totaly unrelated issue so maybe this thread is relevant to you
<mark_weaver>there have been enough changes in master since the last merge that I thought one more evaluation would be helpful.
<mark_weaver>(to avoid too large a window where people need to compile some big packages locally)
<yenda>really there won't be a linux terminator release ?
<civodul>mark_weaver: great, thanks!
<phant0mas>in cross-gcc xlinux as an input creates some problems
<phant0mas>it expects linux-headers to be present as an input in glibc, which is not the case for the hurd glibc
<phant0mas>will probably need to change it to something like "kernel-headers" ,(if hurd ...)
<civodul>maybe yes
<civodul>ACTION fixed two serious scalability issues in 'guix publish' \\o/
<sprang>yenda: thanks, I will take a look
<civodul>Hello Guix!
<civodul>ACTION upgraded his whole profile
<civodul>and hydra is blazingly fast, as crazy as it may seem
<carif_>when i do an initial install as per directions, does the last step 'guix system init /mnt/etc/config.scm /mnt' create a log? Apparently the last step, to write grub, failed and lost the exact message. Also, can I boot my machine using the usb image and then do the last grub step manually?
<carif_>ACTION is very close to a guix system
<iyzsong>does the installation resumable (don't copy store items twice)? anyway, it's always safe to try it again..
<civodul>things are not redownloaded/rebuilt, but they are re-copied to the target
<iyzsong>so, I think if carif_ reboot with the usb image, it need redownload again.
<yenda-> what do they mean by the BIOS is "almost free" ?
<yenda->is there such thing as almost free or it's just for good measure ?
<civodul>iyzsong: but rebooting loses pre-built/pre-downloaded stuff
<yenda->did they put an electronic bracelet on it ?
<civodul>iyzsong: i upgraded emacs and somehow it can no longer find its icons: Icon 'document-new' not present in theme Adwaita
<civodul>is this specific to my setup?
<iyzsong>civodul: do you have 'adwaita-icon-theme' installed?
<davexunit>yenda-: the bios is no more free than most other laptops
<iyzsong>I think many gtk3 applications expect it to be installed..
<civodul>iyzsong: no but i didn't have it before either
<mark_weaver>civodul: so, I can't build
<mark_weaver>I can't build 'guix' on armhf because I can't get the 'netpbm' source code.
<civodul>iyzsong: problem fixed when i install it
<carif_>iyzsong, civodul, so a log is created somewhere? I'd like to know what the error was so perhaps I can avoid a retry. Pl. advise.
<civodul>mark_weaver: oh, the source moved again?
<iyzsong>good :-)
<carif_>perhaps there's something like "update-grub"
<mark_weaver>netpbm is on sourceforge, which has been down for a surprisingly long time. they have a subversion repo somewhere else (which is where we get the source), but that's down too.
<civodul>is SF still down?
<mark_weaver>civodul: yes
<davexunit>I thought sourceforge was back?
<civodul>mark_weaver: you could enable substitutes and run "guix build -S netpbm -s x86_64-linux"
<civodul>as an interim solution
<mark_weaver>civodul: interesting. so the one for x86_64-linux will work to build armhf?
<iyzsong>carif_: I don't know whether 'guix system init' save log. but if you haven't reboot, I'd just suggest to install again.
<iyzsong>run the 'guix system init' again.
<mark_weaver>carif_: I don't believe there is a log of installing grub
<civodul>mark_weaver: it will use the substitute, but actually you don't even need "-s x86_64-linux" for that
<mark_weaver>civodul: I tried to do that a day or two ago, and it didn't work. as I recall, the substitute wasn't on hydra.
<mark_weaver>I'll try again.
<civodul>it's available at
<mark_weaver>civodul: okay, it worked this time, without the -s
<mark_weaver>attempting to build 'guix' now
<mark_weaver>other broken source URIs include lsof and sqlite
<mark_weaver>well, I can't connect to the lsof site because my IP address cannot be converted to a name and then back to the original IP, which I suppose I ought to complain to my ISP about.
<mark_weaver>*lsof ftp site
<francis7><yenda-> what do they mean by the BIOS is "almost free" ?
<francis7>yenda, librem comes with a proprietary BIOS developed by American Megatrends
<francis7>or "AMI"
<francis7>AMI also developers proprietary firmware for the large OEMs
<mark_weaver>I'm not sure how that could be called "almost free"
<davexunit>I think they have some naive belief that will be able to work out a deal to free the source code.
<davexunit>but that ain't gonna happen.
<mark_weaver>in their little table comparing themselves to other laptop offerings, it's interesting that they didn't include the Libreboot X200
<cirno9>good morning :)
<mark_weaver>IMO, they are being dishonest
<davexunit>they've gotten a lot of flak for it.
<davexunit>but seems like they haven't really corrected anything.
<mark_weaver>an honest table would use red color for their bullshit "almost free" boxes, and would include the Libreboot X200 which would have a green box in the BIOS column.
<mark_weaver>but if they did that, they wouldn't look so attractive, so we can't have that...
<francis7><mark_weaver> in their little table comparing themselves to other laptop offerings, it's interesting that they didn't include the Libreboot X200
<francis7>That's because if they did, people would immediately have something that's real and not fake to compare to.
<francis7>mark_weaver, the whole point of that large box with the green dots is to make the BIOS issue look less relevant.
<cirno9>they have their own fork of FF ignoring icecat..
<mark_weaver>and again, they pretend the other free browsers don't exist
<mark_weaver>trying to position themselves as the first free thing
<cirno9>well maybe if someone shoots them an email about it they will fix it up, it seems like what they aim to do is good
<mark_weaver>cirno9: they've been told.
<cirno9>ah that's a shame
<mark_weaver>I don't think they aim to do good. I think they aim to mislead people.
<cirno9>I want to add a package to gnu/packages (so I can contribute a patch/package definition) - I have /gnu/store/...-guix-source but I don't think I edit that directly? Might I have to change my setup a bit? (This is on guix SD)
<mark_weaver>cirno9: set GUIX_PACKAGE_PATH to a directory that will contain your package recipes. see section 6.5 (Package Modules) in the guix manual.
<mark_weaver>or better yet, build guix from git, and then make modifications in the git checkout. that approach has many advantages, although it takes a bit more work at first.
<mark_weaver>civodul: the new guix snapshot failed to build on mips:
<mark_weaver>compile error, not tests
<mark_weaver>I'm building guix clean from git on one of the mips slaves.
<civodul>mark_weaver: gnuzilla.scm not found? any idea what that could be?
<mark_weaver>civodul: I'm quite puzzled.
<mark_weaver>the clock on one of the hydra slaves is about 20 minutes slow, despite running openntpd. I wonder what's up with that, and if it might be responsible for this error.
<civodul>should we restart it?
<mark_weaver>civodul: actually, I just realized that the failure was in guix-0.8.2, not the snapshot.
<mark_weaver>the snapshot hasn't yet been built on mips.
<mark_weaver>yeah, I'll restart it.
<yenda->mark_weaver: also isn't there this backdoor issue with the iX intel chipsets ?
<cirno9>I can't find the "Building from Git" section in the guix manual, some IRC logs said it's in HACKING but it's not there either
<cirno9>ah it's in contributing
<mark_weaver>yenda-: my understanding is that in all newer intel chipsets, we've been unable to find a way to run them without loading their proprietary OS into that independent processor in the northbridge that has direct access to the network devices and can be used to remotely reconfigure the machine, regardless of what OS you have installed.
<mark_weaver>the best place to ask about this is in #libreboot
<rekado_>(what does "OS freed" in the context of hardware manufacturers even mean?)
<mark_weaver>yeah, it's ridiculous
<mark_weaver>well, to be fair, it is relevant and important what OS is initially shipped with a given piece of hardware.
<mark_weaver>but it is clear that they are deliberately omitting all other good (and better) options in their comparison tables
<cirno9>How do I find this? the 'localstatedir' value of the currently installed Guix
<cirno9>I tried to enter localstatedir into guile repl but it was an unbound variable
<cirno9>I think it is just /var
<davexunit>cirno9: first, import the (guix config) module
<davexunit>you cannot expect to reference a symbol from a module you haven't imported
<davexunit>(use-modules (guix config))
<mark_weaver>cirno9: on GuixSD and Guix from our binary install, localstatedir is /var
***necronian_ is now known as necronian
<carif_>mark_weaver, google shows that you have/had an MIT affiliation. Are you based in Cambridge?
<mark_weaver>carif_: yes
<mark_weaver>I don't really have an official MIT affiliation, although I'm a long-time volunteer at their all-volunteer radio station.
<mark_weaver>btw, what did you find in google that suggested an MIT affiliation?
<carif_>you had records some talks that mentioned the MIT radio station. its a kind of affiliation, yes?
<cirno9>I build guix from git source but the filesystems test froze my computer
<cirno9>oh maybe the test after filesystems actually, it was the last one I saw printed
<davexunit>cirno9: I guess that means it was the containers test
<davexunit>damn it.
<davexunit>I don't know how it could possibly crash your entire system, though
<cirno9>yes containers does not have a log, it was that one
<davexunit>is this on guixsd?
<davexunit>okay they should definitely not crash
<davexunit>did you have to restart your computer?
<davexunit>could you try to run just that test file and see if it happens again?
<davexunit>make check TESTS=tests/containers.scm
<cirno9>yeah definitely the containers test!
<cirno9>I also had a fuse blow shortly after but that was unrelated..
<mark_weaver>cirno9: did you add your user to the guix-builders group? I hope not.
<cirno9>I have an empty containers.log
<civodul>davexunit: BTW, should we delay the 'guix environment --container' patch?
<cirno9>I haven't done that manually
<cirno9>uid=1000(cirno) gid=998(users) groups=998(users),990(netdev),991(audio),992(video),999(wheel)
<cirno9>and it looks like im not
<mark_weaver>okay, good
<cirno9>but i was running the test in 'guix environment guix' if that makes a difference
<davexunit>civodul: I feel like that needs more work, too.
<cirno9>I wonder if it's call-with-container that's causing the freeze, or a particular one of the tests
<davexunit>civodul: at the very least we need to bind-mount /bin/sh, and maybe other things.
<davexunit>I can't get 'make' to work inside the container.
<davexunit>and then there's the existing damage I've done to the test suite.
<davexunit>cirno9: try commenting out all of the tests in that file except for one
<davexunit>tests are in the 'test-assert' or 'test-equal' blocks
<mark_weaver>you can comment out an entire s-expression by putting #; before it.
<carif_>doing another 'guix system init' seems to download new modules. is this because new modules were built on hydra between yesterday and today? And do I call them modules or packages?
<mark_weaver>there have been changes in the last day, yes
<mark_weaver>although you would only get them if you ran "guix pull" or similar
<mark_weaver>if you changed your OS config that can also lead to new downloads
***dmbaturin_ is now known as dmbaturin
<davexunit>mark_weaver: whoa I didn't know about #;
<civodul>davexunit: yeah, we'll keep it for later then
<davexunit>sucks. I thought I'd have things working decently.
<davexunit>maybe next release I can have this + cgroups working.
<mark_weaver>davexunit: eh, you're working on non-trivial stuff. difficulties are to be expected
<davexunit>I've already encountered so many, but I was naive to think I had tackled them all.
<cirno9>I commented out every test-assert in tests/containers.scm and strangely i got one test failing - here is the log file
<civodul>davexunit: yeah, np, that's fine :-)
<civodul>davexunit: BTW, could you update tests/containers.scm to skip tests on non-capable systems, akin to b62a3eb?
<davexunit>cirno9: this is tedious, but if you're up for it could you comment out that one test, and uncomment the next and run? repeat until you find the one that crashes your system.
<civodul>davexunit: it might even be a simple (unless (file-exists? "/proc/self/ns/user") (exit 77)) before 'test-begin'
<cirno9>every single test is commented out!
<cirno9>that's why it's strange that it's saying one failed
<cirno9>the fail comes from something else
<mark_weaver>cirno9: can you paste the tests/containers.scm that has every test commented out but still fails?
<davexunit>civodul: yes, I can do that.
<mark_weaver>cirno9: I suspect that you made a mistake in the commenting.
<davexunit>civodul: is 77 a special exit status?
<mark_weaver>davexunit: 77 means "skip test"
<davexunit>so that 'make check' will consider the test file skipped?
<civodul>yes, exactly
<mark_weaver>or rather "test skipped"
<cirno9>oh you're right, I acidentally put 'nn' into the file when I was trying to save (dvorak/qwerty mixup)
<davexunit>in the future, I would like if 'make check' could show whether an individual test within a file failed, rather than simply saying the whole test file was a failure
<mark_weaver>cirno9: okay
<cirno9>test 1 was ok
<rekado_>For bioperl-minimal I would like to use package-transitive-target-inputs from (guix packages), but it seems I cannot just add the module in the list after #:modules.
<rekado_>I get this error: no code for module (guix packages)
<rekado_>Is this module not available at build time?
<mark_weaver>rekado_: no, it's not, and it's probably not a good idea to try to import all that stuff into the build side.
<mark_weaver>what are you trying to do?
<cirno9>so the test which is causing my computer to freeze up is the mnt namespace one
<rekado_>mark_weaver: I'm trying to solve this problem:
<rekado_>I want to get all runtime inputs and wrap the executables with their paths.
<rekado_>I don't want to include the native inputs.
<rekado_>I also don't want to manually do what this procedure does and list all transitive inputs.
<civodul>cirno9: could you try running "strace -f -o log make check TESTS=tests/containers.scm", and then post the 'log' file? (hoping it gets written to disk)
<civodul>cirno9: also, what's the kernel version?
<rekado_>so the easiest way would be to use that procedure and run it over all inputs of the current package, then generate the paths and use that path to wrap the executables.
<mark_weaver>rekado_: that procedure requires all of the package recipes, so basically most of guix would have to be imported into the store as inputs to this build.
<mark_weaver>the inputs to the current package are already available via %build-inputs and via the 'inputs' keyword argument to all phases.
<cirno9>uname -r says 4.0.2-gnu
<cirno9>ill do the strace now :)
<rekado_>mark_weaver: I need all the transitive inputs of all %build-inputs.
<rekado_>(do %build-inputs include native-inputs?)
<mark_weaver>rekado_: I'm sorry, these are questions for civodul
<mark_weaver>rekado_: you might look at some of the early procedures in guix/build/gnu-build-system.scm, e.g. 'set-paths'.
<mark_weaver>I see that there are both 'inputs' and 'native-inputs' keyword arguments to phases.
<davexunit>rekado_: what's the issue here? there's a 'package-transitive-inputs' procedure
<mark_weaver>I believe those include the inputs/native-inputs propagated from the direct inputs/native-inputs
<davexunit>in 'guix environment', I do something like: (delete-duplicates (map package-transitive-inputs package))
<mark_weaver>davexunit: the issue is that he wants to do these things from the build side procedures
<cirno9>sorry, the strace command did not write anything to the log file
<rekado_>mark_weaver: maybe I don't need to do it from the build side at all.
<rekado_>I could just wrap this all in a let binding.
<rekado_>thanks for the input (no pun intended)!
<mark_weaver>rekado_: do you need the normal run-time dependencies of all the inputs, or only propagated-inputs?
<rekado_>mark_weaver: I don't really know, haven't thought about this enough.
<mark_weaver>rekado_: I think this needs input from civodul, maybe best done on the ML.
<rekado_>mark_weaver: writing to the ML was my intention. That's why I'm preparing a patch.
<rekado_>I'm now collecting the names of the transitive inputs first and then on the build look them up in %build-inputs.
<mark_weaver>I wonder if transitive inputs will end up including all the way down to the bootstrap binaries
<mark_weaver>if it includes the transitive closure of build inputs, then it will indeed
<cirno9>I added some debugging prints to guix/gnu/build/linux-containers.scm
<cirno9>I was hoping to see which stage was causing the freeze
<cirno9>the file was created, but it's empty
<cirno9>(i also tried to strace make check with 2> log.txt but that was empty as well)
<mark_weaver>strace -f -o trace.out make check TESTS=tests/containers.scm
<davexunit>I wish the optional --exec command in 'guix environment' didn't have to be quoted, like the above strace snippet or when running commands via sudo or ssh, but I'm not sure how to make it work.
<mark_weaver>if you run "strace -f make check TESTS=tests/containers.scm" from a text console (not in X), there might be useful information left on the screen at the time of the crash.
<cirno9>I'm just trying guix pull because I've started getting an error note: source file ./srfi/srfi-64.scm newer than compiled /gnu/store/...-guile-2.0.11/lib/guile/2.0/ccache/srfi/srfi-64.go
<cirno9>which is stopping me reproducing the freeze
<cirno9>that didn't fix it though
<cirno9>any suggestion for what to do about that error?
<cirno9>maybe a fresh git clone would help or something
<mark_weaver>cirno9: you're building from git?
<mark_weaver>(when you get that notice)?
<mark_weaver>it looks like a harmless warning to me
<mark_weaver>in fact, guix contains srfi-64.scm, although it is also present in recent versions of guile, to support older versions that don't have it.
<mark_weaver>davexunit: btw, you might be interested to know that in GNU IceCat 31.8.0, one of the advertised, intentional changes was "Disabled hardware acceleration and WebGL".
<davexunit>mark_weaver: I saw that. not pleased.
<mark_weaver>davexunit: on, gmane.comp.gnu.gnuzilla, I asked him why, and the response was "Hardware acceleration seems to cause glitches in several platforms, and WebGL can be used for fingerprinting and other attacks."
<mark_weaver>I undid that change in the guix package
<davexunit>can it be re-enabled without recompiling?
<davexunit>oh, cool.
<mark_weaver>yes, it's actually just a couple of default settings that could be undone in about:config
<mark_weaver>see gnu/packages/patches/icecat-enable-acceleration-and-webgl.patch
<mark_weaver>still, I question the judgment that led to this decision.
<mark_weaver>maybe worth further discussion on bug-gnuzilla
<mark_weaver>well, I'd be curious to know what the "other attacks" are.
<davexunit>I'm not sooo upset now that I know it's a couple of flags that can be changed at runtime, but it still seems like an unnecessary change that makes icecat seem less capable than other browsers without any real security benefit.
<mark_weaver>it does seem that way to me too, although I confess that I don't know what "other attacks" he's referring to.
<cirno9>I managed to get strace output now (since my debug prints seem to stop the freeze happening, but the test still fails)
<cirno9>the output is too long and complex so I can't get anything from it
<davexunit>if you upload it we can grep it
<cirno9>m not sure where to upload it lisppaste and lpaste reject it, it's 2.4 MB
<mark_weaver>davexunit: maybe you could help describe how to find a relevant excerpt of his strace output.
<cirno9>I think ithis is the most relevant part
<paroneayea>hello #guix
<davexunit>cirno9: clone, setns, and pivot_root calls are worth looking for
<davexunit>and readlink
<rekado->mark_weaver: using this method I got a much shorter path than what's in the PERL5LIB variable, so it looks like it works. Will test tomorrow.
<mark_weaver>rekado-: ah, okay, good!
<cirno9>well my goal was to makea package for 'unrar',
<cirno9>This worked well with the GUIX_PACKAGE_PATH thing, I wasn't able to do the other way based on building guix itself
<cirno9>the only problem is that unrar is not very good: It only handles rar2 not rar3
<davexunit>I thought the free unrar could do rar v3 now?
<cirno9>there are two open source programs which can extract rar3 but they have a clause about anti reverse engineering in their license
<davexunit>rar really is the worst compression format.
<mark_weaver>unrar is nonfree software
<cirno9>there are two unrars, this is the free one
<mark_weaver>ah, okay
<cirno9>frustratingly i wasn't able to extract my files with it, but maybe it's useful anyway
<paroneayea>that's interesting
<mark_weaver>I'd like to see that anti-reverse-engineering clause. I'm skeptical that it's really free software, if it prohibits such a thing.
<paroneayea>oscon's network is banning
<paroneayea>I'm guessing because of me ;p
<cirno9>sure, here
<paroneayea>oh now it works.
<cirno9>point 2
<cirno9>unrar <> and p7zip are not free, due to this clause - the other unrar <> is free (GPL2) but it can only open older rar files
<cirno9>I made a package for the other unrar, you are welcome to include it if you like (even though it has limited usefulness)
<mark_weaver>cirno9: that's not a free software license.
<cirno9>what isn't?
<mark_weaver>the thing you pasted
<mark_weaver>with the prohibition against reverse engineering.
<cirno9>yeah I agree with you, that's what I'm saying
<mark_weaver>cirno9: you wrote "there are two open source programs which can extract rar3 but they have a clause about anti reverse engineering in their license"
<cirno9>that's why I didn't package this, I'm sure it's not wanted in guix
<mark_weaver>which open source program has the anti-reverse engineering clause?
<cirno9>rarlabs unrar and p7zip
<rekado-> is GPL2.
<cirno9>it's confusing because there are two programs called 'unrar'
<rekado->but actually, this unrar thing at gna contains files that are under the unrarlib-license.
<cirno9>debian has unrar-free and unrar because of this
<cirno9>rekado-: that's interesting.. maybe debian is making a mistake with unrar-free then
<rekado->src/unrarlib.c is apparently dual-licensed, unrarlib-license or GPL.
<mark_weaver>I'm not sure that rarlabs unrar is even open source, although maybe it is. it's definitely not free software, though.
<cirno9>mark_weaver: I have the soucre code for it, but yeah it's not free software
<mark_weaver>availability of the source code does not make it open source.
<cirno9>ah we have a difference in dialect
<rekado->actually, it just makes it "open source" (because this can mean anything), but it's not "free software".
<mark_weaver>"open source" has a definition, here:
<mark_weaver>but yes, it is often assumed to simply mean that the source code is available, which is part of the reason why it's a bad term to use.
<davexunit>open washing
<davexunit>people do it all the time
<davexunit>there's a lot of proprietary software out there now whose marketing materials say its "open"
<mark_weaver>grump, tests/store.scm fails on armhf
<cirno9>ill try to contribute something a bit better than a unrar :P
<mark_weaver>heh :)
<civodul>ACTION wonders if we should distribute the pub key of so people can use it as a backup
<civodul>we'd run 'guix publish' on it
<davexunit>that would be cool
<davexunit>albeit high bandwidth right now
<davexunit>and single threaded
<davexunit>and nginx frontend plus some load balancer (if a free one exists) could make it perform pretty well
<davexunit>ooh I think nginx has built-in load balancing support now, so we could run N instances of 'guix publish' and throuw nginx in front of it.
<davexunit>civodul: oh, just saw your mail...
<davexunit>ACTION pulls
<civodul>it's still no substitute to nginx, of course
<civodul>but it might be "good enough" for occasional use
<davexunit>it should still be very easy to spawn a handful of 'guix publish' processes on different ports and have nginx load balance them.
<davexunit>worth considering if we ever find that gets slammed
<mark_weaver>civodul: fyi, guix test failure on armhf:
<civodul>i'm looking at it
<davexunit>civodul: nice hacks! well, not nice that we have to have those hacks in the first place, but nice that our performance will be much better now!
<davexunit>ACTION pushed tests/container.scm fix
<mark_weaver>davexunit: thanks! do you think the 'disable-container-tests' phase of our guix-devel package can be removed or trimmed now?
<civodul>i think so
<cirno9>is there any way i could help more with the freeze?
<civodul>cirno9: if you'd like to test an installation image, that'd be great!
<civodul>i can upload one
<cirno9>im on guix sd already, would i have to overwrite my current install?
<civodul>or test in a VM
<cirno9>ah sure!
<cirno9>I can boot into my other linux install to test in a VM
<civodul>or run "guix package -i qemu" in GuixSD :-)
<cirno9>even better
<civodul>mark_weaver: dunno what to think of that bug you reported
<mark_weaver>civodul: hmm.
<mark_weaver>well, I could try again and see if it's non-deterministic
<civodul>yeah :-/
<davexunit>mark_weaver: yeah.
<civodul>could you post the output of 'make check' for that failed build to see the ordering of tests?
<civodul>it might give a clue
<mark_weaver>civodul: sure..
<mark_weaver>I have the build log and the failed build directory
<davexunit>mark_weaver: I can commit that change if you'd like.
<civodul>mark_weaver: if you have the failed directory, can you try 'make recheck'?
<civodul>what's the number of GNU make parallel jobs?
<mark_weaver>civodul: I suspect it will be 2, but how can I verify that?
<mark_weaver>(the novena has 4 cores but I've disabled 2 to prevent overheating)
<mark_weaver>(there's a new kernel that supports automatic throttling to regulate temperature, but I haven't updated to it yet)
<civodul>(guix store) defaults to (current-processor-count)
<civodul>so that may be 4
<mark_weaver>civodul: (current-processor-count) returns 2
<civodul>hmm no clue here
<mark_weaver>okay, I'll try "make recheck" on the failed directory....
<mark_weaver>what's the difference between recheck and check?
<civodul>rechecks runs only tests that failed previously
<mark_weaver>this time: PASS: tests/store.scm
<mark_weaver># FAIL: 0
<mark_weaver>okay, time to rebuild I guess :)
<civodul>could you try: while make check TESTS=tests/store.scm; do : ;done ?
<civodul>just for a few minutes
<civodul>i hope it's not going to overheat ;-)
<mark_weaver>heh :)
<davexunit>I did a variant of that loop with my container tests
<davexunit>it would exit upon test failure
<davexunit>made it less tedious to see that there were still race conditions in my tests.
<rekado->hmm, trying to package radium but it depends on so many forked third-party libraries.
<rekado->It's no fun.
<mark_weaver>civodul: six successful runs so far
<mark_weaver>still waiting for another failure
<rekado->e.g. huge visualisation library forked, couple of files added, bundled.
<civodul>sounds like a déjà vu
<civodul>rekado-, davexunit: any idea how to address ?
<davexunit>civodul: not off the top of my head.
<rekado->civodul: I'm not at all familiar with Python. When some '' don't support the ‘--always-unzip’ option, can we just make this optional?
<rekado->like #:parallel-build?
<rekado->or am I misunderstanding the problem?
<rekado->ACTION goes afk
<mark_weaver>civodul: okay, 10 consecutive successful runs. I guess it was a fluke :-(
<mark_weaver>or else it only happens in the build environment. I guess I'll find out when I rebuild.
<civodul>mark_weaver: yeah, let's do that
<civodul>not completely satisfactory, but hey
<mark_weaver>thanks for looking at it
<civodul>rekado-: dunno!
<civodul>Steap: i forgot to solicit you for ; what's your take? :-)
<civodul>we could also special-case python-pillow for now, but python-build-system doesn't even provide a way to pass flags
<Steap>civodul: oh, the compressed eggs
<Steap>I started looking at the matplot issue, but I ended up downloading 3GB of LaTeX for some reason
<Steap>and well, it was not downloading really fast :D
<mark_weaver>civodul: btw, I've noticed that the version number comparison logic in 'guix package -u' does not mix well with the version numbers used by 'guix-devel'. it thinks that the latest update was actually a downgrade.
<Steap>so about the egss
<Steap>we are currently doing "python install", right ?
<mark_weaver>I wonder if the version number should include a count of commits since the last tag, like 'git describe' does.
<Steap>Some people suggest "python easy_install -Z "
<Steap>or tweaking setup.cfg:
<civodul>mark_weaver: probably, yes
<civodul>Steap: the setup.cfg approach looks nice
<Steap>it's a matter of echo blah >> setup.cfg
<Steap>are all Python packages affected ?
<civodul>i don't know
<civodul>i'm trying on pillow for now
<civodul>how could we know?
<civodul>i guess (1) not all of them use easy_install, and (2) not all those that do use it have compression enabled
<Steap>I'm lost in all that Python crazyness
<Steap>setuptools/distutils/their forks
<Steap>the eggs
<Steap>the wheels
***cirno is now known as Guest16702
<civodul> + .sig
<civodul>any testers? :-)