18:00:09 <paragan> #startmeeting FESCO (2015-08-05) 18:00:09 <zodbot> Meeting started Wed Aug 5 18:00:09 2015 UTC. The chair is paragan. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:09 <paragan> #meetingname fesco 18:00:09 <paragan> #chair ajax dgilmore number80 jwb nirik paragan rishi thozza sgallagh 18:00:09 <paragan> #topic init process 18:00:09 <zodbot> The meeting name has been set to 'fesco' 18:00:09 <zodbot> Current chairs: ajax dgilmore jwb nirik number80 paragan rishi sgallagh thozza 18:00:18 <nirik> morning. 18:00:23 <rishi`> evening 18:00:25 <paragan> Hi 18:00:38 <ajax> howdy 18:00:38 <sgallagh> Guten tag 18:01:21 <jwb> hell 18:01:22 <jwb> er 18:01:23 <jwb> hello 18:01:42 <sgallagh> jwb: Either way, really 18:01:56 <jkurik> hi 18:02:20 <paragan> okay let's start 18:02:20 <paragan> #topic 1455 F23 System Wide Change: Standardized Passphrase Policy 18:02:20 <paragan> .fesco 1455 18:02:20 <paragan> https://fedorahosted.org/fesco/ticket/1455 18:02:22 <nirik> so I wrote this up... 18:02:22 <zodbot> paragan: #1455 (F23 System Wide Change: Standardized Passphrase Policy) – FESCo - https://fedorahosted.org/fesco/ticket/1455 18:02:36 <nirik> but wanted folks to look it over again (since I changed some wording) 18:02:49 <nirik> and also to talk about luks passwords (which I didn't address). 18:03:11 <number80> o/ 18:03:12 <nirik> https://fedoraproject.org/wiki/Passphrase_policy 18:03:19 <nirik> anyone find anything they would prefer to change there? 18:03:33 <dgilmore> hi 18:04:05 <paragan> luks uses libpwquality so the new proposed rules for libpwquality will also applied to luks? 18:04:42 <sgallagh> nirik: I might explicitly state that the "score" must not be used as a decision-making factor 18:04:43 <nirik> paragan: nope... it doesn't. anaconda calls pwquality directly for it 18:04:47 <nirik> +pwpolicy luks --strict --minlen=8 --minquality=50 --nochanges --emptyok 18:05:12 <nirik> sgallagh: good idea. 18:05:35 <ajax> looks sane enough to me 18:05:43 * nirik edits 18:06:41 <nirik> ok, cryptsetup is linked to libpwquality. cool. . 18:07:19 <paragan> wording looks good to me 18:07:27 <jkurik> nirik: are we still aiming with the Change to F23 ? 18:07:30 <nirik> anyhow, I guess we can ask that luks use the same policy for now and adjust if we want it to be different later? 18:07:44 <nirik> jkurik: yeah, but it will have to be after alpha now. ;( 18:08:17 <jkurik> will not be better to postpone it to F24 ? 18:08:20 <nirik> I think thats better than defering it. 18:08:40 <paragan> yes good to have it in F23 18:08:41 <nirik> well, we could, but I personally don't want to read all the flames. 18:08:58 <nirik> so I am for getting it into f23. The anaconda changes shouldn't be too major. 18:09:06 <nirik> and gnome-intial-setup will need a few 18:09:08 <nirik> and thats it. 18:09:55 <rishi`> Sounds reasonable to me, but I don't work on anaconda. :) 18:10:02 <rishi`> Did we run this past the anaconda team? 18:10:17 <nirik> rishi`: I have been talking with dcantrell yes 18:11:02 <sgallagh> Yeah, from what dcantrell has said to me, they're prepared to run with it once it's approved. 18:11:18 <dgilmore> I am good with what is propossed 18:11:20 <paragan> proposal: Accept https://fedoraproject.org/wiki/Passphrase_policy and use this for luks passwords also 18:11:24 <dgilmore> +! 18:11:25 <dgilmore> +1 18:11:29 <sgallagh> They just mostly want to have something to point at the next time someone complains about their favorite pet-peeve not being addressed by the current implementation 18:11:31 <nirik> +1, sounds good to me. 18:11:37 <ajax> +1 18:11:37 <sgallagh> +1 18:11:39 <paragan> +1 18:11:42 <jwb> +1 18:11:42 <nirik> sgallagh: yes, and that will be us. :) we have to be good for something. 18:12:50 <paragan> #agreed: Accept https://fedoraproject.org/wiki/Passphrase_policy and use this for luks passwords also (+6, 0, 0) 18:12:52 <rishi`> +1 18:12:57 <paragan> #undo 18:12:58 <zodbot> Removing item from minutes: AGREED by paragan at 18:12:50 : : Accept https://fedoraproject.org/wiki/Passphrase_policy and use this for luks passwords also (+6, 0, 0) 18:13:07 <paragan> #agreed: Accept https://fedoraproject.org/wiki/Passphrase_policy and use this for luks passwords also (+7, 0, 0) 18:13:14 <nirik> I'll file the bugs and move things forward. Thanks. 18:13:31 <paragan> nirik, thanks 18:13:35 <paragan> #topic 1463 upgrades for F23 and beyond 18:13:35 <paragan> .fesco 1463 18:13:35 <paragan> https://fedorahosted.org/fesco/ticket/1463 18:13:36 <zodbot> paragan: #1463 (upgrades for F23 and beyond) – FESCo - https://fedorahosted.org/fesco/ticket/1463 18:14:30 <nirik> this was posted to the devel-announce list last week... 18:14:32 <dgilmore> I am +1 the devs are willing to support this and not the old way 18:14:34 <nirik> and got 0 replies. ;) 18:14:42 <nirik> +1 to the change 18:15:01 <number80> +1 18:15:02 <paragan> I think we already approved this but for the process let's vote again 18:15:10 <paragan> +1 18:15:29 <number80> I don't think there are any other alternative :) 18:15:46 <rishi`> +1 18:16:13 <ajax> i can't imagine what good it would do to reject this 18:16:14 <ajax> +! 18:16:36 <paragan> nirik, I see discussion happening on rpm-ecosystem list for this fedup change 18:16:46 <nirik> some yeah. 18:16:49 <sgallagh> Yeah this is moving ahead 18:17:08 <sgallagh> And likely will regardless of our vote, so might as well support it (since it makes sense and is a good approach as well): +1 18:17:17 <rishi`> Do we need to decide whether to deprecate fedup or entirely remove it? 18:17:46 <dgilmore> rishi`: I think wwoods wants it taken out back and shot 18:18:07 <rishi`> Yes that was my assumption from the "indentify maintainer" part. 18:18:16 <dgilmore> rishi`: he was talking about sending in patches so we no longer make the upgrade.img initramfs 18:19:04 <paragan> #agreed: Accepted https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades (+7, 0, 0) 18:19:14 <rishi`> Ok 18:19:34 <paragan> #topic #1466 non-responsive maintainer exception process for skottler 18:19:35 <paragan> .fesco 1466 18:19:35 <paragan> https://fedorahosted.org/fesco/ticket/1466 18:19:36 <zodbot> paragan: #1466 (non-responsive maintainer exception process for skottler) – FESCo - https://fedorahosted.org/fesco/ticket/1466 18:19:49 <paragan> Looks like this is in progress and will take some more time. 18:19:53 <jwb> well, sort of 18:19:58 <jwb> here's an update 18:20:26 <jwb> i contacted sam. he replied saying that he likely doesn't have time to maintain most of his packages and will begin the orphan process for them at some point 18:20:49 <jwb> however, he implied that he would still maintain the packages he uses, nagios-plugins being explicitly listed 18:21:13 <jwb> for nagios-plugins, there is the on-going upstream debate that i think we should frankly avoid at this point 18:21:28 <jwb> the CVE fixes, afaik, are all fixed in the 2.0.3 release 18:21:42 <jwb> i have a local build of that, but i have no realistic way to test 18:21:50 <jwb> so the options seem to be: 18:21:56 <jwb> 1) wait longer 18:22:08 <jwb> 2) have me commit and build the 2.0.3 update to fix the CVEs 18:22:23 <jwb> 3) proceed with non-responsive maintainer despite sam's reply 18:22:34 <jwb> <end of update> 18:22:48 <dgilmore> I do not think we shoudl wait longer 18:22:56 <ajax> 2 18:22:58 <rishi`> I prefer (2). 18:23:03 <paragan> option 2 18:23:13 <sgallagh> I'm of the opinion that the upstream debate should run its course and if monitoring-plugins wants in, it should have its own named package as the fork it is 18:23:16 <rishi`> If something breaks, then either they will fix your build, or revert it. 18:23:17 <number80> I suggest 4) allow infra sysadmins to grant ACLs requests on skottler packages 18:23:19 <sgallagh> I'm for 2) as well 18:23:24 <jwb> it's worth pointing out that solution 2 is only a temporary fix to the on-going MIA problem 18:23:27 <number80> we did that recently for kanarip 18:23:30 <rishi`> Hopefully, a revert would come with an explanation. 18:23:35 <jwb> sgallagh, there is actually a package review for it already done 18:23:37 <nirik> I would also go for 2 and add that we have a nagios setup and would be happy to test your package before it goes in. 18:24:06 <jwb> number80, to whom? i already have the needed ACLs 18:24:31 <dgilmore> jwb: we need to get the CVE's fixed. so its a good bandaid, however we need something else long term. I do not think waiting is a good option for very long. 18:24:33 <number80> jwb: to any people who requested it, there must be someone who started the non-responsive process 18:24:59 <number80> if their goal is to maintain some packages, let's give them acls directly 18:25:21 <swilkerson> that would be me,, I have already offered to take the package 18:25:25 <jwb> number80, nb started it but suggesting reassigning to upstream nagios. which is where the upstream debate comes in 18:25:50 <number80> swilkerson: did you request ACLs? 18:26:00 <jwb> no 18:26:11 <number80> then, I would say 2. 18:26:20 <swilkerson> It was proposed here https://bugzilla.redhat.com/show_bug.cgi?id=1098548#c14 18:26:32 <rishi`> number80: My understanding was that Sam doesn't want swilkerson to be a co-maintainer. 18:27:05 <number80> rishi`: then, he has to choose: maintain it and let swilkerson do it 18:27:17 <nirik> (co)maintainers that don't get along don't seem like a very good idea. Longer term it seems like sam should take monitoring-plugins and swilkerson could take over nagios-plugins... but we aren't there yet? 18:27:39 <jwb> nirik, yes and tbh i'm not sure we'll get there 18:27:53 <nirik> that makes me sad, but ok 18:28:04 <swilkerson> nirik: I agree with that 18:28:49 <paragan> I think for now option 2 is good and all are voted +1 for it 18:28:50 <number80> nirik: I prefer a maintainer that is responsive than one who is not, though I appreciate skottler, if I had to chose, I'd reassign it to swilkerson in these conditions 18:28:55 <sgallagh> In general, I'd much rather side with giving upstream control over the nagios-plugins package than let a fork take over the name 18:29:07 <sgallagh> That seems disingenuous to our users 18:29:14 <number80> *nods* 18:29:16 <jwb> nobody is talking about doing taht here 18:29:32 <ajax> in the meantime, yes, let's nmu the thing and play politics later. 18:29:35 <sgallagh> jwb: It sounds like that's exactly what skottler is doing 18:29:41 <nirik> so, lets do 2 now and keep trying to come to some arrangement? 18:29:55 <jwb> sgallagh, skottler isn't _doing_ anything which is the whole point of this conversation 18:30:05 <jwb> we'd be having a different conversation if he was 18:30:38 <sgallagh> I'm fine with 2) as a stopgap measuer 18:31:12 <jwb> ok. i'll commit it and file an update. i will also inform skottler that we did so 18:31:12 <number80> yes, we need to move forward with 2. but I'd rather have a long-term solution quickly 18:32:13 <paragan> let's approve option 2 then 18:32:42 <number80> *nods* 18:32:56 <paragan> #agreed: jwb to commit and build the 2.0.3 update to fix the CVEs (+8, 0, 0) 18:33:47 <paragan> we done with the Agenda topics 18:34:09 <paragan> Should we discuss https://fedorahosted.org/fesco/ticket/1467? 18:34:20 <paragan> jkurik, is there any update on ^^? 18:34:27 <paragan> .fesco 1467 18:34:29 <zodbot> paragan: #1467 (F23 Changes - Progress at Change Checkpoint: Completion deadline (testable)) – FESCo - https://fedorahosted.org/fesco/ticket/1467 18:35:37 <paragan> I don't know how the next process is for Changes remained in NEW/ASSIGNED state 18:35:47 * rishi` has to run now 18:36:01 <rishi`> Need to pack for GUADEC. 18:36:08 <paragan> no problem 18:36:20 <number80> rishi`: travel safe to sweden :) 18:37:14 <sgallagh> Happy trails 18:37:24 <nirik> safe travels rishi` 18:37:32 <sgallagh> paragan: At this point, FESCo really should rule on whether these features must be deferred to F24 18:38:00 <paragan> I am already in favor to move them to F24 18:38:11 <jkurik> paragan: I am going to update the ticket, give me a while 18:38:41 <number80> as for atomic and layered docker image, as they don't impact release, we should allow them to remain for F23 18:39:37 <paragan> I think that will be considered as an exception to Changes process 18:40:06 <dgilmore> number80: we plan to have both of those in place for BEta 18:40:10 <number80> yes, but deferring these would not do a favour to the atomic host 18:40:26 <number80> dgilmore: all the more a reason, not to defer them to F24 18:40:32 <dgilmore> we are still figuring out all teh tooling 18:41:46 <number80> dgilmore: what's the best course in your opinion? deferring to F24 or keeping it for F23? I'm know aware of all the infra discussions for atomic 18:41:53 <number80> s/know/not/ 18:42:20 <dgilmore> number80: I would keep for f23 at this point and evaluate at Beta Freeze 18:42:33 <number80> dgilmore: thanks for your feedback 18:43:15 <number80> proposal: reevaluate 2 weeks atomic + layered docker image for inclusion in F23 at beta freeze 18:43:29 <dgilmore> +1 18:43:34 <number80> (implicit: all remaining features should be deferred to F24) 18:43:36 <number80> +1 18:43:38 <nirik> are we going to go over each item? or were we waiting for jkurik to update things? 18:43:45 <nirik> but sure, +1 on that 18:43:57 <jkurik> Except the following two Changes: 18:43:58 <number80> nirik: yeah, not reevaluating each of them :) 18:43:58 <paragan> I am fine with number80 proposal 18:43:58 <jkurik> 1238411 Two Week Atomic 18:44:00 <jkurik> 1243736 Layered Docker Image Build Service 18:44:02 <jkurik> I would recommend to defer these Changes to F24. 18:44:12 <number80> jkurik: thanks :) 18:44:16 <sgallagh> Which is I think the exact proposal. 18:44:19 <sgallagh> I agree; +1 18:44:26 * nirik looks at the rest of the list. 18:45:11 <nirik> there's a lot of them 18:45:13 <number80> as far as I know, other cloud proposals are not ready 18:45:31 <sgallagh> The Node.js stuff is nowhere near ready 18:45:33 <paragan> there is no update on nodejs changes 18:45:33 <number80> especially networkd one 18:45:56 <sgallagh> ditto io.js 18:46:05 <roshi> we've still got a long discussion for networkd 18:46:11 <roshi> to be talked about at flock 18:46:12 <sgallagh> The dnssec and glibc ones are the only ones I'm unsure about 18:46:14 <paragan> we have then Local DNF Resolver Change 18:46:27 <number80> roshi: which means it has to be deferred to F24 ;) 18:46:30 <roshi> the cloud WG knows it'll be F24 at the soonest 18:46:51 <nirik> sgallagh: me too I think. 18:47:15 <paragan> I talked with mfabian and moved glibc Change bug to F24 18:47:21 <nirik> paragan: ah, ok. 18:47:28 <sgallagh> paragan: OK great 18:47:49 <number80> so we continue voting the current proposal or amend it? 18:47:57 <sgallagh> So last I heard, the DNSSEC thing was in a bit of a confused state because the Workstation folks and DNS folks only came to agreement very recently 18:48:29 <nirik> I'm +1 to moving all them to f24 except those two (two week atomic/layered docker images) 18:48:39 <paragan> nirik, +1 18:48:54 <nirik> and then if some of them turn out to be ready, the change owners can come tell us and we can revisit next week. 18:49:02 <number80> nirik: good point 18:49:04 <sgallagh> Reasonable, I guess 18:50:52 * nirik goes to get more coffee while others vote. 18:50:56 <paragan> votes please? 18:51:15 <sgallagh> +1 (again) 18:51:53 <number80> still +1 18:52:20 <paragan> looking back I count 5 +1's 18:53:29 <paragan> #agreed: moving all them to f24 except these (two week atomic/layered docker images) Changes, (+5, 0, 0) 18:53:41 <paragan> #topic Next week's chair 18:53:50 <sgallagh> Are we meeting next week? 18:53:50 <paragan> Next week is Flock!! 18:53:54 <number80> next week will be flock :) 18:54:03 <sgallagh> So probably not 18:54:05 <paragan> I think most people are attending Flock next week so I propose the cancel the meeting next week. 18:54:11 <sgallagh> Seconded 18:54:21 <number80> +1 18:54:33 <jwb> yes 18:54:49 <nirik> yeah, no meeting next week... there was a ticket for a 'meet your fesco' wasn't there? 18:54:53 <paragan> #info no meeting next week 18:54:57 <jwb> yes 18:55:05 <paragan> .fesco 1431 18:55:07 <zodbot> paragan: #1431 (Meet Your FESCo at Flock) – FESCo - https://fedorahosted.org/fesco/ticket/1431 18:56:18 <nirik> 4:30pm on thursday 18:56:27 <nirik> http://flock2015.sched.org/event/85fbdf579fa91c49ba13d45a9c1774eb 18:58:07 <paragan> while we discuss this... 18:58:10 <paragan> Who want to chair for 19th August meeting? 18:58:32 <number80> I'll be flying home on 19th 18:58:51 <jwb> i will miss the 19th as i'll be at LPC 18:59:07 * nirik may be busy rolling out bodhi2 then... 18:59:21 <sgallagh> I can do it, I guess 18:59:29 <sgallagh> If we even have quorum that day... 18:59:30 <number80> sgallagh: thanks 18:59:43 <paragan> sgallagh, thanks 19:00:06 <paragan> #info sgallagh to chair next meeting 19:00:35 <paragan> #topic Open Floor 19:00:39 <jwb> FYI, updates for nagios-plugins filed 19:00:45 <sgallagh> jwb++ 19:00:57 <adamw> did the fedup stuff get discussed/decided yet? 19:00:58 <sgallagh> Do we want to discuss i686 in any capacity today? 19:00:58 <paragan> jwb, thanks for quick update on ticket also :) 19:01:05 * dgilmore has one thing 19:01:08 <adamw> sgallagh: i certainly do, but i also had fedup 19:01:12 <sgallagh> adamw: Yes, we approved the Change 19:01:14 <adamw> rgr 19:01:22 <adamw> dgilmore: your thing is probably same as mine? 19:01:44 <nirik> I'd like to note #fedora-flock is open for flock related discussions and remote folks who want to see whats going on at flock. ;) 19:02:02 <dgilmore> 32 bit x86 cloud image is failing to install, anaconda is some kind of special pain. 19:02:16 <dgilmore> the cloud sig has said they do not want to build i386 images 19:02:29 <adamw> ref: https://fedorahosted.org/cloud/ticket/106 19:02:50 <dgilmore> can we consider it non blocking? 19:03:00 <dgilmore> adamw: I think we are on the same page 19:03:26 <dgilmore> since we do not have a list of deliverables and their blocking status its a bit up in teh air 19:03:27 <nirik> +1 to 32bit cloud image being non blocking for f23. 19:03:29 <dgilmore> the air 19:03:44 <nirik> dgilmore: so, an image isn't even made right now? or ? 19:03:48 <dgilmore> if it is blocking then we will have to slip Alpha as we debug the issue 19:04:02 <number80> +1 19:04:04 <dgilmore> nirik: I will have to turn off attempting it 19:04:12 <dgilmore> but it fails to install 19:04:24 <dgilmore> and the output from imagefactory is not at all helpful 19:04:31 <nirik> well, my question is because I'm fine with not shipping it if it's broken, but I don't think we should ship a broken iso out. 19:04:44 <paragan> +1 consider 32bit cloud image as non blocking 19:04:46 <adamw> for the record, cloud images are built by running an install in a somewhat special mode, so what the means is basically 'the image doesn't build'. 19:04:48 <nirik> s/iso/qcow2 or raw/ 19:05:00 <nirik> thats fine. :) 19:05:11 <dgilmore> nirik: well if it is non blocking because we know it is not working I will disable its generation 19:05:17 <dgilmore> it will not be made or ship 19:05:27 <jwb> if cloud doesn't want a 32-bit image, then why are we even attempting to ship one? 19:05:43 <nirik> fine also. I just wanted to make sure we didn't say it was non blocking and shipped the broken thing. 19:05:55 <dgilmore> jwb: I only know they don't because I follow their list 19:06:09 <dgilmore> they have not done anything to actually make it happen 19:06:15 <jwb> sigh 19:06:22 <jwb> well, this seems pretty easy to 'make it happen' 19:06:26 <dgilmore> they have not filed any tickets, updated their PRD etc 19:06:49 <number80> damnit 19:07:23 <number80> PRD was updated, but likely not submitted for review ... 19:07:33 <dgilmore> https://fedoraproject.org/wiki/Cloud/Cloud_PRD?rd=Cloud_PRD 19:07:36 <adamw> dgilmore: well, per earlier discussion they didn't really know what the process was. 19:07:50 <dgilmore> it says "we will target 32 and 64-bit x86" 19:08:08 <sgallagh> I'm fine with not blocking on 32-bit images if Cloud WG isn't keen on it. 19:08:34 <number80> sigh, ok, I'll put it in cloud SIG meeting agenda next week 19:08:37 <adamw> from a process POV, so far as I'm concerned all that needs to change to make this policy is the Cloud PRD 19:09:01 <dgilmore> adamw: and make sure that releng knows about teh change 19:09:04 <dgilmore> the 19:09:13 <adamw> the criteria already allow for flavor WGs to not deliver images for particular arches at their discretion (though i'm not sure how many people are aware of that) 19:09:15 <adamw> dgilmore: right. 19:09:59 <nirik> right, make it so... next? 19:10:14 <adamw> assuming fesco +1s it we'll consider it 'done' for 23 Alpha, i.e. we're not gonna block Alpha on the missing image. 19:10:31 <jwb> fesco doesn't need to +1 a WGs decision 19:10:37 <jwb> particularly not on their own output 19:10:38 <adamw> OK, i think that was the part that wasn't clear 19:11:06 <adamw> since there's a sort of overlap between the flavor WGs' 'autonomy' or whatever and the distro-wide concept of primary arches 19:11:21 <adamw> i think that's why cloud wasn't sure they could just go ahead and say 'no more i686' 19:11:28 <jwb> fair, but they can 19:11:38 <jwb> now if we can get workstation and server to do the same, i would be so happy 19:11:42 <adamw> =) 19:12:30 <sgallagh> jwb: I'd be thrilled to drop i686 install media, but every time it comes up, the "I have a 30-year-old server in my closet" people show up 19:13:09 <jwb> i don't think carrying something along for the benefit of people that have 0 interest in creating and maintaining that something is a good idea 19:13:32 <jwb> i686 limps along because it isn't terribly broken. not because someone is invested in its success 19:13:46 <jwb> and that is a model for failure in a number of ways 19:13:56 * dgilmore does not care much either way. my main concern would be OLPC, but that is kinda almost dead, at least on i686 19:13:59 <adamw> sgallagh: there doesn't seem to be a pile of enthusiasm in the current devel@ thread. maybe dinosaurs are finally dead? 19:14:35 <sgallagh> adamw: roshi just pestered me about hit 45 minutes ago :-P 19:14:38 <nirik> adamw: give them time, it takes a while to load the mail reader on i686. ;) 19:14:48 <adamw> heh. 19:15:02 <adamw> 'i'm still inflating the airbags, damnit' 19:16:35 <paragan> If there's nothing else to discuss, I will close the meeting in 2 minutes 19:18:04 <paragan> #endmeeting