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