1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
[[!meta copyright="Copyright © 2011 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`?
# 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
|
