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

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> &lt;=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