summaryrefslogtreecommitdiff
path: root/open_issues
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues')
-rw-r--r--open_issues/e2fsck_i_file_acl_hi.mdwn5
-rw-r--r--open_issues/libpthread_dlopen.mdwn14
-rw-r--r--open_issues/perl.mdwn13
-rw-r--r--open_issues/runit.mdwn57
-rw-r--r--open_issues/sync_but_still_unclean_filesystem.mdwn5
-rw-r--r--open_issues/virtualbox.mdwn30
6 files changed, 56 insertions, 68 deletions
diff --git a/open_issues/e2fsck_i_file_acl_hi.mdwn b/open_issues/e2fsck_i_file_acl_hi.mdwn
index f055babe..d03b733c 100644
--- a/open_issues/e2fsck_i_file_acl_hi.mdwn
+++ b/open_issues/e2fsck_i_file_acl_hi.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -34,4 +34,5 @@ IRC, unknown channel, unknown date.
<youpi> k
<antrik> but it's always passive translator nodes
-This is due to an erroneous read/write from e2fsck, see http://sourceforge.net/tracker/?func=detail&aid=3379227&group_id=2406&atid=102406
+This is due to an erroneous read/write from e2fsck, see
+<http://sourceforge.net/tracker/?func=detail&aid=3379227&group_id=2406&atid=102406>.
diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn
index 0cd761f2..0d3628ec 100644
--- a/open_issues/libpthread_dlopen.mdwn
+++ b/open_issues/libpthread_dlopen.mdwn
@@ -15,7 +15,7 @@ IRC, OFTC, #debian-hurd, 2011-07-21.
<youpi> there's one known issue with pthreads
<youpi> you can't dlopen() it
-[ if the main application is not already linked against it ]
+... if the main application is not already linked against it.
<youpi> which also means you can't dlopen() a module which depends on it if
the main application hasn't used -lpthread already
@@ -43,12 +43,12 @@ The fix thus being: link the main application with -lpthread.
The same symptom appears in an odd case, for instance:
-buildd@hurd:~$ ldd /usr/bin/openjade
- libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000)
- libosp.so.5 => /usr/lib/libosp.so.5 (0x01044000)
- libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x01221000)
- libnsl.so.1 => /lib/i386-gnu/libnsl.so.1 (0x01232000)
-...
+ buildd@hurd:~$ ldd /usr/bin/openjade
+ libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000)
+ libosp.so.5 => /usr/lib/libosp.so.5 (0x01044000)
+ libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x01221000)
+ libnsl.so.1 => /lib/i386-gnu/libnsl.so.1 (0x01232000)
+ [...]
openjade links against *both* libthreads and libpthread. The result is that libc
early-initializes libthreads only, and thus libpthread is not early-initialized,
diff --git a/open_issues/perl.mdwn b/open_issues/perl.mdwn
index c7428cb5..45680328 100644
--- a/open_issues/perl.mdwn
+++ b/open_issues/perl.mdwn
@@ -10,16 +10,13 @@ License|/fdl]]."]]"""]]
[[!meta title="Foster Perl programming"]]
-A dependency loop in Debian GNU/Hurd currently leads to
+[[!template id=note text="""**2011-08**. A dependency loop in Debian GNU/Hurd
+currently leads to: *Could not perform immediate configuration on 'perl'*.
+Easy workaround:
-`Could not perform immediate configuration on 'perl'`
-
-Simply use
-
-`apt-get install perl perl-base -o APT::Immediate-Configure=false`
-
-to break the loop.
+ # apt-get install perl perl-base -o APT::Immediate-Configure=false
+"""]]
Resolve issues uncovered by Perl's test suite, and enable Hurd-specific
diff --git a/open_issues/runit.mdwn b/open_issues/runit.mdwn
index 6b336ef7..659b81ea 100644
--- a/open_issues/runit.mdwn
+++ b/open_issues/runit.mdwn
@@ -1,12 +1,13 @@
-[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2011 Free Software Foundation,
+Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
-is included in the section entitled
-[[GNU Free Documentation License|/fdl]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
[[!tag open_issue_porting]]
@@ -26,36 +27,24 @@ Originally answered by Samuel Thibault:
Usual issue with rpctrace: it does not support fork().
-I've checked a backtrace in gdb, got this:
-
- 0x0105af6c in mach_msg_trap ()
- at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-
-1 0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140,
- timeout=1000020, notify=0) at msg.c:110
-
-2 0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0,
- timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324
-
-3 0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48
-
-4 0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29
-
-5 0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543
-
-
-and main() shows up as:
-
- sig_unblock(sig_term);
-
- sig_unblock(sig_child);
-
- -> iopause(x, 2 +haslog, &deadline, &now);
-
- sig_block(sig_term);
-
- sig_block(sig_child);
-
+ I've checked a backtrace in gdb, got this:
+
+ 0x0105af6c in mach_msg_trap ()
+ at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
+ 1 0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140,
+ timeout=1000020, notify=0) at msg.c:110
+ 2 0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0,
+ timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324
+ 3 0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48
+ 4 0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29
+ 5 0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543
+
+ and main() shows up as:
+
+ sig_unblock(sig_term);
+ sig_unblock(sig_child);
+ -> iopause(x, 2 +haslog, &deadline, &now);
+ sig_block(sig_term);
+ sig_block(sig_child);
So it simply looks like the known "signals don't interrupt select" bug.
-
diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn
index 8a0b1d49..c8a37169 100644
--- a/open_issues/sync_but_still_unclean_filesystem.mdwn
+++ b/open_issues/sync_but_still_unclean_filesystem.mdwn
@@ -33,6 +33,5 @@ Of course, [[hurd/translator/ext2fs]] is meant to be doing this to-disk
synchronization internally upon translator shutdown, but evidently it doesn't
in all cases.
- Apparently diskfs simply does not set filesystem as readonly:
-
- http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00024.html
+Apparently diskfs simply does not set filesystems as read-only:
+<http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00024.html>.
diff --git a/open_issues/virtualbox.mdwn b/open_issues/virtualbox.mdwn
index 246313ff..9440284f 100644
--- a/open_issues/virtualbox.mdwn
+++ b/open_issues/virtualbox.mdwn
@@ -8,15 +8,16 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
-[[!meta title="xattr: extended attributes"]]
-
[[!tag open_issue_gnumach]]
Running GNU Mach in VirtualBox crashes during initialization.
IRC, freenode, #hurd, 2011-08-15
- <BlueT_> HowTo Reproduce: 1) Use `reboot` to reboot the system. 2) Once you see the Grub menu, turn off the debian hurd box. 3) Let the box boot normally, and wait for the error/crash/reboot. 4) The error/crash will happen twice and it's reboot automatically. The 3rd boot will success.
+ <BlueT_> HowTo Reproduce: 1) Use `reboot` to reboot the system. 2) Once
+ you see the Grub menu, turn off the debian hurd box. 3) Let the box boot
+ normally, and wait for the error/crash/reboot. 4) The error/crash will
+ happen twice and it's reboot automatically. The 3rd boot will success.
<BlueT_> root@dhurd:/boot# addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x106c93 0x1556a5 0x152c54
<BlueT_> copyoutmsg
@@ -28,8 +29,8 @@ IRC, freenode, #hurd, 2011-08-15
i386/i386/locore.S:1289 is
- movl $USER_DS,%eax /* use user data segment for accesses */
-=> mov %ax,%es
+ movl $USER_DS,%eax /* use user data segment for accesses */
+ => mov %ax,%es
State is
@@ -66,14 +67,14 @@ IRC, freenode, #hurd, 2011-08-15
i386/i386/locore.S:527 is:
-_return_from_kernel:
-_kret_popl_gs:
- popl %gs /* restore segment registers */
-_kret_popl_fs:
- popl %fs
-_kret_popl_es:
-=> popl %es
-_kret_popl_ds:
+ _return_from_kernel:
+ _kret_popl_gs:
+ popl %gs /* restore segment registers */
+ _kret_popl_fs:
+ popl %fs
+ _kret_popl_es:
+ => popl %es
+ _kret_popl_ds:
cs: 0x8
ds: 0x10
@@ -93,5 +94,6 @@ _kret_popl_ds:
efl: 0x10216
<youpi> looks again like a $USER_DS issue
- <youpi> what's interesting is that that one means that $USER_DS did load in %es fine at least once
+ <youpi> what's interesting is that that one means that $USER_DS did load in
+ %es fine at least once
<youpi> and it's the reload that fails