http://blog.gmane.org/gmane.os.hurd.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.os.hurd.bugs/21864 <pre>Hi! We've been seeing this on darnassus several times: try to allocate a PTY (log in via SSH, or start screen, etc.), and get a »No more PTYs« message. Now the same happend on flubber: I could log in via SSH, but starting screen failed. I did a »ls -l /dev/tty* /dev/pty*« (which will start all translators due to »stat«ing the nodes) -- and then I was able to start screen. Strange? Grüße, Thomas </pre> Thomas Schwinge 2012-05-25T09:34:45 http://comments.gmane.org/gmane.os.hurd.bugs/21859 <pre>Hi, currently, sendto() crashes when the specified addr is NULL; the attached patch fixes it making sendto() with NULL addr behave as it would be a plain send(). Thanks, </pre> Pino Toscano 2012-05-20T20:58:24 http://comments.gmane.org/gmane.os.hurd.bugs/21857 <pre>Hi, while configuring/installing grub-pc from debian, the kernel panics in the way attached in the screenshot. Riccardo </pre> Riccardo Mottola 2012-05-19T14:15:19 http://comments.gmane.org/gmane.os.hurd.bugs/21855 <pre>Hi, while configuring/installing grub-pc from debian, the kernel panics in the way attached in the screenshot. Riccardo </pre> Riccardo Mottola 2012-05-19T14:13:19 http://comments.gmane.org/gmane.os.hurd.bugs/21854 <pre>Hello, One nifty feature of userland drivers is that you can easily restart them by just making the translator away. However, that makes pfinet away, as well as all current network connexions and listening servers. But pfinet doesn't really need to exit: it could just reopen the network device after e.g. 1s delay, reconfigure it, and continue as if nothing happened. Could somebody have a look? Samuel </pre> Samuel Thibault 2012-05-19T12:45:58 http://comments.gmane.org/gmane.os.hurd.bugs/21848 <pre>Hi, I attach a screenshot on how my kernel panics when I just "ping" localhost. I provide a "screenshot" since I had to uninstall any ssh, telnet or login daemon to be able to boot. This happens after the last debian update I was doing. dpkg -l | grep hurd reports: 20120408-3 Any hints? Riccardo </pre> Riccardo Mottola 2012-05-15T22:35:02 http://comments.gmane.org/gmane.os.hurd.bugs/21847 <pre>So, I have gotten this patch back to where Barry had it in 2008: It needs testing. Specific changes that I have made are to remove the need for condition_implies from console-client, pfinet, term, and trans. I, mostly, followed the pattern set by Vicente in libpipe. (Which was in a strange state in Barry's patch.) I also audited uses of trylock due to the return values changing from cthreads to pthreads. The only questionable piece of code is marked "BDD - Is this sane?" in ufs/sizes.c. I think Barry's replacement is correct. Compiling notes: The patch should apply cleanly to HEAD as of May 14, 2012. You need an implementation of hurd_condition_wait in libpthread: I will attach Vicente's, which he put in sysdeps/hurd. I had to comment out the declaration of hurd_condition_wait in /usr/include/cthreads.h for the new one to compile. I had to give the absolute path to libpthread2.a in libpthread.a to get the linker to link to it. Without doing so, the linker would use the libpthread2.a somewhere in /lib/, a</pre> Thomas Thomas 2012-05-15T22:53:40 http://comments.gmane.org/gmane.os.hurd.bugs/21840 <pre>2005-07-11 Marcus Brinkmann &lt;marcus&lt; at &gt;gnu.org&gt; * hurd/Makefile (routines): Add sysvshm. (distribute): Add sysvshm.h. * hurd/sysvshm.h: New file. * hurd/sysvshm.c: New file. * sysdeps/mach/hurd/bits/stat.h (S_IMMAP0): New macro. (S_ISPARE): Unset the S_IMMAP0 flag. * sysdeps/mach/hurd/ftok.c: New file. * sysdeps/mach/hurd/shmat.c: New file. * sysdeps/mach/hurd/shmctl.c: New file. * sysdeps/mach/hurd/shmdt.c: New file. * sysdeps/mach/hurd/bits/posix_opt.h: Define _XOPEN_SHM to 1. --- hurd/Makefile | 3 +- hurd/sysvshm.c | 96 ++++++++++++++ hurd/sysvshm.h | 47 +++++++ sysdeps/mach/hurd/bits/posix_opt.h | 2 + sysdeps/mach/hurd/ftok.c | 43 +++++++ sysdeps/mach/hurd/shmat.c | 78 ++++++++++++ sysdeps/mach/hurd/shmctl.c | 132 ++++++++++++++++++++ sysdeps/mach/hurd/shmdt.c | 51 ++++++++ sysdeps/mach/hurd/shmg</pre> Samuel Thibault 2012-05-12T18:01:00 http://comments.gmane.org/gmane.os.hurd.bugs/21839 <pre>This adds TLS support to GNU/HURD. Using it to replace threadvar will be part of another patch. I had to separate the thread state with segments from the thread state without segments: each thread has its own gs segment, which needs to be inherited across fork, etc. I also had to fix some initialization order. 2009-07-30 Samuel Thibault &lt;samuel.thibault&lt; at &gt;gnu.org&gt; * sysdeps/mach/hurd/bits/libc-lock.h [_LIBC - 0]: Include &lt;tls.h&gt; * sysdeps/mach/hurd/tls.h: Include &lt;stdint.h&gt; and &lt;sysdep.h&gt; * include/errno.h (__GNU__): Do not define TLS errno for now. * sysdeps/generic/thread_state.h (MACHINE_NEW_THREAD_STATE_FLAVOR): New macro. * sysdeps/mach/thread_state.h (MACHINE_THREAD_STATE_FIX_NEW): New macro. * sysdeps/mach/i386/thread_state.h (MACHINE_NEW_THREAD_STATE_FLAVOR): New macro, defined to i386_THREAD_STATE. (MACHINE_THREAD_STATE_FLAVOR): Define to i386_REGS_SEGS_STATE instead of i386_THREAD_STATE. (MACHINE_THREAD_STATE_FIX_NEW): New macro, reads segments. * sysdeps/mach/powerpc/thread_state.</pre> Samuel Thibault 2012-05-12T17:27:52 http://comments.gmane.org/gmane.os.hurd.bugs/21828 <pre>In function initialize_pthread in file pthread/pt-alloc.c, you need to initialize the value of have_kernel_resources to zero if the thread structure is not recycled. Following the logic of __pthread_create_internal: we go from __pthread_alloc to __pthread_thread_alloc without touching have_kernel_resources. Then, __pthread_thread_alloc exits immediately if have_kernel_resources is non-zero: not good if we haven't actually allocated these resources. Sorry this isn't a patch, but it is only a one line fix, Thomas D </pre> Thomas Thomas 2012-05-11T00:38:26 http://comments.gmane.org/gmane.os.hurd.bugs/21820 <pre>Hello, As discussed on IRC recently and on the bug-hurd mailing list http://lists.gnu.org/archive/html/bug-hurd/2012-01/msg00004.html and the debian-hurd mailing list http://lists.debian.org/debian-hurd/2012/01/msg00001.html (bug 654381, tests run under fakeroot and . not in PATH) http://lists.debian.org/debian-hurd/2012/01/msg00002.html the icon package FTBFS due to a missing . in PATH. Other architectures does not have this problem. According to Samuel the problem is missing info from glibc to the exec server about $0. In May-June 2010 Emilio Pozuelo monfort proposed a set of patches to glibc and the exec server by adding two new RPCs http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00002.html However, that patch was considered not worth the effort http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00010.html Now when glibc Hurd patches are being considered upstream maybe the set of patches by Emilio can be revised again. In one w</pre> Svante Signell 2012-05-10T09:30:52 http://comments.gmane.org/gmane.os.hurd.bugs/21806 <pre>There is some agitation in libc circles about the state of Hurd support. I'd like to get a lot of the low-hanging-fruit Hurd changes merged into libc ASAP. I've been looking at git://git.sv.gnu.org/hurd/glibc.git and read enough about topgit to have a general sense of how the branches are meant to be used. I've looked at a small handful of the branches and some seem quite trivial to merge. But they are not really merge-ready. Some are completely lacking ChangeLog entries, and I'd rather have these written by the person who made the change than do it myself. Some have incomplete ChangeLog entries (not mentioning every file touched). Probably all are missing proper copyright year updates for the current protocol (which is to collapse down to a single year range ending in 2012). Unless I've been even more remiss than I thought I'd been, some of these changes were never posted for my review at all. I guess I was sufficiently remiss for a long time that people could reasonably have given up, and I'm sorr</pre> Roland McGrath 2012-05-09T20:57:38 http://comments.gmane.org/gmane.os.hurd.bugs/21798 <pre>Hello, (From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670478 ) cp/parent-perm-race tries to copy a fifo with the --copy-contents option. The problem is that cp still uses O_NOFOLLOW in that case, strace shows: open("mode/fifo", O_RDONLY|O_NOFOLLOW) O_NOFOLLOW is actually normally meant for security, to avoid attacks through symlink redirection. In that case, the Hurd thus disables translators too, to avoid any rogue translator that would achieve the same kind attack as symlink redirection. But then --copy-contents can not work, since the fifo thus can not work (it's a translator that implements it). I don't think either the Hurd or coreutils will want to change their behavior, so could the test be disabled on GNU/Hurd? Samuel </pre> Samuel Thibault 2012-05-08T18:38:16 http://comments.gmane.org/gmane.os.hurd.bugs/21794 <pre>Hello, There's currently no way to know whether netdde found a network device, because devprobe only works with mach devices. It should however not be hard to extend it to work with netdde: it should be a matter of doing in devprobe something like commit d3ad9490749fe330bea91c0027a0c8319476cac0 in pfinet, see below. Could someone have a look? Samuel commit d3ad9490749fe330bea91c0027a0c8319476cac0 Author: Samuel Thibault &lt;samuel.thibault&lt; at &gt;ens-lyon.org&gt; Date: Sun Feb 19 05:32:36 2012 +0100 Make pfinet try both a filepath and kernel device pfinet/ethernet.c (ethernet_open): Try to file_name_lookup() the device as filepath before opening the Mach device. diff --git a/pfinet/ethernet.c b/pfinet/ethernet.c index dab5c56..f366919 100644 --- a/pfinet/ethernet.c +++ b/pfinet/ethernet.c &lt; at &gt;&lt; at &gt; -166,14 +166,33 &lt; at &gt;&lt; at &gt; ethernet_open (struct device *dev) mach_port_set_qlimit (mach_task_self (), edev-&gt;readptname, MACH_PORT_QLIMIT_MAX); - err = get_privileged_ports (0, &amp;master_device); - if (err) -</pre> Samuel Thibault 2012-05-05T12:27:09 http://comments.gmane.org/gmane.os.hurd.bugs/21793 <pre>I've applied Barry's patch, and removed all cthreads references that I can find (in the code that gets compiled). I compiled everything in the source tree, so I clobbered the linker script version of libpthread.a. In attempting to run ext2fs.static, I get an assertion failure in pthread (somewhere). I renamed the library and unclobbered the linker script, and am now trying to just recompile ext2fs.static. However, when I do I get errors about undefined references to hurd_condition_wait. That function is in libpthread2.a, so why can it not be found now that we're going through the linker script? Thomas D </pre> Thomas Thomas 2012-05-03T19:27:52 http://comments.gmane.org/gmane.os.hurd.bugs/21790 <pre>So, mach-defpager "wires" all of its threads. What exactly does that mean? I think the headers are kind-of sketchy. They do say that in GNU all threads are wired, will this apply to pthread threads, too? Nextly, it uses cthread_data to store a pointer to a thread-specific buffer that it uses in paging. As I see it: all threads are created when the pager starts up, and no threads are created afterward. Thus, I could achieve the same result by using a hash to map between the thread handles and the buffer pointers. Would this be a good idea/efficient? Mainly, I just want your thoughts. I'll leave it at this... Thomas D </pre> Thomas Thomas 2012-04-30T23:30:00 http://comments.gmane.org/gmane.os.hurd.bugs/21789 <pre>Hi, attached there is a patch to make Mach's nanosleep() (used by Hurd) a bit more POSIX compliant: * check for validity of the `requested_time' parameter * return EINTR when interrupted * modify correctly the `remaining' parameter only when interrupted Thanks, </pre> Pino Toscano 2012-04-28T15:29:00 http://comments.gmane.org/gmane.os.hurd.bugs/21780 <pre>Hi, attached there is a patch to fix few issues in Hurd's ptsname_r(), mostly checking for more error conditions and making sure to set as errno and return the proper values on error conditions. Thanks, </pre> Pino Toscano 2012-04-27T10:44:10 http://comments.gmane.org/gmane.os.hurd.bugs/21779 <pre>Hi, attached there is a patch to fix few issues in Hurd's getlogin_r(): avoid a static buffer, and check for buffer shorter than necessary. Thanks, </pre> Pino Toscano 2012-04-27T10:44:03 http://comments.gmane.org/gmane.os.hurd.bugs/21778 <pre>Hi, attached there is a patch to fix a couple of issues with Hurd's getgroups(), namely when the requested number is &lt; 0 or when it is &gt; 0 but less than the actual number of groups that would be returned (this case is handled by simply returning the first n groups, instead of failing). Thanks, </pre> Pino Toscano 2012-04-27T10:43:43 http://comments.gmane.org/gmane.os.hurd.bugs/21775 <pre>Hi! I won't be available for one week starting today (completely, without Internet access, huh) :-) and the two weeks after won't be much better. After that, my focus will be GSoC and glibc. Grüße, Thomas </pre> Thomas Schwinge 2012-04-27T06:26:03 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.hurd.bugs