fix merge

9 files changed, 96 insertions, 63 deletions

diff --git a/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn b/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn
index 646738b1..1e8c4ef6 100644
--- a/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn
+++ b/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009 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
@@ -9,7 +9,8 @@ is included in the section entitled
 [[GNU Free Documentation License|/fdl]]."]]"""]]
 
 Sometimes it may already be helpful to capture a translator's `stdout` and
-`stderr`, for example like this:
+`stderr`, for example in this situation where [[translator/pfinet]] was
+silently dying all the time, without any console output:
 
     $ sudo settrans -fgap ↩
       /servers/socket/2 ↩
@@ -31,3 +32,7 @@ for appropriate `fflush`es on these, or force them to be line buffered again
 using the appropriate glibc magic (`setvbuf`).  Otherwise you'll see text in
 the output files only if either glibc herself decides to flush (after some KiB
 of text) the after translator exits.
+
+It is a [[!taglink open_issue_hurd]] to decide / implement / fix that
+(all?) running (passive?) translators' output should show up on the
+console / syslog.
diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn
index 1beb53a0..5fd66292 100644
--- a/hurd/porting/guidelines.mdwn
+++ b/hurd/porting/guidelines.mdwn
@@ -170,12 +170,15 @@ This comes from ioctls.  Fixing this is easy if the structure members can be exp
 `#define _IOT_termios /* Hurd ioctl type field.  */ \
   _IOT (_IOTS (tcflag_t), 4, _IOTS (cc_t), NCCS, _IOTS (speed_t), 2)`
 
-because `struct termios` holds 4 members of type `tcflag_ts`, then `NCCS`
-members of type `cc_tsi` and finaly 2 members of type `speed_ts`.
-
-As you can see, this limits the number of kinds of members to 3, and in
-addition to that (see the bitfield described in `ioctls.h`), the third
-kind of member is limited to 3 members.
+The rationale behind is that on the Hurd ioctl numbers actually encode how the
+data should be transferred via RPC: here `struct termios` holds 4 members of
+type `tcflag_ts`, then `NCCS` members of type `cc_tsi` and finaly 2 members of
+type `speed_ts`, so the RPC mecanism will know how to transfer them.
+
+As you can see, this limits the number of contiguous kinds of members to 3, and
+in addition to that (see the bitfield described in `ioctls.h`), the third kind
+of member is limited to 3 members.  This is a design limitation, there is no way
+to overcome it at the moment.
 
 Note: if a field member is a pointer, then the ioctl can't be expressed
 this way, and that makes sense, since the server you're talking to
