diff options
Diffstat (limited to 'open_issues/glibc')
| -rw-r--r-- | open_issues/glibc/0.4.mdwn | 4 | ||||
| -rw-r--r-- | open_issues/glibc/debian.mdwn | 67 | ||||
| -rw-r--r-- | open_issues/glibc/debian/experimental.mdwn | 60 | ||||
| -rw-r--r-- | open_issues/glibc/t/tls-threadvar.mdwn | 12 |
4 files changed, 142 insertions, 1 deletions
diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn index ceb5ea21..f864469d 100644 --- a/open_issues/glibc/0.4.mdwn +++ b/open_issues/glibc/0.4.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013 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 @@ -10,6 +10,8 @@ License|/fdl]]."]]"""]] [[!tag open_issue_glibc open_issue_libpthread]] +Things to consider doing when bumping the glibc SONAME. + # IRC, freenode, #hurd, 2012-12-14 diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn index 331632f3..9886ec98 100644 --- a/open_issues/glibc/debian.mdwn +++ b/open_issues/glibc/debian.mdwn @@ -62,3 +62,70 @@ apter applying patches. If the Debian symbol versioning file is not up to date and the build of Debian packages fails due to this, putting `DPKG_GENSYMBOLS_CHECK_LEVEL=0` in the environment \`\`helps''; see `man dpkg-gensymbols`. + + +# IRC, freenode, #hurd, 2013-07-01 + + <braunr> something seems to have changed with regard to patch handling in + eglibc 2.17 + <braunr> pinotree: when i add a patch to series and use dpkg-buildpackage, + i'm told there are local modifications and the build stops :/ + <braunr> any idea what i'm doing wrong ? + <pinotree> which steps do you do? + <braunr> i extract the sources, copy the patch to debian/patches/hurd-i386, + add the appropriate line to debian/patches/series, call dch -i, then + dpkg-buildpackage + <pinotree> eglibc is a "3.0 (quilt)" format source package + <pinotree> this means its default patches are in a quilt-style system, and + they are applied on extraction + <braunr> ok + <braunr> and it can't detect new patches ? + <pinotree> so if you add a new patch to the global serie, you have to push + it manually + <braunr> i have to revert them all ? + <braunr> ok + <braunr> how do i do that ? + <pinotree> quilt push -a + <braunr> ok + <braunr> thanks + <pinotree> remember to do that before starting the build, since the rest + assumes the quilt-style patches are fully applied + <bddebian> No push applies them, quilt pop -a reverts them + <pinotree> yeah, and he has to push the new over the dpkg-applied ones + <bddebian> Oh, aye + <braunr> does quilt change series ? + <pinotree> no + <braunr> ok + <pinotree> i mean, some commands do that + <braunr> so i do everything i did, with an additional push, right ? + <pinotree> ok, screw me, i didn't get your question above :P + <braunr> does that change your answer ? + <pinotree> <braunr> does quilt change series ? + <braunr> yes + <pinotree> if you import or create a new patch, it changes series indeed + <braunr> ok + <pinotree> push or pop of patches does not + <braunr> i'm doing it wron + <braunr> g + <pinotree> btw, in a quilt patch stack you can easily import a new patch + using the import command + <pinotree> so for example you could do + <pinotree> apt-get source eglibc # or get it somehow else + <pinotree> cd eglibc-* + <pinotree> quilt import /location/of/my/patch + <pinotree> quilt push # now your patch is applied + <braunr> ah thanks + <pinotree> dpkg-buildpackage as usual + <braunr> that's what i was looking for + <bddebian> quilt new adds a new entry in series + <pinotree> y + <bddebian> or import, aye + <pinotree> braunr: if you want to learn quilt, a very good doc is its own, + eg /usr/share/doc/quilt/quilt.txt.gz + * bddebian has never actually used import + <braunr> ok + <pinotree> it is basically a simple stack of patches + + <youpi> braunr: yes, patch handling is a bit different + <youpi> the arch-independant patches are applied by dpkg-source -x + <youpi> and the arch-dependent patches are applied during build diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn index 8d117e99..5168479d 100644 --- a/open_issues/glibc/debian/experimental.mdwn +++ b/open_issues/glibc/debian/experimental.mdwn @@ -11,6 +11,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_glibc]] Issues with the current 2.17 version of glibc/EGLIBC in Debian experimental. +Now in unstable. # IRC, OFTC, #debian-hurd, 2013-03-14 @@ -113,3 +114,62 @@ Issues with the current 2.17 version of glibc/EGLIBC in Debian experimental. eventually? (Some experimental package(s), but which?) <youpi> that was libc0.3 packages <youpi> which are indeed known to break the network + + +# IRC, freenode, #hurd, 2013-06-18 + + <braunr> root@darnassus:~# dpkg-reconfigure locales + <braunr> Generating locales (this might take a + while)... en_US.UTF-8...Segmentation fault + <braunr> is it known ? + <youpi> uh, no + + +## IRC, OFTC, #debian-hurd, 2013-06-19 + + <pinotree> btw i saw too the segmentation fault when generating locales + + +# IRC, OFTC, #debian-hurd, 2013-06-20 + + <youpi> damn + <youpi> hang at ext2fs boot + <youpi> static linking issue, clearly + + +## IRC, freenode, #hurd, 2013-06-30 + + <youpi> Mmm + <youpi> __access ("/etc/ld.so.nohwcap", F_OK) at startup of ext2fs + <youpi> deemed to fail.... + <pinotree> when does that happen? + <youpi> at hwcap initialization + <youpi> at least that's were ext2fs.static linked against libc 2.17 hangs + at startup + <youpi> and this is indeed a very good culprit :) + <pinotree> ah, a debian patch + <youpi> does anybody know a quick way to know whether one is the / ext2fs ? + :) + <pinotree> isn't the root fs given a special port? + <youpi> I was thinking about something like this, yes + <youpi> ok, boots + <youpi> I'll build a 8~0 that includes the fix + <youpi> so people can easily build the hurd package + <youpi> Mmm, no, the bootstrap port is also NULL for normally-started + processes :/ + <youpi> I don't understand why + <youpi> ah, only translators get a bootstrap port :/ + <youpi> perhaps CRDIR then + <youpi> (which makes a lot of sense) + + +## IRC, freenode, #hurd, 2013-07-01 + + <braunr> youpi: what is local-no-bootstrap-fs-access.diff supposed to fix ? + <youpi> ext2fs.static linked againt debian glibc 2.17 + <youpi> well, as long as you don't build & use ext2fs.static with it... + <braunr> that's thing, i want to :) + <braunr> +the + <youpi> I'd warmly welcome a way to detect whether being the / translator + process btw + <youpi> it seems far from trivial diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn index 105a07c7..609d866b 100644 --- a/open_issues/glibc/t/tls-threadvar.mdwn +++ b/open_issues/glibc/t/tls-threadvar.mdwn @@ -64,3 +64,15 @@ dropped altogether, and `__thread` directly be used in glibc. <youpi> I saw the mails, but didn't investigate at all [[!message-id "878vdyqht3.fsf@kepler.schwinge.homeip.net"]]. + + +# IRC, freenode, #hurd, 2013-07-08 + + <youpi> tschwinge: apparently there were a lot of changes missing in the + threadvars branch I had commited long time ago + <youpi> I'm gathering things + <tschwinge> youpi: t/tls-threadvar you mean? + <youpi> yes + <youpi> tschwinge: yes, there were a lot other occurences of threadvars + stuff in various places + <youpi> I'm building libc again, and will see what issue would remain |