Log
The following discussion about release qualification of architectures for etch took place between 00:00 and 02:15 UTC on 2005/10/09 on #debian-tech.
Participants
Ganneff - ?JoergJaspert
Q_ - ?KurtRoeckx
Sledge - SteveMcIntyre
aj - AnthonyTowns
dato - ?AdeodatoSimo
elmo - ?JamesTroup
fjp - ?FransPop
joeyh - JoeyHess
jvw - ?JeroenVanWolffelaar
kyle - ?KyleMcMartin
kyllikki - ?VincentSanders
lennert - ?LennertBuytenhek
neuro - RyanMurray
rwhitby - ?RodWhitby
ths - ?ThiemoSeufer
vorlon - ?SteveLangasek
waldi - BastianBlank
weasel - ?PeterPalfrader
willy - ?MatthewWilcox
wookey - ?Wookey
zack - ?ZackCerza
Summary and Log
This session was arranged to give porters an opportunity to voice in realtime any concerns about the stated architecture criteria for etch, and to make as much progress as possible on establishing where the architectures are today with respect to those criteria. Information about the event, including information on the qualification status of various ports, is available at IRC/debian-tech/Event/20051009-releasequalification.
1 00:03 -!- vorlon changed the topic of #debian-tech to: Channel info: http://wiki.debian.org/IRC/debian-tech | Now playing: http://wiki.debian.org/IRC/debian-tech/Event/20051009-releasequalification
2 00:03 <waldi> 3 minutes too late *hide*
3 00:03 <vorlon> ;)
4 00:04 <joeyh> hmm, the ia64etchreleaserecertification page on the wiki isn't there
5 00:04 <joeyh> oh, wiki is case sensative, let's fix the link
6 00:04 <vorlon> so if people are here for the port requalification stuff, could you please say something so we have some idea of who's here?
7 00:05 <vorlon> joeyh: oh, it's not jvw trying to vancouver ia64? :)
8 00:05 <kyle> good evening.
9 00:05 * vorlon waves to kyle
10 00:05 <waldi> vorlon: ping
11 00:06 <wookey> I'm here to represent arm
12 00:06 <neuro> I'm in Vancouver.
13 00:06 * lennert is an observer on behalf of the unofficial armeb port
14 00:06 * jvw recovers the map of vancouver I still have laying around somewhere...
15 00:06 <jvw> lennert: typically, observers don't speak ;-) [but never mind]
16 00:06 <rwhitby> I'm here representing the nslu2-linux project (using the fledgling armeb port) and supporting arm.
17 00:07 * zack is impersoning joe random developer interested in the requalification stuff
18 00:07 <vorlon> aj: ping?
19 00:07 <lennert> jvw: *muted sounds*
20 00:07 <waldi> zack: anyway, request granted
21 00:07 <wookey> What's the proceedure here - just get stuck in, or does our chairman want to try and control the agenda?
22 00:08 <joeyh> oddly enough I can also represent a company that does arm
23 00:08 <vorlon> wookey: I'm imagining something freeform; aj may have other ideas, but I haven't seen aj on IRC yet this morning
24 00:08 <wookey> OK, can I start by saying I'm a bit concerned about this '2 buildds' rule
25 00:09 <wookey> It's only just practical for us now, and I expect things only to get worse over time
26 00:09 <wookey> I understand that more buildds means more overhead, but I don't really think it's a sensible _rule_
27 00:10 <wookey> If an arch can lok after its buildds then it should bne allowed toi use as many as is necessary, surely?
28 00:10 <elmo> no, not surely
29 00:10 <neuro> wookey: it already took us a long time after the release of etch to update chroots on the buildds we have now.
30 00:10 <wookey> aha elmo - hi
31 00:11 <joeyh> hasn't that already been discussed to death on the lists?
32 00:11 <wookey> maybe it has, in which case I'll shut up
33 00:11 <vorlon> yeah, it's been discussed quite a bit
34 00:12 <wookey> But what if the two fastest arm boxes in the world can't keep up?
35 00:12 <waldi> arm isn't that slow
36 00:12 <joeyh> then you have to accept that keeping arm as a release architecture would cause unavoidable issues for the release team, security team, etc
37 00:12 <joeyh> s/you have/you'd have
38 00:12 <vorlon> I can understand that people affiliated with ports based on slower procs are going to dislike this rule, but you have to bear in mind that parallelized buildd networks don't help in the case of deep transitions that have to be done serially, which are a concern throughout the release
39 00:13 <neuro> and when you expand from a single buildd maintainer to a large "team", where each package is building on a different system, with a different person's daily schedule...
40 00:14 <neuro> it starts to add additional days to each layer of the transition
41 00:15 <wookey> but isn't that also true if the packages take ages to build due to insufficient resources?
42 00:15 <vorlon> so if the two fastest arms in the world can't keep up, you can try to boost performance with distcc or the like.
43 00:16 <Q_> Didn't the m68k people going to try distcc? Didn't hear anything about it.
44 00:16 <lennert> we (armeb) tried distcc to x86 boxes
45 00:16 * joeyh wonders what the fastest arms are anyway. Best I have are 400mhz xscales
46 00:16 <wookey> OK, well, we'll see how it goes. I think the armeb guys are trying distcc
47 00:16 <jvw> would it be totally crazy to actually if you can't keep up, seriously limit what you're building in the first place? If you build only a subset of lighter programs, for example, two buildd's might more easily be enough...
48 00:16 <lennert> it mostly works, but it's a pain to deal with different gcc versions that are being constantly updated
49 00:17 <lennert> and cross-compiling generates different code for float ops
50 00:17 <wookey> jvw - that would then make the '95% built rule a problem...
51 00:17 <waldi> lennert: why does it generate different code?
52 00:17 <lennert> joeyh: ixp2350 runs at 900mhz-ish, which is the fastest arm i know of
53 00:17 <neuro> jvw: that runs into the problem of, why are we calling it "the debian system" if large chunks of it aren't there?
54 00:17 <vorlon> wookey: well, not if the 95% rule was explicitly scaled to accept a specific subclass of the system; but see neuro's remarks.
55 00:17 <lennert> waldi: it seemed to generate explicit code for floating point ops with constants instead of doing them on the host
56 00:18 <jvw> neuro: yeah... fair enough. So not an option
57 00:18 <neuro> and begs the question, what exactly are we targeting anyways?
58 00:18 <waldi> lennert: ah
59 00:18 <lennert> joeyh: (ixp23xx has nice 512k l2 cache too)
60 00:18 <wookey> anyway - I don;t want to repeat arguments unecessarily
61 00:18 <vorlon> the other thing is that if you say "yes, you only have to build subset x", and there's an arch-specific toolchain problem that holds things up for a month, you now have a slow arch, that hasn't been building anything for a month, and now has to play catch-up
62 00:19 <vorlon> and can only catch up more slowly than faster archs would
63 00:19 <joeyh> wookey: are you seeing a case for stable arm releases? Because at work, we're not, using unstable or testing is ok
64 00:19 <vorlon> and strangely, even though I didn't mean to, I think I just described what happened on m68k this summer
65 00:19 <wookey> It's not completely fatal at the moment
66 00:19 <wookey> joeyh: I use stable on my server here
67 00:20 <wookey> but now there is testing-security it would be no prob to change
68 00:20 <lennert> joeyh: for armeb we're building both unstable and stable
69 00:20 <neuro> if we're not having a stable release of an arch, there wouldn't be a testing one, tho?
70 00:20 <wookey> I agree stable is probably the least-important
71 00:20 <lennert> joeyh: unstable with an eye towards eventual assimilation by debian, stable for the userbase
72 00:20 <neuro> because if there is, then we're waiting for it to be ready for a stable that we don't release
73 00:20 <joeyh> there might be a testing one that is dropped when it gets behindn and has to play catchup
74 00:20 <joeyh> which could potentially need some hand-holding from the porters for that arch
75 00:22 <wookey> vorlon: the 'having to catch up after toolchain-trouble' scenario is one where more boxes are helpful, rather than a hindrance, is it not?
76 00:22 <jvw> a kind of permanent testing-that-won't-get-stable would be possible I'd say, but because britney won't wait for your arch if you're missing a build, you'll probably need to do a bit more of for-testing building
77 00:23 <wookey> anyway, perhaps there are other issues people want to cover?
78 00:23 <vorlon> wookey: they would help, yes. This rule doesn't say "you can't have more than 2 buildds", it says "no more than 2 buildds should be necessary for keeping up with the archive"
79 00:23 <jvw> wookey: you're missing the point that the fact that you *need* a lot of boxes, implies it's a slow arch, and that there probably isn't a serious amount of overpower
80 00:23 -!- faw [~felipe@201.24.232.152] has joined #debian-tech
81 00:24 <wookey> jvw: no, that's the point I am concerned about, I don;t think I'm missing it? perhaps I misunderstand you?
82 00:24 <vorlon> wookey: adding more buildds doesn't give you parallelization of individual packages, so some of those packages are going to take a while to build, and some of those large packages are going to block lots of other stuff until they're done...
83 00:24 <neuro> testing loses it's point on a given arch if you are always setting a given arch to "who cares"
84 00:24 <jvw> m68k needs, what, 12 buildd's for normal usage, but they don't have 24 of them in order to catch up when needed
85 00:24 <wookey> vorlon: exactly
86 00:24 <vorlon> btw, since we've got so many arm people present, who wants to tell me what the deal is with the perl arm failure?
87 00:24 <vorlon> (not necessarily during this session, though :)
88 00:25 <lennert> "12" vs. "34"?
89 00:25 <wookey> vorlon: the arm perl guru isn;t here (nick)
90 00:25 <lennert> Fails test suite:
91 00:25 <lennert> > t/op/pack.................................# Failed at op/pack.t line 441
92 00:25 <lennert> > # got '34'
93 00:25 <lennert> > # expected '12'
94 00:25 <lennert> that one?
95 00:26 <lennert> didn't look at that yet i must admit
96 00:26 <lennert> we (armeb) only got around to building that package ~3 days ago
97 00:26 <neuro> so you don't even have build-essential built yet?
98 00:27 <lennert> not for unstable, no
99 00:27 -!- fjp [~fjp@195-240-184-66-mx.xdsl.tiscali.nl] has joined #debian-tech
100 00:27 <lennert> that's why i
101 00:27 <lennert> 'm 'observing'
102 00:27 <wookey> noisily :-)
103 00:27 <lennert> armeb has no chance of being in etch
104 00:27 <lennert> wookey: yeah, sorry :)
105 00:27 <vorlon> wookey: hrm, "exactly" what? I'm saying that if the arch isn't fast enough to build a core package, such as gcc, glibc, perl, gtk, ... within a specific but unspecified period of time, this exacerbates the impact of any toolchain breakage and hurts testing for everyone
106 00:27 <joeyh> it's quantum.
107 00:28 <vorlon> lennert: there's more than one failure in the build log that I saw. Point is, someone needs to take care of it, because Debian is *also* currently without a porter machine for arm...
108 00:29 <joeyh> fwiw, I've been trying to line one up
109 00:29 <wookey> ah, OK, I thought you were saying that some packages inevitably fill up a buildd for ages so that's when a bit more parallelization can help (because other machine can build other stuff)
110 00:29 <joeyh> just waiting to hear back from elmo on if what we can offer is good enough
111 00:29 <vorlon> joeyh: ok, cool
112 00:30 <vorlon> wookey: nah, this once again comes back to "buildd parallelization doesn't solve all problems"
113 00:30 <lennert> vorlon: point taken.
114 00:30 <vorlon> distcc would solve more, if it's viable. The m68k folks seemed to have doubts that it would improve things for them
115 00:31 <lennert> vorlon: just to have that clear; distcc to x86 boxes or to same-arch boxes?
116 00:31 <neuro> distcc also suddenly requires all makefiles to be written to support make -j...
117 00:31 <joeyh> ports need to be able to build X quickly enough to not delay security updates. They need to be able to build gcc fast enough to unstick all the packages broken by the latest version. Etc.
118 00:31 <wookey> OK, so the main problem is the build time of major packages
119 00:31 <lennert> we did a make wrapper to force -j N (for some value of N) and that broke badly
120 00:31 <joeyh> not if you distcc to one amd64 ;-)
121 00:31 <vorlon> lennert: whatever meets the needs of the port? I think m68k frontend+big x86/amd64 backend was discussed
122 00:31 <lennert> yeah, ok, except that it doesn't generate the same code
123 00:32 <vorlon> joeyh: exactly.
124 00:32 <lennert> not sure if that's a problem, but it doesn't seem like a desirable property to me
125 00:32 <vorlon> lennert: well, then it's not a viable option for you, because you have a broken cross-compiler. :)
126 00:32 <wookey> OK, that's helped me understand the rule.
127 00:32 <lennert> vorlon: i don't gcc cross generates identical code in any case
128 00:32 <lennert> vorlon: s/gcc/think gcc/
129 00:32 <lennert> vorlon: a cross-compiler cannot evaluate things like 12345*0.1
130 00:33 <vorlon> lennert: it should. When it doesn't, that's a bug.
131 00:33 <Sledge> hmmm
132 00:33 <lennert> vorlon: it will generate functionally identical code but not identical code
133 00:33 <waldi> vorlon: no, this is just an compiletime optimization
134 00:33 <vorlon> (yeah, nasty floating point, blah... ok, hook your cross-compiler gcc to a copy of qemu ;)
135 00:33 <Sledge> _could_ we work on the bigger packages to make them more friendly for make -j<foo>?
136 00:33 <wookey> hello sledge
137 00:33 <Sledge> hey wookey
138 00:34 <lennert> vorlon: ok, if that's not a problem, all the better for us
139 00:34 <ths> Sledge: This would be generally desireable.
140 00:34 <neuro> better is to break such huge packages up into component pieces.
141 00:34 <Sledge> yeah, that too
142 00:34 <lennert> neuro: like X, yes
143 00:34 <vorlon> ok, let me clarify then: a cross-compiler that doesn't generate functionally identical code is buggy
144 00:34 <waldi> vorlon: no
145 00:34 <waldi> s/no/yes/
146 00:34 <vorlon> hah!
147 00:34 <lennert> vorlon: functionally identical shouldn't be a problem
148 00:34 * vorlon quotefiles that regex
149 00:34 * Sledge pokes waldi :-)
150 00:35 <waldi> vorlon: bah ;)
151 00:35 <neuro> it's just not optimal, and if the arch is so slow that we are talking about such things, speed of built binaries will be a bigger factor...
152 00:36 <joeyh> well, that's half an hour for arm, so we have 3 more halfs of hours for the other 3 arches we will (or won't?) release with.. ;-)
153 00:36 <kyle> which 3? :)
154 00:36 <vorlon> joeyh: well, we only have hppa, s390, and arm represented here, I think :)
155 00:36 <Sledge> no alpha people?
156 00:36 <wookey> no that was half an hour on 'why 2 buildds' :-)
157 00:36 <waldi> vorlon: powerpc, maybe
158 00:36 <joeyh> mips
159 00:36 <wookey> (sorry)
160 00:36 <vorlon> ah, ok. :)
161 00:36 <Ganneff> and amd64. :)
162 00:36 <neuro> and mips counts as two archs!
163 00:36 <kyle> fwiw, 2 buildds shouldn't be a problem for hppa.
164 00:36 <vorlon> Ganneff: you didn't speak up at the beginning, so you don't count. ;)
165 00:36 <joeyh> yay for mips counting as 2 arches
166 00:37 <joeyh> :-P
167 00:37 <Ganneff> vorlon: im not an amd64 porter. :)
168 00:37 <Sledge> and arm heading the same way
169 00:37 <waldi> joeyh: hmm, periodic reboot with flaping endianess-selection? ;)
170 00:37 <joeyh> tbm does it
171 00:37 * Sledge tsks at people who can't make their mind up on which way to swing
172 00:37 <vorlon> are there any other criteria that people have concerns about being able to meet for their ports, or that they think should be worded better? That's definitely in scope for this session
173 00:37 <Q_> amd64 isn't in unstable yet, so who cares?
174 00:38 <Ganneff> Q_: you should
175 00:38 <joeyh> Q_ just think, you only have to knck out one of these arches to get amd64 in
176 00:38 <waldi> vorlon: it speaks about "developers", which sort of developers?
177 00:38 <vorlon> waldi: Debian developers
178 00:38 <wookey> the last version of the 'ports' doc is the one wouter published after debconf - right?
179 00:38 <vorlon> waldi: people who can actually pick up the slack and do porter uploads of packages when things need fixing
180 00:39 <neuro> I think we should specify that there must be a debian developer who has commit access for patches for that port for all of the toolchain packages
181 00:39 <waldi> neuro: where is the repository for binutils?
182 00:40 <wookey> I suppose I kind of wonder what '5 developers' means?
183 00:40 <neuro> waldi: well, that's something that may be needed as well.
184 00:40 -!- Zomb [~eb@x118.rhrk.uni-kl.de] has joined #debian-tech
185 00:40 <waldi> neuro: maybe just push merge it with gcc
186 00:40 <Q_> And kernel.
187 00:40 <waldi> kernel is no problem
188 00:40 <wookey> we have 5 developers who take an interest, but somewhat randomly.
189 00:41 <wookey> >5, but obviously some are keener than others
190 00:41 <vorlon> wookey: people who are willing to do the work to fix the port when it breaks
191 00:41 <wookey> OK.
192 00:42 <wookey> but people have different expertises. We probably only have two who can do really hard-core toolchain things
193 00:42 <joeyh> I don't actually see the 5 developer criterion on http://release.debian.org/etch_arch_criteria.html
194 00:42 <Q_> joeyh: The 3rd.
195 00:42 <vorlon> joeyh: appears to be lumped in with "Users"
196 00:42 <joeyh> ah ok
197 00:43 <vorlon> wookey: yeah, that's probably true for most ports; but there are other things that need to be kept up on, like bootloaders, kernel, installer, general portability fixes
198 00:43 <wookey> the installer things is almost irrelevant for arm.
199 00:43 <wookey> A lot of people use debain-arm one way or another. Hardly any of them use debian-installer to do it
200 00:43 <lennert> only one of my arm boards has directly attached storage
201 00:44 <joeyh> all my arm boards except one can run d-i just fine with usb storage
202 00:44 <wookey> so 90% of our users couldn't care less whether there is instaler support or not
203 00:44 <wookey> (no offence joey :-)
204 00:44 <vorlon> well, that's again "what is the Debian system?"
205 00:45 <wookey> for many arm people it's 'a useful base'
206 00:45 <joeyh> however, a fact is that d-i just doesn't have the manpower to support all of debian's arches. It's literally a full-time job just to coordinate testing and building of d-i on 12 arches.
207 00:45 <joeyh> if we want to drop d-i for mostly embedded arches like arm, that's one solution to that problem
208 00:46 <lennert> if i can ssh into an armeb box that has all the tools that i also have on my x86 debian box, that sounds like it's debian to me
209 00:46 <wookey> joey - I certainly think it should be optional
210 00:46 <wookey> and if that helps the d-i team, then that's good.
211 00:47 <vorlon> joeyh: does *not* having d-i for arm hurt some subset of our userbase?
212 00:47 <wookey> There are some machines (like cats and netwinder) where people actually use the installer, but only once about 5 years ago in most cases
213 00:47 <joeyh> although I think you're underestimating the usage of d-i on semi-enmbeeded arches. Not everyone is cablable of deboostrapping debian from scratch
214 00:47 <vorlon> could the job of d-i be done by some of the configure-from-live-CD stuff that Ubuntu is working on?
215 00:47 <joeyh> vorlon: yes, of course
216 00:47 <vorlon> yes to which?
217 00:47 <wookey> Joey: I may be, yes - it's hard to know the proportiond
218 00:47 <joeyh> yes it hurs some users
219 00:48 * kyle uses d-i on arm.
220 00:48 <kyle> as a data point. :)
221 00:49 <joeyh> most of these things don't have CDs, and they boot in fairly diverse ways
222 00:49 <lennert> the way people currently install armeb on the nslu2 is to boot with a custom firmware image, and run some commands to download a prefabbed deboostrap tgz and customise that
223 00:49 <vorlon> so, some people need d-i, others don't. I think the requirement that there be *an* installer needs to stand; it isn't meant to imply that it has to be d-i, but there has to be something.
224 00:49 <rwhitby> nslu2-linux is trying to get debian-installer to work on Linksys NSLU2 (armeb) via netconsole
225 00:49 <wookey> I suppose at the moment there are enough conventional arm machines that there should be at least one machines supported by d-i
226 00:50 <vorlon> :)
227 00:50 <wookey> vorlon: yes, I think you are right
228 00:50 <vorlon> rwhitby: fwiw, I think it's important that we focus right now on those ports that are candidates for etch. :)
229 00:50 <rwhitby> vorlon: nod
230 00:50 <wookey> but it might not remain true - we might end up with no machines that normally use d-i
231 00:51 <wookey> but we can worry about that in due course
232 00:51 <waldi> hmm, can we do the other part of program and try to fill the criteria table?
233 00:51 <vorlon> wookey: right, well, "we have d-i, it works on this one arm box, therefore we can put a mark in the checkbox even though all the actual users are debootstrapping by hand"...
234 00:51 <joeyh> wookey: I think that's unlikely, fwiw.
235 00:51 <joeyh> based on priveliged info from one company
236 00:51 <wookey> joeyh: you are propbably right
237 00:51 <vorlon> :-)
238 00:52 <vorlon> waldi: absolutely. I think we can do both at the same time, no?
239 00:52 <ths> wookey: I think the general growth of embedded systems will make d-i more attractive.
240 00:52 <aj> what do we want to do about "privileged info"? pass it on to the RM team and have (one of) them validate it, or just assume that if a DD says it so, then it's so, or?
241 00:52 <wookey> ths: could be - I couldn;t work out ow to make it work on machines I'm responsible for :-(
242 00:52 <wookey> I seem to be too dumb
243 00:52 <joeyh> well I can probably boil it down to someting non-priveliged
244 00:52 <aj> there's been some "yeah, there's a company whose name i can't say in public that uses <arch> for <zillions> of users for <some> purpose" too
245 00:52 <wookey> so i did it a different way
246 00:53 <joeyh> in this case anyway
247 trimmings like displays, touchscreens, usb disks, and a flashy debian load. This configurtation can run d-i nicely. there.
248 00:54 <wookey> joeyh: you working for ADS now?
249 00:54 <joeyh> yep
250 00:54 <vorlon> waldi: so I assume you wanted to look at s/390 specifically. I see from the wiki that the port is short on developers...
251 00:54 <wookey> cool - sound people
252 00:55 <kyle> analog devices?
253 00:55 <waldi> vorlon: and powerpc
254 00:55 <vorlon> waldi: ok, no wiki page for that one yet
255 00:55 <aj> hrm, so there's not an arm wiki page yet?
256 00:55 <waldi> vorlon: yes, there is none
257 00:55 <wookey> kyle: nope, but I forget what it stands for
258 00:55 <kyle> ah.
259 00:55 <kyle> ah, right, analog is "ADI"
260 00:55 <wookey> aj: nope - I should just create one, I assume?
261 00:55 <aj> wookey: sure
262 00:55 <vorlon> fwiw, the biggest concern with powerpc qualifying for etch is probably going to be people assuming that someone else is taking care of it
263 00:56 <vorlon> ditto i386
264 00:56 <joeyh> heh
265 00:56 <vorlon> neither arch has buildd redundancy today, and they ought to :)
266 00:56 <joeyh> hey, any sparc people here?
267 00:57 <vorlon> doesn't look like it
268 00:57 <waldi> vorlon: debian have two openpower machines, but noone wants to use them
269 00:57 <vorlon> give me root, I'll find a use ;)
270 00:58 <joeyh> why am I not suprised?
271 00:58 <aj> waldi: list them as available and currently unused on the wiki page
272 00:58 <waldi> aj: which one?
273 00:58 <vorlon> the one you're about to create for powerpc :-)
274 00:58 <neuro> I certainly don't see anything sent to debian-admin about it this year.
275 00:58 <aj> waldi: the powerpc? qualification page
276 00:59 <waldi> neuro: tbm managed that in january
277 00:59 <aj> waldi: (also, list their current admin / connectivity status)
278 00:59 <vorlon> btw, why is everybody listing "gdb integrated upstream" as part of the toolchain? I mean, debuggers are important, but why is gdb more important than glibc and binutils? :)
279 01:00 <waldi> vorlon: thay copied the original text?
280 01:00 <aj> vorlon: i don't think anyone really groks the "upstream" expectations well
281 01:01 <vorlon> neuro, elmo: can you comment on what the salient details are that are taken into consideration wrt buildd offers? type of machine, type of hosting facility, nature and speed of connectivity, identity of local admin?
282 01:01 <aj> maybe we should set goals, either (a) dropping _x_ ports or (b) making all ports imprive to _y_ level?
283 01:01 <neuro> waldi: I see nothing with a subject that would indicate "new machines"
284 01:02 <waldi> neuro: hmm, joey knows about them
285 01:02 <neuro> joey != debian-admin
286 01:02 <fjp> aj: No a) is what was wrong with the original Vancouver proposel.
287 01:02 <neuro> there's a list for a reason. If you tell one person, well....
288 01:03 <aj> fjp: if (b) doesn't happen, (a) is required for us to release *shrug*
289 01:03 <joeyh> btw, what's going to be done about fact-checking these wiki pages? For example, the hppa page says "ArchitectureUsage shows that hppa is one of the more popular architectures", but what it actually seems to indicate is that on 3 mirrors, hppa accounts for a max of 0.75% of traffic
290 01:03 <elmo> *giggle*
291 01:03 <elmo> vorlon: that sounds about right
292 01:04 * jvw tickles elmo
293 01:04 <kyle> joeyh, i dunno who added that.
294 01:04 <vorlon> elmo: ok. any chance you could quantify some of those, so that porting teams could proactively filter offers for you guys?
295 01:04 <aj> hrm, britney's OOMing or something?
296 01:05 <willy> I added that
297 01:05 <vorlon> aj: it is? it seems to have completed a run today
298 01:05 <aj> maybe it's not mailing what i expect anymore then
299 01:05 <willy> It's true -- hppa is massively above everything except i386, ppc and sparc
300 01:06 <willy> oh, and it was level with alpha
301 01:06 <elmo> vorlon: umm, not being funny but not really? it depends on circumstance and varies per architecture. I wouldn't accept a sparc on an ADSL line right now, but most of the m68ks are and in a couple of years time, I might not have a choice with sparc
302 01:06 <kyle> i dunno what to say, hppa accounts for 100% of traffic on my mirror (which runs on a hppa...)
303 01:06 <vorlon> elmo: hmm, alright.
304 01:06 <elmo> willy: "more popular" and 0.75% don't really mix terribly well
305 01:06 <joeyh> the page that it links to does not seem to show any of that
306 01:06 <joeyh> http://dirk.eddelbuettel.com/blog/2005/03/08/#more_download_by_arch
307 01:06 <aj> in a copule of years, an ADSL line is going to be pretty impressive though
308 01:06 <vorlon> elmo: are you in the loop regarding Snow-Man's efforts to get a sparc hosted for Debian w/ his employer, btw?
309 01:06 <elmo> vorlon: no?
310 01:06 <weasel> aj: and packages will have even more bloat and be 100 times the size
311 01:07 <joeyh> the most popular listed arch on that graph is powerpc, at 2.5%
312 01:07 <waldi> hmm, the s390 autobuilders are idle most of the day
313 01:07 <waldi> do more uploades
314 01:07 <aj> weasel: we're only growing by ~30G/year for the entire archive, maybe ~5G per year by arch
315 01:07 <vorlon> elmo: ok. dilinger has a sunfire box, Snow-Man has a rack that he wants to put stuff in that helps Debian and his company (that runs lots of Debian sparc stuff), and I'm playing matchmaker. :) Should I get them to gather details for you?
316 01:07 <neuro> same with mips, i386, powerpc, alpha
317 01:08 <elmo> vorlon: I know about dilinger, not snow-man tho - I'm behind on d-a@l.d.o tho, dunno if he's mailed there
318 01:08 <neuro> no machine offers there lately
319 01:08 <vorlon> I don't know if he has. He's still in the process of getting it approved by management.
320 01:08 <elmo> ok
321 01:09 <aj> Out of dates holding up testing:
322 01:09 <fjp> OTOH sparc has a serious shortage in developers IMO
323 01:09 <neuro> the poor adsl connections have been the cause of several days of delay in security and large package uploads, tho
324 01:09 <aj> 125 hppa
325 01:09 <aj> 214 sparc
326 01:09 <aj> 284 arm
327 01:09 <aj> 397 m68k
328 01:09 * joeyh cheers arm on :-P
329 01:09 <aj> 3 i386
330 01:09 <aj> 55 s390
331 01:09 <aj> ^ are the top two
332 01:09 <elmo> sparc is still recovering from the kernel-deaths of vore/auric
333 01:10 <aj> #2-#6 are pretty much the same (55-89)
334 01:10 <waldi> aj: hihi
335 01:10 <willy> joeyh: Look at it on each country. For Italy, hppa is behind ppc and ia64. For Sweden, hppa is behind ppc, ia64 and sparc. For the UK, hppa is middle-of-the-pack
336 01:11 <joeyh> fwiw, d-i is currently being blocked by: out of dates on arm, toolchain on ia64, general unhappiness on sparc
337 01:11 <vorlon> fjp: in theory, sparc has dilinger and trave11er. joshk is apparently inactive now that he's gone to college without his box. I don't know if there are others, I'm not following debian-sparc.
338 01:11 <wookey> Is the object of this excercise to actually drop some arches for etch?
339 01:12 <joeyh> which is pretty much a direct result of aj's numbers, although somehow m68k has escaped .. oh yeah, it's not build d-i yet at all
340 01:12 <wookey> or would that just be a potential side-effect?
341 01:12 <vorlon> but yes, sparc has pretty much been bit-rotting since BenC went idle
342 01:12 <neuro> wookey: if that's what's needed by the release team
343 01:12 <fjp> vorlon: Silo is practically unmaintained; kernel upstream is one person who's interest is currently very intermittent
344 01:13 <fjp> vorlon: I do.
345 01:13 <kyle> s/very intermittent/limited to boxes he cares about/
346 01:13 <aj> wookey: my understanding is that it's to make release management do-able by reducing the complexity -- which either means all arches being better maintained than in sarge, or dropping a number of arches. vorlon?
347 01:13 <vorlon> yes, that's essentially it
348 01:13 <aj> any quantification of either branch?
349 01:14 <fjp> Note I have a sparc myself that runs nicely, but not having anyone to talk to or fixing stuff that keeps creeping up in installation reports is frustrating.
350 01:14 <wookey> OK. And we are moving the less-popular ports to their own archive-servers?
351 01:14 <vorlon> the idea of dropping the arch count for its own sake gets no traction, so I'm not pushing that
352 01:14 <jvw> if an arch 'just works', and issues are resolved quickly, it doesn't add that much to complexity... it's the number of near-bitrotting archs that matter
353 01:14 <aj> wookey: no, just not releasing them
354 01:15 <wookey> no - I mean ones that still qualify, but are much-less-downloaded
355 01:15 <vorlon> as for "better maintained", the quantification is http://release.debian.org/etch_arch_criteria.html
356 01:15 <aj> so the simplest stat we have is the buildd/testing stuff, which makes hppa, sparc, arm and m68k the worst atm
357 01:15 <vorlon> fjp: so the kernel upstream in question is DaveM?
358 01:15 <fjp> Yep
359 01:15 <jvw> wookey: mirroring stuff is distinct and not really ontopic here, basicly: yes, it'll happen eventually
360 01:16 <willy> aj: hppa's recovering from a gcc issue atm, aiui
361 01:16 <wookey> but doesn;t that just show that arm/m68k are slowest?
362 01:16 <aj> willy: how long ago was the issue, and how long did it last?
363 01:16 <wookey> jvw: OK, I was fishing for a guess as when 'eventually' might be :-)
364 01:16 <Sledge> jvw: I'm interested too
365 01:16 <jvw> wookey: when it's ready... :)
366 01:17 <joeyh> willy: even if you choose to read the graph that way, being 4th or 5th out of 12 arches doesn't equate to "most popular" to me
367 01:17 <aj> wookey: if so, they need more buildds
368 01:17 <wookey> fair enough
369 01:17 <willy> aj: I haven't been paying much attention, but it afflicted shared libs and propagated.
370 01:17 <jvw> (sorry, that was smart-assish, but nevertheless the best answer I can give)
371 01:17 <wookey> aj: OK, but I was getting the strong impression that more buildds was discouraged (especially by elmo)
372 01:17 <elmo> wookey: err, say what?
373 01:17 <aj> wookey: sure, it is; but having unbuilt stuff is worse, particularly for the RM team
374 01:18 <elmo> I've bought up like, 8 arm buildds in the last couple of years
375 01:18 * fjp is amazed at the last lines flashing by
376 01:18 <fjp> buildd shall be 2+1 was one of the hardest criteria from Vancouver...
377 01:18 <vorlon> fjp: and he's only intermittently involved? hrm, he was one of the people I heard complaining about the prospect of Debian dropping sparc...
378 01:19 <aj> "Autobuilder support: The architecture is able to keep up with unstable with not more than two buildds,"
379 01:19 <kyle> aj, hppa: gcc broke glibc, which broke $lots.
380 01:19 <aj> is from the current criteria
381 01:19 <wookey> elmo: OK, sorry if I've got that wrong - I thought buildds had been offered but you didn;t want more (becuase you had to look after them)
382 01:19 <ths> vorlon: AFAIR davem only cares about sparc64 today (kernel-wise).
383 01:19 <aj> kyle: when, though? how long ago was it fixed, how long did it take to fix?
384 01:19 <kyle> aj, looking at we speak
385 01:19 <wookey> Are we running on just 2 boxes at the moment?
386 01:19 <Sledge> ths: yup, that's what I've seen too
387 01:20 <fjp> vorlon: Sure. He would be. Debian is the best (only?) distro for Sparc linux...
388 01:20 <kyle> aj, it's hard because discussion spans so two lists and irc.
389 01:20 <elmo> wookey: umm, no - arm buildds disappeared into a black hole due to local admin crapness, not me
390 01:20 <aj> kyle: sure, best guess is fine
391 01:20 <Sledge> wookey: at least 3 arm machines now that I'm aware of
392 01:20 <elmo> 4 arms atm
393 01:20 <elmo> toffee, grieg, netwinder and smackdown
394 01:20 <Sledge> elmo: where's the other???
395 01:20 <Sledge> ah, smackdown yes
396 01:20 <kyle> aj, Date: Sat, 6 Aug 2005 09:44:03 -0400
397 01:20 <elmo> Sledge: bdale's and pb's
398 01:20 <aj> elmo: wow, four arms? that's like deformed!
399 01:21 <kyle> aj, is the first report of "fakeroot segfaults" on hppa.
400 01:21 * elmo beats aj with all 4 arms
401 01:21 * Sledge tickles aj
402 01:21 <vorlon> ths: well, I only care about sparc64 too, in spite of the fact that my only box is a sparc32, because I can't *do* anything with my SS5.
403 01:21 <Sledge> elmo: don't forget cats (even if it shows up as toffee!)
404 01:21 <aj> kyle: two months is a /long/ time
405 01:22 <Sledge> vorlon: yeah, sparc32 is just _too_ old for most people
406 01:22 <elmo> oh, err, right, so 5 arms
407 01:22 <joeyh> on the s390 qual page, re d-i.. d-i is still not able to use partman for s390, I'm not sure how long we'll want to keep around the old partitioner
408 01:22 <kyle> aj, hmm, i think there were two seperate problems, hold on.
409 01:22 <wookey> elmo: OK, but we need more because we still struggling to keep up on the lists? Or do we need more admins?
410 01:22 <vorlon> fjp: well, then he can become a DD and sign up to help the port? ;)
411 01:22 -!- azummo [~azummo@213-140-6-127.ip.fastwebnet.it] has left #debian-tech []
412 01:22 <aj> so, is anyone doing pages for arm, ppc, i386 yet?
413 01:22 <waldi> joeyh: etch needs a complete new hardware configuration which is beeing worked on
414 01:22 <vorlon> Sledge: it's not even the age, it's just how many core packages have to build sparc64 variants
415 01:23 <wookey> aj: I'm trying but I'm failing to drive this wiki
416 01:23 <fjp> joeyh: partitioner's also used for some m68k subarchs
417 01:23 <elmo> wookey: we don't need more admins, we need someone to investigate arm specific failures
418 01:23 <elmo> wookey: like perl vorlon mentioned earlier
419 01:23 <vorlon> Sledge: can't build a kernel on sparc32, or d-i, or glibc, ...
420 01:23 <wookey> elmo: OK
421 01:23 <ths> joeyh: That's also still a problem for ARCS mips.
422 01:23 <elmo> wookey: that requires arm knowledge, and I've never had or claimed to have that
423 01:23 <Sledge> vorlon: yeah, that too
424 01:23 <joeyh> fjp: yeah, and it adds more than it's fair share of load to keep maintained
425 01:23 -!- kyllikki [~vince@pike.pepperfish.net] has joined #debian-tech
426 01:23 <waldi> joeyh: partman is simply too slow
427 01:23 <Sledge> hey kyllikki
428 01:24 <aj> vorlon: (do you want these under wiki.d.o/release.debian.org/qualification/i386 or is as they are fine?)
429 01:24 <joeyh> it's an S390, for crying out loud
430 01:24 * kyllikki apologises for his tardyness
431 01:24 <joeyh> of do you mean m68k? :-)
432 01:24 <lennert> hello kyllikki
433 01:24 <fjp> joeyh: Please consider my poor Hercules ;-)
434 01:24 <joeyh> oh good, more arm people
435 01:24 <wookey> :-))
436 01:24 <vorlon> wookey: single biggest problem affecting arm right now is C++ ICEs with swaths of KDE stuff; this bug also affects hppa and m68k, you'd think *someone* would step up and fix it already
437 01:24 <wookey> see we're keen really, even if we are a bit crap
438 01:24 <aj> what's arm's excuse for having so many oods?
439 01:25 <kyllikki> aj: oods?
440 01:25 <aj> "out of dates"
441 01:25 <aj> vorlon just answered though :)
442 01:25 <elmo> aj: dpkg randomly starts to segfault on buildds
443 01:25 <kyllikki> aj: ask elmo to upload more ofted?
444 01:25 <waldi> joeyh: i meant m68k; but hercules is also slow
445 01:25 <joeyh> "HP sells [WWW] new systems at insane price" bwahahaha
446 01:25 <fjp> Too many buildds fighting over same packages probably
447 01:25 <vorlon> aj: are you asking what url to use for i386? makes no difference to me
448 01:25 <kyle> joeyh, url?
449 01:25 <joeyh> alpha qual page
450 01:25 <kyllikki> elmo: thought we fixed that?
451 01:25 <elmo> kyllikki: err, no?
452 01:26 <elmo> it's happened 5 times now, the "fix" each time has been to reboot the box in question
453 01:26 <Sledge> yeah, that's a worrying development
454 01:26 <elmo> that doesn't actually fix the underlying problem
455 01:26 <waldi> aj: better start wirt Ports/Qualification/$arch
456 01:26 <kyllikki> elmo: having a huge pile of packages listed as building against machines that dont exist any more can't be helping either?
457 01:26 <elmo> or stop the resulting buildd pile up car crash
458 01:26 <Sledge> and it's not just in the chroots - the base system is seeing it too
459 01:26 <elmo> kyllikki: eh, like what?
460 01:27 <kyllikki> Sledge: the segfault comes from the dynamic linker, its untracable through the ld.so
461 01:27 <wookey> vorlon: where should people be looking for arch-specific hold-ups? Do they always make it to the debian-arch list or are we expected to be monitoring something else?
462 01:27 <kyllikki> elmo: well the building list still refers to smackdown?
463 01:27 <vorlon> kyllikki: smackdown still exists
464 01:27 <vorlon> unless this is a recent development
465 01:28 <kyllikki> vorlon: smackdown is phils machine? thought he dismantled it?
466 01:28 <vorlon> wookey: try http://buildd.debian.org/status/architecture.php?a=arm
467 01:28 <vorlon> kyllikki: again, not unless this happened recently
468 01:28 <elmo> james@smackdown:~$ date
469 01:28 <elmo> Sun Oct 9 02:28:19 BST 2005
470 01:28 <wookey> kyllikki: pb said he had a running build week before last
471 01:28 <kyllikki> evidently not
472 01:28 <elmo> kyllikki: smackdown is alive and well and hasn't not been AFAIK
473 01:28 <vorlon> wookey: 163 packages in state "Maybe-Failed"
474 01:29 <waldi> elmo: british (standard|summer) time?
475 01:29 <elmo> waldi: yes
476 01:29 <elmo> (summer)
477 01:29 <kyllikki> elmo: it wasnt available during the complete faliure of all the other machines tho which is why I thought it went away
478 01:29 <joeyh> wow, never saw those pages before
479 01:30 <wookey> vorlon: that's a really useful URL - how long have I not known about it?
480 01:30 <vorlon> wookey: only about 6 months I think
481 01:30 <jvw> so it's tofee [sic] (== toffee + that other one) that's having 250'ish in 'Building' without build log
482 01:31 <elmo> yes, arm is due a give back
483 01:31 <elmo> however, there is PLENTY for arm knowledgable people to be fixing
484 01:31 <elmo> and no one really has been since pb became less active
485 01:31 <aj> wookey: so, you have to create the page before doing a [wiki:... ..] link to it evidently
486 01:31 <wookey> OK - that's not too bad, but the fact that I don't is a good example of the sort of internal communication inefficiencies we suffer from
487 01:32 <wookey> aj: indeed - the opposite way round to other wikis I have used
488 01:32 <wookey> elmo: indeed - we've been depending of guru-phil for some time
489 01:33 <lennert> lots of issues are shared between arm and armeb
490 01:33 <wookey> I didn't know he'd slowed down, of course
491 01:33 <vorlon> wookey: well, there have been other ways to get at Maybe-Failed lists forever; jvw's page just happens to be the easiest to use
492 01:33 <neuro> much like mips and mipsel
493 01:33 <lennert> we (armeb people) think we can lend a helping hand there
494 01:33 <wookey> vorlon: I'm sure
495 01:33 <wookey> yeah, I think the armeb new blood will help a lot
496 01:34 -!- Keybuk [~scott@62.49.129.42] has joined #debian-tech
497 01:37 <kyllikki> elmo: a lot of that is because the ARM open acess machine doesnt exist tho..I do make the other ARM boxen available for develoeprs on an ad hoc basis but a real machine would be nice
498 01:38 <Sledge> we have a standing offer for hosting a machine at BCN - we just need to get it there...
499 01:38 <elmo> get what there?
500 01:38 <elmo> debussy?
501 01:38 <Sledge> a machine
502 01:38 <Sledge> I dunno which
503 01:38 <wookey> I can put up a machine for developers - we have a spare IP for the purpose
504 01:38 <vorlon> well, if debussy was up, I would surely have already taken a crack at the perl failure already; but a) debussy's not up, and b) why should it be me? :P
505 01:38 <neuro> do we have enough contact with blindman via alfie to get debussy there?
506 01:39 <vorlon> to get it where?
507 01:39 <neuro> BCN
508 01:39 <wookey> black cat networks
509 01:39 <vorlon> last I heard was that BlindMan was in Canada
510 01:39 <neuro> where local admins can be more responsive
511 01:39 <elmo> yes, the open access machine should happen, but it's also orthogonal to the fact that arm has very few / none active porters working on it, beyond keeping the kernel and d-i going
512 01:40 <Sledge> elmo: yup
513 01:40 <joeyh> fwiw, one other thing I want to do at work is bring in at least one and possibly 2 of our developers as DDs
514 01:40 <neuro> and while developers that know nothing about the arch can give it a try...that doesn't make for quick resolution of problems
515 01:40 <joeyh> (for arm)
516 01:40 <kyllikki> elmo: indeed, but theres only one of me and Im not doin *everything* ;-)
517 01:40 <wookey> elmo: OK, but now we know that I expect it can be resolved
518 01:41 <lennert> joeyh: the armeb people have two people in the DD queue
519 01:41 <wookey> I know I've been assuming pb was on top of things
520 01:41 <elmo> kyllikki: sure - I recognised you with the kernel/d-i disclaimer :)
521 01:41 <lennert> joeyh: currently waiting for AM
522 01:41 * kyllikki notes provision of hardware for debussy isnt an issue if the old machine isnt viable
523 01:42 <kyllikki> elmo: tho had I know that the porting stuff had gotten oyut of hand I would have done a bit
524 01:42 <neuro> kyllikki: so, get it to BCN, and we've got that one solved, then?
525 01:42 <wookey> I'm pretty sure there enough people who care about arm - they just need telling what to do, and how
526 01:42 <neuro> fwiw, I don't think there's anyone actively looking at powerpc-specific failures, either
527 01:42 <kyllikki> vorlon: hmm that perl faliure is weired
528 01:42 <jvw> so how about we try to get the chart a bit filled in...
529 01:42 <kyllikki> neuro: heh as long as it doesnt wait on admin as long as tofee did
530 01:43 <vorlon> kyllikki: yeah. I've already had one person suggest it was a transient issue.
531 01:43 <wookey> kyllikki: we normally give wired arm perl probslem to nick
532 01:43 <jvw> this discussion is now going into quite specific details of mainly arm...
533 01:43 <Sledge> jvw: yeah
534 01:43 <wookey> sorry
535 01:43 <neuro> jvw: discussion can only go in the direction for which people are here to talk about
536 01:43 <Sledge> any other arch people want to chime in?
537 01:43 <wookey> but it seems we have problems that need adressing
538 01:43 <jvw> rather than getting an idea of which archs are probably qualifyeable and which are not
539 01:43 <wookey> and the people with the answers are here :-)
540 01:43 <fjp> vorlon: Just remember for sparc that blars does a fair amount of work. especially re build failures
541 01:43 <kyllikki> ARM == we have issues but hey, we can fix em
542 01:44 <vorlon> jvw: I guess arm is the only one that'll qualify, because no one else cares to speak up ;)
543 01:44 * kyllikki was only late because I thought this meeting was tomorrow :-/
544 01:44 <jvw> people can speak for other archs too
545 01:44 <jvw> a bit, at least
546 01:44 <jvw> some boxes are easy to fill in
547 01:44 <neuro> a second buildd for i386 is in the works
548 01:44 <vorlon> fjp: I'm actually a bit disappointed with the bugs Blars files about build failures, because they tend not to include much analysis
549 01:45 <neuro> it's just so idle it's not very high on my list
550 01:45 <wookey> vorlon: yeah. we may be disorganised, but we did turn up :=)
551 01:45 <kyllikki> and it is 03:00 local
552 01:45 <kyllikki> nearly
553 01:45 #dudes: * dato tries to catch up in #debian-tech
554 01:45 <fjp> vorlon: True. It's more notifying than analyzing.
555 01:45 -!- lennert [~buytenh@alephnull.demon.nl] has joined #debian-tech
556 01:45 <neuro> mipsen is obviously having problems (no java compiler, none coming anytime soon)
557 01:46 <vorlon> fjp: so, bugs are filed, but the maintainers still have to figure out why it failed, which may require sparc-specific knowledge...
558 01:46 <ths> neuro: I hope the anytime soon won't stay true for long.
559 01:46 <jvw> So, *availability*: ttbmok, i386, ia64, powerpc are obviously green, the rest?
560 01:46 <neuro> ths: Are you finding time for it? Or is someone else working on it?
561 01:47 <neuro> powerpc has a problem like arm. someone knows there are machines somewhere
562 01:47 <waldi> jvw: which sort of availability?
563 01:47 <ths> neuro: It's the next on my list after 2.6 kernels.
564 01:47 <fjp> jvw: i386 and powerpc are both lacking a backup buildd, so red (well, maybe orange)
565 01:47 <jvw> I'm talking availability -> to buy new etc
566 01:47 <aj> http://wiki.debian.org/EtchReleaseRecertificationTemplate
567 01:47 <joeyh> jvw: alpha is apparently still available, according to its qual page. ia64 is for sale.
568 01:47 <aj> ^-- blank certification template fwiw
569 01:48 <neuro> i just said i386 is being dealt with, and with how idle it is, it's really a big deal.
570 01:48 <aj> vorlon: do you want to check that's okay?
571 01:48 <aj> neuro: not a big deal, ym?
572 01:48 <jvw> https://release.debian.org/etch/arch_qualify.html
573 01:48 <neuro> errr, right
574 01:48 <joeyh> jvw: arm can be bought new.
575 01:48 <ths> jvw: mips/mipsel is available.
576 01:48 <fjp> neuro: Just replying to the "obviously"
577 01:48 <waldi> jvw: s390 and powerpc are available
578 01:48 <willy> jvw: alpha, arm, hppa, s390 are definitely available
579 01:49 <willy> sparc is purchasable too
580 01:49 <jvw> anyone wanting to contest any of those claims?
581 01:49 <waldi> but ia64 is mostly dead
582 01:49 <aj> rather than contest them, can we just have certification pages with links that prove them?
583 01:49 <willy> waldi: oh, hush
584 01:49 <vorlon> aj: looks good to me
585 01:49 <elmo> waldi: dude, please
586 01:50 <wookey> I'm working on the arm cert page now
587 01:50 <elmo> s390 folks calling ia64 dead - jesus, the irony
588 01:50 <joeyh> and when you finish, I suppose I can go on-clock to add links to where to buy :-P
589 01:50 <fjp> elmo: Hey, I work in cobol/idms environment for a living (on s/390 :-)
590 01:50 <weasel> elmo: soon there'll be an s390 in every home :)
591 01:50 <jvw> I'm trying to get a quick overview now, to identify issues
592 01:50 <ths> waldi: SGI Altix is available. :-)
593 01:50 <aj> so has anyone started on i386, ppc or amd64?
594 01:50 <joeyh> and a chicken in the pot on every s390
595 01:51 <joeyh> I did i386
596 01:51 <joeyh> well, mostly
597 01:51 <joeyh> I don't know about developer machines
598 01:51 <willy> aj: do you want the hppa or ia64 ones redone to fit the template?
599 01:51 <aj> willy: ask vorlon :)
600 01:51 * willy twinkles at vorlon
601 01:51 * kyllikki tries to sell everyone nice shiny new ARM machines
602 01:51 <vorlon> weasel: I hear they sell systems that combine s/390s with furnaces and air conditioners now
603 01:52 <waldi> vorlon: a s390 always contains air condition
604 01:52 <vorlon> willy: would be helpful to have them all with the same layout, yes please
605 01:52 <joeyh> and here I spent all day fixing my wood stove's pipe, and I could have been airlifint a s390 in
606 01:52 <vorlon> waldi: but do they air condition your house? :)
607 01:52 <joeyh> airlifting
608 01:52 <jvw> is sparc really available new?
609 01:52 <waldi> vorlon: no
610 01:52 <willy> vorlon: ok. i;ll do hppa now.
611 01:52 <willy> jvw: yes
612 01:52 <vorlon> willy: thanks
613 01:53 * jvw got offered two of them at least in the past month, but they were not new...
614 01:53 <vorlon> sparc is never cheap new
615 01:53 <Q_> Should I already put some time in amd64 getting qualified?
616 01:53 * joeyh goes to redo i386 with aj's template
617 01:53 <aj> vorlon: "Archive coverage and Autobuilder support" is kinda blank, i'm not sure what should go in there to demonstrate that the arch can keep up with testing
618 01:53 <jvw> so, hppa/m68k seem to be the only ones failing so far
619 01:54 <aj> err, "keep up with unstable, satisfactorily for testing's purposes"
620 01:54 <vorlon> aj: other than the 98% mark?
621 01:54 <fjp> jvw: sparc new: yes (but not well supported by kernel)
622 01:54 <vorlon> jvw: dannf assured me that even hppa boxes can be purchased new
623 01:54 <aj> vorlon: everything except i386 fails the 98% mark now doesn't it?
624 01:54 <vorlon> aj: today, yes
625 01:54 <fjp> "refurbished" pobably
626 01:55 <waldi> aj: if you count the not-for-us as failed, yes
627 01:55 <elmo> not-for-us shouldn't be used
628 01:55 <aj> waldi: 98% == of packages built in unstable, 98% have the current version built
629 01:55 <vorlon> elmo: meaning P-a-s should be used instead?
630 01:55 <elmo> yes
631 01:55 <vorlon> agreed
632 01:56 <aj> http://buildd.debian.org/stats/graph-week.png ?
633 01:56 <aj> that's what we want to use, isn't it?
634 01:56 <jvw> <tr><td>buildds: N<=2</td>. /me beats the release team over with a HTML spec
635 01:57 <kyllikki> why is the n<=2 in tehre?
636 01:57 <jvw> <=2 :)
637 01:57 <kyllikki> surely we really want at least three for redundancys sake?
638 01:57 <vorlon> aj: doesn't account for P-a-s, which it really ought to, no?
639 01:57 <jvw> (needing to keep up)
640 01:57 <waldi> elmo: so, where can I add changes?
641 1:57 <vorlon> kyllikki: if you only need one, then two is plenty redundant
642 01:57 <aj> kyllikki: demonstration that the arch can build packages quickly enough for security support, and to reduce admin complexity which slows down updating the buildds for things like security support at release time
643 01:58 <aj> vorlon: it doesn't?
644 01:58 <vorlon> aj: not AFAIK
645 01:58 <elmo> vorlon: it does
646 01:58 * aj makes a face at vorlon
647 01:58 <vorlon> elmo: it does? Oh wow
648 01:58 <elmo> waldi: see the top of P-a-s; if you send a couple of obviously sane changes, I'll add you to the CVS group
649 01:58 <kyllikki> vorlon: hmm yes but ARM will probably need two for some time to come...when the main purpose of your CPU is to use less than 200mW not to be a performance CPU...
650 01:58 <vorlon> dude, why have I not asked for m68k to be ignored yet then? :P
651 01:58 <aj> because you're a wuss!
652 01:59 <willy> jvw: HP recently introduced the PA8900 boxes. Admittedly these are supposed to be the last boxes (unless they changed the roadmap since I last looked), but I expect you to be able to buy new PA machines for at least the next 5 years
653 01:59 <aj> sparc and arm could do with ignoring too, by the under 95% rule
654 02:00 <kyllikki> some of these rules seem a tad arbitrary
655 02:00 <Sledge> kyllikki: yes, they may be
656 02:00 <neuro> vorlon: erm, yes it does take P-a-s into consideration?
657 02:00 <vorlon> aj: I've been going by 92%, and using force hints for 92-95%; but m68k is apparently *way* worse than I thought
658 02:00 <aj> all the "fast enough" rules have to be a tad arbitrary
659 02:00 <aj> vorlon: so ignore m68k, rerun britney?
660 02:00 <Sledge> but precise numbers can be tweaked once we get an idea of what seems to work
661 02:00 <vorlon> aj: yah :)
662 02:01 <waldi> elmo: okay
663 02:01 <aj> vorlon: just ignore version sync, or ignore uninstallability too?
664 02:01 * kyllikki mutters that intel are bastards and refused to make good on their hw offer
665 02:01 <joeyh> yes please, do it now
666 02:01 <vorlon> aj: both
667 02:01 <Sledge> kyllikki: typical
668 02:02 <aj> vorlon: wanna make an m68k page, and just fill in the RM veto section? :)
669 02:02 <joeyh> lol
670 02:02 <elmo> kyllikki: did they? stockholm said he was going to put you in touch with them; did he?
671 02:02 <vorlon> ok, so, 0200 UTC... time for me to go find dinner. :)
672 02:02 <aj> vorlon: Both? are you sure? uninstallability increases are extreme
673 02:02 <lennert> it's 4AM here now, and i'd really love to go to sleep
674 02:02 <kyllikki> elmo: It all happened, when they discovered I wanted some real hw not a pissing little 200MHz PXA270 they didnt really want to know
675 02:03 <jvw> I got bored at making https://release.debian.org/etch/arch_qualify.html
676 02:03 <kyllikki> elmo: we wanted a 1.2GHz intel dev kit, but as their the thick end of 20k they said no
677 02:03 <elmo> kyllikki: oh, meh
678 02:04 * fjp likes seeing machine names in "Developer availability"
679 02:04 <jvw> fjp: actually, that's what is meant there
680 02:04 <jvw> machines available for DD's
681 02:04 <kyllikki> elmo: we could have a iop331 system at 400MHz which performs like what we already have...
682 02:04 <vorlon> aj: I'm sure that if we're marking m68k as down and out, I don't want to still be adding force hints to get RC bugfixes in for a subset of packages that are both out-of-date on m68k, and left uninstallable by the update
683 02:05 <vorlon> rather, force-hint hints
684 02:05 <fjp> jvw: Suggest retitle to "developers system"
685 02:05 <neuro> vorlon: doing the second one makes it very, very, very hard to get the arch back in.
686 02:05 <vorlon> neuro: well aj called me a wuss, so I'm overcompensating
687 02:05 <jvw> fjp: better?
688 02:05 <kyllikki> elmo: hmm a large number of the build fails seem to come from the lack of kafe...wonder why thats been building for so long
689 02:06 <fjp> jvw: :-)
690 02:06 <aj> vorlon: i'd encourage you to consider 90% = uninstallable+unsync, 95% = unsync as cutoffs then; allowing desyncing is fixed much more easily later, so it's nice to have a gradual cut in
691 02:06 <fjp> jvw: It's not really porter though as they probably have their own box. Maybe "Porting" though.
692 02:06 <kyllikki> I gotta get some shut eye, gnight
693 02:06 <vorlon> aj: that sounds reasonable. m68k is still below the lower line.
694 02:07 <aj> yup
695 02:07 <neuro> want me to move the lines on the graph?
696 02:07 * jvw whines at gluck being too slow for a useable vim session
697 02:07 <aj> (arm, and sparc are under the higher line)
698 02:07 <vorlon> neuro: yes please
699 02:08 <aj> http://buildd.debian.org/stats/graph2-week.png <-- a 90% or 95% cut off on that sounds plausible too
700 02:08 <fjp> aj: sparc is recovering from failure of both buildds; give it some time to catch back up
701 02:09 <kyllikki> wtf is going on with ARM, weve dropped like a brick
702 02:09 <vorlon> yeah, sparc has only briefly dipped below the line
703 02:10 <kyllikki> must sleep...that can wait
704 02:10 <willy> http://wiki.debian.org/hppaEtchReleaseRecertification rewritten now
705 02:10 <neuro> graph2 numbers tend to be higher, as they don't include uncompiled packages
706 02:10 <fjp> and sparc is above 95% currently in the graph
707 02:11 <vorlon> yeah, and I think graph2 is the wrong metric for judging releasability
708 02:11 <kyllikki> Sledge: I assume as cats is idle again that theres summat wrong with the buildd on there again?
709 02:11 <Sledge> kyllikki: hmmm
710 02:12 <neuro> I think it's the right one for making testing cutoff decisions, tho
711 02:13 <vorlon> hmm, possibly
712 02:13 <aj> erm
713 02:13 <neuro> because testing doesn't care about an arch being "uncompiled"
714 02:13 <vorlon> I'll think about that while I'm off dealing with dinner
715 02:13 <vorlon> later, folks. :)
716 02:13 <aj> oh, okay