<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>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. <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 ? <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>ACTION fixed two serious scalability issues in 'guix publish' \\o/ <sprang>yenda: thanks, I will take a look <civodul>and hydra is blazingly fast, as crazy as it may seem <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->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 <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>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? <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>mark_weaver: you could enable substitutes and run "guix build -S netpbm -s x86_64-linux" <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. <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>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. <francis7>yenda, librem comes with a proprietary BIOS developed by American Megatrends <francis7>AMI also developers proprietary firmware for the large OEMs <davexunit>I think they have some naive belief that will be able to work out a deal to free the source code. <mark_weaver>in their little table comparing themselves to other laptop offerings, it's interesting that they didn't include the Libreboot X200 <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. <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>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>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>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. <mark_weaver>civodul: actually, I just realized that the failure was in guix-0.8.2, not the snapshot. <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 <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. <rekado_>(what does "OS freed" in the context of hardware manufacturers even mean?) <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 <davexunit>cirno9: first, import the (guix config) module <davexunit>you cannot expect to reference a symbol from a module you haven't imported <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>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>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>could you try to run just that test file and see if it happens again? <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. <civodul>davexunit: BTW, should we delay the 'guix environment --container' patch? <cirno9>uid=1000(cirno) gid=998(users) groups=998(users),990(netdev),991(audio),992(video),999(wheel) <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>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
<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. <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? <mark_weaver>cirno9: I suspect that you made a mistake in the commenting. <davexunit>so that 'make check' will consider the test file 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 <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. <cirno9>so the test which is causing my computer to freeze up is the mnt namespace one <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. <rekado_>mark_weaver: I need all the transitive inputs of all %build-inputs. <rekado_>(do %build-inputs include native-inputs?) <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 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>any suggestion for what to do about that error? <cirno9>maybe a fresh git clone would help or something <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". <mark_weaver>davexunit: on bug-gnuzilla@gnu.org, 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>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>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 <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. <davexunit>cirno9: clone, setns, and pivot_root calls are worth looking for <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. <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 <cirno9>there are two unrars, this is the free one <cirno9>frustratingly i wasn't able to extract my files with it, but maybe it's useful anyway <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. <cirno9>I made a package for the other unrar, you are welcome to include it if you like (even though it has limited usefulness) <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>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>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>there's a lot of proprietary software out there now whose marketing materials say its "open" <cirno9>ill try to contribute something a bit better than a unrar :P <civodul>ACTION wonders if we should distribute the pub key of hydra.gnunet.org so people can use it as a backup <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. <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 hydra.gnunet.org gets slammed <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! <mark_weaver>davexunit: thanks! do you think the 'disable-container-tests' phase of our guix-devel package can be removed or trimmed now? <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! <cirno9>im on guix sd already, would i have to overwrite my current install? <cirno9>I can boot into my other linux install to test in a VM <civodul>or run "guix package -i qemu" in GuixSD :-) <civodul>mark_weaver: dunno what to think of that bug you reported <mark_weaver>well, I could try again and see if it's non-deterministic <civodul>could you post the output of 'make check' for that failed build to see the ordering of tests? <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) <mark_weaver>okay, I'll try "make recheck" on the failed directory.... <civodul>rechecks runs only tests that failed previously <civodul>could you try: while make check TESTS=tests/store.scm; do : ;done ? <civodul>i hope it's not going to overheat ;-) <davexunit>I did a variant of that loop with my container tests <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->e.g. huge visualisation library forked, couple of files added, bundled. <rekado->civodul: I'm not at all familiar with Python. When some 'setup.py' don't support the ‘--always-unzip’ option, can we just make this optional? <rekado->or am I misunderstanding the problem? <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>not completely satisfactory, but hey <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>we are currently doing "python setup.py 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 setup.py easy_install -Z " <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 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 ***cirno is now known as Guest16702