diff options
Diffstat (limited to 'open_issues/packaging_libpthread.mdwn')
| -rw-r--r-- | open_issues/packaging_libpthread.mdwn | 24 |
1 files changed, 24 insertions, 0 deletions
diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn index 18f124b4..171dc7a0 100644 --- a/open_issues/packaging_libpthread.mdwn +++ b/open_issues/packaging_libpthread.mdwn @@ -155,6 +155,30 @@ cherry-picked. 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 |