***Server sets mode: +nt
***Server sets mode: +nt
<damo22>youpi: where do i get the glibc_2.31.orig.tar.gz tarball ? <damo22>i tried the one on ftp watch file <damo22>$ make -f debian/rules.d/tarball.mk get-orig-source ? <jma>So I tried to compile the git master debian hurd, it compiled and install smoothly. (I installed hurd_0.9 and hurd-libc0.3 packages). However, when it boots, it says it cannot find /lib-exec/console-run, and gets stuck in a boot loop <jma>any hint on how to fix it? I have a ubuntu live iso, so I can access the root file system on hurd. <jma>oh, console-run is in /sbin. but why does hurd look for it in /libexec? <damo22>jma: hurd uses "translators" which are set via special gnu.* xattributes on particular files on an ext2 filesystem, without setting these up, you can't create a bootable system <damo22>youpi: while compiling glibc i got "no more room in df7be558 ((...i386-libc/elf/ld.so.1(2669))" is that expected? <jma>damo22: yes I understand that. But the git debian-hurd looks for console-run in /libexec, but it is installed in /sbin/ <damo22>there is no /libexec on my hurd system <jma>I know. There isn't one on mine too. But somehow the path is hard coded in startup/startup.c <jma>I just copied the files into /libexec, and I am boot into a what seemed to be a single user console. <youpi>damo22: as I said in my mail you don't need to rebuild glibc since I triggered a rebuild, versioned 2.31-1+b1 <youpi>damo22: yes, some glibc tests do try to allocate more that the virtual space allows <youpi>for jma: did you really use the debian package? It has patches, which you have to apply with dh_quilt_patch, but that'd be done by dpkg-buildpackage anyway. you *don't* want to use ./configure && make && make install, that'd screw everything up since debian's file hierarchy doesn't necessarily matches upstream's <youpi>notably, as you have seen, there is no /libexec on Debian <youpi>that's a disagreement between the various parties (Debian, GNU, the FHS) <youpi>see the libexec.patch in debian/patches <youpi>(and no, such kludge is not specific to the hurd, you would really *not* want to use ./configure && make && make install for glibc for instance, that'd bring mayhem) <damo22>youpi: oh, is glibc 2.31-1+b1 installable from anywhere? <youpi>since I did it yesterday, it's already on all mirrors <youpi>damo22: oh, btw, the gnumach support is missing one thing: register to get a dead port notification, so as to automatically release the irq if the translator dies <youpi>currently the intr_thread looks for that, but it's not guaranteed to wake up timely <damo22>youpi: implicit declaration of function 'device_open' , device_intr_* and vm_allocate_contiguous... trying to compile rumpkernel with new rpcs, i have installed gnumach-dev and libc0.3 <damo22>do i need to #include <device/device.h> ? <youpi>you need libc0.3-dev also for the headers <youpi>you need to include the headers, yes ***foggy68 is now known as foggy67
<Pellescours>youpi: for multiboot2 support should I keep the multiboot1 support and add an option in configure ? Or don't take care and only support multiboot2 ? <youpi>don't we need to support both at the same time? <youpi>to be bootable from bootloaders that only support multiboot1 <Pellescours>okay, so I keep multiboot1 and multiboot version is choosen at compile time <youpi>no, we want to support both at the same time <youpi>so people don't have to know whether to build for multiboot1 or 2 <damo22>ahcisata0 at pci0 dev 31 function 2: vendor 8086 product 2922 (rev. 0x02) <damo22>panic: rumpuser_clock_sleep failed with error 22 <Pellescours>understand but I don't know if it's possible, I'm not sure we can put multibbot1 header and multiboot2 header in the kernel image. Multiboot2 is not backward compatible with multiboot1 <youpi>err, ok, but how are other OSes doing it? <damo22>i dont know why we care about UEFI, even coreboot does not have a fully supported UEFI payload <damo22>there is tianocore, but i dont think it works out of the box <damo22>the problem is, one day hardware manufacturers will drop legacy support, then coreboot will have to think about supporting it properly ***Server sets mode: +nt
***Server sets mode: +nt
<damo22>youpi: where is the source for libpciaccess 0.16-1+hurd.4 <damo22>i have a feeling its missing a critical patch ***Grimler_ is now known as Grimler