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
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
[[!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
|
