IRC channel logs

2020-05-19.log

back to list of logs

<alextee[m]>🎉
<PotentialUser-72>Still trying to install GuixSD and now when I do guix pull; guix system reconfigure; the guix package version is stepping **backwards**
<PotentialUser-72>I first got Guix 1.1.0rc2, now I just got guix 1.0.1-15
<PotentialUser-72>Any hints tips or incantations?
<lfam>PotentialUser-72: If you did `guix pull`, you should not be going backwards
<lfam>However, `guix pull` is per-user
<pkill9>it doesn't matter because you normally don't use that version of guix, you use the one you get with `guix pull`, which will update the user's guic
<lfam>Each user has their own `guix pull`
<pkill9>guix*
<lfam>But, reconfigure requires root
<lfam>So, make sure you pull as root before reconfiguring
<PotentialUser-72>I running as root because i'm still at the initial guix stage - trying to get working system to boot into.
<lfam>And pkill9 is correct, you should not install Guix with Guix.
<lfam>I mean, do not do `guix package --install guix` or `guix install guix`
<lfam>So, you are still trying to install the system? Reconfiguring is something you only do after you install
<PotentialUser-72>lfam: I've done none of those.
<lfam>Okay
<lfam>Can you clarify your question?
<PotentialUser-72>The guix init never finished cleanly.
<PotentialUser-72>so am trying to progress that.
<lfam>How did it fail?
<PotentialUser-72>First a timezone typo resulted in etc.drv failing to build.
<PotentialUser-72>Once that was fixed it is now choking on grub install
<lfam>How?
<lfam>It's not easy to give advice without specific details
<PotentialUser-72>lfam: appreciate the help. Its not easy reproducing these error msgs on a different computer ;)
<lfam>It can be enough to just paraphrase the error message
<PotentialUser-72>grub-install is looking for a file in a i386 path on a x86_64 arch machine.
<PotentialUser-72>This is a efi boot, and it seems the partition holding that should have been mounted to /boot/efi and not /mnt/boot/efi
<PotentialUser-72>Not sure yet. because guix started going backwards
<lfam>It's normal and expected for grub to say "i386" on 64-bit Intel-compatible hardware
<lfam>Where are you seeing the Guix package version?
<lfam>I'm not sure if you should be seeing GRUB stuff is you specified to use EFI, however
<PotentialUser-72>Ok but when I loked in that path there was no i386 folder only a x86_64 folder.
<lfam>I mean, if you specified
<lfam>GRUB just calls it i386
<lfam>I don't know specifically what file you are talking about but, in general, this is probably a red herring
<PotentialUser-72>I'm saw the guix package version at the reconfigure step when it grabbed it.
<PotentialUser-72>I've gone back to trying to just keep rerunning guix system init.
<PotentialUser-72>FYI this adventure started last night when the guix servers seemed to be down
<PotentialUser-72>first a build failed, then guix pulled returned 504, then 502 untill this AM when guix pull proceeded and then guix system init hit my timezone
<PotentialUser-72>typo
<PotentialUser-72>guix system init is now running....
<lfam>Okay
<PotentialUser-72>24 hours to install on OS is not quite a record for me ;)
<lfam>In general, my advice is that you should not run `guix pull` until after the system is successfully initialized. `guix pull` will make you use the very latest development version of Guix, and we won't have tested the installation process rigorously
<PotentialUser-72>I only did that because the reconfigure step warned about not doing that.
<lfam>It's also normal that the version of Guix you might notice is older than the version number advertised as the latest release. Guix can only contain an older version of itself
<PotentialUser-72>I belieive I got the reconfigure step from looking at bug reports when I was trying to work out whythe init build was failing
<lfam>Alright
<PotentialUser-72>that was before I worked out the guix servers were down
<lfam>That's a pain
<PotentialUser-72>Still better than some of the early bewolf cluster install scripts
<PotentialUser-72>Its progress when NA servers have drifted to the bottom of your checklist
<PotentialUser-72>Thinking ahead: is there a guix command that cleans out old builds and any residuals?
<PotentialUser-72>Lookin at a grub .conf it had some cruft from the failing init and reconfigure.
<lfam>PotentialUser-72: Old or failed builds don't affect anything in Guix, *maybe* barring trying to install the bootloader
<PotentialUser-72>Hmm, it looks like this init is redownloading all the packages - I won't have some stale cache fro the backeard stepping guix?
<PotentialUser-72>\/backeard\/backward
<lfam>There is no "backwards stepping guix"
<lfam>It will only download things that it doesn't already have
<PotentialUser-72>So the package down loads I saw?
<lfam>Those are things it needed that it didn't already have
<lfam>Like I said previously, "It's also normal that the version of Guix you might notice is older than the version number advertised as the latest release. Guix can only contain an older version of itself"
<PotentialUser-72>yup that is what had me puzzled - I got 1.1.0rc2 then 1.0.1-15
<lfam>My recommendation is to make a copy of your config.scm on a USB stick, and then reboot and start the process over from scratch
<lfam>If you ran `guix pull` or `guix system reconfigure`, then you are in uncharted experts-only territory for initializing a new Guix System
<PotentialUser-72>Yeah I'll see how far this init goes.
<PotentialUser-72>still downloading packages.
<lfam>If the installation succeeds and you reboot successfully, then it's fine
<PotentialUser-72>finger crossed.
<PotentialUser-72>Thanks again for the help.
<lfam>But, it sounds like you did something wrong and ended up downgrading the installer, so who knows
<lfam>I'm still not sure in what context you would see a version number, so hard to be sure
<PotentialUser-72>see the version number when 'downloading from' message appears
<lfam>Right
<lfam>I recommend not looking closely at that stuff
<PotentialUser-72>Hmm too old to do that :)
<mbakke>PotentialUser-72: that GRUB error can happen if you use grub-efi-bootloader, but have booted in "legacy" BIOS mode
***catonano_ is now known as catonano
<PotentialUser-72>mbakke: thanks for the tip. Solution is to reboot and restart the config? Thinking about it sounds like reconfiguring to a different boot type is a catch-22?
<srandom>May 19 00:14:32 localhost gdm: GdmLocalDisplayFactory: Failed to issue method call: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.login1 was not provided by any .service files
<srandom>I configuration the gdm-service-type on my chromebook but it start failed.
<xelxebar>srandom: login1? Not just "login"? Perhaps there's a typo in your configuration?
<srandom>no, I have not any 'login1' in my config.scm
<apteryx>weird; the following always run out of build users: ./pre-inst-env guix build emacs-magit-todos@1.4.1 emacs-orgit@1.5.3 emacs-repo@0.1.3 emacs-magit-annex@1.7.1-1.ef5dce6 emacs-forge@0.1.0-3.63cbf81 emacs-magit-svn@2.2.1-2.9e33cee emacs-treemacs-extra@2.6 emacs-magit-gerrit@0.3-1.ece6f36 emacs-magit-org-todos-el@0.1.1-1.df20628 emacs-vdiff-magit@0.3.2-8.b100d12 emacs-evil-magit@0.4.2-3.4b66a1d
<apteryx>--check -M2
<apteryx>-> guix build: error: all build users are currently in use; consider creating additional users and adding them to the `guixbuild' group
<reepca>okay folks, I have a rather unorthodox question: can one program wrap the main() of another program?
<jsoo>reepca: you can use wrap-program or wrap-script if you need to modify environment variables or somehow wrap the program in some way
<reepca>jsoo: ah, but that's not what I need. I need to shove some code in front of another program's code *without* an execve in between
<reepca>for context, it's not a packaging problem I'm working on right now
<PotentialUser-72>I managed to get GuixSD installed - thanks for the help. One last question:
<PotentialUser-72>What is the 'correct' way or re-configuring?
<PotentialUser-72>reading the docs it actually sounds like:
<PotentialUser-72>sudo -i guix pull
<PotentialUser-72>sudo -i guix system reconfigure /etc/config.scm
<PotentialUser-72>\/or/for
<reepca>I do sudo -E guix system reconfigure /etc/config.scm
<reepca>that way I only have to pull for my user
<PotentialUser-72>reepa: Without `sudo -E guix pull` beforehand?
<jsoo>reepca: hmm maybe a patch is what you need
<reepca>'sudo -E guix pull' does the same thing as 'guix pull' except it might mess up the permissions on some stuff in your home directory
<reepca>I think, anyway
<reepca>you 'guix pull' to update your user's guix, you 'sudo -i guix pull' to update root's guix
<PotentialUser-72>reepca: OK so `guix system reconfigure` has `guix pull` within it or some such equivalent?
<reepca>PotentialUser-72: no, it doesn't.
<reepca>the full process for updating my system would look like:
<reepca>guix pull
<reepca>sudo -E guix system reconfigure /etc/config.scm
<PotentialUser-72>reepca: OK now I'm confused. Thinking....
<reepca>-E tells sudo to leave the environment variables as-is. This means when it searches for 'guix', it finds it in the current PATH - meaning it finds *your user's guix*.
<PotentialUser-72>reepca: That will rebuild bootloader changes etc ?
<reepca>the reconfigure command will, yes
<PotentialUser-72>reepca: Curious why the docs say to use `sudo -i ...`?
<rain>could someone explain why this package doesn't show up in a search? http://paste.debian.net/1147575/
<reepca>PotentialUser-72: where are you seeing that? I only see it in section 3.7 "After System Installation", where it says to use that only if you want to run root's guix.
<rain>it evaluates to a package, it's public, there are no errors, so...
<PotentialUser-72>reepca: Correct. It didn't make sense to me to `reconfigure` what another user (root) had installed, so I was puzled. Hence the question.
<reepca>rain: gcc-4.7.4, which the other gcc's all inherit from, uses hidden-package to add a property that marks it hidden
<reepca>since your package inherits from it, it also inherits that hidden flag
<rain>oh. thanks.
<reepca>to change it you can just write (properties '())
<PotentialUser-72>reepca: Thanks. giving your workflow a spin with some bootloader changes ;)
<PotentialUser-72>guix pull -> HTTP 502
<reepca>ah yes, savannah has been having some issues lately I've heard
<PotentialUser-72>anyone else seeing that? I had this most of last night.
<PotentialUser-72>What? This isn't running off some HA setup?
<reepca>HA?
<PotentialUser-72>Are there mirror that are more robust?
<PotentialUser-72>High-Availability
<reepca>ah
<reepca>probably, but I haven't checked into it
<PotentialUser-72>Googling now this is a deal breaker if things are this brittle.
<PotentialUser-72>Just my recent experience two outages in < two days
<reepca>to be fair, you got the worst two days in recent history.
<PotentialUser-72>Understood, I was circulating around the bewolf cluster setup days - but the world has moved on and there is no resons for flaky setups any more.
<PotentialUser-72>Anyone know anything about the github guix mirror?
<PotentialUser-72>github.com/guix-mirror/guix
<PotentialUser-72>It seems semi-official sounding, repo content is recent +6hours, but the relases page seems to lag - but that isn't critical right now.
<reepca>¯\_(ツ)_/¯ haven't had to look into it before
<reepca>and I should go to sleep
<PotentialUser-72>reepca: Thanks again for your help.
<reepca>good luck with pulling! Hopefully the savannah mess gets sorted out soon, and this motivates all of us to build more reliable infrastructure
*reepca --> zzz
<badair>The github mirror diff is 2217 lines difference between my few days old checkout from savannah, FWIW
<PotentialUser-72>badair: they are 2217 lines behind or ahead
<PotentialUser-72>badair: still getting my mind around Guix. The github repo isn't the packages is it?
<badair>The latest is from 17 hours ago. Seems legit, but idk (I'm new). Could have a bitcoin miner for all I know
<boeg>So as I understand it, I cannot use LVM with guix for my drive, so I have to use LUKS directly on e.g. ext4. But how do I go about swap then? I cannot create another partition for it, because then the swapped memory wont be encrypted. Is the only possibility to use a swap file inside the ext4 drive?
<boeg>yes, it seems like that is the way to do it as far as I understand the manual
***dingenskirchen1 is now known as dingenskirchen
<PotentialUser-72>boeg: reding the install notes during an installation it seemed to say the swap was encrypted.
<PotentialUser-72>Anyone know what 'extraneous field initalizers (timeout)" means? DuckDuckGO returns empty set.
<leoprikler>timeout is probably not a field of your record
<PotentialUser-72>douh I didn't see that :)
<boeg>PotentialUser-72: if you create a swapfile inside the encrypted drive, then its encrypted, but since you cannot use LVM, you cannot have a swap partition thats encrypted, as far as I udnerstand it
<PotentialUser-72>Been a long 24 hours
<PotentialUser-72>boeg: yes. sorry I thought you were asking about the first.
<boeg>PotentialUser-72: no problem :)
<efraim>you could use zram to use compressed ram for swap
<efraim>there's no service for it yet but I have a working set of services that make it work on my machine™
<sirmacik>hey guix
<ArneBab>To whoever packaged ripgrep: THANK YOU! I tried but did not get it finished, and this will make my life A LOT easier.
<ssb>hi! do I understand correctly that /boot/grub/grub.cfg is just a copy of the corresponding /gnu/store/*-grub.cfg and is not 'registered' anywhere ?
<civodul>hi!
<civodul>ssb: yes
<civodul>what do you mean by "registered" though?
<civodul>nckx: should we kick ArneBab until they've figured out what's wrong?
<janneke>civodul: maybe they (ArneBab) haven't noticed?
*janneke suggests a polite kick
<ssb>civodul, thanks! I meant if that file referenced in some database (/guix/var/guix/db/db.sqlite or via some symlink). Completely not sure if that makes sense, just started to learn guix
<olivuser>hello guix
***ChanServ sets mode: +o civodul
<olivuser>where can I configure the desktop environments that are available on login? I want there to be less available than currently are. If I undertstand correctly, I need to find xorg.conf, but I was unable to
***ArneBab was kicked by civodul (Kicked by civodul)
<civodul>janneke: i PM'd them and did a "polite kick" :-)
<mbakke>poor ArneBab, kicked just for using ripgrep (I think my IRC proxy misses some crucial details :P)
*civodul .oO what does ripgrep have to do with that?
<mbakke>olivuser: just remove the window manager/desktop services from your config.scm and reconfigure
<olivuser>mbakke, yeah I see where you are going, I tried that
<mbakke>civodul: I see the same as logs: http://logs.guix.gnu.org/guix/2020-05-19.log
<mbakke>ArneBab joins, expresses his thanks for the ripgrep packager, and gets kicked :P
<olivuser>but I want to be able to use LXQt which needs a window manager. I use openbox. Now when I use openbox, it also specifies things like KDE/Openbox or GNOME/Openbox on login, which I dont need
<civodul>there are examples in https://guix.gnu.org/manual/en/html_node/Using-the-Configuration-System.html that might be useful
<civodul>mbakke: oh ArneBab was present earlier today?
<efraim>IIRC those are listed as xsession options from openbox
<sirmacik>olivuser: it comes to mind that you can overwrite that behaviour by writing your own .xsession file
<efraim>about 25 minutes ago
<ennoausberlin>Hello, I installed a server running guix sd. I want to use it mainly for development, but from time to time I have to test GUI applications. How can I enable X11 forwarding?
<ennoausberlin>Normal ssh access works like a charm
<mbakke>civodul: joined 11:13 from my view
<janneke>mbakke: *lol*, that's one way to look at it
<olivuser>sirmacik, thanks, that exaclty what I needed :)
<sirmacik>(:
<ennoausberlin>Also the package texlive-union is missing. Some other packages fail to build due to this, e.g. python-matplotlib-documentation
<rekado_>what do you mean by “texlive-union is missing”? texlive-union is not one package.
<ArneBab_>civodul: I’m searching for the problem; somehow quassel cannot keep the connection to freenode stable.
<mbakke>ennoausberlin: see the documentation for openssh-service-type, you need to add (x11-forwarding? #t)
<ennoausberlin>mbakke: That might work. For now I edited only my users .ssh/config to set all options needed. Thank you. I will try it
<ennoausberlin>rekado: I want to install chez-web and it complains about texlive-union
<rekado_>ennoausberlin: can you give us the full error message please?
<ennoausberlin> reza[m]:
<boeg>On a personal machine, after I install the setup and set a password on my user account with `passwd`, should I set a root password, or simply lock it so it cannot be used?
<boeg>any suggestions?
<boeg>install guix*
<ennoausberlin>rekado_:
<ennoausberlin>~ λ guix package -i chez-web
<ennoausberlin>The following package will be installed:
<ennoausberlin> chez-web 2.0-1.5fd177f
<ennoausberlin>
<ennoausberlin>The following derivations will be built:
<ennoausberlin> /gnu/store/q01ycb5963ziq0qlpxyj8f7y2fkgqr68-chez-web-2.0-1.5fd177f.drv
<ennoausberlin> /gnu/store/rp4bvh94ap55gx69kf850g3dmp5w885y-texlive-union-51265.drv
<ennoausberlin>building /gnu/store/rp4bvh94ap55gx69kf850g3dmp5w885y-texlive-union-51265.drv...
<ennoausberlin>\builder for `/gnu/store/rp4bvh94ap55gx69kf850g3dmp5w885y-texlive-union-51265.drv' failed with exit code 1
<boeg>im thinking i can use sudo with my user to do root stuff, so simply locking the root account with `passwd -l root` seems to be a good option
<ennoausberlin>build of /gnu/store/rp4bvh94ap55gx69kf850g3dmp5w885y-texlive-union-51265.drv failed
<ennoausberlin>View build log at '/var/log/guix/drvs/rp/4bvh94ap55gx69kf850g3dmp5w885y-texlive-union-51265.drv.bz2'.
<ennoausberlin>cannot build derivation `/gnu/store/q01ycb5963ziq0qlpxyj8f7y2fkgqr68-chez-web-2.0-1.5fd177f.drv': 1 dependencies couldn't be built
<ennoausberlin>guix package: error: build of `/gnu/store/q01ycb5963ziq0qlpxyj8f7y2fkgqr68-chez-web-2.0-1.5fd177f.drv' failed
<boeg>ennoausberlin: use a pastebin
<ennoausberlin>boeg: You are right
<rekado_>ennoausberlin: this only tells us that texlive-union failed to build, not that it cannot be found
<rekado_>what does the log say?
<ennoausberlin>rekado_: The output is more than 700 lines. I have to reactivate my pastebin account first
<rekado_>ennoausberlin: don’t paste all of it
<rekado_>we just need to understand what’s going on
<rekado_>FYI: today there may be a short network outage as we replace cables in the data centre, so ci.guix.gnu.org might not be available for a few minutes.
<civodul>thanks for letting us know!
***jonsger1 is now known as jonsger
<ennoausberlin>rekado_: Here is the output of the chez-web fail https://pastebin.com/WA8RSxf1
<rekado_>the relevant error seems to be: updmap: can't write lines to >/gnu/store/q0vpljzsbrd3930dry3d2mhrf6by6v0q-texlive-union-51265/share/texmf-dist/fonts/map/pdftex/updmap//pdftex_ndl14.map: Permission denied at /gnu/store/g358kjbvcm4y0bndfb1qb1hxgiz3zm05-texlive-bin-20190410/share/texmf-dist/scripts/texlive/updmap.pl line 533.
<rekado_>this seems to be a regression in the newer texlive; the texlive-union procedure would need to be adjusted to make all files writable
<rekado_>it could also be a problem with just one of the texlive-* packages that are part of the union
<rekado_>so perhaps we can avoid a big rebuild and just fix that one package
<rekado_>can you tell us what readlink -f /gnu/store/q0vpljzsbrd3930dry3d2mhrf6by6v0q-texlive-union-51265/share/texmf-dist/fonts/map/pdftex/updmap//pdftex_ndl14.map says?
<nikita`>so I decided to go through my backlog of stuff I wanted to upstream for ~2 years. is the audacious patch done? I packaged both audacious and audacious-plugins in 2018
<nikita`>#37329 by Kei
<ennoausberlin>rekado_: readlink gives /gnu/store/522gvdar50vmskfd8jaam7av6r3nxish-texlive-generic-pdftex-51265/share/texmf-dist/fonts/map/pdftex/updmap/pdftex_ndl14.map
<r-7>Hello. I’ve been having some font problems in GuixSD: lots of numbered squares in GUI programs. Adding font packages to config.scm somehow worsened the problem, and now dmenu is unusable. I’ve several fonts installed via “guix install,” and I’ve tried sudo fc-cache -rv, which doesn’t help, so I’m out of ideas. Is there a resource or some kind of wiki page for these issues?
<rekado_>ennoausberlin: excellent. This is one of the old-style packages, and I assume that the file is read-only.
<rekado_>r-7: there are a few open bug reports about this on issues.guix.gnu.org
<wingo>r-7: a recent guix-devel post https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00281.html
<wingo>this is also something i find to be mysterious, fwiw
<rekado_>r-7: it’s a recent regression, and while people say that installing this or that font “fixes” it, there’s no good solution yet
***amiloradovsky1 is now known as amiloradovsky
<PotentialUser-72>How do people manage their 'dot' files? In Chef I use files and templates to populate my 'dot files (and others).
<nikita`>git and bmake
<nikita`>and basically just symlink forcing
<nikita`>I switch a lot between different OS, and that's most portable for me
<srandom>How to use swapfile in GuixSD?
<rekado_>srandom: see the manual section 8.2 ‘operating-system’ Reference
<srandom>Thanks, I have been looking for them in the file-system and services documentation. Ignore this section
<ennoausberlin>PotentialUser-72: There was an article from Alex Pearce using GNU stow to manage your dotfiles. I do not have a link but google will find it
<rekado_>srandom: the manual has a curated index, which includes “swap devices”
<rekado_>you can access the index in your Info reader with “i”
<r-7> rekado: Thank you for the reply. I’d try installing the fonts suggested, but I have a new, possibly related problem, here while installing font-dejavu --> guix install: error: error parsing derivation `/gnu/store/lvzpkcl59nrikb0bsqls38kkmswsd8hd-cups-minimal-2.3.3.drv': expected string `Derive(['
<r-7>I’ve also had that error with other attempted installs and with guix pull and package -u
<srandom>thanks
<rekado_>r-7: that’s disk corruption
<rekado_>the file is probably empty
<rekado_>and it shouldn’t be
<PotentialUser-72>ennoausberlin: Thanks I'll hunt it down
<r-7>rekado: Is there anything short of reinstalling that would fix that?
<civodul>r-7: can you try "guix gc -D /gnu/store/lvzpkcl59nrikb0bsqls38kkmswsd8hd-cups-minimal-2.3.3.drv"?
<r-7>civodul: Giving that a try
<olivuser>hello guix. so I asked how to limit the choices of WMs in the login manager and was supplied with some information, specifically regarding an xsession file
<olivuser>now I tried to do some research on my own but found I couldnt find anything useful, because it was mostly some 'exec <WM OF CHOICE>', while what I am looking for is providing options which should be available upon login
<olivuser>thus, is there a resource that helps building an xsession file for a choice of several wm/de's?
<mroh>PotentialUser-72: I use vcsh for my dot files (https://github.com/RichiH/vcsh)
<rekado_>olivuser: the display managers should all support .desktop files, so if you’ve got them for each window manager / DE it should display them.
*nikita` begins to think she got unsubscribed from guix-patches@ but still receives emails
<nikita`>strange..
<nikita`>does guix-patches do this sometimes?
<nikita`>i tried to get an password reminder, but so far nothing, and i still receive emails people send to it
***jonsger1 is now known as jonsger
<nikita`>oh, i found the unsubscribe email.
<PotentialUser-72>mroh: thanks I'll look at that too. I assume you define these sources and how to apply/use them in the /etc/config.scm
<nikita`>i can't even subscribe again. obviously i can send emails and my email host is okay (idk why it got unsubscribed for too many bounces). can someone look into this in the mailman admin?
<r-7>civodul: guix gc -D worked, but it turns out I have the same corruption elsewhere. Now trying guix gc followed by pull and package -u, it seems like I’m effectively reinstalling everything, but at least it’s automated
<rekado_>r-7: there’s a “guix gc” option to verify and repair the store
<nikita`>got an email
<rekado_>guix gc --verify=repair,contents
<olivuser>rekado_, thanks but I want some to NOT be displayed
<rekado_>oh
<mroh>PotentialUser-72: no, i have vcsh in my user manifest. for most packages it is much more flexible to have them in user profiles, not the system profile.
<lprndn>Hey rekado! any news for lightdm? I can take on some work to ease your burden if you need to.
<rekado_>lprndn: sorry, I didn’t manage to make much progress :(
<rekado_>it’s near the top of my TODO list, though
<rekado_>sorry for the delay!
<nikita`>so, sorry for the last 2 or 3 patches to the list without being subscribed, I had no idea mailman unsubscribed me
<rekado_>lprndn: I’d like to finish replacing the lightdm-gtk-greeter string with the actual package
<rekado_>and then test it again
<rekado_>everything else can be addressed in later commits; I don’t want to hold this up much longer
<olivuser>rekado_, any idea where I could start digging? I mean xsession has kinda failed me, and my "last resort" is like altering the login manager configuration (slim)
<r-7>rekado_: That seems like a more elegant solution, but the dumb way also worked
<lprndn>rekado: Ok, don't worry, I now you're busy and there is no need to hurry ;) I'm just checking if everything's ok. :)
<lprndn>sneek: later tell olivuser: Maybe you can create a custom package with the .desktop files and declare the wms you need as inputs? Something like that...
<sneek>Okay.
<pkill9>it would be neat to have a URL specified for where to post issues for packages, so you could just run a command to post an issue
<mothacehe> janneke: With this patch on top of your branch: https://paste.debian.net/1147629/, I'm able to generate an EFI disk-image.
<mothacehe>That I start with this command: qemu-system-i386 -enable-kvm -bios $(guix build ovmf)/share/firmware/ovmf_ia32.bin -hda /tmp/qemu-image -m 1024
<mothacehe>janneke: Sadly, just after Grub, the virtual machine restarts, nothing is printed.
<rekado_>pkill9: maybe we should add this to mumi / issues.guix.gnu.org
<rekado_>pkill9: details matter, though. How exactly should this work?
<janneke>mothacehe: that's beautiful...i'm having a look
<pkill9>rekado_: I was thinking you'd have a field in the package definition for issues, like you do for the home-page, e.g. (issues-page "https://github.com/teeworlds/teeworlds/issues"), then you could have a guix command, or an external tool, that submits an issue
<pkill9>really in general just more package metadata would be neat, so you could do things like that
<pkill9>maybe an entire new record for upstream URLs
<pkill9>im just throwing ideas out
<janneke>mothacehe: terriffic work on the mes bootstrap, btw!
<rekado_>oh, I thought for issues.guix.gnu.org
<rekado_>because we should be the first point of contact
<rekado_>in case our packaging introduced problems
<rekado_>you don’t want to flood the authors with distro-specific problems
<mothacehe>janneke: thanks :) The painful part will be to define both stat and stat64 structures for i686 and x86_64, I'll try to do that later on!
<janneke>mothacehe: i wanted to ask you that -- no hurry -- if you'd like to create a full patch
<janneke>(i'll do so on the list too :-)
<janneke>mothacehe: i'm especially happy that you followed through and make it a bit better understandable
<janneke>mothacehe: oh wow, a cursor and instant reboot
<mothacehe>janneke: ok :) I think I found at least two reasons why my Hurd image won't boot. I'm mising the "-o hurd" flag passed to mkfs.ext2, and I'm not calling make-hurd-device-nodes!
<janneke>mothacehe: yeah, it's kinda "supposed" not to work without those ;-)
<mothacehe>janneke: oh, sad :(
<janneke>it took me a while to start seeing such details
<janneke>so, you may be close!
*janneke was trying a joke, looking good mothacehe!
<rekado_>FYI: we temporarily replace the patched connection with a direct cable to the core switch and we now have 10G
<rekado_>but download speed is unchanged
<rekado_>we’re still trying to diagnose at which point the connection drops to 1G to replace that part permanently
<janneke>so, the bottleneck is possibly elsewhere?
<rekado_>but in the meantime it would be good to check what limits our speed
<mothacehe>janneke: haha ok, then there's hope :p Have to go, I'll keep trying later!
<rekado_>yeah, I’d suggest bypassing nginx for a test
<rekado_>see if that makes any difference
<rekado_>I worry it might be the firewall…
<olivuser>hello guix
<sneek>olivuser, you have 1 message!
<sneek>olivuser, lprndn says: Maybe you can create a custom package with the .desktop files and declare the wms you need as inputs? Something like that...
<olivuser>lprndn, will test that, but it is currently beyond my capacities
<olivuser>is there any way, in xsession or xinitrc, to select ONLY A SUBSET of the total available sessions to be displayed by the login manager?
<olivuser>Because as far as I understand it, for xinitrc or xsession to be able to do that, I need to modify a file in the store which doesnt work
<olivuser>and then there's only the solutions with a custom package
<rekado_>I get 111MB/s with “cat /dev/zero | pv -r | nc ci.guix.gnu.org 873”
<rekado_>I started a plain netcat server on that port
<rekado_>that’s faster than what I get with “guix install”
<rekado_>obviously, this is now limited by my laptop’s 1G port
<rekado_>1 min downtime for ci.guix.gnu.org
<civodul>rekado_: is now a good time to test?
<rekado_>ci.guix.gnu.org is back now
<rekado_>so… this is weird
<rekado_>we switched back to the patched cable that we used before and the card renegotiated a 10G connection
<rekado_>so we didn’t screw up the cabling
<rekado_>could be that there was a temporary problem and the card negotiated down to 1G
<rekado_>and never realized it could go up to 10G again
<reepca>so it turns out wrapping another program's main() is infeasible. I'd be better off just using libguile to throw together something that can be "close enough" to guile for our purposes
<rekado_> civodul: could you test the command above?
<rekado_>I tried to run it on another server here, but the firewall won’t let me
<boeg>I have a bash script right now that uses curl, parted, wipefs, cryptsetup, mkfs.ext4, mount, dd, chmod, mkswap, swapon, and some other utilities and then calls upon herd start cow-store, guix pull and then finally guix system init to prepare the disks and spin up a device with guix on it. Does the guix ecosystem has something made for a situation like this - like a module that exposes all those utilities to scheme so I can
<boeg>do it in scheme instead of bash? I know I can just do it in scheme with a bunch of (system ...) calls, but that seems to me a little weird, so i opted to not do that.
<jonsger>rekado_: which package provides nc?
<nikita`>pkill9: creating a way to automically report issues somewhere (what user? etc) just asks for ignoring issue templates and processes upstream might have and get ignored more than accepted
<lprndn>sneek: later tell ryanprior: I'm not sure how to proceed. I'm working directly on guix master so just waiting for your patches to be merged, rebasing and sending mine seems a little easier. What do you think?
<sneek>Will do.
<rekado_>jonsger: netcat
<nikita`>tbh I sometimes ignore templates when I know it's trivial what I report
<jonsger>rekado_: 3MiB/s on my server 1.5MiB/s on my laptop
<rekado_>uhm
<rekado_>that’s … low?
<rekado_>guess there should only be one person using it at a tim
<rekado_>*time
<rekado_>it’s just nc after all.
<rekado_>let’s see, I’ll try with socat and forking
<ryanprior>lprndn I have a guix fork you can add as a remote if you'd like. Hard to predict how long it will take to get my patches merged
<sneek>ryanprior, you have 1 message!
<sneek>ryanprior, lprndn says: I'm not sure how to proceed. I'm working directly on guix master so just waiting for your patches to be merged, rebasing and sending mine seems a little easier. What do you think?
<rekado_>jonsger: can you try again?
<jonsger>up to 30MBit/s on my server
<rekado_>I get between 109 and 111 MiB/s for the most part
<rekado_>now dropping to ~80
<rekado_>and back up
<jonsger>50MiB/s on my hetzner server versus 30MiB/s on the contabo one
<rekado_>I’m getting 50MiB/s now as well
<rekado_>what are your usual download speeds with Guix?
<jonsger>more something around 2MiB/s up to 8MiB/s during the night
<lprndn>ryanprior: We can try! So you can see what I did. Just please keep in mind that I fight more than use git...
<ryanprior>lprndn if you want to pair on it I'd be happy to help 😄
<rekado_>jonsger: how about wget http://ci.guix.gnu.org/.well-known/foo -O - > /dev/null
<dutchie>i don't normally get more than 1.5MiB/s downloading from guix, although i can get 2-3x that on other things
<kamil_>Question: is it normal that inferiors without substitutes are built unverbosely?
<rekado_>dutchie: can you try “cat /dev/zero | pv -r | nc ci.guix.gnu.org 873” and report what it tells you?
<dutchie>foo was coming down at 3 MiB/s just now
<jonsger>12,0MB/s on laptop, 48MB/s on contabo, 55MB/s on hetzner
<rekado_>I got 99MB/s for foo
<dutchie>~2.2 for that upload
<dutchie>MiB/s
<rekado_>dutchie: what upload?
<dutchie>cat /dev/zero | nc ci.guix.gnu.org
<rekado_>ah, ok
<civodul>rekado_: "cat /dev/zero | guix environment --ad-hoc pv -- pv -r | nc ci.guix.gnu.org 873" peaks at 19MiB/s
<rekado_>civodul: how about the foo download?
<lprndn>ryanprior: thanks. where's your guix fork?
<civodul>rekado_: between 15 and 40MB/s
<rekado_>foo is served by nginx
<civodul>so it's sendfile'd i guess
<civodul>"wget -O /dev/null https://ci.guix.gnu.org/nar/lzip/72dncmg5a2jx0lqbjhx0vml2jc45qyn6-libreoffice-6.4.2.2" is at 1.4MB/s
<civodul>so we're definitely doing something wrong
<rekado_>I’ll replace the netcat thing with woof and serve one file over 873
<rekado_>again as a control against nginx
<civodul>rekado_: but look, the 2nd time, the command above has 61MB/s
<civodul>so i think that's what i had observed a while back: on cache misses, nginx is terribly slow
<civodul>and on cache hits, it's fast
<civodul>'guix publish' can't be blamed because it does sendfile
<civodul>so i think it has to do with the size of nginx buffers when fetching stuff from 'guix publish'
<civodul>hopefully i wrote my previous findings on guix-sysadmin or guix-devel
<civodul>i remember stracing the damn thing back in the day
<cbaines>maybe increasing the proxy_buffer_size would help http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffer_size
<cbaines>Actually looks like this bit of config is more relevant http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers
<cbaines>proxy_buffers
<ryanprior>lprndn: https://github.com/ryanprior/guix/tree/add-pantheon
<civodul>cbaines: ah ha!
<civodul>i'd need to find my notes, i tried several options back then
<cbaines>I'm not quite sure what proxy_busy_buffers_size relates to
<cbaines>I'm not vouching for the content, but this page seems useful https://www.getpagespeed.com/server-setup/nginx/tuning-proxy_buffer_size-in-nginx
<lfam>More locales confusion on help-guix!
<jonsger>civodul: couldn't it be also the case that the first request triggers nginx to ask for the file from the upstream server. On the second request this file is already in a file system cache or so
<civodul>jonsger: yes, that's what happens, but still: it shouldn't be a 40x difference
<civodul>problem is that all this is hard to test
<civodul>we'd need a scratch nginx install somewhere to tune the params
<cbaines>maybe you can just copy the NGinx config, tweak the port, and test that way?
<cbaines>You might be able to reproduce the issue on the machine, which would avoid firewall issues, otherwise you could SSH forward the port
<civodul>yeah
<civodul>gpg says that nckx signs messages with (unknown algorithm 22)
<civodul>bah i couldn't find my previous findings on this topic
<janneke>sneek: later tell mothacehe, i added some stuff for the hurd, see https://paste.debian.net/1147654/, but see no result of it...still the same reboot!
<sneek>Got it.
<janneke>sneek: botsnack
<sneek>:)
<cbaines>is there any way of making the substitute: updating substitutes from messages more verbose?
<cbaines>I know something's not working regarding substitutes, and all I need to see is what it's fetching
<reepca>where should a helper program for (gnu build linux-container) go in the hierarchy?
<rekado_>civodul, cbaines we could run a second nginx on port 873
<apteryx>rekado_: did something improve w.r.t. the disk space usage on Berlin?
<rekado_>apteryx: yes, we’re now at a stable 3T free every day
<rekado_>not sure exactly what fixed it, but I think it was a bit of everything
<apteryx>OK, good to know!
<rekado_>including the ISO images was a good idea, but also adjusting the cron job
<rekado_>I haven’t had to do any manual cleanup work this week, so I’m pretty happy with it.
<rekado_>re nginx: I asked IT to open 873 on the firewall for the rsync daemon, but we could use it for some more tests.
<rekado_>before we do that, though, I think we should figure out why cache misses are expensive.
<rekado_>that’s just nginx forwarding to “guix publish”, no?
<rekado_>so let’s cut out nginx and its cache and directly connect to “guix publish”
<rekado_>will this be slow? If so: why?
<alextee[m]>im looking at the strace of running the `guix pack` thing, but i hav eno idea what all of this means or what is hould be looking for
<cbaines>rekado_, I'm not sure guix publish does TLS
<alextee[m]>i see some access("/gnu/store....font-config.../etc/fonts etc//
<alextee[m]>i guess i'll upload this and send it to the bug report
<cbaines>For the reverse proxy, I posted some config bits earlier, mostly around proxy_buffers
<rekado_>cbaines: it doesn’t have to do TLS. We can also just fetch over HTTP.
<cbaines>indeed, I just mention it as that's a difference I can think off when not going through NGinx
<rekado_>true; I’d just like to be certain that “guix publish” isn’t to blame
<cbaines>if you're on the server, could you try requesting something from NGinx, and then the same thing from guix publish?
<cbaines>Ideally something that isn't in the NGinx cache?
<rekado_>annoyingly, I don’t have a fast connection at home
<rekado_>I can’t get close to what I reported when testing in the data centre
<rekado_>we can also tell nginx to bypass the cache with a headern
<cbaines>Ah, so if you talk to NGinx from the machine, it's really quick?
<cbaines>It could be that latency is the primary thing at play
<rekado_>I haven’t tried doing any tests on the ci.guix.gnu.org server directly
<rekado_>previously I ran the netcat test while sitting in the data centre with a laptop
<rekado_>after all I was trying to measure the performance over the public network interface
<cbaines>I'd perhaps see what wget says for the speed, when running wget on berlin
<rekado_>but now that we’re just looking at nginx I could do this right on the server
<rekado_>right now I get 682MB/s for the libreoffice item
<rekado_>when running wget on ci.guix.gnu.org
<cbaines>that seems pretty good, do we know if that's coming from the NGinx cache?
<rekado_>getting the same thing from guix publish is slow!
<rekado_>1.38MB/s
<rekado_>that’s with wget -O /dev/null http://localhost:3000/nar/lzip/72dncmg5a2jx0lqbjhx0vml2jc45qyn6-libreoffice-6.4.2.2
<nckx>civodul: FYI I uncommented the Russians earlier today, thanks for taking care of that. Now what's this about my GPG key this week? 😛
<nckx>And what was ArneBab up to? It doesn't show up in my logs.
<rekado_>nckx: ArneBab was connecting and disconnecting
<nckx>Ah. Thanks.
<rekado_>strace tells me that “guix publish” is in fact using sendfile.
<rekado_>I think we shouldn’t bother playing with nginx settings. If wget + guix publish on the same host is limited to about 2MiB/s then something’s probably not right in guix publish.
<nikita`>lfam: was that an implicit question in my cwm patch if I could redraft and change the website?
*nikita` stuck between imrpvoing languages, preping for job interviews, gsoc and life.. sorry for not reading everything the right way immediately right now
<lfam>I'll handle it soon nikita`
<nikita`>ah, thanks :)
<nikita`>if I get one of the jobs I'm rooting for it involves writing more Nim. I did have some nim-build-system outside of guix ~2 years back, it worked, but ran into the same issue I ran into with pkgsrc - there is no concensus on how system integration of packages written in Nim are handled. Do you want me to write a post to the mailinglist before someone else looks into this and runs into similar blockers where
<nikita`>the only way forward is to join 3 other package manager developers/contributors in figuring out the best way forward?
<nikita`>I'd essentially re-post from a blog post of mine I want to write or extend on it
<nikita`>it's a bit sad how many packages I had let bitrot because I needed some time away
<lfam>It happens
***sputny1 is now known as sputny
<apteryx>how long is the openjdk bootstrap process? it's currently at openjdk@12, running a pretty lengthy test suite
<rekado_>it goes to 14
<apteryx>yikes :-)
<rekado_>all have slow tests
<apteryx>a single process python script...
<apteryx>anyway, I won't hold my breath, thanks for the info
***sputny1 is now known as sputny
<apteryx>if someone is interested to try a newer, faster Magit for Emacs, I've sent some patches here: https://issues.guix.info/41405
<rekado_> oh, nice!
<apteryx>I'm using it right now, it seems to work well so far
<janneke>that's also nice :-P
<ryanprior>If I want to use git in a pure guix environment, what do I have to install so I don't get "server certificate verification failed" issues?
<rekado_>you need nss-certs and the environment variables to point git to the certificates
<rekado_>GIT_SSL_CAINFO
<ryanprior>Adding nss-certs was enough thankfully. Appreciate the tip rekado_ !
<civodul>nckx: thanks for the overdrives! re gpg, i think it just doesn't recognize the hash algorithm you're using
<nckx>Algorithm 22 was added in GnuPG 2.1.0 in 2014. Are you using some weird home-brewed bindings?
<nckx>(No offence 🙂
<nckx>)
<nckx>Weird is fun.
<civodul>actually: (define PUBLIC-KEY-EDDSA 22)
<civodul>no i'm using plain gpg 2.2.20
<civodul>weird, lemme see
<civodul>this is the message you sent at 15:35 to guix-sysadmin
<nckx>Interesting.
<nckx>[[PGP Signed Part:Good signature from 0DB0FF884F556D79 Tobias Geerinckx-Rice <me@tobias.gr> (trust undefined) created at 2020-05-19T15:35:02+0200 using (unknown algorithm 22)]]
<lfam>I can verify that signature okay
<nckx>On the machine that sent & signed that exact message.
<nckx>Oversight/bug in the printing only? Dunno.
<lfam>Only with PGP would you get "Good signature" and "unknown algorithm" at the same time
<nckx>I was thinking something very similar 😃
<lfam>Mutt's GPG integration doesn't say "unknown algorithm" fwiw
<nckx>I'm using mu4e, I assume civodul uses something emacs-based too.
<civodul>nckx: 22 is presumably a "signature subpacket", "Preferred Compression Algorithms"
<civodul> https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-06#section-5.2.3.1
<civodul>(guix openpgp) chokes on it
<nckx>Hmkay.
<nckx>civodul: Does it break something Guix?
<reepca>w00t. Have a working helper program based on libguile that runs guile in new namespaces in a single execve(), so it doesn't have to drop capabilities.
<civodul>nckx: not at all, i'm just wondering
<civodul>hey reepca
<civodul>reepca: "drop capabilities"?
<nckx> https://paste.debian.net/plain/1147723 - guix pull on dmitri. sergei is still pulling. Familiar to anyone?
<reepca>aye, by default any call to execve() will drop all linux capabilities (including those necessary for setting up a container) unless the caller is uid 0.
<nckx>civodul: Phew. So this doesn't break your new guix authentication, that's what I was worried about.
<reepca>civodul: I take it you haven't seen my email?
<civodul>reepca: ah no, so i should check mail before bothering you :-)
<civodul>sorry!
<reepca>no bother, I would have just silently wondered "hm... did he see it yet?" for a few days before mentioning it
<reepca>so really it's a net positive
<olivuser>hello guix!
<NieDzejkob>o/
<olivuser>when a package states it needs the i386 version of some packages, am I safe to take the i686 versions from guix?
<NieDzejkob>yeah, it's generally the same thing
<olivuser>okay, thanks!
<olivuser>and how do I specify those? I mean I do probably have like (input `(("gcc" ,gcc))); but is it then 'gcc:i686'?
<rekado_>made a quick test with sendfile and a simple socket server in Guile, and file transfer is very fast
<rekado_>I wonder if the Guile web server framework does something that hurts performance
<civodul>rekado_: that's weird, if you "strace -f" guix publish, you should see that it just calls sendfile
<reepca>is said framework using fibers?
<lfam>olivuser: I think you would limit the package to only be i686 by using the supported-systems procedure
<civodul>reepca: 'guix publish' doesn't
<rekado_>civodul: yes, that’s strange indeed
<olivuser>lfam, thanks :)
<rekado_>here’s my test server: https://paste.ubuntu.com/p/bzH3BQnfWR/
<rekado_>and I just run time nc localhost 2904 >/tmp/foobar
<lfam>That would be my approach anyways
<NieDzejkob>olivuser: you could use cross-gcc, too
<civodul>rekado_: if you strace it, it does call sendfile(2), right?
<olivuser>NieDzejkob, thanks but I think for now lfams approach sounds easier (a learning noob here o/ )
<rekado_>civodul: yes
<rekado_>the guix publish strace looks optimal
<civodul>good
<civodul>so the slow local wget is weird
<civodul>sendfile OK: https://paste.debian.net/1147727/
<civodul>hmm
<rekado_>I’m looking into socket options now
<rekado_>replacing http-read
<civodul>TCP_MAXSEG or some other obscure thing?
<rekado_>woah
<rekado_>I increased SO_SNDBUF and it’s super fast
<rekado_>set it to (* 128 1024)
<rekado_>default in (web server http) is (* 12 1024)
<apteryx>rekado_: nice find :-)
<rekado_>with 128 I get 1.55 GB/s
<civodul>woohoo!
<civodul>woow
<rekado_>so… what to do?
<civodul>that!
<civodul>:-)
<rekado_>hah
<civodul>in (guix scripts publish) i guess
<rekado_>in Guile that’s not configurable
<apteryx>submit a patch to change the default in Guile?
<rekado_>so we’d have to carry our own implementation of http-read
<civodul>really?
<civodul>can't we just do that right before sendfile?
<rekado_>I did try that and it would be reset
<rekado_>in strace I see my call to set the buffer settings and then a little later Guile is lowering it
<civodul>on the same socket?
<NieDzejkob>mbakke: I'm trying to apply #40283 following the c-u merge, but I'm still getting various errors from the NTL headers. Some of them mention that features are only available with -std=c++11 or newer, while flint compiles with -ansi which is equivalent to -std=c++98. Is the C++ version supposed to be handled differently for system headers too?
<NieDzejkob>(other distros seem to build it with -ansi without problems)
<rekado_>I’ll play with this some more to see if there’s a good place where we can sneak this in
<civodul>in guix publish, in http-write, right before sendfile, i think Guile won't touch it
<civodul>anyway, good catch!
<reepca>should a helper binary go in ${bindir}/ or ${libexecdir}/?
<rekado_>it’s a different socket, sorry
<rekado_>my bad
<NieDzejkob>reepca: if it has no business being in $PATH, go with libexecdir
<olivuser>can someone tell me what (_ "") means? Is it possible to say something about this as syntax independent of its context?
<NieDzejkob>is it in some macro?
<NieDzejkob>why wouldn't you provide context -_-
<rekado_>it worked
<rekado_>will push a fix
<civodul>yay!
<civodul>i don't know if the default in (web http) should be changed, but at least it could be made configurable
*civodul feels ashamed for putting the blame on nginx
<civodul>a beginner's mistake: "yeah, it must be the kernel or gcc or nginx, certainly not my code"
<slyfox>(or hardware!)
<janneke>we all learn and grow, civodul; be happy \o/
*rekado_ reconfigures ci.guix.gnu.org
<reepca>the expert blame-deflector would simply claim that it's guile's fault for not providing a "better" default
<olivuser>NieDzejkob, https://paste.debian.net/1147728/
<civodul>rekado_: wait, we need to update the "guix" package...
<rekado_>oh, right
<NieDzejkob>olivuser: oh, in a match, that's the "else" branch
<NieDzejkob>_ is basically used as a throwaway variable name here
<civodul>rekado_: or you can try running "guix time-machine -- publish ..." to double-check
<civodul>reepca: i don't know if it's a bad default, i guess it depends on the application?
<civodul>dunno
<olivuser>NieDzejkob, thus I dont need it if I dont do a match?
<reepca>and that's why you're not an expert blame-deflector ;-)
<civodul>:-)
<civodul>anyway, that was a fun story
<NieDzejkob>olivuser: You could say it's inherently a part of match's syntax...
<NieDzejkob>try it and find out
<civodul>i made a significant contribution to making everyone grumpy for years :-)
<janneke>without trying, even!
<civodul>yup!
<olivuser>NieDzejkob, thanks :-)
<rekado_>civodul: running guix time-machine (for the first time) now
<rekado_>now that the nginx cache is no longer all that important we could also reduce its size
<rekado_>oh, it’s only 40G
<civodul>maybe we could get rid of it
<civodul>we removed the cache for narinfos
<civodul>well, publish creates threads without any upper limit, so we'd still need to ensure nginx sets a limit
<rekado_>I’m seeing “Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...” without any more output
<civodul>or fix publish :-)
<apteryx>civodul: I'd err toward a bad default, given the performance boost is phenomenal :-)
<rekado_>would be nice to have some progress bar there.
<civodul>+1
<rekado_>apteryx: I think the default might be okay for serving small files quickly
<civodul>yeah
<rekado_>there’s a comment right above it that says:
<rekado_>;; From "HOP, A Fast Server for the Diffuse Web", Serrano.
<civodul>woow
<civodul>memories
*rekado_ opens a wishlist bug about the progress bar
<apteryx>perhaps true 30 years ago
<apteryx>:-P
*apteryx is exagerating
<civodul>heheh
<mbakke>NieDzejkob: oh, I had read the error message wrong, -fpermissive is different from -Werror, sorry for the confusion
<NieDzejkob>:(
<NieDzejkob>I've substituted -ansi out and now it's running the test suite, but this feels wrooong...
<rekado_>the new “guix publish” is now running
<rekado_>tests welcome
<rekado_>BTW there’s a good chance we can further improve this
<rekado_>I just picked (* 128 1024) arbitrarily
<rekado_>there might be a better buffer size
<rekado_>maybe the average size of a substitute, or something like that
<rekado_>we should also set TCP_CORK according to the sendfile man page
*rekado_ –> zzzZ
<mbakke>NieDzejkob: reading the flint configure script, it adds -ansi (and more) only if CFLAGS is not already set, I guess Arch sets CFLAGS by default
<jonsger>rekado_: tbh, I don't see any faster downloads something around 3MB/s
***atw` is now known as atw
<atw>this patch is pretty old but the latest should be mergeable, so I'm just gonna bump it: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36751