= 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 [[irc://irc.debian.org/debian-tech|#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]]. {{{#!irc 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 00:03 3 minutes too late *hide* 00:03 ;) 00:04 hmm, the ia64etchreleaserecertification page on the wiki isn't there 00:04 oh, wiki is case sensative, let's fix the link 00:04 so if people are here for the port requalification stuff, could you please say something so we have some idea of who's here? 00:05 joeyh: oh, it's not jvw trying to vancouver ia64? :) 00:05 good evening. 00:05 * vorlon waves to kyle 00:05 vorlon: ping 00:06 I'm here to represent arm 00:06 I'm in Vancouver. 00:06 * lennert is an observer on behalf of the unofficial armeb port 00:06 * jvw recovers the map of vancouver I still have laying around somewhere... 00:06 lennert: typically, observers don't speak ;-) [but never mind] 00:06 I'm here representing the nslu2-linux project (using the fledgling armeb port) and supporting arm. 00:07 * zack is impersoning joe random developer interested in the requalification stuff 00:07 aj: ping? 00:07 jvw: *muted sounds* 00:07 zack: anyway, request granted 00:07 What's the proceedure here - just get stuck in, or does our chairman want to try and control the agenda? 00:08 oddly enough I can also represent a company that does arm 00:08 wookey: I'm imagining something freeform; aj may have other ideas, but I haven't seen aj on IRC yet this morning 00:08 OK, can I start by saying I'm a bit concerned about this '2 buildds' rule 00:09 It's only just practical for us now, and I expect things only to get worse over time 00:09 I understand that more buildds means more overhead, but I don't really think it's a sensible _rule_ 00:10 If an arch can lok after its buildds then it should bne allowed toi use as many as is necessary, surely? 00:10 no, not surely 00:10 wookey: it already took us a long time after the release of etch to update chroots on the buildds we have now. 00:10 aha elmo - hi 00:11 hasn't that already been discussed to death on the lists? 00:11 maybe it has, in which case I'll shut up 00:11 yeah, it's been discussed quite a bit 00:12 But what if the two fastest arm boxes in the world can't keep up? 00:12 arm isn't that slow 00:12 then you have to accept that keeping arm as a release architecture would cause unavoidable issues for the release team, security team, etc 00:12 s/you have/you'd have 00:12 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 00:13 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... 00:14 it starts to add additional days to each layer of the transition 00:15 but isn't that also true if the packages take ages to build due to insufficient resources? 00:15 so if the two fastest arms in the world can't keep up, you can try to boost performance with distcc or the like. 00:16 Didn't the m68k people going to try distcc? Didn't hear anything about it. 00:16 we (armeb) tried distcc to x86 boxes 00:16 * joeyh wonders what the fastest arms are anyway. Best I have are 400mhz xscales 00:16 OK, well, we'll see how it goes. I think the armeb guys are trying distcc 00:16 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... 00:16 it mostly works, but it's a pain to deal with different gcc versions that are being constantly updated 00:17 and cross-compiling generates different code for float ops 00:17 jvw - that would then make the '95% built rule a problem... 00:17 lennert: why does it generate different code? 00:17 joeyh: ixp2350 runs at 900mhz-ish, which is the fastest arm i know of 00:17 jvw: that runs into the problem of, why are we calling it "the debian system" if large chunks of it aren't there? 00:17 wookey: well, not if the 95% rule was explicitly scaled to accept a specific subclass of the system; but see neuro's remarks. 00:17 waldi: it seemed to generate explicit code for floating point ops with constants instead of doing them on the host 00:18 neuro: yeah... fair enough. So not an option 00:18 and begs the question, what exactly are we targeting anyways? 00:18 lennert: ah 00:18 joeyh: (ixp23xx has nice 512k l2 cache too) 00:18 anyway - I don;t want to repeat arguments unecessarily 00:18 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 00:19 and can only catch up more slowly than faster archs would 00:19 wookey: are you seeing a case for stable arm releases? Because at work, we're not, using unstable or testing is ok 00:19 and strangely, even though I didn't mean to, I think I just described what happened on m68k this summer 00:19 It's not completely fatal at the moment 00:19 joeyh: I use stable on my server here 00:20 but now there is testing-security it would be no prob to change 00:20 joeyh: for armeb we're building both unstable and stable 00:20 if we're not having a stable release of an arch, there wouldn't be a testing one, tho? 00:20 I agree stable is probably the least-important 00:20 joeyh: unstable with an eye towards eventual assimilation by debian, stable for the userbase 00:20 because if there is, then we're waiting for it to be ready for a stable that we don't release 00:20 there might be a testing one that is dropped when it gets behindn and has to play catchup 00:20 which could potentially need some hand-holding from the porters for that arch 00:22 vorlon: the 'having to catch up after toolchain-trouble' scenario is one where more boxes are helpful, rather than a hindrance, is it not? 00:22 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 00:23 anyway, perhaps there are other issues people want to cover? 00:23 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" 00:23 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 00:23 -!- faw [~felipe@201.24.232.152] has joined #debian-tech 00:24 jvw: no, that's the point I am concerned about, I don;t think I'm missing it? perhaps I misunderstand you? 00:24 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... 00:24 testing loses it's point on a given arch if you are always setting a given arch to "who cares" 00:24 m68k needs, what, 12 buildd's for normal usage, but they don't have 24 of them in order to catch up when needed 00:24 vorlon: exactly 00:24 btw, since we've got so many arm people present, who wants to tell me what the deal is with the perl arm failure? 00:24 (not necessarily during this session, though :) 00:25 "12" vs. "34"? 00:25 vorlon: the arm perl guru isn;t here (nick) 00:25 Fails test suite: 00:25 > t/op/pack.................................# Failed at op/pack.t line 441 00:25 > # got '34' 00:25 > # expected '12' 00:25 that one? 00:26 didn't look at that yet i must admit 00:26 we (armeb) only got around to building that package ~3 days ago 00:26 so you don't even have build-essential built yet? 00:27 not for unstable, no 00:27 -!- fjp [~fjp@195-240-184-66-mx.xdsl.tiscali.nl] has joined #debian-tech 00:27 that's why i 00:27 'm 'observing' 00:27 noisily :-) 00:27 armeb has no chance of being in etch 00:27 wookey: yeah, sorry :) 00:27 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 00:27 it's quantum. 00:28 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... 00:29 fwiw, I've been trying to line one up 00:29 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) 00:29 just waiting to hear back from elmo on if what we can offer is good enough 00:29 joeyh: ok, cool 00:30 wookey: nah, this once again comes back to "buildd parallelization doesn't solve all problems" 00:30 vorlon: point taken. 00:30 distcc would solve more, if it's viable. The m68k folks seemed to have doubts that it would improve things for them 00:31 vorlon: just to have that clear; distcc to x86 boxes or to same-arch boxes? 00:31 distcc also suddenly requires all makefiles to be written to support make -j... 00:31 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. 00:31 OK, so the main problem is the build time of major packages 00:31 we did a make wrapper to force -j N (for some value of N) and that broke badly 00:31 not if you distcc to one amd64 ;-) 00:31 lennert: whatever meets the needs of the port? I think m68k frontend+big x86/amd64 backend was discussed 00:31 yeah, ok, except that it doesn't generate the same code 00:32 joeyh: exactly. 00:32 not sure if that's a problem, but it doesn't seem like a desirable property to me 00:32 lennert: well, then it's not a viable option for you, because you have a broken cross-compiler. :) 00:32 OK, that's helped me understand the rule. 00:32 vorlon: i don't gcc cross generates identical code in any case 00:32 vorlon: s/gcc/think gcc/ 00:32 vorlon: a cross-compiler cannot evaluate things like 12345*0.1 00:33 lennert: it should. When it doesn't, that's a bug. 00:33 hmmm 00:33 vorlon: it will generate functionally identical code but not identical code 00:33 vorlon: no, this is just an compiletime optimization 00:33 (yeah, nasty floating point, blah... ok, hook your cross-compiler gcc to a copy of qemu ;) 00:33 _could_ we work on the bigger packages to make them more friendly for make -j? 00:33 hello sledge 00:33 hey wookey 00:34 vorlon: ok, if that's not a problem, all the better for us 00:34 Sledge: This would be generally desireable. 00:34 better is to break such huge packages up into component pieces. 00:34 yeah, that too 00:34 neuro: like X, yes 00:34 ok, let me clarify then: a cross-compiler that doesn't generate functionally identical code is buggy 00:34 vorlon: no 00:34 s/no/yes/ 00:34 hah! 00:34 vorlon: functionally identical shouldn't be a problem 00:34 * vorlon quotefiles that regex 00:34 * Sledge pokes waldi :-) 00:35 vorlon: bah ;) 00:35 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... 00:36 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.. ;-) 00:36 which 3? :) 00:36 joeyh: well, we only have hppa, s390, and arm represented here, I think :) 00:36 no alpha people? 00:36 no that was half an hour on 'why 2 buildds' :-) 00:36 vorlon: powerpc, maybe 00:36 mips 00:36 (sorry) 00:36 ah, ok. :) 00:36 and amd64. :) 00:36 and mips counts as two archs! 00:36 fwiw, 2 buildds shouldn't be a problem for hppa. 00:36 Ganneff: you didn't speak up at the beginning, so you don't count. ;) 00:36 yay for mips counting as 2 arches 00:37 :-P 00:37 vorlon: im not an amd64 porter. :) 00:37 and arm heading the same way 00:37 joeyh: hmm, periodic reboot with flaping endianess-selection? ;) 00:37 tbm does it 00:37 * Sledge tsks at people who can't make their mind up on which way to swing 00:37 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 00:37 amd64 isn't in unstable yet, so who cares? 00:38 Q_: you should 00:38 Q_ just think, you only have to knck out one of these arches to get amd64 in 00:38 vorlon: it speaks about "developers", which sort of developers? 00:38 waldi: Debian developers 00:38 the last version of the 'ports' doc is the one wouter published after debconf - right? 00:38 waldi: people who can actually pick up the slack and do porter uploads of packages when things need fixing 00:39 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 00:39 neuro: where is the repository for binutils? 00:40 I suppose I kind of wonder what '5 developers' means? 00:40 waldi: well, that's something that may be needed as well. 00:40 -!- Zomb [~eb@x118.rhrk.uni-kl.de] has joined #debian-tech 00:40 neuro: maybe just push merge it with gcc 00:40 And kernel. 00:40 kernel is no problem 00:40 we have 5 developers who take an interest, but somewhat randomly. 00:41 >5, but obviously some are keener than others 00:41 wookey: people who are willing to do the work to fix the port when it breaks 00:41 OK. 00:42 but people have different expertises. We probably only have two who can do really hard-core toolchain things 00:42 I don't actually see the 5 developer criterion on http://release.debian.org/etch_arch_criteria.html 00:42 joeyh: The 3rd. 00:42 joeyh: appears to be lumped in with "Users" 00:42 ah ok 00:43 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 00:43 the installer things is almost irrelevant for arm. 00:43 A lot of people use debain-arm one way or another. Hardly any of them use debian-installer to do it 00:43 only one of my arm boards has directly attached storage 00:44 all my arm boards except one can run d-i just fine with usb storage 00:44 so 90% of our users couldn't care less whether there is instaler support or not 00:44 (no offence joey :-) 00:44 well, that's again "what is the Debian system?" 00:45 for many arm people it's 'a useful base' 00:45 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. 00:45 if we want to drop d-i for mostly embedded arches like arm, that's one solution to that problem 00:46 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 00:46 joey - I certainly think it should be optional 00:46 and if that helps the d-i team, then that's good. 00:47 joeyh: does *not* having d-i for arm hurt some subset of our userbase? 00:47 There are some machines (like cats and netwinder) where people actually use the installer, but only once about 5 years ago in most cases 00:47 although I think you're underestimating the usage of d-i on semi-enmbeeded arches. Not everyone is cablable of deboostrapping debian from scratch 00:47 could the job of d-i be done by some of the configure-from-live-CD stuff that Ubuntu is working on? 00:47 vorlon: yes, of course 00:47 yes to which? 00:47 Joey: I may be, yes - it's hard to know the proportiond 00:47 yes it hurs some users 00:48 * kyle uses d-i on arm. 00:48 as a data point. :) 00:49 most of these things don't have CDs, and they boot in fairly diverse ways 00:49 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 00:49 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. 00:49 nslu2-linux is trying to get debian-installer to work on Linksys NSLU2 (armeb) via netconsole 00:49 I suppose at the moment there are enough conventional arm machines that there should be at least one machines supported by d-i 00:50 :) 00:50 vorlon: yes, I think you are right 00:50 rwhitby: fwiw, I think it's important that we focus right now on those ports that are candidates for etch. :) 00:50 vorlon: nod 00:50 but it might not remain true - we might end up with no machines that normally use d-i 00:51 but we can worry about that in due course 00:51 hmm, can we do the other part of program and try to fill the criteria table? 00:51 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"... 00:51 wookey: I think that's unlikely, fwiw. 00:51 based on priveliged info from one company 00:51 joeyh: you are propbably right 00:51 :-) 00:52 waldi: absolutely. I think we can do both at the same time, no? 00:52 wookey: I think the general growth of embedded systems will make d-i more attractive. 00:52 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? 00:52 ths: could be - I couldn;t work out ow to make it work on machines I'm responsible for :-( 00:52 I seem to be too dumb 00:52 well I can probably boil it down to someting non-priveliged 00:52 there's been some "yeah, there's a company whose name i can't say in public that uses for of users for purpose" too 00:52 so i did it a different way 00:53 in this case anyway trimmings like displays, touchscreens, usb disks, and a flashy debian load. This configurtation can run d-i nicely. there. 00:54 joeyh: you working for ADS now? 00:54 yep 00:54 waldi: so I assume you wanted to look at s/390 specifically. I see from the wiki that the port is short on developers... 00:54 cool - sound people 00:55 analog devices? 00:55 vorlon: and powerpc 00:55 waldi: ok, no wiki page for that one yet 00:55 hrm, so there's not an arm wiki page yet? 00:55 vorlon: yes, there is none 00:55 kyle: nope, but I forget what it stands for 00:55 ah. 00:55 ah, right, analog is "ADI" 00:55 aj: nope - I should just create one, I assume? 00:55 wookey: sure 00:55 fwiw, the biggest concern with powerpc qualifying for etch is probably going to be people assuming that someone else is taking care of it 00:56 ditto i386 00:56 heh 00:56 neither arch has buildd redundancy today, and they ought to :) 00:56 hey, any sparc people here? 00:57 doesn't look like it 00:57 vorlon: debian have two openpower machines, but noone wants to use them 00:57 give me root, I'll find a use ;) 00:58 why am I not suprised? 00:58 waldi: list them as available and currently unused on the wiki page 00:58 aj: which one? 00:58 the one you're about to create for powerpc :-) 00:58 I certainly don't see anything sent to debian-admin about it this year. 00:58 waldi: the powerpc? qualification page 00:59 neuro: tbm managed that in january 00:59 waldi: (also, list their current admin / connectivity status) 00:59 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? :) 01:00 vorlon: thay copied the original text? 01:00 vorlon: i don't think anyone really groks the "upstream" expectations well 01:01 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? 01:01 maybe we should set goals, either (a) dropping _x_ ports or (b) making all ports imprive to _y_ level? 01:01 waldi: I see nothing with a subject that would indicate "new machines" 01:02 neuro: hmm, joey knows about them 01:02 joey != debian-admin 01:02 aj: No a) is what was wrong with the original Vancouver proposel. 01:02 there's a list for a reason. If you tell one person, well.... 01:03 fjp: if (b) doesn't happen, (a) is required for us to release *shrug* 01:03 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 01:03 *giggle* 01:03 vorlon: that sounds about right 01:04 * jvw tickles elmo 01:04 joeyh, i dunno who added that. 01:04 elmo: ok. any chance you could quantify some of those, so that porting teams could proactively filter offers for you guys? 01:04 hrm, britney's OOMing or something? 01:05 I added that 01:05 aj: it is? it seems to have completed a run today 01:05 maybe it's not mailing what i expect anymore then 01:05 It's true -- hppa is massively above everything except i386, ppc and sparc 01:06 oh, and it was level with alpha 01:06 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 01:06 i dunno what to say, hppa accounts for 100% of traffic on my mirror (which runs on a hppa...) 01:06 elmo: hmm, alright. 01:06 willy: "more popular" and 0.75% don't really mix terribly well 01:06 the page that it links to does not seem to show any of that 01:06 http://dirk.eddelbuettel.com/blog/2005/03/08/#more_download_by_arch 01:06 in a copule of years, an ADSL line is going to be pretty impressive though 01:06 elmo: are you in the loop regarding Snow-Man's efforts to get a sparc hosted for Debian w/ his employer, btw? 01:06 vorlon: no? 01:06 aj: and packages will have even more bloat and be 100 times the size 01:07 the most popular listed arch on that graph is powerpc, at 2.5% 01:07 hmm, the s390 autobuilders are idle most of the day 01:07 do more uploades 01:07 weasel: we're only growing by ~30G/year for the entire archive, maybe ~5G per year by arch 01:07 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? 01:07 same with mips, i386, powerpc, alpha 01:08 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 01:08 no machine offers there lately 01:08 I don't know if he has. He's still in the process of getting it approved by management. 01:08 ok 01:09 Out of dates holding up testing: 01:09 OTOH sparc has a serious shortage in developers IMO 01:09 the poor adsl connections have been the cause of several days of delay in security and large package uploads, tho 01:09 125 hppa 01:09 214 sparc 01:09 284 arm 01:09 397 m68k 01:09 * joeyh cheers arm on :-P 01:09 3 i386 01:09 55 s390 01:09 ^ are the top two 01:09 sparc is still recovering from the kernel-deaths of vore/auric 01:10 #2-#6 are pretty much the same (55-89) 01:10 aj: hihi 01:10 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 01:11 fwiw, d-i is currently being blocked by: out of dates on arm, toolchain on ia64, general unhappiness on sparc 01:11 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. 01:11 Is the object of this excercise to actually drop some arches for etch? 01:12 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 01:12 or would that just be a potential side-effect? 01:12 but yes, sparc has pretty much been bit-rotting since BenC went idle 01:12 wookey: if that's what's needed by the release team 01:12 vorlon: Silo is practically unmaintained; kernel upstream is one person who's interest is currently very intermittent 01:13 vorlon: I do. 01:13 s/very intermittent/limited to boxes he cares about/ 01:13 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? 01:13 yes, that's essentially it 01:13 any quantification of either branch? 01:14 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. 01:14 OK. And we are moving the less-popular ports to their own archive-servers? 01:14 the idea of dropping the arch count for its own sake gets no traction, so I'm not pushing that 01:14 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 01:14 wookey: no, just not releasing them 01:15 no - I mean ones that still qualify, but are much-less-downloaded 01:15 as for "better maintained", the quantification is http://release.debian.org/etch_arch_criteria.html 01:15 so the simplest stat we have is the buildd/testing stuff, which makes hppa, sparc, arm and m68k the worst atm 01:15 fjp: so the kernel upstream in question is DaveM? 01:15 Yep 01:15 wookey: mirroring stuff is distinct and not really ontopic here, basicly: yes, it'll happen eventually 01:16 aj: hppa's recovering from a gcc issue atm, aiui 01:16 but doesn;t that just show that arm/m68k are slowest? 01:16 willy: how long ago was the issue, and how long did it last? 01:16 jvw: OK, I was fishing for a guess as when 'eventually' might be :-) 01:16 jvw: I'm interested too 01:16 wookey: when it's ready... :) 01:17 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 01:17 wookey: if so, they need more buildds 01:17 fair enough 01:17 aj: I haven't been paying much attention, but it afflicted shared libs and propagated. 01:17 (sorry, that was smart-assish, but nevertheless the best answer I can give) 01:17 aj: OK, but I was getting the strong impression that more buildds was discouraged (especially by elmo) 01:17 wookey: err, say what? 01:17 wookey: sure, it is; but having unbuilt stuff is worse, particularly for the RM team 01:18 I've bought up like, 8 arm buildds in the last couple of years 01:18 * fjp is amazed at the last lines flashing by 01:18 buildd shall be 2+1 was one of the hardest criteria from Vancouver... 01:18 fjp: and he's only intermittently involved? hrm, he was one of the people I heard complaining about the prospect of Debian dropping sparc... 01:19 "Autobuilder support: The architecture is able to keep up with unstable with not more than two buildds," 01:19 aj, hppa: gcc broke glibc, which broke $lots. 01:19 is from the current criteria 01:19 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) 01:19 vorlon: AFAIR davem only cares about sparc64 today (kernel-wise). 01:19 kyle: when, though? how long ago was it fixed, how long did it take to fix? 01:19 aj, looking at we speak 01:19 Are we running on just 2 boxes at the moment? 01:19 ths: yup, that's what I've seen too 01:20 vorlon: Sure. He would be. Debian is the best (only?) distro for Sparc linux... 01:20 aj, it's hard because discussion spans so two lists and irc. 01:20 wookey: umm, no - arm buildds disappeared into a black hole due to local admin crapness, not me 01:20 kyle: sure, best guess is fine 01:20 wookey: at least 3 arm machines now that I'm aware of 01:20 4 arms atm 01:20 toffee, grieg, netwinder and smackdown 01:20 elmo: where's the other??? 01:20 ah, smackdown yes 01:20 aj, Date: Sat, 6 Aug 2005 09:44:03 -0400 01:20 Sledge: bdale's and pb's 01:20 elmo: wow, four arms? that's like deformed! 01:21 aj, is the first report of "fakeroot segfaults" on hppa. 01:21 * elmo beats aj with all 4 arms 01:21 * Sledge tickles aj 01:21 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. 01:21 elmo: don't forget cats (even if it shows up as toffee!) 01:21 kyle: two months is a /long/ time 01:22 vorlon: yeah, sparc32 is just _too_ old for most people 01:22 oh, err, right, so 5 arms 01:22 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 01:22 aj, hmm, i think there were two seperate problems, hold on. 01:22 elmo: OK, but we need more because we still struggling to keep up on the lists? Or do we need more admins? 01:22 fjp: well, then he can become a DD and sign up to help the port? ;) 01:22 -!- azummo [~azummo@213-140-6-127.ip.fastwebnet.it] has left #debian-tech [] 01:22 so, is anyone doing pages for arm, ppc, i386 yet? 01:22 joeyh: etch needs a complete new hardware configuration which is beeing worked on 01:22 Sledge: it's not even the age, it's just how many core packages have to build sparc64 variants 01:23 aj: I'm trying but I'm failing to drive this wiki 01:23 joeyh: partitioner's also used for some m68k subarchs 01:23 wookey: we don't need more admins, we need someone to investigate arm specific failures 01:23 wookey: like perl vorlon mentioned earlier 01:23 Sledge: can't build a kernel on sparc32, or d-i, or glibc, ... 01:23 elmo: OK 01:23 joeyh: That's also still a problem for ARCS mips. 01:23 wookey: that requires arm knowledge, and I've never had or claimed to have that 01:23 vorlon: yeah, that too 01:23 fjp: yeah, and it adds more than it's fair share of load to keep maintained 01:23 -!- kyllikki [~vince@pike.pepperfish.net] has joined #debian-tech 01:23 joeyh: partman is simply too slow 01:23 hey kyllikki 01:24 vorlon: (do you want these under wiki.d.o/release.debian.org/qualification/i386 or is as they are fine?) 01:24 it's an S390, for crying out loud 01:24 * kyllikki apologises for his tardyness 01:24 of do you mean m68k? :-) 01:24 hello kyllikki 01:24 joeyh: Please consider my poor Hercules ;-) 01:24 oh good, more arm people 01:24 :-)) 01:24 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 01:24 see we're keen really, even if we are a bit crap 01:24 what's arm's excuse for having so many oods? 01:25 aj: oods? 01:25 "out of dates" 01:25 vorlon just answered though :) 01:25 aj: dpkg randomly starts to segfault on buildds 01:25 aj: ask elmo to upload more ofted? 01:25 joeyh: i meant m68k; but hercules is also slow 01:25 "HP sells [WWW] new systems at insane price" bwahahaha 01:25 Too many buildds fighting over same packages probably 01:25 aj: are you asking what url to use for i386? makes no difference to me 01:25 joeyh, url? 01:25 alpha qual page 01:25 elmo: thought we fixed that? 01:25 kyllikki: err, no? 01:26 it's happened 5 times now, the "fix" each time has been to reboot the box in question 01:26 yeah, that's a worrying development 01:26 that doesn't actually fix the underlying problem 01:26 aj: better start wirt Ports/Qualification/$arch 01:26 elmo: having a huge pile of packages listed as building against machines that dont exist any more can't be helping either? 01:26 or stop the resulting buildd pile up car crash 01:26 and it's not just in the chroots - the base system is seeing it too 01:26 kyllikki: eh, like what? 01:27 Sledge: the segfault comes from the dynamic linker, its untracable through the ld.so 01:27 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? 01:27 elmo: well the building list still refers to smackdown? 01:27 kyllikki: smackdown still exists 01:27 unless this is a recent development 01:28 vorlon: smackdown is phils machine? thought he dismantled it? 01:28 wookey: try http://buildd.debian.org/status/architecture.php?a=arm 01:28 kyllikki: again, not unless this happened recently 01:28 james@smackdown:~$ date 01:28 Sun Oct 9 02:28:19 BST 2005 01:28 kyllikki: pb said he had a running build week before last 01:28 evidently not 01:28 kyllikki: smackdown is alive and well and hasn't not been AFAIK 01:28 wookey: 163 packages in state "Maybe-Failed" 01:29 elmo: british (standard|summer) time? 01:29 waldi: yes 01:29 (summer) 01:29 elmo: it wasnt available during the complete faliure of all the other machines tho which is why I thought it went away 01:29 wow, never saw those pages before 01:30 vorlon: that's a really useful URL - how long have I not known about it? 01:30 wookey: only about 6 months I think 01:30 so it's tofee [sic] (== toffee + that other one) that's having 250'ish in 'Building' without build log 01:31 yes, arm is due a give back 01:31 however, there is PLENTY for arm knowledgable people to be fixing 01:31 and no one really has been since pb became less active 01:31 wookey: so, you have to create the page before doing a [wiki:... ..] link to it evidently 01:31 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 01:32 aj: indeed - the opposite way round to other wikis I have used 01:32 elmo: indeed - we've been depending of guru-phil for some time 01:33 lots of issues are shared between arm and armeb 01:33 I didn't know he'd slowed down, of course 01:33 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 01:33 much like mips and mipsel 01:33 we (armeb people) think we can lend a helping hand there 01:33 vorlon: I'm sure 01:33 yeah, I think the armeb new blood will help a lot 01:34 -!- Keybuk [~scott@62.49.129.42] has joined #debian-tech 01:37 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 01:38 we have a standing offer for hosting a machine at BCN - we just need to get it there... 01:38 get what there? 01:38 debussy? 01:38 a machine 01:38 I dunno which 01:38 I can put up a machine for developers - we have a spare IP for the purpose 01:38 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 01:38 do we have enough contact with blindman via alfie to get debussy there? 01:39 to get it where? 01:39 BCN 01:39 black cat networks 01:39 last I heard was that BlindMan was in Canada 01:39 where local admins can be more responsive 01:39 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 01:40 elmo: yup 01:40 fwiw, one other thing I want to do at work is bring in at least one and possibly 2 of our developers as DDs 01:40 and while developers that know nothing about the arch can give it a try...that doesn't make for quick resolution of problems 01:40 (for arm) 01:40 elmo: indeed, but theres only one of me and Im not doin *everything* ;-) 01:40 elmo: OK, but now we know that I expect it can be resolved 01:41 joeyh: the armeb people have two people in the DD queue 01:41 I know I've been assuming pb was on top of things 01:41 kyllikki: sure - I recognised you with the kernel/d-i disclaimer :) 01:41 joeyh: currently waiting for AM 01:41 * kyllikki notes provision of hardware for debussy isnt an issue if the old machine isnt viable 01:42 elmo: tho had I know that the porting stuff had gotten oyut of hand I would have done a bit 01:42 kyllikki: so, get it to BCN, and we've got that one solved, then? 01:42 I'm pretty sure there enough people who care about arm - they just need telling what to do, and how 01:42 fwiw, I don't think there's anyone actively looking at powerpc-specific failures, either 01:42 vorlon: hmm that perl faliure is weired 01:42 so how about we try to get the chart a bit filled in... 01:42 neuro: heh as long as it doesnt wait on admin as long as tofee did 01:43 kyllikki: yeah. I've already had one person suggest it was a transient issue. 01:43 kyllikki: we normally give wired arm perl probslem to nick 01:43 this discussion is now going into quite specific details of mainly arm... 01:43 jvw: yeah 01:43 sorry 01:43 jvw: discussion can only go in the direction for which people are here to talk about 01:43 any other arch people want to chime in? 01:43 but it seems we have problems that need adressing 01:43 rather than getting an idea of which archs are probably qualifyeable and which are not 01:43 and the people with the answers are here :-) 01:43 vorlon: Just remember for sparc that blars does a fair amount of work. especially re build failures 01:43 ARM == we have issues but hey, we can fix em 01:44 jvw: I guess arm is the only one that'll qualify, because no one else cares to speak up ;) 01:44 * kyllikki was only late because I thought this meeting was tomorrow :-/ 01:44 people can speak for other archs too 01:44 a bit, at least 01:44 some boxes are easy to fill in 01:44 a second buildd for i386 is in the works 01:44 fjp: I'm actually a bit disappointed with the bugs Blars files about build failures, because they tend not to include much analysis 01:45 it's just so idle it's not very high on my list 01:45 vorlon: yeah. we may be disorganised, but we did turn up :=) 01:45 and it is 03:00 local 01:45 nearly 01:45 #dudes: * dato tries to catch up in #debian-tech 01:45 vorlon: True. It's more notifying than analyzing. 01:45 -!- lennert [~buytenh@alephnull.demon.nl] has joined #debian-tech 01:45 mipsen is obviously having problems (no java compiler, none coming anytime soon) 01:46 fjp: so, bugs are filed, but the maintainers still have to figure out why it failed, which may require sparc-specific knowledge... 01:46 neuro: I hope the anytime soon won't stay true for long. 01:46 So, *availability*: ttbmok, i386, ia64, powerpc are obviously green, the rest? 01:46 ths: Are you finding time for it? Or is someone else working on it? 01:47 powerpc has a problem like arm. someone knows there are machines somewhere 01:47 jvw: which sort of availability? 01:47 neuro: It's the next on my list after 2.6 kernels. 01:47 jvw: i386 and powerpc are both lacking a backup buildd, so red (well, maybe orange) 01:47 I'm talking availability -> to buy new etc 01:47 http://wiki.debian.org/EtchReleaseRecertificationTemplate 01:47 jvw: alpha is apparently still available, according to its qual page. ia64 is for sale. 01:47 ^-- blank certification template fwiw 01:48 i just said i386 is being dealt with, and with how idle it is, it's really a big deal. 01:48 vorlon: do you want to check that's okay? 01:48 neuro: not a big deal, ym? 01:48 https://release.debian.org/etch/arch_qualify.html 01:48 errr, right 01:48 jvw: arm can be bought new. 01:48 jvw: mips/mipsel is available. 01:48 neuro: Just replying to the "obviously" 01:48 jvw: s390 and powerpc are available 01:48 jvw: alpha, arm, hppa, s390 are definitely available 01:49 sparc is purchasable too 01:49 anyone wanting to contest any of those claims? 01:49 but ia64 is mostly dead 01:49 rather than contest them, can we just have certification pages with links that prove them? 01:49 waldi: oh, hush 01:49 aj: looks good to me 01:49 waldi: dude, please 01:50 I'm working on the arm cert page now 01:50 s390 folks calling ia64 dead - jesus, the irony 01:50 and when you finish, I suppose I can go on-clock to add links to where to buy :-P 01:50 elmo: Hey, I work in cobol/idms environment for a living (on s/390 :-) 01:50 elmo: soon there'll be an s390 in every home :) 01:50 I'm trying to get a quick overview now, to identify issues 01:50 waldi: SGI Altix is available. :-) 01:50 so has anyone started on i386, ppc or amd64? 01:50 and a chicken in the pot on every s390 01:51 I did i386 01:51 well, mostly 01:51 I don't know about developer machines 01:51 aj: do you want the hppa or ia64 ones redone to fit the template? 01:51 willy: ask vorlon :) 01:51 * willy twinkles at vorlon 01:51 * kyllikki tries to sell everyone nice shiny new ARM machines 01:51 weasel: I hear they sell systems that combine s/390s with furnaces and air conditioners now 01:52 vorlon: a s390 always contains air condition 01:52 willy: would be helpful to have them all with the same layout, yes please 01:52 and here I spent all day fixing my wood stove's pipe, and I could have been airlifint a s390 in 01:52 waldi: but do they air condition your house? :) 01:52 airlifting 01:52 is sparc really available new? 01:52 vorlon: no 01:52 vorlon: ok. i;ll do hppa now. 01:52 jvw: yes 01:52 willy: thanks 01:53 * jvw got offered two of them at least in the past month, but they were not new... 01:53 sparc is never cheap new 01:53 Should I already put some time in amd64 getting qualified? 01:53 * joeyh goes to redo i386 with aj's template 01:53 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 01:53 so, hppa/m68k seem to be the only ones failing so far 01:54 err, "keep up with unstable, satisfactorily for testing's purposes" 01:54 aj: other than the 98% mark? 01:54 jvw: sparc new: yes (but not well supported by kernel) 01:54 jvw: dannf assured me that even hppa boxes can be purchased new 01:54 vorlon: everything except i386 fails the 98% mark now doesn't it? 01:54 aj: today, yes 01:54 "refurbished" pobably 01:55 aj: if you count the not-for-us as failed, yes 01:55 not-for-us shouldn't be used 01:55 waldi: 98% == of packages built in unstable, 98% have the current version built 01:55 elmo: meaning P-a-s should be used instead? 01:55 yes 01:55 agreed 01:56 http://buildd.debian.org/stats/graph-week.png ? 01:56 that's what we want to use, isn't it? 01:56 buildds: N<=2. /me beats the release team over with a HTML spec 01:57 why is the n<=2 in tehre? 01:57 <=2 :) 01:57 surely we really want at least three for redundancys sake? 01:57 aj: doesn't account for P-a-s, which it really ought to, no? 01:57 (needing to keep up) 01:57 elmo: so, where can I add changes? 1:57 kyllikki: if you only need one, then two is plenty redundant 01:57 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 01:58 vorlon: it doesn't? 01:58 aj: not AFAIK 01:58 vorlon: it does 01:58 * aj makes a face at vorlon 01:58 elmo: it does? Oh wow 01:58 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 01:58 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... 01:58 dude, why have I not asked for m68k to be ignored yet then? :P 01:58 because you're a wuss! 01:59 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 01:59 sparc and arm could do with ignoring too, by the under 95% rule 02:00 some of these rules seem a tad arbitrary 02:00 kyllikki: yes, they may be 02:00 vorlon: erm, yes it does take P-a-s into consideration? 02:00 aj: I've been going by 92%, and using force hints for 92-95%; but m68k is apparently *way* worse than I thought 02:00 all the "fast enough" rules have to be a tad arbitrary 02:00 vorlon: so ignore m68k, rerun britney? 02:00 but precise numbers can be tweaked once we get an idea of what seems to work 02:00 aj: yah :) 02:01 elmo: okay 02:01 vorlon: just ignore version sync, or ignore uninstallability too? 02:01 * kyllikki mutters that intel are bastards and refused to make good on their hw offer 02:01 yes please, do it now 02:01 aj: both 02:01 kyllikki: typical 02:02 vorlon: wanna make an m68k page, and just fill in the RM veto section? :) 02:02 lol 02:02 kyllikki: did they? stockholm said he was going to put you in touch with them; did he? 02:02 ok, so, 0200 UTC... time for me to go find dinner. :) 02:02 vorlon: Both? are you sure? uninstallability increases are extreme 02:02 it's 4AM here now, and i'd really love to go to sleep 02:02 elmo: It all happened, when they discovered I wanted some real hw not a pissing little 200MHz PXA270 they didnt really want to know 02:03 I got bored at making https://release.debian.org/etch/arch_qualify.html 02:03 elmo: we wanted a 1.2GHz intel dev kit, but as their the thick end of 20k they said no 02:03 kyllikki: oh, meh 02:04 * fjp likes seeing machine names in "Developer availability" 02:04 fjp: actually, that's what is meant there 02:04 machines available for DD's 02:04 elmo: we could have a iop331 system at 400MHz which performs like what we already have... 02:04 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 02:05 rather, force-hint hints 02:05 jvw: Suggest retitle to "developers system" 02:05 vorlon: doing the second one makes it very, very, very hard to get the arch back in. 02:05 neuro: well aj called me a wuss, so I'm overcompensating 02:05 fjp: better? 02:05 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 02:06 jvw: :-) 02:06 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 02:06 jvw: It's not really porter though as they probably have their own box. Maybe "Porting" though. 02:06 I gotta get some shut eye, gnight 02:06 aj: that sounds reasonable. m68k is still below the lower line. 02:07 yup 02:07 want me to move the lines on the graph? 02:07 * jvw whines at gluck being too slow for a useable vim session 02:07 (arm, and sparc are under the higher line) 02:07 neuro: yes please 02:08 http://buildd.debian.org/stats/graph2-week.png <-- a 90% or 95% cut off on that sounds plausible too 02:08 aj: sparc is recovering from failure of both buildds; give it some time to catch back up 02:09 wtf is going on with ARM, weve dropped like a brick 02:09 yeah, sparc has only briefly dipped below the line 02:10 must sleep...that can wait 02:10 http://wiki.debian.org/hppaEtchReleaseRecertification rewritten now 02:10 graph2 numbers tend to be higher, as they don't include uncompiled packages 02:10 and sparc is above 95% currently in the graph 02:11 yeah, and I think graph2 is the wrong metric for judging releasability 02:11 Sledge: I assume as cats is idle again that theres summat wrong with the buildd on there again? 02:11 kyllikki: hmmm 02:12 I think it's the right one for making testing cutoff decisions, tho 02:13 hmm, possibly 02:13 erm 02:13 because testing doesn't care about an arch being "uncompiled" 02:13 I'll think about that while I'm off dealing with dinner 02:13 later, folks. :) 02:13 oh, okay }}}