18:59:21 <nthykier> #startmeeting
18:59:21 <MeetBot> Meeting started Wed Feb 24 18:59:21 2016 UTC.  The chair is nthykier. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:21 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:26 <nthykier> #chair jmw
18:59:26 <MeetBot> Current chairs: jmw nthykier
18:59:31 <jmw> I pushed it down the list a bit to try and give the others some chances of a discussion...
18:59:38 <pochu> o/
18:59:40 <nthykier> woohoo, it works when you spell the command right!
18:59:42 <jcristau> (i need to cook dinner, might not be around much)
18:59:45 <jmw> nthykier: :D
18:59:46 <nthykier> #chair pochu
18:59:46 <MeetBot> Current chairs: jmw nthykier pochu
18:59:52 <nthykier> #chair adsb
18:59:52 <MeetBot> Current chairs: adsb jmw nthykier pochu
18:59:57 <nthykier> #chair ivodd
18:59:57 <MeetBot> Current chairs: adsb ivodd jmw nthykier pochu
18:59:58 <nthykier> #chair
18:59:58 <MeetBot> Current chairs: adsb ivodd jmw nthykier pochu
19:00:03 <nthykier> #chair mehdi
19:00:03 <MeetBot> Current chairs: adsb ivodd jmw mehdi nthykier pochu
19:00:06 <nthykier> There
19:00:11 <nthykier> #chair jcristau
19:00:11 <MeetBot> Current chairs: adsb ivodd jcristau jmw mehdi nthykier pochu
19:00:18 <jmw> all teh peoples
19:00:25 <nthykier> indeed
19:00:30 <jmw> shall I lead or leave it to you?
19:00:33 <nthykier> Go
19:00:39 <nthykier> just do it in the original order
19:00:48 <jmw> righto
19:00:54 <jmw> #topic Apologies/Admin
19:01:03 <jmw> I am not aware of any apologies in advance
19:01:10 <jmw> last minutes were published
19:01:37 <jmw> does the time of this meeting suit people? someone (pochu?) would find it better tuesday, but I'm normally out
19:01:53 <jmw> alternatively it could be during the day, but I guess there would be employment trouble
19:02:00 <pochu> right
19:02:12 <nthykier> At this time of day, any week day works for me in general
19:02:19 <pochu> hard to fine a time slot that suits everyone ;)
19:02:33 <jmw> it is
19:02:46 <jmw> unless there are any great ideas right now, I suggest keeping the status quo
19:02:53 <pochu> sure, no worries then. let's leave it as is
19:02:58 <jmw> ok
19:03:06 <jmw> #topic Transitions
19:03:12 <jmw> this is just a status check
19:03:25 <jmw> I don't have any concerns over any (though as usual pochu is doing most of the work here)
19:03:41 <pochu> no big issues there
19:03:43 <nthykier> Me neither - kudos to pochu !
19:03:53 <jmw> ok moving straight on then
19:03:54 <pochu> I'm waiting on openmpi to finish before starting libpng (finally!)
19:03:57 <jmw> (see this is how it's supposed to work :) )
19:04:05 <pochu> openmpi got an RC bug, but that's about it
19:04:10 <nthykier> #info No major issues with transitions at this time.
19:04:17 <pochu> that's all :)
19:04:24 <pochu> oh
19:04:37 <pochu> any objections wrt me closing the libstdc++ transition bug?
19:04:37 <jmw> #topic Reproducible builds: rebuild before release
19:04:44 <jmw> pochu: oh, no objections
19:04:53 <pochu> I think that's done and we can close it
19:05:02 <nthykier> pochu: go ahead and close it
19:05:18 <pochu> cool ta
19:05:27 <jmw> we errored by not making that an action last time
19:05:44 <jmw> right, rebuilds
19:05:58 <jmw> this stems from a query at the minidebconf cambridge, summary:
19:06:15 <jmw> https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20151102/003828.html
19:07:07 <jcristau> -1 from me fwiw
19:07:13 <pochu> what's the question there?
19:07:38 <nthykier> make Stretch self-contained by mass rebuild AAICT
19:07:41 <nthykier> AFAICT*
19:07:43 <jcristau> pochu: aiui they want us to rebuild the world a month before release
19:07:50 <jmw> the question is can the reproducible builds team have a rebuild of the archive (possibly only one arch) before release to get .buildinfo files
19:08:03 <jmw> I wonder if h01ger is around
19:08:15 <nthykier> well, due to M-A: same, it would have to be more than one arch in practise
19:08:35 <jmw> #info Multi-arch would mean rebuilding all architectures
19:08:47 <nthykier> also, arch:all are not binNMU-able, so arch:all packages would not be rebuilt with our current setup
19:09:01 <jmw> #info arch:all packages could not be rebuilt
19:09:04 <pochu> is the only goal to get .buildinfo ?
19:09:43 <nthykier> Quote: "Self contained reproducibility should be the goal…"
19:10:33 <nthykier> Personally, I like the idea and the goal, but...
19:10:35 <jmw> pochu: that's a primary aim, yes. then users of stretch would be able to rebuild and check that nothing nasty happened
19:11:01 <nthykier> A) I have a concern that we do not have the resources to do it (buildds).  This can probably be fixed
19:11:25 <nthykier> B) I do not think it makes sense, if all arch:all packages fall through or have to be manually re-uploaded
19:11:25 <jcristau> i don't think that's a realistic goal.  it won't be true for anything with a build-depends loop anyway.
19:12:04 <jcristau> (the self-contained bit)
19:12:12 <nthykier> Yeah, Build-Dependency loops would need a break as well
19:12:25 <jmw> #info Build-Depends loops would need sorting out by hand
19:12:40 <jmw> this is starting to sound like a re-bootstrap for some or all arches
19:13:15 <nthykier> Technically, a dependency loop is not a deal breaker provided the results to not change (a la fixed point computation)
19:13:43 <nthykier> But that assumes the packages are not capturing version numbers from one another
19:13:49 <nthykier> anyway, I digress
19:14:20 <jmw> I wonder if a lintian thing would be a good start for this, so that a) the momentum starts and b) it's easier to assess the scale of the problem later on?
19:14:33 <jmw> (maybe it already is)
19:14:36 <jcristau> well, no
19:14:39 <nthykier> I do not think lintian can test anythin useful here
19:14:48 <jcristau> does the archive even accept buildinfo files yet?
19:14:57 <nthykier> jcristau: It accepts them and discards them
19:15:26 * adsb vaguely waves (work+roadworks+life==fail)
19:15:44 <nthykier> It was added to enable dpkg to create them now while the buildinfo support is expanded in dak
19:16:22 <jcristau> ok, so i stand by my -1 for now :)
19:16:30 <jmw> maybe we should register our concerns, and await dak developments for now then?
19:16:44 <nthykier> jmw: wfm
19:17:03 <nthykier> Can you give me an action on that?
19:17:08 <jmw> #agree Right now, a full rebuild would not be feasible
19:17:23 <jmw> sure
19:17:37 <jcristau> adsb: _o/
19:18:00 <jmw> #agree We should await developments in dak so we know what support will be like in Stretch
19:18:21 <jmw> nthykier: go ahead and set an action that says what you want it to :)
19:18:41 <nthykier> #action nthykier to voice concerns to the reproducible team
19:18:45 <nthykier> there
19:18:54 <jmw> wfm
19:18:57 <jmw> moving on?
19:19:11 <nthykier> ok for me
19:19:21 <jmw> #topic mips64el
19:19:31 <jmw> ah, now, I don't know how put this on the agenda or what they wanted to discuss
19:19:38 <jmw> so, um...
19:19:44 <jcristau> moving on? :)
19:19:46 <adsb> not guilty
19:19:50 <jmw> unless anyone else knows
19:19:56 <nthykier> pochu: ^?
19:20:21 <nthykier> It looks like his color (but it might be from a previous session)
19:20:24 <jmw> yeh
19:20:46 <jmw> #info not clear who wanted to discuss what - defer until next time
19:21:02 <jmw> #topic Linux version in Stretch
19:21:06 <pochu> yeah that was me :)
19:21:21 <pochu> (let's do linux first if you want)
19:21:39 <jmw> #undo
19:21:39 <MeetBot> Removing item from minutes: <MeetBot.items.Topic object at 0x112ff50>
19:21:46 <jmw> #undo
19:21:46 <MeetBot> Removing item from minutes: <MeetBot.items.Info object at 0x112f310>
19:21:49 <jmw> winner
19:21:50 <jmw> pochu: go
19:21:51 <adsb> nice message
19:21:56 <pochu> hehe
19:22:30 <pochu> so mips64el is on ftpmaster since a while... so I was just wondering whether there are plans to release Stretch with mips64el, and if so, if we should add it to testing already - and if not, then when
19:22:53 <pochu> who's behind the port, whether we have buildd redundancy, etc
19:22:54 <ansgar> I would like to see the last package that was imported to be rebuilt before it is in testing: https://ftp-master.debian.org/users/mhy/mipsel64import.txt
19:23:48 <ansgar> Besides that I guess it's up to aurel32 and other people behind the port?
19:23:51 <jmw> #info mips64el is available in sid, and could join testing
19:24:24 <jmw> https://wiki.debian.org/ArchiveQualification/mips64el is helpful perhaps?
19:24:43 <nthykier> Nothing listed in https://release.debian.org/stretch/arch_qualify.html btw
19:24:52 <nthykier> ah
19:25:06 <jmw> ansgar: is that an ftp-masters position or your own only?
19:25:29 <nthykier> jmw: standard proceedure as I recall
19:25:36 <mehdi> indeed
19:25:43 <jmw> #info imported packages should be rebuilt first
19:25:43 <ansgar> jmw: At least mine. And given it's only one package remaining... :)
19:25:59 <pochu> who's behind mips64el?
19:26:01 <nthykier> jmw: We usually do not bootstrap architectures in testing until they have finished their "self-containedness rebuild"
19:26:04 <jmw> if it's only one, does anyone fancy an action?
19:26:15 <nthykier> pochu: Alleedly https://wiki.debian.org/mips64el#Development_Team
19:26:15 <pochu> so we can look for a victim :p
19:26:15 <jcristau> jmw: up to the porters imo
19:26:37 <pochu> yes, that's for the porters (so we can at least see there is interest...)
19:26:51 <jmw> will someone contact the porters and see what the current plan is?
19:27:17 <pochu> I can do that
19:27:22 <pochu> if you give me an action :)
19:27:28 <jmw> oh that page of people is slightly out of date, james cowgill just became a DD
19:27:47 <jmw> #action pochu contact the mips64el ports and ask about a) plans b) whether they want to join Stretch
19:28:06 <adsb> only yesterday afair :P
19:28:15 <jmw> indeed
19:28:39 <nthykier> mips64el done?
19:28:44 <pochu> jmw: can you add an action to add mips64el to arch_qualify.html?
19:28:53 <jmw> pochu: for you?
19:29:00 <pochu> jmw: sure
19:29:01 <jmw> (I updated the page)
19:29:10 <jmw> #action pochu add mips64el to arch_qualify.html
19:29:11 <jmw> .
19:29:18 <pochu> and done yeah
19:29:21 <jmw> done
19:29:39 <jmw> hmm lost my page
19:29:45 <jmw> ah yes
19:29:52 <jmw> #topic Linux version in Stretch
19:29:56 <jmw> so we have a scheduling problem
19:30:08 <nthykier> Indeed
19:30:44 <jmw> can someone summarise the clash better than I can?
19:30:51 <nthykier> yupe
19:30:54 <jmw> ta
19:31:20 <nthykier> The Linux kernel maintainers want to include Linux 4.10 in Stretch, which is expected to be released in January 2017 (or maybe early Feb)
19:31:25 <jmw> (I presume that means you're going to and not just that you think someone can do it better than I :) )
19:32:29 <nthykier> The "deep" freeze is set at 5th of December 2016, so if we commit to Linux 4.10 we commit to at least 2 months of deep freeze plus an upstream release of linux in the deep freeze
19:33:10 <nthykier> The reasons from the kernel maintainers are (among others) that we would align ourselves with the upstream kernel LTS, so Ben does not have to support 3 kernel LTSs at the same time
19:33:19 <jcristau> i'd vote for moving the freeze back 2 months
19:33:48 <nthykier> As in 5th of Feb and commit to accepting Linux 4.10?
19:33:49 <adsb> and ignore the world and his dog who want us to move it to somewhere slightly different because their pet thing
19:34:45 <jmw> I must say I'd normally want 4.10 and the extended maintenance, and moving the freeze does seem the least troublesome way of getting that
19:34:51 <pochu> adsb++
19:34:55 <nthykier> FTR, I am (also?) in favour of moving the freeze by ~2 months (all milestones) and commiting to Linux 4.10
19:35:05 <jmw> and assuming the kernel sticks to this pattern, that sets us up nicely for future freezes as well
19:35:12 <nthykier> Indeed
19:35:13 <mehdi> looks like we all agree then. easy topic.
19:35:15 <pochu> about the freeze, can't we not move it but accept linux at that point?
19:35:20 <nthykier> that assumption is likely to be true
19:35:29 <jcristau> nthykier: i thought it was nov -> jan
19:35:40 <adsb> counting is hard
19:35:45 <jmw> pochu: the trouble with that a new upstream is unlikely to be instant, which makes the freeze long and everybody grumpy
19:35:46 <nthykier> jcristau: Depends on what milestone you consider the "deep freeze"
19:35:47 <pochu> my "worry" is that we'll move it to Jan/Feb, and then the freeze will last till May/June :p
19:35:52 <nthykier> Nov 5th is the "new freeze"
19:36:04 <nthykier> (ie. no new packages in testing without manual approval)
19:36:24 <jmw> ok to clarify, are we talking about moving the deep freeze (5th dec) or the start (5th  nov)?
19:36:57 <nthykier> If we move the freeze, I presume we will move all milestone dates
19:37:55 <nthykier> For reference, I stand by moving all milestone dates by 2 months
19:38:18 <mehdi> easier to explain and more coherent to move all dates
19:38:38 <nthykier> That is: Transition freeze goes from Oct 5th to Dec 5th, "new freeze" moves from 5th Nov to 5th of Jan and "deep freeze" goes from Dec 5 to Feb 5th
19:39:39 <jmw> that seems sensible to me
19:39:57 <jmw> there's potential for the kernel to be not ready until early february though
19:40:15 <jmw> should it just have an exception?
19:40:42 <nthykier> Personally, I would like them to do release candidates up til, so we weed out the bugs early
19:40:59 <jmw> certainly
19:41:14 <nthykier> and then have an exception - Linux is one of the packages we already have an exception for to some extend as I recall
19:41:35 <nthykier> (I think we accept new LTS point releases in stable)
19:42:30 <nthykier> SRMs ^?
19:43:06 <mehdi> if 4.10 is not ready, is it acceptable to go with an rcX version and integrate final release later? (I guess question to kernel maintainers too)
19:43:07 <ansgar> Well, if we don't accept new LTS releases, using a LTS branch loses its point?
19:43:15 <adsb> we accept what ben uploads :) which basically translates to upstream stable releases of whichever tree we're following
19:44:00 <jmw> #agree We want Linux 4.10 in Stretch if possible to reduce the maintenance burden in (old)stable
19:44:13 <nthykier> mehdi: I think we should decide that in the freeze if it becomes a problem
19:44:30 <mehdi> nthykier: wfm.
19:44:39 <jmw> yes, we shouldn't try to guess what might happen after freeze but deal with it when we know
19:44:46 <nthykier> Do we also agree on the "pre-release of linux during freeze"?
19:44:55 <pochu> to sid? or to exp?
19:44:57 <nthykier> sid
19:45:18 <pochu> if the linux maintainers are comfortable with that, sure
19:45:46 <pochu> (so maybe rc1 / rc2 to exp, then rc3 through final to sid)
19:45:50 <jmw> I think that's up to them to decide how they want to approach it, but it would be good to have some previews yes
19:45:55 <pochu> I wouldn't want to ask them to upload rc1 to sid, tbh
19:46:03 <pochu> right
19:46:31 <jmw> are nthykier's proposed dates agreed? to recap:
19:46:38 <jmw> <nthykier> That is: Transition freeze goes from Oct 5th to Dec 5th, "new freeze" moves from 5th Nov to 5th of Jan and "deep freeze" goes from Dec 5 to Feb 5th
19:46:52 <nthykier> wfm (obviously?)
19:46:57 <jmw> :)
19:47:02 <mehdi> "happy new year freeze" :)
19:47:05 <jmw> it wfm too
19:47:10 <mehdi> wfm too
19:47:49 <jmw> it worked for jcristau too, and I don't think adsb objects, so let's go for it
19:47:57 <adsb> sure
19:48:06 <jmw> #agree Stretch freeze will be delayed by two calendar months
19:48:09 <nthykier> \o/
19:48:23 <nthykier> I think that calls for a bits to d-d-a
19:48:35 <jmw> #agree Linux 4.10 will get an automatic freeze exception if it doesn't make the deep freeze
19:49:10 <jmw> #info For the avoidance of doubt, this policy applies only to linux
19:49:12 <mehdi> can we add that point (d-d-a mails) to the agenda?
19:49:27 <jmw> mehdi: agenda or minutes?
19:50:10 <mehdi> jmw: I want to propose that we make a mail to d-d-a after every meeting. so that's not specifically related to the current topic.
19:50:28 <jmw> mehdi: one moment then
19:51:03 <jmw> #agree Linux maintainers are encouraged to upload release candidates of 4.10 in sid to shake out bugs earlier
19:51:10 <jmw> anything else before we move on?
19:51:45 <jmw> mehdi: let's come back to it if that's ok, we have the elephant in the room still to get through
19:52:02 <nthykier> ok to moving on
19:52:13 <mehdi> jmw: sure :)
19:52:21 <jmw> #topic MySQL variants in Stretch
19:52:33 <jmw> are reps from pkg-mysql-maint here? I saw otto join at least
19:53:09 <nthykier> I think he is the only one
19:53:21 <nthykier> (at least by nicks I remember)
19:53:50 <jmw> me too
19:54:10 <jmw> rbasak and ryeng are not here
19:54:26 <jmw> well let's start anyway
19:54:52 <jmw> just finding my notes...
19:55:54 <jmw> ok recent DSAs: I had an action to get security team feedback about mysql and maria dsas
19:56:16 <jmw> we did get a reply off the record, and things seem much better there although there can be improvement, which is to be expected
19:56:24 <jmw> so I think that is ok for now
19:56:39 <jmw> meanwhile Otto has become a DD, which should also help with the work
19:57:19 <nthykier> otto: congrats :)
19:57:59 <nthykier> I believe we also have an outstanding item on moving to MariaDB as the default?
19:57:59 <jmw> we also got some requirements notes from the security team, nthykier do you remember where they are? were they official yet?
19:58:20 <nthykier> Their security transparency requirements?
19:58:23 <jmw> yes
19:58:25 <nthykier> They posted that to Oracle already
19:58:30 <jmw> excellent
19:58:35 <nthykier> It was 3 item list
19:58:39 <nthykier> was an*
19:58:49 <jmw> #info Recent DSAs of MySQL and MariaDB went much better, and there are no major concerns right now
19:59:03 <adsb> <20160202144708.GA19323@inutil.org> ftr
19:59:21 <jmw> aha, thanks
19:59:22 <nthykier> <20160129193951.GA23052@pisco.westfalen.local>
19:59:23 <nthykier> ah
19:59:41 <adsb> I assume that's the one just up-thread
19:59:42 <nthykier> Adam beat me to it
19:59:59 <nthykier> two up, but yes
20:00:15 <nthykier> Adding an info
20:00:19 <jmw> #info Security team requirements have been published (<20160129193951.GA23052@pisco.westfalen.local>)
20:00:22 <jmw> oops
20:00:28 <nthykier> jmw: nope thats fine :)
20:00:44 <jmw> transition to mariadb libraries
20:01:38 <jmw> I mailed the release team initially to get feedback on this, but didn't get much response (but it was only 10 days ago)
20:01:47 <jmw> is there anything to be added to that now?
20:02:01 <pochu> that we should make the switch? :)
20:02:47 <jmw> I believe jcristau is also in favour (please correct me if not)
20:03:30 <adsb> [eating]
20:03:33 <jmw> for myself, I quite like the idea of getting ourselves some insurance. it's probably not going to be realistic to switch back, but it's better than trying to do it in a hurry
20:04:04 <jmw> I could be persuaded either way though really
20:04:15 <nthykier> I am also in favour of switching for reducing the risk
20:05:02 <jmw> #info Switching dependencies to MariaDB early reduces the risk of needing to do it in a hurry later
20:07:11 <jmw> ok, let me put it another way: are there any reasons to *not* switch today?
20:07:48 <nthykier> I am not aware of any that outweights the risks of keeping status quo
20:08:56 <jmw> sounds like agreement, objections?
20:09:17 <nthykier> agreed!
20:09:35 <jmw> #agree MySQL dependencies should be transitioned to MariaDB
20:10:18 <jmw> #info MySQL could still be shipped in Stretch if there are no objections from the security team, but it's unlikely that dependencies would be switched back
20:10:27 <jmw> #action jmw write to pkg-mysql-maint to get a plan formed
20:10:33 <jmw> anything else before we move on?
20:10:39 <otto> (sorry for delay in reply, back at keyboard now in case you have questions)
20:11:11 <nthykier> moving on would be ok for me
20:11:26 <pochu> yeah let's wrap this up :)
20:11:33 <jmw> #topic d-d-a after meetings?
20:11:39 <jmw> mehdi
20:12:04 <jmw> currently I announce a meeting on debian-release@l.d.o, and follow up to it with a link to the minutes
20:12:59 <pochu> what if there's nothing worthwhile to announce?
20:13:07 <jmw> mehdi: what was your proposal?
20:13:26 <mehdi> send a report after each meeting
20:13:52 <mehdi> (be it brief or long with decisions mades or issues discussed during the meeting)
20:14:09 <jmw> mehdi: did you intend to send a full report, or just a minutes link? the minutes tend to be quite comprehensive, I'm not sure I want to duplicate that by hand
20:14:18 <jmw> someone else could of course
20:14:19 <nthykier> I do not think there is any other core team with regular meetings that does that, so we would be the first to do it
20:14:24 <pochu> I think we should just send the report to -release@, unless there's a big thing that deserves d-d-a
20:14:36 <mehdi> jmw: both work for me, tbh.
20:15:04 <jmw> I think I'd prefer only to mail d-d-a for special things, otherwise people get used to it
20:15:15 <jmw> we have bits for that sort of announcement
20:15:18 <nthykier> Personally, I am inclined to agree with pochu - I am not entirely convinced that every meeting is naturally worthy of a d-d-a mail
20:15:25 <jmw> +1
20:15:35 <jmw> mehdi: ok with that?
20:16:00 <mehdi> we are 4 vs 1. i am not going to cry. :)
20:16:03 <jmw> #agree d-d-a mails to be reserved for announcements
20:16:09 <jmw> #topic Next meeting
20:16:13 <pochu> but certainly if made a decission on an important topic (e.g. moving the freeze today) that sure deserves a d-d-a mail :)
20:16:19 <jmw> pochu: definitely
20:16:31 <jmw> according to my calendar we are 23rd March next time
20:16:37 <jmw> could someone double check?
20:16:44 <pochu> that's right
20:16:54 <jmw> #topic AOB
20:17:03 <jmw> any other business? shout now, or forever...
20:17:16 <pochu> no #info nextmeeting ?
20:17:19 <nthykier> kudos for getting through all items!
20:17:24 <jmw> oh right, yeh
20:17:25 <pochu> yay!
20:17:25 <jmw> #undo
20:17:25 <MeetBot> Removing item from minutes: <MeetBot.items.Topic object at 0x10bfa50>
20:17:36 <jmw> #info Next meeting: 23rd March 2016
20:17:39 <jmw> #topic AOB
20:17:45 <jmw> no aob, let's end
20:17:47 <jmw> #endmeeting