IRC channel logs
2023-05-13.log
back to list of logs
<janneke>ACTION tries to upgrate the hurd sources to latest git in an attempt to sidestep the mach-defpager problem and stubbles upon the weirdest errors <janneke>util/atoi.c:96:15: error: unknown type name ‘u_char’ <janneke>ACTION keeps patching for now, but whut? <janneke>hmm, it's _POSIX_SOURCE that's not defined in include/sys/types.h <janneke>and __KERNEL_STRICT_NAMES being defined in linux/dev/include/linux/types.h <janneke>linux/src/drivers/net/de4x5.h:898: warning: "FALSE" redefined <janneke>test -s gnumach-undef-bad: puts, putchar <biblio>luckyluke: I tested with kdb. In can see the fault is from acpi user space. I am not sure if it is before loading acpi ELF or inside acpi main function. I could not build acpi.static in current HURD code. <biblio>EX_WRONG_ARCH 6001 /* valid executable, but wrong arch. */ <janneke>FWIW jpoiret civodul; this doesn't even build: <janneke>4e497b00ad gnu: gnumach-headers: Update to 1.8-0-8cc2ed2eec. <janneke>b17e122109 gnu: mig: Update to 1.8-0-g04bfe7a912. <janneke>=> <janneke> test -s gnumach-undef-bad: puts, putchar, ... and more <janneke>so jpoiret, quite an achievement you found a set of package versions that work... <jpoiret>janneke: yes, newer hurd requires a newer glibc, which requires newer mig. I was pretty lucky to find something that builds, but we don't really know if the set of versions I chose was ever supposed to run properly <janneke>i guess we shouldn't complain, it's prolly a sign of active development; the hurd<->glibc dependency is especially tricksy i guess <janneke>jpoiret: so, i tried to bisect a bit, reverting your patches one by one, upgrading to newer versions, but am a bit at loss right now <jpoiret>janneke: I'm currently trying to build a newer set of packages with glibc 2.37, and cleaning up some messy stuff like hardcoded --host=i586-pc-gnu arguments <janneke>jpoiret: nice, the forward flight, i like it <gnucode>since the hurd project no longer plans to have a 64 bit kernel with a 32 bit userspace...is the hurd project still interested in portable RPC interfaces? <gnucode>Just out of curiosity what is the usefulness in having "mig portable rpc declarations"? <gnucode>open_issues/mig_portable_rpc_declarations <gnucode>hmmm looks like "package-list-packages" crashes emacs on the console on the Hurd. <gnucode>or maybe not crashes it, but does some weird things so that I had to force kill emacs <gnucode>but it looks like debian has magit packaged to no worries either way! <biblio>does anyone know how to build acpi.static ? <jpoiret>anyone would be willing to lend a hand to the Guix port of Hurd? After recently upgrading to glibc 2.35 and gcc 11, I had to resort to ugrading mig/gnumach/hurd to make it build, but now it's just not booting properly. It's hanging while trying to spawn mach-defpager, and I don't really know what's happening/why <jpoiret>it seems it's just waiting on some msg, but I don't know how to debug further <biblio>jpoiret: for gnumach you may try ../configure --enable-kdb (not sure it will help.) <jpoiret>We have kdb enabled, that's how I'm seeing that every thread is just waiting on some message <jpoiret>looking at the debian packaging there seems to be a couple of patches applied on top, but we mostly do the same boot-up process <jpoiret>it may be that we forgot to start an essential server but I'm not seeing anything right (it doesn't help that I can't find any doc on what is needed for the pager) <jpoiret>Being able to inspect the IPC from kdb would be a start i think, but I don't know how to do that <biblio>jpoiret: could you please check if you have acpi.static present in your hurd build. <biblio>jpoiret: please try to install libacpica-dev and try to build hurd again. it should generate acpi.static as well <biblio>jpoiret: make acpi (full hurd is not needed i think) <jpoiret>biblio: i'm using Guix to build Hurd. Are you saying a static acpi is important here? <jpoiret>I would've expected it to not really matter at this point <biblio>jpoiret: I was able to boot with acpi and ext2fs modules. once I skipped acpi - i did not manage to get login prompt. It could be my local config issue. <jpoiret>didn't really help after setting those translators <jpoiret>well, just got it to boot, and I think that it comes from a very stupid misconfiguration on our part :) <jpoiret>I haven't tried to remove acpi from the default translators yet but I don't think that it was our original issue <biblio>jpoiret: i was able to boot with ext2fs without acpi.