IRC channel logs

2018-03-25.log

back to list of logs

<random_auroras>Is Guix built literally on top of Nix or just similar in design and goal?
<mbakke>random_auroras: the latter.
<random_auroras>mbakke: I see. And it's compatible with the latter's package of some reddit page I found was right?
<random_auroras>s/of/if/
<random_auroras>s/the latter's package/Nix's packges/
<mbakke>random_auroras: not really, there's an importer for Nix but I don't know if it actually works.
<mbakke>The main thing Nix and Guix have in common is the daemon, but that's diverging too.
<random_auroras>I see.
<random_auroras>Does GNU have its own package format? The importer suggests so.
<random_auroras>And so it more-or-less doesn't. It's standard tarballs with a description file somewhere on GNU servers. For those interested... https://git.savannah.gnu.org/cgit/guix.git/tree/guix/gnu-maintenance.scm
<mitch80>how to use guixsd on virtual box?
<mitch80> https://thepasteb.in/p/k5hY0BzmwNNCE
<mitch80>during usb installation on gpg -- verify it shows
<mitch80>gpg: no signed data
<mitch80>gpg: can't hash datafile: file open error
<mitch80>can someone tell me why this is happening?
<efraim>from a system.drv is it possible to get a list of setuid binaries? I think I may have messed up my enlightenment service, and that'd be why the binaries i've set SUID aren't working correctly
<efraim>hmm, it seems that /path/to/binary is compiled in, and not just `binary`
<mbakke>Can someone update httpd? I have to go now, but there's a large amount of security fixes. Tarballs can be found here: https://www-eu.apache.org/dist/httpd/
<thomassgn>trying to update httpd to 2.4.33 lets see how it goes... :)
<thomassgn>I might have it, but have not tested it. See https://notabug.org/thomassgn/guixsd-configuration/src/master/modules/ton-tull.scm#L17 for what I did. got to go.
<thomassgn>patch is not sent. mbakke: ^^
<mbakke>thomassgn: Thanks anyway! I'll be back online in about 8 hours and can create the patch then if no one beats me to it.
<efraim>mbakke: looks like u-boot 2018.3 is compatible with our dtb
<efraim>s/dtb/dtc
<efraim>might have spoken too soon, failed to build pine64
<mbakke>efraim: Thanks for working on it :) I'll have to obtain an aarch64 board soon.
<efraim>checked the source online, same bundled version of dtc as the previous version
<efraim>u-boot.itb exceeds file size limit:
<efraim> limit: 516096 bytes
<efraim> actual: 523196 bytes
<efraim> excess: 7100 bytes
<mbakke>Or at the very least dust off the Rockchip Chromebook and get it in shape.
<mbakke>Want to buy free software Mali drivers.
<efraim>not a straight forward update it seems, same failure on the pine64 as I saw before, could be pine64 specific though
<efraim>check out the new wandboards
<efraim>about $100 but free graphics IIRC
<mbakke>They look nice indeed. Do you know if the Broadcom chip works with the free driver?
<efraim>I didn't even check that
<efraim>I'm not expecting much from the WiFi, but I believe we build vivante graphics
<efraim>s/vivante/etnaviv
<mbakke>Ah yes, mesa and libdrm should have etnaviv.
<efraim>The other one I'm looking at is odroid hc[12], it has a sata port, not sure about the libreness of the boot process
<Apteryx_>don't we have a mu4e package?
<Apteryx_>yes: mu
<nckx>:-)
<Apteryx_>but it fails one of its test :/
<Apteryx_>../../build-aux/test-driver: line 107: 11611 Aborted "$@" > $log_file 2>&1 (\\n) FAIL: test-utils
<Apteryx_>yep, reproducible.
<nckx>For certain values of reproducible, then... Builds finely here.
<Apteryx_>oh. Hm.
<nckx> /gnu/store/ii439r3qxz3626fngy99p0x8x3y9v7b8-mu-1.0
<nckx>Weird.
<Apteryx_>Well I'm on a rather involved branch, so maybe I screwed up something.
<nckx>Apteryx_: do you have time to find the test suite log & find out more?
<nckx>Ah, I just got a build failure with --rounds...
<nckx>OK. It seems that my successful build was a fluke, and that test failure is the most common. Kewl.
<Apteryx_>good!
<Apteryx_>thanks for the report. I'll see if I can fix the failure. I'm thinking it must be trying to log to a directory it doesn't have access to.
<nckx>Apteryx_: that's not how I read it, but I'm not undistracted right now.
<nckx>‘ERROR:test-utils.cc:102:void test_date_ymwdhMs(): 'tests[i].diff - diff <= tests[i].tolerance' should be TRUE’
<nckx>(cat lib/parser/test-suite.log)
<nckx>Seems more insidious. I tried re-mounting my /tmp with atime as a guess but that doesn't seem to help. Good luck! :-)
<nckx>Bonus points if it turns out to only have started failing after a certain date. Those are always fun.
<Apteryx_>hehe, it was just a gues (without even looking at test-suite.log). I'll dig further now that the coffee is underway.
<thorwil>some "fun" with mcron during a reconfigure: https://bpaste.net/raw/0bb96ffac78c
<thorwil>could this have to do with last nights switch to daylight savings time (european)?
<efraim>Not sure, my user mcron services aren't happy either, haven't gotten around to debugging them
<Apteryx_>thorwil: could it be an issue going from Guile 2.0 to Guile 2.3? I've updated mcron2 to do so recently.
<Apteryx_>also, mcron2 was deprecated as mcron was updated to a new release which includes all the fixes from mcron2, this is commit cfbf6de18cc70d2e385feb5f61f9363f18e78ddf.
<rekado>ant-bootstrap still fails to build.
<rekado>I need to find a replacement for sablevm
<rekado>nothing I tried consistently fixed the random crashes.
<jonsger[m]>finally Guix 0.14 arrived in openSUSE Factory :)
<thorwil>Apteryx_: if so, can i expect those errors to not reappear, after the whole system has been updated?
<Apteryx_>thorwil: I'm not sure. I'd try debugging the mcron jobs by themselves.
<Apteryx_>you can try running them as your user or with sudo and try to understand what needs to be adapted for them work with the new mcron.
<Apteryx_>(make sure to update your mcron in your user profile first).
<rekado>I’ll see if I can use an older version of JamVM instead of SableVM.
<thorwil>hmm, all mcron has to do here is whatever the defaults are, plus cooperate with a rottlog-service
<rekado>built an older JamVM, but there are still some problems with the Classpath that need to be solved before I can use it to replace sablevm.
<ng0>hi! So I'm trying to switch to a relay OpenSMTPD local.. and the sendmail which comes with it has issues in our installation (with the service running successfully): normal usage with sendmail of opensmtpd gives "cannot create temporary file /var/spool/smtpd/offline/1521994889.XXXXDUZb6n: Permission denied". On Guix this directory is root:root owned, on my OpenBSD this is root:wheel (with more restricted
<ng0>permissions for everyone else) owned.
<ng0>which however is a problem in Guix as opensmtpd complains when it differs from 711 root:root. I'll ask upstream how the sendmail is supposed to act
<ng0>now we're getting somewhere, this might be necessary for a functional sendmail:
<ng0>Mar 25 16:31:47 localhost smtpd[3034]: /var/spool/smtpd/offline is not owned by gid 976
<ng0>Mar 25 16:31:47 localhost smtpd[3034]: /var/spool/smtpd/offline must be rwxrwx--- (770)
<ng0>nvm. I'm back to the previous error I had with my non-existent IPv6 here.
<rekado>Got a replacement for sablevm!
<ng0_>hm. I'm not sure, but there was just something shepherd related which just kicked me completely out, had to hard reset..
<sneek>ng0_, you have 1 message.
<sneek>ng0_, lfam says: It was my mistake, I accidentally reverted your change in my commit
<ng0_>aha
<ng0_>okay :)
<mbakke>rekado: what's the replacement?
<ng0_>the lack of info with shepherd services makes me angry sometimes. if there only were a central log for reasons why a service not started instead of tty 1, and in the current virtual terminal you just get "could not be started"
<ng0_>it's annoying :/
<rekado>mbakke: classpath 0.93 + jamvm 1.5.1
<rekado>classpath 0.93 is the last version that can be built without ECJ
<rekado>jamvm 1.5.1 is the last version to work with classpath < 0.95 (which is the version that requires ECJ).
<rekado>I used jamvm+classpath to build ant-bootstrap
<rekado>now trying to build ecj-bootstrap
<rekado>built successfully.
<efraim>After you get it working I'll see how far I can get with s/ia64/aarch64/g
<rekado>efraim: Classpath will require patching, because it’s got an old configure script .
<rekado>I should be done in about an hour; now I just need to rip out all references to sablevm.
<efraim>That's not too bad
<efraim>Bonus points if it works on other arhitectures :)
<rekado>we will lose some of the complexity because we no longer need to build another round of tools that don’t keep references to sablevm. I think that’s pretty good.
<rekado>efraim: did you ever get sablevm to work on aarch64?
<efraim>Enlightenment hardcodes $destdir/prefix too often
<efraim> https://gitlab.com/Efraim/guix/commits/aarch64-java looks like I stopped at jamvm-bootstrap
<efraim>But looking at other architectures I didn't go far enough to test if it actually worked
<efraim>Of course if it worked I'd change the commits to not be so hackish
<jonsger[m]>efraim: maybe you could review https://build.opensuse.org/request/show/590925 I saw that you are the maintainer of that package :P
<efraim>jonsger[m]: if that's how they call aarch64 (and not arm64) then it looks good
<jonsger[m]>efraim: yeah
<jonsger[m]>%{arm} is armv7l and armhf, aarch64 is arm64
<Sleep_Walker>jonsger[m]: FYI guix will be in next Factory snapshot :)
<Sleep_Walker>%arm is defined as 'armv3l armv4b armv4l armv4tl armv5b armv5l armv5teb armv5tel armv5tejl armv6l armv6hl armv7l armv7hl armv7hnl'
<jonsger[m]>efraim: all four supported platforms a green now :)
<amz3>seems like the outreachy program is going well
<rekado>I just built icedtea with the changed bootstrap.
<rekado>but ant-bootstrap just failed again on berlin.
<rekado>seems easy to fix, but I wonder why it didn’t fail on my laptop
<rekado>hmm, this is more difficult than I thought.
<rekado>it consistently fails to build on berlin, but it builds just fine on my laptop.
<rekado>hmm, the difference is of course the bootstrap phase that exists on the rhel6 branch, but not on master.
<rekado>very disappointing. On rhel6 the new bootstrap JDK doesn’t seem to work. It just hangs when trying to compile ant-bootstrap.
<rekado>Just like the sablevm-based JDK (when it wasn’t just segfaulting)
<ng0>hm... so when you reconfigure at least 5 times in a row without rebooting (could be just a coincidence) on a commit around bba66e7a600b35159d20e41df7c18fc1ec764dd9 (I'm running my czustom thing, this is the last master commit in guix it bases on), so the new shepherd version should be in there, you trigger a kernel panic. I've had 2 in the last 5 hours..
<ng0>I'll see how I can reproduce this soon
<ng0>of course my setup is different from yours, different kernel etc, but I can try to run with linux-libre on another laptop and reproduce it
<Apteryx>Can I start a Guix environment from inside Emacs?
<Apteryx>so that even Emacs modes such as GDB will have access to the environment's libraries and such?
<mbakke>rekado: Reminds me of the ant-bootstrap issues on the previous core-updates, where it "mostly worked" when built on low-end hardware, but not on Big Machines.
<rekado>mbakke: yeah, exactly.
<rekado>I looked at this more closely and jikes can compile the bootstrap source files just fine. It just gets stuck when running the bootstrap ant, which calls out to jikes.
<Apteryx>emacs-guix always gives me: guix environment: error: execlp: No such file oremacs-guix always gives me: guix environment: error: execlp: No such file or directory when trying to use environments.
<rekado>found a way to fix it with a jamvm option. It’s not pretty though.