diff --git a/hurd/running/debian/porting.mdwn b/hurd/running/debian/porting.mdwn
index 10ee4c5c..aa044570 100644
--- a/hurd/running/debian/porting.mdwn
+++ b/hurd/running/debian/porting.mdwn
@@ -17,7 +17,7 @@ Hurd, however, many programs fail to build for various reasons.
 A [list of build failures including error
 messages](http://unstable.buildd.net/buildd/hurd-i386_Failed.html) can be
 found, as well as a [preliminary
-analysis](http://lists.debian.org/debian-hurd/2007/07/msg00000.html) of them and [solutions](http://lists.debian.org/debian-hurd/2007/07/msg00001.html).
+analysis](http://lists.debian.org/debian-hurd/2007/07/msg00000.html) of them and [solutions](http://lists.debian.org/debian-hurd/2007/07/msg00001.html), and some more details in [[hurd/porting/guidelines]].
 
 It might be a good idea to record your intention to port something either in
 the list below or in the [Alioth task
diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn
index a059f3b1..48d87b35 100644
--- a/hurd/running/qemu.mdwn
+++ b/hurd/running/qemu.mdwn
@@ -71,7 +71,7 @@ Now take the number of sectors for the beginning of the partition and multiply i
 
 ## Having QEMU create *virtual FAT disk images*
 
-[Manual](http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC24).
+[Manual](http://www.nongnu.org/qemu/qemu-doc.html#SEC25).
 
 QEMU has a facility to create FAT file systems on-the-fly:
 
@@ -97,7 +97,7 @@ If you just want to access the internet from within QEMU, you can setup pfinet f
     # settrans -afgp /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0
     # echo "nameserver 10.0.2.3" > /etc/resolv.conf
 
-(See also <http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC30>.)
+(See also <http://www.nongnu.org/qemu/qemu-doc.html#SEC32>.)
 
 Outgoing internet connections should just work then.
 
diff --git a/hurd/status.mdwn b/hurd/status.mdwn
index cc303dcf..3ee8ddcf 100644
--- a/hurd/status.mdwn
+++ b/hurd/status.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2001, 2002, 2007, 2008 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2001, 2002, 2007, 2008, 2009 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
@@ -60,42 +60,43 @@ already expect delays; to disappoint them in this way as
 well would be unfortunate. Moreover, it would lessen the
 possibility that they would want to try the Hurd again in the future.
 
-## Usability status 2009-06-11
 
-*(This text is taken from two emails posted on the [[bug-hurd mailinglist|mailing_lists]] 
-by Olaf Buddenhagen)*
-
-I have been using the Hurd for most of my everyday work for some two
-years now. Most of the time it's pretty OK, but occasionally programs
-crash, or the screen session dies, or even the whole system. Also,
-various programs simply don't work at all, or don't work in certain
-situations.
-
-While I have learned to work around many of these issues, I don't
-believe I would be able to use it as my primary system, without having a
-GNU/Linux system running in parallel, as a fallback for all the stuff
-that doesn't work on the Hurd.
-
-My everyday work includes reading/writing email and other texts, preparing and giving
-presentations, text-mode web browsing, viewing pictures, IRC, reading
-PDF documents, programming, and various other random stuff...
-
-[...]
-
-One particular problem for desktop use is the fact that while X does
-work, it works very poorly -- it's not only slow and jerky all the time,
-but also tends to lock up completely. (At least with the local socket
-transport... Haven't tried whether forcing TCP works better.)
-
-Note that while many of the stability problems are simply bugs to fix,
-the system will still be very fragile in the absence of these -- a
-simple port leak is sufficient to kill it within seconds. This is
-something that can't be easily solved. Properly fixing this will require
-a sound resource accounting framework, i.e. very fundamental changes to
-the system... Though I tend to believe that it could be improved at
-least partially, at the expense of flexibility, by enforcing certain
-fixed limits on users, processes etc. like other UNIX systems do.
-
-[...]
-
-[But] unlike a few years back [...] the system is stable enough under load nowadays [...].
+## Usability Reports
+
+### Olaf Buddenhagen, 2009-06-09
+
+> I have been using the Hurd for most of my everyday work for some two
+> years now. Most of the time it's pretty OK, but occasionally programs
+> crash, or the screen session dies, or even the whole system. Also,
+> various programs simply don't work at all, or don't work in certain
+> situations.
+> 
+> While I have learned to work around many of these issues, I don't
+> believe I would be able to use it as my primary system, without having a
+> GNU/Linux system running in parallel, as a fallback for all the stuff
+> that doesn't work on the Hurd.
+> 
+> My everyday work includes reading/writing email and other texts, preparing and giving
+> presentations, text-mode web browsing, viewing pictures, IRC, reading
+> PDF documents, programming, and various other random stuff...
+> 
+> [...]
+> 
+> One particular problem for desktop use is the fact that while X does
+> work, it works very poorly -- it's not only slow and jerky all the time,
+> but also tends to lock up completely. (At least with the local socket
+> transport... Haven't tried whether forcing TCP works better.)
+> 
+> Note that while many of the stability problems are simply bugs to fix,
+> the system will still be very fragile in the absence of these -- a
+> simple port leak is sufficient to kill it within seconds. This is
+> something that can't be easily solved. Properly fixing this will require
+> a sound resource accounting framework, i.e. very fundamental changes to
+> the system... Though I tend to believe that it could be improved at
+> least partially, at the expense of flexibility, by enforcing certain
+> fixed limits on users, processes etc. like other UNIX systems do.
+> 
+> [...]
+> 
+> [But] unlike a few years back [...] the system is stable enough under
+> load nowadays [...].
diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn
index 38cc7911..3a93c6ad 100644
--- a/microkernel/mach/gnumach/debugging.mdwn
+++ b/microkernel/mach/gnumach/debugging.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 2009 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
@@ -14,7 +15,7 @@ Mach has a built-in kernel debugger.
 
 When you're [[running_a_system_in_QEMU|hurd/running/qemu]] you can directly
 [use GDB on the running
-kernel](http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC36).
+kernel](http://www.nongnu.org/qemu/qemu-doc.html#SEC48).
 
 
 Alternatively you can use an approach like this one: add the following code
diff --git a/open_issues/tinyproxy.mdwn b/open_issues/tinyproxy.mdwn
new file mode 100644
index 00000000..9a4a0cfb
--- /dev/null
+++ b/open_issues/tinyproxy.mdwn
@@ -0,0 +1,18 @@
+[[!meta copyright="Copyright © 2009 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]]."]]"""]]
+
+[[!meta title="Problem with using tinyproxy for tunneling HTTPS"]]
+
+`tinyproxy` works fine for HTTP connections, but fails to proxy HTTPS ones:
+
+    ERROR     Jun 12 14:58:51 [20676]: relay_connection: select() error "Interrupted system call". Closing connection (client_fd:7, server_fd:8)
+
+This is supposedly due to the already known select bug, which is a [[!taglink
+open_issue_glibc]].
diff --git a/qemu.mdwn b/qemu.mdwn
index bfd2f1cb..19b5fb9f 100644
--- a/qemu.mdwn
+++ b/qemu.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2005, 2007, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2005, 2007, 2008, 2009 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
@@ -31,6 +32,5 @@ emulation under the [[GPL]].
 
 # External Links
 
-  * <http://fabrice.bellard.free.fr/qemu/>
-  * <http://kidsquid.com/cgi-bin/moin.cgi> QEMU Wiki
+  * <http://www.nongnu.org/qemu/>
   * [Qemu on Windows](http://www.h7.dion.ne.jp/~qemu-win/)
diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn
index 2182f12e..2f8ea542 100644
--- a/user/scolobb.mdwn
+++ b/user/scolobb.mdwn
@@ -82,20 +82,25 @@ For documentation, see [[hurd/translator/unionmount]].
   by the comments in the sources. The goal is to write a more coherent
   documentation.
 
+* **Start with a clean unionfs and implement the `--mount` argument**
+  *(11 Jun)* It was suggested to implement the union mount
+  functionality first, instead of doing some partial adaptation of
+  `unionfs` to `unionmount` and leaving the complete adaptation for
+  the future.
+
+* **Compile GNU/Hurd from source to be able to study
+  eth-multiplexer.** *(16 Jun)* On my way to getting a working
+  instance of eth-multiplexer I learnt how I could compile GNU/Hurd in
+  a Debian GNU/Hurd system.
+
 ### TODO
 
 (Dates in brackets show the *expected* completion date)
 
-* **Study eth-multiplexer.** *(12 Jun)* In order to get an idea of
+* **Study eth-multiplexer.** *(19 Jun)* In order to get an idea of
   what should the rules for eth-multipexer be, I will have to study
   the current state of eth-multiplexer.
 
-* **Start with a clean unionfs and implement the `--mount` argument**
-  *(12 Jun)* It was suggested to implement the union mount
-  functionality first, instead of doing some partial adaptation of
-  `unionfs` to `unionmount` and leaving the complete adaptation for
-  the future.
-
 * **Implement merging rules.** *(25 Jul)* Some details are still
   awaiting discovery by me.