19:03:12 <nthykier> #startmeeting
19:03:12 <MeetBot> Meeting started Wed Feb 22 19:03:12 2017 UTC.  The chair is nthykier. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:12 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:03:25 <nthykier> Ok, time for meeting :)
19:04:03 <jmw> this meeting thing is contagious
19:04:40 <nthykier> #topic Transitions
19:05:00 <nthykier> So, to my knowlegde we have two transitions left for stretch
19:05:15 <nthykier> MySQL -> MariaDB which should now be complete
19:05:20 <jmw> it is
19:05:29 <nthykier> #info MySQL -> MariaDB is now complete
19:05:31 <jmw> mysql left stretch some weeks ago
19:05:57 <nthykier> And the other one is OpenSSL 1.1
19:06:24 <nthykier> That is nearly completely, I just want to rebuild wget in testing so we don't get surprises in stable
19:06:35 <jmw> that is good news indeed
19:06:42 <nthykier> #info OpenSSL transition is nearly complete
19:06:58 <jmw> any reason not to rebuilt it in sid and let it migrate?
19:07:14 <nthykier> #action nthykier to ensure wget gets rebuilt against openssl 1.1 in testing
19:07:28 <nthykier> new upstream version in sid and I am not sure it qualifies
19:07:38 <jmw> right
19:08:27 <nthykier> but admittedly it is a possible solution to that - I just wanted to keep it simple and do a t-p-u so KiBi could review and test it in his own time :)
19:08:49 <nthykier> Any thing else for transitions?
19:08:59 <jmw> yum it ships __pycache__ and stuff
19:09:12 <nthykier> (wget?)
19:09:14 <jmw> yeh
19:09:16 <adsb> eww
19:09:25 <ivodd> the diff is horrible
19:09:53 <nthykier> and thus my choice :)
19:10:03 <jmw> and /tmp... I can't even work out how that's possible
19:10:05 <jmw> anyway
19:10:46 <nthykier> #topic Secure Boot
19:10:59 <nthykier> this is a bit less positive
19:11:36 <nthykier> Unless there has been some recent development I have not been aware of, Secure Boot is not really progressing
19:11:52 <Mithrandir> that is blocking on me and/or vorlon jumping through the necessary hoops to get it signed by MS.
19:12:06 <nthykier> That is one of the blockers
19:12:08 <Mithrandir> we jumped through the first set of hoops, then the hooping changed and the new hoops are
19:12:19 <Mithrandir> (let me find the link)
19:12:43 <Mithrandir> https://docs.google.com/document/d/1gHFkhMmn6VVvVQim5YcjJ8uc3xf1JHQnA9f8KSE6qqY/edit
19:13:27 <nthykier> The other blocker is that we have not setup signing yet - to my knowledge, jcristau is waiting for the FTP-masters to confirm the "API" between DSA and FTP-masters
19:16:25 <nthykier> I am not convinced that we are progressing at a rate where I am comfortable to declare this a blocker for stretch
19:17:54 <nthykier> (which may have been "British" for "can-defer")
19:18:16 <jmw> we probably don't need to make a decision on that at this stage
19:18:31 <nthykier> that is true
19:18:54 <jmw> we're realistically not going to be in that position for a month yet - we can probably await the to-dos for now
19:18:57 <nthykier> at the same time, I feel the need to say that I don't think it will make it at this time
19:19:18 <nthykier> at this rate*
19:19:59 <nthykier> jmw: the issue for me is that once the signing on our side (not MS) is done, we still have some outstanding items after that
19:20:08 <jmw> yeh
19:21:04 <jmw> well, there's not much we can do about it right now
19:21:07 <nthykier> true
19:21:23 <nthykier> If there are no questions for Secure Boot then I will move on
19:21:43 <jmw> Mithrandir: do you need anything else from us for getting the shim signed?
19:22:12 <nthykier> The code needs to be rebased on the github repository (currently in bzr)
19:22:19 <nthykier> and then resubmitted as I recall
19:22:28 <nthykier> (rebased as in converted to git)
19:22:55 <jmw> we should have some infos
19:23:05 <nthykier> true
19:23:07 <Mithrandir> we just need to provide a git repo which corresponds to the source package (as per the document).  Anybody can do that, I'll do it if vorlon doesn't, when I get around to it, but I'd be very happy for somebody else to take it and run with it.
19:23:42 <nthykier> #info shim signing need us to convert our packaging repo from bzr to git and resubmit (per https://docs.google.com/document/d/1gHFkhMmn6VVvVQim5YcjJ8uc3xf1JHQnA9f8KSE6qqY/edit)
19:23:46 <jmw> Mithrandir: where are the repos to be found?
19:23:59 <jmw> then they will show up in the minutes and someone might have tuits
19:24:00 <nthykier> Vcs-header of shim, right?
19:24:14 <Mithrandir> AFAIK, yes.
19:24:21 <nthykier> #undo
19:24:21 <MeetBot> Removing item from minutes: <MeetBot.items.Info object at 0x20a6110>
19:24:40 <jmw> https://github.com/rhinstaller/shim is one
19:24:49 <nthykier> #info shim signing need us to convert our packaging repo from bzr to git and resubmit (per https://docs.google.com/document/d/1gHFkhMmn6VVvVQim5YcjJ8uc3xf1JHQnA9f8KSE6qqY/edit)
19:25:00 <nthykier> #info From lp:~ubuntu-core-dev/shim/trunk to https://github.com/rhinstaller/shim
19:25:09 <jmw> https://code.launchpad.net/~ubuntu-core-dev/shim/trunk
19:25:24 <jmw> (for people like me who'll forget in five minutes time)
19:25:42 <jmw> ok I'm done being awkward now :)
19:26:09 <nthykier> #info We are missing signing support for the bootloader, kernel modules (etc.) on ftp-master.d.o (even manual signing).  Waiting for feedback from FTP-masters
19:26:17 <nthykier> I think that should cover it
19:26:33 <jmw> yes
19:26:34 <jmw> next
19:26:41 <nthykier> #topic PIE rebuilt or not
19:26:57 <nthykier> We enabled PIE by default but have a number of packages that did not get rebuilt
19:27:13 <nthykier> There was a proposal to rebuild them before the stretch release
19:27:50 <jmw> what's the number?
19:28:45 <nthykier> 3404 source packages (where it actually caused the package to get PIE enabled plus 81 that did not fix it - at least not fully)
19:29:28 <nthykier> For me, the concern is that if we do not do it now, we may do it post-release (e.g. in via pu or security upload)
19:29:32 <jmw> that's quite a lot
19:29:40 <nthykier> indeed
19:30:11 <nthykier> jcristau was on the other hand concerned about the churn + risk + work not outweighing the benefits of doing the rebuild
19:30:45 <jmw> we could be weeks rebuilding that many, especially on slower buildds
19:32:04 <nthykier> should we look at selecting a subset or just drop it completly then?
19:32:32 <ansgar> Rebuild only on some architectures?
19:32:47 <nthykier> (ftr, https://lintian.debian.org/tags/hardening-no-pie.html has list of /binary/ packages affected by this)
19:32:51 <jmw> nthykier: arches or packages?
19:32:56 <nthykier> packages
19:33:20 <nthykier> only doing some architectures would break Multi-Arch: same and make people sad
19:33:27 <jmw> ah yes
19:33:28 <nthykier> (unless we exclude those)
19:33:44 <jrtc27> and also the slow (less popular) architectures are probably more likely to have issues?
19:33:56 <jmw> we could do required+standard, and not optional+extra, but the benefit is getting slimmer and slimmer then
19:34:10 <nthykier> but if we have issues, I prefer fixing them now rather than leaving it to the SRMs to clean it up
19:34:29 <ivodd> we could start with a subset and see how well that goes
19:35:32 <jmw> nthykier: do you have rapid l33t sk1llz to get a quick idea of how many are in each section?
19:35:54 <nthykier> jmw: unfortunately no
19:36:18 <nthykier> (key packages may also be another selection criteria)
19:36:46 <jmw> in some ways I'd rather start with leaf packages, but again risk/benefit
19:36:52 <nthykier> or that
19:37:05 <nthykier> Any takers for selecting a subset to pilot this ?
19:37:26 <nthykier> Remember, do'ers decide! ;)
19:38:02 <ivodd> I'm happy to start with a subset (if you point me at the list again)
19:38:02 <nthykier> #info At least 3404 source packages would enable PIE after a no-change rebuild
19:38:34 <nthykier> #action ivodd to select a subset to build
19:38:36 <jmw> identifying a subset with a good risk/reward balance is probably the first thing
19:38:52 <nthykier> #undo
19:38:52 <MeetBot> Removing item from minutes: <MeetBot.items.Action object at 0x20349d0>
19:39:08 <nthykier> #action ivodd to select a subset to build with a good risk/reward balance
19:39:14 <nthykier> there, fancy wording included! :)
19:39:17 <jmw> ha
19:39:17 <ivodd> :)
19:39:24 <jmw> ok it's a plan
19:40:00 <nthykier> ivodd: https://people.debian.org/~rbalint/pie-mass-rebuild/sources-rebuild-works.txt
19:40:20 <jmw> https://people.debian.org/~rbalint/pie-mass-rebuild/sources-rebuild-works.txt is the master list
19:40:28 <jmw> (for the minutes' benefit)
19:40:53 <nthykier> :)
19:41:18 <nthykier> #topic RC bug fixing
19:41:28 <nthykier> The rate has declined!
19:41:41 <jmw> you shock me :p
19:41:57 <jmw> it is 214 as of 18:00 though, which is actually good progress
19:42:29 <nthykier> The last few days, key packages have been stuck at ~100 RC bugs and the number of bugs fixed in unstable has dropped to ~30 (from 50-60)
19:43:53 <jmw> I make key packages 85, according to udd
19:44:00 <nthykier> While it could be that we are filing bugs as fast as we are fixing them, I suspect that we have weeded out most of the "easy" RC bugs in the key packages
19:44:07 <nthykier> jmw: https://udd.debian.org/bugs/?release=stretch_and_sid&merged=ign&keypackages=only&fnewerval=7&flastmodval=7&rc=1&ctags=1&cdeferred=1&crttags=1&sortby=id&sorto=asc&format=html#results ?
19:44:26 <nthykier> (the default view ignores stuff with patches)
19:44:38 <jmw> ah patches right
19:45:01 <nthykier> well, tagged patch - which may or may not be useful
19:45:13 <jmw> true
19:45:20 <anarcat> if i may - couldn't it be also that autoremoval cleaned up a lot of packages as well? or that doesn't matter because autoremoval was already in place before the freeze?
19:45:34 <nthykier> anarcat: Only looking at key packages atm
19:45:57 <jmw> I propose we stretch-ignore bugs like #704303
19:46:19 <jmw> on the basis it will be fixed in the next policy release
19:46:30 <nthykier> Of these 101 RC bug only one is currently tagged will-remove; nothing got any other "releasy" tags (can-defer/ignore, or is-blocker)
19:46:40 <nthykier> fine with me
19:46:54 <jmw> please info
19:47:08 <nthykier> jmw: which one of them?
19:47:22 <jmw> that we will stretch-ignore missing mpl text
19:47:39 <nthykier> #action jmw will -ignore #704303
19:47:41 <nthykier> :P
19:48:11 <nthykier> #undo
19:48:11 <MeetBot> Removing item from minutes: <MeetBot.items.Action object at 0x2075790>
19:48:32 <jmw> hm seems to be the only one actually
19:48:39 <nthykier> #agreed We will ignore #704303 on the basis of it being fixed in the next release
19:49:30 <jrtc27> returning to PIE, I believe http://paste.debian.net/916265/ is a summary of all the binary packages on amd64
19:49:34 <jrtc27> which is 2813 out of the 3324 in the file
19:50:00 <jmw> nthykier: much else about bugs, or lets talk unblocks?
19:50:24 <nthykier> #info The RC bug list for key packaes could use a review and get proposals for "will-remove", "is-blocker" or "can-defer" tags
19:50:29 <nthykier> jmw: nope that was it
19:50:41 <nthykier> #topic Unblocks
19:51:06 <nthykier> First of, we are much better off than we were during jessie! \o/
19:51:37 <nthykier> jmw: want to take this? :)
19:51:50 <jmw> I have specific queries on some of them, so sure
19:52:04 <nthykier> (jrtc27: Thanks - please follow up with ivodd after the meeting)
19:52:13 <jmw> shotwell: dear mr release manager, how much do you care about epoch vs. really, and am I being too obstinate about it?
19:52:39 <jmw> tl;dr: I don't mind +really-blah versions temporarily, but not in a release because they are a lie
19:52:59 <jmw> and there is maintainer resistance to an epoch
19:53:08 <nthykier> ugh
19:53:13 <jmw> quite
19:53:55 <jmw> on the basis that we hope not to have to touch it in stable, the proposed version string will be 0.25.4+really0.24.5-0.1 for the next five years
19:54:14 <nthykier> that is sad
19:54:23 <jmw> I don't mind climbing down, but I don't know how strongly anyone else feels about it
19:54:31 <nthykier> but on the flip side, we already got packages with "really" in testing
19:54:36 <jmw> it's true
19:55:13 <jmw> (we could fix that too, but that's a different discusion)
19:55:56 <ivodd> jmw: you could do an nmu with an epoch, and that would be the end of the argument
19:56:04 <nthykier> I don't feel we can mandate it if we don't enforce it all the way through (which would just start a "different" discussion)
19:56:10 <nthykier> ivodd: be nice! :P
19:56:14 <jmw> ivodd: not sure that will make me any more popular :p
19:56:29 <ivodd> jmw: that wasn't your question...
19:56:37 <ivodd> nthykier: I'll try
19:56:55 <nthykier> ivodd: as in, convince the maintainer or do the nmu?
19:57:12 <jmw> ok, maybe the right thing to do here is follow up to the bug with everything on the table, and see how they want to play it. I'll accept the +really if there's still resistance
19:57:14 <adsb> I assumed "be nice"
19:57:23 <nthykier> adsb: ah, thanks
19:57:29 <jmw> I wouldn't bet on it :D
19:57:31 <adsb> but icbw :)
19:57:58 <ivodd> I'll try to be nice :)
19:58:01 <jmw> right, next: d and friends (#855229)
19:58:17 <jmw> hm I thought there was another one to go with that
19:58:45 <jmw> ah dustmite, but someone has already fixed that while I wasn't looking
19:59:36 <nthykier> ok - any thing in particular?
19:59:51 <jmw> no, I think that answers that actually
19:59:58 <jmw> lack of preparation error, sorry
20:00:08 <nthykier> :)
20:00:16 <jmw> the diff is still pretty big, but better than I recalled
20:01:15 <jmw> asterisk
20:01:27 <jmw> that is a fun new-upstream-vs-backports one
20:02:24 <jmw> I am inclined towards taking the upstream for improved maintenance for that one, if there are no objections
20:02:55 <ivodd> jmw: ok, go ahead
20:02:59 <nthykier> jmw: sounds good to me
20:03:48 <jmw> and then there is btrfs-progs, which breaks all the no-exceptions precedents in one fell swoop :(
20:04:07 <jmw> how bad is it if it doesn't match the kernel implementation?
20:04:07 <nthykier> yeah
20:04:22 <jmw> (possibly a question for the maintainer)
20:04:37 <nthykier> That would be a decent question for the maintainer
20:04:50 <ivodd> I guess the old version should work with a new kernel
20:04:52 <jmw> ok
20:05:04 <ivodd> so there should be a good reason before we can consider the new version
20:05:18 <jmw> those are all my question marks, everything else just needs eyes
20:06:46 <nthykier> Ok
20:07:28 <nthykier> jmw: I assume you are following up on these bugs?
20:07:34 <jmw> I will do later, y es
20:07:39 <nthykier> great thanks :)
20:08:03 <nthykier> Any suggestions on #855137 ?
20:08:25 <nthykier> I am stuck between punting for buster and granting the exception to deal with it
20:09:13 <ivodd> nthykier: if the new package fixes it, I'd accept it
20:09:50 <nthykier> ok, thanks
20:10:27 <jmw> it sounds straightforward to go with that, yes
20:10:31 <nthykier> If there are no other unblock requests to be brought up, I guess I will move to "closing"
20:10:42 <nthykier> (AOB, next meeting etc)
20:10:55 <nthykier> #topic AOB
20:10:58 <nthykier> Any ?
20:11:00 <ivodd> sprint?
20:12:06 <jmw> sorry to drop the ball on the spain sprint; if it's still on the cards, I'm still up for it
20:12:18 <nthykier> I think it feel apart - we only had 3 people who could commit to an answer to the poll back in January and progress died there
20:12:28 <jmw> yeh
20:12:55 <nthykier> if any one is interested in reviving it, I am interested
20:13:13 <nthykier> (although, "this weekend" will be too short notice for me)
20:13:23 <jmw> tonight!
20:13:24 <ivodd> nthykier: there is a bsp in berlin, we could all go there :)
20:13:26 * jmw ducks
20:13:32 <nthykier> ivodd: when is that again?
20:13:37 <ivodd> nthykier: this weekend
20:13:49 <nthykier> ...
20:13:54 <ivodd> on a more serious note: there are a few bsps planned later
20:13:56 <ivodd> and suncamp
20:14:06 <jmw> suncamp is a long way out
20:14:12 <jmw> may I think
20:14:15 <ivodd> jmw: yes
20:14:44 <nthykier> would have loved to, but I can't attend the 17th-19th of March either
20:15:10 <jmw> I need to go soon, anything else first?
20:15:43 <nthykier> Don't think so
20:15:46 <nthykier> moving on
20:15:50 <nthykier> #topic Next meeting
20:16:46 <jcristau> nthykier: re: rebuild if you do it post release you control which packages and what pace, so you can do targetted testing.  a mass rebuild doesn't allow that.
20:17:16 <nthykier> #info Next meeting is 22nd of March at 19:00 UTC (import into your calendar via https://release.debian.org/release-calendar.ics)
20:18:00 <nthykier> #endmeeting