Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"

This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.

1 files changed, 236 insertions, 0 deletions

diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn
new file mode 100644
index 00000000..171dc7a0
--- /dev/null
+++ b/open_issues/packaging_libpthread.mdwn
@@ -0,0 +1,236 @@
+[[!meta copyright="Copyright © 2010, 2011, 2012 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 open_issue_glibc]]
+
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2010-07-31
+
+    <tschwinge> My idea was to have a separate libpthread package.  What do you
+      think about that?
+    <youpi> in the long term, that can't work with glibc
+    <youpi> because of the thread stub stuff
+
+[[libpthread_dlopen]], for example.
+
+    <youpi> it's not really possible to keep synchronized
+    <youpi> because you have to decide which package you unpack first
+    <youpi> (when upgrading)
+    <tschwinge> Hmm, how is that different if two shared libraries are in one
+      package vs. two packages?  It isn't atomic either way?  Aren't sonames /
+      versioned library packages solving that?
+    <tschwinge> ... for incompatible forward changes?
+    <youpi> that'd be a mess to maintain
+    <youpi> Drepper doesn't have this constraint and thus adds members of
+      private fields at will
+    <tschwinge> OK, but how is it different then if the libpthread is in the
+      Hurd package?
+    <youpi> I'm not saying it's better to have libpthread in the Hurd package
+    <tschwinge> OK.
+    <youpi> I'm saying it's useless to package it separately when Drepper makes
+      everything to have us put it along glibc
+    <tschwinge> Then, to goal is to have it in glibc?
+    <tschwinge> OK.   :-)
+    <tschwinge> OK, I can accommodate to that.  Isn't not that we'd want to
+      switch libpthread to something else so quickly.
+    <tschwinge> So our official goal is to have libpthread in glibc, at least
+      for Debian purposese?
+    <youpi> for any port purpose
+    <tschwinge> Ack.
+    <youpi> provided you're using glibc, you're deemed to ship libpthread with
+      it
+    <youpi> because of the strong relations Drepper puts between them
+    <youpi> (just to remind: we already have bugs just because our current
+      libpthread isn't bound enough to glibc: dlopen()ing a library depending
+      on libpthread doesn't work, for instance)
+    <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread
+      isn't used
+    <pinotree> (would be nice to not have those issues anymore...)
+    <tschwinge> So -- what do we need to put it into glibc?  We can make
+      libpthread a Git submodule (or move the code; but it's shared also for
+      Neal's viengoos, so perhaps the submodule is better?), plus some glibc
+      make foo, plus some other adaptions (stubs, etc.)
+    <tschwinge> Does that sound about right, or am I missing something
+      fundamental?
+    <youpi> I actually don't know what a git submodule permits :)
+    <youpi> looks like a good thing for this, yes
+    <tschwinge> Unfortunately I can't allocate much time at the moment to work
+      on this.  :-/
+    <youpi> well, as long as I know where we're going, I can know how to
+      package stuff in Debian
+    <tschwinge> That sounds like a plan to me.  libpthread -> glibc as
+      submodule.
+    <youpi> (note: actually, the interface between glibc and the libpthread is
+      the responsibility of the libpthread: it gives a couple of .c files to be
+      shipped in libc.so)
+
+
+# IRC, freenode, #hurd, 2012-04-21
+
+    <youpi> had you tried to build libpthread as a glibc addon?
+    <tschwinge> youpi: No, I only know about libpthread in Hurd build system,
+      and libpthread stand-alone (with the Auto* stuff that I added), but not
+      yet as a glibc add-on.
+    <youpi> k
+    <youpi> I'm trying it atm
+    <tschwinge> Oh, OK.
+    <youpi> that should fix the no-add-needed issue in gcc/binutils, as well as
+      the pthread_threads assertion errors in threaded plugins
+    <youpi> (once I add forward.c, but that part should not be hard)
+    <pinotree> that means also less use of pthread-stubs^
+    <pinotree> ?
+    <youpi> tschwinge: do you remember whether sysdeps/mach/bits/spin* are used
+      by anybody?
+    <youpi> they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and
+      come in the way when building in glibc
+    <youpi> pinotree: rid of pthread-stubs yes
+    <pinotree> \o/
+    <tschwinge> youpi: You mean sysdeps/mach/i386/machine-lock.h?  No idea
+      about that one, sorry.
+    <youpi> I'm talking about libpthread
+    <youpi> not glibc
+    <tschwinge> Oh.
+    <tschwinge> sysdeps/i386/bits/spin-lock.h:# define
+      __PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0)
+    <tschwinge> Anyway, no idea about that either.
+    <youpi> that one is meant to be used with the spin-lock.h just below
+    <youpi> +-inline
+    <youpi> also, I guess signal/ was for the l4 port?
+    <tschwinge> youpi: I guess so.
+    <youpi> tschwinge: I have an issue with sysdeps pt files:
+      sysdeps/hurd/pt-getspecific.c is not looked for by libc ; symlinking into
+      sysdeps/mach/hurd/pt-getspecific.c works
+    <youpi> we don't have a non-mach sysdeps directory?
+    <pinotree> youpi: if you add sysdeps/mach/hurd/Implies containing only
+      "hurd", does sysdeps/hurd work?
+    <youpi> ah, right
+    <pinotree> youpi: did it work? (and, it was needed in sysdeps/mach/hurd, or
+      in libpthread/sysdeps/mach/hurd?)
+    <youpi> pinotree: it worked, it was for libpthread
+    <youpi> good: I got libpthread built and forward working
+
+
+## IRC, freenode, #hurd, 2012-04-23
+
+    <youpi> phew
+    <youpi> confirmed that moving libpthread to glibc fixes the gcc/binutils
+      no-add-needed issue
+
+
+## IRC, freenode, #hurd, 2012-08-07
+
+    <tschwinge> Also, the Savannah hurd/glibc.git one does not/not yet include
+      libpthread.
+    <tschwinge> But that could easily be added as a Git submodule.
+    <tschwinge> youpi: To put libpthread into glibc it is literally enough to
+      make Savannah hurd/libpthread.git appear at [glibc]/libpthread?
+    <youpi> tschwinge: there are some patches needed in the rest of the tree
+    <youpi> see in debian, libpthread_clean.diff, tg-libpthread_depends.diff,
+      unsubmitted-pthread.diff, unsubmitted-pthread_posix_options.diff
+    <tschwinge> The libpthread in Debian glibc is
+      hurd/libpthread.git:b428baaa85c0adca9ef4884c637f289a0ab5e2d6 but with
+      25260994c812050a5d7addf125cdc90c911ca5c1 »Store self in __thread variable
+      instead of threadvar« reverted (why?), [...]
+
+..., and 549aba4335946c26f2701c2b43be0e6148d27c09 »Fix libpthread.so symlink«
+cherry-picked.
+
+    <braunr> tschwinge: is there any plan to merge libpthread.git in glibc.git
+      upstream ?
+    <tschwinge> braunr, youpi: Has not yet been discussed with Roland, as far
+      as I know.
+    <youpi> has not
+    <youpi> libpthread.diff is supposed to be a verbatim copy of the repository
+    <youpi> and then there are a couple patches which don't (yet) make sense
+      upstream
+
+
+## IRC, OFTC, #debian-hurd, 2013-02-08
+
+    <tschwinge> I also have it on my (never-ending) agenda to add libpthread to
+      the tschwinge/Roger_Whittaker branch and/or propose it be added upstream
+      (as a Git submodule?).
+    <pinotree> imho a git submodule could be a solution, if glibc people would
+      accept it
+    <pinotree> if so, libpthread.git would need proper glibc/x.y branches to
+      follow glibc
+    <tschwinge> Yep.
+    <tschwinge> I though that would be the least invasive approach for glibc
+      upstream -- and quite convenient for us, too.
+    <pinotree> after all, git submodules don't track branches, but point to
+      specific commits, no?
+    <tschwinge> Correct.
+    <tschwinge> So we can do locally/in Debian whatever we want, and every once
+      in a while update the upstream glibc commit ID for libpthread.
+    <pinotree> so we could update the git submodule references in glibc when
+      we've tested enough libpthread changes
+    <tschwinge> Just like when committing patches upstream, just without
+      pestering them with all the patches/commits.
+    <tschwinge> Yep.
+
+
+# IRC, freenode, #hurd, 2012-11-16
+
+    <pinotree> *** $(common-objpfx)resolv/gai_suspend.o: uses
+      /usr/include/i386-gnu/bits/pthread.h
+    <pinotree> so the ones in the libpthread addon are not used...
+    <tschwinge> pinotree: The latter at leash should be useful information.
+    <pinotree> tschwinge: i'm afraid i didn't get you :) what are you referring
+      to?
+    <tschwinge> pinotree: s%leash%least -- what I mean was the it's actually a
+      real bug that not the in-tree libpthread addon include files are being
+      used.
+    <pinotree> tschwinge: ah sure -- basically, the stuff in
+      libpthread/sysdeps/generic are not used at all
+    <pinotree> (glibc only uses generic for glibc/sysdeps/generic)
+    <pinotree> tschwinge: i might have an idea how to fix it: moving the
+      contents from libpthread/sysdeps/generic to libpthread/sysdeps/pthread,
+      and that would depend on one of the latest libpthread patches i sent
+
+
+# libihash
+
+## IRC, freenode, #hurd, 2012-11-16
+
+    <pinotree> also, libpthread uses hurd's ihash
+    <tschwinge> Yes, I already thought a little bit about the ihash thing.  I
+      besically see two options: move ihash into glibc ((probably?) not as a
+      public interface, though), or have libpthread use of of the hash
+      implementations that surely are already present in glibc.
+    <tschwinge> My notes say:
+    <tschwinge>       * include/inline-hashtab.h
+    <tschwinge>       * locale/programs/simple-hash.h
+    <tschwinge>       * misc/hsearch_r.c
+    <tschwinge>       * NNS; cf. f46f0abfee5a2b34451708f2462a1c3b1701facd
+    <tschwinge> No idea whether they're equivalent/usable.
+    <pinotree> interesting
+    <tschwinge> And no immediate recollection what NNS is;
+      f46f0abfee5a2b34451708f2462a1c3b1701facd is not a glibc commit after all.
+      ;-)
+    <tschwinge> Oh, and: libiberty: `hashtab.c`
+    <pinotree> hmm, but then you would need to properly ifdef the libpthread
+      hash usage (iirc only for pthread keys) depending on whether it's in
+      glibc or standalone
+    <pinotree> but that shouldn't be an ussue, i guess
+    <pinotree> *issue
+    <tschwinge> No that'd be fine.
+    <tschwinge> My understanding is that the long-term goal (well, no so
+      long-term, actually) is to completely move libpthread into glibc.
+    <pinotree> ie have it buildable only ad glibc addon?
+    <tschwinge> Yes.
+    <tschwinge> No need for more than one mechanism for building it, I think.
+    <tschwinge> Hmm, this doesn't bring us any further:
+      https://www.google.com/search?q=f46f0abfee5a2b34451708f2462a1c3b1701facd
+    <pinotree> yay for acronyms ;)
+    <tschwinge> So, if someone figures out what NNS and this commit it are: one
+      beer.  ;-)