IRC channel logs

IRC channel logs
IRC channel logs
2023-05-28.log
back to list of logs

hi sorry, how do you restart shepherd on a foreign distro?

i don't know what step 2 is, but step 1 is ‘herd stop root’

step 2 is however you normally start it

oh ok, thanks bjc

oh... apparently that's handled automatically by guix home? i think? anyway, a guix home reconfigure seems to have fixed my problem

minima: i didn't know you could run shepherd on a foreign distro. how are you doing that?

you can run shepherd as regular user

if you mean as init, though, that'd probably be trickier

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).

What would be the best way of modifying the control groups definition ? Pretty new to guile, etc

does making a team imply commit access or having a savannah account?

strictly speaking, probably not.

there's quite a few packages I'm interested in tweaking but coincidentally happen to have no team at all

so idk what to do about them (other than start prefixing them as mirai-orphanage)

are they not well maintained? are they logically grouped together?

you don't need to have a team for a package either

e.g. anyone can submit patches to update, fix, modify, etc. packages ...

some are outdated, some could be refactored. logically independent

if you're not careful and you submit lots of good fixes you might be recommended to get commit access :)

some of the packages will cause 1000-3000+ rebuilds though

what to do with big rebuilds is currently in flux, with the attempt to deprecate the staging and core-updates branches...

but historically, that would have gone to staging (or maybe core updates if it was really large)

i think the documentation still suggests that ...

these might be good questions to pose on the guix-devel@gnu.org mailing list

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

and I was just taking a look at getting flac bumped up

until I noticed the torrent of rebuilds it would bring

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

(there's already a few CVEs on our flac)

if it is security issues, it might be possible to fix with grafts and whatnot

i am not too familiar with those, but have a rough idea of what they are :)

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

right, makes sense

you also get the broadest pool of expertise :)

I've been affixing some “core-updates warning” for some of the more complete patch-series (like #63081)

though I don't know how “visible” they are

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

mirai: those warnings are a little anachronistic with the teams workflow

okay, so I got rootless podman working by creating a new elogind service type that throws away the old %control-groups mounts in preference for the unified mount
(https://github.com/alam0rt/guix-config/blob/main/system/config.scm#L12-L91),
my question to the channel is, how can I modify the existing service type (monkey patching?) without feeling like i've committed a war crime? the code is heinous... but

works

hey guix

o/

o/

\o

janneke: I looked at the hurd thread the other day, you got netdde working?

jpoiret: yes!

incredible!
janneke just sent mail about /dev/urandom sillyness btw

then we should get rid of the in-kernel drivers then

i have been quite busy these past few days but i'll have a look at all of this today or tomorrow i hope

yes, we must even, otherwise it doesn't run

need to catch up on my mails first :(

hehe, fwiw: i've been using your patchset with much success, except for maybe this /dev/urandom thingy

i've booted Guix/Hurd on my x60, with networking, but a second boot currently still hangs
janneke thinks they're almost there, though ...

the urandom thingy is totally unnecessary, i was just copying debian's translators

well, at least I think it is

that's what i thought when i looked at your patch ;)

janneke: i'll just remove that first patch when pushing tbh, doesn't bring anything significant to the table

i'll also try to update everything to latest

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

depends on whether the header changes are backwards-compatible most of the time or not

yeah, most of the time they aren't

maybe just keep your versions where they are right now, (except maybe mig)

jpoiret: there's all kinds of potentially destabilizing 64bit work going on

we can update to the new tags though

ah sure

if that's not too much work for you

maybe if you update in a month (or two?), we have 64bit

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

still have to fix the native compilation (how long have i been saying this)

jpoiret: i do have a fix for that, but untested:

jpoiret:

(eh, for the first problem i found, that is)

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?)

bootstrap guile*

i'll try this out, the comment made me rty other things

ah, right

great

Welcome back civodul!

janneke: it seems from a cursory reading of bug-hurd that 64bit userland is working as well

jpoiret: yeah, samuel is starting to create binaries

i thought they don't reach login yet?

we need to time our next blog post on the hurd carefully ;)
janneke is hoping jpoiret would take the lead in this

yes, I'm thinking we can wait for 64-bit Hurd for that?

that's a big announcement, and it would be great if we get it at the same time as debian

that would be amazing

do you have your netdde changes anywhere?

talkin' serious business here!

first time using the etc/teams script, not as scary as I thought it would be

not sent yet, but at
janneke was "waiting" for jpoiret's and janneke's patch sets to land first

ah, I was thinking of doing all of them at the same time

but I guess we don't really *need* netdde

no, all patch sets have merit on their own

in fact, i'd like to keep patch sets as small possible

(or maybe: rather smaller, than larger)

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

so for 64bit we'd need HEAD for everything (glibc included). Should we try to go for itL

i would really like to get all my current patches in, including support for native builds and a second-boot fix

since we'd basically need to wait for a new glibc release, it would be a while before we do get it

oh no sure, I was talking about after that

