17:59:37 <jmw> #startmeeting
17:59:37 <MeetBot> Meeting started Wed Sep 23 17:59:37 2015 UTC.  The chair is jmw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:37 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:48 <jmw> ok, who made it from the release team?
17:59:57 <jmw> #addchair nthykier
18:00:20 <jmw> uff
18:00:23 <pochu> o/
18:00:23 <jmw> #chair nthykier
18:00:23 <MeetBot> Current chairs: jmw nthykier
18:00:24 * faw waves
18:00:27 <jmw> #chair pochu
18:00:27 <MeetBot> Current chairs: jmw nthykier pochu
18:00:31 <jmw> #chair faw
18:00:31 <MeetBot> Current chairs: faw jmw nthykier pochu
18:00:42 <ivodd> hi
18:00:45 <nthykier> morning :D
18:00:46 <jmw> #chair ivodd
18:00:46 <MeetBot> Current chairs: faw ivodd jmw nthykier pochu
18:01:08 <adsb> o/
18:01:14 <jmw> #chair adsb
18:01:14 <MeetBot> Current chairs: adsb faw ivodd jmw nthykier pochu
18:01:15 <jmw> aha
18:01:22 <jmw> I wondered if you were still commuting
18:02:04 <jmw> I wonder if jcristau is around, that would be helpful for the first item I think
18:02:09 <jcristau> not really
18:02:12 <jmw> ok
18:02:22 <nthykier> perhaps we should come back to that later then?
18:02:24 <jcristau> food takes priority
18:02:33 <jmw> we can do, sure
18:03:04 <KiBi> #chair kibi
18:03:13 <jmw> #chair KiBi
18:03:13 <MeetBot> Current chairs: KiBi adsb faw ivodd jmw nthykier pochu
18:03:15 <jmw> ohai
18:04:24 <pochu> so, second item?
18:04:27 <jmw> that's probably everyone we're likely to get
18:04:34 <nthykier> indeed
18:04:37 <jmw> #topic Forthcoming transitions
18:04:46 <MeetBot> nthykier: Error: Can't start another meeting, one is in progress.
18:04:53 <nthykier> okay, we already did that
18:05:01 <nthykier> why isn't #topic working then?
18:05:14 <ansgar> nthykier: Because #-release has +t
18:05:19 <nthykier> oh silly me
18:05:29 <jmw> it doesn't change topic, but does show up in minutes, so it's useful
18:06:00 <nthykier> Ok, Forth coming transitions - Perl is a known big one, anything else?
18:06:01 <jmw> so, we're stacking up a few transition requests now, some of which may be able to start running now that g++blah is at least in testing, if not finished
18:06:17 <pochu> we also got python2.5 and ruby2.2
18:06:19 <jmw> I wondered particularly about python3.5, which is one of these multi-stage ones
18:06:29 <jmw> and completion of ruby, yes
18:06:46 <nthykier> Multi-stage as in "migrate to 3.4+3.5 and the remove 3.4 later"?
18:06:48 * adsb gives pochu an s/2/3/
18:06:49 <jmw> yes
18:06:58 <pochu> and gfortran
18:07:06 <pochu> ocaml
18:07:11 <jmw> indeed
18:07:14 <nthykier> Ok, Python 3.5 should not be much of an issue then
18:07:17 <jcristau> jmw: fwiw i've been ignoring release stuff for the last 2-3 weeks so am probably not very useful on the g++5 status front
18:07:22 <jmw> jcristau: ack
18:07:23 <pochu> those seem to be the bigger ones. the rest are standard
18:07:46 <jmw> so, should we try and start off some of the ones that don't overlap with g++, or should we avoid that, or should someone investigate further?
18:08:01 <adsb> there's the vtk stuff, which will no doubt continue to be a pain in anywhere it can manage
18:08:25 <adsb> if they don't overlap then sanity-checking some and getting them going sounds like a plan imo
18:08:28 <jmw> vtk is horrible in its own special way :)
18:08:34 <pochu> I've been holding on from approving any of those until I knew the status of the g++ one, since I've been rather away from that and I don't know if things would get tangled
18:08:39 <jcristau> adsb: i was hoping the rc bugs i filed against vtk5 rdeps meant stuff would be autormed
18:08:40 <jmw> pochu: me too
18:08:56 <adsb> jcristau: cunning
18:09:24 <jmw> (if things don't get autormed we can always do it with RoD-UK bugs...)
18:09:40 <jmw> anyway
18:09:49 <jmw> would anyone like to look into possible transitions to kick off?
18:10:08 <nthykier> Ruby looks like it can continue already
18:10:20 <ivodd> jcristau: it's on the auto-removal list, but the delay isn't over yet
18:10:21 <pochu> I can do that. maybe starting with smaller ones (i.e. not perl or python) and see if they are ok, then get to bigger ones
18:10:27 <jmw> pochu: thanks
18:10:28 <nthykier> AFAICT it is the second stage of a "two-stage" transition, so it should be good
18:10:34 <pochu> nthykier: yeah
18:10:46 <jmw> #action pochu will look into starting off some of the smaller transitions alongside g++
18:10:59 <jcristau> ivodd: i'm in no hurry
18:11:48 <jmw> #agree the ruby transition is the second part of a "two-stage" transition, so it should be a good candidate
18:11:52 <nthykier> (pochu: apt is already clear of g++ AFAIK)
18:12:25 <jmw> anything else to say before we move on?
18:12:35 <jcristau> lack of graphicsmagick g++5 transition is getting annoying
18:12:56 <pochu> nthykier: ok, I'll take a look at that
18:12:57 <jmw> we can probably do something about that
18:12:57 <jcristau> so if any other transition depends on graphicsmagick you'll want to hold off
18:13:11 <pochu> jcristau: ok
18:13:12 <nthykier> jmw: no, I am ok with moving on :)
18:13:30 <jmw> #topic g++ transition check
18:13:37 <jmw> oh boy, this one
18:14:04 <jmw> I have not had time to check in with this for a couple of weeks, can anyone give a better-than-I-can idea of where we are?
18:14:23 <nthykier> On the plus side, we seem to have finished a lot of the transitions listed in the titanpad.  On the bad side,  I am pretty sure we have lost track of it
18:14:49 <jmw> yeh, that was my feeling
18:14:58 <nthykier> The transition tracker is franckly useless for this transition and the titanpad gives no overview whatsoever
18:15:17 <jmw> I also sense that people think the transition is finished and therefore so has the stuff, is that just me? I certainly saw people saying it was over
18:15:39 <nthykier> While it isn't, the worst is most likely over
18:15:42 <jmw> #info visibility problem, the tracker is not very helpful for this and the titanpad lacks an overview
18:15:55 <KiBi> jmw: that's my sentiment as well. :/
18:16:04 <jmw> yes, my fear is that maintainers are also no longer interested because it's perceived to be yesterday's transition
18:16:32 <jmw> #info maintainers (and users) seem to think that the transition is over, but there is lots more work to finish
18:16:44 <jcristau> maintainers of packages in https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-gcc@lists.debian.org;tag=libstdc%2b%2b-cxx11 should care, the rest probably not
18:17:42 <jmw> well I suppose on the plus side, that list has more resolved than open bugs :)
18:18:06 <jcristau> but tbh after august i kind of needed to walk away from dealing with that cleanup
18:18:30 <jmw> yeh, I burned out a bit on it too, as well as lacking time lately
18:18:52 <jmw> we're definitely lacking in momentum at the moment
18:18:57 <nthykier> I can certainly appreciate that - thanks for the hard work you have put into it so far
18:19:00 <jmw> is it worth an encouraging mail to a list of some sort?
18:20:10 <nthykier> jmw: If you think it will work, I don't see why not :)
18:20:47 <jmw> nthykier: it's just an idea, I'm not sure how much faith I would have :)
18:21:00 <pochu> btw what's left here? maintainers need to change pkg name and start a transition, and we need to do binnmus? do we need to ack the transition bugs we've got?
18:21:30 <jmw> jcristau: is graphicsmagick a blocker or just an irritation?
18:21:47 <nthykier> pochu: If we can get them to upload their stuff, finishing the transitions are usually fairly managable
18:22:03 <nthykier> (ignoring stuff entangled in icu or boost )
18:22:33 <jcristau> jmw: it seems to be blocking octave
18:22:34 <jmw> if there are transition bugs against r.d.o then it's possible maintainers are waiting for acks on those, so that's worth following up
18:22:38 <jcristau> at least.
18:22:39 <jmw> jcristau: eugh
18:22:49 * jmw puts that down as 'blocker'
18:23:04 <jmw> #info graphicsmagick is blocking part of the chain
18:23:25 <jmw> jcristau: do you know if there's a problem with graphicsmagick itself?
18:23:40 <jmw> oh bugs
18:23:41 <jcristau> aiui it had an unrelated packaging change that broke ABI of the C lib
18:23:42 <jmw> nice
18:23:56 <jmw> #796310 I guess
18:24:01 <nthykier> yes
18:24:02 <jcristau> y
18:24:14 <nthykier> jmw: are you #info'ing that?
18:24:34 <nthykier> or should I? :)
18:24:37 <jmw> nthykier: go for it
18:24:54 <jmw> there will be a hyperlink in the minutes in any case
18:24:55 <nthykier> #info The graphicsmagick blocker is #796310
18:25:00 <nthykier> excellent
18:25:03 <jcristau> grep-excuses knows
18:25:37 <jmw> the bug has had traffic in the last day or so, including from jcristau, so I guess it's in hand if slow
18:26:22 <jcristau> it was left there for a month before that, so...
18:26:37 <jmw> oh yes. nice.
18:27:04 <jmw> ok I suggest we leave that for now then and see what comes out of it
18:27:34 <jmw> or does someone want to poke it?
18:28:32 <nthykier> We really need it solved sooner rather than later if it blocks transitions
18:28:57 <nthykier> #action nthykier to follow up on #796310
18:29:02 <jmw> thanks
18:29:03 <nthykier> good, lets move on then
18:29:14 <jmw> #action jmw will check up on transition bugs that may be waiting for acks
18:29:27 <jmw> shall I do a bits from the g++ transitioners with an update too?
18:29:36 <nthykier> sgtm :)
18:29:52 <jmw> #action jmw will draft for review "bits from the g++ transitioners"
18:30:04 <jmw> I'll do a draft and review round to make it's not full of lies
18:30:13 <nthykier> Ok
18:30:15 <jmw> before we move on it should also be noted that simon has been an absolute star in this transition
18:30:18 <jcristau> one could configure octave --with-magick=ImageMagick
18:30:19 <jmw> he's not here or I would highlight him
18:30:25 <adsb> bad smcv
18:30:51 <jmw> but he has gone well above and beyond his own packages and got a lot done for us
18:31:10 <pochu> yeah smcv rocks :)
18:31:34 <jmw> #topic MySQL variants in Stretch
18:31:52 <jmw> did any of pkg-mysql-maint make it? I don't know any nicks unfortunately
18:32:00 <pochu> I think the security team's mail wrt that is pretty clear
18:32:00 <ryeng> o/
18:32:01 <jmw> also security team, but they weren't expecting to so I assume not
18:32:29 <jmw> hi ryeng
18:32:41 <ryeng> hi, looks like I'm the only one
18:33:38 <jmw> ok
18:33:40 <jmw> so, let me try and summarise the security team's concerns accurately for those who don't get such mail:
18:35:51 <jmw> 1. mysql upstream's policy of security updates and information is a problem; particularly the lack of information (and thus testing). for this reason they favour shipping only maria in stretch, which (aiui) is less problematic there
18:36:29 <jmw> 2. this isn't a new problem, but they took the decision to support mysql and maria in jessie to allow some time for users to migrate
18:37:14 <jmw> (for the avoidance of doubt, what goes into stretch is a release team decision, but the security team support it for several years so we take their views seriously)
18:37:49 <pochu> and because of that, mysql is currently unsupported in squeeze
18:38:03 <jmw> correct
18:38:21 <jmw> and now that we have lts of course, that exacerbates the problem
18:38:28 <jmw> meanwhile the mysql/maria maintainers are less keen on shipping only one variant, and would prefer both (there was also percona something, but it's been removed)
18:38:36 <ryeng> Speaking for upstream, we've offered to discuss the security bug situation with the security team a couple of times, but they haven't responded.
18:39:11 <jmw> #info the security team have doubts about mysql upstream security processes; maria is less of a problem
18:39:24 <jmw> #info mysql is unsupported in squeeze
18:40:11 <jmw> #info jessie includes mysql and maria side-by-side for migration purposes
18:40:13 <jmw> ryeng: are there proposals for easing the situation or were you looking for a wider discussion with them?
18:40:29 <ryeng> jmw: Options for sharing more info with the security team.
18:40:34 <ryeng> in general
18:40:54 <jmw> would additional information be embargoed or could they share it in (e.g.) DSA announcements?
18:41:11 <ryeng> We'll need to talk about that.
18:41:13 <jmw> ok
18:41:21 <jmw> any release team thoughts?
18:41:46 <jmw> #info mysql upstream have offered to discuss sharing more info with the security team
18:42:01 <mehdi> is it unsupported because we don't accept huge updates or is it another issue?
18:42:11 <jcristau> also afaict carnil is doing the support work for jessie/wheezy, not the maintainers?
18:42:33 <ryeng> mehdi: It ships MySQL 5.1 which has been EOL upstream for a couple of years.
18:43:00 <mehdi> ryeng: k
18:43:06 <pochu> why is it unsupported in squeeze? because upstream doesn't share information and so we & other distros can't backport patches?
18:43:17 <jmw> jcristau: I had heard something like that, yes. I wasn't sure if I'd read it or heard it (I can't find the source)
18:43:31 <pochu> jmw: I remember that as well
18:43:42 <jcristau> jmw: it was mentioned at the debconf meeting, and who-uploads agrees
18:43:45 <adsb> I believe carnil's doing the squeeze-lts work too
18:44:10 <adsb> we keep having to bump mysql-5.5 from p-u to sid during point releases, which is getting tedious
18:44:28 <nthykier> FTR, MySQL in Jessie (5.6) will also be EOL December 2018, so it will also be an issue for Jessie-LTS
18:44:33 <jmw> ryeng: forgive me, but are you involved in packaging much?
18:44:34 <nthykier> erh, 5.5.
18:44:37 <nthykier> 5.5*
18:44:42 <jmw> I get confused about who's who
18:44:51 <ryeng> jmw: Yes.
18:45:40 <jmw> ryeng: in that case, can you comment on stable maintenance from your perspective?
18:45:47 <jmw> (stable in the debian sense)
18:46:37 <mehdi> nthykier: if you consider -lts (i.e. 6y from release date) then anything is unsupportable
18:47:32 <ryeng> jmw: Can you be more specific? What do you want to know?
18:47:33 <adsb> some things are more supportable than others. but anyway
18:47:48 <nthykier> mehdi: Even so, I suspect MySQL 5.5 will EOL before Jessie will (the non-LTS variant)
18:47:49 <KiBi> some badly need to be..
18:48:33 <nthykier> (the question is of course by how much)
18:48:44 <jmw> ryeng: there's concern that the security team are ending up carrying all the load of updates in jessie/wheezy. does that match up with your experience?
18:49:40 <ryeng> I've had the impression that we haven't been allowed to upload until the release team sees a CPU announcement. We'd like to upload every point release (~every 2 months) and thereby be ahead of security announcements.
18:49:56 <jmw> CPU?
18:49:57 <ryeng> CPU announcement == Oracle's security announcements
18:49:58 <jmw> ah
18:50:03 <ryeng> bad acronym
18:50:20 <nthykier> ("Critical Patch Updates")
18:50:46 <ryeng> If we're allowed to upload every point release, we'd have the patches in at the time of the announcement, and the security team wouldn't have to upload anything.
18:51:20 <adsb> I don't remember anyone asking us about doing it via p-u
18:51:57 <jmw> news to me too
18:52:21 <mehdi> i can join the me-toos group
18:52:57 <adsb> also bear in mind that p-u means that users may wait 2 months to get the packages, depending on how dates align
18:53:26 <mehdi> why wouldn't those uploads land in -security? did the security team rejected uploads or requests of updates in the past?
18:53:53 <jmw> mehdi: not all upstream point releases are security-worthy, aiui
18:54:14 <ryeng> jmw: correct
18:54:23 <adsb> but either way, none of that stops the maintainers preparing packages for those that are and those going via -security
18:54:37 <adsb> which I think was more the original question
18:54:43 <jmw> yes
18:55:02 <jmw> whether we take non-urgent things through p-u as well is a different matter
18:55:14 <mehdi> indeed
18:55:23 <ryeng> True. I can't speak for the whole team, but at least I've had the understanding that it wouldn't go in. We can start doing every point release.
18:55:48 <adsb> again, I think we may be talking at cross-purposes
18:56:02 <pochu> I have to leave so I'll state this now. At this point I'm more inclined towards removing mysql tbh. If we & the security team are convinced otherwise, it can be brought back later. but I see too many problems plus not many benefits with shipping both maria and mysql (if there are, then that's something for the convincing mail). I'll let you keep discussing it and make a final decision and will read the backlog later
18:56:03 <jmw> mm, I'm not sure that's a winner either; the security team aren't going to release DSAs for non-security things
18:56:10 <mehdi> i think this needs to clarified with the security team
18:56:13 <pochu> ttyl o/
18:56:18 <jmw> pochu: thanks, and laters
18:56:33 <adsb> you appear to be suggesting that either you're allowed to upload every release or the security team have to do all the work. those aren't the only two choices
18:57:18 <ryeng> No, not at all. I've just had the impression that there hasn't been a point preparing every point release. I've obviously been mistaken. We can corret that.
18:58:22 <adsb> well there might not be. I can't speak for the security team
18:58:42 <jmw> ryeng: I think perhaps there is some confusion about what the security team does (fast, targetted fixes through their own repository) and what the stable release managers do (errata)
18:59:04 <jmw> a security upload to the security team can be done independently of ordinary point releases to the stable release managers
18:59:27 <jmw> the security team's complain is that they're doing all the work for security releases when they are required
19:00:07 <ryeng> I think the pkg-mysql-maint team can handle that going forward.
19:00:31 <mehdi> well, good news then
19:00:58 <mehdi> did you inform the sec team about that?
19:01:03 <jmw> that would probably go a long way towards persuading them about stable maintenance, at least. I'm still concerned about the amount of information from upstream
19:01:13 <ryeng> mehdi: I haven't.
19:01:59 <jmw> ryeng: just to clarify, you still need approval from security *before* doing any uploads, and they handle the archive side
19:02:01 <mehdi> jmw: that help, at least, for jessie now. but yes, question remains for stretch.
19:02:29 <ryeng> jmw: I know.
19:03:11 <jmw> mehdi: yes and no. but I can't speak for them
19:03:19 <mehdi> maybe time to record that using #info? :-)
19:03:43 <mehdi> where "that" refers to the last 10mins :-)
19:03:53 <jmw> #action pkg-mysql-maint (or some of that team) will get more involved with preparing security updates
19:04:44 <adsb> (ftr my dinner has just arrived so I may not be useful for a short while)
19:05:02 <jmw> for stretch, I remain concerned about the information we get from upstream, the lifetime, the duplication of effort in maintaining both forks, and the potential for divergence of the forks
19:05:32 <mehdi> adsb eating is more useful than a starving adsb :-)
19:05:41 <mehdi> enjoy your dinner
19:05:49 <jmw> but I'm minded to leave that for now and see if we can get ryeng and the security team talking about the upstream parts
19:05:56 <jmw> any release team thoughts?
19:06:08 * mehdi agrees
19:06:16 <nthykier> Sounds good to me at first glance, but we need a deadline on resolving this
19:06:17 * faw agress
19:06:24 <faw> ugh... horrible typo
19:06:29 <mehdi> we can see how it goes and leave this for later
19:06:34 <jmw> we do
19:06:35 <nthykier> A migration to MariaDB will take quite some times
19:06:57 <jmw> I will leave this item on the agenda for next time, and let's have an update then if possible
19:07:03 <nthykier> Ack
19:07:09 <ryeng> jmw: When is that?
19:07:15 <jmw> ryeng: to be decided
19:07:22 <mehdi> 1month from now?
19:07:41 <jmw> something like that
19:07:58 <jmw> ryeng: do you want me to mail the security team and nudge them towards setting something up with you?
19:08:31 <ryeng> jmw: Yes, thank you! Please cc the whole pkg-mysql-maint list, not just me.
19:08:35 <jmw> sure
19:08:49 <jmw> #action jmw will try to get the security team and pkg-mysql-maint talking about upstream relations
19:08:58 <jmw> shall we move on?
19:09:04 <nthykier> ok with me
19:09:05 <mehdi> yes
19:09:11 <jmw> ah sprint
19:09:17 <jmw> ryeng: thanks for your input
19:09:30 <ryeng> thanks for listening
19:09:31 <jmw> #topic Sprint at Cambridge mini-debconf?
19:09:32 <mehdi> indeed. thx ryeng
19:09:56 <jmw> right, Sledge has offered us a repeat arrangement at the miniconf in November
19:10:18 <nthykier> Personally, I think it is a good idea, though I am not convinced I will make it
19:10:43 <jmw> at least adsb, ivodd (but other commitments) and I will be there; but there are other people wanting to sprint as well and I think we should not hog meeting space unneccessarily
19:10:51 <mehdi> November is usually quite busy for me, personally. i don't think i'll be able to attend.
19:10:58 <jmw> so I'd like to let Sledge know whether we want a room or just a corner in the main hackspace
19:11:27 <KiBi> I'll probably be busy at this time. Not that you need me anyway…
19:11:44 <nthykier> KiBi: Needing you there != wanting you there! :)
19:11:57 <jmw> what nthykier said
19:13:01 <jmw> I'm inclined to say a hacking corner rather than a meeting room, unless we come up with things to discuss in private between now and then
19:13:14 <jmw> but I don't have a great deal of preference
19:13:24 <nthykier> :)
19:13:25 <mehdi> are people planning to attend next fosdem? (could be a plan too for next time)
19:14:15 <nthykier> mehdi: Hold that thought - it is a good suggesting, but I think we should close the Cambridge sprint first
19:14:23 <nthykier> (i.e. the topic)
19:14:39 <faw> I can't make to UK in November, and I currently don't have plans to attend FOSDEM  :)
19:15:06 <nthykier> jmw: Sounds like a hack-corner will do for Cambridge
19:15:34 <jmw> let's say hack corner for now, and if we come up with a big list of s3kr1t things in the meantime they may be able to sort us out
19:15:48 <jmw> #action jmw to confirm rooming with Steve
19:15:55 <jmw> #topic Next meeting
19:16:11 <jmw> so I hope this has been useful, and I hope we want to do it again :-/
19:16:12 <mehdi> if it is a virtual hack corner, i can probably be there :p
19:16:36 <nthykier> jmw: We just committed to a next meeting 20 minutes ago :P
19:16:40 <mehdi> excellent to catch up and sync together
19:16:47 <nthykier> Indeed.
19:17:10 <jmw> the next "third wednesday in the month" is 21st October, but I am on vac so you'd have to do it without me
19:17:27 <KiBi> ohnoes
19:17:38 <nthykier> jmw: I thought we did the fourth?
19:17:43 <jmw> or it's only a fortnight from then until the miniconf; or we could go for 2 months (probably not unreasonable) which would be 18th Nov
19:17:58 <jmw> oh so we do. well I'm still on vac, so :p
19:18:05 <mehdi> lol
19:18:14 <jmw> ok fourth wednesday in november is 25th
19:18:35 <mehdi> i'll be on a work-trip between 14th and 20th of nov
19:18:48 <mehdi> 25th is good
19:19:10 <jmw> nthykier: what do you think? one month or two?
19:19:29 <nthykier> Monthly sounds good to me for now
19:19:56 <KiBi> especially if we want to have an answer for *sql by then
19:20:09 <jmw> let's say 28th October for now then
19:20:18 <mehdi> k
19:20:31 <jmw> #agree Next meeting (provisional): 28th October
19:20:38 <jmw> but I am away, so you're on your owns :)
19:20:44 <jmw> #topic AOB
19:20:46 <jmw> AOB?
19:20:46 <nthykier> jmw: Thanks :)
19:21:12 <mehdi> NOB :-)
19:21:35 <jmw> say now or forever hold...
19:21:46 <nthykier> Lets close it, we are 30 minutes overtime
19:21:52 <mehdi> or maybe suggestions to make transition tracker more useful for transitions like
19:22:02 <mehdi> g++ are welcome
19:22:20 <jmw> #endmeeting