Re: news 2010-03: *bug squashing* and *Hurd in GSoC 2010 with GNU*

2010-03-27 Thread Arne Babenhauserheide
Hi, Am Samstag, 27. März 2010 16:00:37 schrieb olafbuddenha...@gmx.net: > Hi, > > On Sat, Mar 27, 2010 at 03:03:36PM +0100, Arne Babenhauserheide wrote: > > > This month saw bugs dieing as they met hackers like > > > [Jérémie, Antrik, Samuel](http://lists.gnu.org/archive/html/bug- > I don't tak

Re: news 2010-03: *bug squashing* and *Hurd in GSoC 2010 with GNU*

2010-03-27 Thread olafBuddenhagen
Hi, On Sat, Mar 27, 2010 at 03:03:36PM +0100, Arne Babenhauserheide wrote: > > This month saw bugs dieing as they met hackers like > > [Jérémie, Antrik, Samuel](http://lists.gnu.org/archive/html/bug- > hurd/2010-03/msg00027.html), I don't take any credit for that... Also, I never capitalize my

news 2010-03: *bug squashing* and *Hurd in GSoC 2010 with GNU*

2010-03-27 Thread Arne Babenhauserheide
I wrote the news for this march and am ready to release it. Please write every improvement suggestinon which comes to your mind! > This month saw bugs dieing as they met hackers like > [Jérémie, Antrik, Samuel](http://lists.gnu.org/archive/html/bug- hurd/2010-03/msg00027.html), > [Da Zheng, Tho

rm -fr slowness

2010-03-27 Thread Samuel Thibault
Hello, I have always been surprised by the slowness of a mere rm -fr. Looking a bit inside, I see that diskfs_dirremove_hard() calls diskfs_file_update (dp, 1) (as does diskfs_truncate, diskfs_direnter_hard, and diskfs_dirrewrite_hard). diskfs_file_update then calls pager_sync on the pager, which

libpager deadlock

2010-03-27 Thread Samuel Thibault
Hello, >From times to times, ext2fs deadlocks on the pager->interlock mutex. This is an excerpt of what I could find in the process: #2 0x08106e59 in memory_object_lock_request () #3 0x0806fdeb in _pager_lock_object (p=0x81c97b8, offset=0, size=827392, should_return=2, should_flush=0, lock

Re: The curse of the umbrella, or: Why we got rejected as an organisation

2010-03-27 Thread Neil Jerram
writes: > antrik: so my friend, we are asking most GNU projects to work >under the GNU project umbrella. > > It's worth reading the rest of the log as well however, as there are > some suggestions for umbrella projects in the followup that might be > helpful -- and I don't really have tim