<PotentialUser-72>Still trying to install GuixSD and now when I do guix pull; guix system reconfigure; the guix package version is stepping **backwards** <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` <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 <lfam>Can you clarify your question? <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 <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>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>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 <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 <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? <lfam>There is no "backwards stepping guix" <lfam>It will only download things that it doesn't already have <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" <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 <lfam>If the installation succeeds and you reboot successfully, then it's fine <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 <lfam>I recommend not looking closely at that stuff <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>-> 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: <reepca>I do sudo -E guix system reconfigure /etc/config.scm <reepca>that way I only have to pull for my user <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>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>sudo -E guix system reconfigure /etc/config.scm <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*. <reepca>the reconfigure command will, yes <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 <reepca>to change it you can just write (properties '()) <PotentialUser-72>reepca: Thanks. giving your workflow a spin with some bootloader changes ;) <reepca>ah yes, savannah has been having some issues lately I've heard <reepca>probably, but I haven't checked into it <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>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>good luck with pulling! Hopefully the savannah mess gets sorted out soon, and this motivates all of us to build more reliable infrastructure <badair>The github mirror diff is 2217 lines difference between my few days old checkout from savannah, FWIW <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. <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 <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ā¢ <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>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 ***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>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>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 <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? <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 :) <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? <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? <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 <rekado_>ennoausberlin: this only tells us that texlive-union failed to build, not that it cannot be found <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. ***jonsger1 is now known as jonsger
<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 <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>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`>I switch a lot between different OS, and that's most portable for me <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 <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? <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`>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
<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 <olivuser>rekado_, thanks but I want some to NOT be displayed <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 <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_>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... <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>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 <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>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 ;-) <janneke>it took me a while to start seeing such details *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_>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 <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 <civodul>rekado_: is now a good time to test? <rekado_>we switched back to the patched cable that we used before and the card renegotiated a 10G connection <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. <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? <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_>guess there should only be one person using it at a tim <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_>I get between 109 and 111 MiB/s for the most part <jonsger>50MiB/s on my hetzner server versus 30MiB/s on the contabo one <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 š <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 <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>so we're definitely doing something wrong <rekado_>Iāll replace the netcat thing with woof and serve one file over 873 <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>'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 <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 <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>gpg says that nckx signs messages with (unknown algorithm 22) <civodul>bah i couldn't find my previous findings on this topic <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 <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ā <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! <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 <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`>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 ***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 <apteryx>anyway, I won't hold my breath, thanks for the info ***sputny1 is now known as sputny
<apteryx>I'm using it right now, it seems to work well so far <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 <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? <civodul>actually: (define PUBLIC-KEY-EDDSA 22) <civodul>this is the message you sent at 15:35 to guix-sysadmin <nckx>[[PGP Signed Part:Good signature from 0DB0FF884F556D79 Tobias Geerinckx-Rice <me@saibot.rg> (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" <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 <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 :-) <reepca>no bother, I would have just silently wondered "hm... did he see it yet?" for a few days before mentioning it <olivuser>when a package states it needs the i386 version of some packages, am I safe to take the i686 versions from guix? <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 <lfam>olivuser: I think you would limit the package to only be i686 by using the supported-systems procedure <rekado_>civodul: yes, thatās strange indeed <rekado_>and I just run time nc localhost 2904 >/tmp/foobar <lfam>That would be my approach anyways <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_>the guix publish strace looks optimal <rekado_>Iām looking into socket options now <civodul>TCP_MAXSEG or some other obscure thing? <rekado_>I increased SO_SNDBUF and itās super fast <rekado_>default in (web server http) is (* 12 1024) <apteryx>submit a patch to change the default in Guile? <rekado_>so weād have to carry our own implementation of http-read <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 <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 <reepca>should a helper binary go in ${bindir}/ or ${libexecdir}/? <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? <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" <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 <civodul>rekado_: wait, we need to update the "guix" package... <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? <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 ;-) <NieDzejkob>olivuser: You could say it's inherently a part of match's syntax... <civodul>i made a significant contribution to making everyone grumpy for years :-) <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 <civodul>well, publish creates threads without any upper limit, so we'd still need to ensure nginx sets a limit <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. <rekado_>apteryx: I think the default might be okay for serving small files quickly <rekado_>thereās a comment right above it that says: <rekado_>;; From "HOP, A Fast Server for the Diffuse Web", Serrano. *rekado_ opens a wishlist bug about the progress bar <mbakke>NieDzejkob: oh, I had read the error message wrong, -fpermissive is different from -Werror, sorry for the confusion <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_>BTW thereās a good chance we can further improve this <rekado_>I just picked (* 128 1024) arbitrarily <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 <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