<vagrantc>civodul: the conference didn't have any, but cmmarusich took a recording ***luciddreamzzz is now known as ghosthunter
<tune>I thought somebody here had one they were thinking of submitting ***ghosthunter is now known as Ca5p3r669
***Ca5p3r669 is now known as ghosthunter
***ghosthunter is now known as luciddreamz
***luciddreamz is now known as ghostfinder
***LucidDreamZzZz is now known as ghostfinder
<rekado>I don’t think the imagemagick update should have been done on teh “master” branch. <rekado>sneek: later tell civodul The caches have been relocated, bind-mounted, and nginx+cuirass have been restarted. Should be okay to remove /mnt/root-fs/var/cache now. <divansantana>Hmm trying to run a foreign package (qutebrowser) on top of guixsd. The browser fails to launch with 'could not initialize GLX'. Any one have an idea why that would be? I've tried c.qt.force_software_rendering = 'software-opengl' in it's config, but that doesn't help. <efraim>I wouldn't be suprised to find that imagemagick was a stealth CVE fix <kmicu>How much data was on hydra.gnu.org that fsck couldn’t fit in RAM? <efraim>last I heard a few years ago hydra has 4GB of ram, not sure how much is on the physical machine <kmicu>Oh c’mon! 4GB RAM on build server is not a good reason to redesign the store. 😺 <kmicu>(and how did they even compile IceCat on it…) <rekado>well, we’ll see if this becomes a problem on berlin now that we have a store that could grow to 37TB. <kmicu>Thank you for the recent Berlin improvements so much rekado ʕノ•ᴥ•ʔノ ︵ λ𝛌𝚲𝝀 <sneek>Welcome back civodul, you have 2 messages. <sneek>civodul, nckx says: I still had PMs blocked from the Great Freenode Spam Wave. Your messages didn't come through, but feel free to /msg me again. <sneek>civodul, rekado says: The caches have been relocated, bind-mounted, and nginx+cuirass have been restarted. Should be okay to remove /mnt/root-fs/var/cache now. *rekado just swapped a broken disk on berlin. <rekado>could have been semi-broken on delivery and we only noticed now that we’re actually using it. <rekado>warranty is great, though. Dell sent a new disk yesterday, no questions asked. <jonsger>rekado: but the Disk itself is not from Dell or? <civodul>rekado: excellent, we're already taking advantage of RAID :-) <rekado>jonsger: it’s a Dell-branded disk (and with a “Certified by Dell” label), but manufactured by HGST, which is Western Digital AFAIK. <rekado>civodul: yeah, we’ve been running off one of the hot spares, which was resilvered automatically. <rekado>BTW: I think we can get even more storage with some configuration changes. 37TB is a bit low for the number of disks and RAID 6. I may have forgotten to delete a virtual disk that we used to play with storage settings. <rekado>(sorry for the unintentional dramatic line break) <efraim>so about my display problem on my PPC laptop, I think the display was just set all the way down <civodul>rekado: an extra 20TB is always welcome, sure :_) <civodul>rekado: BTW, did you update berlin.scm with the bind-mounting stuff? <civodul>also how do we access the /var/cache beneath the bind mount, so we can remove it? :-) <civodul>i think we can put ourselves in a different mount space and all, but i'm never sure how to do that <efraim>also unrelated to guix, it looks like some of the Adélie folks hang out in #gentoo-powerpc <rekado>civodul: I have not updated berlin.scm yet <rekado>civodul: part of the reason is because I’m afraid of reconfiguring at this time. <rekado>because then I’d have to manually copy over stuff from /gnu/store to /mnt/root-fs/gnu/store <rekado>I bind mounted / to /mnt/root-fs <rekado>so that’s how we can access the root file system without the shadowing bind mounts. <rekado>we can delete /mnt/root-fs/var/cache to delete the /var/cache beneath the bind mount. <civodul>rekado: even if we don't reconfigure right away, i think it's important to have the bind mounts written down <civodul>otherwise next time we'll spend ages figuring out what's going on <civodul>is it just the initrd and kernel that need to be copied? <rekado>I had the whole store synced when I first booted the reconfigured system. <rekado>I haven’t removed the rest of the store on the root fs, so it is possible that there are more things that need to be in the root fs store. <civodul>GRUB only needs to access these two files <civodul>so normally that's really all that needs to be there <civodul>actually, to copy that, we could use 'guix system init config.scm /mnt/root-fs' <rekado>we could try this by moving /mnt/root-fs/gnu out of the way, and copying just the initrd and kernel to /store. <rekado>would “guix system init” destroy the existing store? <rekado>I’d like to have a safe command to run after reconfigure to ensure that the new system’s initrd+kernel are *added* to the existing kernels. <efraim>'super-special-file-service to plop them in /boot? <rekado>not only do they need to be on the root fs but the GRUB entry would need to use those references to /boot (instead of /gnu/store). <g_bor>janneke: Hello, I've seen some interest around bootstrapping recently :) <janneke>anything i could have missed/want to know about? <g_bor>rekado: We got organizer approval for the Outreachy project settings, so it seems that the formilites are settled. <g_bor>janneke: You seem to always know about everything, so I don't think so :) <g_bor>rekado: I'm glad to see that this storage is finally working. <g_bor>I will try to get the hardware working here the next week, and share any insights gained there. <rekado>g_bor: me too. Turns out I had given up too early when I previously got the initrd error message. <g_bor>Is there any reason why locally booting is preferable to network booting in your setup? <janneke>gash is getting real close to its 0.1 release ... and a package in guix <rekado>once civodul confirmed that the correct UUID was in fact the one I previously used I could figure things out. <rekado>g_bor: the storage is attached directly to the server via dedicated HBAs. I think that’s preferable to connecting it via iscsi. <janneke>rekado: yeah, i "stole" some stuff from guix/* and other places <janneke>i'd like if we could find/create a place for a shared shelly library functions <g_bor>I have seen some hints that an efi implementation is free to expose any device to later stages, but this seems to be firmware specific, and one has to configure this at the firmware level... <rekado>janneke: there are a lot of neat things that are currently only found in guix/* that I think would be great as separate libraries. <janneke>rekado: great, i thought so too...i boldly tried to give them a home in (gash shell-utils), but i'd be also quite happy if we created a (guile shell) package -- or even move them to guile proper <janneke>in any case, guile will become an amazing shelly scripting language :-D <snape>civodul, rekado: Berlin's web interface is down *civodul looks forward to a Prometheus/Nagios/whatever service... <civodul>it wasn't dead, but db queries seemed to not complete <civodul>rekado: we have ENOSPC on some of the build machines <snape>it's weird that db queries weren't completing <snape>I've never experienced this on my machine <civodul>rekado: do we have mcron jobs on these machines? <civodul>snape: dunno if it relates to "PRAGMA optimize", which i've run this morning <rekado>civodul: that’s the big node which I added in the end. It’s not even running GuixSD yet. <rekado>I planned to install it, but it must have fallen off my list. <rekado>will install GuixSD some time in December. <snape>how can I pass several arguments to --substitute-urls? <snape>jonsger: I get "guix package: error: https: unknown package" <jonsger>works for me, but I'm on an old guix <civodul>snape: you and swedebugia are keeping me busy with those reports ;-) <civodul>if anyone else wants to chime in, feel free! <snape>civodul: believe me I'm not doing them with bad intentions, I'm just trying to use Guix ;-) <Sleep_Walker>I'd like to add fake - mocking utility for testing - what target gnu/packages/*.scm file it should be? <civodul>i don't blame people who report bugs, it's useful <civodul>hey Guix, in just 9 days, Guix will turn 6! *civodul turns #x26 today as well :-) <civodul>we could collect testimonials of old-timers and newcomers to Guix and put that in a blog post *jonsger chante "Joyeux Anniversaire" :P <apteryx>civodul: thanks for giving life to such an interesting and useful project and to continue driving it forward for all those years. <bavier>what are people working on today? <nckx>Oh wow. Félicitations à vous deux, civodul! <mbakke>bavier: I'll be working through a rather large backlog of emails, for one.. <jonsger>mbakke: I guess it's a little overrated as writing package definitions (most of guix repo) doesn't need so much time then equivalent "real" code... <mbakke>jonsger: I suspect maintaining them takes more effort than "real" code, so it evens out :-) <jonsger>mbakke: for core packages like gcc, glibc and that of course. But all those leaf packages, with our tooling (guix refresh et.al)? <mbakke>jonsger: guix refresh currently has rather low coverage, and packages often break due to incompatible dependencies. <mbakke>jonsger: See e.g. `git shortlog -n master..core-updates --no-merges`. <civodul>mbakke: 'guix refresh --list-updaters' claims it covers 64.6% of the packages <civodul>sometimes the updaters don't quite work though, so it's probably a little bit less <pkill9>has anyone ever create a guix package definition for a node package? <efraim>What do we need for core-updates? <bavier>mbakke: you asked me to push my python '--cores' patch to python-updates, could it go to core-updates instead? <civodul>efraim: Mark reported a failure of system tests yesterday, so that would be an important thing to address <snape>Hi, how can I get a package to export PYTHONPATH? <snape>well, propagating python works... <civodul>yup but that's Not the Right Way :-) <civodul>basically, as long as you have both python and python-foo in the same profile, --search-paths will suggest PYTHONPATH <snape>I want to package a Gajim plugin that would add a python dependency to gajim. The user doesn't need to have python in their profile, but they need PYTHONPATH so that Gajim can find the python package propagated by the plugin. <snape>But there must be another way :) <snape>Oh, I can use wrap-program I guess, on Gajim <vagrantc>trying to upstream arm-trusted-firmware-pine64-plus, and it can now use upstream's git rather than a fork, but not a released version yet, so it still needs to use a specific commit <bavier>vagrantc: you can use package and origin field accessor functions <vagrantc>i see some uses of (inherit (package-source ...)), but haven't been able to cargo-cult it into a working shape for what i need... :) <vagrantc>it obviously needs a different hash, and the upstream is specified by tag and not commit <mbakke>bavier: core-updates cannot handle large rebuilds at the moment. <mbakke>rekado: Is it OK do delete the python-updates branch? <mbakke>bavier: But core-updates-next may be equally good, I don't know if we'll have time for a 'half rebuild' before the next full rebuild. <buenouanq>can someone post an example of a working certbot service config <snape>it needs NGINX to update the certificates, but NGINX won't run because its conf lacks the certificates <snape>so the first update needs to be done with a custom NGINX that doesn't contain the failing certificates in its conf <snape>you can 'ps auxww | grep nginx', stop it, and re-run it with a custom configuration that doesn't contain the non-existing certificates <snape>then run the certbot command that update everything <snape>and then everything should be fine <snape>(and I don't know how to fix it) <buenouanq>it's not a bug in the normal sense, everything is working properly <snape>it works properly once it's setup, but it's impossible to setup properly ;) <g_bor>anyone knows how the guix.info website is updated? <g_bor>it seems that we have a bug somewhere in the link generation. <rekado>g_bor: there are problems with links to the manual, right? <g_bor>it is already tracked at #33293. <rekado>I’m generating it from the same website that is in the guix-artwork git repository. <g_bor>the html_node part seems to be at the wrong place. <rekado>this is because on gnu.org/s/guix the manual isn’t built as part of the website. <rekado>so the links in our website are hardcoded to the layout of the manual as it is deployed on gnu.org. <rekado>unfortunately, I probably won’t be able to fix this soon as I’m moving apartments. <g_bor>is it ok to send a patch for this, or are there other sites generated from this? <rekado>only guix.info and gnu.org/s/guix are built from this code. <mbakke>And I am unable to reproduce the failure. <rekado>is this a problem with parallel tests? <efraim>my initial guess is no, it built fine on my faster aarch64 board <rekado>“tpic2pdftex.test: line 8: pic: command not found” <rekado>why are there so many configure checks…? <mbakke>rekado: I've built it on multiple machines with varying levels of parallelism, so presumably not. <tune>did GuixSD running with Hurd ever become a thing? I'm seeing results from a year or two ago <ngz>Hello. On my main user, "guix --version" reports "guix (GNU Guix) d5401375099", whereas on root, it does report "guix (GNU Guix) 0.15.0-5.1d0be47". I call "guix pull" on both users everytime. So I guess there's something wrong in my root setup. Probably a wrong link or so. Is there any pointer to fix that? <mbakke>ngz: How do you become root? Typically you need to use "sudo -i" or "su -" in order to source the relevant login files. <ngz>mbakke: Also, root's configuration is stored in .bashrc so it's not a login file, is it? <civodul>mbakke: re texlive-bin, it does look like a genuine test failure though <civodul>./omfonts: tests/xcheck.opl: No such file or directory <mbakke>ngz: For GuixSD I think you need to source /etc/profile as well. <rekado>tune: there’s no GuixSD on Hurd yet. But Guix can be used on the Hurd if you’re brave. <ngz>mbakke: I use Guix in a foreign distro. I think I spotted the issue however. I have $PATH in root's .bashrc pointing to an odd location <rekado>tune: we don’t currently build substitutes for the Hurd yet. <civodul>janneke: i've (finally!) started a build of 'bootstrap-tarballs' from commit d0bb7ed61ed9e356c53de1a8e9bd6c2ec030ffb6 of core-updates-next <civodul>i suppose it's gonna take a while... <apteryx>I don't see any multiline substitute* examples so far. Has someone ever used it this way? <janneke>i just finished building another round myself, from my wip-bootstrap branch <apteryx>I know I can replace a single line by multiple lines, but I don't think we can replace multiple lines by something else (I get a regexp end region error or something) <rekado>apteryx: would using a patch be possible? <janneke>this new wip-bootstrap will probably take at least a month of work before it's ready <apteryx>rekado: yeah... I don't like having to use patches when possible, as it leads to crufts easily forgotten (in the build system and the patch itself). <apteryx>the range was my error, not I get #t but nothing is changed in the file <apteryx>is there any function that we can use to automatically escape all special characters of scheme regexps? <vagrantc>if you bind-mount /srv/gnu/ to /gnu/ ... will that break any of guix's assumptions? <pkill9>i've done that and it worked fine <vagrantc>i've been thinking to at least get guix into debian's "contrib" repository by making a "downloader" package that downloads the appropriate binary distribution and configures it. <vagrantc>rather than trying to build guix from source ... with it's entire bootstrap chain <vagrantc>not as idea as a "proper" package, but you can use strong hashes and/or gpg signature verification to ensure the right binary guix is downloaded