IRC channel logs
2016-12-18.log
back to list of logs
<geemili>I'm trying to use ConTeXt from the texlive pacakge, but the `mtxrun` file has a shebang that isn't patched <geemili>First line of `mtxrun`: `#!/usr/bin/env texlua` <geemili>Just read up on why you would want to use `#!/usr/bin/env`. It looks like it is just to allow flexibility in which version of the program runs the script. <geemili>Does `patch-source-shebangs` already handle `#!/usr/bin/env`, or do I need to manually handle it? <geemili>I wrote a hacky little script that fixes texlua <Apteryx>No space left to even create an empty file, but "df -h" says I have 10 GiB left? <jmd>Apteryx: No i-nodes left ? <Apteryx>jmd: How can I check if this is really the issue? <jmd>Try deleting a few other unwanted files first. <jmd>and perhaps "tune2fs -l /dev/sda1" might give some enlightenment. <jmd>In particular, look at "Free inodes" and "Free blocks" <Apteryx>When I delete a file I can create (touch) a new one. But no more. <Apteryx>So you seems to be right that it's an inode issue (although the tune2fs command reports I still have a few inodes left) <jmd>That system hasn't been checked for a while, so it might be worth running fsck on it. <Apteryx>Can this happen because of the Guix store? I haven't run the garbage collector in a while, affraid of bug #24703. <Apteryx>Ah... Seems I have to boot from another drive just to run fsck. That's inconvenient. <Apteryx>I'll get some sleep, thanks for giving me a few ideas :) <jmd>You cannot fsck a mounted system yes. <jmd>I would be grateful if you could post a message to guix-devel about this, including that tune2fs output. Because I think that the default mke2fs options are not suitable for what we put in /gnu/store <rekado>most of the importer test failures have in common that they actually perform imports. <rekado>they seem to miss something in the mock declaration of url-fetch. <rekado>gem.scm also imports the actual “foo” package instead of using the mocked up package data. <rekado>probably caused by 63773200d7ac68fcaee6efd9ffe8ea7aa3fafa38 <rekado>where json-fetch switches from url-fetch to http-fetch <civodul>rekado: i see you already fixed the pypi etc. tests no? <rekado>there’s one pypi test that is skipped on my laptop but that fails on my workstation. <rekado>this only leaves the hackage test, if I’m not mistaken <rekado>(don’t know why the test is still skipped on my laptop, but it works fine on the workstation) <rekado>looking at hackage.scm now, but this looks harder <rekado>oh? For all of them I see this: + (wrong-number-of-args <rekado>+ "Wrong number of arguments to ~A" <rekado>+ (#<procedure ___push (delta new-category lvalue tok)>) <civodul>i've seen people report it, but it seems that's due to a specific version of (system base lalr) no? <rekado>I these failures on the laptop and on the workstation. <rekado>I’m running this in “guix environment --pure guix” <civodul>oh i had not emailed the Translation Project for updates <amz3>eventually I iinstalled guix ontop of ubuntu 16.10 <amz3>guix pull at last worked <amz3>and guile-next is up to date :) <amz3>I had issue installing: /gnu/store/sq03gq3lhpwgbiy9k5klnqd2q8z7iwxp-module-import <amz3>it was saying that the binary substitute did not have the good checksum <amz3>and recommend to use --fallback but there is no --fallback option in guix pull <civodul>rekado: all the substitutes that the makefile targets check for are now on hydra.gnu.org <civodul>might take a bit of time before the mirror is updated (it cached 404s for 1 hour) <civodul>rekado: could you push the test suite fixes that you have? <rekado>here’s another “make distcheck” error: '/gnu/store/705vk6pqgfralqnik74fxrw6y416l5c2-bash-4.4.0-include' refers to bootstrap inputs: ("/gnu/store/705vk6pqgfralqnik74fxrw6y416l5c2-bash-4.4.0-include" "/gnu/store/bm0gfw4jkw8gd0vpnnzrb6z0xncrbx3p-readline-7.0" "/gnu/store/dymkjkjsmch06vlhrirm1dm8absyfwq0-bootstrap-binaries-0" "/gnu/store/hdrli1v7q3107w842s7di8rid82xlfvl-ncurses-6.0" "/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0") <civodul>apologies for all the bumps on the road! <civodul>i have a fixlet for tests/cpan.scm, which is broken here <rekado>I thought about removing the last two tests, because they don’t seem relevant any more. <jmd>ACTION suspects that guix system disk-image ignores ./pre-inst-env or parts thereof. <civodul>rekado: dunno, they are easily fixed <jmd>Does anyone know how to create a disk-image which includes an extra-package? <jmd>Alternatively, does anyone know how to add an extra package to the installation-os such that it'll be included when I run guix system disk-image ? <amz3>jmd: You can customize gnu/system/install.scm <jmd>amz3: Yeah, tried that. <jmd>the customizations are ignored. <amz3>what command did you use to generate the image? <jmd>./pre-inst-env guix system disk-image disk-image.scm <amz3>disk-image.scm is the custom install.scm? <jmd>No. It contains "installation-os" and the necessary "use-modules". <rekado>civodul: fixed the cpan failures. <amz3>jmd: paste that file please <rekado>looks like “make check -j15” leads to a failure in tests/lint.scm while a sequential “make check” passes. <amz3>jmd: maybe try to pass directly the install.scm as argument <amz3>jmd: sorry, I'm not the best person to help <jmd>Seems like an odd thing to do, but I will try ... <jmd>amz3: That results in exactly the same derivation. <rekado>ha, make check TESTS="tests/hackage.scm" passes after removing /home/rekado/.guix-profile/share/guile/site/2.0 and /run/current-system/profile/share/guile/site/2.0 from my GUILE_LOAD_PATH <jmd>rekado: You're preparing a release? <rekado>I started a local branch “version-0.12.0” <rekado>can I push this when I’m unsure what to add to the NEWS file? <rekado>then you could add what you think is missing <rekado>ACTION notes that the new rust stuff isn’t documented in the manual <jmd>I suggest that in future we make a policy that NEWS should be updated upon each commit as appropriate rather than just before a release. <rekado>this would certainly make it easier to release <rekado>I only have about 2000 commits to wade through… <jmd>You could always do git diff v0.11.0 HEAD <rekado>I’m doing git shortlog v0.11.0..HEAD <rekado>then remove all “Update to” messages, then look for noteworthy stuff <jmd>I don't envy that task. <rekado>there have been *a lot* of changes, and many seem like old news… <janneke>it seems my paredit doesn't know about #; <civodul>rekado: sure, push what you want for NEWS <civodul>or we can agree on ranges to look at if you want? <civodul>in the past i tried to keep only high-level stuff <civodul>and the more we wait for the new release, the higher-level the filtering ;-) <rekado>there’s so much good stuff there! <rekado>my apologies to the authors of all the cool stuff we won’t mention explicitly in NEWS <civodul>sometimes there are small changes, but mentioning them allows us to remind people of the existence of a tool/feature <civodul>rekado: BTW make sure to bump the version number in configure.ac <rekado>commit messages that don’t follow our common format *really* stick out in this overview, and they make it harder to figure out what actually happened. <rekado>luckily most committers follow the guidelines <rekado>civodul: are we going to get more translation changes? <civodul>rekado: i was about to send the tarball to the TP, so probably not <civodul>i'll send it anyway, we'll have them later <rekado>civodul: could you please go through your commits and pick items for NEWS? I’ll take care of the rest. <rekado>should we also list *removed* packages? <rekado>it’s a little hard to identify removed packages because the commit messages aren’t very clear. <rekado>some say “X superseded by Y” others “gnu: Remove …” <rekado>I remember some lisp* implementations <rekado>and I see “gnu: Remove openjpeg-2.0” right here. <civodul>but that's probably the removal of an old version no? <civodul>i think it's ok if you don't bother ;-) <rekado>FWIW the hackage tests still fail on my “release-making” workstation. <rekado>civodul: I pushed branch version-0.12.0 with a first draft of NEWS. <rekado>gotta take a break for a couple of minutes <johnzorn>Is it possible to use the guix pkg manager in another distro similar to the way you can install nix pkg manager at the user level. If so are there instructions somewhere? <civodul>rekado: i'll let you do filtering/merging of these, but let me know if there's anything amiss! <rekado>hmm, I’m in “guix environment guix”, have run ./configure, yet some check in “make distcheck” says: <rekado>“checking for BZ2_bzWriteOpen in -lbz2... no” <rekado>in config.log it’s marked as successful. <rekado>but there’s a configure run started by “make distcheck” that fails <civodul>oh, but does _build/xyz/config.log show something useful? <rekado>looks like it uses /bin/ld for some reason <rekado>hmm, same error with “guix environment --pure guix --ad-hoc perl git” <rekado>/bin/ld: /gnu/store/g3g9b9b6rs741ifdfvc65x6dy5vdrr9f-profile/lib/crt1.o: unrecognized relocation (0x29) in section `.text' <civodul>oh you cannot do that, because some things need to talk to the daemon <rekado>can’t I just --expose=/var and --expose=/gnu? <civodul>i suspect 'configure' prefers "/bin/ld" and uses that as its first choice <rekado>I’ll add some more info to release.org (e.g. the exact container command used) <rekado>there’s a problem generating guix-daemon.service: <rekado>/bin/sh: line 1: ../../../../etc/guix-daemon.service.in: No such file or directory <rekado>looks like it goes one level too far up <pmikkelsen>Hello guix, when I run ghc or ghci, it fails with an error about libncursesw.so.6 <roptat>I'm trying to use the #:log-file option of make-forkexec-constructor, but when I reconfigure my system I get: <roptat>ERROR: Unrecognized keyword: #:log-file <roptat>nevermind it works after a reboot, I was probably running an older version of shepherd <civodul>roptat: right, it's only in 0.3.2 i think <civodul>rekado: i've pushed 4 commits to master, including the .service fix; feel free to take them to the 0.12 branch <civodul>i'm going to be mostly afk for a while now <civodul>if you feel like we should delay until Tuesday, that's fine with me ofc <civodul>looks like we've ironed out most of the annoying issues already :-) <rekado>maybe it’s best to delay until Tuesday. <rekado>I’m a little unsure about building the binaries for arm and mips; as I don’t have SSH access to hydra we’d have to coordinate this somehow. <Apteryx>jmd: OK, I'll make a couple tests (1. simply reboot to see if the inodes issues resolves 2. run fsck from a live usb) and then send a post about it to guix-devel. <roptat_>I'm trying to use haunt on guisd, but the example here (https://haunt.dthompson.us/) does not build. I get ERROR: no code for module (system reader). Since the news website is run by haunt, I guess some of you may know how to use it properly? <rekado>you may need to install guile into your profile or set GUILE_LOAD_PATH <rekado>the haunt package propagates the guile-reader package, so this error tells you that Guile just doesn’t know how to find it. <rekado>civodul: the “make doc/guix.dvi” target fails because @inlinefmtifelse is unknown. <Apteryx>jmd: I just sent a report of my inodes problem to guix-devel. <lfam>Apteryx: That bug is still present <Apteryx>lfam: OK. I'm running out of inodes so I guess I don't really have a choice... <lfam>It should be fixed in the next core-updates cycle as a consequence of b810a85019ab3c4ee1f889d0751b8eb06157dadc and 8033772363b287ca529461e575ceb4a69d7af942 <lfam>Apteryx: Yeah, sorry about that :/ <Apteryx>It's alright, I knew it was beta when I signed up :p. I'll try it and report if anything goes wrong. <Apteryx>You mean the fontconfig issue specifically? <Apteryx>(that should be fixed in the next core-updates...) <lfam>Well, that bug in general, which fontconfig suffers from <lfam>We'll update the GCC used to build everything to GCC 5, which has a patch to avoid this issue <Apteryx>I see. I guess this is being delayed because the whole world will need to be rebuilt? What's the timeframe to do this? In time for 0.12.0? <lfam>It will require everything to be rebuilt, and we want to release 0.12.0 imminently. <lfam>Considering how serious this bug is, maybe we'll try to make this change sooner than 0.13.0, which is a few months off. I don't know. <lfam>We should identify packages that we know are affected and decide if we can update them to use GCC 5 sooner, on a staging branch <Apteryx>Yes, this sounds like it would be useful in the meantime. <lfam>Apteryx: Some of the affected packages will require a huge number of rebuilds themselves. It depends on the capacity of our build infrastructure. I think we can probably do more building. There are times when the farm is underutilized. <lfam>But, there are other limitations, such as disk space <Apteryx>By the way, it'll be the first time I attempt to run 'guix gc' after I've started using Guix directly from its git checkout. Do I need to run "guix gc" from a "guix environment guix" to make sure it doesn't garbage collect itself? <Apteryx>I've got both my root and user guix pointing to the git checkout. <lfam>If the Guix you want to preserve is in a user profile, then you should be good. You can inspect /var/guix/gcroots to see exactly what is protected from the garbage collector <Apteryx>lfam: I understand. I'm using lots of space just with my small selection of installed packages, the whole collection must use quite a large amount of storage! <lfam>The Guix you built from Git is not in /gnu/store, btw. It's wherever you built it <lfam>So, it shouldn't be affected by the garbage collector at all, IIUC <Apteryx>OK. This gives me some confidence, thanks. <lfam>Apteryx: Can you try running the command with `strace -f` to see where it's looking? Or checking the udiskctl documentation to see if it mentions this issue <Apteryx>lfam: I tried looking at the strace output but cannot find anything obvious. <lfam>Apteryx: Did you try looking for the string 'cryptsetup'? <lfam>Does it try opening cryptsetup anywhere? <Apteryx>The only cryptsetup occurence is in the error thrown, even when looking at the strace. <Apteryx>I'll paste the strace somewhere for you to see, it's quite cryptic. <taylan>all of leptonica 1.73's tests fail with tons of errors saying stream couldn't be opened, (later) file not found, etc. it seems the programs in the test suite have difficulty writing to the filesystem. some directories and files do get successfully created by the test suite programs though. what may be causing most of them to fail in creating / writing to files in the build environment? <taylan>I built leptonica and ran its tests in a guix environment container and they didn't have the problem there <lfam>Apteryx: What package provides udiskctl? <taylan>on a related question, how can I get a faithful approximation of the build environment created by the daemon to build packages? <Apteryx>Sorry it should be spelled udisksctl (with the S after udisk) <Apteryx>I belive the package is named the same. <lfam>I guess we could try patching the strings in src/udisksstate.c and src/udiskslinuxblock.c <lfam>Taylan: Can you share your 1.7.3 update patch? <taylan>(hmm, removing the changes to the "which gnuplot" calls was also wrong I suppose, as 'which' isn't in the build environment? changing them to the literal output of 'which gnuplot' seemed wrong too though; I guess best to change them to "true") <lfam>You can add which to the build environment <lfam>I'm trying to build it now <civodul>rekado: you need to copy texinfo.tex from a recent Gnulib or such <taylan>I just patched it to "true" so we can avoid the dependency on 'which'. gnuplot is added as a native input after all; we already know it's there. <civodul>roptat_: hopefully if you install Haunt from Guix, you won't have this problem <taylan>civodul: quick Q: is there a way to get a faithful replica of the build environment the daemon would create to build a package, for messing around in it interactively? sometimes I have an issue that happens in that environment but not in e.g. 'guix environment -C --pure foo' <civodul>roptat_: oh indeed, that's a bug: 'haunt' should close over guile-reader <civodul>taylan: 'guix environment -C' is almost the same, modulo /bin/sh and a couple of minor things <civodul>we could add a switch to not add /bin/sh <civodul>that said, you can also do 'guix environment -C' and then 'rm /bin/sh' there <taylan>civodul: leptonica's tests fail to create/write to most files <taylan>many directories and very few files seem to be successfully created, which I can see in the directory left from build -K, but almost all write operations fail so all tests fail in the end <lfam>taylan: What files does it fail to write? <lfam>Maybe they are in some directories that don't exist <taylan>hm, maybe this is related to out-of-tree building or something else I failed to replicate in my call to make check in the guix container <taylan>lfam: it seems the directories exist. I think it successfully creates all directories it needs, and a handful of files in them <taylan>I forgot, does the gnu build system build out-of-tree by default? or do something else that may cause the test suite to fail *reading* files referenced via relative paths? <civodul>in "guix container -C" file creation always succeeds i think, because you're root <civodul>i would go and strace one of these tests to see where it's trying to write <civodul>might just be $HOME, which points to a non-existent dir <civodul>rekado: so let's finish that on Tuesday <civodul>we'll be more relaxed and more confident <civodul>thanks a lot for everything you've done today <civodul>rekado: i did send your OpenPGP key for the FTP uploads right? i think back in January <civodul>you'll have to change the key in guix.texi