IRC channel logs


back to list of logs

***Server sets mode: +nt
***GeneralDuke1 is now known as GeneralDuke
<damo22>youpi: is there a new libc0.3 coming in the pipeline?
<youpi>damo22: probably yes, but no hurd changes is forecasted, why the question?
<damo22>checking for _hurd_libc_proc_init... no
<damo22>isnt that supposed to be yes?
<youpi>it's in glibc 2.34 only
<youpi>(will be, actually)
<youpi>see the comment log
<damo22>ok, so your fix for 2.34 doesnt apply in previous versions, but something is still broken for /proc/6/stat
<damo22>the rumpdisk process does not get a proper stat
<damo22>root@zamhurd:/proc/5# cat stat
<damo22>5 (pci-arbiter) S 1 1 1 0 0 0 0 0 0 0 27 3 0 0 10 -10 5 0 0 179978240 407 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
<damo22>that one is okay
<damo22>root@zamhurd:/proc/6# cat stat
<damo22>cat: stat: Input/output error
<youpi>no need to repeat that information, we had already investigated inside procfs, it was one piece of proc information that is missing, track with mach_print what is supposed to set it, and why it's not getting set
<damo22>i didnt repeat it, its different now, i think both the arbiter and rumpdisk was broken last time
<youpi>ok so you need to track down inside procfs again
<damo22>jlledo has a branch of hurd for pci device mapping, it would be good if he rebases it
<damo22>ok i will investigate procfs
<damo22>S_proc_mark_important() is hitting EPERM
<damo22>twice instead of once
<damo22>probably because rumpdisk is not a child of startup
<damo22>is --libexecdir supposed to be /usr/libexec on debian?
<youpi>it is
<youpi>or /usr/lib/<triplet>/libexec if useful
<damo22>thanks for fixing the hardcoded paths
<damo22>now i can build debian compatible startup without adding patches
***Emulatorman_ is now known as Emulatorman