<allana>Hi, I am building a go program. when I reach the "reset-gzip-timestamps" build phase, I get an error: "In procedure open-fdes: Permission denied". Has anyone had an experience like this, and can anyone guide me through fixing this error? <allana>amz3: from what I can tell, dmesg doesn't produce anyhting interesting <amz3>well, the error is a hint to use 'strace' but I don't know in the context of guix how to do it <amz3>allana: there is a procedure I think to keep the build after the failure and then run the build yourself, do you know what I am talking about? <allana>amz3: I am a complete guix newbie here. I am trying to run the build now having deleted that phase <amz3>allana: look into 'guix build -K package-name' <amz3>there is even a section in the documentation wow! <reepca>any idea why xterm would be honoring ~/.Xdefaults but uxterm wouldn't be? <reepca>never mind, turns out you need UXTerm* lines instead of XTerm* lines in there when launched as UXTerm. <apteryx_>I'm trying to build a package from a local git checkout: guix build --with-source=supercollider@3.10.0=$HOME/src/supercollider supercollider <apteryx_>but I get the error: guix build: error: sendfile: Broken pipe. Any ideas? ***apteryx_ is now known as apteryx
<reepca>anyone know of a good font that has ツ in it but also is nicely monospaced in xterm? Apparently xterm can only use a single font (as far as I've been able to discern), which is pretty annoying <efraim>is that a composed character? I tried ") to get it but it didn't work <reepca>dunno, it's some fancy asian character that I use in my M-x shrugs ¯\_(ツ)_/¯ <efraim>I normally alternate between "dejavu sans mono (book)" and terminus <reepca>I wonder if there's a way to create fonts that are "unions" of other fonts for situations like this where for some reason it wants only one font... I think. <reepca>dejavu sans mono doesn't display it, installing terminus to give it a shot <reepca>In gui emacs I see it, and M-x describe-char tells me it's from unifont. But I tried that in xterm and it looked pretty bad. And then I try unifont mono and it looks good but doesn't have that character... <reepca>hm, seems terminus doesn't have it either <efraim>It might be xterm, I don't remember having good luck with Hebrew fonts there ***daviid is now known as Guest71115
<civodul>so i guess we're all set with this new round of binaries, right? <janneke>samplet is working very hard on the gash/geesh merger, i'm urging them to post to guix-devel but they need some more days -- the merger is very rough <janneke>we may get a bootstrap-gash some time, but i don't expect that before FOSDEM <janneke>and possibly it can be source-only, no bootstrap binary needed... <janneke>civodul: "round of binaries" is only mes-minimal-stripped-tarball update, right? <civodul>yeah i got a failure email, but there's a bit of latency as you know... <janneke>tell me...it took me quite some time (and got help) to get my first mes upload done <janneke>i keep reminding myself how happy and proud i am that you and rekado and myself and ... are an important part of gnu <janneke>civodul: oh wait...you uploaded them as "x86_64-linux" <janneke>we know that the content is identical between i686 and x86_64, shall i just change this in name <janneke>i just downloaded and verified that guix hash gives the exact same answer... <civodul>janneke: i'm uploading it under the right name now <civodul>so you can push your commits with "i686-linux" in the name <rekado>make: gnu/system/examples/lightweight-desktop.tmpl: Timestamp out of range; substituting 2514-05-30 01:53:03.999999999 <rekado>cp: cannot create regular file 'doc/os-config-lightweight-desktop.texi': Permission denied <rekado>that’s directly on berlin, no offloading *janneke has weird mailing troubles <rekado>I’m still trying to automate building systems for the build farm nodes. <rekado>I’m building things locally, push the derivations and the outputs to the target, and then I run a remote reconfiguration. <rekado>but for some reason reconfiguration still downloads a lot of things, indicating that I haven’t pushed all items to the target. <rekado>I’m pushing the OS output, Guix itself, and all derivations for these two outputs. <rekado>on the remote I then use the copied Guix to reconfigure. <rekado>I tried with and without grafts. *janneke is feeling wobbly about apparently nice work being done, but advocating proprietary software on #bootstrappable <rekado>there may have been a slight configuration difference <roptat>I'm trying to update our groovy package... the first groovy package (entirely written in java) now depends on picocli <roptat>picocli is written in java, but depends on groovy's standard library for some reason <roptat>and I was saying nice things about groovy at the R-B summit <roptat>because our version is bootstrappable <roptat>I could update to the latest version of the 2.4 branch, then build picocli with that, then build the latest version (2.5.4) <roptat>now for the new version, I could build the bootstrap and use it to build the rest, or use the old compiler to build the new one <janneke>roptat: i guess you can't file a bug report against groovy for adding this circular dependency? <roptat>I don't know where there bug tracker is <janneke>if you have a very clear case and can make a crips report, it may just raise some awareness, you never know <janneke>hmm, i just meant a good bug report -- not vague but precise -- you have a clear case of being able to build it, but unable to update it <roptat>does hydra build stuff for aarch64? <efraim>Just Berlin, unless something changed <rekado>jackhill: it is not clear what “free service” means. If it is free software and it doesn’t steer the user to installing non-free software then it is fine. <jackhill>rekado: thanks. In this case the service is primarily GitHub, and, at least for me, using those packages instead of the web interface with non-free JS (and easy scripting from emacs, etc) is a step in the right directrion freedom-wise. <jackhill>they are free sofware, and don't recommend installing additional software, so I think it would be fine. <bavier>rekado: are you settled into the new apartment yet? <rekado>bavier: I sit between half assembled furniture and the contents of unpacked boxes. Most rooms are still really messy. <bavier>rekado: :) good luck. I just recently unpacked the last box from my move 2 years ago :P <notnotdan>jackhill: I've never heard of magit/forge, but it looks cool! <notnotdan>and it works with gitlab, which is free software, right? <roptat>mh... Maybe I can just remove picocli support in the bootstrap Groovy, then build picocli, then groovy with picocli <roptat>or maybe remove groovy support from picocli if that's not needed, then rebuild picocli <janneke>yes, one of the big challanges of bootstrapping--what to choose <rekado>a few of the net-snmp tests fail on berlin, but they pass on my workstation. <bavier>speaking of bootstrapping, I was thinking of trying to add aarch64 support to our GHC package. The bootstrap binary would need to be a different version, since aarch64 support wasn't added until 8.2, iirc <bavier>so rather than 7.8 -> 8.0 -> 8.4, we'd have 8.2 -> 8.4 for aarch64 <roptat>ah, we need a newer java-asm now <roptat>but it seems that using a groovy-less picocli will work <jlicht>jackhill: I am working on packaging forge and all the required dependencies right now :-) <jlicht>Although I think there will still be quite some bugs in the current versions of forge and ghub, so it might take up to a week before the dust settles <efraim>Sed and grep releases! It's been a busy day <efraim>bavier: if you match it up with armhf they can share the bootstrap versioning <bavier>efraim: I considered that; it could work <bavier>armv7 support was added much earlier <jackhill>notnotdan: I didn't now about it until yesterday :) <efraim>The release binaries are only one version off from eachother I thought <jackhill>jlicht: awesome! Feel free to ping me if you need a tester (although I mostly work with gitlab projects) <efraim>... found the cat napping on my laptop again <efraim>good thing I locked the keyboard this time <efraim>so it does, i wonder how I missed that <bavier>so that's a bootstrapping question. I suppose it would be better to go back as far as possible? <efraim>yeah, as far back is probably preferable <efraim>I don't know why I remembered it as 8.2 and 8.0 <bavier>np. I'll look at the aarch64 only for now, my machine can't emulate 32-bit arm <efraim>worst case we can add armhf at the aarch64 level and then move it back later i guess <bavier>uff da, this will be harder than I thought, there's more bootstrapping stuff embedded in the ghc-7 package than I thought <efraim>bavier: I'm going to try to put the armv7 bootstrap (7.10.3) in ghc-7.10 and let it work from there <efraim>so blessed-binary-7.10.3->ghc-7.10.2->ghc-8 <efraim>well my armhf attempt ended early, patchelf still doesn't build for armhf <bavier>maybe time to extend (guix build gremlin) with more patchelf features? <efraim>It would be nice to not need it anymore ***ilya-fedin_ is now known as ilya-fedin
<janneke>vagrantc: the mes-bootstrap bug we found at R-B has been squashed and we now have a pretty nice bootstrap story in place <vagrantc>janneke: now you just need to trick, er, convince other distros to get on board :) <janneke>thanks! hoping to get that into nixos too and wondering about debian <janneke>vagrantc: yeah, there was this debian developer whose name i did not catch at R-B, who also wanted to talk with you and me about this... <g_bor>something seems to be strange. <g_bor>I'm building icedtea-6 right now, from a very recent master. <allana>g_bor: funny that you say that. me too. it's been going on for over an hour. <allana>g_bor: I am also curious about this. <g_bor>the git update on master rebuilds the java world... <allana>I suppose that's why there is no substitute yet <g_bor>This also means that berlin is already lagging more than 30 hours behind on that commit. <g_bor>I am working on changes on the Cuirass web interface to have a better overview about what is going on. <g_bor>istm that we can't get the number of rebuilds triggered by git update <xelxebar>Is there a canonical way to chroot into a guixsd root? <g_bor>I would not say so, but there was a thread on the mailing list on how to do that <xelxebar>I copied over the directory hirerachy from the qemu image and would like to chroot into it just to play around <xelxebar>g_bor: Thanks. I took a cursory glance at what initrd was doing to see if I could easily copy it, but wasn't too successful. <g_bor>it is a bit longish, but worth the reading.