summaryrefslogtreecommitdiff
path: root/open_issues/glibc/debian.mdwn
diff options
context:
space:
mode:
authorhttps://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14 <diana@web>2015-02-16 20:08:03 +0100
committerGNU Hurd web pages engine <web-hurd@gnu.org>2015-02-16 20:08:03 +0100
commit95878586ec7611791f4001a4ee17abf943fae3c1 (patch)
tree847cf658ab3c3208a296202194b16a6550b243cf /open_issues/glibc/debian.mdwn
parent8063426bf7848411b0ef3626d57be8cb4826715e (diff)
rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn
Diffstat (limited to 'open_issues/glibc/debian.mdwn')
-rw-r--r--open_issues/glibc/debian.mdwn168
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