19:01:36 #startmeeting 19:01:36 Meeting started Wed Nov 23 19:01:36 2016 UTC. The chair is nthykier. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:36 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:02:27 hey, who is around? :) 19:02:34 o/ 19:02:44 I think we got 2-3 known no-shows (or late shows) 19:03:22 yeah 19:03:27 . 19:03:37 oh look, an Adam o/ 19:03:38 (although will need to nip off in ~20 minutes to eat) 19:03:42 While we wait 19:03:46 hmm, food 19:03:52 #info Last meeting minutes at: http://meetbot.debian.net/debian-release/2016/debian-release.2016-10-26-19.02.html 19:04:25 ok 19:04:34 I suspect jmw is currently driving 19:04:38 #topic Previous meeting/actions 19:05:25 #info nthykier was supposed to ask MariaDB maintainers to start a MFB for the migration - they started the discussion on their own 19:05:48 pochu: you got an item for a sprint - a venue and a mail to team@? 19:06:31 Any news on that? :) 19:06:46 yeah. I started to look at that this afternoon (I suck), and I call a hotel but got asked to call again tomorrow morning so that I could talk to the person in charge of meetings et al 19:06:50 but I find a nice hotel, I think 19:06:58 with nice prices, I think 19:07:03 Ah, very nice 19:07:11 just need to talk to that lady and ask about meeting space, discounts, etc :) 19:07:20 #info pochu is still working on the venue for the sprint! 19:07:54 btw we should know who is planning to attend, and find the best date. but we can do that over email 19:08:11 as we're only 3 here atm 19:08:23 we should - I need to request vacation for that time, so the sooner we figure that out the better for me :) 19:08:33 (unless we keep to strictly weekend) 19:08:44 yeah. I'll call the hotel tomorrow morning and send that mail - promise 19:08:49 Thanks 19:09:25 ok, I think I will move on then 19:09:34 #topic Transitions 19:10:04 Lets ignore the elephant in the room a while longer and start with the others 19:10:20 I believe we got a couple of minor self-contained transitions 19:10:31 pochu: Any thing (besides ssl) worth mentioning? 19:11:58 xserver is started since yesterday - currently blocked on the binutils mips bug 19:12:19 I want to start the hdf5 one, but am waiting for openssl to settle 19:12:33 haskell is blocked on openssl 19:12:57 the rest is very small / unimportant 19:13:03 SQLAlchemy? 19:13:28 I want to push the mariadb one as well, so more packages switch to default-libmysqlclient-dev 19:13:54 by push I don't mean start a transition. that has been ongoing for months... 19:14:23 we have a new SQLAlchemy version which seems to break some packages. I still need to mediate there and see what's the best option 19:15:17 Yeah, SQLAlchemy sounded a bit sore 19:15:49 pochu: do you have a feeling about the mysql transitions and how far it is? 19:16:25 nthykier: I haven't looked too closely, but mostly we need ~100 packages to build-dep on default-lib... rather than lib... 19:16:40 ouch 19:16:46 so that they pick up a dependency on libmariaclient 19:16:59 And then a removal, which usually implies that someone realising that a use-case was overlooked? 19:17:03 and we can remove mysql-5.6 19:17:13 nthykier: sorry, wdym? 19:17:24 pochu: I mean "assuming no one overlooked something" :) 19:17:30 * KiBi waves from belated train 19:17:39 and here come the tunnels anyway… meh :( 19:17:41 oh yes. that's why I said I haven't looked closely at it 19:17:51 Hopefully we didn't :) 19:18:03 I need to play a bit with dak rm, look at Packages and Sources files, and see if there are any other dependencies 19:18:06 (no offense intended btw. - it came out wrong) 19:18:27 good 19:18:51 for now, I am blocking mysql-5.7 from entering testing. which has the nice side effect that packages that get rebuilt with libmysqlclient-dev pick a dependency on that, and they don't enter testing. nice effect because then they have to switch to default-libmysqlclient-dev ;-) 19:19:15 :D 19:19:21 nthykier: no worries man, I didn't get it in a bad way 19:19:24 :) 19:19:30 That is a nice way to push it 19:19:42 I asked Otto to send a MBF mail to debian-devel, but I guess he's been busy 19:20:18 ok - any final remarks on general transitions? 19:20:57 oh there was boost1.62. that's currently blocked by the mips* binutils bug too 19:22:02 and as I expected, there are quite some uncoordinated transitions happening after the freeze. which I don't really mind at this point as they are small, but I wonder if this will keep happening one or two months from now 19:22:06 and that's all 19:22:49 [food] 19:23:14 they will - especially if we permit them. But I agree if they are small / self-contained and cause no issues, then we are probably better off letting them through than enforcing the freeze 19:23:57 yeah. or at least, let's see if that becomes a problem, and only act / enforce it if that happens 19:23:59 But we should remember to slow it down as we approach December - it should be done before we reach 5th. of Jan 19:24:17 aye 19:24:27 I thought "small / self-contained" doesn't count as a transition? 19:24:55 I still plan to update a few dune-* packages for example (they have no outside dependencies). 19:25:03 I'm only acking small transitions now (also because the maintainers that didn't ask are doing them, so why punish those who are asking and did their job of testing rdeps...) 19:25:57 ansgar: self-contained might be a bit overloaded in this case :) 19:26:41 ansgar: if you maintain them all and there aren't many packages involved, then I don't think you need to ask at this point in time 19:27:12 pochu: AFAICT, ssl and mariadb/mysql are the only two major ongoing transitions, which looks like they might not complete before 5th of Jan - agreed? 19:27:40 or would at least require some focus to make it 19:27:45 nthykier: agreed 19:28:25 #info There are a bunch of minor ongoing transitions, which are not an issue 19:28:55 #info There is a concern about the SSL 1.1 and MySQL transition being complete before 5th of Jan 19:29:13 Ok - with that, SSL1.1 19:29:58 We have had some internal communication with Q_ and the security team on that. 19:31:17 We have been looking at how big a bundle of (source) packages have to agree on the same version of openssl 19:32:05 On the positive side, we have found a significant number of packages that are allegedly isolated from the rest in that regard (i.e. they can freely choose) 19:32:41 On the flip side - we are still not quite done with the process, and we still have a rather large group left. 19:32:59 Last I heard, we are hoping to get it down to about 70 source packages. 19:33:52 Is that the group around curl? 19:34:07 nthykier: isshibboleth in that set? that's been one of the problematic ones iirc 19:34:22 is shibboleth 19:34:51 -> https://paste.debian.net/898166/ 19:34:57 That is the list I got 19:35:19 curl is there, but I think shibboleth isn't 19:36:49 Why is haskell-curl not? 19:36:49 what source package builds shibboleth again? 19:37:35 shibboleth-sp2 / shibboleth-resolver / moonshot-* 19:39:00 bunk: because it does not depend on libssl? 19:39:05 (is my guess) 19:39:38 the tool used uses binary (pre)-depends for computing this 19:39:43 oh and xml-security-c 19:39:48 ah, haskell does static linking, or? 19:40:52 bunk: it depends on libcurl-gnutls and libcurl-openssl-dev AFAICT 19:41:18 pochu: xml-security-c is the package I have been using as indicator :) 19:41:31 nthykier: You've seen my patch for libcurl4-openssl-dev? 19:41:37 xmltooling is also part of shibboleth 19:41:41 bunk: no, I haven't 19:42:22 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018#10 19:43:11 This forces 1.0.2 on all users of libcurl3. 19:43:40 ok 19:44:10 We should definitely enforce the same ssl version in curl and its rdeps 19:44:25 (from what I gathered so far) 19:46:45 Yes, I think anything using libcurl should probably use the same version. 19:46:57 At least if it's making use of those functions. 19:48:02 And that group of 70 is around libcurl yes 19:48:46 Hey Q_ :) 19:48:46 At least one of them is zurl, which says he switched because of QT5. I just send him an email. 19:49:18 I'm here (maintainer of zurl) 19:49:50 Q_: Am I correct in that openssl/1.1.0c-2 upload fixes all known RC bugs in openssl 1.1? :) 19:49:57 Yes 19:50:00 My current understanding is that zurl should use same version of openssl as libcurl, but qt is independent, as no internal structures are exchanged that way. 19:50:20 (excellent, been wanting ssl1.1 in testing for a while now) 19:50:46 yes, but it won't transition to testing until #844503 gets fixed 19:50:56 There is just a minor problem on hppa, and I guess you don't care about that. 19:51:20 pochu: you could remove salt from testing 19:51:26 I was about to say that 19:51:28 pochu: Does that Breaks really prevent the migration? 19:51:45 Q_: yes, because otherwise salt becomes uninstallable 19:51:54 Oh, right. 19:52:07 but it is marked for autoremoval. so I may remove it earlier to not stall openssl anymore 19:52:39 oh, upstream merged the patch 19:52:46 https://github.com/saltstack/salt/pull/37772 19:53:32 tag away 19:53:35 ok 19:53:47 There are at least 2 other packages in the libcurl grop with open RC bugs. One is php5. 19:54:00 I believe php5 was scheduled for removal? 19:54:20 yes, RM bug is waiting for rdeps to disappear 19:54:25 rather, php5 is not in testing 19:54:49 Ok, so I can ignore that. 19:54:53 yes 19:55:09 yeah 19:55:17 cgsi-gsoap was the other I know about 19:56:42 allegedly blocked by the voms ssl issue 19:56:46 Oh, and osslsigncode also uses libssl1.0-dev 19:56:50 #828595 19:59:27 So the big question we need to finish is - how big is this set really and what version do they need 20:00:04 For the rest, it seems like we have divided it into small enough bits to handle those. 20:00:56 voms has X509_STORE_CTX as part of its API, unless that's identical in 1.0.2 and 1.1 this is part of the curl group 20:01:59 Since we made it opaque, I can't guarantee it says the same anyway. 20:02:34 ok 20:03:11 So there are something around 5 packages in the libcurl group that are currently still on 1.0 20:03:17 We are running low on time, so I will have to cut it here (meeting-wise, you are welcome to continue this afterwards) 20:03:45 Assuming I can get all of them to support 1.1, I guess it's going to require an soname change in that case? 20:03:55 boost1.62 also uses X509_STORE_CTX in its headers 20:05:25 https://sources.debian.net/src/mysql-5.7/5.7.16-1/extra/yassl/include/openssl/ssl.h/?hl=115#L115 20:05:47 ah sorry that was a mysql file 20:06:20 https://sources.debian.net/src/boost1.62/1.62.0%2Bdfsg-1/boost/asio/ssl/verify_context.hpp/?hl=43#L43 20:06:30 bunk: boost actually doesn't show up in the list of libraries using libssl? 20:06:47 Oh, it'a asio. 20:09:50 I presume that means a(nother) boost transition? 20:09:59 for ssl1.1 to be the default 20:11:33 Ok - as said, we are out of time, so I will have to cut this short here. 20:11:46 #topic AOB 20:11:50 Any last minute items? 20:11:59 (and very short ones preferably) 20:12:16 not from me 20:12:23 nope 20:12:37 #topic Next meeting 20:13:03 Auto scheduled to Dec 28 2016 at 1900 UTC - does this seem sensible? 20:13:10 Dec 21st? 20:13:14 ah 20:13:24 So my current understanding is that zurl needs to use libssl1.0 because of QT5 anyway. 20:13:47 nthykier: it's christmas and I'll be on holidays. so I won't know if I can make it until an hour earlier :P 20:13:54 but fine with me 20:14:06 Q_: Did you get my mail? Probably 1.1 is fine as well, I think. 20:14:15 jannic: Writing to you. 20:14:18 ok 20:14:35 nthykier: give me an action for the sprint venue 20:14:40 pochu: ok 20:14:48 But let's just say it here. 20:14:55 #action pochu to work on the sprint venue 20:15:10 ta 20:15:21 wfm - I fear rescheduling to the 21st would mean a lot of busy people with no time anyway, so lets keep it simple :P 20:15:33 aye 20:15:41 #info Next meeting 28th of December at 1900 UTC 20:15:44 and with that .. 20:15:48 #endmeeting