***Server sets mode: +nt
***JBB-xmpp is now known as jbb
***jbb is now known as JBB-xmpp
***JBB-xmpp is now known as jbb
***jbb is now known as JBB-xmpp
***JBB-xmpp is now known as jbb
***jbb is now known as JBB-xmpp
***JBB-xmpp is now known as jbb
***jbb is now known as JBB-xmpp
***JBB-xmpp is now known as jbb
***jbb is now known as JBB-xmpp
<gnu_srs>fsysopts /servers/socket/26 show that ipv4 addresses are used. That does not work with qemu. should I change qemu or /servers? <kilobug>gnu_srs: could be in both from what I know, but qemu offer multiple networking options (different emulated cards, and different topology : bridge, nat, ...) perhaps it'll work with some options and not others ? <gnu_srs>Correction: fsysopts /servers/socket/26 show that ipv6 addresses are used <gnu_srs>Seems like both ipv4 and ipv6 is set up. ssh-ing _from_ the image works fine, but _to_ it fails. /etc/init.d/ssh start does not start the server. <gnu_srs>Cannot start openssh-server! Any ideas? <gnu_srs>Seem like libcrypt.so.1 was a symbolic link to libcrypt-2.25.so shadowing the real libcrypt.so.1.1.0 <gnu_srs>Now when installing exim4-daemon-light it complains on no certificates found, creating a selfsigned certificate? <z3ntu>I'm not sure why the #define SIGCONTEXT is in debug/segfault.c because it wil redefine the macro which is "struct sigcontext" for Hurd and "struct sigcontext *" for all other platforms. And because the new define has a castable types for everything non-Hurd it works but not for Hurd, I'm guessing <z3ntu>youpi: haha you joined like half a minute after my last message, reposting them for you (as you probably know what to do) <z3ntu>I'm not sure why the #define SIGCONTEXT is in debug/segfault.c because it wil redefine the macro which is "struct sigcontext" for Hurd and "struct sigcontext *" for all other platforms. And because the new define has a castable types for everything non-Hurd it works but not for Hurd, I'm guessing <youpi>what happens is that the parameters of the signal handler depends whether SA_SIGINFO was set or not <youpi>the default SIGCONTEXT content is for when SA_SIGINFO is not set <youpi>segfault.c redefines it because it sets SA_SIGINFO <AlmuHS>I'm checking the " if (processor->state == PROCESSOR_IDLE) {" case in thread_setrun() function of sched_prim.c . But I have some questions <AlmuHS>in " if (processor->state == PROCESSOR_IDLE) {" there are a simple_unlock() of pset and processor. But, after this code, these simple_unlock() are done again <AlmuHS>mmm... I see a return after this block, but this return don't have any data <AlmuHS>Is a "return;" without any variable <AlmuHS>furthermore, this function is "void", so this return is wrong here <youpi>it's not duplicated, it's done before the return <youpi>not having data is not a problem <youpi>that's what is expected for a function returning void <youpi>but the function still terminates there <AlmuHS>This can be candidate to refactor <AlmuHS>(but I don't risk to refactor It) <AlmuHS>I've just added some prints in " if ((processor = th->bound_processor) == PROCESSOR_NULL) {" case, but It seems don't enter here <AlmuHS>I go to reenable the another prints ***JBB-xmpp is now known as jbb
***jbb is now known as JBB-xmpp
***JBB-xmpp is now known as jbb
***jbb is now known as JBB-xmpp
<z3ntu>youpi: are you planning to make a patch to fix the glibc issue, or do I have to make a dirty patch myself? :) <youpi>I don't plan to, since I don't have the issue, it'll be hard for me to come up with a fix