IRC.

1 files changed, 40 insertions, 10 deletions

diff --git a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
index d069641e..93055b77 100644
--- a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
+++ b/open_issues/libmachuser_libhurduser_rpc_stubs.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
@@ -8,19 +8,49 @@ 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.
+[[!tag open_issue_glibc open_issue_hurd]]
 
----
+[[!toc]]
 
-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 :-)
+# bug-hurd discussion.
+
+
+# IRC, freenode, #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/ ?
+    <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...
+    <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
+
+
+# IRC, OFTC, #debian-hurd, 2011-09-29
+
+    <tschwinge> pinotree: I don't like their existence.  IMO (but I haven't
+      researched this in very much detail), every user of RPC stubs should
+      generated them for themselves (and glibc should directly include the
+      stubs it uses internally).
+    <pinotree> sounds fair
+    <pinotree> maybe they could be moved from glibc to hurd?
+    <tschwinge> pinotree: Yeah; someone needs to research why we have them (or
+      if it's only convenience), and whether we want to keep them.
+    <pinotree> you could move them to hurd, leaving them unaltered, so binary
+      compatibility with eventual 3rd party users is not broken
+    <pinotree> but those using them, other than hurd itself, won't compile
+      anymore, so you fix them progressively