IRC channel logs

<gnucode>Well it looks like it installed a base debian system...

<gnucode>but when it asked me to set up apt, I again put in "deb.debian.org" and for the director I put in "/debian-ports". It apparently failed to download the file.

<gnucode>maybe the building's firewall is blocking the download...

<gnucode>I'll try not setting up apt.

<gnucode>maybe the installation will proceed.

<gnucode>It seems to be working.

<gnucode>looks like I've got the Hurd installed on my T410. I just now need to copy in my /etc/apt/sources from my T43 and do some updates.

<gnucode>dang. The Hurd on my T410 doesn't appear to be very stable. I logged in (there were weird errors about /dev/tty2 does not exist). Then I did a sudo halt

<gnucode>It started to shut off and I got more errors. /hurd/crash

<gnucode>"/hurd/crash" complained about /dev/hd2, which I believe is my swap partition.

<gnucode>"/hurd/crash" is not complaining about acpi...

<gnucode>It's actually fairly interesting. I keep getting error messages like "/hurd/crash(acpi number)"

<gnucode>The number is currently 20,000.

<damo22>hmm its possible my HP T620 does not work correctly with acpi server because i wrote the bios and may have left out some of the ACPI tables

<damo22>ioapic is broken on AMD

<damo22>--enable-apic crashes early on AMD

<janneke>after updating to glibc-2.38 and possible other changes, i get

<janneke>No rule to make target 'mach/machine/mach_i386.h', needed by 'trivfs_server.o'. Stop.

<damo22>perhaps you need gnumach headers?

<janneke>i have gnumach-headers-cross-i586-pc-gnu-1.8+git20230410/include/mach/i386

<janneke>(but no mach_i386.h in there, only mach_i386.defs and mach_i386_types.h)

<damo22>its possible mig can generate that header from the .defs ?

<janneke>yes, but then -- when and/or why didn't that happen?

<youpi>$ dpkg -S mach_i386.h

<youpi>libc0.3-dev:hurd-i386: /usr/include/i386-gnu/mach/i386/mach_i386.h

<youpi>it's supposed to be shipped by glibc

<janneke>OK, thanks that helps

<janneke>ACTION goes to look

<janneke>hmm, have that too

<janneke>glibc-cross-i586-pc-gnu-2.38/include/mach/i386/mach_i386.h

<damo22>you may be missing a symlink from i386 -> machine ?

<janneke>there must be something broken with cross include flags on our end

<janneke>there's no symlink here: glibc-cross-i586-pc-gnu-2.38/include/mach/

<damo22>autoreconf -fi ?

<janneke>we're building from glibc-2.38.tar.xz

<janneke>ACTION goes to look into guix's glibc build

<damo22>i meant (07:39:39 PM) janneke: No rule to make target 'mach/machine/mach_i386.h', needed by 'trivfs_server.o'. Stop.

<damo22>^ mach/machine/mach_i386.h could be pointed to mach/i386/mach_i386.h

<youpi>you're supposed to have a machine-> i386 symlink

<youpi>(or the converse, depending how you understand symlinks)

<janneke>yes, in the glibc build there should be that symlink, right?

<janneke>i'm afraid that workarounds for 2.37 that we had in place prevented that symlink to be built

<janneke>(workarounds for configuring mach headers)

<jpoiret>what kind of workarounds?

<youpi>it's the gnumach package that creates that symlink

<janneke>%glibc/hurd-configure-flags

<janneke>youpi: interesting...gnumach makes a symlink in a glibc include directory?

<janneke>jpoiret: we may need a (partial) build phase in gnumach-headers, then?

<damo22>it probably makes sense if you have a {arch} kernel you want the symlink to be -> {arch} or something like that, but im just guessing

<jpoiret>janneke: if it's just `make symlink` that should be fine right :p

<youpi>janneke: in all systems but nix & guix, the include directory is shared :)

<janneke>youpi: sure

