19:00:44 #startmeeting 19:00:44 Meeting started Wed Sep 28 19:00:44 2016 UTC. The chair is jmw. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:44 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:48 #chair nthykier 19:00:48 Current chairs: jmw nthykier 19:01:06 right, it's wednesday, it's 19:00, and it's release time again :) 19:01:10 blurg 19:01:14 blerg 19:01:15 o/ 19:02:50 apparently it's a popular time for meetings :) 19:03:05 adsb: braincell. i want it back. 19:03:12 is it? 19:03:33 There is a jenkins meeting in #d-qa 19:03:38 ah 19:04:13 * h01ger waves 19:04:15 wonder if pochu is around 19:04:55 jcristau: sure, I don't appear to be using it much this evening 19:05:10 :) 19:05:43 oh well, maybe he'll catch us up 19:05:49 I do hope so :) 19:05:50 let's start 19:05:57 #topic Admin 19:06:22 #link http://meetbot.debian.net/debian-release/2016/debian-release.2016-08-24-19.05.html is the last minutes 19:06:41 I don't think we had any advance apologies this time 19:06:51 #topic MySQL/MariaDB variants 19:06:51 you may want to include http://meetbot.debian.net/debian-release/2016/debian-release.2016-07-27-19.00.html as well 19:07:03 #undo 19:07:03 Removing item from minutes: 19:07:05 nvm :) 19:07:59 #link http://meetbot.debian.net/debian-release/2016/debian-release.2016-07-27-19.00.html before those 19:08:03 #topic MySQL/MariaDB variants 19:08:17 #munin has a meeting in 30min :) (and thanks for teaching me MeetBot knows undo now!) 19:08:19 I have no idea where we are with this now, sorry 19:08:51 There are some default-mysql-* packages now and the next version of lintian will nag about some uses of "old" MySQL packages 19:09:02 I have been out of the loop for too long being vacationy or something 19:09:28 (see lintian commit 9044421b3c9261943556e297a924dd4bb69cdcae) 19:09:33 do they have the intended effect? :) 19:09:55 I did not check - I just hope so 19:10:04 fair enough 19:10:39 it does include libmysqlclient-dev, mysql-server(-core) and mysql-client(-core) packages 19:11:01 (which gets replaced by a "default-mysql-$something") 19:11:44 if nothing else, it is a decent start 19:12:48 the thing we mustn't lose sight of is deciding which ones will ship in stretch. but I don't think it's worth looking at that tonight 19:13:04 that's the point of this defaults excercise, after al 19:13:25 ok 19:13:55 should we move on? 19:14:09 yes 19:14:17 #topic Porter roll-call 19:14:19 ah this is yours 19:14:26 We completed the roll call 19:14:48 Except ppc and the waived architectures, all architectured had porters that replied in time 19:15:22 I got two topics further down about PPC and about the toolchain support issue 19:16:10 so this isn't where i ask if there's a reason not to disqualify ppc? 19:16:11 We also learned that we should have phrased the reply template differently (to push for more links from porters pointing to their contributions) 19:16:27 jcristau: nope - we will get there soon though :) 19:16:32 ack :) 19:17:00 * doko listens silently 19:17:13 But https://release.debian.org/stretch/arch_qualify.html is up to date with all the information I got (incl. toolchain and lack of porters) 19:17:50 anyway, lets move on if there are no remarks to the roll call 19:17:55 (itself) 19:18:31 nthykier: so mips* is still considered a candidate as a release arch? 19:19:06 doko: we will get to that a bit later - I got a topic about arch qual + upsteam support 19:19:32 great 19:19:35 next time it would be nice to include glibc in the toolchain 19:19:35 #topic Artwork 19:19:41 also yours :) 19:20:05 Yupe (ftr, I intended these to be a quick status since last time and not a dicussion point) 19:20:08 is there a agenda for the meeting? 19:20:32 We got a bunch of artwork - I failed on doing a selection / vote for finding the default 19:21:02 We also got a proposal from mbiebl about including all of the artwork (in a separate package). I like that idea, so I intend to encourage it 19:21:13 EOT for me (unless there are questions) 19:21:19 doko: yes, in the gobby 19:21:27 (see /topic ) 19:21:44 #topic Secure boot status 19:22:04 should probably make some notes about these 19:22:08 #undo 19:22:08 Removing item from minutes: 19:22:09 #undo 19:22:09 Removing item from minutes: 19:22:22 (ok, waiting for you before starting) 19:22:24 #undo 19:22:24 Removing item from minutes: 19:22:43 #info There are some default-mysql-* packages now and the next version of lintian will nag about some uses of "old" MySQL packages 19:23:00 #info We still need to evaluate variants for Stretch when the alternative system is feasible 19:23:05 #topic Porter roll-call 19:23:17 #info Porter information has been updated in https://release.debian.org/stretch/arch_qualify.html 19:23:22 #topic Artwork 19:23:35 #info Artwork has all been collated 19:24:00 #action nthykier Encourage shipping all artwork in a package 19:24:10 #action nthykier Organise selection/voting of some sort 19:24:17 ack 19:24:21 #topic Secure boot status 19:24:23 ok I'm done 19:24:25 thanks 19:25:01 To my knowledge: shim got uploaded and rejected (due to d/copyright). Allegedly this should have a patch and is waiting for vorlon to reupload 19:25:32 We also got a successful linux signing test by jcristau, which allegedly works albeit taking ~25 minutes to complete 19:26:00 jcristau: did I miss any other noteworthy changes in the past month? 19:26:03 #info shim package is in progress and awaiting an upload 19:27:00 is the signing thing the effort towards being able to sign builds on debian infrastructure? 19:27:03 as I understand it, the signing code has not been merged yet (but we did just get a patch to make it run with a different user) 19:27:15 we've got tentative dak patches, no ftpmaster input yet 19:28:16 and i'm not sure whether to set this up on franck or wait until we move to fasolo, that's also in ftpmaster hands 19:28:21 mostly 19:28:41 . 19:28:41 #info linux signing infrastructure is in progress; there are tentative patches for dak but need ftp-master input 19:29:37 done from me as well 19:29:39 jcristau: are you best placed to keep that rolling with ftp-masters? 19:30:04 i guess 19:31:10 #action jcristau to continue progressing 19:31:50 if you have time, makes sense 19:32:54 Next topic? 19:33:17 #topic PIE by default for Stretch 19:33:25 all teh topics for nthykier :) 19:33:34 "Propose ALL the topics!" 19:33:35 :P 19:33:55 ftwca topics 19:33:58 Should we go with PIE by default for Stretch? 19:34:11 probably 19:34:20 The majority of all porters across all ports (with porters) believed their port was ready 19:34:48 I understand that there are some blockers (e.g. rebuilding some static libraries with PIE in order) for this to be done 19:35:20 presumably the downside is possible bugs in binaries? 19:36:07 Plus there can be slow downs on register-starved architectures (except i386, which got fixed in gcc-5) 19:36:52 what are the register starved architectures beside x86? 19:36:56 which arches are those? 19:36:59 There will also be packages that need to disable PIE because they do "magic" (e.g. some asm) 19:37:36 jmw: aurel32: Standard disclaimer - did not map it to the Debian release architecture, since I don't know any arch beyond x86 19:37:43 ok 19:37:57 ok 19:38:24 anyway, if we want the change in GCC, I suspect doko would like an answer "really soon now" 19:38:28 #info could reveal bugs in built binaries (but those should be fixed or PIE disabled) 19:39:01 saw it at least on arm32 19:39:38 #info can cause slowdowns in register-starved architectures, including i386 (fixed in gcc5) and arm32 19:39:41 I'm a bit concerned about the attitude of porters: "we don't know issues, let's do it" 19:40:10 at least the various arm ports should have resources for a test rebuild 19:40:30 #info majority of porters believe their architecture is ready 19:40:45 do problems cause build failures or just buggy binaries? 19:40:51 doko: are we concerned about build failures or miscompilation? 19:40:58 bah. 19:41:32 Most of the issues I am aware of will be FTBFS (which is not to say that there will be no runtime issues) 19:42:19 for build failures, worst case some arch breaks, and either the porters fix it or the pie change gets reverted? 19:42:24 jcristau: you usually can fix ftbfs with no-change rebuilds 19:43:08 so there is other fun about pie/pic interactions, however these shouldn't be arch specific 19:43:29 ok 19:43:31 so yes, my concerns are miscompilations. I think nobody tried to build a distro on arm* mips* with pie before 19:44:24 if porters think their arches are ready, now is the time to throw the switch and try it I guess 19:44:26 and I don't see a point when there are plans to drop an arch for buster to add new problems for stretch, it's not worth it, and porters for these archs might have to fight other fires 19:44:42 we can always roll it back globally or per-arch or disable it per-package, so we have some options if it's too much chaos 19:45:07 but it *is* quite late in the cycle 19:45:10 disabling per package is "fun" 19:45:25 because -fno-pie turns off -fpic as well :-/ 19:46:16 There is also the option of using the dpkg-buildflags approach, where dpkg adds a "compiler-spec" file to selectively enable it 19:46:40 nthykier: selectively based on what? 19:46:52 Ah no, it would have the same issue with disabling it 19:47:00 if we consider rolling back, is there a reliable way to tell which packages were built with pie? scraping build logs sounds unreliable to me. 19:47:38 file tells it 19:47:51 jcristau: based on which compiler flags are passed 19:47:59 (AFAICT) 19:48:04 doko: otoh a number of binaries/packages are built with PIE on all archs for a few years and nobody noticed it was broken, afaik? 19:48:18 nthykier: selectively enabling will lead to intersting issues, when you first have to rebuild a library 19:48:27 jcristau: https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/dpkg-buildflags-pie-gcc-specs&id=ad4854b4b4711dd49e39371280f0609f8b81c2a6 19:48:50 doko: the static library issue? 19:49:09 jcristau: sure this is a subset. do you know how many of them worked initially? 19:49:14 nthykier: yes 19:49:49 doko: but we could use it for disabling PIE "per package"? 19:49:52 doko: i don't. presumably some of them have build-time tests, too. 19:50:10 doko: also, if stuff breaks and it's too late to revert, it's an argument to disqualify that arch, which might make you happy ;) 19:50:57 nthykier: in principle yes, except for uncommon build systems, where you can't directly influcence the order of rhe -fno-pie and -fpic arguments (as in openjdk) 19:51:23 doko: ok 19:51:24 (:51, we might want to move on) 19:52:03 jcristau: well, this is a release-selfish approach then, because you leave it broken as a port 19:52:12 yes 19:52:33 but when did debian care about ports ... 19:52:54 i think it's fair for the release team to be concerned about release architectures 19:53:04 ommv 19:53:32 that's maybe a topic for another meeting =) 19:54:07 Should I send out a mail to d-release about enabling PIE by default and see what the other members say? If there are no major concerns within a week, we would go for PIE by default? 19:54:16 sgtm 19:54:53 #action nthykier Send mail to d-release about enabling PIE by default! If there are no major concerns brought up within a week, Stretch will go with PIE by default 19:55:00 ok, lets move on then 19:55:06 wfm 19:55:24 #topic Architectures: upstream toolchain support 19:55:25 pleae make sure to get one or two persons per arch who work on fixing these 19:55:36 pic issues when they arise 19:55:45 doko: ok 19:56:12 just speaking out of experience enabling pie in another distro ... 19:56:37 nthykier: is this and the next topic not really architecture qualification? 19:57:08 jmw: kind of. You want to move it to a separate meeting ? (Would WFM given we are running out of time) 19:57:23 let's arrange the arch-qual meeting instead 19:57:24 #undo 19:57:24 Removing item from minutes: 19:57:30 #topic Architecture qualification 19:57:47 jmw: well, it's listed as release criteria, isn't it? 19:58:35 it is, that doesn't mean it needs its own slot outside the normal qualification process 19:58:44 unless you have a particular concern you want to bring up earlier than that? 19:59:46 for arch-qual, we have this meeting in october, november or december if that works (though december is getting a little late for my comfort, personally. also holidays) 20:00:13 or we could arrange something at the cambridge miniconf if we have enough people 20:00:23 We might want to do an out of band one 20:00:36 or we could arrange something else 20:00:41 what nthykier said :) 20:01:40 maybe a doodle poll is a good move here. but what kind of window? October? November? 20:02:20 jmw: I say we do it off-line - I suspect there will be sufficient turn up for doing it at Cambridge 20:03:34 Or latter half of October / first 2 weeks of November 20:04:08 #action jmw organise architecture qualification in late October or early November 20:04:22 that do? 20:04:27 yupe 20:04:35 #topic mips64el 20:04:43 no idea what the status of this is 20:05:28 mips64el looks reasonably stable from an installability PoV, so it might make sense to move it out of "F***ED_ARCHES" and "BREAK_ARCHES" 20:05:43 (assuming the perl transition does not completely bork it) 20:06:17 suits me, but I have very little investment so... :) 20:06:25 I think I will just do that and then we can remvert it, if there is an issue 20:06:31 revert* 20:06:45 #action nthykier promote mips64el to BREAK_ARCHES, revert if there are issues 20:06:46 right 20:06:46 lack of mariadb on mips64el makes the libmysqlclient switch kinda icky 20:06:55 oh hm 20:06:56 if mips64el starts counting 20:07:08 #undo 20:07:08 Removing item from minutes: 20:07:17 you wuss :p 20:07:28 #action nthykier promote mips64el to BREAK_ARCHES once libmysqlclient is available on mips64el, revert if there are issues 20:07:28 indeed 20:07:36 ok 20:07:47 the problem has been reported upstream there: https://jira.mariadb.org/browse/MDEV-10417 20:07:59 nthykier: you had a space on that command, I don't think meetbot will see it 20:08:05 #action nthykier promote mips64el to BREAK_ARCHES once libmysqlclient is available on mips64el, revert if there are issues 20:08:06 and Vicentiu Ciorbaru got an account on the porter box to look at that 20:08:19 cool 20:08:22 EOT for me 20:08:29 -ERROR HY000: Error dropping database (can't rmdir './testing_1', errno: 39 "Directory not empty") 20:08:29 but if it becomes more critical we can try to have more people looking at it 20:08:32 +ERROR HY000: Error dropping database (can't rmdir './testing_1', errno: 93 "Directory not empty") 20:08:37 #info the problem with mariadb is upstream: https://jira.mariadb.org/browse/MDEV-10417 20:08:54 is that some kind of ^t just to spite people? :) 20:10:00 moving on? 20:10:05 yesplz 20:10:10 (ofm) 20:10:13 #topic Release schedule 20:10:22 #info Linux - 4.9 will be LTS, presumably November 20:10:38 I'll put my cards right down and say we don't change our plans 20:10:57 +1 20:10:57 Ack 20:10:57 but I'm open to persuasion 20:11:11 even though that gives us slightly less time with stretch as stable and kernel upstream support overlapping 20:11:31 *crickets* 20:11:40 winner. 20:11:41 I expect gcc-6.3 in december, same with python 2.7.13 and 3.5.3 20:12:07 #agreed Stick to the published schedule to avoid confusion 20:12:11 so you want to shorten the schedule by two months? 20:12:17 ahh, ok 20:12:34 so much for avoiding confusion :) 20:12:41 #topic Mini-Debconf Cambridge 20:13:05 i'd like to go. will try to confirm next week. 20:13:16 we have the option of meeting space at cambs again if we want it, I think: will it be worth doing that or shall we just ad-hoc? 20:13:42 jmw: coordinate in e-mail since there's only 3 of us now? 20:13:47 ok 20:13:52 +1 20:14:04 #action jmw find out about meeting space requirements 20:14:13 * doko has to leave, will read backlog ... 20:14:18 I'm going to skip the spain sprint, with pochu not here 20:14:18 I'm vaguely still around, having to poke stupid things for being stupid for no apparent reason though 20:14:27 #topic AOB 20:14:29 any? 20:14:39 nope 20:14:44 no 20:15:14 #topic Next meeting 20:15:16 Britney patches have been submitted for review 20:15:20 #undo 20:15:20 Removing item from minutes: 20:16:03 #info Britney patches have been submitted for review - deadline Oct 03 for comments 20:16:09 * nthykier . 20:16:09 ok 20:16:11 #topic Next meeting 20:16:24 26th of Oct according to the release calender 20:16:38 #info Next meeting: 2016-10-26 19:00UTC 20:16:45 \o/ 20:16:54 jmw: thanks for running this. nthykier: thanks for all the topics :) 20:16:55 so nthykier, that's 20:00 real time :p 20:17:16 #endmeeting