IRC channel logs


back to list of logs

***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>patches dont apply
<damo22>$ make -f debian/rules.d/ get-orig-source ?
<damo22>got a build going!
<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/" 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 see the corresponding bug report
<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?
<damo22>my build is still going
<youpi>well, as usual
<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> ?
<damo22>and <mach/gnumach.h> ?
<youpi>you need libc0.3-dev also for the headers
<youpi>you need to include the headers, yes
<youpi>see what I commited for dde
<damo22>i think i got it building
***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
<damo22>rump kernel halting...
<damo22>never seen that before
<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?
<Pellescours>I'm doing research
<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
<youpi>in the same directory?
<youpi>use dget on the .dsc
<damo22>hmm looks okay to me
<damo22>i cant explain the rump failure
<damo22> i have this diff between what i used to have and now
***Grimler_ is now known as Grimler