IRC channel logs


back to list of logs

<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?
<amz3>try 'dmesg'
<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>allana: ^
<amz3>there is even a section in the documentation wow!
<allana>amz3: thanks! :-)
<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
<janneke>Hello Guix!
<roptat>hi Guix!
***daviid is now known as Guest71115
<civodul>Hello Guix!
<janneke>hello civodul!
<civodul>hey janneke!
<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>uploading it now
<civodul>upload, 2nd try
<janneke>oh my...
<civodul>yeah i got a failure email, but there's a bit of latency as you know...
<janneke>tell 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 uploaded them as "x86_64-linux"
<civodul>janneke: hmm
<janneke>we know that the content is identical between i686 and x86_64, shall i just change this in name
<civodul>i could rename it, bah
<civodul>how does that work again
<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
<janneke>thank you!
<efraim>can I ask someone to take a look at the file CVE patch I have on guix-patches?
<rekado>on berlin Guix fails to build:
<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>here’s the most recent attempt:
<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>what might I be missing?
<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.
<efraim>With and without grafts?
<rekado>no, that’s not it.
<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
*rekado tries again
<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
<janneke>roptat: fun!...
<roptat>and I was saying nice things about groovy at the R-B summit
<roptat>because our version is bootstrappable
<roptat>what should I do?
<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
<roptat>ah, found it
<janneke>if you have a very clear case and can make a crips report, it may just raise some awareness, you never know
<janneke>oh oops: crisp -- a very clear case
<roptat>I still don't understand
<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>ah I see
<roptat>does hydra build stuff for aarch64?
<efraim>Just Berlin, unless something changed
<jackhill>Would software like and meet the free software distribution guidelines? They are mainly for working with non-free network services (although the former supports free and quasi-free services to some extent as well).
<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.
<rekado>yes, sounds good
<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.
<rekado>slowly getting there
<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
<janneke>sounds nice
<roptat>or maybe remove groovy support from picocli if that's not needed, then rebuild picocli
<roptat>that should be even easier
<roptat>so many options :)
<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 :)
<bavier>in version 7.10
<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
<roptat>this broke jarjar :/
<bavier>efraim: ghc@7.10.2 has an "arm" release:
<bavier>(later it's "armv7")
<efraim>so it does, i wonder how I missed that
<bavier>efraim: then in ghc@8.2.1 there's a "aarch64" binary:
<bavier>so that's a bootstrapping question. I suppose it would be better to go back as far as possible?
<efraim>there's also
<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
<bavier>efraim: cool, that should work
<efraim>and it reuses a lot of code
<efraim>well my armhf attempt ended early, patchelf still doesn't build for armhf
<bavier>oh... :(
<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
<baconicsynergy>Hi guix!
<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: congrats!
<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...
<janneke>i feel so silly about that
<g_bor>hello guix!
<g_bor>something seems to be strange.
<bavier>hello g_bor
<g_bor>I'm building icedtea-6 right now, from a very recent master.
<g_bor>any idea why?
<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>allana: I've found it
<g_bor>the git update on master rebuilds the java world...
<allana>I suppose that's why there is no substitute yet
<g_bor>yes, exactly.
<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>something is fishy...
<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>here it goes:
<g_bor>it is a bit longish, but worth the reading.
<xelxebar>Nice. Thanks for digging that up.