Minor tweaks.

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