IRC channel logs


back to list of 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>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
<youpi>if not tested before
<Zopolis4>wait arent the debian buildbots cross-compiling?
<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, 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
<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>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>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