18:58:25 <jmw> #startmeeting
18:58:25 <MeetBot> Meeting started Sun Sep 14 18:58:25 2014 UTC.  The chair is jmw. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:58:25 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:58:29 <jmw> #lurk
18:58:39 <jmw> #meetingtopic Architecture Qualification
18:58:47 <jmw> #meetingname arch-qual
18:59:22 <jmw> by way of explanation, I offered to chair in place of adsb as he isn't very keen on such things
18:59:31 <jmw> release team: if you're present, please say hi
18:59:34 <aba> hi
18:59:35 <adsb> hi
18:59:37 <ivodd> hi
18:59:49 <jcristau> hi
18:59:59 <jmw> DSA: Mithrandir, are you happy to speak for dsa?
19:00:13 <weasel> go Mithrandir, go!
19:00:17 <Mithrandir> I am
19:00:23 <jmw> ah weasel, you can too :)
19:00:31 <Mithrandir> I do think we have a bunch of people to correct me if I turn out to be too silly
19:00:49 <jmw> porters: if you're present and available for questions, please say so and which port
19:01:24 <aurel32> hi, I am there for mips*, s390x, and ppc64el (if it applies to this meeting)
19:01:43 * zumbi is around (arm*)
19:01:49 <aba> we might need to re-ask that at inidividual ports if necessary
19:01:54 <jmw> yes, I will do
19:02:14 <jmw> I assume that's it
19:02:34 <jmw> other than that, feel free to be in the channel and follow along, but please refrain from chipping in
19:02:35 <aba> which order do we go?
19:02:39 <jmw> ok, let's start with the easy ones
19:02:45 <jmw> #topic amd64/i386
19:02:55 <Mithrandir> no concerns from DSA.
19:02:58 <jmw> are there any serious objections to keeping these ports in?
19:03:07 <ivodd> no
19:03:09 <adsb> nah
19:03:15 <pkern> hi
19:03:26 <jcristau> only a joke objection to the 32bit one.  so no.
19:03:30 <jmw> good
19:03:35 <weasel> is the security team represented?
19:03:38 <jmw> #agree amd64/i386 stay
19:03:53 <aba> btw, I think pkern, aurel32 and I also are here for buildd if necessary.
19:03:58 <jcristau> carnil: around?
19:03:58 <jmw> excellent
19:04:07 <jmw> next
19:04:12 <aurel32> i guess Q_ also for buildd
19:04:14 <aba> I think sparc is also easy btw
19:04:14 <jmw> #topic hurd-i386
19:04:24 <Mithrandir> no concerns from DSA.
19:04:33 <carnil> jcristau: sort of only, I was going to dissaper soon for today
19:04:55 <pkern> No DSA'ed buildds afaik?
19:05:00 <jmw> hurd-i386 is already marked 'no'; are there any really good reasons to change that?
19:05:00 <Mithrandir> as in, if we release hurd-i386, we can support it.  That might be a not-insignificant if, though.
19:05:02 <aba> well, that could be fixed easily
19:05:14 <aba> jmw: moment ...
19:05:17 <pkern> aba: And might raise DSA concerns. :P
19:05:22 <jcristau> carnil: ok, too bad.  thanks.
19:05:41 <jmw> https://release.debian.org/jessie/arch_qualify.html is the arch page I'm working from, by the way
19:05:41 <aba> jmw: we had a hard time the last two times to find any reason to keep it out from release, apart from "everyone knows it's too broken"
19:06:01 <aba> that's not convincing for me, so I think we should either have a good reason to keep it out, and add it.
19:06:07 <aba> of course, RMs might just ignore me :)
19:06:20 <aba> s,and,or
19:06:32 <jmw> adsb?
19:06:51 <adsb> I must admit I haven't looked at the status there for a while
19:06:56 <aba> we discussed about "keeps up", but that was mostly an wanna-build stats error
19:06:59 <pkern> I guess that'd require a list of hurd issues that'd suddenly be RC and all. Seems rather late.
19:07:00 <jmw> I note there is less than 80% build coverage for hurd
19:07:22 <aba> jmw: that's from the way stats are done
19:07:27 <jmw> aba: ok
19:07:39 <aba> if packages are db-uninst, they are not in the "not covered"-stats, but things depending on such packages are
19:07:59 <aba> "depending" = build-depending
19:08:22 <jmw> carnil: there is an concern for buildd-fast-sec on the arch page. do you have any thoughts there?
19:08:36 <aba> jmw: that's because theris currently not security buildd
19:08:40 <jmw> none at all? ok
19:08:49 <aba> actually hurd could easily have a fast one, as soon as it has DSAed buildds
19:08:55 <aba> jmw: security buildds are always DSAed
19:09:03 <aba> (because of access to embargoed queue)
19:09:08 <jmw> yes
19:09:28 <aba> pkern: we could e.g. decide to require such a list of things while adding it to testing (and the issues are not RC), and decide in $time to either drop them again, or make the issues RC.
19:09:28 <jcristau> i think the coverage is an issue...
19:09:30 <pkern> "easily" if hurd itself is "fast". (Just sayin'. My experience with the porterboxes was bad.)
19:09:45 <aba> pkern: last I looked at build times it wasn't that bad.
19:09:52 <pkern> Okay.
19:09:55 <Mithrandir> pkern: I suspect any DSA machines are a tad faster than the current porterboxes.
19:10:03 <pkern> I guess in the end it needs to run in Xen to be fast or something.
19:10:22 <aba> https://buildd.debian.org/status/logs.php?pkg=meanwhile that's a small package
19:10:27 <aba> but hurd isn't so bad here
19:10:40 <jmw> I also see only a handful of popcon returns for hurd, which I know is also not a foolproof method; our criteria is for >50 users
19:10:53 <pkern> So hurd is no longer the reason for many bugs still appearing on bugs.d.o because versions were out of date? ;)
19:10:55 <jmw> (depending on measurement, popcon says about 20)
19:11:11 <Mithrandir> jmw: (ooi) users or installations?
19:11:30 <jmw> Mithrandir: inst. vote is ~10
19:11:35 <jcristau> Mithrandir: users, if we want to keep s390x
19:11:37 <aba> pkern: it got a bit better.
19:11:49 <jmw> oh sorry, for the criteria? 50 users
19:11:59 <aba> (and it was always users, not installations, at least in the vancouver mail explecitly explained)
19:12:38 <aba> tbh, I'd have hoped a bit more active things from hurd porters in old versions cleanup and coverage, but I need to admit that things are better than I always thought.
19:12:49 <Mithrandir> ok, thanks.
19:13:34 <Mithrandir> what are the RM concerns listed?
19:14:01 <adsb> given our experience so far with !linux ports, I'm not convinced it's going to go well. having one as "tech-preview" for several releases is bad enough
19:14:35 <jmw> ok, we need to come to a decision. hurd is currently not in testing; personally I have concerns over archive coverage and user count.
19:14:46 <aba> so we should write the reaosns down
19:15:00 <aba> howeer, I think it would also be fair to add that things are better but not good enough then
19:15:09 <jmw> aba: I think that's a fair assessment
19:15:19 <adsb> we also still have 10 ports to go through
19:15:36 <aba> so we have archive coverage, user count, and the not optimal experience with !linux-ports
19:15:56 <aba> (and also that we miss a list of potential RC issues, and perhaps a bit more activity from the porters - but last please in a nice way)
19:16:03 <aba> is that all, or something else?
19:16:09 <ansgar> There was a removal request some time ago that hurd had (some) uploads done with disabled test suite.
19:16:36 <jmw> I want to move on. are there any serious objections to gently saying 'no' to hurd?
19:16:45 <aba> jcristau, adsb: ^ is that ok all?
19:16:53 <jcristau> yes, please move one
19:16:56 <jcristau> on
19:17:02 <aba> ansgar: that shouldn't happen. We perhaps should communicate that explicitly to the porters then (except if they already notied themselves)
19:17:09 <aba> jmw: sure, move on
19:17:17 <jmw> #info the hurd situation is improved, but not enough
19:17:26 <jmw> #agree hurd-i386 will not be a release architecture
19:17:33 <jmw> #topic sparc
19:17:36 <aba> dead.
19:17:37 <jcristau> rip.
19:17:39 <adsb> dead
19:17:42 <Mithrandir> bye, bye
19:17:48 <jmw> there are serious concerns still outstanding; I am marking this not releasable
19:17:56 <jmw> #agree sparc will not be a release architecture
19:18:00 <aba> (that seems to be easier then the one before)
19:18:14 <jmw> #topic armel/armhf
19:18:22 <Mithrandir> DSA has concerns.
19:18:28 <jmw> Mithrandir: I believe you have concerns here
19:18:33 <Mithrandir> Multiple, in fact.
19:18:49 <Mithrandir> low geographical redundancy, if we lose a DC, the rest is unable to keep up
19:19:06 <Mithrandir> actually, let me just cut and paste:
19:19:08 <Mithrandir> - Low geographical redunancy. If we lose a DC, the rest can't keep up.
19:19:10 <Mithrandir> - Poor remote manageability: Daisy-chaining of serial consoles and lack of remote power. Needs manual intervention to boot after power failure.
19:19:12 <Mithrandir> - some currently running non-debian.org kernels.  ick.
19:19:14 <Mithrandir> OK, assuming those concerns are addressed in full well before the release.
19:19:15 <aba> Mithrandir: we could still keep up with security if we lose a DC?
19:19:19 <jmw> #info DSA have multiple concerns
19:19:19 <Mithrandir> aba: yes.
19:19:23 <ansgar> aba: #749134
19:19:33 <Mithrandir> (I believe so)
19:19:36 <jcristau> Mithrandir: only if ancina isn't decommissioned
19:19:46 <weasel> ancina will go.
19:19:47 <aba> I think we need to make sure that at minimum
19:19:50 <jcristau> and even then i'm not sure
19:19:55 <aba> then I have a concern, sorry.
19:20:12 <Mithrandir> jcristau: as in, keep up with security only if ancina isn't decommissioned?
19:20:25 <jmw> Mithrandir: ancina is the only machine remote from the others, yes?
19:20:29 <aba> can we move one box elsewhere? because we should have geographic available security updates for anything in (old)stable.
19:20:30 <zumbi> ancina must be decomissied
19:20:38 <zumbi> decomissioned*
19:20:47 <aba> ansgar: thanks
19:20:48 <Mithrandir> we have armhf stuff at York
19:20:58 <aba> Mithrandir: ok, that could run armel chroots?
19:21:04 <Mithrandir> yes
19:21:08 <zumbi> ancina does not have upstream kernel support
19:21:09 <aba> so we could add security buildds there (in worst case)
19:21:10 <jmw> #info ancina is the only machine remote from the others, and due to be decommissioned
19:21:24 <Mithrandir> jmw: only remote armel
19:21:31 <jmw> #undo
19:21:33 <aba> so for armhf it is already ok, and for armel we could add new chroots in york
19:21:36 <aba> +?
19:21:37 <jmw> #info ancina is the only armel machine remote from the others, and due to be decommissioned
19:21:47 <Mithrandir> but we want to move to doing armel in a chroot anyway and armhf in the host system
19:21:50 <aba> then we should create an armel sec buildd in york if possible?
19:22:07 <aba> so this is something we could take care with our current hw.
19:22:24 <aba> we still have the issue of "if one DC fails, unstable can't keep up"
19:22:27 <aurel32> if there is a machine in york that can do armel/armhf, security is not really a concern
19:22:32 <aba> (which however IM'HO i sless relevant)
19:22:38 <weasel> (we have *two* MX53 hosts at ynic.  that's the total of non-arm-hosted armhf hw)
19:22:46 <aurel32> it's 15 minutes to do so, we are not going to discuss that for hours
19:22:47 <aba> aurel32: sure, but IMHO we should setup the chroot before we need it :)
19:22:58 <jmw> #info there are two armhf machines remote from the others, both at ynic
19:22:58 <aba> for security I think we can tick it ok
19:23:07 <aba> how for unstable?
19:23:15 <weasel> hahaha.
19:23:32 <aba> well, this question actually goes to the RMs, because they have to live with the fallout :)
19:23:48 <zumbi> unstable cannot keep up with only york machines
19:23:59 <aba> sure, but I also think it's not really that big a deal
19:24:01 <Mithrandir> AIUI, unstable suffered when york flooded.
19:24:13 <Mithrandir> aba: that's not your call, though.  You don't have to live with suffering machines.
19:24:16 <aba> because it only affcts unstable.
19:24:20 <zumbi> Mithrandir: note hardware has changed
19:24:35 <zumbi> (now it is faster, but only at ARM)
19:24:51 <Mithrandir> zumbi: right, so it'd probably be ok with flooded york, but not flooded arm.
19:25:16 <jmw> is ARM considered a risky location, or could we live with it?
19:25:18 <pkern> Has Arm itself been less reliable than the others? (connectivity, power, etc.)
19:25:22 <zumbi> right, sending some of the ARM machines somewhere else should fix the issue
19:25:25 <_rene_> aba: which then indirecly affects testing as stuff with bugfixes doesn't get built and block and... and that's more important than "just" unstable
19:25:51 <aba> _rene_: we could always ignore one arch at testin migration if necessary.
19:25:51 <Mithrandir> zumbi: no, it doesn't fix it, due to their poor remote management properties.
19:25:57 <zumbi> jmw: at worst case, ARM machines are quite common to setup buildd anywhere
19:26:03 <Mithrandir> we can't have random DC people go in and poke bare devboards.
19:26:38 <aba> so, conclusion?
19:26:42 <jmw> #info if ARM failed, the hardware there could be relocated
19:26:44 <Mithrandir> jmw: it's a bit painful for various admin-y reasons, but in terms of power etc, it's not terrible.  They do a fair bit of maintenance leading to outages.
19:26:51 <pkern> jmw: Could it be?
19:26:54 <aba> is this bad enough for DSA that we should remove it from testing?
19:27:08 <jcristau> jmw: that's not what i hear..
19:27:19 <jmw> #undo
19:27:23 <Mithrandir> jmw: not if the DC burns down.
19:27:28 <jmw> ok, zumbi was less concrete that I read
19:27:34 <Mithrandir> which, as some people might remember, has actually happened.
19:27:35 <jmw> Mithrandir: true.
19:27:55 <jmw> ok, is this a blocker for DSA?
19:28:20 <Mithrandir> yes
19:28:35 <Mithrandir> it was a half-blocker for wheezy, nothing got better, things were painful.
19:28:40 <Mithrandir> we would like the pain to stop.
19:29:01 <aba> is that the redundancy or the current dc?
19:29:03 <aba> or both?
19:29:03 <jmw> is there any scope to improve the situation between now and release? i.e. more hardware
19:29:25 <jmw> (carefully placed, geographically...)
19:29:38 <Mithrandir> I certainly believe an improvement is possible.  It's not like ARM lacks for engineering resources and we have hosting available for suitable hardware.
19:29:39 <zumbi> jmw: I believe so, porters will do as much as possible to fix it up
19:29:55 <Mithrandir> so I don't think the first move is to remove armel and armhf from testing..
19:29:58 <ivodd> can we give them a warning and a deadline?
19:29:58 <jmw> #info DSA did not see an improvement in the situation during the last cycle
19:30:17 <aba> ivodd: sounds good to me
19:30:22 <jmw> ok, I'd like somebody to liaise with ARM about additional hardware, please
19:30:24 <adsb> yeah
19:30:27 <jmw> meanwhile:
19:30:43 <jmw> #agree armel/armhf hardware situation is not a blocker at this stage, but the situation needs to improve before release
19:30:47 <jcristau> additional hw, or remote mgmt?
19:30:52 <jmw> jcristau: either, really
19:30:56 <aba> we also had RM concerns btw, are they gone?
19:30:56 <Mithrandir> jcristau: both.
19:31:02 <jmw> oh, sorry
19:31:03 <jcristau> right.
19:31:04 <jmw> RM concerns?
19:31:11 <aba> https://release.debian.org/jessie/arch_qualify.html says so
19:31:17 <Mithrandir> jmw: DSA can talk to them about that.  I don't know what form you want to communicate the result of this meeting, but they should probably know before it hits d-d-a or similar.
19:31:24 <ivodd> I think the concern was from before the hardware upgrades
19:31:25 <zumbi> no additional hardware, but geolocation redundancy
19:31:30 <aba> IIRC they were only a followup on DSA concerns, so probably we have done them now as well
19:31:49 <aba> but we should mark them as "done" somewhere
19:31:51 <adsb> the RM concerns were around up-to-dateness. which is related to hardware, yeah
19:31:58 <jcristau> that was before they changed the buildd hw
19:31:59 <aba> ok, so RM concerns done?
19:32:01 <Mithrandir> zumbi: we should be able to keep up with one lost DC.  If that just means shifting hw around + fixing it so it auto-boots and is nice to work with, great.
19:32:02 <aba> good.
19:32:10 <jmw> #action DSA liaise with ARM about hardware and remote management, best-effort
19:32:34 <aba> (should I update the arch-table, or does someone else want to?)
19:32:44 <jmw> Mithrandir: an off-the-record chat with Sledge might be a worthwhile starting point, he's a useful ally
19:32:51 <jmw> ok, I'm going to move on
19:32:59 <ivodd> as DSA considers this a blocker, we should make it clear that they can be dropped later on if the issues aren't fixed
19:33:07 <zumbi> Mithrandir: right, there is enough machines at ARM do send some out and still keep up (also those are faster)
19:33:10 <Mithrandir> jmw: absolutely.
19:33:10 <jmw> #topic kfreebsd-amd64/kfreebsd-i386
19:33:27 <jmw> we seem to have vague RM concerns for this one
19:33:41 <jcristau> not so vague
19:33:47 <jmw> jcristau: go
19:33:48 <jcristau> there's about 1 active porter
19:33:52 <jcristau> which is not enough
19:33:57 <Mithrandir> no DSA concerns for kfreebsd.
19:33:58 <adsb> it concerns me that the change causing #756464 was in testing for three months before anyone found it, and still isn't fixed
19:34:07 <jcristau> also that.
19:34:18 <adsb> well, s/found/reported/, but
19:34:19 <jmw> #info only one porter appears to be active
19:34:41 <jmw> #info RC bugs do not appear to be found quickly nor fixed in a suitable timeframe
19:34:44 <adsb> #750836 isn't great either, although I got the impression people were less concerned about that
19:35:13 <aba> I started to updae the web page
19:35:27 <jmw> I also see few (although >50) popcon returns for inst of the kernel v9, and they want to move to v10 relatively late in this cycle
19:35:54 <jmw> I really don't see it as a promising architecture at the moment, considering it must be maintained for the next 3 years
19:36:07 <adsb> it's been downgraded because it was worked around elsewhere, but the workaround in libpcap means disabling functionality that worked in wheezy. and I think the patch should be fairly trivial
19:36:19 <aba> for stable, do we have the concern thatit breaks in our hands while stable?
19:36:30 <aba> or that it doesn't survive the next cycle start?
19:36:48 <jmw> #752194 looks fairly nasty...
19:36:53 <adsb> well right now anyone upgrading from wheezy will have their machine break
19:37:13 <adsb> yeah, that's the one I mentioned earlier (merged?)
19:37:16 <jmw> praps
19:37:41 <jmw> it doesn't appear to have a response, either, since june
19:37:44 <pkern> KiBi also seemed concerned wrt installer breakage. (OTOH for full disclosure s390x is probably in a similar boat with very light testing.)
19:37:55 <jmw> yes, he did
19:37:59 <aba> in that case, perhaps we should also issue an warning, and say if they don't manage it in time we might need to remove them?
19:38:08 <jmw> are we generally of the opinion that this isn't release suitable?
19:38:16 <jmw> #info there appear to be significant unresolved upgrade problems
19:38:29 <adsb> as-is, I'm not convinced it's suitable
19:38:31 <jcristau> jmw: i am
19:38:36 <jmw> aba: we're weeks from freeze. I think it's too late for warnings
19:38:46 <aba> jmw: we just did one for arm*.
19:38:54 <aba> or do we believe thisone here is unsolvable?
19:39:23 <aba> (if it's unsolvable in that time, a warning doesn't make sense of course)
19:39:30 <jcristau> <20140818234006.GM1999@mraw.org> looks like a warning to me
19:39:46 <jmw> I don't see arm* as being a release problem, but a resources problem. this is a package quality problem
19:39:48 <aba> actually the kernel issue could probably be fixed with a transition package
19:40:07 <jmw> I'm going to move to remove kfreebsd* from the release list, today. objections?
19:40:13 <Mithrandir> the problem with a warning for "you're not enough people doing enough" is the usual response is "we'll try harder", which doesn't work.  The arm stuff is a one time change, not ongoing.
19:40:14 <aba> yes
19:40:18 <jmw> aba?
19:40:20 <aba> let me read the mai lplease
19:41:05 <aba> Mithrandir: sure, it only works if *additional* people come up
19:41:32 <aba> I personally think a final warning would be better, but if I'm the only one just go ahead
19:41:50 <aba> which still could lead to removing from next release of course
19:42:11 <adsb> I'm not convinced there's going to be any actual progress, as Mithrandir says
19:42:37 <jcristau> next?
19:42:40 <aba> as I said, if I'm the only one with that opinion, it#s ok to go ahead
19:42:43 <adsb> #756464 should have been trivial to spot
19:42:55 <jmw> #agree kfreebsd-amd64/kfreebsd-i386 will not be release architectures
19:43:07 <jmw> I really hope these things are working.. anyway.
19:43:22 <jmw> #topic mips/mipsel
19:43:24 <adsb> if anyone works hard enough to convince us quickly enough, most things are possible...
19:43:36 <jmw> I'm lumping these together, but they could be treated separately if anyone wishes it
19:43:45 <jcristau> they probably should be
19:43:48 <jmw> Mithrandir: dsa has concerns listed for this
19:43:58 <jmw> are they still present?
19:44:08 <Mithrandir> we do, I was late to the meeting, so maybe weasel could expand?
19:44:16 <Mithrandir> weasel: ^
19:44:17 <weasel> sure.
19:44:26 <Mithrandir> (thanks)
19:44:30 <weasel> for mips, we are unhappy with the HW we currently have.
19:44:38 <weasel> but new HW is in the pipeline.
19:45:00 <weasel> we're commissioning a new DC (AQL) in the UK that will host HW provided by imgtec.
19:45:09 <weasel> and that DC can then also host additional mipsel gear.
19:45:15 <aba> (for kbsd I added "too many unfixed RC bugs" as RM concerns)
19:45:43 <jmw> #info DSA has concerns, but they should be alleviated soon with a new datacentre and hardware
19:45:46 <weasel> so, while the current situation is probably not ok, we have faith it will improve significantly within the year.
19:45:50 <_rene_> and mips?
19:46:04 <aurel32> the new hardware is for mips
19:46:04 <_rene_> at least my feeling is that mips has a harder time to keep up than mipsel...
19:46:21 <adsb> right now, yes, but the new DC is hopefully going to resolve that
19:46:23 <weasel> _rene_: AQL is (at first) for mips.  it can *also* take mipsel gear.
19:46:25 <aurel32> yes mips is not really able to follow unstable, only on the medium term
19:46:35 <aba> we have a bitof new mipsel hw already, but mips not yet
19:46:43 <_rene_> ah, ok, I just saw the "mipsel gear"
19:46:45 <_rene_> nevermind :)
19:46:46 <KiBi> _rene_: that's correct
19:46:55 <weasel> that's it from DSA.
19:46:56 <KiBi> (mips (much) slower than mipsel)
19:47:01 <aurel32> the mips hardware is already there, but we are missing the infrastructure in the datacenter afaik
19:47:30 <aba> "have" was "in use as buildds" above
19:47:35 <jmw> ok, that sounds like it's going to be taken care of just fine. we also have RM concerns but they appear to be the same
19:47:40 <adsb> from #d-a earlier, that sounded about to get fixed though?
19:47:40 <jmw> are there any other points to be made?
19:47:59 <aba> I'd put the RMs concerns as "see DSA" then on the web page
19:48:07 <jmw> aba, please do that
19:48:27 <ivodd> we also should set a deadline (as we did with arm)
19:48:29 <adsb> they'll at least have the same resolution (or won't)
19:48:57 <jmw> weasel: how is the mips porterbox? will that be resolved with this new hardware too?
19:49:15 <aba> jmw: yes
19:49:23 <weasel> jmw: I expect us to throw out all the movidis machines at ubc, once we have a sufficient number of new mips hosts we like.
19:49:30 <jmw> ok
19:49:49 <jmw> so my feeling is that mips/mipsel are both ok, assuming this new hardware goes to plan
19:49:50 <weasel> (that might not happen within a month or two, but it should happen relatively soon)
19:49:59 <weasel> that's our impression, yes.
19:50:06 <jmw> we can presumably maintain the status quo for now without any deal-breakers
19:50:32 <jmw> #agree mips/mipsel will be release architectures
19:50:40 <jmw> #topic powerpc
19:50:57 <jmw> I don't have a lot of information about this one
19:50:59 <Mithrandir> no DSA concerns (yet)
19:51:08 <jmw> RMs?
19:51:25 <adsb> not that I know of
19:51:33 <Mithrandir> it's, like i386, an arch that's likely to be gone in not too long, but it's not problematic for us at this point.
19:51:39 <jmw> that works for me
19:51:45 <jmw> #agree powerpc will be a release architecture
19:51:50 <aba> (tbh, I think we'll slowly run out of 32bit-releases soon. but not this time)
19:51:54 <jmw> #topic s390x
19:51:54 <adsb> there's a "partial upstream support" note, but no expansion. but yeah, I suspect it'll hop along happily this time
19:52:09 <jmw> I also don't have much info for s390x, other than it replaced s390 and appears to be doing just fine
19:52:43 <Mithrandir> DSA: minor concern: rely on sponsors for HW and not being worked on.
19:52:55 <aba> Mithrandir: that's unchanged?
19:52:57 <aurel32> as a porter, my main concern is that we are dropping big-endian architectures slowly
19:52:58 <Mithrandir> yes
19:53:03 <Mithrandir> aba: ^
19:53:04 <pkern> Mithrandir: What's not being worked on?
19:53:30 <aba> Mithrandir: does it get worse (like on arm*), or is it just the same?
19:53:35 <Mithrandir> pkern: getting rid of the reliance of a single vendor sponsoring all our gear.
19:53:38 <pkern> I'm a bit concerned about s390x's state right now, but I don't have specifics. We recently had severe ABI breakage in unstable which might not yet be rectified completely.
19:53:43 <pkern> Mithrandir: Like ARM?
19:53:45 <aba> aurel32: yes, I also have that concern.
19:53:59 <Mithrandir> pkern: ARM gear is easy to buy.
19:54:03 <Mithrandir> s390x not so much
19:54:04 <aba> Mithrandir: I thought we had two different?
19:54:10 <aurel32> we got a 3rd hosting location in the meantime for s390x
19:54:12 <aba> or did my memory mix it up?
19:54:14 <jmw> #info DSA have concerns about a single source of hardware, sponsored, and it doesn't appear to be improving
19:54:20 <aba> aurel32: from there different companies?
19:54:26 <aba> s,there,three,
19:54:28 <Mithrandir> jmw: it's a mild concern though, not a blocker.
19:54:33 <jmw> Mithrandir, noted
19:54:34 <aurel32> note that we have 3 sponsors there for the machines
19:54:37 <adsb> do we actually expect to have any issues with the current sponsors?
19:54:42 <Mithrandir> adsb: no.
19:54:45 <adsb> k
19:54:49 <adsb> just checking
19:54:49 <aba> ok, then we are not depending on one company but there
19:54:53 <aba> but three.
19:54:56 <aba> (bad fingers)
19:55:04 <aba> I think that sounds ok-ish to me
19:55:05 <pkern> I think it's a tad unfair given that we went from 1 location to 3.
19:55:07 <aurel32> but only IBM produce such machines
19:55:26 <aba> Mithrandir: could we live with that we now have 3 locations?
19:55:48 <pkern> It's more important that unstable actually works. It'd probably make sense to give a deadline for confirmation that it actually works and warn.
19:56:03 <Mithrandir> yes, we can live with it.  If we couldn't, I'd not have said "mild concern"
19:56:09 <weasel> the s390 thing is just a mild/minor concern.  something to keep in mind.
19:56:10 <aba> ok, so we could go ahead
19:56:14 <aba> good.
19:56:15 <jmw> #info we do have redundant locations. DSA's concern is only mild
19:56:17 <weasel> it's not, by any means, a blocker at this time.
19:56:23 <pkern> Once s390x is in stable it likely does not break again.
19:56:44 <jmw> ok, I move that it's releasable unless there are deal-breakers during freeze. objections?
19:56:45 <aba> ok, so I think we agree and could go to the next ones
19:57:13 <jmw> I hear no objections :)
19:57:14 <jmw> #agree s390x will be a release architecture
19:57:37 <jmw> now, new architectures. I realise feelings may be strong here, please try not to flood the channel
19:57:53 <aba> which one first?
19:57:59 <aba> ppc64el is IMHO releaseable
19:58:09 <jmw> let's start with arm64, since it appears (to me) less progressed than ppc64el, so we may be able to carry some decision to the latter
19:58:12 <jmw> #topic arm64
19:58:14 <aba> (but we need to make the minor details like buildds etc)
19:58:16 <jmw> #info arm64 is a new port
19:58:30 <jmw> Mithrandir, weasel ?
19:58:35 <Mithrandir> multiple concerns:
19:58:40 <jmw> I thought so :)
19:58:52 <Mithrandir> - Expensive hardware, so hard to replace if it breaks
19:59:11 <Mithrandir> - No porterbox due to silly no-iran-nk-cuba requirements.  Being worked on by ARM lawyers
19:59:28 <Mithrandir> - existing hosts have very poor managability (e.g. no remote power/reset; no oob management; no remote reinstall)
19:59:33 <Mithrandir> - no location redundancy
19:59:40 <aba> Mithrandir: aren't the first two expected to be fixed in 6-12 months when hw is more common?
19:59:49 <aba> (and the others are same as armhf/le?)
19:59:55 <jcristau> in 6-12 months is post release
19:59:57 <jmw> #info DSA have multiple concerns; hardware availability, management of existing hosts, no geographic redundancy
20:00:04 <jmw> 6-12 months is a long time away
20:00:04 <jcristau> i don't think that's ok
20:00:07 <aba> jcristau: not doubting about that
20:00:09 <Mithrandir> aba: we have _no_ location redunancy for arm64
20:00:11 <jcristau> it's also very much up in the air
20:00:23 <aba> Mithrandir: sure, that sounds to me like "not yet"
20:00:48 <Mithrandir> we're ok with the port if those points are addressed in full well before the release.
20:01:01 <pkern> i.e. now
20:01:09 <aba> well, or in a fortnight
20:01:25 <Mithrandir> I've only heard a freeze date, not a suggested freeze length, so that is hard to comment on
20:01:40 <jcristau> the boostrap is also nowhere near done afaict?
20:01:42 <jmw> suffice to say we do not wish the freeze to drag
20:01:57 <ivodd> dropping a port isn't hard to do
20:01:58 <aba> jcristau: IMHO lacks mostly build power, until it's worse than ppc64el
20:02:04 <jmw> we have set agressive internal targets
20:02:07 <Mithrandir> jcristau: AIUI, that's correct.  That's not really a DSA concern, though.
20:02:26 <adsb> there's 87 !debian packages right now
20:02:27 <jcristau> Mithrandir: sure
20:02:32 <Mithrandir> (but absolutely on-topic for the meeting. :-)
20:02:49 <jcristau> aba: i don't care why it's not done
20:02:50 <jcristau> but we
20:03:09 <aba> jcristau: that wasn't an excuse but an explanaition
20:03:12 <jcristau> 're close to freeze and the arch isn't bootstraped in sid, i think that's relevant for arch qual
20:03:28 <aba> jcristau: so you'd say "no"
20:03:30 <aba> +?
20:03:33 <aba> (just to be clear)
20:03:39 <jmw> I do think it's difficult for us to be strict with other ports while giving arm64 a free license
20:03:43 <jcristau> at this point, yes
20:03:50 <aba> anyone here for "yes, it should be in"?
20:03:54 <jmw> it's not in good shape by any of our criteria, though it does have committed porters
20:04:02 <aurel32> arm porters maybe?
20:04:12 <aba> zumbi: ?
20:04:12 <aurel32> that would be interesting to have comments from them
20:04:24 <_rene_> I'd agree with this, but then we should keep armh at least (don't mind about armel, except maybe raspberry people), I don't think we should drop arm completely :)
20:04:26 * weasel would like to see both arm64 and ppc64el in.
20:04:32 <_rene_> armhf
20:04:32 <adsb> it's been making good progress, at least, just not there yet aiui
20:04:41 <aba> _rene_: I don't think we want to drop armhf/le
20:04:44 <adsb> I believe Sledge is travelling right now
20:04:48 <jmw> he is
20:04:50 <Mithrandir> yes, the level of commitment from arm64 porters is good.
20:05:08 <ivodd> we could maybe delay the decision, but not by much
20:05:26 <aba> actually if we add a new arch to testing, we should do it for all at the same time
20:05:33 <jcristau> i'm not going to stop anyone adding it to testing and see what it looks like in a month, but it's clearly not in good shape now.
20:05:42 <zumbi> aba: well, I have no clear word I can say about arm64, it is just too new, but it should improve over time
20:05:42 <aba> i.e. in case we add ppc64el, then we should add arm64 the same time
20:05:47 <jmw> #info the port is not yet bootstrapped into sid
20:05:58 <adsb> jcristau: that was a thought I was having, yes
20:06:02 <aba> (of course as jcristau said we still could drop it later)
20:06:21 <Mithrandir> there's nothing stopping them from tracking testing and doing a jessie-arm64-unoff.
20:06:28 <jcristau> Mithrandir: absolutely
20:06:35 <Mithrandir> like we did for the first iteration of amd64, back in the day.
20:06:52 <aba> so we have strong DSA concerns, not bootstraped into sid yet, but consider to add it now to give them time to fix that (or be dropped again before release)?
20:06:56 <jmw> are we looking at technology preview then?
20:07:05 <aba> I don't think so
20:07:10 <weasel> "technology preview" doesn't mean anything.
20:07:19 <aba> debian on linux is something we quite experienced
20:07:27 <ivodd> and it has to be ok or it will be dropped
20:07:34 <adsb> yeah, it's "just" another port there
20:07:48 <aba> I have as: concerns-rm: "not fully bootstrapped into sid yet"
20:07:51 <jmw> do we have any way of knowing how successful a testing migration might be for these ports if we tried it right now?
20:07:59 <jmw> s/migration/bootstrap
20:08:04 <aba> jmw: you mean testing sourcing?
20:08:18 <aba> should be possible given enough buildd power (uh) plus a bit of time
20:08:26 <aba> but freeze makes it easier not harder
20:08:37 <aba> (I have done it before, and I could do it again)
20:08:57 <jmw> I'd be open to trying it very soon, and making a better informed decision in a couple of weeks time. but I don't know if that's really feasible
20:09:15 <adsb> I forget the details of how we did the bootstrap last time. I know nthykier believes britney should be able to do it unaided, but I don't think you can without either a quite chunky initial force-hint or a by-hand import of a set of initial packages
20:09:32 <aba> adsb: nah, just set it to break+fucked, and let britney do the rest
20:09:45 <aba> and then binNMU special packages in testing
20:09:59 <aba> (at least that's how we did armel plus kbsds)
20:10:08 * jcristau thinks this is off topic
20:10:15 * aba agrees
20:10:16 <adsb> yeah, sorry
20:10:30 <jmw> if it's feasible in principle, I'd welcome volunteers to try it and report back
20:10:48 <jmw> and meanwhile we can record a 'release arch in principle, assuming successful' in the minutes
20:10:57 <aba> jmw: if it (plus ppc64el) is in testing, I'd take a look
20:11:01 <jmw> aba, thanks
20:11:01 <Mithrandir> and assuming DSA concerns addressed?
20:11:20 <ivodd> Mithrandir: obviously
20:11:20 <jcristau> the lack of porterbox is a non-starter for release imo
20:11:26 <jmw> Mithrandir: is the blocker currently all lawyer-based?
20:11:30 <aba> Mithrandir: I put that as "strong" on the web page
20:11:46 <aba> jmw: the other half was same as the other arms
20:11:49 <jmw> #action aba to try a testing bootstrap of arm64 and ppc64el
20:11:52 <Mithrandir> jcristau: it might be that the porters are able to get ARM to pony up more HW if they point out that they're at a real risk of missing the train.
20:11:57 <Mithrandir> it can go either way.
20:12:00 <aba> jmw: only if it's really in testing of course
20:12:00 <weasel> aba: location redundancy is Strong too.
20:12:09 <jmw> aba, ok
20:12:12 <aba> weasel: I put all DSA comments as storng
20:12:15 <aba> (for the web page)
20:12:23 <weasel> (good.  they are.)
20:12:28 <jmw> the DSA concerns for arm64 do worry me
20:13:04 <aba> weasel, Mithrandir: anything we need to explicitly minute so that we could go ahead?
20:13:11 <jmw> I'd like to get a yes/no for the port tonight, but I fear that may not be realistic
20:13:30 <aba> jmw: it's a "we try it out, but might need to drop it again" I think
20:13:37 <Mithrandir> that WFM.
20:13:38 <jmw> aba, agreed
20:13:44 <aba> (and the drop could happen prior to the release)
20:13:52 <adsb> yeah. we should have tried it before tbh :( (and yes, I know it was suggested previously)
20:14:03 <aba> sorryfor doing so
20:14:04 <jmw> the drop will probably end up being during freeze, I don't think we'll get a resolution before then
20:14:57 <jmw> #agree arm64 is a release architecture in principle, providing a testing bootstrap is successful and DSA's hardware concerns can be alleviated. if there are significant problems, the architecture may be dropped before release
20:15:05 <jmw> #topic ppc64el
20:15:13 <aba> arm64 for website: candidate: "only if issues are fully resolved prior to release"
20:15:16 <Mithrandir> we need to be very clear about what needs to be done by when to not have some very disappointed porters for arm64 then
20:15:25 <adsb> ack
20:15:42 <Mithrandir> DSA: two concerns from DSA, one mild: relying on sponsors for HW, like for s390x
20:15:43 <aba> definiltly
20:15:49 <Mithrandir> mild concern, not a blocker
20:15:56 <aba> ^ definitly = arm64
20:15:56 <jmw> #info mild DSA concern about hardware, not a blocker
20:16:10 <Mithrandir> The other is a single DC location only
20:16:21 <Mithrandir> this is being worked on and seems to be making good progress.
20:16:22 <aba> Mithrandir: the current VMs are at two different DCs
20:16:23 <ivodd> Mithrandir: there is a second (non-dsa) buildd now
20:16:31 <weasel> aba: not the debian.org owned ones
20:16:41 <aba> weasel: sure, we need to move to DSAed ones
20:16:53 <jmw> Mithrandir: are you confident the single DC location will be resolved?
20:16:54 <weasel> but leitao is actively working on getting us a power8/power7+ box at OSL.
20:17:02 <jmw> or weasel
20:17:12 <aurel32> the shipping to OSUOSL should happen soon
20:17:16 <jmw> excellent
20:17:17 <adsb> presumably at some point there'll be a DSAed porter box too
20:17:17 <weasel> yes.  it's being worked on and it should happen soonish.
20:17:28 <aurel32> the last mails i have seen are about the address / phone number
20:17:34 <jmw> #info DSA concerns about hardware location are expected to be resolved imminently
20:17:37 <Mithrandir> yes, I'm confident it'll happen.  They seemed very on the ball at debconf.
20:17:44 <weasel> adsb: yes.  mainly blocking on being installable, and ideally being in testing :)
20:17:46 <aurel32> also we still have the offer about IBM in France or possibly in Canada
20:17:54 <aurel32> but that would mean yet another location
20:18:01 <jmw> the port coverage seems to be very promising. are there RM concerns apart from bootstrapping testing?
20:18:07 <aba> for the web page that is now: concerns-dsa: "rely on sponsors for hardware (mild concern); no geo-redundancy (strong, being worked on)
20:18:11 <Mithrandir> I need to go now, since I have a plane to catch tomorrow morning, but I'm sure weasel can speak up if there are more DSA input.
20:18:11 <adsb> weasel: ppft :)
20:18:19 <aba> Mithrandir: good flight
20:18:21 <adsb> jmw: not from me
20:18:32 <jmw> Mithrandir: thanks for your input
20:18:34 <Mithrandir> I shall be toasting from the town of London tomorrow.
20:19:06 <aba> (of course we also need a DSAed porter box etc, but well.)
20:19:19 <jmw> are there any objections to a similar ok-in-principle for ppc64el?
20:19:39 <aba> I think it's more obvious here what we want
20:19:50 <aba> just the geo-redundancy needs to be resolved
20:19:54 <adsb> wfm (and has more chance of getting the concerns fixed, I suspect)
20:20:21 <jmw> #agree ppc64el is a release architecture in principle, providing a testing bootstrap is successful and DSA's hardware concerns can be alleviated. if there are significant problems, the architecture may be dropped before release
20:20:23 <adsb> there's also only 3 non-bootstrapped packages remaining on ppc64el
20:20:26 <aba> for website:     candidate: "yes (if geo-redundancy is ok)"
20:20:38 <aba> adsb: one of them cant build on any arch (openldap)
20:20:39 <jmw> yes, the port is much better progressed than arm64
20:20:46 <aurel32> adsb: unfortunately for the last 3, it's on any arch
20:20:49 <jmw> ok, I think we've covered all arches. did I miss any?
20:20:53 <aba> the othertwo are rc buggy because they're rejected by ftp-master
20:21:01 <aba> due to newer packages taken over binary packages
20:21:05 * jcristau heads to bed
20:21:07 <jcristau> good night
20:21:12 <aba> jcristau: good night
20:21:13 <jmw> jcristau: thanks, and good night
20:21:13 <adsb> aurel32: aba: thanks for the information
20:21:18 <adsb> jcristau: o/
20:21:22 <aurel32> yes, openjpeg is a huge mess
20:21:25 <adsb> jmw: I think we're done
20:21:30 <aba> jmw: I'd like to also add mips64el but that was too slow for now :)
20:21:36 <jmw> #unlurk
20:21:42 <jmw> thanks everybody for your input
20:21:43 <aba> (and I think it's better to resolve the mipsel issues first)
20:21:46 <jmw> #endmeeting