diff options
Diffstat (limited to 'open_issues/glibc/debian.mdwn')
| -rw-r--r-- | open_issues/glibc/debian.mdwn | 168 |
1 files changed, 0 insertions, 168 deletions
diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn deleted file mode 100644 index 2ef2c474..00000000 --- a/open_issues/glibc/debian.mdwn +++ /dev/null @@ -1,168 +0,0 @@ -[[!meta copyright="Copyright © 2011, 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 -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]]."]]"""]] - - -# Open Issues - -`threads = yes` is set in `debian/sysdeps/linux.mk` and -`debian/sysdeps/kfreebsd.mk`, `debian/sysdeps/hurd.mk` set to `no`. But this -is only read in `debian/rules` for deciding some `nscd` package issue? - -`debian/sysdeps/hurd.mk`'s `libc_extra_install` for `ld.so`: check with GCC -configuration. - -Could add a toggle to `$(stamp)build_%` in `debian/rules.d/build.mk` to skip -locale stuff. - -`--disable-compatible-utmp`? - - -## IRC, freenode, #hurd, 2013-08-28 - - <youpi> uh, the i686 profiles have much more progression than i386 - <youpi> it seems they don't actually run these - <pinotree> youpi: what do you mean with "we don't run those"? - <pinotree> iirc there are three build profiles done, but there are 4 - regression test files - <youpi> yes, but some failing tests are not run in the three build profiles - <youpi> even if they are built for all of them - <pinotree> not even run? which ones? - <youpi> see for instance test-ifloat.out - <youpi> test-ifloat is built in all profiles, but only run in the libc one - <pinotree> don't have a glibc built tree around atm, sorry :/ - <youpi> perhaps because glibc thinks it's not useful to run it again if it - fails on i386 - <youpi> you can check the logs - <pinotree> do you think glibc's build system is that smart? :) - <pinotree> all the builds are done in separate builddirs, so theorically - they should not touch each other... - <youpi> yes - <youpi> that's why I'm surprised - <pinotree> could it be they get not run in optimized/particular builds? - <pinotree> what about linux/kfreebsd i386? - <youpi> I don't see what makes them not run - <youpi> or at least be treated particularly by th eMakefile - <youpi> not run on kfreebsd either - <youpi> pinotree: also, most of the tests now working have been marked as - failing by your patches for 2.17, would it be possible to retry them on - the box you used at that time? - <pinotree> that's the vm on my machine - <youpi> which kind of vm? - <youpi> kvm? - <pinotree> y - <youpi> they are working here - <youpi> with kvm - - -# Building - -Run `debian/rules patch` to apply patches (instead of having it done during the -build). Then you can edit files manually. - -Several passes: `libc`, `i686`, `xen`; `EGLIBC_PASSES='libc i686'`, etc. - -If building with `EGLIBC_PASSES=libc` (more specifically, without `xen`), the -`libc0.3-dev_extra_pkg_install` rule in `debian/sysdeps/hurd-i386.mk` will -fail. (Same for `libc6-dev_extra_pkg_install` in `debian/sysdeps/i386.mk`, for -example.) Why is this special handling only done for `xen`, but not for -`i686`? - -> Samuel: Historically because it's done that way in linux-i386. I don't know -> the real reason. - -Do `export LC_ALL=C` before building, otherwise the testsuite/make error -messages will be different from those stored in the -`debian/testsuite-checking/expected-results-*` files, resulting in a spurious -build failure. - -Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]` -to build (or `build` instead of `build-arch` to build the arch-independent -stuff, too). Can interrupt with `C-c` during locale stuff or testsuite if only -interested in the build tree. - -Run `fakeroot debian/rules binary DEB_BUILD_OPTIONS=parallel=2 -[EGLIBC_PASSES=...]` to build Debian packages or `binary-arch` for just the -architecture-dependent ones. - -The latter two steps can also be combined as `dpkg-buildpackage -R'debian/rules -EGLIBC_PASSES=libc' -nc -b -uc`. `-nc` will prevent the *clean step* which -would first try to un-patch, which may conflict if you have done any edits -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 |