Merge remote-tracking branch 'fp/master'

3 files changed, 174 insertions, 3 deletions

diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index fd24f081..df6290f7 100644
--- a/hurd/debugging/rpctrace.mdwn
+++ b/hurd/debugging/rpctrace.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011 Free Software
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software
 Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -89,6 +89,84 @@ See `rpctrace --help` about how to use it.
         <pinotree> braunr: the output of rpctrace --help should tell the
           default dir for msgids
 
+* IRC, freenode, #hurd, 2012-06-30
+
+        <mcsim> hello. Has anyone faced with problem when translator works
+          fine, but when it is started via rpctrace it hangs? Probably you know
+          what can cause this?
+        <antrik> mcsim: rpctrace itself is quite buggy
+        <antrik> zhengda once did a number of improvements, but they never went
+          upstream...
+        <youpi> well, he never explained how his fixes worked :)
+        <youpi> GNU/Hurd is no different from other projects in that regard: if
+          you don't explain how your patches work, there's low chance that they
+          are applied
+        <youpi> unless the maintainer has time to dive himself, which we don't
+        <pinotree> "it compiles, ship it!"
+        <braunr> pinotree: i guess the hurd is different in that particular
+          regard :p
+        <youpi> not different from linux
+        <braunr> eh, they include staging drivers now :)
+        <youpi> we have a sort-of staging tree as well, with netdde
+        <youpi> we don't really care about stability there
+        <antrik> youpi: actually, I think by now (and not to a small part
+          because of this episode) that we are too strict about patch
+          submission
+        <youpi> well, review really is needed, otherwise source gets into a bad
+          shape
+        <antrik> while zhengda's variant might not have been ideal (nobody of
+          us understands the workings of rpctrace enough to tell), I have
+          little doubt that it would be an improvement...
+        <youpi> it happened quite a few times that a fix revealed to be
+          actually bogus
+        <youpi> in that particular case, I agree
+        <youpi> the problem is that usually what happens is that questions are
+          asked
+        <youpi> and the answers never happen
+        <youpi> and thus the patch gets lost
+        <antrik> after all, when he when he submitted that patch, he had a much
+          better understanding of rpctrace than any of us...
+        <youpi> sure
+        <antrik> Linus is actually quite pragmatic about that. from what I've
+          seen, if he can be convinced that something is *probably* an
+          improvement over the previous status, he will usually merge it, even
+          if he has some qualms
+        <youpi> when there is a maintainer, he usually requires his approval,
+          doesn't he?
+        <antrik> in particular, for code that is new or has been in a very bad
+          shape before, standards shouldn't be as high as for changes to known
+          good code. and quite frankly, large parts of the Hurd code base
+          aren't all that good to begin with...
+        <youpi> sure
+        <antrik> well, sure. in this case, we should have just appointed
+          zhengda to be the rpctrace maintainer :-)
+        <antrik> BTW, as his version is quite fundamentally different, perhaps
+          instead of merging the very large patch, perhaps we should just ship
+          both versions, and perhaps drop the old one at some point if the new
+          one turns out to work well...
+        <antrik> (and perhaps I overused the word perhaps in that sentence
+          perhaps ;-) )
+        <youpi> about that particular patch, you had needed raised a few bits
+        <youpi> and there was no answers
+        <youpi> the patch is still in my mbox, far away
+        <youpi> so it was *not* technically lost
+        <youpi> it's just that as usual we lack manpower
+        <antrik> yeah, I know. but many of the things I raised were mostly
+          formalisms, which might be helpful for maintaining high-quality code,
+          but probably were just a waste of time and effort in this case... I'm
+          not surprised that zhengda lost motivation to pursue this further :-(
+        <braunr> it would help a lot to get the ton of patches in the debian
+          packages upstream :)
+        <youpi> braunr: there  aren't many, and usually for a good reason
+        <youpi> some of them are in debian for testing, and can probably be
+          commited at some point
+        <pinotree> youpi: we could mark (with dep3 headers) the ones which are
+          meant to be debian-specific
+        <youpi> sure
+        <antrik> well, there are also a few patches that are not exactly
+          Debian-specific, but not ready for upstream either...
+        <youpi> antrik: yes
+
 
 # See Also
 
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index ad79c7b9..8e15d1c7 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -18,6 +18,8 @@ License|/fdl]]."]]"""]]
 
   * [[Page_cache]]
 
+  * [[metadata_caching]]
+
 
 ## Large Stores
 
@@ -43,6 +45,48 @@ Smaller block sizes are commonly automatically selected by `mke2fs` when using
 small backend stores, like floppy devices.
 
 
