20:02:04 #startmeeting 20:02:04 Meeting started Mon Aug 23 20:02:04 2010 UTC. The chair is phil. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:04 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:02:05 MeetBot: pingall meeting about to start 20:02:05 meeting about to start 20:02:05 _rene_ aba AbsintheSyringe adsb ana AndrewLee ansgar armin arthur aurel32 azeem bdale bgoglin bigon blathijs broonie buxy bwh bzed carnil carstenh cgreco christoph Clint codehelp Corsac Cowboy Cowboy__ dannf darst des DktrKranz dobedobedoh doko DonKult dwatson 20:02:05 eddyp_work enrico fabo fatal faw frankie fs Ganneff gilbert_ Guest381 h01ger HE idnar jandd jcristau JHM jhr jimpop jmw johfel jordi jwilk kaeso kaol KiBi kilobyte kmap kmuto_ kobold kov Laney LM lool lucas luk luk_work Lutin MadCoder maks marga Maulkin maxyz 20:02:05 mbiebl Md meebey MeetBot mehdi mgoetze MoDaX mornfall morph mvo nekral neli nenolod noahm Np237 nthykier otavio pcc pdewacht_ peterS phil pos Q_ Renegade Rhonda Rubidium Ryan52 ScottK sf sgnb sgran shoragan siretart Sledge smd spion sutula Svedrin symoon tarzeau 20:02:05 the-me Tolimar varun vorlon waldi weasel xoswald xtophe Yoda-BZH zack Zhenech zobel zumbi_ zwenna 20:02:05 meeting about to start 20:02:10 Waah. 20:02:11 eww. 20:02:22 * ana always wanted to do that 20:02:22 hello everyone :) 20:02:26 A warm welcome to everyone who made it to this Release Meeting. It's 20:02 UTC, so let's start. 20:02:29 I had to get myself identified to it, for some reason I had to restart it 20:02:37 The agenda for today is as follows: 20:02:38 1) What will be the release architectures for squeeze? 20:02:38 2) Which transitions are left for squeeze? What's their current state? 20:02:38 3) Release Team meeting 2-3 October in Paris: Who's going? 20:02:38 4) What's the state of the Release Notes? 20:02:39 darst: thanks 20:02:40 5) Any other business? 20:02:42 We'll work with a soft deadline of 1h, and a hard deadline of 1,5h. After the soft deadline we'll not take up any more agenda items unless really necessary. 20:02:45 adsb, Maulkin, jcristau, faw, luk, mehdi, vorlon, zobel, HE: Could you please wave if you're there? :) 20:02:48 o/ 20:02:56 _o/ 20:02:59 o/ 20:03:15 didnt know there is a release meeting, but good to know! ^^ 20:03:16 o/ 20:03:58 *salute* Go team release 20:04:27 And I saw Maulkin earlier. :) 20:04:32 uh 20:04:33 he's hiding now 20:04:34 * Maulkin waves 20:04:40 oh there he is 20:04:45 Please keep random chatter down so that the minutes are actually readable afterwards. :) 20:04:56 So, there we are. First up are architectures... 20:05:01 #topic What will be the release architectures for squeeze? 20:05:17 the less, the better 20:05:39 AFAICS we've got concerns raised about hppa, kfreebsd-*, sparc and mips. 20:05:53 * Maulkin nods 20:05:56 the status package lists concerns about the toolchain in the comments, but doesn't have an entry for the toolchain maintainers. please can we address this? 20:06:20 You mean listing toolchain maintainers in addition to the porters? 20:06:37 sparc and mips* were raised as issues by doko, from a toolchain maintenance point of view 20:06:55 Let's discuss them first, then. Given that doko's here. 20:07:08 yes, you address problem in the comments, but these don't show the status of the toolchain 20:07:11 hppa has an RC kernel bug but I don't know whether it affects all or only some hppa machines 20:07:22 phil: one by one ? 20:07:29 first sparc and then mips ? 20:07:32 sure 20:07:35 Yep. 20:07:57 doko: can you explain the current issues on sparc? 20:09:03 AIUI we use a supported code generation option nowadays (-mcpu=v9) in 32bit mode instead of 64bit mode. 20:09:04 well, the current configuration that we have for squeeze isn;t an upstream config, but just a "hack" which seems to work okish. 20:09:35 do we have concrete issues identified? 20:09:51 however we don't have anybody committed to the sparc port and the sparc maintainers are all gone 20:10:15 Listed are bzed and jurij. 20:10:48 aurel32: concrete issues are openjdk; still works for openjdk6-b18, but not b20 20:11:04 * HE waves 20:11:16 phil: I did see that bzed stepped back 20:11:29 for the glibc part, I can tell that David Miller is really active upstream 20:11:48 he usually fixes the bug quite fast 20:11:52 for gcc I don't know 20:11:56 That would leave us with a high bus factor on the Debian side. 20:11:59 the point is that everybody defaults to sparc64, except debian 20:12:16 that sounds quite strange 20:12:29 doko: who else does linux/sparc? 20:12:35 because the sparc64 toolchain is not in a really good state 20:12:37 Didn't we EOL 32bit sparc? Or is that my memory playing tricks on me? 20:12:43 aurel32: He's certainly active on gcc for sparc 20:12:43 Maulkin: 32bit kernels 20:12:46 jcristau: sparc, or sparc64? 20:12:49 doko: whichever 20:12:56 for exampel sysv ipc were not working until a few months 20:12:59 I add to fix that 20:13:08 jcristau: sparc64 would be at least gentoo and fedora 20:13:14 We have had a few packages that seem to have issues with (at least some of) the buildds, but those could machine related as at least e.g. db4.8 builds fine on the porter box 20:13:25 same the kernel has a lot of recent issues executing sparc64 binaries 20:13:27 Maulkin: sparc userspace is still mostly 32bit, running on a 64bit kernel. 20:13:34 doko, phil: mainly because I don't have spare time left. if machines are missing I can help out, though 20:13:42 jcristau: ah, ack 20:13:43 * zobel waves 20:13:51 my impression is that maybe 32-bit toolchain is deprecated, but it behaves better than 64-bit 20:14:00 bzed: no, it's not machines but man power 20:14:13 Are you sure that gentoo is sparc64 on the userland side? 20:14:14 doko: I know 20:14:36 phil: I was told so 20:14:56 now the question is what the toolchain maintenance means once squeeze is released 20:14:59 ? 20:15:26 would we be able to do a sparc rebuild? 20:16:22 doko: When did you change the toolchain for v9? 20:17:00 i see 'On sparc default to v9 in 32bit mode' in gcc-4.3 4.3.4-6, nov 2009 20:17:39 OK, could we concentrate on the few important issues? I see two problems (a) Can we be sure that the freeze won't be delayed because of sparc problems (b) will we be able to provide support for sparc in squeeze's lifecycle 20:17:40 yes 20:17:46 We might do some rebuilds, if the buildd maints are given a package list, FWIW. If it helps anything. 20:18:23 I think we can answer (a) prettly easily: This won't be a big problem. The few sparc-specific problems we had in the past have been fixed quite fast and I expect this not to change in the coming few months. 20:18:27 phil: for a package list, I would propose packages which land on CD's/DVD's 20:18:45 doko: all packages in main land in cd's/dvd's. 20:18:52 doko: Which would be everything, basically, so a no-go. Ubuntu does it differently, I know, but Debian ships all. 20:19:19 unless you mean cd1 or dvd1 20:19:32 The question for (b) is more interesting and is what the rebuild more or less could answer for us. I haven't done the sparc buildds in the past few weeks, but I think we can spare a machine to do a rebuild test on the whole archive. 20:19:33 so please define the list of packages yourself 20:19:52 HE: That sounds sensible 20:20:12 To get it more interesting, we should probably just choose packages which haven't been built this year (because there was neither an upload nor binNMU) 20:20:39 I can take care of the scheduling then. If we want that. 20:20:57 Would that solve the sparc issue for now? 20:21:02 HE: if the resources are available, I would appreciate a rebuild of all packages (maybe sorted by priority) 20:21:06 phil: I think this would be a sensible option. We don't have any concrete problems at the moment that need to be handled. 20:21:32 #action phil queues packages that have not been built this year to rebuild on sparc 20:21:39 So let's move on to mips*. 20:21:51 just to be clear, this means sparc stays? 20:21:55 faw: Yes. 20:22:00 ack 20:22:08 We should probably split this into a mips and mipsel part, which have slightly different problems on the hardware side 20:22:21 well, I would expect this be an outcome of the rebuild 20:22:30 do we have a mips porterbox, or still not? 20:22:31 #info sparc stays as a release architecture for squeeze 20:22:46 although a common toolchain issue (the gcc-4.4 -g issue) 20:22:54 yes 20:22:57 #info sparc stays as a release architecture for squeeze, depending on the results of a rebuild 20:23:04 this is definitely a blocker for the release 20:23:18 Yes. Shall we handle this common problem first? 20:23:19 doko: if it doesn't work, what about disabling this patch building for v9? 20:23:45 HE: I think 20:23:48 aurel32: Could we defer details about sparc to a later point? We have hard limit on this meeting and would like to discuss everything on the agenda 20:23:54 HE: ok 20:24:11 so for the mips -g issue 20:24:25 aurel32: imo, not an option. because this change was active now for about nine months 20:24:26 we have a patch for gcc 4.5, but we don't know how to backport it to 4.4 20:24:34 agreed 20:24:44 aurel32: Was upstream asked about a backport? 20:24:54 phil: just did that a few hours ago 20:25:51 otherwise loongson people would like to help on that 20:26:02 according to what was discussed at debconf 20:26:25 So there's a solution on the horizon and you're optimistic that it could work out? Did you already contact the loongson people too? 20:27:02 phil: looked at it. fedora has a backport, however their branch has too many backports. for this one, it's closer to 4.5, which won't work for debian 20:27:27 no, nothing on the horizon 20:27:30 I haven't yet asked the loongson people more than at debconf, I should recontact them 20:27:49 OK, maybe we should give a hint to those people who are not tracking mips: We are talking about the many FTBFSes induced by #519006 20:28:21 #action aurel32 to follow up with gcc upstream and loongson people about getting a backported fix for #519006 20:28:37 I think we cannot do more about this. 20:28:47 aurel32: Could you report about your progress in a week or so on -release? 20:28:56 So mips is still at risk. 20:29:07 jcristau: already followed up upstream 20:29:10 well, it's more mipsel than mips 20:29:28 Yes, this is absolutely a release critical issue: It breaks building of many packages and the workaround (not using -g) is quite horrible. 20:29:29 I will also contact people at codesourcery 20:29:34 moving to other mips/mipsel issues besides that bug? 20:29:48 Yes, we should probably split this up. Maybe first mips, then mipsel? 20:30:15 fine with this order 20:30:23 For mips, we have a simple HW issue: We don't have enough stable (!) buildd and porter machines. 20:30:24 we might have a toolchain issue for mipsel (I don't want to investigate), which breaks the openjdk build 20:30:39 basically as far as I know, since we moved to the movidis boxes, we have plenty of problems 20:30:42 doko: isn't it for mips? 20:31:00 aurel32: sorry, yes 20:31:28 I am convinced this openjdk-6 bug on mips is triggered by the hardware 20:31:36 we have plenty of strange failures on mips 20:31:43 and not on mipsel 20:31:54 maybe, but there are no machines to investigate this 20:31:55 historically mips and mipsel have almost always behaved the same 20:32:12 The movidis boxes seem to have kernel issue that breaks the machines from time to time. We also have some FTBFSes which only happen on the movidis boxes, but not on the SWARMs. 20:32:17 Could I just check who the mips/mipsel porters are? 20:32:52 HE: and the stable hardware we used to have broke down? 20:33:15 does the release team have a list of mips porters, or do you want one? 20:33:17 jcristau: No, we still have those boxes 20:33:31 jcristau: They are just too handle all of unstable alone 20:33:42 jcristau: Besides, we had a broken HDD taking one of them down for some time 20:33:49 HE: afaik we only have ball 20:33:54 mayr is broken 20:34:01 getting someone who cares to look into the kernel issue on the movidis boxes seems wise 20:34:08 aurel32: I'd just like to know that there are some. And that they're active. And possibly that they care about it still :) 20:34:14 regarding mips* porters it's always a good idea to Cc linux-mips@linux-mips.org for tests on hardware or debugging hard issues... 20:34:25 aurel32: AFAIK mayr is supposed to be reinstalled one of these days? 20:34:37 HE: depends on osuosl 20:34:45 I mean yes, but we can't predict when 20:35:02 Yeah, but it's not broken as in broken-for-good, but broken for now 20:35:49 aurel32: i'd quite like a list of mips porters, if it's not just you.. 20:36:16 are there any? 20:36:19 I don't think we have a full list somewhere, but I can try from memory 20:36:40 tbm has said he want to stop, but is still doing stuff on the kernel packaging 20:37:15 guido guenther, peter de schrijver 20:37:33 any of these toolchain maintainers? 20:37:45 aba has packaged the kernel for loongson 20:38:00 aurel32: packaging is one thing. fixing issues is another.. 20:38:01 jcristau: Florian Lohoff and Thomas Bogendoerfer can be added to the list, though they need to be prodded 20:38:14 arnaud patard is active on the mailing list 20:38:23 but we don't have official toolchain maintainers to answer the question 20:38:27 we rely on upstream for that 20:38:36 * doko nods 20:39:12 OK, so can we try to forward the possible toolchain issue by openjdk-6 to upstream? 20:39:14 * aurel32 wonder if we have toolchain maintainers in Debian for some of our architectures 20:39:22 sorry for comming in too late 20:40:03 HE: we can try, though I would start by building it on ball first 20:40:05 aurel32: also for movidis, the cavium-network coorp guy is quite actively responding to mails when we had troubles with the movidis boxen 20:40:15 aurel32: OK, will you handle this? 20:40:27 so we could ask him for kernel help with mips maybe as well 20:40:40 my experience with mips* is that we get responses on the -mips-lists 20:40:48 I can try yes 20:40:53 HE: no, openjdk doesn't care, and icedtea zero mips for debian was my effort, which I cannot continue 20:41:04 aba: that requires somebody who cares enough to prod them. 20:41:05 #action aurel32 will try to reproduce openjdk-6 toolchain issues 20:41:10 aba: on the debian side 20:41:13 jcristau: I did that often enough. 20:41:16 which seems to be lacking 20:41:25 OK, away from the software issues: HW issues: Is there something that needs to be done urgently? 20:41:26 at least when it annoyed me enough 20:41:27 I am afraid I will need an access to ball for that 20:41:38 aurel32: ok with me 20:41:44 fine then 20:41:53 on the other hand - I think maintainers should at least contact the porters list. 20:41:56 aurel32: No problem, open a ticket with DSA, someone will ACK it. 20:42:10 HE: i can do it without 20:42:20 zobel: then go ahead 20:42:33 HE: well we don't have porterboxes.. 20:42:35 as soon as i have a shell on draghi. 20:42:36 afaik 20:42:43 aba: I think it's a general problem. porters are not often aware of the issues 20:42:56 jcristau: for mips we have, for mipsel we dont 20:42:57 aurel32: right. 20:43:02 jcristau: We have gabrielli (movidis, unstable) for mips. For mipsel, we have nothing. 20:43:15 for mipsel we can use the machine I have at home 20:43:21 we should setup one of the longsoon boxes for porters. 20:43:28 it's ready to be used, and it makes noise here 20:43:39 aba: Will you handle this? 20:43:40 also I gave some people access to one of the machines at my place. 20:43:45 and gabrielli and buildds are too different. 20:43:49 HE: if zobel hands me the machine, then yes. 20:43:56 doko: shouldn't. except for bugs. 20:44:10 #action zobel will send another loongson machine to aba, who will set it up as mipsel porter machine 20:44:11 aba: bugs are exactly the problem. 20:44:21 aurel32: should we host your box at a DC 20:44:29 OK, I think we are done with everything we need to do with mips* now. 20:44:36 zobel: it's actually a Debian box 20:44:37 zobel: we can sort it out later I think. 20:44:44 aba: do you volunteer to investigate these? 20:44:45 zobel: yest at a DC, would be ok 20:44:48 HE: hppa? 20:44:49 So: hppa. 20:44:56 #action: zobel takes the other loongson boxes to aba next week when coming to munich 20:44:56 * jcristau ^5 phil 20:44:57 doko: if you send me what works on which machine, yes. 20:45:00 JFTR we should get loongson 3 boards when there are available 20:45:19 So, hppa. Drop it? 20:45:33 no objection 20:45:38 are there alternatives? 20:45:38 from DSA side: i wouldn't mind dropping HPPA in long term. 20:45:47 from a toolchain point of view hppa is much better than mips* 20:45:52 what are the hppa issues currently? still fucked up threads? 20:46:03 jcristau: And no sign of a soluton to that 20:46:09 who had concerns are hppa? 20:46:10 and kernel issues 20:46:11 #561203 20:46:12 we had quite a bit of trouble with HPPA, though it got better the last 2 month 20:46:21 You can't buy any hppa machines anymore, and bdale has even acked the EOL for them two releases ago? 20:46:40 Though /me doesn't have an unbiased opinion, so will stay out of this one :) 20:46:41 dannf: i thought that one had a kernel patch a while back? 20:46:50 there are several kernel patches floating around 20:47:07 the 64bit toolchain can't run the testsuite, we still use weird options 20:47:22 and a wiki page tracking them.. but the ones i've tested haven't helped 20:47:27 dannf: so do you think we could realistically bring it back into release shape on short term? 20:47:49 waldi: we never did run the hppa64 tests afaik 20:47:54 and support it for about 3 years to come? 20:47:57 There is a dirty patch for UP only, right? 20:48:28 doko: we can't, because there is no userspace? 20:48:37 correct 20:48:42 So in theory going UP could solve issues? /me shudders. 20:49:25 There are separate UP and SMP kernel builds, so in theory we could drop the SMP flavours 20:49:31 the only issue i'm aware of still existing is #561203 - and i don't see a sign of that getting fixed 20:49:52 and i haven't noticed better behavior on SMP - buildds run UP kernels 20:50:12 dannf: And the UP kernels are broken, too? 20:50:13 for hppa we should aim at a separate 'release' instead of including it in the offical release IMHO 20:51:00 yes. lafayette seems to be much less affected than the 2 buildds i maintain 20:51:25 luk: But that would still cause us grief with autobuilding, right? 20:51:46 luk: Unless we freeze for a almost-squeeze-hppa at some earlier point? 20:51:53 luk: Isn't that the same as what happens with all non-release architectures, before they are moved to ports? 20:52:16 bwh: some don't even do a semi release... 20:53:10 So, can we agree on any plan for hppa? 20:53:39 phil: well as it would not be official it would not have to be released on the same day, although it would be better if it could 20:53:52 I think the plan is to drop hppa from the official list of release architectures. 20:54:15 * Maulkin nods 20:54:18 And if hppa is causing us real grief in the near future considering ignoring it? 20:54:21 hppa has been almost dropped for over a year, and the situation has not improved significantly. 20:54:50 Someone's mileage may vary on that, though, given that someone actually worked on it. ;-) 20:55:03 The porters have not been able to fix all issues that have come up (at least not as fast as they pop up), new hardware doesn't exist and the userbase is small. 20:55:12 it improved, but I'm not sure if it#s improved enough. 20:55:42 Ok, for the testing migration impact we should still contact the porters I guess. 20:55:53 So my proposal is to drop it from the release architectures, with an option to do a separate hppa-squeeze release that only contains a subset of packages, if the porters manage to hammer it into shape. 20:56:04 ACK. 20:56:07 ack 20:56:13 As noone is crying out loud: So it's going to happen 20:56:18 sounds ok to me 20:56:21 aye 20:56:22 \o/ 20:56:25 moving on to kfreebsd? 20:56:33 #action drop hppa as a release architecture, with an option to do a separate hppa-squeeze release that only contains a subset of packages, if the porters manage to hammer it into shape 20:56:37 4 minutes left 20:56:54 aurel32: For the soft deadline, though, which isn't hard. 20:56:59 kfreebsd it is. 20:56:59 is it 1 hour per item? :-) 20:57:00 aurel32: Please report on the current kfreebsd-* problems. 20:57:01 aurel32: be fast :p 20:57:38 let's be positive and start with things that have improved 20:57:47 i guess d-i :) 20:58:07 d-i from tomorrow should be working on the netinst, monolithic and cd-rom flavour 20:58:29 we finally have zfs mostly working 20:58:30 are there live CDs? 20:58:39 no live cd though, just the normal d-i 20:58:55 on the problems side 20:59:17 - we still have this ruby issue that bothers dsa 20:59:36 petr salinger has send some patches 20:59:43 my goal in the next day is to test them 21:00:00 java stuff only builds on half of the buildds. 21:00:02 haven't started before as I was working on d-i, the deadline was earlier 21:00:03 so we have good hope that it's fixed (but not confirmed yet) 21:00:22 yes, this gcj issue 21:00:22 Then some users popped up to test kbsd's features after our ping on -bsd. What came out of that discussion, in a nutshell? 21:00:53 the integration of the bsd port into openjdk/icedtea is still pending 21:00:57 phil: they mostly reported some issues, that we had to fix, and some of them have started to help 21:01:06 for this gcj issue 21:01:15 I have tracked it down to reading the classmap.db file 21:01:24 it doesn't fail on all machine depending on the size of this file 21:01:42 seems to be a mmap() issue when accessing after the file 21:02:00 linux is more permissive on this 21:02:05 but I haven't tracked more 21:02:13 I know it fails on my machine here 21:02:50 we also have a few pending issue (e.g. konsole broken) already fixed in eglibc SVN 21:02:53 we need to do an upload 21:03:02 and we are lacking a lot of documentation 21:03:21 not in the archive itself 21:03:32 but on the website, wiki, maybe even d-i manual 21:03:49 Can this be labelled as something like a 'preview release' for kfreebsd? 21:03:54 from what i understand, kfreebsd-* is not quite up to release standards, but you'd like to release something with squeeze anyway 21:03:55 What can a user expect from a kfreebsd install? 21:04:04 bwh: ack 21:04:06 <_rene_> bwh: isn't it already? 21:04:07 A server package set, I suppose. 21:04:26 yes, as a server, or light desktop environment it works quite well 21:04:27 <_rene_> bwh: something like that appeared in the freeze PM at least ;) 21:04:44 kde and gnome basically work, but not everything is integrated 21:05:07 a "technological preview" or something like that would be the best IMHO 21:05:44 Asking the security team to do security support on the "limited" package set we have, I guess. 21:05:51 Would this imply a separate suite or the same? 21:06:13 the same is for lots of issues way easier. 21:06:26 aurel32: Would we need to remove packages that are currently unusable or is everything that has been built mor or less usable? 21:06:37 because it will just be "everywhere" where we need it. 21:06:50 the main problem is to determine the packages that are currently unusable 21:07:01 the ones used by the developers work 21:07:16 but we all use a very small subset of debian 21:07:28 aurel32: Well, the main issue is: Can we just handle it as a release arch and label it in the release notes as technology preview (indicating that it's not as stable as the rest) or are additional measures needed? 21:07:29 so difficult to know what are the issues 21:08:10 aba: different suite means they can fix kfreebsd issues there without impacting the rest of us 21:08:11 what do you mean by additional measures? do you have examples of that? 21:08:28 aba: but i don't know if they want to do that in squeeze 21:08:46 we will probably do that, but I don't know to which level 21:08:47 * weasel looks in 21:08:48 jcristau: the question is if we want to pay the prize for that. 21:09:10 weasel: Concerns about kfreebsd-* except for the puppet issue? 21:09:11 aurel32: Will packages need special patches for kfreebsd; will we need to remove lots of binary packages; will it be somewhat ready at the same time as the other archs; ... 21:09:31 * mvo is very sorry but has to leave - if there are any question about the apt transition please either discuss with DonKult or lets discuss it via mail. but I don't expect any problems from the transition 21:09:54 phil: is molly-guard fixed yet? 21:09:55 let's say that compared to linux i386 and amd64 architectures, there are clearly of different quality 21:10:11 mvo: ok, thank you for coming! Sorry we didn't get to it in time! 21:10:13 mvo: ok 21:10:14 compared to another debian architecture, the difference is already smaller 21:10:15 #548099 21:10:40 thanks! 21:10:45 * mvo waves 21:10:51 aurel32: That kinda doesn't answer my question. Do you think we need to handle it specially from a release team POV? 21:10:53 my proposal would then be: for now we mark them as technology preview in release notes etc, but don't use another infrastructure set (we can review that if necessary) 21:11:02 * Maulkin nods 21:11:12 ACK, FWIW. aurel? 21:11:29 I am fine with that 21:11:37 OK. 21:11:48 #info kfreebsd-* as technology preview in squeeze, tentatively using the main suite 21:11:49 #action we mark kfreebsd-* as technology preview in release notes etc, but don't use another infrastructure set (we can review that if necessary) 21:12:12 OK, finished with archs. 21:12:25 weasel: madduck provided a patch that nobody bothered to test? 21:12:34 weasel: A one-liner, too. 21:12:37 #topic Remaining transitions: Status, known problems 21:12:42 phil: he could just test it himself. 21:12:47 don't know why he didn't 21:13:19 HE: looks like the bot doesn't listen to you.. 21:13:24 HE, I think phil's has to do the topic change 21:13:29 anyway, puppet is the huge problem. can't think of anything else that's serious 21:13:29 do #chair HE 21:13:34 I thought we are working on a soft deadline, though. 21:13:37 But well, so be it. 21:13:40 #topic Remaining transitions: Status, known problems 21:13:54 mehdi? 21:14:04 There are: opencv (ongoing), ace (ongoing), apt (planned), gnustep (ongoing) 21:14:14 apt and xapian are ready to start, involve many of the same packages 21:14:25 ace: RC bug, opencv: RC bug, gnustep: RC bug :-) 21:14:44 gnustep: rc bug on hppa, there is a fix 21:14:55 tested and waits for DktrKranz to upload the package 21:15:08 if those rc bugs don't get fixed, is it a problem to not finish those transitions? 21:15:08 the patch is here http://mentors.debian.net/debian/pool/main/g/gnustep-base/gnustep-base_1.20.1-3.dsc 21:15:09 Does DktrKranz need sponsoring? 21:15:13 <_rene_> without wanting to look like ignorant, but why accept new transitions in the freeze? 21:15:16 eh, I don't think so 21:15:17 Maulkin: he's ftpteam 21:15:22 Maulkin: he we on vac 21:15:26 Ah, ok 21:15:29 We had mentioned gdal in the past, but seem to have lost it somewhere 21:15:35 _rene_: because people asked for them prior to the freeze 21:15:38 _rene_: they had been accepted before 21:15:45 <_rene_> ah, ok 21:15:51 _rene_: just icu took too much time 21:15:58 gnustep is finished on all archs, except hppa and a few uploads, fwiw 21:16:05 Awesome 21:16:10 <_rene_> makes sense 21:16:37 as soon as gnustep-base is uploaded, I'll be able to schedule binNMUs on hppa 21:16:47 We're the new huggy feeling caring (ganneff) release team 21:17:00 err 21:17:02 there was some atlas stuff going on, too, iirc? 21:17:07 opencv has an rc and nobody seems to care about it (didn't check it yet) 21:17:17 ftbfs on hppa 21:17:34 (opencv that is) 21:17:37 yes, and no reactions from maitainers, afaict 21:18:08 now people understand why we first took care of the architectures point ;-) 21:18:19 Seems that hppa wouldn't be a blocker anymore. 21:18:21 * phil hides. 21:18:26 yay 21:18:27 (didn't get an answer, or missed it, so:) are those transitions actual release blockers? 21:18:50 jcristau: it's nice to get them done. Why would you skip them? 21:18:57 jcristau: gnustep and opencv only really relay on hppa 21:19:00 and except hppa, there are no problems 21:19:05 What was the apt transition about again? 21:19:29 phil: http://lists.debian.org/deity/2010/08/msg00175.html 21:19:30 phil: 21:19:41 phil: 21:19:45 ace is not RC to get done IMHO 21:19:50 Originally it was getting the long package descriptions split out iirc, but as we've taken a while to get to it the list grew somewhat 21:20:01 Oh and dynamic mmap. 21:20:02 luk: right, for ace. We could skip it. 21:20:21 sorry, I have to ask that, because I believe we should come up with some sort of position. Are we going to consider plans for a *possible* PHP (if they show up in the next days) or it should be a no-go even with any sort of plans? 21:20:25 mehdi: because they're blocked by rc bugs that i'd rather not have to care about if the maintainers don't. 21:20:34 faw: no go imo. 21:20:55 faw: IMHO it's too late for intrusive changes dropping backwards-compatibility. 21:21:00 Yeah, the deprecation list is huge 21:21:07 faw: there are no PHP plans, or can you point me to a public mail? 21:21:12 and with much used functions 21:21:31 Is apt a release blocker? (I'd assume so, but if it is, it should be documented.) 21:21:32 mehdi, no PHP plans 21:21:47 or is it not about php itself, but some kind of modules transition? 21:21:56 We have no mono mail either... 21:22:04 /o\ 21:22:31 adsb: but we discussed it here in this channel, and noone complained (re mono) 21:22:32 though aba knows more about the mono one? 21:22:51 aba: i don't think that counts.. 21:22:52 meebey, aba: It's not helpful that we asked about mails multiple times already. 21:22:57 jcristau: that's a difference 21:23:05 phil: I can't remeber that, but well. 21:23:06 We don't want such important things to go in private with only one-liner pings. 21:23:09 AFAIK it doesn't affect anything else. 21:23:20 but yes, I can make sure we get a mail. 21:23:37 aba: it affects the release if it turns out to be buggy.. 21:23:39 my email is pending before I do an upload 21:23:48 jcristau: everything affects there release if it ... 21:24:03 aba: that's why we're frozen 21:24:10 anyway.. 21:24:11 and the packages received extensive testing (multiple months by ~20k users) 21:24:29 It's it RC to have? 21:24:42 ok, re mono - we will see a mail soon enough. 21:24:55 did we finish php for this meeting? 21:25:06 I think so 21:25:22 DonKult: how soon can apt be uploaded to sid? 21:25:23 good. 21:25:28 php itself is a no go, other thing should be treated equally as mono IMHO 21:25:29 phil: RC to have 2.6 over 2.4? 21:25:48 jcristau: as soon as mvo does it, we are just waiting for a go… 21:26:23 #info There won't be a PHP transition for squeeze, sorry. 21:26:50 phil: there was one already :) 21:26:53 #info gnustep: RC bug on hppa, fix pending upload. Looks good otherwise. 21:26:55 from a release POV, mono 2.6 is a major polished 2.4 without new (used) features by mono software in the archive 21:27:09 #info Mono Transition needs to send a mail with plan 21:27:30 #info opencv: one FTBFS on hppa 21:27:41 #info ace: ftbfs on armel and kfreebsd, not a blocker 21:27:50 #action meebey sends a mail about the mono transition to debian-release@ 21:28:06 I guess we can give the go for the apt one? 21:28:12 (Sorry for the noise, but it makes minutes easier.) 21:28:17 it's acked, so yes. 21:28:19 luk: i think apt and xapian are a go, yes. 21:28:24 Not quite a transition, but we should also have finalish info re llvm-defaults in the next day or two. Not RC, but would help ease things for getting rid of 2.6 in squeeze+1 21:28:31 DonKult: go! 21:28:52 i'll unblock synaptic before scheduling rebuilds 21:29:04 #action mvo starts the apt transition in unstable 21:29:21 luk: will instruct mvo ;) 21:29:26 Do we want to ack xapian at the same time? 21:29:31 yes 21:29:45 * weasel ponders if #593125 should be RC 21:29:54 Done 21:29:57 it's simpler to run them in parallel, imho (apt+xapian) 21:31:14 so i guess we'll stop here? 21:31:18 weasel: you mean to document it with some debconf note during upgrade? 21:31:46 luk: I don't know what the proper approach is, but "upgrade all your machines at the same time" seems to not be a terribly useful advice 21:31:47 paris party^Wmeeting? 21:31:57 jcristau: I think so. We should do a quick show of hands for Paris, though. 21:32:02 weasel: what do you have puppet for? ;-) 21:32:09 #topic Release Meeting in Paris 2-3 Oct, who's going? 21:32:15 o/ 21:32:18 * luk is 21:32:23 i'll probably be here. 21:32:25 * aba 21:32:30 /o\ 21:32:31 I would try to make it. It would help to fix the date and times, though. I didn't see a reply from zack about it. 21:32:41 Though run without me :) 21:32:42 It seems to be hard for both Maulkin and adsb? 21:32:49 I'm depending on travel sponsorship, but as I said before, I'm OK to follow it overseas :) 21:33:04 I can, I just have to get up early on Saturday and not drink too much on the Friday :) 21:33:11 I would like to go, but need to check some things to see if I'm able to go 21:33:24 Somebody should take care of organizing the details to deal with zack 21:33:29 that makes easier for both side 21:33:32 mehdi: I suppose details are still being sketched out? 21:33:32 (as I most likely have a prior engagement on Friday night) 21:33:48 we should make a plan for the meeting 21:34:05 phil: details of? (sorry) 21:34:08 zack wants a lot of info from us: who needs a place to stay, who needs travel sponsorship 21:34:25 we need to organize that, a work plan and come back to him (that's what I understood) 21:34:25 * sgnb will probably be around (if appropriate) 21:34:31 mehdi: what faw says 21:35:02 mehdi: Times mainly, meeting place is probably fixed. 21:35:19 Ok, who's caring about the work plan and the negotiations? 21:35:20 I'll ask him for more details. 21:35:24 We can sort this out thru mail? We mostly know who wants to be there. 21:35:33 faw: ack 21:35:34 phil, I will take care of negotiating/mediating 21:35:39 Thanks 21:35:46 #action faw negotiates with zack 21:35:53 So I guess we should conclude the meeting? 21:36:00 and also "advertise it" 21:36:01 I can do that too... he's next my office 21:36:18 I would need 3 minutes for RN 21:36:19 just share the load :-) 21:36:24 but we can postpone that 21:36:41 which is mainly a "status" 21:36:44 #info mehdi, jcristau, luk, adsb, phil can probably make it; HE unsure; faw relying on oversee travel sponsorship 21:37:04 #info Maulkin cannot make it 21:37:04 faw: vorlon started working on that, right? 21:37:05 If it's just 3 minutes... I'd be inclined to get it done. 21:37:06 faw: do you know how much you'll need? 21:37:14 luk: Oh right, sorry. 21:37:15 phil: why did you ignore me? 21:37:19 mehdi, around USD 1000 21:37:24 aba: Because you didn't say anything. 21:37:30 faw: k, thanks 21:37:33 #info aba can probably make it, too. 21:37:42 He /me'd 21:37:43 do others need sponsorship? 21:37:45 phil: so is the topic #5 delayed for the next meeting? 21:37:46 23:32 * aba 21:37:51 #topic State of Release Notes 21:37:53 adsb: he did without a verb :-) 21:38:00 True :) 21:38:01 faw: make it quick :) 21:38:06 jcristau, yes. And Debian Women wants to help with upgrade-reports which probably vorlon will coordinate 21:38:29 mehdi: lets do that by mail 21:38:29 we are in a bad shape right now, but we should get things done as Franklin also told me he will have time on September 21:38:29 doko: or mail. 21:38:40 luk: ack 21:38:51 we need at least 4 weeks to get it ready. 2 weeks of string freeze, 1 week of fixes and final week for translations. 21:39:33 4 weeks starting from when? :P 21:39:36 jcristau, phil: well, waiting for an answer on python3, and on gcc-4.5 21:39:43 now, that's trick part :) 21:40:06 I would like to think that 4 weeks to get all changes in would be more than enough, that means: 2 months from now 21:40:15 Ok, so we have who working on that? You, vorlon, franklin? 21:40:31 We should get an announcement requesting upgrade testing out, too. I don't know if that's the part vorlon wanted to take care of. 21:40:56 He's mentioned that recently (on -doc) 21:40:56 (And triage of the upgrade-reports pseudo-package to get rid of older bugs not affecting our next and greatest release.) 21:41:03 \o/ 21:41:12 Actually, I would like to talk about a Release Team update on 7.september (30 days after freeze announcement), we could probably ask for upgrade tests at that point 21:41:27 phil, and yes, those are the 3 people involved until now 21:41:37 phil, and Simon is always around 21:41:56 Upgrade tests might possibly also be asked for through a Press Announcement... I guess we need to decide on the form of that. 21:42:11 Is testing-security a blocker for that? (Which is currently RC-blocked by missing source v3 support, too.) 21:42:26 doko: imo gcc-4.5 is a bit late, and would be quite a pain to revert. but that's being discussed on list already, and will get a decision there, so i'm not sure we need more here. 21:42:53 * aba waves good-night 21:43:18 Probably, otherwise we would have quite some problems of "not found" :) 21:43:37 #action vorlon is taking care of upgrade-reports 21:43:43 that's pretty much it for RN 21:44:08 how does the release update drafting work? 21:44:09 #info timeline: 4 weeks to get them ready, 2 weeks of string freeze, 1 week of fixes and final week for translations 21:44:34 I guess we can find one drafting them later. :) 21:44:52 So this concludes the meeting. Thank you all for attending. Sorry for overcommitting the time we had allocated to this. 21:44:56 #endmeeting