IRC channel logs
IRC channel logs
2023-05-17.log
back to list of logs
howdy people!
I was having fun today editing the hurd.texi document. It'
s pretty fun.
is anyone using lwip to replace pfinet here?
apparently our pci-arbiter.static is broken
and rumdisk.static too
if i copy debian-hurd-20220824.img's /hurd/pci-arbiter.static to /debian/pci-arbiter.static and use that in the grub.cfg it crashes on rumpdisk
if i also copy /hurd/rumpdisk.static and use that, it boots
perhaps it's your libpciaccess that needs an update?
we use version 0.17
which doesn't require any hurd-specific patch any more
guix it as 0.16
that's too old
we have fixed many things since then
ah great
i was hoping to ask for a bisect strategy, but you beat me to it with a great suggestion, thanks!!
ACTION goes to update libpciaccess in guix (at least for hurd)
morning friends!
youpi1: libpciaccess-0.17 fixed our pci-arbiter!
yay
now it seems rumpdisk.static is b0rked :-(
i managed to boot debian with the guix pci-arbiter, and guix with debian's rumpdisk.static
ACTION is hoping for yet another magic guess/spell ...
*the guix pci-arbiter.static -- of course
i'm getting this error output, to the bare eye identical on debian and guix alike:
janneke: you probably need the
workaround
youpi1: oh my, didn't you hint me before about that (about 3 years ago?) -- it could be this was dropped, how weird
thanks
ACTION goes to investigate
hmm, the MONOTONIC and centiseconds patches weren't dropped, but forward ported from 2.31
ACTION tries a rebuild with the guix patches reverted, and the current debian patches applied
oh my, there are some 50 odd patches there...
ACTION can imaging upstreaming to glibc can be...hard
*imagine
janneke: it's not so much upstreaming as it getting it commited that is hard (I can do that easily), but turning them into proper fixes
youpi: ah, so it's easy to create "DRAFT" commits, "hey it works", but to turn it into something 100% sane is hard
glibc is a pretty serious project...
it's the 90%-10% rule, yes
getting 90% working is 10% hard, but getting the last 10% working is 90% hard
but we do want computers to work 100% of the time
makes a lot of sense (me knows it as the 80/20 rule)
percentages vary, but that's basically the same :)
janneke: so do we need some libc changes? I can look into having a glibc just for hurd
jpoiret: dunno
when I tried myself I just used a hack to quickly check if that was the issue causing our hurd to not boot
what i'm doing right now, is in cross-glibc revert the monotonic and centiseconds patches we have, and apply the ones youpi linked to
youpi: do you know if a 2020-ish glibc+kernel headers combo would be able to properly compile on a new hurd? our native-compilation on hurd relies on bootstrap blobs, among which this old glibc, and the binaries it produces seem to crash on our newer hurd
our current patches were "adapted" from the debian ones, and they were at the time only necessary for building python
whereas our cross-compilation uses the newer headers
cross-bootstraping from scratch should be just working fine
there's no hidden binary blob
no I mean, our bootstrap libraries are 2 years old compared to our running Hurd that we're building on, so I was wondering if the mismatch would cause problems down the line
jpoiret: note that we boot with rumpdisk just fine now, if we use debian's /hurd/rumpdisk.static
oh, that's great!
building mig/gnumach/glibc/hurd are not supposed to depend on whatever you already have
so everything else _seems_ fine, but of course, it's rumpdisk.STATIC, so it could still be a glibc problem...
youpi: well let's say I have some very old linux kernel headers that aren't up-to-date at all, and I build some native binaries with it, but run them on a newer Linux. They might not work, right?
esp. given the speed at which Hurd/Gnumach seems to move
maybe it's not really clear what I'm asking
and the error message saying
[ 1.0100050] panic: rumpuser_clock_sleep failed with error 22
is pretty suspicious wrt those clock patches
a newer version of the kernel is not supposed to break older userland binaries
linux takes a lot of care about that, and reverts whatever breaks that
we also try that in gnumach, though there's much less testing of it
yes, but what about hurd/gnumach?
alright, that's what I was wondering
see the various pieces of code if (foo() == -1 && errno = EMIG_ID_BOGUS) foo_old()
I'll see if updating the bootstrap solves the native compilation problems we have
thanks!
using debian salsa's glibc time patches rumpdisk still crashes, but differently
that might be good news?
ACTION sends mail...
that took me 5h30' to build...
hey hurd people!
I tried a grep -r command in a httpfs node to demonstrate to a friend some of the issues that it has...
well the fsck saved my bacon!
kudos to everyone for making this OS pretty stable!
gnucode: +1
:)
US