+#### IRC, freenode, #hurd, 2012-06-30
+
+    <braunr> at least having the same api in the debian package and the git
+      source would be great (in reference to the large store patch ofc)
+    <youpi> braunr: the api part could be merged perhaps
+    <youpi> it's very small apparently
+    <antrik> braunr: the large store patch is a sad story. when it was first
+      submitted, one of the maintainers raised some concerns. the other didn't
+      share these (don't remember who is who), but the concerned one never
+      followed up with details. so it has been in limbo ever since. tschwinge
+      once promised to take it up, but didn't get around to it so far. plus,
+      the original author himself mentioned once that he didn't consider it
+      finished...
+    <youpi> antrik: it's clearly not finished
+    <youpi> there are XXXs here and there
+    <braunr> it's called an RC1 and RC2 is mentioned in the release notes
+    <antrik> youpi: well, that doesn't stop most other projects from commiting
+      stuff... including most emphatically the original Hurd code :-)
+    <youpi> what do you refer to my "that" ? :)
+    <braunr> "XXX"
+    <youpi> right
+    <youpi> at the time it made sense to delay applying
+    <youpi> but I guess by nowadays standard we should just as well commit it
+    <youpi> it works enough for Debian, already
+    <youpi> there is just one bug I nkow about
+    <youpi> the apt database file keeps haveing the wrong size, fixed by e2fsck
+    <pinotree> youpi: remember that patch should be fixed in the offset
+      declaration in diskfs.h
+    <youpi> I don't remember about that
+    <youpi> did we fix it in the debian package?
+    <pinotree> nope
+    <youpi> you had issues when fixing it, didn't you?
+    <youpi> (I don't remember where I can find the details about this)
+    <pinotree> i changed it, recompiled hurd and installed it, started a perl
+      rebuild and when running one of the two lfs tests it hard locked the vm
+      after ext2fs was taking 100% cpu for a bit
+    <pinotree> i don't exclude i could have done something stupid on my side
+      though
+    <youpi> or there could just be actual issues, uncovered here
+    <youpi> which can be quite probable
+
+
 # Documentation
 
   * <http://e2fsprogs.sourceforge.net/ext2.html>
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index e7fdf46e..182b438b 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -68,7 +68,7 @@ IRC, #hurd, around October 2010
       owner, but always with root group
 
 
-# `/proc/$pid/stat` being 400 and not 444, and some more
+# `/proc/[PID]/stat` being 400 and not 444, and some more
 
 IRC, freenode, #hurd, 2011-03-27
 
@@ -187,7 +187,7 @@ IRC, freenode, #hurd, 2011-07-22
       server anyway, I think.
 
 
-# `/proc/mounts`, `/proc/$pid/mounts`
+# `/proc/mounts`, `/proc/[PID]/mounts`
 
 IRC, freenode, #hurd, 2011-07-25
 
@@ -277,3 +277,52 @@ Needed by glibc's `pldd` tool (commit
     <antrik> it's very weird for example for fd connected to files that have
       been unlinked. it looks like a broken symlink, but when dereferencing
       (e.g. with cp), you get the actual file contents...
+
+
+# `/proc/[PID]/maps`
+
+## IRC, OFTC, #debian-hurd, 2012-06-20
+
+    <pinotree> bdefreese: the two elfutils tests fail because there are no
+      /proc/$pid/maps files
+    <pinotree> that code is quite relying on linux features, like locating the
+      linux kernel executables and their modules, etc
+    <pinotree> (see eg libdwfl/linux-kernel-modules.c)
+    <pinotree> refactor elfutils to have the linux parts executed only on linux
+      :D
+    <bdefreese> Oh yeah, the maintainer already seems really thrilled about
+      Hurd..  Did you see
+      http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662041 ?
+    <pinotree> kurt is generally helpful with us (= hurd)
+    <pinotree> most probably there he is complaining that we let elfutils build
+      with nocheck (ie skipping the test suite run) instead of investigate and
+      report why the test suite failed
+
+
+# IRC, freenode, #hurd, 2011-06-19
+
+    <pinotree> jkoenig: procfs question: in process.c, process_lookup_pid, why
+      is the entries[2].hook line repeated twice?
+    <jkoenig> pinotree, let me check
+    <jkoenig> pinotree, it's probably just a mistake, there's no way the second
+      one has any effect
+    <pinotree> jkoenig: i see, it looked like you c&p'd that code accidentally
+    <jkoenig> pinotree, it's probably what happened, yes.
+
+
+# IRC, freenode, #hurd, 2012-06-30
+
+    <pinotree> btw, what do you think about making jkoening's procfs master the
+      real master?
+    <youpi> probably a good idea
+    <youpi> it does work quite well, except a few pidof hangs
+    <pinotree> surely better than the old one :)
+    <youpi> yes :)
+
+
+# `/proc/[PID]/cwd`
+
+## IRC, freenode, #hurd, 2012-06-30
+
+    * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying
+        on "internal" (but exported) glibc functions