[[!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 uh, the i686 profiles have much more progression than i386 it seems they don't actually run these youpi: what do you mean with "we don't run those"? iirc there are three build profiles done, but there are 4 regression test files yes, but some failing tests are not run in the three build profiles even if they are built for all of them not even run? which ones? see for instance test-ifloat.out test-ifloat is built in all profiles, but only run in the libc one don't have a glibc built tree around atm, sorry :/ perhaps because glibc thinks it's not useful to run it again if it fails on i386 you can check the logs do you think glibc's build system is that smart? :) all the builds are done in separate builddirs, so theorically they should not touch each other... yes that's why I'm surprised could it be they get not run in optimized/particular builds? what about linux/kfreebsd i386? I don't see what makes them not run or at least be treated particularly by th eMakefile not run on kfreebsd either 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? that's the vm on my machine which kind of vm? kvm? y they are working here 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 something seems to have changed with regard to patch handling in eglibc 2.17 pinotree: when i add a patch to series and use dpkg-buildpackage, i'm told there are local modifications and the build stops :/ any idea what i'm doing wrong ? which steps do you do? 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 eglibc is a "3.0 (quilt)" format source package this means its default patches are in a quilt-style system, and they are applied on extraction ok and it can't detect new patches ? so if you add a new patch to the global serie, you have to push it manually i have to revert them all ? ok how do i do that ? quilt push -a ok thanks remember to do that before starting the build, since the rest assumes the quilt-style patches are fully applied No push applies them, quilt pop -a reverts them yeah, and he has to push the new over the dpkg-applied ones Oh, aye does quilt change series ? no ok i mean, some commands do that so i do everything i did, with an additional push, right ? ok, screw me, i didn't get your question above :P does that change your answer ? does quilt change series ? yes if you import or create a new patch, it changes series indeed ok push or pop of patches does not i'm doing it wron g btw, in a quilt patch stack you can easily import a new patch using the import command so for example you could do apt-get source eglibc # or get it somehow else cd eglibc-* quilt import /location/of/my/patch quilt push # now your patch is applied ah thanks dpkg-buildpackage as usual that's what i was looking for quilt new adds a new entry in series y or import, aye 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 ok it is basically a simple stack of patches braunr: yes, patch handling is a bit different the arch-independant patches are applied by dpkg-source -x and the arch-dependent patches are applied during build