<minima>hi sorry, how do you restart shepherd on a foreign distro? <bjc>i don't know what step 2 is, but step 1 is ‘herd stop root’ <bjc>step 2 is however you normally start it <minima>oh... apparently that's handled automatically by guix home? i think? anyway, a guix home reconfigure seems to have fixed my problem <Gooberpatrol66>minima: i didn't know you could run shepherd on a foreign distro. how are you doing that? <lilyp>you can run shepherd as regular user <lilyp>if you mean as init, though, that'd probably be trickier <sammm>hi, I'm looking at migrating my guix SD over to cgroups v2, from what I can tell, I'll need to modify %control-groups so all of the tmpfs cgroups v1 mount points are replaced with a single cgroup v2 mount at /sys/fs/cgroups (except for elogind which I think can remain at the current mount point). <sammm>What would be the best way of modifying the control groups definition ? Pretty new to guile, etc <mirai>does making a team imply commit access or having a savannah account? <mirai>there's quite a few packages I'm interested in tweaking but coincidentally happen to have no team at all <mirai>so idk what to do about them (other than start prefixing them as mirai-orphanage) <vagrantc>are they not well maintained? are they logically grouped together? <vagrantc>you don't need to have a team for a package either <vagrantc>e.g. anyone can submit patches to update, fix, modify, etc. packages ... <mirai>some are outdated, some could be refactored. logically independent <vagrantc>if you're not careful and you submit lots of good fixes you might be recommended to get commit access :) <mirai>some of the packages will cause 1000-3000+ rebuilds though <vagrantc>what to do with big rebuilds is currently in flux, with the attempt to deprecate the staging and core-updates branches... <vagrantc>but historically, that would have gone to staging (or maybe core updates if it was really large) <vagrantc>i think the documentation still suggests that ... <vagrantc>these might be good questions to pose on the guix-devel@gnu.org mailing list <mirai>I have a trivial patch for avahi (that simply stops shipping some obsolete/irrelevant docs) that's been sitting on my local checkout for months <mirai>and I was just taking a look at getting flac bumped up <mirai>until I noticed the torrent of rebuilds it would bring <vagrantc>you can also submit patches and include in the submission a mention of the number of expected rebuilds ... i usually do that if it is above the old thresholds <mirai>(there's already a few CVEs on our flac) <vagrantc>if it is security issues, it might be possible to fix with grafts and whatnot <vagrantc>i am not too familiar with those, but have a rough idea of what they are :) <vagrantc>mirai: many of the folks aren't likely to be on irc at this hour, which is why i suggest taking it to the mailing list <vagrantc>you also get the broadest pool of expertise :) <mirai>I've been affixing some “core-updates warning” for some of the more complete patch-series (like #63081) <mirai>though I don't know how “visible” they are <sammm>is there a good way to modify the file-system list _after_ things like elogind have brought in it's own? I want to replace the %control-groups with a cgroup2 version I made <lilyp>mirai: those warnings are a little anachronistic with the teams workflow <jpoiret>janneke: I looked at the hurd thread the other day, you got netdde working? *janneke just sent mail about /dev/urandom sillyness btw <jpoiret>then we should get rid of the in-kernel drivers then <jpoiret>i have been quite busy these past few days but i'll have a look at all of this today or tomorrow i hope <janneke>yes, we must even, otherwise it doesn't run <jpoiret>need to catch up on my mails first :( <janneke>hehe, fwiw: i've been using your patchset with much success, except for maybe this /dev/urandom thingy <janneke>i've booted Guix/Hurd on my x60, with networking, but a second boot currently still hangs *janneke thinks they're almost there, though ... <jpoiret>the urandom thingy is totally unnecessary, i was just copying debian's translators <janneke>that's what i thought when i looked at your patch ;) <jpoiret>janneke: i'll just remove that first patch when pushing tbh, doesn't bring anything significant to the table <jpoiret>i'll also try to update everything to latest <jpoiret>i'm wondering if it's a good idea to pin all the header packages so that updating hurd/gnumach doen't cause a world rebuild <jpoiret>depends on whether the header changes are backwards-compatible most of the time or not <janneke>maybe just keep your versions where they are right now, (except maybe mig) <janneke>jpoiret: there's all kinds of potentially destabilizing 64bit work going on <jpoiret>we can update to the new tags though <janneke>maybe if you update in a month (or two?), we have 64bit <jpoiret>yeah, that's mostly what I'm worried about with the headers, I can't see the 64-bit work not creating some problems down the line <jpoiret>still have to fix the native compilation (how long have i been saying this) <janneke>jpoiret: i do have a fix for that, but untested: <janneke>(eh, for the first problem i found, that is) <jpoiret>gcc-boot0 is used in other places though (and doesn't the above comment mention that the bootstrap guix can't possibly do it either?) <jpoiret>i'll try this out, the comment made me rty other things <jpoiret>janneke: it seems from a cursory reading of bug-hurd that 64bit userland is working as well <janneke>jpoiret: yeah, samuel is starting to create binaries <janneke>i thought they don't reach login yet? <janneke>we need to time our next blog post on the hurd carefully ;) *janneke is hoping jpoiret would take the lead in this <jpoiret>yes, I'm thinking we can wait for 64-bit Hurd for that? <jpoiret>that's a big announcement, and it would be great if we get it at the same time as debian <jpoiret>do you have your netdde changes anywhere? <efraim>first time using the etc/teams script, not as scary as I thought it would be *janneke was "waiting" for jpoiret's and janneke's patch sets to land first <jpoiret>ah, I was thinking of doing all of them at the same time <jpoiret>but I guess we don't really *need* netdde <janneke>no, all patch sets have merit on their own <janneke>in fact, i'd like to keep patch sets as small possible <janneke>(or maybe: rather smaller, than larger) <janneke>if we need time to get a patch set to work, such as native compilation, or 64bit support (second boot support?) we could always re-start a wip-hurd at savannah <jpoiret>so for 64bit we'd need HEAD for everything (glibc included). Should we try to go for itL <janneke>i would really like to get all my current patches in, including support for native builds and a second-boot fix <jpoiret>since we'd basically need to wait for a new glibc release, it would be a while before we do get it <jpoiret>oh no sure, I was talking about after that <janneke>upon boot, boot-hurd-system just assumes / is pristine, no /servers, no /dev and creates those <jpoiret>I think we should be doing this yes, and not try to use xattrs and persistance <janneke>booting again on a filesystem that boot-hurd-system has visited (a second boot), it hangs <jpoiret>it seems more in line with the Guix way *janneke has been prying into this for the past two days <jpoiret>(unless you mean it just chokes on the dir /servers existing) <janneke>(yeah, there's also that inconsistancy between creating a qemu image and doing system install, wrt /servers and /dev) <janneke>i've tried many things, removing /servers and /dev, removing parts of them, checking for them and doing nothing, <jpoiret>i guess you're the first to try a guix install on bare metal right? <jpoiret>do you have any error messages, or know what's going wrong exactly? <janneke>guix system init does not run make-hurd-device-nodes <janneke>jpoiret: not really, booting just hangs if <janneke>or /dev/urandom exists, and you do (file-exists? "/dev/null) <jpoiret>but do we need them persistently is the question <jpoiret>then I guess we can just `rm /servers /hurd` on each boot, right <janneke>for my x60, i have a script that cleans the /hurd mount from gnu/linux, removing /hurd, /dev, and /servers, and does an initial /servers setup <janneke>i didn't find the courage yet to write a delete-file-recursively C and add that to startup.c, but possibly that's the smart move right now <jpoiret>ah, do you mean we need to do that before the hand off to the Guile startup? <jpoiret>i'm wondering if we should just start all translators actively <janneke>the startup process already creates stuff in /dev <jpoiret>so that they don't have any persistence <janneke>if we try to remove them from guile, it gets pretty tricksy *janneke is such a Hurd noob... <jpoiret>yes, you can just ask Hurd to start a translator without using xattrs <janneke>oh yes, by all means, let's not embed translators in the file system, civodul ? <janneke>embedding doesn't work so well i guess with the declarative model <jpoiret>i guess your patch should also be fine though *janneke goes to look into glibc's ftw/ntfw <jpoiret>although you mention that startup creates some stuff in /dev that we shouldn't delete in Guile, maybe we can identify all of them and keep only those? <janneke>yeah maybe, but i tried that; writing a delete-file-recursively* with a #:keep? option <janneke>i have finally identified --- wait for it -- /dev/urandom to be the last problem i cannot get around <janneke>removing it makes nothing hang, but we get <janneke>Fatal glibc error: cannot get entropy for arc4random <jpoiret>yeah, glibc needs random/urandom for its startup <janneke>re-adding it, either in boot-hurd-system or in runsystem, either as a symlink or translator, makes (file-exists? "/dev/null") (any 'stat'?) hang again <jpoiret>but that doesn't happen on first boot, right? <jpoiret>I don't really know how translators are handled in Hurd, ie. if (file-exists? "/dev/null") would start the translator <janneke>so that's why doing rm -rf /dev in startup.c seems so attractive... <jpoiret>can you try to use kdb and see if there's a task for /dev/null? <civodul>janneke: yes, i think passive translators are sort of the antithesis of declarative config management <jpoiret>janneke: right, but then it wouldn't be compatible with Debian's Hurd <jpoiret>I'm going to look into starting the essential translators actively <jpoiret>if they're essential, they should just be started instantly, otherwise we can defer them to shepherd later <civodul>plus, they're a security issue: passive translator settings are just a string, without context as to how to interpret that string <janneke>i'll keep the kdb in mind, working on a rm -rf /dev right now <jpoiret>janneke: do you know if startup sets up those translators passively as well? <civodul>just like we have make-inetd-constructor, we could have make-translator-constructor :-) <jpoiret>now I'm updating everything to the latest tags <jpoiret>since you were talking about that in the patchset janneke <aninternettroll>Hi, does anyone know if GNU Guix (the distro) packages and allows installing a non-libre linux kernel? <jpoiret>civodul: wdyt of having everything on HEAD (glibc/hurd included) to try out 64bit later on? <jpoiret>Debian has it working, with userspace packages as well. My untangling of our build process oddities (setting i586-pc-gnu everywhere manually) should help us try it out without too much effort now <civodul>jpoiret: sure, i wouldn't want to block anyone's enthusiasm! :-) <civodul>while doing it, we should invite fellow Hurd folks to tag/release things and help document the set of versions that work together <jpoiret>one thing that's a bit worrying though is that we'd need to update the tarballs again <jpoiret>that quite a lot of work (and an additional one for glibc/hurd) <jpoiret>aninternettroll: no, the GNU Guix distro itself only has linux-libre packaged. Other channels are free to add whatever software they want though <janneke>jpoiret: like i said, i'm fine with only updating mach for now and do another update fo 64bit <jpoiret>right! and seems that updating mach to the latest tag already requires glibc head, so I won't bother with that for now *jonsger lost track what Guix + Hurd do now. There is just to much going on nowadays, which is nice :) <jpoiret>well, it do boot for now, which is already pretty nice <jpoiret>basically Hurd was broken by core-updates, and that was fixed recently, now we're trying to catch up to debian <janneke>so, essentially the childhurd service was resurrected, but with pretty up-to-date sources <janneke>jonsger: lots of stuff to come real soon now, tho <jonsger>crazy, that thing gained traction :) ***breavyn_ is now known as breavyn
<janneke>jonsger: still need some cleanup and tweaking, but my crude rm_r ("/dev") works *janneke has the first successful second-boot after ~2 days of straight hacking <janneke>(the active translator setup might be preferrable but it's always nice to have working code we can improve on) <janneke>oops, /me meant to mention jpoiret, of course ;) <jpoiret>i guess the best would be to have native compilation working so that we can just iterate on the system instead of creating new images each time <jpoiret>i'm also thinking that with qcow2 since you can layer images we might be able to lower the barrier <jpoiret>guix xbuild is so damn slow, i wonder if it's the same for other archs <jpoiret>maybe it's because of the i386/x86_64 arch peculiarities <jonsger>hmpf, calling shell scripts from mcron jobs feels tricky. At least the script returns a different value then when I call it from the shell myself :( <jpoiret>civodul: wdyt about using (gnu packages cross-base) from (... hurd) when the latter already uses the former? I wasn't very fond of adding an unnecessary cycle, but I can see why having to use resolve-interface all the time is annoying <jpoiret>janneke: did you mistakenly remove --target=i586-pc-gnu from the comment at the top of bare-hurd.tmpl? <jpoiret>cross-building guix is literally longer than building gcc <janneke>jpoiret: no, that's implicit when using --image-type=hurd* <jpoiret>i'll move your hurd patches to hurd and not hurd-headers, but apart from that the patches look great <jpoiret>just realized I won't be able to commit though as we'll need to switch away from git-fetch to permit bootstrap <jpoiret>or we include git in the Hurd bootstrap <janneke>jpoiret: what do you mean by "commit?" <janneke>that the native build won't work with your current patch set becaues of git versions? <cassio>How do I upgrade from guix 1.3 to 1.4? Is it just a matter of specifying a new Channel? <janneke>cassio: as guix uses rolling releases, you can always upgrade to latest by doing a "guix pull" and then "guix package --upgrade" and "guix system reconfigure" <janneke>if you *really* don't want to go past 1.4, you could do "guix pull --branch=version-1.4.0" instread <cassio>well, I have done `guix pull` and `guix reconfigure` and I still remain on 1.3. Here's the output of `guix describe`: <janneke>jpoiret: of course, we can always generate and host our own tarballs if ufpstream doesn't want to provide them <cassio> commit: b96b82bcd4bc24529941ff74a91432481f1a71b5 <janneke>ah, i see. git describe says v1.3.0-38771-gb96b82bcd4 <janneke>so not sure what happened with the tags, or how that works (guix does not maintain a linear history) <cassio>what I want is the latest stable version. Is there a `channels` declaration that fetches always the latest stable <janneke>cassio: guix does not provide stable versions <janneke>yes, you're only a handful of commits behind bleeding edge <janneke>if you don't have a guix git checkout, you could look at <janneke>jpoiret: savannah supports tarball downloads from tags, right? <janneke>we can worry about latest-greatest glibc later? <aninternettroll>Hi, anyone have a guix distro guide? Something non-official, I couldn't really understand those docs :/ <jpoiret>janneke: yes, but they would require autotools, right? <jpoiret>it's for the current patchset that I posted some time ago <jpoiret>last time civodul had to create do dist tarballs and host them on the gnu ftp iirc <janneke>jpoiret: quite possibly autotools, but not git <jpoiret>right, that's one less. I wonder if we can make that work then <jpoiret>are the savannah tarballs regenerated ever? <janneke>i don't think the hurd uses automake or libtool <janneke>i haven't heard they are not reproducible <jpoiret>still, we don't have autoconf ever in the bootstrap, right? <cassio>Thanks janneke! Now I'll look into `guix style` ;) <janneke>providing autoconf would be new, but should be douable i guess <janneke>i believe the live-bootstrap project removes all autogenerated files and regenerates them <janneke>cassio: np, thanks for reaching out! <jpoiret>we'll see. I'd be in favor of not depending on dist tarballs if we can <jpoiret>maybe we could build autotools straight away in boot0 and then rely on just that <jpoiret>I wonder why that hasn't been done though <janneke>fwiw, i'd guess: no-one got around to doing this yet; but it could be a policy thing, civodul would know ;) <janneke>i think we prefer released tarballs, but yeah <jpoiret>yeah i've seen it discussed on the MLs a couple of times. Don't really know why though, generating everything seems like the way to go <janneke>"do the simplest thing that could possibly work" <janneke>improving/nitpicking on working code is much easier than getting something to work in the first place <cassio>Now, looking at my `home-configuration.scm` file, I find this: `(packages (map (compose list specification->package+output) <cassio> (append ...)))`. My question is: in the new package declaration style in guix version 1.4, is this declaration awkward? Is it in any way better not to use `specification->package+output`? <janneke>packages (specifications->packages `("acpi" .. "bind:utils" ..)))) <cassio>I'm not too chat-savvy, so, forgive my asking: what does fwiw mean? <cassio>And one last question about installation/upgrade: <cassio>if I'm sticking to standard packages in the current version of guix, with no alternative or modified stuff, I never need to worry about Channels? The default channel will always be OK? <ulfvonbelow>whenever I try to source /etc/profile from a cron environment, I get: /run/current-system/profile/etc/profile.d/bash_completion.sh: line 9: shopt: progcomp: invalid shell option name <ulfvonbelow>it seems to be limited to the bash-static used by glibc's system(). ***mirai_ is now known as mirai
<janneke>jpoiret: i'm going to add all hurd patches that are not necessary for hurd-headers only to hurd *janneke is getting waaay too many gratuitous rebuilds <jpoiret>yeah, maybe not now unless you want a toolchain rebuild <jpoiret>i myself just finished building everything <jpoiret>building guix itself is the longest it seems <janneke>well, i need a change now, so i'm taking the hit... <janneke>i really believed that i was done... <jpoiret>janneke: haven't yet tried to boot with rumpkernel but it works <janneke>it works = it builds, or the rumpdisk server starts fine? <janneke>to use the rumpdisk, you simply need to add "noide" to the kernel-arguments <jpoiret>i see what you mean by it being slow :p <jpoiret>even then, feels like the early userspace is slower <TylerWolf[m]>Hello, ever since I switched to kernel 6.1 my screen turn off automatically doesn't work. Instead of turning off the screen as previously, the screen just blanks, but is still on and clearly emitting light. Anyone know how to fix this? I am using xfce desktop environment. ***samebchase0 is now known as samebchase
<Kabouik>`guix pull` is stuck on `waiting for locks or build slots` since hours, what can I do? <civodul>Kabouik: it means there's another command already building it (like "guix pull" running in another terminal) <civodul>mirai: not right now :-) but i think it's a good idea