Source for grub 2.06-13+hurd.2 ?
Greetings, The Hurd kernel in unstable wants a GRUB version higher than 2.06-13+hurd.2 yet neither unstable or experimental have that. Where can I find it? Thanks! Martin-Éric
Re: proc leaking
Hello, Samuel Thibault, le mer. 01 nov. 2023 16:06:57 +0100, a ecrit: > Samuel Thibault, le mer. 01 nov. 2023 15:35:00 +0100, a ecrit: > > Samuel Thibault, le mer. 01 nov. 2023 13:14:17 +0100, a ecrit: > > > Samuel Thibault, le mer. 01 nov. 2023 01:50:40 +0100, a ecrit: > > > > Samuel Thibault, le mar. 31 oct. 2023 04:40:43 +0100, a ecrit: > > > > > (it looks like there are memory leaks in proc, its vminfo keeps > > > > > increasing). > > > > > > > > It seems 64bit-specific: the program below makes proc leak memory, 100 > > > > vminfo lines at a time. Possibly __mach_msg_destroy doesn't actually > > > > properly parse messages to be destroyed, so that in the error case the > > > > server leaks non-inline data? Flavio, perhaps you have an idea? > > > > > > I don't think we have the kernel-to-user equivalent for > > > adjust_msg_type_size? So that we end up pushing twice too much data to > > > userland for port arrays? > > > > I found and fixed the allocation issue in the kernel. > > It seems proc is still leaking, but on the heap this time. This is not > 64bit-specific, the same simple reproducer triggers it: > > while [ "$(echo -n `echo a` )" = a ] ; do : ; done > > or more simply: > > while true ; do echo $(echo -n $(echo a)) > /dev/null ; done I found the issue, it's because of the quiescence support in libports, which assumes that all threads will sooner or later go through a quiescent state (because it finished processing a message). But that's not true, proc doesn't set a thread timeout, and thus some threads can stay indefinitely stuck in receiving messages. And thus the deferred dereferencing used by ports_destroy_right never gets achieved. I'll push a fix. Samuel
keyboard configuration fails
Greetings, Having found an old Pentium, I downloaded the ISO at (/cdimage/ports/12.0/hurd-i386) and installed. The installer failed to configure the keyboard, which shows with incorrect symbols when typing in my user name at account creation. Following reboot, 'dpkg-reconfigure keyboard-configuration' confirms that the debconf answers are what's expected. Despite this, the system remains with a US keyboard. Is this a known issue? Martin-Éric
Re: dhcpcd: FTBFS on Hurd
On Fri, Nov 24, 2023 at 07:50:15AM +0200, Martin-Éric Racine wrote: > Greetings, > > As dhcpcd is slated to replace dhclient as the default DHCP client in > Debian, I've been trying to fix the build on Hurd, which is the only > architecture that has repeatedly FTBFS. Most of this has merely > required fixing missing includes so far. > > Help is welcome, especially from people who have access to a live Hurd > host and who would be able to test the binaries, and also to help me > finalize the port. I'll just point out that, if you haven't done so already, you can easily get GNU/Hurd running in a VM and work on your port in there. I've done so recently to fix the decade+ long FTBFS streak for libvirt and it was quite painless. Despite the different kernel, it *is* still a Debian system in the end, so most of your existing knowledge transfers over perfectly. Thank you for your efforts! They're much appreciated :) -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
