IRC channel logs

<Zopolis4>is there a good way to cross-compile for hurd? software emulation is too slow to be practical

<damo22>i compile rumpkernel inside hurd with kvm

<damo22>it doesnt take that long

<Zopolis4>yeah i dont have kvm

<damo22>why not

<Zopolis4>or any form of hardware acceleration

<Zopolis4>no admin

<damo22>err

<damo22>if youre in my city i can give you a x230 laptop to hack on hurd

<Zopolis4>i mean

<Zopolis4>i could just bite the bullet and get an external hard drive to boot hurd on my t520

<Zopolis4>i just prefer workingo n this laptop

<damo22>you prefer windows?

<Zopolis4>i develop on wsl

<Zopolis4>windows as it stands is my main os

<Zopolis4>had bad experiences with ubuntu in the past and have never sucesfully installed debian on anything

<damo22>i cant really help you if you dont want to be helped :P

<damo22>but i heard vmware has a windows hw accel thing

<damo22>not that i recommend proprietary software but it might get you hacking on hurd

<damo22>vmware workstation

<jab>Zopolis4: Have you tried guix?

<jab>guix system?

<jab>It can be a bit hard to get installed, but it's been really rock solid for me.

<youpi>Zopolis4: cross-compilation is possible, though not simple, and only ever tried from linux, not from windows

<youpi>(I guess you don't have wsl2)

<Zopolis4>no i do

<Zopolis4>oh gcc isint building atm

<Zopolis4>something about undefined references to pthread_once

<youpi>yes, see patch sent to gcc-patches with bug-hurd in cc

<Zopolis4>ah ok

<damo22>youpi: i saw you sent in a patch for glibc (ifrtreq_t), what about the IOT and 2x IOW , where are they supposed to go?

<youpi>ah, that would be there as well

<damo22>i think it got squished from the commit message because it starts with #

<youpi>no I just copied by hand

<youpi>and had to fix IFNAMESIZ

<youpi>the usual troubles of integrating to upstream

<damo22>:

<youpi>if not tested before

<damo22>:\

<Zopolis4>wait arent the debian buildbots cross-compiling?

<youpi>no

<Pellescours>I ran hurd using piixide (I build rumpdisk without ahcisata), and I can say that it’s slow. I think it does not use DMA, I don’t remember the message but there is one saying error configuring DMA (or probing DMA).

<Zopolis4>for https://blog.darknedgy.net/technology/2015/07/25/0/, given that hurd uses regular glibc now (or so ive heard), will just the regular glibc sources work?

<Zopolis4>instead of the now 404 deb pacakge

<youpi>Zopolis4: it will work, yes, but not on a debian system

<youpi>because paths, conventions, linker etc. have slight differences

<youpi>"not on a debian system": I mean, don't run make install

<youpi>but you can run make check yes

<youpi>(I don't understand what you mean by "now 404 deb package")

<Zopolis4>the glibc link here used to lead to a deb package but it now 404s https://www.irccloud.com/pastebin/b5qvAxQ8/

<Zopolis4>is the hurd triplet i686-pc-windows-gnu?

<Zopolis4>because that seems wrong

<youpi>(link): ah, ok, that was indeed a sad thing that he had to point to a version-specific piece which is since long dead. So, yes, for a cross-build adventure you can just use upstream source

<youpi>the triplet is i686-pc-gnu

<youpi>no reason for putting windows in there :)

<Zopolis4>oh sorry copypaste erorr

<Zopolis4>hold on so if linux is i686-linux-gnu because arch-kernel-os and hurd is i686-pc-gnu whats going on there

<youpi>"triplets" are a mess

<youpi>it's actually i686-pc-linux-gnu

<youpi>it's not kernel-os

<youpi>it's os

<youpi>linux-gnu is the os part

<youpi>it's arch-vendor-os

<youpi>so i686-pc-gnu, and i686-pc-linux-gnu where linux-gnu is the os

<Zopolis4>huh

<Zopolis4>ig because the gnu system or whatever

<youpi>linux-gnu because the os is not only linux, and it's not only gnu

<youpi>while hurd really is only gnu

<Zopolis4>because linux is linux kernel and gnu tools whereas hurd is gnu kernel and gnu tools

<Zopolis4>or gnu kernel servers running on the mach microkernel

<youpi>damo22: I hadn't realized that you had put SIOCADDRT in the 'i' class

<youpi>we really want to stick to BSD which puts it in the 'r' class

<youpi>i.e. introduce rioctl etc.

<youpi>otherwise we'll get clashes

<Pellescours>usrmerge package fail to configure on upgrade, is someone else having it?

<Pellescours>Ah, I didn’t saw the error on first read:

<Pellescours>FATAL ERROR:

<Pellescours>Both /bin/gcore and /usr/bin/gcore exist.

<Pellescours>is someone know what should I do?

<Pellescours>OH, /bin/gcore is provided by hurd package, and /usr/bin/gcore is provided by gdb

<gnu_srs>Pellescours: Please don't upgrade init-system-helpers, and ban usrmerge/usr-is-merged :D

<gnu_srs>Next step would be a devuan-hurd distro, to revert these changes. And don't forget about dpkg-fsys-usrunmess (from dpkg)

<Pellescours>it worked thanks

<youpi>uh

<youpi>well, the gcore conflict really something we want to fix

<youpi>one way or the other

<youpi>apparently the gdb version doesn't work

<youpi>which happens to be the first one in path

<youpi>so we'd rather ask the gdb maintainer to drop gcore on hurd-i386

<youpi>damo22: I have pushed hurd using the definition from glibc's <net/route.h>

<youpi>now we need to make it use rioctl in addition to the iioctl and tioctl

IRC channel logs

2022-09-21.log