but after that, hell yeah!

wdym by second-boot fix?

upon boot, boot-hurd-system just assumes / is pristine, no /servers, no /dev and creates those

I think we should be doing this yes, and not try to use xattrs and persistance

booting again on a filesystem that boot-hurd-system has visited (a second boot), it hangs

it seems more in line with the Guix way
janneke has been prying into this for the past two days

(unless you mean it just chokes on the dir /servers existing)

(yeah, there's also that inconsistancy between creating a qemu image and doing system install, wrt /servers and /dev)

inconsistency where?

i've tried many things, removing /servers and /dev, removing parts of them, checking for them and doing nothing,

i guess you're the first to try a guix install on bare metal right?

quite possibly, but you never know

do you have any error messages, or know what's going wrong exactly?

guix system init does not run make-hurd-device-nodes

jpoiret: not really, booting just hangs if

* /hurd exists

or /dev/urandom exists, and you do (file-exists? "/dev/null)

but do we need them persistently is the question

huh? that's funny behavior

we do not need them persistently

then I guess we can just `rm /servers /hurd` on each boot, right

i'm removing /hurd now:

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

that works nicely

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

*in C

ah, do you mean we need to do that before the hand off to the Guile startup?

yes!

e.g., see

i'm wondering if we should just start all translators actively

the startup process already creates stuff in /dev

so that they don't have any persistence

if we try to remove them from guile, it gets pretty tricksy

wait, that's a possibility?
janneke is such a Hurd noob...

yes, you can just ask Hurd to start a translator without using xattrs

well at least i think so

oh yes, by all means, let's not embed translators in the file system, civodul ?

embedding doesn't work so well i guess with the declarative model

i guess your patch should also be fine though

yeah, once i get it to work!
janneke goes to look into glibc's ftw/ntfw

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?

yeah maybe, but i tried that; writing a delete-file-recursively* with a #:keep? option


but i gave up on that for now

i have finally identified --- wait for it -- /dev/urandom to be the last problem i cannot get around

removing it makes nothing hang, but we get

Fatal glibc error: cannot get entropy for arc4random

yeah, glibc needs random/urandom for its startup

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

when does the glibc error happen/

when running ssh-keygen

but that doesn't happen on first boot, right?

the hang on /dev/null

no, first boot is fine

I don't really know how translators are handled in Hurd, ie. if (file-exists? "/dev/null") would start the translator

so that's why doing rm -rf /dev in startup.c seems so attractive...

can you try to use kdb and see if there's a task for /dev/null?

janneke: yes, i think passive translators are sort of the antithesis of declarative config management

janneke: right, but then it wouldn't be compatible with Debian's Hurd

I'm going to look into starting the essential translators actively

sounds good

great!

if they're essential, they should just be started instantly, otherwise we can defer them to shepherd later

plus, they're a security issue: passive translator settings are just a string, without context as to how to interpret that string

i'll keep the kdb in mind, working on a rm -rf /dev right now

janneke: do you know if startup sets up those translators passively as well?

just like we have make-inetd-constructor, we could have make-translator-constructor :-)

jpoiret: dunno

i'll look at that

now I'm updating everything to the latest tags

since you were talking about that in the patchset janneke

Hi, does anyone know if GNU Guix (the distro) packages and allows installing a non-libre linux kernel?

civodul: wdyt of having everything on HEAD (glibc/hurd included) to try out 64bit later on?

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

jpoiret: sure, i wouldn't want to block anyone's enthusiasm! :-)

it's truly exciting

while doing it, we should invite fellow Hurd folks to tag/release things and help document the set of versions that work together

+1

one thing that's a bit worrying though is that we'd need to update the tarballs again

that quite a lot of work (and an additional one for glibc/hurd)

aninternettroll: no, the GNU Guix distro itself only has linux-libre packaged. Other channels are free to add whatever software they want though

jpoiret: like i said, i'm fine with only updating mach for now and do another update fo 64bit

*only updating mig

jpoiret: Thanks!

oh, right

(mig is one commit behind a tag)

right! and seems that updating mach to the latest tag already requires glibc head, so I won't bother with that for now

ah, right
jonsger lost track what Guix + Hurd do now. There is just to much going on nowadays, which is nice :)

well, it do boot for now, which is already pretty nice

basically Hurd was broken by core-updates, and that was fixed recently, now we're trying to catch up to debian

and already 64bit or still 32bit?

32bit, and only in a vm

so, essentially the childhurd service was resurrected, but with pretty up-to-date sources

jonsger: lots of stuff to come real soon now, tho

the 64bit work is going on over at bug-hurd, you can follow it almost in real time these days:

crazy, that thing gained traction :)
***
breavyn_ is now known as breavyn

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

(the active translator setup might be preferrable but it's always nice to have working code we can improve on)

oops, /me meant to mention jpoiret, of course ;)

nice!

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

yeah

i'm also thinking that with qcow2 since you can layer images we might be able to lower the barrier

