IRC channel logs


back to list of logs

***PuercoPop is now known as Guest12368
<ecbrown>rekado: bought a pentium 4 today, now debian hurd installer proceeds. now i gotta find an open ethernet card like an intel pci and probably new ide hard disks and ribbon cables. this stuff is kind of hard to find local. :-(
<ecbrown>actually bought two of them -- i had to canibalize memory from the other one to get it boosted up to 1 gig
<ecbrown>this machine is gonna rock
***daviid is now known as Guest70811
***Guest70811 is now known as daviid
<emacsomancer>I'm getting a weird error trying to use guix-emacs
<emacsomancer>" 1 (eval (#<procedure 2c737d0 at <unknown port>:19:16 ()>) #<directory (emacs-guix) 2965960>)"
<apteryx>ecbrown: cool (debian hurd box!) I had that running in a VM at some point, I hope to get back to it soon (Although it'll be GuixSD + hurd) :)
<civodul>Hello Guix!
<georges-duperon>G' morning :)
***rekado_ is now known as rekado
<rekado>I’m trying to build the graph for the Hurd bootstrap tarballs. Since “guix graph” doesn’t support “--target” I thought I could do this:
<rekado>guix graph -e '(begin (use-modules (guix utils)) (parameterize ((%current-system "i586-pc-gnu")) (@@ (gnu packages make-bootstrap) %bootstrap-tarballs)))'
<rekado>(or replace %current-system with %current-target-system)
<rekado>but neither of these produces output containing any Hurdish things.
<janneke>rekado: i've been using things like: ./pre-inst-env guix graph --type=bag -e '(begin (use-modules (guix packages)) (%current-system "i686-linux") (@@ (gnu packages commencement) diffutils-boot0))'
<janneke>rekado: to be able to cross build the i686-linux bootstrap, i had to change a number of %boot*-inputs from variable to procedures; so that they are not evaluated at load time
<janneke>i think...
<rekado>I think I need to be using %current-target-system because I’m cross-building the tarballs.
<janneke>ah right...
<rekado>janneke: thanks for the help. I ended up with this: guix graph -e '(begin (use-modules (guix utils)) (%current-target-system "i586-pc-gnu") (@@ (gnu packages base) glibc/hurd)))'
<rekado>it doesn’t show me all the bootstrap tarballs, but I’ll get there eventually
<civodul>rekado: the last command above should work
<civodul>(note: beware of the system vs. triplet confusion!)
<civodul>it looks like the "recent issues" thing and the "date:" filters do not consider new entries as recent
<rekado>what’s the system vs triplet confusion? I probably suffer from it.
<janneke>rekado: \o/
<civodul>rekado: "x86_64-linux" is a "system type" (from Nix); "x86_64-linux-gnu" is a triplet (from GNU)
<civodul>the former is what guix -s understands; the latter is what configure scripts and the toolchain expect
<civodul>%current-system is a system type, whereas %current-target-system is a triplet
<civodul>yeah this is all quite confusing :-)
<rekado>is “i586-gnu” the system type and “i586-pc-gnu” the triplet?
<civodul>in theory it would make more sense for the system type to be "i586-mach", but it doesn't matter much
<rekado>that clears up some of my confusion, thanks!
<rekado>wow, I can’t believe how useful this bit of confirmation was. I’m no longer second-guessing my changes all the time, wondering if maybe I should have used “i586-gnu” instead.
<rekado>however, I’m still confused about the difference in behaviour between this: guix build -e '(begin (use-modules (guix utils)) (%current-target-system "i586-pc-gnu") (@@ (gnu packages base) glibc/hurd)))' — and “guix build --target=i586-pc-gnu bootstrap-tarballs”
<rekado>with the first command I get to build a few things up to a failing build of glibc
<rekado>with the second command, however, it fails building the gnumach-headers (because configure says “C compiler cannot create executables”)
<civodul>that's because cross-base.scm does a lot of things behind the scenes, which you don't get with the first command
<civodul>rekado: did you see the hack that consists in passing --build=i586-pc-gnu for mach?
<civodul>likewise for --host in hurd-headers
<rekado>yeah, but this no longer seems to work.
<civodul>could you paste the failing build log that you have?
<rekado>yes, just a moment.
<roptat>hi guix!
<roptat>there's something I don't understand in the difference between inputs and native-inputs
<roptat>when I build a package with --system=i686-linux, which inputs will be fore i686 and which ones for x86_64?
<rekado>roptat: IIUC “--system” is special; it’s not real cross-building.
<rekado>native-inputs only matter for actual cross-compilation.
<civodul>rekado: you successfully built cross-gcc and cross-binutils already, right?
<civodul>as in "guix build -e '((@ (gnu packages cross-base) cross-gcc) "i586-pc-gnu")'"
<roptat>I'd like to have an i686 environment, but using --system=i686-linux still builds things for x86_64...
<roptat>and I can't add a store path to the environment
<roptat>"guix environment --ad-hoc foo --system=i686-linux" uses a different foo than the one returned by "guix build foo --system=i686-linux"
<civodul>that sounds like a bug
<civodul>roptat: could you email details to
<rekado>civodul: yes, I’ve built the cross-gcc already.
<civodul>so the failure is: guix build -e '((@@ (gnu packages cross-base) cross-kernel-headers) "i586-pc-gnu")' -K
<rekado>that’s right
<civodul>at (which succeeds, on master) we get the exact same configure flags
<rekado>config.log shows me that building the test program fails with “error: unknown type name 'size_t'”
<rekado>that’s in /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include/bits/types/struct_FILE.h
<civodul>hmm ok
<civodul>also you're using a different version of gnumach than on master, right?
<rekado>in order to use glibc 2.28 we need the latest version of gnumach from git.
<civodul>could you send config.log?
<civodul>rekado: /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include are the native headers, which is OK
<civodul>perhaps the problem is that linux-kernel-headers are not in we C_INCLUDE_PATH?
<civodul>or that there are same-named Mach headers in C_INCLUDE_PATH?
<civodul>what does 'environment-variables' look like?
<roptat>so I can't reproduce it with other packages... maybe that's related to the fact that foo depends on bar which is different depending on %current-system
<civodul>rekado: when an R package says "License: GPL-2", it's really v2-only, right?
<jonsger>we don't have guix package --search which only searches for package names?
<roptat>that's also probably why the package is different when the dependency is an input or a native-input
<roptat>how do I refere to %current-system from inside the build environment?
<civodul>jonsger: "guix package -A"
<rekado>civodul: yes.
<rekado>civodul: the DESCRIPTION file supports GPL >= 2 (which is expanded by CRAN to an explicit list of two versions)
<civodul>ok, thanks
<roptat>ok, I found how to fix my issue :)
<roptat>on guile-torrent, I now have the code to remember what pieces my peers have, and select one of them that I don't have and don't have asked another peer for
<roptat>all I need now is to actually write the piece to a file and debug the whole thing
<roptat>because somehow messages between fibers get blocked at some point
<rekado>civodul: hmm, the env vars look fine to me:
<rekado>I checked with find and diff if there are any same-named headers between linux-libre and gnumach but I haven’t seen any.
<civodul>hmm, dunno
<civodul>roptat: looks like you're making very fast progress!
<roptat>I'll probably be bitten by some race conditions though
<roptat>and my code is a mess ^^'
<roptat>oh and I found that the environment only builds the x86_64 version, but it really uses the i686 version...
<civodul>bug report, bug report! :-)
<roptat>that's visible for p7zip for instance: `guix build p7zip --system=i686-linux`, then `guix environment --ad-hoc p7zip --system-i686-linux` will build another version of p7zip, but from the environment `ls -l $GUIX_ENVIRONMENT` shows the i686 version that was built with guix build
<roptat>so the environment is correct, but I don't think the extra build is exected, right?
<civodul>hmm weird
<efraim>Maybe grafts are partially to blame?
<roptat>I think it's related to %current-system
<roptat>but I can try a few things
<efraim>What about 'guix environment --system=i686-linux --ad-hoc p7zip --system=i686-linux'
<efraim>First system for the environment, second for p7zip
<roptat>efraim: same
<roptat>actually, bigloo shows that behaviour, so it's probably unrelated to %current-system after all
***rain1 is now known as rain2
<civodul>roptat: what are you doing with bigloo? :-)
<roptat>civodul: nothing, just testing whether it would also download the x86_64 version
<roptat>it did
<civodul>that's buggy
<civodul>rekado: how do you test changes to the nginx config?
<civodul>it seems that "nginx -s reload -c new-conf.conf" doesn't work
<civodul>instead it just reloads the original config file, right?
<rekado>civodul: I haven’t done this in a long time. Back then on FHS systems I would just issue a reload, which would load the new config from the same place.
<rekado>hmm, when building cross-kernel-headers the build system type and host system type are both i586-pc-gnu; but the gcc is just the host gcc.
<civodul>rekado: i think the problem is that --build=i686-pc-gnu should not be passed in this case
<civodul>snape, roptat: you're familiar with nginx right? :-)
<civodul>i'm trying to see why nginx is slow on berlin for /nar URLs (it proxies 'guix publish')
<snape>civodul: do you have an example URL?
<civodul>(or any nar URL)
<civodul>compared to what's in guix-maintenance.git, i've turned off proxy_cache and proxy_buffering for /nar
<civodul>the result is that performance is bad
<civodul>when i strace nginx, i see that it reads from the backend 4k at a time
<civodul>then sends those 4k to the client
<civodul>so no wonder it's slow
<civodul>(the backend uses sendfile(2) so no problem there)
<rekado>when %current-target-system is not set, “--build=i586-pc-gnu” is deliberately passed, according to the comment: “GNU Mach supports only IA32 currently, so cheat so that we can at least install its headers.” Without it we attempt a native build, which isn’t supported and dies with “ unsupported combination of cpu type `x86_64' and platform `default'”.
<rekado>civodul: is reading 4k chunks not expected when proxy_buffering is disabled?
<snape>civodul: is 1,3MB/s slow?
<rekado>civodul: in addition to proxy_pass to “guix publish” could we use “try_files” to let nginx send the requested nar directly if it exists?
<civodul>snape: it's definitely slow; when proxy_cache was on and the thing was in nginx's cache, i could reach 20+MB/s
<civodul>rekado: didn't know about try_files, lemme see
<civodul>not sure i understand try_files, also we'd need to compute the file name from $uri, dunno if that's possible
*civodul gives up :-/
<mbakke>civodul: Are you sure the bandwidth is not throttled elsewhere?
<civodul>mbakke: yes, because when caching is enabled, on cache hits, i get 20+MB/s
<civodul>try "wget -O /dev/null"
<mbakke>civodul: Right. I got 1272k/s.
<jonsger>20,8MB/s in 1,2s
<mbakke>jonsger: Woah :-)
<roptat>16,8MB/s ds 1,5s
<civodul>so here i get ~20M, whereas if i turn off caching and buffering, i get ~1.5
<civodul>yet the strace of nginx is not very different
<civodul>and 'guix publish' cannot be blamed i think because it just calls sendfile(2)
<civodul>so i don't get it
<jonsger>I get between 2.5M and 20M. When I repeat it
<roptat>civodul: can you test directly guix publish?
<civodul>roptat: not easily, i think i'd need to get an additional port open at the MDC, which could take a while
<rekado>to test “guix publish” directly one could open an SSH tunnel and thus forward the local port.
<georges-duperon>Huh, my browser complains about some SSL certificate issue for :-(
<georges-duperon>civodul: re. the "recent issues" and "date:" filters, it looks like it's using SORT BY DATE, instead of SORT BY DATE DESC (but I couldn't find the repo for that issue-tracking tool to make a PR).
<jabranham>georges-duperon: mine too FWIW
<georges-duperon>To run commands after boot (think /etc/rc.local), recommends creating a new Shepherd service.
<georges-duperon>Is this still the case or is there a simpler way?
<lfam>georges-duperon: I think it's still the case. I think that by not adding a catch-all thing like etc-rc-local-service, we subtly push people to make "proper" services. But it also can push people away who may want to use GuixSD but are not (yet!) proficient in Scheme
<georges-duperon>lfam: I'm proficient in Scheme, but lazy — although I do prefer my languages non-lazy :-p
<lfam>Heh :)
<georges-duperon>lfam: +1 for pushing people to make proper services, I suspected that was the motive and in the end it seems not that scary.
<lfam>For better or for worse, all my non-GuixSD systems have a few lines in '/etc/rc.local'... and they are all different! So I think a GuixSD service that just runs some arbitrary commands could be useful
<lfam>But it would also be useful to encourage people to share how they use it so we can see what is missing from the greater set of GuixSD services
<mbakke>Can we package a snapshot of the Python 3.7 branch for core-updates? There have been many important fixes, but the 3.7.1 release is still a few weeks away :/
<lfam>mbakke: Do you know what the Python team things of doing that? Is it like glibc where it's basically expected?
<lfam>I guess what I'm wondering is, do they keep their branches in good working order?
<mbakke>lfam: I have no idea. Apparently some of the commits break their CI:
<mbakke>lfam: Debian seems to take the whole branch, although as a patch (see git-updates.diff):
<lfam>But they aren't deploying 3.7 yet, right? <>
<mbakke>Only for testing and unstable:
<mbakke>Oh wait, that's a separate package.
<mbakke>lfam: In unrelated news, do you think we should graft Ghostscript 9.24?
<lfam>mbakke: Yeah, and probably some more patches. I've been putting it off since there is basically no communication from upstream
<lfam>It's very confusing
<lfam>I assume you're following that discussion on oss-sec. Are the bugs fixed? Are they not? I guess that only taviso can tell us
<lfam>At the same time, we should check on CVE-2018-16435 in LCMS
<lfam>Oh wait, our Ghostscript uses a bundled LCMS, so it's not important to handle them together
<lfam>I'm currently testing a graft of libgd
<mbakke>lfam: It does not help that the security review bug is private: :/
<mbakke>Apparently still lots of commit activity around it:;a=log
<lfam>I think it's going to be a long time before it's really "safe". I wish they would be more transparent in the meantime
<lfam>Maybe we should just build from Git, idk
<mbakke>lfam: I considered it too, 'master' is only a few (important-looking) commits ahead of 9.24.
<lfam>It's worth a try, anyways. Same with Python. We could try it and see if our systems still work
<lfam>(I didn't look at the Python log to see what might have been fixed)
<georges-duperon>What's the purpose of #~ in Guile? E.g. in #~(lambda …).
<georges-duperon>It's hard to search online for these two characters :)
<rain2>I think that's a g-expr
<georges-duperon>rain2: Thanks a lot!
<rekado>hmm, weird that the cert for isn’t right.
<rekado>civodul: might this be related to your experiments with nginx on
<rekado>georges-duperon: there’s no SQL query for It talks to the Debbugs service.
<rekado>a couple of hours ago I let it also return recently submitted issues in addition to issues that had recently been commented on.
<civodul>rekado: should be fixed now
<rekado>civodul: not really your fault, because I should have made the changes permanently in the maintenance repo, not just on berlin.
<civodul>though i'm not sure what went wrong
<civodul>i think you did, no?
<rekado>I only made them in the copy of the maintenance repo on berlin; haven’t actually committed the changes yet.
<civodul>ok, i thought i had seen it
*rekado tries to fix glibc/hurd on the master branch instead
<rekado>I have to say that the bootstrap is really the most difficult part to understand.
<civodul>yeah, too bad this turned out to be this painful
<civodul>i must say i forgot the details so i'd have to dig into it again
<rekado>I’ll try not to bother you with this
<rekado>I’m a bit down because I haven’t been able to figure things out on core-updates.
<rekado>need some achievement soon :)
<janneke>i've been stuck several times...
*janneke is only attempting making the bootstrap even more complicated :-/
<janneke>mes doesn't work for hurd yet, no worries
<janneke>i could do with some help for the hurd libc port, though
<rekado>the problem on the master branch is that glibc is patched but the patch doesn’t apply to the old Hurdish glibc.
<civodul>i think cross-bootstrap brings its own challenges too :-)
<rekado>seems simple enough, but after playing with this for a while I can say that it really is not as easy as it seems.
<janneke>yes, i'm afraid that my grafting the bootstrap onto mes has broken that too, at least for x86 ... so much work still to do
<janneke>...small steps
<janneke>rekado: what has helped me a lot is to just talk about where and why i'm stuck, here or on #bootstrappable
<janneke>sometimes i got great help, sometimes just explaining gives new energy
*rekado would like to show submissions that are open but that have not received any responses yet.
<rekado>yes, that’s good advice
<janneke>we have very friendly and helpful communities here
<janneke>i tried to help phant0mas a little bit with a recipe for a debian hurd VM+guix, and tried a week to create a minimal libc for hurd -- otherwise i have no experience; but it would be nice to join efforts some time soon
<rekado>I’m trying to get the bootstrap binaries built and then add a Debian Hurd + Guix VM to the build farm.
<janneke>ah, i used to pull those from phant0mas' server i think
<rekado>the lack of substitutes (and of build monitoring) was a serious obstacle for me back when I wanted to help the GuixSD with Hurd efforts.
<janneke>yes, i can imagine
<OriansJ>I guess no one is familiar with mkinitcpio.conf changes in guixsd
<rekado>OriansJ: sorry, I don’t know. The initrd in GuixSD is a bit special.
<rekado>looks like the old glibc/hurd on master fails to build (after my changes) because our binutils is now too new.
<OriansJ>rekado: Its fine, I guess I'll put it in my queue and deal with it when I get the time (unless someone else finds a solution sooner)