16:00:29 #startmeeting FESCO (2016-08-19) 16:00:29 Meeting started Fri Aug 19 16:00:29 2016 UTC. The chair is maxamillion. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:29 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:29 The meeting name has been set to 'fesco_(2016-08-19)' 16:00:37 #meetingname fesco 16:00:37 The meeting name has been set to 'fesco' 16:00:37 #chair maxamillion dgilmore jwb nirik paragan jsmith kalev sgallagh Rathann 16:00:37 Current chairs: Rathann dgilmore jsmith jwb kalev maxamillion nirik paragan sgallagh 16:00:40 #topic init process 16:00:43 .hello maxamillion 16:00:43 .hello sgallagh 16:00:44 maxamillion: maxamillion 'Adam Miller' 16:00:47 sgallagh: sgallagh 'Stephen Gallagher' 16:00:50 hi 16:00:50 .hello kevin 16:00:51 nirik: kevin 'Kevin Fenzi' 16:00:51 .hello rathann 16:00:53 Rathann: rathann 'Dominik Mierzejewski' 16:00:57 .hello pnemade 16:00:59 paragan: pnemade 'Parag Nemade' 16:01:12 .hello jsmith 16:01:13 jsmith: jsmith 'Jared Smith' 16:01:14 .hello kalev 16:01:15 kalev: kalev 'Kalev Lember' 16:02:45 alright, we're good on attendance, stragglers might roll in later 16:03:01 #topic Follow Ups 16:03:14 #topic #1605 finish retirement of sysvinit-only packages 16:03:23 .fesco 1605 16:03:25 maxamillion: #1605 (finish retirement of sysvinit-only packages) – FESCo - https://fedorahosted.org/fesco/ticket/1605 16:03:28 .fesco 1605 16:03:31 grrr 16:03:31 maxamillion: #1605 (finish retirement of sysvinit-only packages) – FESCo - https://fedorahosted.org/fesco/ticket/1605 16:03:35 https://fedorahosted.org/fesco/ticket/1605 16:03:42 Sounds like this is basically done, I think. 16:03:48 I think it's all done. 16:03:51 yes 16:03:57 so close the ticket? 16:04:00 surprisingly a number of the packages got picked up and fixed. ;) 16:04:01 +1 16:04:04 :-) 16:04:12 nirik, yeah I too observed that 16:04:19 looks like the strategy worked :) 16:04:26 mostly by ellert 16:04:31 if thats what it takes to motivate, sure. ;) 16:04:55 is someone closing or should I? 16:06:21 go ahead. 16:07:23 alright, moving on 16:07:23 #topic #1606 F25 approved Changes not in MODIFIED status 16:07:23 .fesco 1606 16:07:23 https://fedorahosted.org/fesco/ticket/1606 16:07:24 maxamillion: #1606 (F25 approved Changes not in MODIFIED status (considered as not testable)) – FESCo - https://fedorahosted.org/fesco/ticket/1606 16:08:53 I'm not particularly tied to any of the ones not yet set to MODIFIED... 16:09:17 So if it were up to me, I'd say to defer them to F26 16:09:21 One of them is mine (BZ#1345757) but I updated it yesterday, I have things in a testable state, next step is to work on getting it in Fedora Infra Ansible and request some security audit 16:10:15 Does anyone know offhand if zbyszek made the KillUserProcesses change in the systemd included in Alpha Freeze? 16:10:29 * maxamillion does not 16:10:30 sgallagh: I don't know :-( 16:10:33 is anyone from rel-eng here to talk about the koji ticket? 16:10:56 me ... ish 16:11:00 /me goes to check 16:11:14 I don't see it off hand 16:11:39 jgregusk has not replied to needinfo so his 2 changes should be deferred to f26 16:12:13 not sure if we can allow Rust compiler as its waiting on some package review 16:12:36 --without-kill-user-processes 16:12:49 systemd appears to have been built without that setting 16:13:15 paragan: the package review seems to be done, the package is in f25-updates-testing 16:13:15 Since it's apparently not going to get the alpha testing we requested, shall we defer it? 16:13:38 paragan: https://bodhi.fedoraproject.org/updates/FEDORA-2016-08169a6354 16:13:59 it also got pushed to F24 stable :) https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5a0802802 16:14:16 sgallagh: I think so yeah. 16:14:25 sgallagh: +1 16:14:47 maxamillion, cargo package is still not reviewed 16:14:49 sgallagh: +1 16:14:52 paragan: ohhhh ok 16:15:28 as much as I'd like to see systemd cleaning up processes, probably best to defer it at this point, yeah 16:16:20 I'll take on reviewing the cargo package, I'd hate to defer something just because we couldn't find a reviewer ... the review request is a month old, the person working on the change got everything in on time 16:16:28 +1 to deferring KillUserProcesses for the record 16:16:32 maxamillion: so... is koji going to generate the install images or is it a clear defer? 16:16:33 maxamillion, +1 16:16:52 +1 to deferring KillUserProcesses as well 16:16:53 maxamillion: +1 16:16:56 jwb: that's a dgilmore question, I've not followed that topic very will 16:16:58 well* 16:17:00 +1 to deferring KillUserProcesses 16:17:11 alright, let's start tallying votes ... 16:17:23 Proposal: defer KillUserProcess to Fedora 26 16:17:30 +1 16:17:31 +1 16:17:32 +1 16:17:32 +1 16:17:35 +1 16:17:35 +1 16:17:39 +1 16:18:06 +1 16:18:21 #agreed defer KillUserProcess to Fedora 26 (+1: 8, -1: 0, +0: 0) 16:18:33 erm ... I might have miscounted 16:18:43 #undo 16:18:43 Removing item from minutes: AGREED by maxamillion at 16:18:21 : defer KillUserProcess to Fedora 26 (+1: 8, -1: 0, +0: 0) 16:18:49 i count 8 16:18:56 * Rathann counts 8 as well 16:18:58 that was right count 16:19:02 Rathann: what's your FAS name? 16:19:07 rathann 16:19:11 lowercase 16:19:15 ah 16:19:39 so, as something who's only on his second time chairing the meeting, do I count non-FESCo votes? 16:19:54 Rathann is in fesco 16:19:55 afaik, people like us don't count 16:19:59 I think we all are fesco members here 16:20:01 non-fesco folks, that is 16:20:05 jwb: not on the roster https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee?rd=FESCo#Members 16:20:29 roster wasn't updated after last elections 16:20:30 maxamillion: he got elected a few weeks ago and is replacing number80 16:20:32 maxamillion: it's a wiki. it is stale by definition. he was elected in the recent election like 3 weeks ago 16:20:34 *sigh* 16:20:37 yup 16:20:40 burn all the wikis down 16:20:41 maxamillion, well you only pinged him in your initial meeting lines 16:20:42 * Pharaoh_Atem sighs 16:20:43 maxamillion: He replaced Haikel 16:20:46 I'll update it 16:20:46 Rathann: my apologies 16:20:47 we need an API for this 16:20:50 #agreed defer KillUserProcess to Fedora 26 (+1: 8, -1: 0, +0: 0) 16:20:52 no problem ;) 16:21:21 my memory is mush, if it's not written down, I'm going to get it wrong 16:21:23 allllright then 16:21:36 next Rust compiler voting? 16:21:52 Proposal: maxamillion to take the review of cargo to move the rust feature through 16:22:05 errr s/feature/change 16:22:13 maxamillion: +1 16:22:14 +1 16:22:18 is that all that is blocking it? 16:22:19 maxamillion, +1 16:22:23 nirik: yes 16:22:37 nirik: all the work appears to be done 16:22:38 sure then, +1 to give it more time. 16:22:41 +1, thanks for volunteering 16:22:44 nirik: and the review request was filed a month ago 16:22:52 +1 16:22:52 +1, thanks maxamillion 16:22:59 * Rathann is behind his reviews :( 16:23:18 jsmith: ? 16:23:24 +1 from me 16:23:27 (sorry for the latency) 16:23:51 #agreed maxamillion to take the review of cargo to move the rust change through (+1: 8, -1: 0, +0: 0) 16:24:19 Proposal: defer Koji Generates Installation Media change until Fedora 26 16:24:33 +1 16:24:34 +1 16:24:48 +1 16:24:59 +1 16:24:59 +1 i guess 16:25:10 Can we try to get it done in Rawhide ASAP though? 16:25:13 is dgilmore on board with deferring it? 16:25:24 kalev: we don't know. he isn't here. 16:25:30 right :) 16:25:37 +1 (reluctantly) 16:25:49 jsmith: relucantly? ... what's the reservation? 16:25:52 +1 16:26:08 maxamillion: I would have liked to have seen it in F25, if it's fully baked... 16:26:14 jsmith: ah 16:26:16 maxamillion: I just have no idea if it's fully baked 16:26:26 +1, since it's not ready, apparently 16:26:39 seems pretty key to the whole release process so i was hoping we'd have info no it 16:26:43 s/no/on 16:26:56 it seems somewhat difficult to find out what's going on in koji development 16:27:04 jsmith: jwb: would you rather we wait until dgilmore & co can chime in? 16:27:10 Pharaoh_Atem: +1 16:27:15 maxamillion: Yeah, I'm fine with that 16:27:23 alright 16:27:32 maxamillion: Although, I hate leaving things to crunch-time too... 16:27:36 maxamillion: no. it's either doing it now for Alpha or it isn't. if it isn't, then it needs to be deferred 16:27:45 jwb: rgr 16:28:11 alright, well the votes are in, I just wanted to not have a concern go unvoiced if it was something we needed to re-open for discussion 16:28:41 #agreed defer Koji Generates Installation Media change until Fedora 26 (+1: 8, -1: 0, +0: 0) 16:29:44 alright, the other one on there was mine, the RelEng Automation but I updated yesterday and it is currently MODIFIED status ... is there anyone on that one that anyone would like to discuss and/or propose a vote for? 16:30:07 if its done lets approve it :) 16:30:38 Proposal: Approve Release Engineering Automation Workflow Engine Change 16:30:40 +1 16:30:52 jsmith: we're voting to approve the Release Engineering Automation Workflow Engine change 16:30:52 +1 16:30:57 +1 16:31:10 sure, if it's modified now, +1 16:31:10 +1 16:31:18 +1 16:31:26 +1 16:31:48 +1 16:32:11 #agreed Approve Release Engineering Automation Workflow Engine Change (+1: 8, -1: 0, +0: 0) 16:32:22 moving on 16:32:22 #topic #1609 Fedora 26 schedule proposal 16:32:22 .fesco 1609 16:32:22 https://fedorahosted.org/fesco/ticket/1609 16:32:25 maxamillion: #1609 (Fedora 26 schedule proposal) – FESCo - https://fedorahosted.org/fesco/ticket/1609 16:33:28 anyone have any preliminary thoughts on the schedule? anything needing to be discussed here or should we vote? 16:34:12 I'm for three-weeks for mass rebuild -- anything less is really hard 16:34:26 jsmith: +1 16:34:26 we still haven't settled on a schedule to vote on yet 16:34:28 jsmith: +1 16:34:36 Other than that, I'm "meh" 16:34:37 also would be good to get pbrobinson's input on aarch64 merging... 16:34:47 nirik: true 16:34:49 nirik: Aye :-) 16:34:53 ASAP :) 16:34:54 oy 16:35:00 pbrobinson: o hai 16:35:14 hoping to have aarch64 builders done next week 16:35:27 nice 16:35:31 once we have that in place we can work our merging 16:35:53 so we can start building even if we don't instantly enable it in the compose output 16:36:00 so, in any case should land long before a jan mass rebuild 16:36:13 I'm personally of the mind that 2 weeks for rebuilds is totally fine, as people can always push fixes to the branched version afterwards as well 16:36:32 as long as we don't have any special considerations this time around due to the aarch64 merge affecting rebuilds 16:36:39 nirik: yes, wanted it to land ASAP 16:36:41 really uncomfortable with a 2 week rebuild 16:36:59 particularly if we're delaying it to include GCC 7 and with aarch64 being included in the rebuild 16:37:04 nirik: the plan it to land and let it warm into it rather than instantly hit a mass rebuild 16:37:12 I think we should have 3 week rebuild 16:37:14 Proposal: maintain a three week mass rebuild time on the f26 schedule 16:37:16 jwb: I agree with that, 2 weeks is tight 16:37:30 kalev: I've heard rel-eng say multiple times that 2 weeks is unreasonable -- I'm giving the benefit the the doubt 16:38:01 while generally these days the actual mass rebuild normally kicks on a Friday afternoon and is done by Monday it generally takes a good couple of weeks to clean up any mess 16:38:15 right 16:38:38 right, but the mess cleaning can continue after branching too 16:38:51 do we need to delay branching just because there's still things to clean up? 16:39:27 It's harder on the maintainers, but honestly not by much. 16:39:27 it makes the process to fix more combersome because things will feed through bodhi won't it? 16:39:32 It's a git merge and fedpkg build 16:39:45 and a bodhi update and buildroot overrides 16:39:45 Right, and Bodhi activation. 16:39:50 it's a mess 16:40:28 where as rawhide, but design, is the wild west so you just throw things at koji 16:40:48 working things... working things... 16:41:02 Heh 16:41:03 but in that case, we actually get the benefit of not having to manually override to include things in the buildroot 16:41:15 which, depending on what is actually broken, can save a lot of time and confusion 16:41:16 jwb: right 16:41:26 I meant that as a positive, not a negative 16:42:05 the other alternative is to move all dates leading up to the mass rebuild one week earlier 16:42:56 that would put submission deadline at like the 3rd... 16:42:58 and I don't think that would fly, since 2017-01-10 "Change Checkpoint: Proposal submission deadline (System Wide Changes)" would then clash with christmas vacations 16:42:59 well it means maintainers have to do it twice, once for each branch, and then possibly bodhi as well 16:43:01 yeah 16:43:06 i don't think we're going to settle this here today to be honest. we need to line up the proposed schedules in the ticket 16:43:15 I find a lot of maintainers have issues with branching without adding extra in 16:43:19 * nirik nods. more in ticket discussion 16:43:26 I mean, sure, it would be nicer to have 3 weeks, but we just don't seem to have the luxury this time around 16:43:42 yes we do 16:44:06 and it isn't a luxury 16:44:33 alright, let's defer to the ticket then .... shall we move on to the next topic? 16:44:42 please 16:44:44 yes 16:45:27 WORKSFORME 16:45:36 #agreed more in ticket discussion needed for schedule, will revisit later 16:45:44 #topic #1611 Continued lack of support for RPM weak deps in distro tooling 16:45:47 .fesco 1611 16:45:48 maxamillion: #1611 (Continued lack of support for RPM weak dependencies in distribution tooling) – FESCo - https://fedorahosted.org/fesco/ticket/1611 16:45:49 https://fedorahosted.org/fesco/ticket/1611 16:46:20 so we worked around this immediate issue 16:46:32 nirik: iirc, you had some follow up on this ticket? something about builds or composes on f24 machines instead of el7 16:46:50 yeah, so I did make a bodhi machine that was f24 and tested... 16:47:08 doing that is enough to make weak deps appear in the repodata (but not boolean ones) 16:47:29 so, we probibly want to move to that so updates is similar to the other path 16:47:40 is that enough to satisfy the immediate requirements of the ticket or is there a larger issue? 16:47:42 but there's still things that don't handle them... 16:47:54 like appliance-tools (this ticket) 16:47:59 ah 16:48:57 so I guess I'd say close this ticket... people can still use weak deps and if they hit some case with issues with the compose tools we will try and work around that as best we can until all compose tools handle them correctly. 16:49:27 nirik: alright, I think you have the most context on this out of the group ... want to make a proposal for vote? 16:49:44 * stickster asks a (potentially) dumb question 16:49:51 stickster: shoot 16:50:21 I was under the impression that there's a PR pending for koji that would make koji use createrepo_c and allow weak deps to be generated there, is that relevant at all here? 16:50:39 stickster: its still in development 16:50:42 perhaps makes this a stopgap 16:50:44 stickster: yes, it's been pending for a long time 16:50:48 and we are not sure it does everything 16:51:03 it also may not help as it uses yum to do multilib 16:51:18 stickster: That still doesn't fix bohdi either, right? 16:51:32 jsmith: the plan is to have bodhi use koji signed repos 16:51:42 jsmith: not atm, no... but AIUI the plan was for the masher to hand this off to koji signed repos 16:51:47 dgilmore: *nod 16:51:52 Ah, I missed that :-) 16:51:54 proposal: releng will try and move all compose tools to support weak deps, but in the mean time issues with composes and weak deps will need to be handled on a case by case basis. 16:51:59 OK, don't let me pull things off track please 16:52:06 nirik: +1 16:52:09 I just didn't know if I had completely misunderstood that signed repo work 16:52:21 nirik: +1 16:52:21 nirik: +1 16:52:33 nirik: +1 from me 16:52:39 nirik: +1 16:52:40 stickster: signed repos will use whatever koji is configured for 16:52:46 nirik, thanks for your work, +1 16:52:52 I'm not sure what all beyond appliance tools would still not support them... 16:52:54 stickster: so if koji is configured to use createrepo thats what it uses 16:52:59 nirik: +1 16:53:54 nirik: signed repos, mash, appliance-creator, and probably some other bits still use yum 16:54:13 yeah. hard to say what all, but more... 16:54:27 alright, who we missing on votes? 16:54:27 but createrepo + new rpm is enough to get weak deps ok... 16:54:30 jwb: ? 16:54:41 afaik the biggest issue with weak deps is the rpm that bodhi uses 16:54:53 +1 to nirik 16:55:07 which will go away with signed repos 16:55:14 as that will use fedora's rpm 16:55:17 we're sill missing one ... we picked up dgilmore in the vote pool 16:55:36 dgilmore: or a fedora bodhi-backend... 16:55:38 oh, nirik 16:55:47 nirik: I don't think you voted :) 16:55:48 +1 to my own proposal. ;) 16:55:48 nirik: or that 16:56:28 #agreed releng will try and move all compose tools to support weak deps, but in the mean time issues with composes and weak deps will need to be handled on a case by case basis. (+1: 9, -1: 0, +0: 0) 16:56:42 Sorry I am late, I was going over stuff with mohan and did not geta reminder of the meeting 16:56:47 nirik: do you mind updating the ticket? 16:57:02 sure, just add that agreed and close it? 16:57:17 nirik: +1 16:57:28 #topic New Business 16:57:34 #topic #1613 Deletion of EOL AMIs 16:57:34 .fesco 1613 16:57:34 https://fedorahosted.org/fesco/ticket/1613 16:57:35 maxamillion: #1613 (Deletion of EOL AMIs) – FESCo - https://fedorahosted.org/fesco/ticket/1613 16:57:55 initially I removed the AMI's as soona release went EOL 16:58:02 and that made people upset 16:58:38 I think it makes sense to remove them as soon as the release goes EOL 16:58:56 why 16:59:10 We don't do that for any other edition. 16:59:20 we don't remove install media from our mirrors when it goes EOL. AMIs seem equivalent there? 16:59:32 * nirik is ok with the release + last one 16:59:33 jwb: yeah, that's fair 16:59:38 keeping AMIs shoudl cost no money at all, the account they are on is supposed to have free storage for our official AMIs (and not be used for anything else) 16:59:45 so relased AMI's is currently on the AMI that was released at GA 17:00:10 jforbes: is that the case currently though? I heard it was supposed to be but we were somehow paying for storage of images 17:00:13 the ones built as part of the two wwek nightly compose are never really considered released and can be cleaned up at any point 17:00:15 That was the agreement I created when we first set those up, and why the fedora account exists as a separate entity 17:00:22 jforbes: I'm under the impression that is no longer the case for reasons no one has been able to explain to me. 17:00:28 jforbes: that was true in the past 17:00:30 gholms: +1 17:00:31 maxamillion: I had not seen an update to those terms 17:00:41 * jsmith is happy to talk to David Duncan at Amazon if that's not the case 17:00:58 there is ongoing discussions to have amazon cover the bill 17:01:01 jsmith: this was discussed with him at Flock and I think he offered to work to resolve it 17:01:11 or at least help 17:01:14 which is currently a few thousand dollars a month 17:01:20 Yes, he did. 17:01:25 yeah, last number I heard was like $5k/mo 17:01:27 I can tell you we are charged for those, *but* jzb is working with AMZ folks to get that written off 17:01:31 dgilmore: well, that account was flagged when it was created, before we put the first image up. We were supposed to pay for machined time, not storage 17:01:34 stickster: +1 17:01:40 there is work going on to resolve the cost issue 17:01:44 Not sure why that's taking a while, but dduncan is indeed involved and helping. 17:01:47 last months bill was just over $3k though, so something is up, I guess I can look at the itemized 17:01:48 alright, so the billing issue is being resolved ... let's get back to the topic of the ticket 17:02:09 jforbes: no idea when it changed, probably when we started using heaps of storage 17:02:39 Well, billing is an issue because amazon would prefer we don't delete images, and they were supposed to be footing the bill 17:02:51 so there is only one set of GA AMI's per release 17:03:21 jforbes: right, it causes issues for customers when we do 17:03:36 ideally we make the compose process smarter and only make new images when something in them has changed 17:03:57 and have a awesome super easy way for people to get the latest bits 17:04:14 so they then do not go hardcoding AMI's into scripts 17:05:15 If only cloudformation made things that easy. :( 17:05:30 gholms: but the cloud does all the things for you 17:05:37 Heh 17:05:39 and you never need to work about anything :P 17:06:36 I wonder if we should not readress this after getting billing sorted 17:06:44 Okay, looking at the bill, we are being charged for storage, so that needs to be worked out, but some of it is being stored on ssds and various places. We probably need to address that 17:07:05 because maybe without a cost to storage we do not care if there is 1000 new ami's a year 17:07:13 Machine time + data transfer, the bill should be less than a couple of hundred dollars 17:07:50 though we are producing much more than 1000 a year 17:07:54 sorry guys, I need to go AFK, something urgent came up @home 17:08:10 I could be back in about 20 mins, not sure though 17:08:15 dgilmore: well, we don't want to abuse it either, so if we could limit it to new images only when there is something in the image which changes 17:08:38 jforbes: we have no way to detect when things change today 17:08:52 it is on the super long term nice to have roadmap 17:09:11 Rathann: hope everything goes ok 17:09:28 Rathann: what nirik said 17:09:36 I do know when the original agreement was made, the plan was to do images for each release and not update them, so we are using much more storage than they expected 17:10:05 jforbes: right the cloudWG wants to have month updated ami's 17:10:16 can we take the billing thing offline? because this isn't directly relevant to the ticket 17:10:18 we could only upload once a week or something 17:10:27 after some level of testing has passed 17:10:45 maxamillion: I would argue that it is relevant to the ticket, but we should differ the ticket until the billing is worked out 17:11:02 fine 17:11:02 jforbes: We need to stop putting full composes on the mirrors daily as well 17:11:23 Proposal: Defer decision on Deletion of EOL AMIs until the AWS billing issue is sorted 17:11:29 mirrors are not entirely happy about the size of daily churn 17:11:34 maxamillion: +1 17:11:38 +1 17:11:40 maxamillion, +1 17:11:42 sure, +1 17:12:33 +1 17:12:57 +1 17:13:19 jwb: sgallagh: ? 17:14:13 sorry, on a call. +0 because i didn't pay attention 17:14:39 rgr 17:14:40 +1 17:15:17 #agreed defer decision on Deletion of EOL AMIs until the AWS billing issue is sorted (+1: 7, -1: 0, +0: 1) 17:15:25 #topic #1614 FHS exception for /snap 17:15:25 .fesco 1614 17:15:26 https://fedorahosted.org/fesco/ticket/1614 17:15:27 maxamillion: #1614 (FHS exception for /snap) – FESCo - https://fedorahosted.org/fesco/ticket/1614 17:15:36 * Pharaoh_Atem sighs 17:15:52 I made my opinion here known in the ticket 17:16:53 yeah, I agree with sgallagh 17:16:57 * kalev did too. 17:17:00 i have no overwhelming opinion. allowing it on the grounds of interop seems reasonable. rejecting because it's not in FHS seems like clinging to a spec everyone hates just to spite them 17:17:27 I agree with jwb 17:17:48 i guess i would recommend waiting to see how the debian case plays out 17:18:06 jwb: That would be reasonable except for the part where the other distros seem not to particularly want it there either 17:18:13 yeah, I'm on board with waiting to see what debian does and how the arch bug plays out 17:18:26 do we have any contacts with debian? 17:18:30 sgallagh: right. hence waiting for debian. or reaching out to debian 17:18:46 as the reviewer, I tried to find info on the debian decision, but I can't find any 17:18:56 I don't want to make a hard/fast call on anything that would make us an outlier among other community distros 17:20:10 I'd like to get the snapd package in sooner rather than later if this could be resolved, so I'm hoping someone here has some friends "high up" 17:20:13 I think there is value in being the same across all distros 17:20:13 in Debian 17:20:18 dgilmore: +1 17:20:31 does anyone know someone who's a core dev of debian they could reach out to? or involved with arch? 17:20:56 I have a colleague involved in Arch, and I think they're kind of waiting on us 17:21:13 my colleague is the one that triggered the bug 17:21:48 the comments in the bug (https://bugs.archlinux.org/task/50435) are interesting though 17:21:49 Pharaoh_Atem: ah ok, any chance they can chime in on the ticket? I'd like to have an open dialog with members of the other distros in order to come to a joint consensus (if we can) 17:22:09 I can certainly try 17:22:14 also, we should reach out to some of the openSUSE folks as well 17:22:22 yeah, definitely 17:22:39 I'm rather for waiting, don't think there's much rush in getting this in quickly 17:22:57 kalev: indeed 17:23:06 cwickert is involved with openSUSE these days iirc, so he's likely a good point of contact to start the discussion 17:23:12 I would rather do it once and right than redo it a few times 17:23:15 our friends in openSUSE are a bit further along than we are, it seems: https://build.opensuse.org/search?utf8=%E2%9C%93&search_text=snapd&commit=Submit&issue_tracker=bnc&issue=&project=0&project=1&package=0&package=1&name=0&name=1&title=0&description=0&attrib_type_id= 17:23:19 ugh 17:23:24 https://build.opensuse.org/package/show/system:snappy/golang-github-snapcore-snapd 17:23:31 they've got it in a devel project now 17:23:48 though the builds appear to be broken 17:23:58 Pharaoh_Atem: I do not think that is part of OpenSuSE 17:24:05 Pharaoh_Atem: those look like user baked builds and not part of the core distro ... unless I'm mistaken on the OBS labels 17:24:13 That looks like the equivalent of COPRs 17:24:14 you might be right 17:24:32 I get confused with how these projects work in OBS sometimes 17:24:40 wait, this one might be system:snappy https://build.opensuse.org/project/show/system:snappy 17:25:26 alright, lets get people with action items to reach out to various contacts ... I'll reach out to cwickert from OpenSUSE and paultag from Debian to see where to go from here 17:25:37 maxamillion++ 17:25:37 sgallagh: Karma for maxamillion changed to 9 (for the f24 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:25:42 awesome 17:26:02 actually 17:26:05 I think pid1 is here 17:26:09 Pharaoh_Atem: you will reach out to your arch contact? 17:26:13 he's the Arch guy 17:26:15 ah 17:26:18 pid1: hello :) 17:26:19 I asked him to hang out here for the meeting now 17:27:10 he's also the one that filed the bug in Arch 17:27:51 Pharaoh_Atem: would you mind taking the action item to follow up with him off-meeting? 17:27:51 o/ 17:27:54 oh 17:28:04 here he is :) 17:28:24 pid1: would you mind if I followed up with you off-meeting about the /snap topic? 17:28:31 maxamillion: not at all 17:28:35 pid1: awesome 17:28:41 yay friends :D 17:28:46 Timothy doesn't consider it an issue since we're only creating /snaps at runtime 17:28:54 maxamillion++ 17:28:57 I don't personally see how that really makes a difference here, though. 17:29:12 that was the argument zyga made to me 17:29:42 We're seemingly just deferring to "Upstream expects /snaps, so it will exist." 17:29:48 pid1: well, we mostly want to try and collaborate with all community distros about the direction we take instead of making an uninformed or premature decision that could leave us as an outlier 17:29:52 Considering how much Arch defers to upstream behavior, I'm not entirely surprised. 17:29:57 pid1: fair 17:30:00 Honestly, that bothers me more. Not only is it a non-standard location, but it's a non-standard location that packaging tools don't own and manage... 17:30:22 my concern with it is that upstream is essentially defying its own distro rules for this 17:30:31 sgallagh: yeah, the "packaging tools don't own and manage" bit concerns me 17:30:34 alright 17:30:58 If we are going to create it at all, I'd rather /snaps be created by the package so it is owned and managed. 17:31:02 * jsmith has to go.... sorry 17:31:13 oh, sgallagh ++ 17:31:15 #action maxamillion to reach out to openSUSE, arch, and debian contacts on /snap topic to aid in cross-distro agreement on approach 17:31:17 at least if we allow it, we can have the rpm spec create and own /snap 17:31:18 Same thoughts here. 17:31:29 Pharaoh_Atem: Same thoughts with pacman. 17:31:38 Proposal: defer FHS exception for /snap until next week's meeting 17:31:49 * dgilmore does not know enough about how snaps are created to say 17:32:00 snaps are unaware of where they exist on the filesystem 17:32:13 they use internal environment variables to determine their FS structure 17:32:13 but given how flatpak is and that it needs a rebuild to work, I wonder if snaps will be in the same boat 17:32:44 they use a combination of seccomp, chroot, bind mounts, and mandatory access control to jail the environment 17:32:55 there's a proposal up, can FESCo members please vote or suggest something else? 17:32:56 * Rathann is back 17:32:58 the snaps inside have a faked FHS structure 17:33:02 Proposal: defer FHS exception for /snap until next week's meeting 17:33:10 maxamillion: +1 17:33:12 +1 17:33:12 +1 17:33:14 +1 17:33:26 I think we need more info on how it all is supposed to work 17:33:28 +1 17:33:31 +1 for now, I guess 17:33:39 +1 17:33:52 a cross-distro agreement will allow us to be united when we come back with a decision, one way or another 17:33:57 alright, we lost jsmith ... did we lose anyone else in the vote pool? 17:34:01 so I'm godd with a deferral 17:34:05 *good 17:35:00 Pharaoh_Atem: Thinking a little high of yourself? ;-) 17:35:06 haha 17:35:31 kalev: you still with us? 17:35:52 sorry, +1 17:35:57 * kalev was filing expense reports. 17:36:03 blech :) 17:36:08 #agreed defer FHS exception for /snap until next week's meeting (+1: 8, -1: 0, +0: 0) 17:36:21 #topic Next week's chair 17:36:27 maxamillion, we have 2 tickets more 1612 and 1615 17:36:43 i can't chair. have another call booked in the middle of this meeting 17:36:43 paragan: not in the agenda that got sent out ... did they show up today? 17:36:50 #undo 17:36:50 Removing item from minutes: 17:37:06 maxamillion: people emailed to the devel list and asked to add them like the agenda says to :) 17:37:11 maxamillion, not on agenda though requested on list 17:37:15 actually 3 17:37:18 bleh, I missed it 17:37:20 *sigh* 17:37:28 this meeting just won't end 17:37:39 oh, 2 17:37:43 <3 all of you but I'm hungry :D 17:37:47 heh 17:38:00 The Wayland one at least can't wait, I think 17:38:06 both are easy tickets and need just voting I guess 17:38:10 i'd suggest we start with https://fedorahosted.org/fesco/ticket/1612 17:38:11 #topic #1615 Consider Wayland by default for F25 17:38:15 .fesco 1615 17:38:16 maxamillion: #1615 (Consider Wayland by default for F25) – FESCo - https://fedorahosted.org/fesco/ticket/1615 17:38:19 https://fedorahosted.org/fesco/ticket/1615 17:38:23 or that 17:38:30 jwb: sorry, I went in order of requests to the mailing list thread 17:38:44 no worries 17:39:15 so, is wayland set to be default already in f25? I'd guess so since rawhide was changed before branching... 17:39:21 Yes 17:39:36 It was planned that way since F24, but no one rememebered to actually file a Change proposal 17:39:44 sgallagh: fun :) 17:39:45 yeah. ;( 17:39:47 yes its default in f25 17:39:49 :/ 17:39:57 The question before us is whether we want to leave it that way or revert to X. 17:40:03 well I guess technically there was the Change proposal from F24, it just wasn't updated and resbumitted 17:40:18 This is pretty much a judgement call; we need to do it sooner or later. It's going to have breakage whenever it happens. 17:40:24 sgallagh: +1 17:40:35 well, I'd defer in this area to the workstation WG. If they wish to wayland default, then thats fine with me. 17:40:52 They deferred to us :) 17:40:57 I'm game, let's push the leading edge ... we did it with GNOME3 and systemd and I'm sure this won't be the last time something like this comes up 17:41:11 what nirik said, I have not tried wayland at all and have no idea on how well it works or doesnt 17:41:20 Not necessarily the best examples... but probably accurate ones. 17:41:29 For the most part it's quite functional. But there's bugs, corner cases and just plain differences. 17:41:37 I've been using it for a year. There's one or two rough edges, but it's mostly been good for me 17:41:41 but yeah, +1 for the change 17:41:47 So formal proposal: 17:41:47 sgallagh: right, I selected those examples on purpose because they were rocky and we handled them pretty well :) 17:42:18 Proposal: FESCo agrees to go ahead with Wayland by default provided that release notes and common bugs are clear about how to switch back to X11 if needed. 17:42:28 afaik, biggest pain point is a11y still busted for Wayland 17:42:28 sure. +1 17:42:32 but I think everyone knows that already 17:42:39 sgallagh: +1 17:42:41 +1 17:42:58 And nvidia driver users, but discussions have been happening upstream, so hopefully those will be resolved 17:43:04 sgallagh, +1 17:43:18 sgallagh: +1 17:43:27 sgallagh: +1 17:43:28 i find this discussion bizarre 17:43:31 but +1 17:43:32 +1, we'll also discuss it at next Workstation meeting and may go back to xorg depending on how it looks at that point 17:43:40 jwb: What about it? 17:44:23 * nirik somewhat does too, but whatever works 17:44:25 sgallagh: because we were debating on-list about a ca-cert change VERY SERIOUSLY but we're very flippant about possibly pissing off a significant portion of our user base with Wayland 17:44:33 we're short one vote, who we missing? 17:44:44 jsmith is away, I think 17:45:00 jsmith and Rathann have left 17:45:02 yeah, but we had 9 and jsmith left and we have 7 votes counted 17:45:07 dgilmore: no, I'm back 17:45:09 dgilmore: Rathann is back and voted 17:45:11 jwb: That is an interesting point. I gues there's a bit of cognitive dissonance there, huh? 17:45:13 ahh okay :) 17:45:28 jwb: bcuz security :P 17:45:35 sgallagh: yes, that's exactly the term i was trying to remember 17:45:55 well I'm +1 to disabling legacy CAs by default 17:46:00 The difference (rationalization?) in my mind is that it's already been that way through Rawhide and we've been talking about it for years. 17:46:02 there's been enough time already 17:46:07 Whereas the CA thing just kind of appeared. 17:46:22 (And I'm still fine with including it, I just don't want to rock the boat during Alpha) 17:46:26 #agreed FESCo agrees to go ahead with Wayland by default provided that release notes and common bugs are clear about how to switch back to X11 if needed. (+1: 7, -1: 0, +0: 0) 17:46:31 the CA thing has ben there for years, just not as in your face 17:47:54 #topic #1612 Provenpackager request jforbes 17:47:59 .fesco 1612 17:48:00 maxamillion: #1612 (Provenpackager request jforbes) – FESCo - https://fedorahosted.org/fesco/ticket/1612 17:48:05 https://fedorahosted.org/fesco/ticket/1612 17:48:15 I think there is anough +1's in the ticket 17:48:28 /me agrees 17:48:47 +1 17:48:48 though Rathann gave a -1 17:48:57 which is why it is here 17:48:59 dgilmore: which means it goes to a vote by FESCo 17:49:07 and every other fesco member said +1 17:49:19 I am +1 to jforbes being proven packager 17:49:26 which means he'd be on the losing side of the vote unless someone else changed their mind 17:49:30 honestly kinda surprissed he is not already 17:49:35 so was he 17:49:46 Proposal: Approve jforbes Provenpackager request 17:49:48 +1 17:49:50 +1 17:49:53 +1 17:50:20 +1 17:50:31 +1 17:50:43 I'm still -1 for the reasons already stated 17:51:13 Rathann: was there any response or further discussion you'd like to have based on the response in the ticket? 17:51:38 well if he did a couple of package reviews, I'd be happy to change my vote 17:51:53 Rathann: Well, he's not applying for Sponsor 17:51:59 * jforbes is here and happy to answer any questions 17:52:29 I forget if we have actual guidelines for uberpackager. 17:52:29 the vote as it stands is enough to approve 17:52:46 I'm not generally involved in that side of things, so I know I didn't write any. 17:52:54 But if there aren't, then there certainly should be. 17:53:05 well, it's the reason I've never applied to be one 17:53:12 I have no idea what the criteria for it is 17:53:15 yes, there are 17:53:19 https://fedoraproject.org/wiki/Provenpackager_policy 17:53:21 there is 17:53:59 Rathann: I am not against doing package reviews, and have done a couple over the years, but I am rarely have a ton of free time to go looking for more things since just the kernel queue is several hundred deep at any given time 17:54:07 reviews shouldnt be a critera. Thats why we split sponsors and provenpackagers. ;) 17:54:37 personally, provenpackager to me signifies a level of trust in the person. 17:54:47 That says what they do, not really the criteria for applying. 17:54:52 jforbes: if you have, I couldn't find them :( 17:55:08 Rathann: it has been a few years 17:55:09 Rathann: it's because they were done at the beginning of Fedora. 17:55:15 sponsor has discrete guidelines for package reviews, packages maintained and packager group membership time. 17:55:25 Just saying, not to derail, but that would be useful to have. 17:56:16 I'm just saying it's good to do a review once in a while if only to refresh your knowledge of the FPG 17:56:24 because they get updated 17:56:41 and since jforbes hasn't done any in years 17:56:43 I suppose. I'll note also tho that when we closed things to all packagers we expected provenpackager to have a somewhat low bar... been around, won't break guidelines, asks for help, etc. 17:57:00 Kick me out now, because I haven't had time to do a review in ages. 17:57:04 and i'm contending that knowledge of the FPG is good, but is not necessary since provenpackager is useful for fixing problems that have nothing to do with packaging. 17:57:10 The real thing that spurred this request though was pesign needing a build last friday evening, and the number of provenpackagers who can also do signed builds is maybe 2, neither of which were around 17:57:30 jforbes: sure, that's a valid argument 17:57:31 Rathann: FPG changes are posted to the list and reviewed 17:57:49 * pjones definitely thinks jforbes should have provenpackager 17:57:50 I don't ignore them just because I am not reviewing other people's packages actively 17:58:06 nirik: right. again, provenpackager is a measure of trust. it is not some kind of test of FPG knowledge 17:58:17 * nirik nods 17:58:31 NOTE: in case anyone forgot there is a vote up and we're still short FESCo member votes 17:58:37 sure, but one needs some basis for that trust 17:58:43 jforbes: and the list of people who can do signed builds is about 5 maybe 6 17:58:52 maxamillion: we short on members voting, but we are not short on enough votes to pass approval 17:58:52 * nirik is +1 as voted in ticket also 17:59:10 maxamillion: More than five FESCo members +1ed in the ticket as well 17:59:27 given that the trust of doing signed builds is much higher than the trust of provenpackager, perhaps if you can do signed builds proven packager comes with it 17:59:28 Rathann: put succinctly, if you don't trust jforbes then you should be running a different distribution. 17:59:37 Rathann: he literally builds your kernel 17:59:38 sgallagh: yeah 17:59:53 Rathann: he's been maintaining our kernel packages for years, he's run for fesco and had a fairly strong showing in the results several times... 17:59:55 jwb++ 17:59:55 sgallagh: Karma for jwboyer changed to 5 (for the f24 release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:00:04 oh I trust him to take care of the kernel alright 18:00:17 #agreed Approve jforbes Provenpackager request (+1: 7, -1: 1, +0: 0) 18:00:34 Rathann: the FC1 x86_64 offical ISOs were built on my home systems because the Fedora buildsystems couldn't spit them out, the first AMIs were as well. 18:00:41 wow 18:00:50 ok, now we can move on to chair 18:00:55 which i still can't do :\ 18:01:02 I think I have done a few things to earn the community trust 18:01:13 FC1 was near the beginning of my Linux journey 18:01:26 #topic Next week's chair 18:01:40 If no one else can I guess I can... 18:01:59 I can 18:02:03 it has been awhile 18:02:13 nirik: I was going to say the same ;) 18:02:47 #info dgilmore to chair next weeks meeting 18:03:00 #topic Open Floor 18:04:19 Proposal: end meeting before maxamillion goes into low-blood sugar coma 18:04:22 I have nothing but burritos for you 18:04:28 lol 18:04:34 tacos are pretty good too 18:04:37 mac'n'chz 18:04:42 I'll give it another minute just to be sure 18:04:52 and chicken nuggets :) 18:04:58 hotdogs, anyone? 18:04:59 Dunno, tacos and burritos might be hard to find near you maxamillion 18:04:59 pjones: tacos are pretty good 18:05:02 Hang on, what about the CA cert thing? 18:05:14 sgallagh: doing it as an update seems fine 18:05:23 sgallagh: and kai seemed agreeable tot hat 18:05:42 Yeah, I think that's the best course of action. 18:05:46 jforbes: lol? 18:05:54 Do we care enough to vote or just say "go ahead"? 18:06:08 alright, thanks everyone for attending and participating! 18:06:09 #endmeeting