<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
<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>(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?
<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 issues.guix.info :-(
<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).
<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
<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?
<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.