<youpi>mach creates it for its own headers

<youpi>and glibc installs some headers there too

<janneke>should be no problem

<janneke>jpoiret: iwbn to invoke the proper `make ..' command in the gnumach-header's build phase

<damo22>does anyone know why AMD x86 would have different APIC init than intel x86 ?

<jpoiret>janneke: I think we just need to run `make install-data-hook`

<jpoiret>it's in https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/Makefrag.am

<jpoiret>we can't run the whole make yet because we don't have the toolchain to build gnumach iirc

<youpi>make install-dta

<youpi>grah

<youpi>make install-data

<youpi>the -hook rule is just a part of it

<jpoiret>youpi: that's already what we run for the headers-only package, so it might be that it doesn't do the proper thing

<janneke>jpoiret: giving that a try now

<damo22>s/-hook// might fix it?

<jpoiret>I don't know autotools too well :p

<jpoiret>damo22: no, we run `make install-data`

<damo22>oh

<jpoiret>debugging makefiles is a pain

<janneke>jpoiret: yes, this seems to fix it

<janneke>(invoke "make" "install-data" "install-data-hook")

<youpi>debugging anything complex is a pain

<janneke>thanks, all!

<janneke>(i have the symlink created now, let's see how hurd builds)

<jpoiret>janneke: wrt. the headers package, what's your cmdline to build it?

<janneke>jpoiret: i'm using the toplevel image build

<janneke>./pre-inst-env guix system build --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl

<damo22>youpi: i am concerned that there is a lot of hardware that is non-trivial to drive, and qemu cannot be used to test it because it doesnt emulate everything

<damo22>we need to make it easier to test on real hw

<damo22>i wonder if its possible to set up PXE boot where the server is my development machine and i cross compile gnumach into place

<damo22>then cold boot the target with a serial console connected

<azert>youpi: I was thinking about the hypervisor. I think the Hurd in the long run really needs two of them. The first one would be in kernel like kvm, in a way nvmm is even better since it’s built on a similar architecture as gnumach and uses virtual memory. That’s the hyper visor you’ll really just use to run virtual machines. The second one

<azert>should be a real hypervisor, maybe just xen, active by default on all installations. An extension allowing the Hurd to control this hypervisor in an Hurdish way is envisaged. Ideally this hyper visor can be used by userspace drivers to drive some open source low level firmware part. It might be essential for some hardware, it will keep this out of

<azert>gnumach

<azert>damo22: I think grub can boot from pxe and retrieve all parts from tftp

<azert>damo22: you need to setup dhcp and tftp

<damo22>basically i just want grub to locate the kernel from a network

<azert>Then you just need to setup tftp

<azert>Maybe also dhcp, not sure about that

<azert>How the Hurd gets its ip address otherwise?

<damo22>i can install a pxe client into flash as a coreboot payload

<damo22>then i just set up a pxe server somehow on my laptop and serve grub+gnumach

<azert>Yes should work quite straightforwardly

<damo22>we probably need to make usb com ports work with ucom from rump

<damo22>i think the easiest way to develop gnumach on real hw is going to be having it installed on real hw on one machine (dev) and attached to a target machine with a serial console with coreboot + iPXE bios

<damo22>with a network cable between them

<azert>damo22: if you are just interested in coreboot, I see that there are quite some fancy alternatives to the serial console: https://www.coreboot.org/Console_and_outputs

<azert>Including a network console for some cards, and a speaker based console!

<damo22>i know, i wrote a coreboot port using just a speaker console once

<damo22>but we need to shorten the compile/test cycle for real hardware for gnumach

<damo22>otherwise i will never get anywhere

<janneke>jpoiret: i figured that having gnumach-header creating the machine symlink for glibc would be no problem...

<janneke>...but i was thinking about a profile, where the directories are merged

<janneke>in a container build, we'd need the machine symlink in glibc too, of course

<janneke>ACTION goes to patch the glibc build recipe

<youpi>damo22: you can feed grub via pxe, yes, and then boot the hurd

<damo22>im having trouble compiling iPXE

<damo22>as a coreboot payload

<damo22>because my coreboot port is based on code that has been removed from the tree

<janneke>yay, got past that hurd'le

<solid_black>hi janneke

<janneke>now it fails building libdde_linux26

<janneke>../../mk/binary.inc:217: *** Mode "l4env" is not supported for CPU architecture "". Stop.

<janneke>i guess we need to set ARCH, but to what? (i386 or i586-gnu don't seem to work)

<janneke>hi solid_black

<janneke>ah possibly x86

<solid_black>Debian seems to set it to either amd64 or x86

<janneke>yay, thanks for listening

<janneke>yay, got hurd to (cross) build with glibc-2.38!

<gnu_srs>janneke: :)

<jpoiret>janneke: so, glibc is the one responsible for generating mach_i386.h, no?

<jpoiret>I missed the fact that it's generated by mig

<jpoiret>congrats tho!

<janneke>yes, glibc generates mach_i386.h, but fails to generate the necessary symlink

<gnucode>hello you smart people!

<janneke>that's a bug, if you'd ask me

<jpoiret>I'd say the same :p

<gnucode>sneek: later tell damo22 You said that you "wrote the bios" on your HP T620. What? Did you code your own custom BIOS? How hard was that?

<sneek>Got it.

<gnucode>also, our belated Hurd New Year's party is tomorrow. at 3pm UTC. I'll post the details in #hurd irc channel, but all you'll need is a modern web browser to hang out with us.

<janneke>jpoiret: gnumach will create a symlink, but that's only enough in a legacy FHS environment

<janneke>ACTION is kidding and teasing a bit, but also somewhat serious

<jpoiret>i'm looking at where the rule to generate mach_i386.h is though, but I've got no clue

<janneke>couldn't find it either

<janneke>ACTION grepped glibc for 'mach_.*\.h' but found no makefile hits

<jpoiret>aha https://sourceware.org/cgit/glibc/tree/sysdeps/mach/configure#n270 !

<jpoiret>well, the configure.ac file should be a bit clearer ;p

<janneke>great

<gnucode>sneek: later tell damo22 Nevermind, you were customizing coreboot, which is still pretty cool. I didn't realize that the Hurd could run on an Open Source BIOS. That's good news.

<sneek>Will do.

<jpoiret>youpi: what's the rationale behind https://sourceware.org/cgit/glibc/commit/sysdeps/mach?id=196358ae26aa38a70fb6f19a77311c8a58bff929 ?

<jpoiret>is it because you want to generate both?

<youpi>it's because machine/ may point to i386 while we're building a x86_64 version of glibc, and such

<jpoiret>for cross-builds?

<jpoiret>then how do you handle cross-building programs which refer to mach/machine?

<youpi>for cross-build for instance yes

<youpi>well, the picture is more complex

<youpi>for cross-builds you'd usually have /usr/include/i386-gnu/mach/machine that points to i386/ in which you have mach_i386.h

<youpi>and similar with x86_64

<youpi>of course you'll say that it's dumb not to use machine/

<youpi>the thing is: makefiles have to work in all cases

<youpi>including systems which don't use /usr/include/i386-gnu

<youpi>and there we still want mach_i386.h to get installed properly

<youpi>yes, it's a bit of a mess, that's what backportability is about

<jpoiret>alright! I think for our use case where we know in advance for which target we're building our glibc, and there's no risk of overlap we can revert the above

<jpoiret>ie. we don't need x86_64 when our target is i586-pc-gnu and reciprocally

<gnucode>It sounds like the guix people are doing cool Hurd stuff too. Thanks for that!

<jpoiret>if by doing cool hurd stuff you mean trying to catch up with debian all the time then yes :)

IRC channel logs

2024-01-19.log