Merge branch 'master' of flubber:~hurd-web/hurd-web

22 files changed, 592 insertions, 45 deletions

diff --git a/community/meetings.mdwn b/community/meetings.mdwn
index c7ed664d..ba4fc2bd 100644
--- a/community/meetings.mdwn
+++ b/community/meetings.mdwn
@@ -17,6 +17,7 @@ is included in the section entitled
 
 # Past
 
+  * [GNU Hackers Meeting in the Hague 2010](http://www.gnu.org/ghm/2010/denhaag/)
   * [[FOSDEM 2010]]
   * [[EuroSys_2009]]
   * [[FOSDEM_2008]]
diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn
index 6518e0e4..72294629 100644
--- a/hurd/dde/guide.mdwn
+++ b/hurd/dde/guide.mdwn
@@ -60,8 +60,6 @@ suppose you need forcedeth driver
 Download http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=blob_plain;f=drivers/net/forcedeth.c;hb=HEAD from mozilla like
 browser to /mnt/home as forcedeth.c
 
-Download http://pastebin.com/RJAJT2MR the same way and rename it to 0001-Fix-up-DDE-paths.patch
-
 reboot back to hurd (multiuser)
 
 > $ apt-get update
@@ -83,8 +81,6 @@ reboot back to hurd (multiuser)
 
 > $ cd ../hurd_dde
 
-> $ git am ../0001-Fix-up-DDE-paths.patch
-
 > $ cp -r dde_pcnet32 dde_forcedeth
 
 > $ cd dde_forcedeth
@@ -106,7 +102,6 @@ reboot back to hurd (multiuser)
 add these 2 lines after the last #include
 
     #include <ddekit/timer.h>
-    void get_random_byter(void *buf, int nbytes) { }
 
 > $ cd ..
 
diff --git a/hurd/porting/system_api_limitations.mdwn b/hurd/porting/system_api_limitations.mdwn
index 06a6b382..2fac456e 100644
--- a/hurd/porting/system_api_limitations.mdwn
+++ b/hurd/porting/system_api_limitations.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2003, 2004, 2005, 2009 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2003, 2004, 2005, 2009, 2010 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
@@ -24,7 +24,7 @@ These are the known system API limits that have porting implications.
 
 **_[\#184565](http://bugs.debian.org/184565): libc0.3: missing shm\* functions (from `<sys/shm.h>`)_**<br />**breaks:** cdrtools<br />**error:** warning: shm\* is not implemented and will always fail
 
-**_[\#190581](http://bugs.debian.org/190581): nice() doesn't work_**<br />**breaks:** coreutils<br />**error:** `nice()` doesn't take effect on some situations
+**_[[nice() doesn't work|open_issues/nice_vs_mach_thread_priorities]]_**.
 
 **_[\#187391](http://bugs.debian.org/187391): libc0.3-dev: `sockaddr_un.sun_path` can't be assigned a `const char *` when compiling with g++_**<br />**breaks:** fam, gail<br />**status:** maybe this should be in [[PortingIssues]] (see _long_ bug log)
 
diff --git a/media_appearances.mdwn b/media_appearances.mdwn
index 4311f08b..8fe72752 100644
--- a/media_appearances.mdwn
+++ b/media_appearances.mdwn
@@ -8,7 +8,39 @@ 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]]."]]"""]]
 
-This is a collection of Hurd-related media appearances.
+This is a collection of some Hurd-related media appearances.
+
+A lot of stuff is missing here.
+
+# 2010
+
+## August
+
+  * DebConf10 presentation (including video) by Michael Banck: [*Debian
+    GNU/Hurd -- Past.  Present.  And
+    Future?*](http://penta.debconf.org/dc10_schedule/events/595.en.html)
+    ([slides](http://people.debian.org/~mbanck/debian-hurd.pdf)).
+
+## July
+
+  * Koen Vervloesem: [*The Hurd: GNU's quest for the perfect
+    kernel*](http://lwn.net/Articles/395150/)
+
+  * Richard Hillesley: [*GNU HURD: Altered visions and lost
+    promise*](http://www.h-online.com/open/features/GNU-HURD-Altered-visions-and-lost-promise-1030942.html)
+    ([German
+    translation](http://www.heise.de/open/artikel/GNU-HURD-Veraenderte-Visionen-und-verworfene-Versprechen-1046753.html))
+
+    Follow-up discussion, some of it valid and constructive criticism, some of
+    it less so:
+
+      * <http://lwn.net/Articles/394295/>
+      * <http://www.reddit.com/r/linux/comments/ckjt2/gnu_hurd_altered_visions_and_lost_promise/>
+      * <http://www.reddit.com/r/programming/comments/ckjud/the_hurd_altered_visions_and_lost_promise/>
+      * <http://www.osnews.com/comments/23511>
+      * <http://news.ycombinator.com/item?id=1474941>
+
+# 2004
 
   * Marcus Brinkmann, *The GNU Hurd - Lessons and Perspective*, from the
     [OpenWeekend](http://openweekend.cz/) 2004 conference organized by the
diff --git a/news/2010-07-31.mdwn b/news/2010-07-31.mdwn
index 946645df..68153c7a 100644
--- a/news/2010-07-31.mdwn
+++ b/news/2010-07-31.mdwn
@@ -8,41 +8,52 @@ 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]]."]]"""]]
 
-<!-- Date when the news item is (to be) pulished (important for RSS feeds).
-Will be set by tschwinge when publishing.
-[[!meta date="YYYY-MM-DD HH:MM UTC"]]
--->
+[[!meta date="2010-08-10 17:30 UTC"]]
 
-A month of the Hurd: *debian installer*, *compatibility*, *make dist* and *newssites*. 
+A month of the Hurd: *Thanks, Phil!*, *Debian Installer*, *compatibility*, and
+*LWN article*.
 [[!if test="included()" then="""[[!toggle id=full_news
 text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]"""
 else="[[!paste id=full_news]]"]]
 
 [[!cut id="full_news" text="""
 
-> This month Jérémie Koenig got the 
-> [Debian installer (d-i) for the Hurd](http://jk.fr.eu.org/debian/hurd-installer/) into
-> basic working state with a simple 
-> [4 step installation guide](http://jk.fr.eu.org/debian/hurd-installer/README.txt)
->  ([status mail](http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00158.html)). 
-> This gets us a big step towards easy installation and automated image creation. 
-> You can track Jérémie’s progress on his [[user_page|user/jkoenig]]. 
-> 
-> Also Emilio Pozuelo Monfort worked on improving the compatibility with 
-> third party programs via 
-> [changes to exec](http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00141.html)
-> and added support to 
-> [send file descriptors over Unix sockets](http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00145.html). 
-> Both will help getting more packages to compile and run in the Hurd. 
-
-> Additionally Ludovic Courtès 
-> [fixed make dist](http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00098.html) 
-> in console-client which allows easy tarball creation for uploading to ftp.gnu.org.
-
-> And dasht provided 
-> [some background on the Hurd and GNU in general from a FSF hacker](http://news.ycombinator.com/item?id=1474941) 
-> while LWN posted a
-> [well researched article on the status of the Hurd](http://lwn.net/Articles/395150/). 
-
-<!-- Handled debian-hurd until yyyy-mm-dd.  -->
+> Philip Charles, our 72 years old provider of Debian GNU/Hurd installation CDs
+> [has now resigned](http://lists.debian.org/debian-hurd/2010/07/msg00020.html)
+> from that position.  This has lead to a flood of [public thank-you
+> responses](http://lists.debian.org/debian-hurd/2010/07/msg00020.html#00021),
+> and surely yet more of those have been sent privately.  Phil, thanks again
+> for providing the many installation images you've started producing [nearly
+> ten years ago](http://lists.debian.org/debian-hurd/2000/08/msg00249.html)! --
+> oh, the joy of (not) uploading CD-size images using a 56k modem... -- and
+> that have been the first choice for many of us to get a [[Debian
+> GNU/Hurd|hurd/running/debian]] system installed.
+
+> On the other hand, there's no need to worry about these news: Jérémie Koenig
+> got the [Debian Installer for the
+> Hurd](http://jk.fr.eu.org/debian/hurd-installer/) into a basically working
+> state; there is a simple [four step installation
+> guide](http://jk.fr.eu.org/debian/hurd-installer/README.txt).  This brings us
+> a big step forward towards easy installation of Debian GNU/Hurd and automated
+> image creation.  You can track Jérémie's progress on his [[user
+> page|jkoenig]].
+
+> Emilio Pozuelo Monfort also made progress with his Google Summer of Code
+> work.  For example, he posted a new iteration of his proposed [changes to
+> exec](http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00141.html) as
+> well as he added support for [sending file descriptors over Unix
+> sockets](http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00145.html).
+> These patches add features and improve compatibility to other systems, and
+> thus help to get more software packages to work as expected on GNU/Hurd
+> systems.
+
+> Ludovic Courtès [fixed `make
+> dist`](http://lists.gnu.org/archive/html/bug-hurd/2010-07/threads.html#00107),
+> which allows for easy tarball creation of the GNU Hurd sources.
+
+> We've been in the news [[last month|2010-06-30]] -- and this month yet again:
+> LWN posted a well-researched article on the status of the Hurd: Koen
+> Vervloesem: [*The Hurd: GNU's quest for the perfect
+> kernel*](http://lwn.net/Articles/395150/).
+
 """]]
diff --git a/open_issues/bash_busy-loop.mdwn b/open_issues/bash_busy-loop.mdwn
new file mode 100644
index 00000000..5228ba33
--- /dev/null
+++ b/open_issues/bash_busy-loop.mdwn
@@ -0,0 +1,33 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+I've first seen this problem after having had the following command line run
+for a week, or two, or three:
+
+Start `screen`.  Find PID of pfinet.
+
+    $ while sleep 66; do echo "$(date)" " $(ps --no-header --format=hurd -p [PID])"; done | tee ps-pfinet
+
+Leave it running, detach from `screen`.
+
+Eventually, the main `bash` process will go bonkers and eat 100 % CPU time.
+Reproduced on four different systems.
+
+A faster way to reproduce this, again inside `screen`; every three seconds,
+write text in 10 MiB bursts to the terminal:
+
+    $ while sleep 3; do date > tmp/tmp && yes "$(date)" | dd bs=1M count=10; done
+
+This one only needs like ten hours, before `bash` starts its busy-loop, from
+which it can only be terminated with `SIGKILL`.  At this point, the `term`,
+`screen`, `fifo` processes also have used 40, 52, 25 minutes of CPU time,
+respectively, but appear to be still working fine.
+
+I did not yet start debugging this.
diff --git a/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn b/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn
new file mode 100644
index 00000000..4076d8d0
--- /dev/null
+++ b/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn
@@ -0,0 +1,17 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+IRC, unknown channel, unknown date:
+
+    <antrik> I have a theory
+    <antrik> when the system is under CPU load, the ext2 locking issues are more likely to happen
+    <antrik> I'm under the impression, that when doing something disk-intensive (like a compile job) *considerably* more often causes crashes, when doing *any* other activity in parallel -- be it other compile jobs, or CPU-only activities
+    <antrik> thinking about it, I'm not sure whether CPU-intensive is the decisive criterium, or maybe RPC-intensive...
+    <antrik> CPU load doesn't seem to have any effect -- neither alone, nor in combination with other testcases
diff --git a/open_issues/error_message_disk_full.mdwn b/open_issues/error_message_disk_full.mdwn
new file mode 100644
index 00000000..f72cd66a
--- /dev/null
+++ b/open_issues/error_message_disk_full.mdwn
@@ -0,0 +1,14 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+IRC, unknown channel, unknown date:
+
+    <antrik> /usr/bin/install: writing `/usr/src/gnumach-20060408.dfsg.1/debian/gnumach-dbg/boot/gnumach': (os/kern) memory error
+    <antrik> interesting way to tell that the disk is full ;-)
diff --git a/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn b/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn
new file mode 100644
index 00000000..817dac76
--- /dev/null
+++ b/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn
@@ -0,0 +1,17 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+[[!tag open_issue_libpthread]]
+
+IRC, unknown channel, unknown date:
+
+    <azeem> neal: libgomp (GNU's implementation of OpenMP) uses PTHREAD_STACK_MIN, which we do not define apparently
+    <neal> azeem: We have fixed sized stacks.
+    <neal> so the pthread_attr_setstacksize will fail once you define PTHREAD_STACK_MIN)
diff --git a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
new file mode 100644
index 00000000..d069641e
--- /dev/null
+++ b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
@@ -0,0 +1,26 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+bug-hurd discussion.
+
+---
+
+IRC, #hurd, 2010-08-12
+
+    <jkoenig> Looking at hurd.git, shouldn't {hurd,include}/Makefile's "all" target do something, and shouldn't pretty much everything depend on them? As it stands it seems that the system headers are used and the potentially newer ones never get built, except maybe on "install" (which is seemingly never called from the top-level Makefile)
+    <jkoenig> I would fix it, but something tells me that maybe it's a feature :-)
+    <antrik> jkoenig: the headers are provided by glibc, along with the stubs
+    <jkoenig> antrik, you mean, even those built from the .defs files in hurd/ ?
+    <antrik> yes
+    <jkoenig> oh, ok then.
+    <antrik> as glibc provides the stubs (in libhurduser), the headers also have to come from there, or they would get out of sync
+    <jkoenig> hmm, shouldn't glibc also provide /usr/share/msgids/hurd.msgids, then?
+    <antrik> jkoenig: not necessarily. the msgids describe what the servers actually understand. if the stubs are missing from libhurduser, that's no reason to leave out the msgids...
+    <jkoenig> ok this makes sense
diff --git a/open_issues/nice_changes_priority_of_parent_shell.mdwn b/open_issues/nice_changes_priority_of_parent_shell.mdwn
new file mode 100644
index 00000000..d731ef82
--- /dev/null
+++ b/open_issues/nice_changes_priority_of_parent_shell.mdwn
@@ -0,0 +1,15 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+[[!tag open_issue_gnumach open_issue_glibc]]
+
+  * <http://bugs.debian.org/44039>
+
+  * Also see [[nice_vs_mach_thread_priorities]].
diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn
new file mode 100644
index 00000000..e6b68134
--- /dev/null
+++ b/open_issues/nice_vs_mach_thread_priorities.mdwn
@@ -0,0 +1,197 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+[[!tag open_issue_gnumach open_issue_glibc]]
+
+This issue has been known for some time, due to coreutils' testsuite choking
+when testing *nice*: <http://bugs.debian.org/190581>.
+
+There has been older discussion about this, too, but this is not yet captured
+here.
+
+IRC, #hurd, August 2010
+
+    <pochu> I'm reading Mach and POSIX documentation to understand the priorities/nice problems
+    <pochu> antrik said it would be better to reimplement everything instead of fixing the current Mach interfaces, though I'm not sure about that yet
+    <youpi> uh, so he changed his mind?
+    <pochu> it seems POSIX doesn't say nice values should be -20..20, but 0..(2*NZERO - 1)
+    <youpi> he said we could just change the max priority value and be done with it :)
+    <pochu> so we can probably define NZERO to 16 to match the Mach range of 0..31
+    <youpi> s/said/had said previously/
+    <antrik> youpi: POSIX is actually fucked up regarding the definition of nice values
+    <antrik> or at least the version I checked was
+    <pochu> antrik: why? this says the range is [0,{NZERO}*2-1], so we can just set NZERO to 16 AFAICS: http://www.opengroup.org/onlinepubs/9699919799/functions/getpriority.html
+    <antrik> it talkes about NZERO and all; making it *look* like this could be defined arbitrarily... but in other places, it's clear that the standard 40 level range is always assumed
+    <antrik> anyways, I totally see no point in deviating from other systems in this regard. it can only cause problems, and gives us no benefits
+    <cfhammar> it says NZERO should be at least 20 iirc 
+    <youpi> agreed
+    <antrik> I don't remember the details; it's been a while since I looked at this
+    <antrik> youpi: changing the number of levels is only part of the issue. I'm not sure why I didn't mention it initially when we discussed this
+    <antrik> youpi: I already concluded years ago that it's not possible to implement nice levels correctly with the current Mach interfaces in a sane fashion
+    <antrik> (it's probably possible, but only with a stupid hack like setting all the thread priorities one by one)
+    <antrik> youpi: also, last time we discussed this, I checked how the nice stuff works currently on Hurd; and concluded that it's so utterly broken, that there is no point in trying to preserve *any* compatibility. I think we can safely throw away any handling that is alread there, and do it over from scratch in the most straightforward fashion
+    <pochu> antrik: I've thought about setting NZERO to 16 and doing exactly what you've just said to be a hack (setting all the thread priorities one by one)
+    <pochu> but there seems to be consensus that that's undesirable...
+    <pochu> indeed, POSIX says NZERO should be at least 20
+    <antrik> pochu: BTW, I forgot to say: I'm not sure you appreciate the complexity of setting the thread max priorities individually
+    <pochu> antrik: I don't. would it be too complex? I imagined it would be a simple loop :)
+    <antrik> pochu: in order to prevent race conditions, you have to stop all other threads before obtaining the list of threads, and continue them after setting the priority for each
+    <antrik> I don't even know whether it can be done without interfering with other thread handling... in which case it gets really really ugly
+    <pochu> antrik: btw I'm looking at [gnumach]/kern/thread.[ch], removing the priority stuff as appropriate, and will change the tasks code later
+    <antrik> it seems to me that using a more suitable kernel interface will not only be more elegant, but quite possibly actually easier to implement...
+    <pochu> antrik: apparently it's not that hard to change the priority for all threads in a task, see task_priority() in gnumach/kern/task.c
+    <pochu> it looks like the nice test failures are mostly because of the not 1:1 mapping between nice values and Mach priorities
+    <marcusb> "Set priority of task; used only for newly created threads."
+    <marcusb> there is a reason I didn't fix nice 8 years ago
+    <marcusb> ah there is a change_threads option
+    <pochu> marcusb: I'm not sure that comment is correct. that syscall is used by setpriority()
+    <marcusb> yeah
+    <marcusb> I didn't read further, where it explains the change_threads options
+    <marcusb> I was shooting before asking questions :)
+    <marcusb> pochu: although there are some bad interactions if max_priorities are set per thread
+    <antrik> pochu: maybe we are talking past each other. my point was not that it's hard to do in the kernel. I was just saying that it would be painful to do from userspace with the current kernel interface
+    <pochu> antrik: you could still use that interface in user space, couldn't you? or maybe I'm misunderstanding...
+    <pochu> cfhammar, antrik: current patch: http://emilio.pozuelo.org/~deb/gnumach.patch, main issue is probably what to do with high-priority threads. are there cases where there should be a thread with a high priority but the task's priority shouldn't be high? e.g. what to do with kernel_thread() in [gnumach]/kern/thread.c
+    <pochu> i.e. if tasks have a max_priority, then threads shouldn't have a higher priority, but then either we raise the task's max_priority if we need a high-prio thread, or we treat them specially (e.g. new field in struct thread), or maybe it's a non-issue because in such cases, all the task is high-prio?
+    <pochu> also I wonder whether I can kill the processor set's max_priority. It seems totally unused (I've checked gnumach, hurd and glibc)
+    <pochu> (that would simplify the priority handling)
+    <cfhammar> pochu: btw what does your patch do? i can't remember what was decided
+    <pochu> cfhammar: it moves the max_priority from the thread to the task, so raising/lowering it has effect on all of its threads
+    <pochu> it also increases the number of run queues (and thus that of priority levels) from 32 to 40 so we can have a 1:1 mapping with nice values
+    <pochu> cfhammar: btw don't do a full review yet, just a quick look would be fine for now
+    <neal> why not do priorities from 0 to 159
+    <neal> then both ranges can be scaled
+    <neal> without loss of precision
+    <pochu> neal: there would be from Mach to nice priorities, e.g. a task with a priority of 2 another with 3 would have the same niceness, though their priority isn't really the same
+    <neal> pochu: sure
+    <neal> pochu: but any posix priority would map to a current mach priority and back
+    <neal> sorry, that's not true
+    <neal> a posix priority would map to a new mach priority and bach
+    <neal> and a current mach priority would map to a new mach priority and back
+    <neal> which is I think more desirable than changing to 40 priority levels
+    <pochu> neal> and a current mach priority would map to a new mach priority and back <- why should we care about this?
+    <neal> to be compatible with existing mach code
+    <neal> why gratutiously break existing interfaces?
+    <pochu> they would break anyway, wouldn't them? i.e. if you do task_set_priority(..., 20), you can't know if the caller is assuming old or new priorities (to leave it as 20 or as 100)
+    <neal> you add a new interface
+    <neal> you should avoid changing the semantics of existing interfaces as much as possible
+    <pochu> ok, and deprecate the old ones I guess
+    <neal> following that rule, priorities only break if someone does task_set_priority_new(..., X) and task_get_priority ()
+    <neal> there are other users of Mach
+    <neal> I'd add a configure check for the new interface
+    <neal> alternatively, you can check at run time
+    <pochu> well if you _set_priority_new(), you should _get_priority_new() :)
+    <neal> it's not always possible
+    <pochu> other users of GNU Mach?
+    <neal> you are assuming you have complete control of all the code
+    <neal> this is usually not the case
+    <neal> no, other users of Mach
+    <neal> even apple didn't gratuitously break Mach
+    <neal> in fact, it may make sense to see how apple handles this problem
+    <pochu> hmm, I hadn't thought about that
+    <pochu> the other thing I don't understand is: "I'd add a configure check for the new interface". a configure check where? in Mach's configure? that doesn't make sense to me
+    <neal> any users of the interface
+    <pochu> ok so in clients, e.g. glibc & hurd
+    <neal> yes.
+    <antrik> neal: I'm not sure we are winning anything by keeping compatibility with other users of Mach...
+    <antrik> neal: we *know* that to make Hurd work really well, we have to do major changes sooner or later. we can just as well start now IMHO
+    <antrik> keeping compatibility just seems like extra effort without any benefit for us
+    <guillem> just OOC have all other Mach forks, preserved full compatibility?
+    <neal> guillem: Darwin is pretty compatible, as I understand it
+    <antrik> pochu: the fundamental approach of changing the task_priority interface to serve as a max priority, and to drop the notion of max priorities from threads, looks fine
+    <antrik> pochu: I'm not sure about the thread priority handling
+    <antrik> I don't know how thread priorities are supposed to work in chreads and/or pthread
+    <antrik> I can only *guess* that they assume a two-stage scheduling process, where the kernel first decides what process to run; and only later which thread in a process...
+    <antrik> if that's indeed the case, I don't think it's even possible to implement with the current Mach scheduler
+    <antrik> I guess we could work with relative thread priorities if we really want: always have the highest-priority thread run with the task's max priority, and lower the priorities of the other threads accordingly
+    <antrik> however, before engaging into this, I think you should better check whether any of the code in Hurd or glibc actually uses thread priorities at all. my guess is that it doesn't
+    <antrik> I think we could get away with stubbing out thread priority handling alltogether for now, and just use the task priority for all threads
+    <antrik> I agree BTW that it would be useful to check how Darwin handles this
+    <pochu> btw do you know where to download the OS X kernel source? I found something called xnu, but I?m not sure that's it
+    <antrik> pochu: yeah, that's it
+    <antrik> Darwin is the UNIX core of OS X, and Xnu is the actual kernel...
+    <pochu> hmm, so they have both a task.priority and a task.max_priority
+    <neal> pochu: thoughts?
+    <pochu> neal: they have a priority and a max_priority in the task and in the threads, new threads inherit it from its parent task
+    <pochu> then they have a task_priority(task, priority, max_priority) that can change a task's priorities, and it also changes it for all its threads
+    <neal> how does the global run queue work?
+    <pochu> and they have 128 run queues, no idea if there's a special reason for that number
+    <pochu> neal: sorry, what do you mean?
+    <neal> I don't understand the point of the max_priority parameter
+    <pochu> neal: and I don't understand the point of the (base) priority ;)
+    <pochu> the max_priority is just that, the maximum priority of a thread, which can be lowered, but can't exceed the max one
+    <pochu> the (base) priority, I don't understand what it does, though I haven't looked too hard. maybe it's the one a thread starts at, and must be <= max_priority
+    <antrik> pochu: it's clearly documented in the manual, as well as in the code your initial patch changes...
+    <antrik> or do you mean the meaning is different in Darwin?...
+    <pochu> I was speaking of Darwin, though maybe it's the same as you say
+    <antrik> I would assume it's the same. I don't think there would be any point in having the base vs. max priority distinction at all, except to stay in line with standard Mach...
+    <antrik> at least I can't see a point in the base priority semantics for use in POSIX systems...
+    <pochu> right, it would make sense to always have priority == max_priority ...
+    <pochu> neal: so max_priority is that maximum priority, and priority is the one used to calculate the scheduled priority, and can be raised and lowered by the user without giving special permissions as long as he doesn't raise it above max_priority
+    <pochu> well this would allow a user to lower a process' priority, and raise it again later, though that may not be allowed by POSIX, so then we would want to have max_priority == priority (or get rid of one of them if possible and backwards compatible)
+    <antrik> pochu: right, that's what I think too
+    <antrik> BTW, did I bring up handling of thread priorities? I know that I meant to, but I don't remember whether I actually did...
+    <pochu> antrik: you told me it'd be ok to just get rid of them for now
+    <pochu> so I'm more thinking of fixing max_priority and (base) priority and leaving thread's scheduling priority as it currently is
+    <pochu> s/so/though/
+    <antrik> pochu: well, my fear is that keeping the thread priority handling as ist while changing task priority handling would complicate the changes, while giving us no real benefit...
+    <antrik> though looking at what Darwin did there should give you an idea what it involves exactly...
+    <pochu> antrik: what would you propose, keeping sched_priority == max_priority ?
+    <pochu> s/keeping/making/
+    <antrik> yes, if that means what I think it does ;-)
+    <antrik> and keeping the priority of all threads equal to the task priority for now
+    <antrik> of course this only makes sense if changing it like this is actually simpler than extending the current handling...
+    <antrik> again, I can't judge this without actually knowing the code in question. looking at Darwin should give you an idea...
+    <pochu> I think leaving it as is, making it work with the task's max_priority changes would be easier
+    <antrik> perhaps I'm totally overestimating the amount of changes required to do what Darwin does
+    <antrik> OTOH, carrying around dead code isn't exactly helping the maintainability and efficiency of gnumach...
+    <antrik> so I'm a bit ambivalent on this
+    <antrik> should we go for minimal changes here, or use this occasion to simplify things?...
+    <antrik> I guess it would be good to bring this up on the ML
+    <cfhammar> in the context of gsoc i'd say minimal changes
+    <pochu> there's also neal's point on keeping backwards compatibility as much as possible
+    <neal> my point was not backwards compatibility at all costs
+    <antrik> I'm still not convinced this is a valid point :-)
+    <neal> but to not gratutiously break things
+    <antrik> neal: well, I never suggested breaking things just because we can... I only suggested breaking things to make the code and interface simpler :-)
+    <antrik> I do not insist on it though
+    <neal> at that time, we did not know how Mac did it
+    <antrik> I only think it would be good to get into a habit that Mach interfaces are not sacred...
+    <neal> and, I also had a proposal, which I think is not difficult to implement given the existing patch
+    <antrik> but as I said, I do not feel strongly about this. if people feel more confident about a minimal change, I'm fine with that :-)
+    <antrik> neal: err... IIRC your proposal was only about the number of nice levels? we are discussing the interface change necessary to implement POSIX semantics properly
+    <antrik> or am I misremembering?
+    <pochu> antrik: he argues that with that number of nice levels, we could keep backwards compatibility for the 0..31 levels, and for 0..39 for POSIX compatibility
+    <antrik> pochu: yes, I remember that part
+    <neal> antrik : My suggestion was: raise the number of nice levels to 160 and introduce a new interface which uses those.  Adjust the old interface to space by 160/32
+    <antrik> neal: I think I said it before: the problem is not *only* in the number of priority levels. the semantics are also wrong. which is why Darwin added a max_priority for tasks
+    <neal> what do you mean the semantics are wrong?
+    <neal> I apologize if you already explained this.
+    <antrik> hm... I explained it at some point, but I guess you were not present at that conversation
+    <neal> I got disconnected recently so I likely don't have it in backlog.
+    <antrik> in POSIX, any process can lower its priority; while only privileged processes can raise it
+    <antrik> Mach distinguishes between "current" and "max" priority for threads: "max" behaves like POSIX; while "current" can be raised or lowered at will, as long as it stays below "max"
+    <antrik> for tasks, there is only a "current" priority
+    <antrik> (which applies to newly created threads, and optionally can be set for all current threads while changing the task priority)
+    <antrik> glibc currently uses the existing task priorities, which leads to *completely* broken semantics
+    <antrik> instead, we need something like a max task priority -- which is exactly what Darwin added
+    <neal> yes
+    <antrik> (the "current" task priority is useless for POSIX semantics as far as I can tell; and regarding thread priorities, I doubt we actually use them at all?...)
+    <cfhammar> where does a new thread get its initial max_priority from?
+    <antrik> cfhammar: from the creator thread IIRC
+    <pochu> yes
+
+2010-08-12
+
+    <pochu> my plan is to change the number of priority levels and the threads/tasks priority handling, then add new RPCs to play with them and make the old ones stay compatible, then make glibc use the new RPCs
+
+---
+
+Another nice issue: [[nice_changes_priority_of_parent_shell]].
diff --git a/open_issues/nptl.mdwn b/open_issues/nptl.mdwn
index daec8b11..9ff5fb51 100644
--- a/open_issues/nptl.mdwn
+++ b/open_issues/nptl.mdwn
@@ -25,3 +25,13 @@ IRC, #hurd, 2010-07-31
     <youpi> while the interface between glibc and libpthread isn't increasing _so_ much
     <tschwinge> ... and even less so the interfavce that actual applications are using.
     <tschwinge> We'd need to evaluate which benefits NPTL would bring.
+
+---
+
+# Resources
+
+  * <http://www.akkadia.org/drepper/nptl-design.pdf>
+
+  * <http://nptltracetool.sourceforge.net/>
+
+  * <http://posixtest.sourceforge.net/>
diff --git a/open_issues/pflocal_x_slowness.mdwn b/open_issues/pflocal_x_slowness.mdwn
new file mode 100644
index 00000000..9bc18128
--- /dev/null
+++ b/open_issues/pflocal_x_slowness.mdwn
@@ -0,0 +1,16 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+IRC, #hurd, 2010-08-10
+
+    <antrik> m1k11e: I think the X slowness is a problem in pflocal, i.e. the translator handling UNIX domain sockets
+    <antrik> (X clients communicate with a local X server using domain sockets)
diff --git a/open_issues/secure_file_descriptor_handling.mdwn b/open_issues/secure_file_descriptor_handling.mdwn
new file mode 100644
index 00000000..c9956ede
--- /dev/null
+++ b/open_issues/secure_file_descriptor_handling.mdwn
@@ -0,0 +1,14 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+`O_CLOEXEC`, `dup3` et al.; see
+<http://udrepper.livejournal.com/20407.html>.  [[tschwinge]] once worked
+on this, posted patches to libc-alpha.  This works needs to be resumed
+and finished.
diff --git a/open_issues/subhurd_error_messages.mdwn b/open_issues/subhurd_error_messages.mdwn
new file mode 100644
index 00000000..46b58fa4
--- /dev/null
+++ b/open_issues/subhurd_error_messages.mdwn
@@ -0,0 +1,15 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+IRC, unknown channel, unknown date:
+
+    <antrik> BTW, many things in a subhurd print various error messages that are never visible on a normal Hurd...
diff --git a/open_issues/system_crash_nmap.mdwn b/open_issues/system_crash_nmap.mdwn
new file mode 100644
index 00000000..25d9a1c6
--- /dev/null
+++ b/open_issues/system_crash_nmap.mdwn
@@ -0,0 +1,15 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+[[!tag open_issue_gnumach]]
+
+IRC, unknown channel, unknown date:
+
+    <Casper_> Hmm, `nmap hurd -p 1-` seems to reliably make a hurd machine reboot.
diff --git a/open_issues/system_crash_pflocal_fifo.mdwn b/open_issues/system_crash_pflocal_fifo.mdwn
new file mode 100644
index 00000000..1dddc44e
--- /dev/null
+++ b/open_issues/system_crash_pflocal_fifo.mdwn
@@ -0,0 +1,41 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+[[!tag open_issue_gnumach]]
+
+IRC, unknown channel, unknown date:
+
+`cat < /dev/zero | cat > /dev/null` will eventually make the system crash,
+likewise when using a FIFO.
+
+    <antrik> hm... VM activity seems much higher when running fifo than pfinet... may be the cause
+    <antrik> "zero filled" and "page faults" are serveral times higher with pipe than with pfinet
+    <antrik> (cow faults however are about the same...)
+    <antrik> pflocal is about the same as fifo
+    
+    <antrik> no, because it usually takes like 20 minutes until it crashes, sometimes much longer
+    
+    <antrik> not sure, but the longest so far was in the range of hours IIRC
+    
+    <antrik> I think I never tested what happens on "cat /dev/zero >/dev/null"... another thing yet to try
+    
+    <antrik> Linux BTW seems to employ some major VM trickery in this case -- dd shows a transfer rate of 10 GB/s...
+    
+    <antrik> no, no anomalies in vmstat
+    <antrik> the only observation I made is that number of page faults and some other number rise pretty quickly with pflocal and fifo, but not with pfinet
+    <antrik> I guess that's somehow related to the fact that pfinet doesn't crash -- though I guess the difference is simply that pfinet is way slower...
+    <antrik> (haven't checked that, though)
+    
+    <antrik> BTW, I'm not sure you got it right: the test case is "cat /dev/zero|cat >/dev/null", *not* "cat /dev/zero >/dev/null"
+    
+    <antrik> OK, "cat /dev/zero|tail -c 1" also crashes, so it's definitely not related to /dev/null
+    <antrik> "dd if=/dev/zero|tail -c 1" crashes as well
+    <antrik> but "tail -c 1 /dev/zero" doesn't seem to
+    <antrik> cool... running multiple instances of the pipe test also considerably speeds up the crash
diff --git a/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn
new file mode 100644
index 00000000..72af3f35
--- /dev/null
+++ b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn
@@ -0,0 +1,41 @@
+[[!meta copyright="Copyright © 2010 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="ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)'"]]
+
+[[!tag open_issue_hurd]]
+
+<http://bugs.debian.org/46859>, <http://bugs.debian.org/195360>
+
+IRC, unknown channel, unknown date:
+
+    <youpi> azeem, marcus: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)' failed
+    <youpi> I actually don't understand this assertion
+    <youpi> it's just before __spin_lock (&ss->critical_section_lock);
+    <youpi> why should one check that a lock is free before taking it ?
+    <youpi> just the same in hurdexec.c
+    <youpi> (no, ss is not our own sigstate, so it's not safe to assume no other path can take it)
+    <youpi> there's another one in sysdeps/mach/hurd/spawni.c
+    <youpi> and jmp-unwind.c
+    <antrik> youpi: why do you think it's nonsense?... the fact that we take the lock (so we can't be interrupted) doesn't mean we are willing to wait for others to release the lock... maybe the code path should never be reached while others have a lock, or something
+    <youpi> then it's useless to take the lock
+    <youpi> "we take the lock (so we can't be interrupted)": no, it's not _our_ lock here, it's the lock of the thread we want to cancel
+    <antrik> what exactly is cancelling a thread?... (sorry, I don't really have experience with thread programming)
+    <youpi> ~= killing it
+    <antrik> well, we take the lock so nobody can mess with the thread while we are cancelling it, no?...
+    <youpi> yes
+    <youpi> that is fine
+    <youpi> but checking that the lock is free before taking it doesn't make sense
+    <youpi> why nobody should be able to take the lock ?
+    <youpi> and if nobody is, why do we take it ? (since nobody would be able to take it)
+    <antrik> well, maybe after taking the lock, we do some action that might result in others trying to take it...
+    <youpi> nope: look at the code :)
+    <youpi> or maybe the cancel_hook, but I really doubt it
+
diff --git a/public_hurd_boxen/installation/snubber.mdwn b/public_hurd_boxen/installation/snubber.mdwn
index 2fd52d4f..957a73fb 100644
--- a/public_hurd_boxen/installation/snubber.mdwn
+++ b/public_hurd_boxen/installation/snubber.mdwn
@@ -10,7 +10,11 @@ License|/fdl]]."]]"""]]
 
 # Additional Packages
 
-    apache2-mpm-worker build-essential git-core gitweb ikiwiki inetutils-inetd
+Before 2010-08-12, we've been using apache2-mpm-worker, but that brought
+the system to its knees too often, leading to a un-syncable rootfs, etc.
+Let's see how apache2-mpm-prefork behaves.
+
+    apache2-mpm-prefork build-essential git-core gitweb ikiwiki inetutils-inetd
     less libtext-csv-perl netcat nullmailer perlmagick screen texinfo
 
 Yet more:
diff --git a/tag.mdwn b/tag.mdwn
index 4d441b29..590d5d3a 100644
--- a/tag.mdwn
+++ b/tag.mdwn
@@ -36,4 +36,5 @@ Most of them should be self-explanatory.
   * *stable_URL*
 
     These pages are tagged as having a *stable URL*.  That is, they're linked
-    to on external pages, and should not be changed just for the sake of it.
+    to from external pages, and their locations should not be changed
+    needlessly.
diff --git a/user/jkoenig.mdwn b/user/jkoenig.mdwn
index 6045f936..247d61cb 100644
--- a/user/jkoenig.mdwn
+++ b/user/jkoenig.mdwn
@@ -138,7 +138,7 @@ installer kindof works, with documented manual intervention required**
     * The segfault will have to be sorted out. (postponed)
 
 * (./) "Fix" the swap situation. (2010-07-08)
-    * The device_close() libstore patch
+    * The device\_close() libstore patch
       had the unfortunate effect of making swapon fail,
       since the device it activates has to be kept open.
     * add options for MAKEDEV and setup-devices
@@ -151,7 +151,7 @@ installer kindof works, with documented manual intervention required**
     * There was some amount of hurd support already
       (namely, activating the interface by replacing the socket translator)
     * However, this code started an active translator with
-      di_exec_shell_log("settrans -a ...),
+      di\_exec\_shell\_log("settrans -a ...),
       which stalled as a consequence of it capturing libdi's pipe
       as its standard output.
     * Network devices must be probed by trying to open Mach devices
@@ -207,13 +207,13 @@ installer kindof works, with documented manual intervention required**
   * Make hurd.postinst not touch them on initial install.
 
 * (./) Fix mach-defpager for file and part stores on larger devices
-  * Use DEVICE_GET_RECORDS instead of DEVICE_GET_SIZE, which overflows an int
+  * Use DEVICE\_GET\_RECORDS instead of DEVICE\_GET\_SIZE, which overflows an int
     (2010-07-22)
 
 **Milestone (2010-07-22):
 installer works but it's still somewhat ugly and broken**
 
-* (./) Ship the uft-8 font for the hurd console
+* (./) Ship the UTF-8 font for the hurd console
   (2010-07-22)
   * Upload a version of bogl with youpi's patch for Hurd.
     (see [[!debbug 589987]])
@@ -231,6 +231,37 @@ installer works but it's still somewhat ugly and broken**
   * localechooser: set the language display level to 3
     when using the hurd console.
 
+* (./) **busybox**: cross-platform package uploaded to experimental
+  (2010-08-03?)
+  * Aurelien Jarno updated the packaging to busybox 1.17.1,
+    fixed a whole lot of bugs,
+    and uploaded a new package with both our changes;
+  * most patches adopted upstream, and included in the new package;
+  * (u)mount/swaponoff ported to kFreeBSD;
+  * per-OS configuration overrides.
+
+* (./) Update custom packages to the latest versions
+  and send updated patches to the BTS
+  (2010-08-11)
+    * updated partman-base to choose a default filesystem in debian/rules
+      rather than at runtime,
+      as suggested by Aurelien Jarno in [[!debbug 586870]]
+    * patch submitted for debian-installer-utils
+      ([[!debbug 592684]]).
+    * patch submitted for locale-chooser
+      ([[!debbug 592690]]).
+    * debootstrap, grub-installer and finish-install not yet submitted,
+      since the details may still change.
+
+* (./) **partman-target**: fix fstab creation
+  (2010-08-11)
+  * See [[!debbug 592671]]
+  * debian/rules: set `partman/mount_style` to `traditional` on Hurd.
+  * finish.d/create\_fstab\_header: add a Hurd case.
+
+* **rootskel**: FTBFS on Hurd and other quirks
+  (to be fixed very soon)
+
 * **d-i/installer/build**: (expected soon)
     * publish the patch I use
     * sort out the changes suitable for inclusion
@@ -265,6 +296,7 @@ installer works but it's still somewhat ugly and broken**
       though the kFreeBSD people will need them
 
 * **partman**: further adjustments
+    * partman-base: handle /dev/hd?s* in lib/base.h
     * hide irrelevant mount options? (sync, relatime)
 
 * Network configuration on the installed system.