***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 ***daviid is now known as Guest70811
***Guest70811 is now known as daviid
<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) :) ***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 <rekado>I think I need to be using %current-target-system because I’m cross-building the tarballs. <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. <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? <rekado>yeah, but this no longer seems to work. <civodul>could you paste the failing build log that you have? <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>roptat: could you email details to bug-guix@gnu.org? <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>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>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>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? <rekado>civodul: the DESCRIPTION file supports GPL >= 2 (which is expanded by CRAN to an explicit list of two versions) <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>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>roptat: looks like you're making very fast progress! <roptat>I'll probably be bitten by some race conditions though <roptat>oh and I found that the environment only builds the x86_64 version, but it really uses the i686 version... <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? <efraim>Maybe grafts are partially to blame? <roptat>I think it's related to %current-system <efraim>What about 'guix environment --system=i686-linux --ad-hoc p7zip --system=i686-linux' <efraim>First system for the environment, second for p7zip <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 <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>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>(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? <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 <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>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) <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? <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>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 <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) <rekado>hmm, weird that the cert for issues.guix.info isn’t right. <rekado>civodul: might this be related to your experiments with nginx on berlin.guixsd.org? <rekado>georges-duperon: there’s no SQL query for issues.guix.info. 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. <rekado>civodul: not really your fault, because I should have made the changes permanently in the maintenance repo, not just on berlin. <rekado>I only made them in the copy of the maintenance repo on berlin; haven’t actually committed the changes yet. *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. *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>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 issues.guix.info to show submissions that are open but that have not received any responses yet. <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. <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)