IRC channel logs


back to list of logs

<civodul>is the video available?
<civodul>well i'll see tomorrow
*civodul -> zZz
<civodul>good night/day!
<vagrantc>civodul: the conference didn't have any, but cmmarusich took a recording
***luciddreamzzz is now known as ghosthunter
<tune>still no deluge package
<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>This led to 500 rebuilds.
<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.
<sneek>Will do.
<rekado>sneek: botsnack
<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 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 ʕノ•ᴥ•ʔノ ︵ λ𝛌𝚲𝝀
<roptat>hi guix!
<civodul>Hello Guix!
<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.
<civodul>hi nckx! hi rekado! :-)
*rekado just swapped a broken disk on berlin.
<civodul>in the disk array?
<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.
<rekado>8TB disks.
<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>this could give us
<rekado>20TB extra
<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
<civodul>(guix-daemon does 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.
<jonsger>efraim: and in #talos-workstation
<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 don’t actually know.
<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.
<civodul>that could work too
<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>hello guix!
<janneke>hey g_bor!
<g_bor>janneke: Hello, I've seen some interest around bootstrapping recently :)
<janneke>g_bor: oh, that's very nice
<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 :)
<rekado>g_bor: very nice!
<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.
<rekado>janneke: exciting!
<g_bor>rekado: I see.
<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
<civodul>janneke: woohoo!
<snape>civodul, rekado: Berlin's web interface is down
*civodul looks forward to a Prometheus/Nagios/whatever service...
<civodul>snape: i've restarted Cuirass
<snape>civodul: thank you!
<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
<snape>oh... ;)
<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>I’m cleaning it out now.
<rekado>will install GuixSD some time in December.
<rekado>sorry about that.
<snape>how can I pass several arguments to --substitute-urls?
<jonsger>snape: --substitute-urls="http://one http://two"
<snape>jonsger: I get "guix package: error: https: unknown package"
<snape>third bug I'll report today
<jonsger>works for me, but I'm on an old guix
<snape>I'm on a recent one
<civodul>rekado: np!
<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>snape: yep i guess so!
<Sleep_Walker> <-- this one
<civodul>i don't blame people who report bugs, it's useful
<civodul>Sleep_Walker: maybe check.scm?
<Sleep_Walker>that sounds right, thanks!
<civodul>hey Guix, in just 9 days, Guix will turn 6!
*civodul turns #x26 today as well :-)
<apteryx>civodul: \o/
<civodul>we could collect testimonials of old-timers and newcomers to Guix and put that in a blog post
<civodul>that could be fun
<apteryx>happy birthday, Ludo!
*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.
<civodul>heheh, thank you!
<bavier>hello guix
<nckx>Hullo bavier.
<bavier>what are people working on today?
<nckx>Oh wow. Félicitations à vous deux, civodul!
<nckx>Bloggy post sounds fun.
<mbakke>civodul: Happy birthday! According to Open Hub, Guix represents over 100 years of effort: :-)
<mbakke>bavier: I'll be working through a rather large backlog of emails, for one..
<civodul>mbakke: now i feel old!
<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 :-)
<snape>civodul: bon anniv ;)
<jonsger>mbakke: for core packages like gcc, glibc and that of course. But all those leaf packages, with our tooling (guix refresh
<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>snape: tx :-)
<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
<civodul>apart from that i don't know!
<snape>Hi, how can I get a package to export PYTHONPATH?
<snape>(upon installation)
<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
<civodul>yeah, that's what i would do
<vagrantc>is it possible to inherit a single item from another package ... e.g. i want to inherit (source (uri "https://..../foo.git"))
<vagrantc>or rather, how elegant is it?
<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
<bavier>see guix/packages.scm
<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.
<bavier>mbakke: sounds good
<buenouanq>can someone post an example of a working certbot service config
<buenouanq>please and thank you
<snape>but there is a bug
<snape>it needs NGINX to update the certificates, but NGINX won't run because its conf lacks the certificates
<buenouanq>maybe that's my problem
<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>I should report this bug
<snape>(and I don't know how to fix it)
<buenouanq>it's not a bug in the normal sense, everything is working properly
<buenouanq>it's a how would you break into that issue
<snape>it works properly once it's setup, but it's impossible to setup properly ;)
<snape>gotta go, bye
<g_bor>hello guix!
<g_bor>anyone knows how the website is updated?
<rekado>g_bor: yes, I know :)
<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.
<g_bor>they look like this:
<g_bor>and then go to 404.
<rekado>yes, it should be
<g_bor>what might be causing this?
<rekado>this is because on 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
<rekado>this shouldn’t be hard to fix.
<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 and are built from this code.
<mbakke>civodul: texlive-bin refuses to build on
<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…?
<efraim>recursive ./configure && make ?
<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>sudo su
<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
<civodul>what's the shebang of this file?
<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.
<mbakke>ngz: Ah, great.
<ngz>Yes, that's it.
<tune>thanks for hte info
<civodul>janneke: i've (finally!) started a build of 'bootstrap-tarballs' from commit d0bb7ed61ed9e356c53de1a8e9bd6c2ec030ffb6 of core-updates-next
<civodul>so that i can upload them
<civodul>i suppose it's gonna take a while...
<janneke>civodul: great!
<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?
<civodul>apteryx: there's regexp-quote
<apteryx>civodul: neat, thank you!
<vagrantc>if you bind-mount /srv/gnu/ to /gnu/ ... will that break any of guix's assumptions?
<civodul>no, it should be invisible to guix
<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