18:59:41 #startmeeting 18:59:41 Meeting started Wed Jan 27 18:59:41 2016 UTC. The chair is nthykier. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:41 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:59:48 #addchair jmw 18:59:49 indeed 18:59:54 #addchair KiBi 18:59:57 #addchair KiBiadsb 19:00:03 #addchair adsb 19:00:10 #addchair jcristau 19:00:11 right let's rattle through the formalities: 19:00:14 #topic Apologies 19:00:23 I'm aware of at least pochu who will not make it, are there any others? 19:00:37 adsb: wasn't sure 19:00:48 sorry - adsb said he was not sure 19:00:54 yes, he might catch us up 19:01:07 mehdi: ping? 19:01:47 I should state delayed apologies for myself for last time (I did mail team), and also thanks for taking care of it that time 19:01:56 s/and/but/ 19:02:08 :) 19:02:17 nthykier: looks like it might just be you and I then... 19:02:30 oh well 19:02:45 #topic Transitions 19:03:00 as usual, pochu does a fabulous job managing transitions 19:03:19 there is quite a lot of unannounced ones though, which are usually quite small but sometimes get tangled 19:03:26 is that a problem we should deal with or is the status quo ok for now? 19:03:56 I have not heard of any considerable problems, so I presume it is ok for now 19:04:06 (though I have not looked at it) 19:04:18 I have had a vague eye open, and it seems not to be too bad 19:04:30 getting maintainers to move the transition on is sometimes more of an issue 19:04:55 #info maintainer-led transitions seem to be working ok for the time being 19:05:08 maybe we should remind library maintainers of their responsibilities in some bits? 19:05:22 That might be good :) 19:05:23 I know how you love bits :) 19:05:38 #agreed remind library maintainers of their responsibilities in next bits 19:06:10 #topic g++5 progress 19:06:15 aha this one has been brewing a while 19:06:40 so this kindof ground to a halt at 47%, although I don't know how reliable that figure is for actual progress 19:06:54 it is useless 19:06:59 right, that was easy then :) 19:06:59 (the figure) 19:07:27 can you give an idea of where we really stand? 19:07:58 I suspect we have basically lost track of it because we did not handle progress loging correctly from the beginning 19:09:42 #info the 47% completion label on the transition tracker is actually not very much use 19:09:44 rather because there's no way to handle progress logging 19:09:49 We should probably just get the last known items fixed (https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-gcc@lists.debian.org;tag=libstdc%2b%2b-cxx11) and then close it at that 19:09:50 ohai o/ 19:10:31 There is - but it was manual and probably not structured well enough. 19:10:41 that does look like a much more manageable list 19:11:04 I have an idea for "next time" (although I prefer there was no "next time" for this) 19:11:14 it might have been manageable if libstdc++6 shlibs had been bumped 19:11:18 (don't we have an upcoming gcc6? ;)) 19:11:42 but it wasn't, so it isn't 19:12:54 well, that list of bugs is something we can make some progress on probably, which is better than doing nothing 19:13:02 pochu did ping some or all of them in october 19:13:40 the rc ones shouldn't affect testing anymore, hopefully? 19:13:43 are nmus feasible? istr it was difficult to have confidence in uploads 19:13:48 so they can rot 19:13:59 true 19:14:12 maybe we should end the transition here then 19:14:30 presumably there's been plenty of time for people to find breakage... 19:14:51 wfm 19:14:56 well, doko wanted the whole archive rebuilt with gcc5, transition or no 19:15:12 but that's not tractable, so i'd rather not have that on my plate 19:15:25 #info rc bugs should no longer affect testing, so we will leave those out of the equation now 19:16:27 I can't say I'm wild about rebuilding the whole archive 19:17:09 even then, you would probably need gcc-4.8 and gcc-4.9 removed first to ensure everything was built with gcc-5 19:18:05 jmw: libstdc++ rdeps rather than the whole archive, and most have probably already been rebuilt 19:18:12 ack 19:18:27 can we get away with just letting that one lie as well? 19:18:46 you did say "whole archive" as well :P 19:18:56 wfm as well 19:19:30 should be possible with some projectb query to find the list of source packages that build a deb depending on libstdc++, figure out when it was last built and binNMU if it's before $cutoff 19:19:34 but, meh. 19:19:40 somebody who cares can do that 19:20:05 I don't really mind either way, but as you say none of us particularly wants to do it, so 19:20:18 #info rebuilding the archive is not very practical 19:20:37 #info it's been long enough that any serious breakage should have become apparent by now 19:20:40 the little spare time i have is already not being spent on helping adsb manage the p-u requests queue, and i care more about that :( 19:21:14 #agreed unless problems are found at this stage, we consider the g++5 transition over 19:21:22 Ack 19:21:24 anything else to be said on this topic? 19:21:38 Not from me 19:21:59 #topic MySQL variants in Stretch 19:22:21 I assume we have representation from robie or otto and maybe others? I forget nicks, sorry 19:22:32 _o/ 19:22:37 rbasak: otto_: ltangvald: 19:22:42 Yup 19:22:51 Though I probably won't say much 19:23:20 for the record, I should apologise for having dropped the ball so badly on this in september; there are reasons, but I haven't shared them publicly 19:24:29 ok 19:24:43 just trying to work out where to begin on this :) 19:25:08 how did the recent DSAs go from the maintainers perspectives? 19:25:19 Thanks jmw. I appreciate that everyone involved has other things to do too, and I thank you all for the time that you have been able to commit. 19:25:27 there were one each I think? 19:25:59 The security uploads are all done, as of a few hours ago. There were a few technical hiccups, so I think we have some points we can improve on for next time. 19:26:07 o/ 19:26:33 It's a little painful as the primary maintainers (of both MySQL and MariaDB) are not DDs, but hopefully that can be fixed in time. 19:27:26 (it's also painful because the builds take so long and don't work in parallel; that's better in testing already) 19:27:27 there should be at least one DD very soon, so that will hopefully make things easier 19:27:40 jmw: you are one of the DAMs right? I've been waiting in DAM review since November to become a DD.. wink, wink :) 19:27:49 I just have to get round to finishing otto's review 19:28:07 quite :) 19:29:16 Robie is also excellent candidate, his work is always of high standards. 19:29:37 ok, but that's not really what we need to get to here 19:29:51 It is apitty database packaging is not very sexy and practically no now team members have appeared in a long time 19:29:58 Thanks otto_ :) 19:30:01 s/apitty/a pity/ 19:30:31 Though if MySQL is removed, that may become irrelevant. The only other package I maintain needs to be removed probably now (it's Mozilla Persona related) 19:33:39 nthykier: o/ 19:34:50 On that note. I have been told that the Security Team is drafting a policy on their requirements for upstream security policies 19:35:24 "Security Transparency" was the actual words used 19:35:42 #info Security team working on a "Security Transparancy" document 19:36:29 I think that will go a long way towards expectation-setting 19:37:04 Thank you - I really appreciate that. I hope it will help with resolving the disclosure policy issue we have with both MySQL and MariaDB at the moment. 19:37:12 Though, I got no ETA on its completion nor its current status. Presumably it is in a very early state 19:37:45 I don't think MariaDB has any disclosure problem. Take as example very recent CVE from MariaDB, mailed to oss-security 19:38:18 otto_: http://www.openwall.com/lists/oss-security/2016/01/26/3 19:38:21 otto_: MariaDB *upstream*, don't, but from a Debian perspective it does, right? Or else, why did you have to ask Oracle on the ML in relation to MariaDB? 19:38:22 ? 19:40:32 rbasak: Based on the security team's words and actions so far, I suspect they feel the same way as otto_ (although, it is my interpretation) 19:40:59 I understand that the root cause is Oracle's disclosure policy (which we hope to have them change). 19:41:16 But AFAICT, both the MariaDB and MySQL packages are impacted by this issue from Debian's perspective. 19:41:26 The security team themselves said so. 19:41:48 http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008536.html 19:41:51 rbasak: impacted yes, but there is a difference between being affected by MySQL and behaving like MySQL 19:42:21 Yes, that's true. So the question is: does Debian make a decision based on technical impact, or something deeper? 19:43:11 making a decision based on whose policies are reasonable and whose aren't wouldn't be the worst idea ever, imo 19:43:15 If deeper, then I'd question whether the release or security teams have the remit to make that decision (I don't know - I don't mean to accuse). 19:44:29 that is an interesting constitutional question, but I don't know if that's a rabbit hole we want to go down too far 19:44:38 I'm not sure that makes sense though. I could release rbasakSQL tomorrow, and have amazing Debian-spirit-compliant policies. 19:44:51 Anyway, sure. 19:44:56 Let's move on. 19:46:12 the disclosure/information sharing thing is very relevant though. I think (though I can't speak for them) that a large part of the security team's objection is the quality of information that arrives in disclosures (the ones like "unspecified vulnerability") 19:46:32 Debian is historically very open about what is wrong and how it's being fixed, and those make that very hard 19:46:51 I am aware that some work is being done in that area though 19:48:50 Yes - I look forward to seeing the outcome for that. I hope that it will fix the situation for both MySQL and MariaDB. 19:49:16 who is liaising with oracle about that? I get confused easily 19:49:32 Is there anything new on the Oracle side? My understanding was that they were waiting for a fully specified list of things to implement 19:49:52 jmw: ryeng is an Oracle employee. It's on the pkg-mysql-maint list. 19:50:02 nthykier: Yes, I'm waiting for the security team to come back with some requirements. 19:50:06 One might say I'm liasing I suppose, and I'm happy to do that. But ryeng is happy to participate directly. 19:50:21 He's on the list, I mean. 19:50:21 ltangvald is as well (based on the @oracle.com in from) 19:50:33 o/ 19:50:47 Yeah. I work on our Debian/Ubuntu packaging 19:51:02 ltangvald is being delegated a ton of the engineering work. He's behind the new 5.7 branch (not uploaded yet) and prepared the security updates. 19:51:07 ltangvald may not be directly involved in the disclosure discussion though? 19:51:19 No 19:51:22 No, I'm handling that from the Oracle side. 19:51:22 jmw: right. That's ryeng really. We're leaving ltangvald out of the politics. 19:51:26 ok, thanks 19:51:32 let me try and summarise some infos: 19:51:34 lucky him 19:51:36 :) 19:51:38 :) 19:51:40 heheeh 19:52:28 jmw: ok :) 19:52:31 #info the security team is working on a policy for security disclosure requirements, but it's not yet clear quite what shape that will take 19:53:29 #info ryeng is liaising with oracle over the disclosure requirements 19:54:01 ryeng: we don't want to end up with both teams waiting for each other though, so anything proactive you can do to oil the wheels would probably be appreciated all round 19:54:45 Is there any chance the Oracle policy change can be more iterative/agile? 19:55:03 ah nthykier has the buzzwords I am missing :) 19:56:17 I doubt it. We don't want to change policies all the time, so it will be one change in policy. Once we get some requirements, we can go back and forth a bit trying to find a specific solutions if there are options. 19:56:41 So there's "policy change", and "policy change process". 19:57:04 I don't think there's anyone here saying that the process cannot have some back and forthing, but I do think we need a written starting point. 19:57:46 ok :) Figured it was worth a shot :) 19:58:00 My concern is that Oracle will do something, say "we've done it", and what they did won't be acceptable to Debian. 19:58:15 I want to avoid that, since all our efforts would be wasted. 19:58:22 (and we'd run out of time) 19:58:40 rbasak: you mean "if they only get the requireents little by little"? 19:58:45 requirements* 19:58:46 So I think it needs to start by Debian setting out its requirements, so I really appreciate that the security team are working on that now. 19:58:58 I wonder if jmm_ or carnil carnil_ or Corsac are around and might be able to give an idea of what stage this is at 19:59:16 hhm? 19:59:18 aha 19:59:27 jmw: I heard from jmm that he did not expect to be around 19:59:38 nthykier: yeh it was a long shot 20:00:01 Corsac: we are discussing mysql + security disclosures, and there's a rumour that the security team are working on some guidelines for disclosure requirements 20:00:16 if it's news to you as well it's fine :) 20:01:02 jmm_ mentioned it earlier in this channel I think, before the meeting. 20:01:07 I'm not around either, and to be honest: the threads are way to large, with way too long mails (including the “summary” ones); so I'm definitely not aware enough 20:01:39 ok, not to worry 20:01:43 thanks 20:01:58 He said they've started, but it wouldn't be ready for this meeting. 20:02:12 let's await developments there then 20:02:29 (FYI: I'll be in FOSDEM this weekend if anybody wants to work on any MariaDB issues with me in person) 20:03:53 on a different note, I have skimmed #811428 just now and this seems much more productive than on previous occasions, so assuming that continues I think I have much less concern about maintenance in stable for mysql 20:04:00 I am considering to add "[#]info The general feeling is that Oracle is unlikely to implement the desired result unless the full requirement list is given at once." - does that seem accurate enough / worded correctly 20:05:11 I'd say we're unlikely to hit the mark unless we have the full requirement list 20:06:07 jmw: thanks. Oracle worked hard to make that happen since it was brought up, so I appreciate you noticing! 20:06:08 ryeng: ok 20:06:11 You're the ones pushing for change, so we'll try to adapt to what we get from you. If that's not a complete list, it may not be a complete solution. 20:06:49 #info Oracle believes they are unlikely to hit the mark unless they got a full requirement list 20:06:50 nthykier: how about $agree it's not reasonable for oracle to implement a moving set of requirements at short notice, so we await a more concrete set of guidelines to negotiate with 20:07:00 or that 20:07:05 jmw: wfm 20:07:12 will you do it? 20:07:27 or we'll end up with two :) 20:07:41 will do 20:08:07 #agree It is not reasonable for Oracle to implement a moving set of requirements at short notice. We will await a more concrete set of guidelines to negotiate with. 20:08:10 otto_: I couldn't find a similar bug for the mariadb dsa recently, was there much discussion about that or did it just work? 20:09:12 ryeng: Do you know if this has high priority within Oracle in general? 20:09:39 There was no separate bug report, we just documented the CVE in the package changelog and initial trigger to upload happened with Oracle CPU coming out 20:10:04 nthykier: It does, high up. 20:11:02 otto_: ok, thanks 20:11:07 :) 20:11:53 jmw: from this page you find the best links to more info: https://security-tracker.debian.org/tracker/CVE-2016-2047 20:12:42 can I take it we're agreed that the maintenance issue isn't a big one any longer, and we can put that objection aside? 20:13:26 jcristau: your opinion valued on that point, with your SRM hat on 20:14:10 i have no information on that. don't know. 20:14:29 If it continues like #811428 I do not have any immediate concerns - I cannot speak for the security team nor the SRMs 20:14:47 well, I mean maintenance in {old,}stable specifically 20:15:24 SRM hasn't been involved in any of that so far afaik. they're all through security. 20:16:32 (concerns over the how, though it is still new upstream releases) 20:16:35 ok 20:17:21 #agreed the security release process seems much improved, but a longer view should be taken about overall maintenance in stable 20:17:32 I guess there isn't likely to be much non-security stable maintenance 20:18:13 #action jmw will mail the security team to see how things are going with DSAs 20:18:29 now this question of "defaults" 20:19:35 jmw: please keep mail *short*; we're already overwhelmed by mail for actually handling/triaging security issues, embargoed or not 20:19:46 Corsac: sure thing 20:21:28 defaults: we have a finite window in which to make package dependency changes to effectively default one engine over the other for packages which just don't care (the libmysqlclient problem) 20:22:20 there is a virtual mysql package at the moment as well, isn't there? (I'm not so clear on this bit) 20:22:51 I believe there's virtual-mysql-server, provided by both mysql-server and mariadb-server, or something like that. 20:23:00 otto_ knows more I think. 20:23:32 https://wiki.debian.org/Teams/MySQL/virtual-mysql-server 20:23:41 libmysqlclient is an entirely separate thing I think. It'll take some care and coordination, since the MariaDB build of it is different from the MySQL build of it (same soname) 20:24:12 AIUI, MariaDB aren't progressing libmysqlclient at all. Instead they have a separate client library that they work on, with a separate soname. 20:24:17 maraidb.org repos ship libmariadbclient18 and all software seems to work OK with it 20:24:45 libmariadbclient18 is designed to be a drop-in-replacement for libmysqlclietn18 20:24:47 rbasak: Correct, MariaDB Corp. are developing a separate library: https://lists.launchpad.net/maria-developers/msg09042.html 20:25:10 According to them, libmysqlclient in MariaDB is not actively maintained 20:25:21 All new developments I think is in libmariadb2 and libmariadb3, which is natural 20:25:51 otto_: Yes, if switching library, it would be natural to use that instead of libmysqlclient from MariaDB. 20:25:56 otto_: is libmariadb3 also a client library? 20:26:15 I hear three names - libmysqlclient, libmariadbclient, and libmariadb. 20:26:31 I'm a bit confused as to MariaDB's position on the first two. 20:26:43 Switch to a new library (eg libmaria2) I think needs something from the app developer to do, at minimum change soname they link to 20:26:44 Are they the same? 20:27:12 Switch to libmariadbclient18 package provided libmysqlclient.so.18 would not require any extra work 20:27:45 Any ABI differences? 20:28:05 It doesn't feel right to me that MariaDB is taking over the same soname, but that's up to the release team I suppose. 20:28:22 It might be cleaner to get dependent packages to explicitly build against a new soname perhaps? 20:28:55 SUSE and RedHat migrated all existing software to build against MariaDB provided version of libmysqlclient 20:28:58 libmysqlclient in MySQL and MariaDB are very similar, but there may be a few issues with 5.6 features and newer, since that happened after the fork. 20:29:59 otto_: what soname do SUSE and RedHat use? 20:30:18 The ABI is not 100% same in mysql-5.5/libmysqlclient.so.18 and mysql-5.6/libmysqlclient.so.18 and mariadb-*/libmysqlclient.so.18 20:30:40 ..but with regard of compatibility they are the same 20:30:41 ryeng: But the libmariadbclient.so.18 implements these features? 20:30:53 MariaDB has some extra async functions 20:31:16 ("these features" being the 5.6 features) 20:31:58 nthykier: I'm not sure what libmariadbclient.so.18 is. If it's libmysqlclient.so.18 as shipped by MariaDB, it doesn't implement all features in libmysqlclient.so.18 as shipped by MySQL. 20:31:59 This is the rule of thumb: mysql-5.5=mariadb-5.5, mysql-5.6=mariadb-10.0 20:32:30 otto_: ack, thanks 20:33:10 ryeng: ok - guess I will have to ask otto_ :) 20:33:31 but they all have the soname .18 by Oracle design - only in 5.7 Oracle bumped to so.20 20:33:36 am I right in saying that the major problem we need to solve is whether to ship variants, rather than which one gets preferred by applications? 20:33:40 wrt libraries and SONAMEs, i don't think rule of thumb is enough. it sounds like if we switch packages to use mariadb-provided libmysqlclient, it should have a different SONAME. 20:33:56 and not pretend to be something it's not 20:34:38 the -dev package could still ship libmysqlclient.so, to keep API the same. 20:34:43 jcristau: If that rule is followed to the letter, then the SONAME in mysql-5.6 should urgently be changed to .19 20:34:55 otto_: nope 20:35:20 otto_: right, and Oracle kindly reserved .19 for Debian for this purpose. 20:35:42 jep, but not implemented yet as nobody requested it hard enough 20:35:50 We decided not to do it because we thought it was the lesser of two evils, given the timing. 20:36:22 But I'm happy to fix it that way if the release team require it. That's not a policy problem in my mind, just a bug that needs to be fixed. 20:36:43 otto_: if something built against libmysqlclient from mysql 5.5 would still work with libmysqlclient.so.18 from 5.6, there's no need to change SONAMEs. but with two parallel branches, keeping oracle's SONAME sounds like a recipe for trouble 20:36:44 Equally the lesser of two evils in migration to libmariadb.so.18 would be to keep the SONAME 20:37:36 anyway. dinner time. 20:37:53 otto_: I think that introduces potential future problems because you end up with two owners of the same soname. For example, what happens if Oracle's disclosure policy gets fixed to Debian's satisfaction, and then Oracle want an 18.1 or 19? 20:37:54 jcristau: Yes, the Debian repositories should not have two providers of libmysqlclient.so.18, thus MariaDB in Debian does not ship any libmariadbclient package from teh mariadb server source as mysql does 20:37:59 (or 20, which they have) 20:39:02 I am just replying to jmw question: can the client library "default" switched? Yes if release team wants. 20:39:33 ok 20:40:16 otto_: that wasn't quite what I meant, let me rephrase it 20:41:13 the disagreement between mysql and release teams is about whether to ship a particular variant or not, rather than the "default", right? for example, shipping mariadb but not mysql 20:41:33 and the mysql team's position is that you want to ship both in parallel 20:41:47 jmw: right. We want to ship both, you (and/or security) want to remove one. 20:41:51 That's my understanding. 20:41:55 ok good 20:42:24 If there is only one option, then we don't need to have a discussion of what is the "default" 20:42:32 I'm coming to that 20:43:16 the major concern from our point of view is the amount of time there is remaining to do the technical work *if* one variant ends up dropped because it lacks support from the security team, for whatever reason 20:44:07 I don't think it's disputed that mysql is currently the issue there, rather than mariadb (the security team certainly have that preference, afaik) 20:44:32 I agree in part. 20:44:48 There's no dispute that it's MySQL facing the cut here. 20:45:03 But I think there is dispute that it's being done on sound technical reasons, rather than political feeling. 20:45:48 Since, for example, security disclosure issues *impact* both variants, as we discussed earlier. 20:46:08 ok, noted, although security support is largely out of our hands (we have no desire to ship something without security team support) 20:46:35 I understand that you can only proceed on the decision of the security team. 20:47:00 I think that the security team owe us an answer on this point, which is distinct and separate from the progress on getting Oracle to change their policy. 20:47:11 Currently we have worked to have both side-by-side. Inside the team we cannot of course agree that either one should be defalt in any way, and thus technically Debian users have as much freedom to choose right now as possible. Which is a positive thing. 20:48:32 meanwhile the freeze marches nearer, and one idea I recently heard was to start the process of switching dependencies towards mariadb clients in anticipation of a problem. this would not mean that we don't do everything we can to ship both side by side, but it lessens the crunch quite a lot in november when we suddenly have to get on with it 20:48:53 shipping in parallel would be ideal, but this keeps the options open 20:49:23 jmw: It is november - 2 months (assuming this to be a transition) 20:49:27 As an aside, two packages come to mind. akonadi and pinba-engine-mysql. They have deeper integration with MySQL than most. 20:49:30 nthykier: yes 20:49:51 If there are issues switching, I think those are more likely to have issues than some of the others. 20:50:06 I haven't done any real analysis though. That's just off the top of my head. 20:51:04 rbasak: Yes, those and ... and MP3 player I don't remember the name of just now, which uses the embedded server lib. 20:51:09 I don't know pinba but there was at least one user running akonadi with mariadb-server-core-10.0 package installed and reported it to work 20:51:23 jmw: I wonder. Could you agree to ship both, if and when the security team considers its cocnerns addressed? 20:51:56 jmw: because if you can, that might make it more likely to get a favourable result (from Debian's perspective) on the disclosure issue. 20:53:10 well, I'm pretty sure shipping mysql in stretch is less disruption all round. not sure whether I would want to commit to it right here and now though, although I'm not against it 20:53:15 I wonder what nthykier thinks 20:54:41 (brb) 20:56:05 (I need to go to bed soon, early morning and long travel day tomorrow..) 20:56:13 otto_: ack 20:57:01 Personally, I am not against shipping both based on the assumption that every thing works out on the security disclosure transparancy part. 20:57:51 Though, I like jmw I am not comfortable with commiting to ship both right here and now 20:58:41 I understand that there may be other reasons that crop up, and wouldn't expect you to be restrained by those. 20:58:55 I wonder if there's some sort of statement in the middle that you can make. 20:59:00 I don't know what. 20:59:59 My thinking is that if Oracle face "meet these requirements and the problem is solved", that's better than facing "meet this requirements and we'll think about it". The former is much more likely to get us a favourable result, IYSWIM. 21:00:15 rbasak: we certainly can't commit the team to it between the two of us (especially not SRMs), but I'm inclined to be upbeat 21:00:27 the security team objection is by far the biggest factor 21:00:58 SRM's concern will be/is long-term maintenance; there are at least three years worth 21:01:43 so returning to the question of switching clients early in anticipation 21:02:15 There are clients, depending on libmysqlclient18. And there are things that need servers, depending on mysql-server-5.6 or mysql-server-5.6-core. 21:02:25 Anything else? 21:02:40 ryeng: mentioned an MP3 client. 21:02:59 pinba-engine-mysql build-depends on mysql-server-source (binary) 21:03:44 cqrlog 21:03:47 pinba-engine-mysql might be a good place to start, actually. If it's blocked, then the release team will need to make a decision about what to do with it. 21:03:54 what I'm getting at is should we start that process *now* 21:04:13 or dither and hope we don't have to do it at all 21:04:58 there is by the way already packages with "Depends: mariadb-server | virtual-mysql-server" 21:05:10 Certainly biased, but I am in favor of starting the process *now*. My greatest motivation being risk reduction 21:05:40 But it is of course a different scale if release team sets it as a goal for all mysql depending pacakges 21:05:41 If MySQL eventually gets leave to remain, what would happen then? 21:05:42 s/reatest/primary/ ? 21:05:57 I presume that right now the release team will set the goal, and later on let maintainers do what they wish again? 21:07:09 I guess - given we haven't worked this out yet - that we would file non-rc bugs requesting a switch, and when we know for sure what the outcome will be either make them RC or relax 21:07:16 something along those lines, probably 21:07:33 Understood, thanks. 21:08:11 I'd appreciate the opportunity to provide some feedback on the text of that bug. 21:08:22 certainly, if and when the time comes 21:08:29 Thanks 21:08:49 to be honest, pkg-mysql-maint would be in a better position to drive that process in general, knowing the packages better 21:08:56 but we can sort that later 21:10:03 I must admit starting that process and leaving time for fixups appeals to me as it does nthykier (and I think jcristau too) 21:11:01 we should move this to mail so that the rest of the teams can get involved: 21:11:04 If the release team makes a clear announcement somewhere I can then implement what was requested 21:11:21 (file bugs about virtual-mysql-* preference) 21:12:01 Something else? We can't touch libmysqlclient.so.18 now and there might not be a need to do it ever? 21:12:34 jmw: I'm not really clear on how the release team works on this kind of thing. What's necessary to get a release team decision? Eg. majority vote, a leader, or something else? 21:13:09 #info it may be wise to start migration towards mariadb dependencies sooner rather than later, but ship mysql as well if security concerns are resolved 21:13:24 #info a decision cannot be taken right now 21:13:27 rbasak: If we had been more, we would probably have voted over IRC 21:13:33 otto_: I imagine that it'd be a virtual-mysql-* preference together with an instruction to build against libmaria* and drop libmysqlclient dependency? 21:13:48 rbasak: but we appear to be 2 (maybe 3), so I think we will vote over email 21:13:49 #action jmw will mail release team and include pkg-mysql-maint about moving to mariadb dependencies 21:13:56 quite 21:14:03 OK, thanks. 21:14:15 we don't usually have to resort to voting and can reach consensus, but nthykier and I certainly can't decide this on our own 21:14:33 I think we should wrap mysql up there; we have made some progress and have some actions 21:14:47 rbasak otto_ ryeng thanks for your contributions 21:15:03 jmw: thank you 21:15:04 tsk, you forgot ltangvald :) 21:15:16 ah i was just trying to find him in scrollback :) 21:15:19 Shh, I'm not part of the political talk :D 21:15:26 :) 21:15:29 hahaha 21:15:32 ltangvald, thanks for your non-political contributions :) 21:15:43 And thank you for the time from the release and security teams on this. 21:15:54 Thanks and good night! (now or later today :)) 21:15:57 Yes, thank you! 21:16:05 If anyone wants to talk face to face, both Otto and I will be at FOSDEM. Just reach out. 21:16:12 nthykier: so we have a few things left on the agenda, but it's getting on: 21:16:29 reproducible builds: I feel bad pushing that back another month :s 21:16:53 they were keen for a discussion before christmas even 21:17:16 jmw: Ok with me :) 21:17:40 h01ger: we have not forgotten you 21:17:51 I will put move it to the top of the agenda for next time perhaps 21:18:09 nthykier: mips64el, do you know what that is about? 21:18:22 next to nothing 21:18:27 ok we'll defer that 21:18:36 and linux in stretch only arrived this evening, that can wait 21:18:44 I might see ben next month anyway 21:18:52 #topic Next meeting 21:19:23 according to my calendar it's 24th Feb next, does that sound right? 21:20:08 Yupe - my calendar also says Feb 24th 21:20:16 #info Next meeting: 24th February 2016 21:20:28 I will do the usual 21:20:31 #topic AOB 21:20:35 any other business? 21:20:58 nope 21:21:07 not from me (apologies as well, only slowly coming back to #-release stuff) 21:21:22 ok, let's leave it there 21:21:23 #endmeeting 21:21:36 #endmeeting