IRC channel logs

2015-12-11.log

back to list of logs

<fps>ty
<davexunit>yw
<davexunit>holiday party time
<fps>and yeah, i see another error in my reasoning
<fps>while the bit representation might not have changed [having an interpreter as input is a good example instead of a shared library object file]
<fps>the resulting _behaviour_ is still different
<fps>ruling that out is almost impossible
<fps>good night..
<apa512>i'm getting some errors in the check phase in guix system reconfigure: https://gist.github.com/apa512/3cd4696032b571d4cbd6
<apa512>anyone know what could be wrong?
<apa512>i can't find test-suite.log anywhere
<amz3>L15: the recipe for target 'test-suite.log' failed
<bavier>apa512: can you still see the output?
<bavier>otherwise, you'll want to pass --keep-failed to `guix system reconfigure`
<bavier>apa512: also, have you considered upgrading to guix-0.9.0 ;)
<apa512>erik@guix ~$ guix --version guix (GNU Guix) 0.9.0 Copyright (C) 2015 the Guix authors License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
<apa512>i have no idea where 0.8.3 is coming from
<apa512>this is the latest guix after guix pull
<apa512>FAIL: tests/build-utils.scm
<apa512>this is where the failure is happening. otherwise i don't really know what to check for.
<bavier>apa512: I assume you're running `guix system reconfigure` as root. does root also have access to the latest guix?
<bavier>i.e. did you run `guix pull` as root?
<apa512>i'm running reconfigure with sudo but have probably only run pull as a normal user. i will try sudo guix pull now.
<civodul>Hello Guix!
<roelj>Hello civodul
<roelj>I'm packaging a library that is licenced "BSD". How can I recognize which "BSD" license it is?
<civodul>roelj: when in doubt, i look at the URLs in (guix licenses)
<civodul>the directory.fsf.org URLs have the full text, so it's quite easy to see which one it is
<roelj>civodul: Ah ok. Thanks
<civodul>roelj: BTW, did you hear from the sysadmins re the JS thing?
<roelj>civodul: Nope
<roelj>civodul: So I figured.. would subdomains be OK? It turns out that you need to add a HTTP header as well for subdomains..
<roelj>civodul: So I'm stuck on that.
<roelj>It seems that webmasters at gnu is a volunteering effort.
<roelj>I'm packaging something that roughly needs the following to build: git clone ...; git submodules init --update; mkdir build/; cmake ..; make && make install
<roelj>The only thing I don't know how to package is the 'git submodules init --update' part. Is there an example available?
<roelj>I think I need something like (arguments #:phases ...)
<efraim>maybe something like (lambda _ (system* "git submodules init --update")) inside your new phase?
<roelj>efraim: Thanks, I'm going to try that.
<efraim>but then again it will want internet access, and I don't think that's possible from within the build environment
<roelj>Oh. That is indeed going to be a problem.
<efraim>check out mpv, it has an item with a source from the internet, maybe something like that can work in place of downloading at build time
<roelj>The way "waf" is handled?
<efraim>yeah, something like that might work
<roelj>Yes, possibly. Can I somehow copy the output of the extraction of the tarball in a subdirectory?
<roelj>So, it downloads waf-version.tar.gz, extracts it, builds it. Can that resulting directory be copied to mpv/some/dir/?
<efraim>it should be possible, not something I've tried before
<roelj>I'll probably have to read the docs about this :)
<roelj>Ok, thanks a lot for your help
<efraim>np :)
<roelj>In a couple of hours I should have some more time to experiment with the build process.
<roelj>So I'll report back on how it worked out.
<civodul>ACTION back from coffee
<civodul>roelj: re gnu.org yeah, dunno
<civodul>it seems mostly volunteer, and mostly unresponsive
<civodul>davexunit could tell you more
<civodul>is there anything we can do to fix this issue if the sysadmins don't help?
<roelj>civodul: Other than moving away from the GNU web server? Maybe we can host a javascript file doing the fetching on hydra.gnu.org, and load it (just like many websites load jquery from Google's server(s)).
<roelj>But I should check whether that works.
<civodul>yeah, let me know if you find such a solution
<roelj>Absolutely :)
<civodul>i'd like to avoid leaving gnu.org, but we're clearly seeing the effects of being dependent on this archaic and frozen infrastructure
<roelj>Yes, I'd also like to stay on gnu.org. Maybe I could 'volunteer' to fix the archaic infrastructure at some point.. :)
<civodul>maybe!
<civodul>have a discussion with davexunit to get some background info, if you like
<roelj>Thanks for the pointer. Can I PM him?
<civodul>sure, but he's probably asleep right now
<rekado>roelj: take a look at the inputs and phases of icedtea6. There we have an origin expression for a tarball that would otherwise be downloaded from the internet.
<fps>re this issue of multiple users running emacs' guix-repl:
<roelj>rekado: Thanks, there directories are created indeed.
<fps>even if the reasons described in the source code [!] are sound
<fps>the error message the user gets is not informative at all
<fps>without knowledge of the system internals
<fps>Starting Guix REPL ... [2 times]
<fps>error in process sentinel: sleep-for: Text is read-only
<fps>error in process sentinel: Text is read-only
<fps>geiser-repl--wait-for-prompt: No prompt found!
<fps>expect the question i asked to pop up more often in the future :)
<fps>brb getting breakfast..
<kmicu>ACTION thinks that fps has the biggest ‘IRC lines’/signal ratio ever. All IRC bouncers with a line limited backlog are crying right now ( ͡~ ͜ʖ ͡°)
<Digit>ACTION notes it hasnt gotten so bad to warrant casting a finger-cancer curse on fps' enter key yet, as gets done to the more rabid flooders. ;]
<fps>:)
<fps>'cmon bro, come at me ;)
<fps>also you might have noticed that i do adapt my style to the noise floor on the channel usually
<fps>being on irc
<fps>for 25+ years
<fps>does that
<fps>to you
<fps>:)
<alezost>fps: apparently running Guix commands in several Emacs instances at the same time is not a common practice, as you are the first who asked about it, but I agree that the error message is not useful at all. I'll look at improving the situation, thanks!
<fps>alezost: cool, thanks :)
<fps>alezost: quick question though: couldn't the situation be avoided completely by either a] having a port selection scheme that avoids conflicts or b] use a unix-socket instead of a network port?
<alezost>fps: thanks for the ideas, I'll think about it
<fps>alezost: no problem. thanks for being awesome..
<rekado>using a user-owned socket file (if possible) actually sounds like a good idea.
<alezost>rekado: fps: I don't really know if it's possible: it's about calling "guile --listen=XXX"
<alezost>rekado: btw, did you see civodul's and mine answers to your "highlighting lambda* / indentind modify-phases" problem?
<alezost>rekado: anyway: lambda* is highlighted by Geiser 0.8; modify-phases is indented/highlighted by `guix-devel-mode'
<alezost>you probably use an older Geiser and some old version of guix which don't have `guix-devel-mode'
<fps>rekado: alezost: hmm, so guile itself would need a unix socket option?
<fps>yay
<fps>--listen[=p]
<fps>While this program runs, listen on a local port or a path for REPL clients. If p starts with a number, it is assumed to be a local port on which to listen. If it starts with a forward slash, it is assumed to be a path to a UNIX domain socket on which to listen.
<fps>fps@raksha ~/guix$ guile --listen=/tmp/foo
<fps>that doesn't complain
<fps>fps@raksha ~$ ls /tmp/foo -l
<fps>srwxrwxrwx 1 fps users 0 Dec 11 12:57 /tmp/foo
<fps>the -h output is just out of sync with the manual..
<fps>fps@raksha ~$ socat STDIN UNIX-CONNECT:/tmp/foo
<fps>GNU Guile 2.0.11
<fps>meh, people quit so nonchalantly :)
<fps>sneek: later ask alezost: guile --listen=/tmp/foo -> socat STDIN UNIX-CONNECT:/tmp/foo -> awesomeness
<sneek>Okay.
<fps>sneek: botsnack
<sneek>:)
<fps>git checkout version-0.9.0 should give me the package definitions for 0.9.0, right? and if i ./pre-inst-env guix build all those i should have 0.9.0 packages in store, right?
<fps>oh, and we noticed another thing yesterday: the dhcp service doesn't seem to send the hostname along..
<fps>[21:43] (Channel) Rakete: send host-name = gethostname();
<rekado>sneek: later tell alezost Thank you for answering the question. "guix-devel-mode" doesn't seem to work in my Emacs here at work, but it's probably my own fault.
<sneek>Will do.
<rekado>sneek: here, have a botsnack.
<sneek>:)
<fps>i have screwed up my config and i can't see how..
<fps>config: https://pastee.org/6q4rc
<fps>error: https://pastee.org/4u5kc
<roelj>Can I somehow refer to the build directory root of the package I'm building in the build process?
<rekado>roelj: what are you trying to do?
<rekado>maybe it would be enough to use "(getcwd)" to get the current directory.
<rekado>this would be run at build-time, so it should return the $TMPDIR/nix-build-... directory.
<roelj>rekado: That should probably work indeed. I hadn't thought of it myself, thanks!
<roelj>I'm trying to get LDC (D compiler and standard library) working.
<fps>uuh, licenses exports "openssl"? :)
<fps>indeed.. hmm
<rekado>because there's an openssl license.
<fps>rekado: yeah, looks like it.. :)
<rekado>It's best to import licenses with the "license:" prefix.
<fps>i get about a million warnings on make with current master
<fps>many duplicates though.. i suppose it's no problem then
<rekado>what kind of warnings?
<fps>WARNING: (gnu packages linux): `openssl' imported from both (gnu packages tls) and (guix licenses)
<fps>and yeah, it's always (gnu packages linux) it seems
<fps>how does guile resolve the conflict? [since it's just a warning]
<civodul>wip-refactor-emacs-ui, woohoo!
<rekado>fps: I'm also getting this error.
<fps>rekado: the one i pasted?
<fps>rekado: or do you mean the warnings?
<rekado>I find this odd because 7534370435e40b11b0b254753d63d2c27cc9a9a5 adds a line to hide the openssl license from the imported license module.
<rekado>sneek: later tell davexunit I'd be happy if you could take a look at these Ruby patches and nod approvingly: http://lists.gnu.org/archive/html/guix-devel/2015-11/msg00673.html
<sneek>Okay.
<davexunit>rekado: okay
<sneek>davexunit, you have 1 message.
<sneek>davexunit, rekado says: I'd be happy if you could take a look at these Ruby patches and nod approvingly: http://lists.gnu.org/archive/html/guix-devel/2015-11/msg00673.html
<civodul>twice, to make sure :-)
<davexunit>rekado: if you don't mind, I'll tell you some minor nits here and then you can fix and apply. :)
<davexunit>for ruby-json-pure, fix the style on the 'call-with-input-file' call
<davexunit>the line break should go *after* the first argument, but it looks like you can fit the entire expression on a single line
<rekado>I have to go now but I'll review the log later. Thanks in advance!
<davexunit>rekado: okay!
<davexunit>rekado: add a comment about why you run the tests the way you do in ruby-netrc
<davexunit>rekado: finally, please explain the binary wrapping going on in ruby-redcloth.
<davexunit>OK to push with these changes!
<davexunit>that's a ton of gems. thanks!
<davexunit>and sorry for the long delay.
<fps>ok, the errors weren't in my config. it was just that i had borked my git clone somehow :)
<fps>if i give guix-daemon a bad argument in my config the system will still boot, right? just the daemon will fail to start?
<davexunit>yeah
<fps>good, ty
<fps>lets reboot and hope for the best :)
<fps>yep, daemon didn't come back up.. off to work
<fps>laters
<noname>hi!
<noname>I am trying to install GuixSD for the third time
<noname>Booting the system rendered dmd-errors about file-system mounts that failed with "No such file or directory"
<noname>Because of depends dmd refuses to boot the system.
<noname>Even though / and /home was mounted fine
<mark_weaver>noname: can you paste your OS config somewhere? (not pastebin.com please, since it blocks tor users)
<noname>I tried booting from the usb-key and run guix system reconfigure /different-config-without-the-failed-mounts.scm /mnt
<noname>but it failed
<noname>I suppose you can ONLY run that command when the system is booted completely
<noname>config comming up...
<noname> https://pastee.org/44cd5
<noname>ls of /mnt on the root-system contains no directories
<noname>log from dmd comming up
<noname> https://pastee.org/cxuwb
<noname>I just tried running guix system init /config-without-mounts-of-trisquel-and-storage.scm /mnt and it took 45 min to sync the substitutes and 34 min to download them (again) despite every one of them already being in the store from the previous installation to the same partition.
<noname>Now booting to see if it made a difference. (I installed twice to the same partition)
<mark_weaver>noname: you can only use 'guix system reconfigure' from within an already-installed GuixSD system.
<mark_weaver>noname: iiuc, if you reboot the USB installer, then you are basically starting from scratch again and cannot benefit from the things you downloaded on the previous attempt.
<mark_weaver>once you get a working system that you can boot from, then mistakes in the future do not cause such problems, because you can always boot into an earlier generation of your system that works. but mistakes during the initial install are expensive to recover from I'm afraid.
<noname>I know. Could we change guix system init to make it possible to tell it to check the contents of /gnu/store and the db on the target BEFORE dancing with hydra etc
<noname>It booted just fine!
<noname>Horay!
<mark_weaver>that's good!
<noname>I have 1265 dead paths. Is that a lot?
<mark_weaver>I don't know what a "dead path" is
<noname>387 live ones
<noname>guix gc --list-dead
<mark_weaver>I don't know, I never tried doing that right after an install
<noname>Is it possible that I found a bug in the guix system init: it does not create the dirs that dmd needs to mount the filesystems at boot?
<mark_weaver>noname: there's an optional 'create-mount-point?' field in 'file-system' specifications, which defaults to #f. I guess maybe you need it to be #t if you didn't arrange to create those mount points yourself on the root partition.
<mark_weaver>see section 7.2.3 (File Systems) in the Guix manual
<noname>ok, thanks!
<noname>I just tried to run guix publish as root on my other machine with guix on top of trisquel. Got this output:
<noname>publishing /gnu/store on 0.0.0.0, port 8080
<noname>Any ideas?
<roelj>Doesn't that mean that you can now reach your publishing machine on any of the external network interfaces on port 8080?
<mark_weaver>+1
<roelj>So if your ip address is 192.168.1.12 then you can reach it on another machine at 192.168.1.12:8080
<noname>cool!
<noname>This means that if I would ever need to install guix again I can fetch the substitutes from my other machine and avoid hydra as much as possible.
<noname>Mark, roelj would you like to share your config.scm? I booted mine and now I'm curious as to what others are running
<mark_weaver>my config is kind of messy right now from so much experimentation over the years, and anyway I have to go afk. happy hacking!
<mark_weaver>noname: one suggestion: always keep a backup of a known-working version of your OS config. better yet, keep it in a version control system.
<roelj>noname: Mine is an adapted version of the graphical example (using xfce4). I have to admit I don't run GuixSD on my main laptop (yet)..
<noname>me neither. testing it on my server atm
<noname>thanks for your time.
<noname>I have a new problem: when running guix package -i it proposes NO substitutes at all from hydra.
<mark_weaver>noname: does /etc/guix/acl contain a key?
<noname>I ran --authorize but did not check. one moment
<mark_weaver>if not, you need to run this as root to authorize substitutes from hydra: guix archive --authorize < /run/current-system/share/guix/hydra.gnu.org.pub
<mark_weaver>I have to go afk again. good luck!
<noname>ok!
<noname>yes contains
<pirfle>Hello, I have a Raspberry Pi 2 (I know, it's not the most freedom respecting machine, I won't buy it again, but it's cheap). Is guix ready to use on top of my raspbian system for armv7?
<noname> /run/current-system/share/ does not exist on my guixsd
<davexunit>pirfle: yes, we have an armv7 port. note that GuixSD, the distro, is not yet supported.
<pirfle>davexunit: Yes, thanks. I want to keep my raspbian system.
<davexunit>pirfle: then you should be good. I have guix installed on my Novena, which is also an armv7 system.
<pirfle>davexunit: So I will start installing guix. But I have a basic question: the binary installation just installs a profile for root. Can I just copy it to my home directory and run 'chown'?
<davexunit>pirfle: no.
<davexunit>just make your own.
<davexunit>root's profile only has the guix package in it, to prevent it from being gc'd
<pirfle>davexunit: How? (I'm a beginner.)
<davexunit>'guix package'
<davexunit>for example, to install emacs:
<davexunit>'guix package -i emacs'
<davexunit>that will add emacs to your user's profile
<pirfle>But don't I need a basic, predefined profile, which contains guix itself for example?
<davexunit>no
<pirfle>And the guix executable?
<davexunit>the idea with the binary install is that you'd symlink /root/.guix-profile/bin/guix to /usr/local/bin/guix or something
<davexunit>pretty sure the manual mentions this in the binary installation instructions
<noname>make sure to set the LOCPATH the root env. (not yet mentioned in the manual)
<noname>in guixsd with non-working substitutes and a populated /etc/guix/acl - how do I best go about debugging/solving the issue?
<noname>how do I know if the deamon runs without --no-substitutes?
<noname>*by default
<davexunit>noname: ps -ef | grep guix-daemon
<davexunit>see what options are listed
<noname>thanks!
<noname>it runs with [...]--substitute-urls http://hydra.gnu.org
<noname>hm
<noname>reboot?
<noname>helped!
<noname>horay!
<davexunit>awesome :)
<noname>is there a way to restart the deamon (to make it read the updated acl)?
<noname>is anybody (besides hydra) running guix publish publicly?
<davexunit>noname: hydra doesn't actually use 'guix publish'
<davexunit>I think fps had a publicly available 'guix publish' instance for a bit, not sure if it's still up.
<davexunit>I would like to run one at some point since I wrote the darn thing
<pirfle>davexunit: My root directory is not readable for normal users - should I change this (I think there's no need for it)?
<davexunit>pirfle: / or /root?
<davexunit>I'm guessing /root otherwise you'd have lots of problems
<noname>any firewall packaged yet?
<noname>did not find ufw or anything matching "firewall" in the package list
<pirfle>davexunit: /root of course. Could I install the guix profile for root in a seperate directory?
<davexunit>pirfle: please read the manual
<davexunit> http://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation
<davexunit>I was incorrect about the /root/.guix-profile thing, but the manual has all of the accurate information
<davexunit>it's always a good idea to inspect the manual first
<noname>is anybody working on packaging https://github.com/Bitmessage/PyBitmessage/ ?
<davexunit>someone mentioned it recently
<davexunit>was it you? :)
<noname>seems it needs python2-qt4 which does not seem to be in yet
<noname>no
<davexunit>in general I say: just go for it!
<noname>this is my first time on this channel
<davexunit>ah okay
***noname is now known as swedebugia
<mark_weaver>anonymiss also talked about wanting bitmessage
<swedebugia>ok
<davexunit>ah that's the name!
<davexunit>thanks
<swedebugia>from sweden with <3
<swedebugia>:D
<mark_weaver>:)
<swedebugia>I started to package slurm yesterday as it only depends on ncurses which is in already
<swedebugia>do we have a module for network packages yet?
<swedebugia>slurm is a netw monitor
<mark_weaver>swedebugia: sounds like a good package to start with.
<davexunit>swedebugia: maybe gnu/packages/admin.scm would be a good fit
<mark_weaver>or networking.scm
<anonymiss>noname: my priority is getting gnunet-gtk ready (soon), then i will do pybitmessage, although i tend to use the dev fork/branch.
<davexunit>mark_weaver: oh yeah :)
<mark_weaver>:)
<anonymiss>but if someone does pybitmessage, it would be cool. I'm just planning to do it because it's not there.
<anonymiss>possibly the only reason why i haven't moved the tor / im laptop from hardened gentoo deblobbed to guixsd
<swedebugia>"although i tend to use the dev fork/branch." did not underst. could you ellaborate?
<swedebugia>talking about packaging. how do you determine if the program needs the dependency at buildtime and or runtime?
<swedebugia>trial and error?
<swedebugia>ask the dev?
<swedebugia>ex https://github.com/mattthias/slurm
<anonymiss> https://github.com/mailchuck/PyBitmessage so far compatible to the stable repo this is merged into
<anonymiss>better ui et
<anonymiss>etc
<swedebugia>got this far https://pastee.org/ekwr7
<swedebugia>thanks for the tip anonymiss
<anonymiss>i recommend both at the same time, dev can have issues sometimes
<anonymiss>and there's a discussion chan for the new version (think they mean mailchuck ), but i can't remember it without looking at Bitmessage
<anonymiss>swedebugia if it's not listed in the repo, you could ping one of my public addresses at http://libertad.pw and i'll send you the chan name/BM tomorrow
<swedebugia>anonymiss: just queued a message for you. how much work do you do when sending? 1.0?
<anonymiss>average default... which is 1.0 i guess
<swedebugia>anonymiss: ok
<swedebugia>it takes minutes on my 2 core 1,6ghz to send... BUT its hopefully private :D
<anonymiss>i have random times.. since i changed to supported usb wifi with external 4 and 9dbm it got faster. i'll be watching Narcopolis now, it looks good and came out this year it seems
<swedebugia>ok. also going afk. see ya!
<pirfle>How long should a package description be?
<davexunit>pirfle: a paragraph or so.
<pirfle>ok
<davexunit>two or three sentences usually.
<davexunit>whatever is sufficient to describe the software
<civodul>ACTION received a Novena for the build farm donated by bunnie \\o/
<anonymiss>cool
<pirfle>What does the error message "Throw to key `match-error' with args `("match" "no matching pattern" #<unspecified>)'" mean, if I run guix build with a custom package definition?
<pirfle>Oh, I see that it also occurs at builds from existing definitions - so I have no error in my package definition. Do I have to add something to PATH or set another environment variable?
<civodul>pirfle: how do you obtain this error exactly?
<davexunit>civodul: wow, really!?
<pirfle>It occurs everytime I invoke "guix build".
<pirfle> http://pastebin.com/9gdTR70i
<civodul>davexunit: yup!
<civodul>pirfle: could you post hello.scm?
<pirfle>It's the example package: http://pastebin.com/C0iWMzHW
<davexunit>civodul: that's so cool. when I reached out to him he didn't have anything to spare.
<fps>ok, sudo ./pre-inst-env guix system reconfigure config.scm did not install my patched guix-daemon
<fps>hmm
<fps>what's the daemon's dmd service name?
<davexunit>guix-daemon
<davexunit>how did you patch guix-daemon?
<fps>eh, i thought i tried that before :)
<fps>davexunit: in a git checkout..
<fps>davexunit: or do you mean literally? i edited some sources and reran make ;)
<davexunit>fps: that doesn't magically update the guix package
<davexunit>the misunderstanding is that you don't install the version of guix you have checked out
<davexunit>you install the guix package as defined within your checkout
<davexunit>in gnu/packages/package-management.scm
<fps>davexunit: ok.. you told me precisely that before. maybe this time it'll sink in :)
<fps>let's see how i get the daemon started again without the offending option.. hmm
<civodul>davexunit: ae got in touch with him a couple of weeks ago, and apparently that was the right time
<fps>hmmm: fps@raksha ~$ grep "cache-failures" /run/current-system/profile/* -R
<fps>Binary file /run/current-system/profile/bin/guix-daemon matches
<fps>that's not it ;)
<fps>btw: if i don't have access to the grub menu, can i just change the /run/current-system and or /var/guix/profiles/system link and reboot?
<civodul>you can change the /var/guix/profiles/system link, yes
<fps>since the build daemon is dysfunctional due to --cache-timeout-failure not being an option for the installed binary, i'm a little bit at loss at how to get the daemon back running
<fps>ok
<fps>civodul: thanks\\
<civodul>just reconfigure without that option
<fps>um, doesn't reconfigure need the daemon?
<civodul>good point :-)
<fps>ok ;)
<civodul>if you have a checkout around, you could run it from there
<fps>i've never run it manually before..
<fps>i'm sure there's lots of chances to screw up
<fps>let me try some
<fps>--usage shows too many for me to try them all ;)
<fps>i think i'll go with changing the profile link :)
<fps>root@raksha /var/guix/profiles# mv system system.bak
<fps>root@raksha /var/guix/profiles# ln -s system-13-link system
<fps>is the .bak there a problem?
<fps>let's give it a shot anyways :)
<fps>the daemon still refuses connections. oh well, almost time to sleep..
<fps>oh, /run/current-system points to a different system in the store than /var/guix/profiles/system-13-link
<fps>got it figured out i think. guix-daemon just needs the right --build-users-group
<fps>ok, so how then do i smuggle the new guix-daemon into the system short of running it manually?
<fps>i guess starting it manually is the better option :)
<fps>does this look familiar to anyone: guix build: error: build failed: unexpected EOF reading a line
<fps>oops, this line:
<fps>error: executing `/libexec/guix/offload': No such file or directory
<civodul>you write too much :-)
<civodul>fps: /gnu/store/*guix*/bin/guix-daemon is another solution
<fps>civodul: that one doesn't have the new option to test though. hmm. then in the checkout with the patched daemon, this should work: sudo ./pre-inst-env ./guix-daemon --build-users-group=guixbuild --cache-failures --cache-timeout-failures ?
<fps>yep, stuff happens. ok. now i can go to sleep safely and see how it turns out :)
<fps>building all 0.9.0 packages :)
<fps>good night and thanks for the help..
<civodul>build all packages doesn't sound good
<fps>why not?
<civodul>hope you used the right localstatedir
<civodul>why would things be rebuilt?
<civodul>dunno
<fps>hmm. i meant i just did for n in `./pre-inst-env guix package -A | cut -f1`; do ./pre-inst-env guix build .... || true; done from the git clone where i have 0.9.0 checked out and some things build.. but not all
<pirfle>Now I'm here again. Have sb got an idea about my problem (^21:44)?
<fps>and started the guix-daemon from the git clone which i have on the branch with the patch for --cache-timout-failures
<fps>some things do not get rebuilt..
<fps>/gnu/store/q1cgdn3yd8lv59pdr38xcq69hv6lxl3x-apl-1.5
<fps>for example..
<civodul>pirfle: add a last line that reads: hello
<codemac>Anyone here used chicken scheme on guix?
<civodul>pirfle: the thing is that the file's return value must be a package
<civodul>pirfle: whereas here, it returned nothing (because 'define' returns nothing, just defines a variable as a side effect)
<fps>codemac: no, but i found that the build fails due to staying silent for over an hour ;)
<civodul>pirfle: see the example for -f at http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-build.html
<codemac>or I should say, "built chicken scheme" -- I think there is a test that has perturbed behavior on systems with unlimited argument list length
<codemac>fps: we looked at the same thing it seems :D
<civodul>codemac: i vaguely recall seeing build issues for Chicken
<codemac>still need to set up my own hydra so I can contribute quicker while I'm at work or doing other things.
<fps>codemac: it's the thing that motivated me to add the --cache-timeout-failures option to guix-daemon
<fps>cause it was being built over and over again
<fps>and timing out over and over again
<codemac>testing direct invocation can detect calls of too many arguments...
<codemac>^^ that's the test that is just sitting there
<civodul>fps: i need to check that bug report
<civodul>this is weird
<fps>civodul: what's weird about it?
<civodul>that i didn't expect it to be buggy :-)
<fps>civodul: packages depend on chicken, chicken gets built. it times out, failure is not cached. next package depending on it gets built, chicken gets built, times out, lalalalaa
<fps>ad nausaeum
<pirfle>civodul: thanks
<fps>civodul: it's not chicken specific but will happen for any package with many dependees which times out..
<fps>codemac: can you disable that particular test?
<fps>another one was a package tbb-4.3.1 or something..
<codemac>I'm not very familiar with chicken, I'm looking into it for a minute or two
<fps>if you care to you can add http://fps.io:9999 to your list of substituters.. it might have a few packages available
<fps>um, or maybe not since the publish service is not running right now ;)
<fps>[since i had to stop guix-service to run guix-daemon manually]
<codemac>it's ok
<codemac>I found it
<codemac>it's apply-test.scm
<codemac>it has a feature flag 'manyargs
<codemac>Does the guix-builder set up things like limits the same for all builds?
<fps>what limits?
<codemac>I'd rather not fix this and have it break people that do have stack size limits, etc
<codemac>the problem here is that the apply-test never exits, and my suspicion is that the test is trying to hit the upperlimit of how many (apply it can call in a row.. but now that I'm looking at the code it's not as clear to me.
<codemac> http://code.call-cc.org/cgi-bin/gitweb.cgi?p=chicken-core.git;a=blob;f=tests/apply-test.scm;h=4996dd0d1ec717be39fe4829b47468b14b9cf75a;hb=HEAD
<fps>sorry, no idea :(
<codemac>someone is asking me on hacker news in guix can install nix packages, I remember this was a goal at some point.. not sure if guix ever intends to do something like that these days though?