guix xbuild is so damn slow, i wonder if it's the same for other archs

maybe it's because of the i386/x86_64 arch peculiarities

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 :(

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

janneke: did you mistakenly remove --target=i586-pc-gnu from the comment at the top of bare-hurd.tmpl?

cross-building guix is literally longer than building gcc

jpoiret: no, that's implicit when using --image-type=hurd*

oh, I didn't know that

i'll move your hurd patches to hurd and not hurd-headers, but apart from that the patches look great

just realized I won't be able to commit though as we'll need to switch away from git-fetch to permit bootstrap

or we include git in the Hurd bootstrap

hmm

Hello!

jpoiret: what do you mean by "commit?"

that the native build won't work with your current patch set becaues of git versions?

(or is it a future 64bit concern?)

How do I upgrade from guix 1.3 to 1.4? Is it just a matter of specifying a new Channel?

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"

if you *really* don't want to go past 1.4, you could do "guix pull --branch=version-1.4.0" instread

well, I have done `guix pull` and `guix reconfigure` and I still remain on 1.3.  Here's the output of `guix describe`:

jpoiret: of course, we can always generate and host our own tarballs if ufpstream doesn't want to provide them

guix b96b82b

URL do repositório:

ramo: master

commit: b96b82bcd4bc24529941ff74a91432481f1a71b5

this commit is version 1.3

ah, i see. git describe says v1.3.0-38771-gb96b82bcd4

so not sure what happened with the tags, or how that works (guix does not maintain a linear history)

what I want is the latest stable version. Is there a `channels` declaration that fetches always the latest stable

but you're definitely beyond 1.4

am I?

cassio: guix does not provide stable versions

yes, you're only a handful of commits behind bleeding edge

how can I tell that?

if you don't have a guix git checkout, you could look at


and

jpoiret: savannah supports tarball downloads from tags, right?

mig:

we can worry about latest-greatest glibc later?

Hi, anyone have a guix distro guide? Something non-official, I couldn't really understand those docs :/

cassio: =>

janneke: yes, but they would require autotools, right?

it's for the current patchset that I posted some time ago

last time civodul had to create do dist tarballs and host them on the gnu ftp iirc

jpoiret: quite possibly autotools, but not git

right, that's one less. I wonder if we can make that work then

and most probably only autoconf

are the savannah tarballs regenerated ever?

i don't think the hurd uses automake or libtool

i haven't heard they are not reproducible

that would be terrible

still, we don't have autoconf ever in the bootstrap, right?

Thanks janneke! Now I'll look into `guix style`  ;)

providing autoconf would be new, but should be douable i guess

i believe the live-bootstrap project removes all autogenerated files and regenerates them

cassio: np, thanks for reaching out!

we'll see. I'd be in favor of not depending on dist tarballs if we can

maybe we could build autotools straight away in boot0 and then rely on just that

autoconf needs bash, perl, and m4

yeah, that would be nice

I wonder why that hasn't been done though

must be a reason

fwiw, i'd guess: no-one got around to doing this yet; but it could be a policy thing, civodul would know ;)

i think we prefer released tarballs, but yeah

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

yes

certainly in our hurd case

jpoiret: autoconf-boot0, go for it!

heh, seems quite attractive

"do the simplest thing that could possibly work"

improving/nitpicking on working code is much easier than getting something to work in the first place

esp. when smart people add their 2c

Now, looking at my `home-configuration.scm` file, I find this: `(packages (map (compose list specification->package+output)

(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`?

cassio: fwiw, i'm using

packages (specifications->packages `("acpi" .. "bind:utils" ..))))


I'm not too chat-savvy, so, forgive my asking: what does fwiw mean?

cassio: fwiw means for what it's worth

And one last question about installation/upgrade:

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?

Would anyone mind having a look at this patch for a new bash package:

cassio: yep

Great!  Thanks

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

it seems to be limited to the bash-static used by glibc's system().

Could someone take a look at this patch too?
***
mirai_ is now known as mirai

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

yeah, maybe not now unless you want a toolchain rebuild

i myself just finished building everything

building guix itself is the longest it seems

yes

well, i need a change now, so i'm taking the hit...

i really believed that i was done...

janneke: haven't yet tried to boot with rumpkernel but it works

jpoiret: wdym?

it works = it builds, or the rumpdisk server starts fine?

to use the rumpdisk, you simply need to add "noide" to the kernel-arguments

i see what you mean by it being slow :p

but very impressive!

yeah, startup is slow

and it is memory hungry

i've got no idea about performance

even then, feels like the early userspace is slower

not just the rumpdisk startup

ah, that could be

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

`guix pull` is stuck on `waiting for locks or build slots` since hours, what can I do?

I'm currently planning a “generic” INI serializer to be used with define-configuration, any alternative suggestions to this API sketch?


Kabouik: it means there's another command already building it (like "guix pull" running in another terminal)

mirai: not right now :-) but i think it's a good idea

Thanks civodul