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