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