16:07:44 #startmeeting FESCO (2016-08-26) 16:07:44 Meeting started Fri Aug 26 16:07:44 2016 UTC. The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:07:44 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:07:44 The meeting name has been set to 'fesco_(2016-08-26)' 16:07:45 #meetingname fesco 16:07:45 The meeting name has been set to 'fesco' 16:07:45 #chair maxamillion dgilmore jwb nirik paragan jsmith kalev sgallagh Rathann 16:07:45 Current chairs: Rathann dgilmore jsmith jwb kalev maxamillion nirik paragan sgallagh 16:07:48 #topic init process 16:08:01 .hello sgallagh 16:08:01 .hellomynameis jsmith 16:08:02 sgallagh: sgallagh 'Stephen Gallagher' 16:08:04 jsmith: jsmith 'Jared Smith' 16:08:09 .hello kalev 16:08:10 kalev: kalev 'Kalev Lember' 16:08:12 .hello kevin 16:08:16 nirik: kevin 'Kevin Fenzi' 16:08:21 .hello pnemade 16:08:22 .hello rathann 16:08:22 paragan: pnemade 'Parag Nemade' 16:08:25 Rathann: rathann 'Dominik Mierzejewski' 16:08:36 .hello maxamillion 16:08:37 maxamillion: maxamillion 'Adam Miller' 16:09:48 lets get started 16:10:00 #topic #1609 Fedora 26 schedule proposal 16:10:00 .fesco 1609 16:10:00 https://fedorahosted.org/fesco/ticket/1609 16:10:02 dgilmore: #1609 (Fedora 26 schedule proposal) – FESCo - https://fedorahosted.org/fesco/ticket/1609 16:10:15 I guess we didn't discuss this anymore in ticket. ;( 16:10:29 I have to agree with jwb we should not shorted the mass rebuild window 16:10:59 I've said my peace... and defer to rel-eng on the length of the mass rebuild 16:11:00 shorten 16:11:24 jsmith: you said it where? 16:11:39 * jwb is here now 16:12:06 jsmith: I am unaware of what you said. and it is not in the ticket 16:12:50 dgilmore: In last week's meeting 16:12:56 jwb: we are working out a couple of issues with the moonshot chasis, as soon as that is resolved, we will be working to bring in aarch64 16:12:58 dgilmore: you didn't want branching and bodhi activation on the same day right? (There was a proposal to do that last time I think) 16:13:07 nirik: right 16:13:17 nirik: we used to do that and it is just too much work 16:13:18 but 1 week would be ok for that? or ? 16:13:27 1 week is fine 16:13:27 dgilmore: yep. pbrobinson is keeping me in the loop there 16:13:50 adamw wants gpg checking to follow that too... ie, not be 1 until bodhi activation point. 16:14:01 could bodhi activation be a day later, not a week later? 16:14:11 kalev: not really 16:14:18 kalev: maybe 2 or 3 days later 16:14:26 * kalev nods. 16:14:33 kalev: there is a lot of small pieces in there 16:14:46 it takes a bit to shake out 16:14:59 nirik: well hopefull autosigning will be in place 16:15:02 so, we could make it on thursday of the alpha activation week (where thats tuesday)? 16:15:12 dgilmore: well, we can hope. ;) 16:15:15 nirik: we could 16:17:36 so, we need to have a new proposal with all this mixed in. 16:17:42 nirik: yeah 16:17:43 not sure about gcc 16:18:04 we should ask jakub 16:18:14 law chimed in there... 16:18:16 in ticket. 16:18:17 nirik: They specifically told us January 25th 16:18:32 sgallagh: nope, actually not 16:18:44 Before that, they wouldn't recommend mass rebuilding as the likelihood of code generation issues would be too high 16:18:46 nirik: ? 16:18:46 they said they did the 25th for f24 with a bunch of scrambling 16:18:56 yes, he said "What makes a lot more sense is to have a go/no go by say Jan 30." 16:19:05 yeah, so, jan 31st 16:19:06 gcc and glibc seem to be best with mass rebuild in feb 16:19:32 OK, I must have misread. 16:19:34 Well, crap 16:19:44 and we really need 3 weeks 16:19:56 so I would say GA should be June 6 16:21:00 So should we just go ahead and declare today that odd-numbered Fedoras will be longer cycles and even-numbered ones short? 16:21:03 how about someone propose dates based on all this in ticket and we visit next week, which would allow gcc/glibc or whoever to weigh in. 16:21:20 nirik: sounds good 16:21:37 sgallagh: sure sounding like thats going to be the case. ;( 16:23:22 does anyone want to put together a proposed schedule?? 16:23:46 sgallagh: I'm fine with that, personally :-) 16:23:48 I guess I'll do it; I created the other proposed ones. 16:24:25 #action sgallagh to put together a proposed schedule with mass rebuild in Feb for 3 weeks and release on June 6th 16:24:35 * Rathann is trying to get the hang of making tables in trac 16:24:42 #topic #1613 Deletion of EOL AMIs 16:24:42 .fesco 1613 16:24:43 dgilmore: #1613 (Deletion of EOL AMIs) – FESCo - https://fedorahosted.org/fesco/ticket/1613 16:24:44 https://fedorahosted.org/fesco/ticket/1613 16:24:47 Rathann: I just copied and pasted from earlier comments :-D 16:24:52 heh 16:25:21 not sure we have a resolution on the aws account yet 16:25:40 this was waiting on that... yeah. perhaps remove meeting keyword until there is news? 16:25:51 yeah 16:25:52 That works for me 16:26:09 #info remove meeting keywork until we have the account issues resolved 16:26:36 (Quick question on F25: do we want to extend the Change Submission date by a week if we're moving out the rebuild?) 16:26:48 sgallagh: no 16:27:18 sgallagh: but i assume you mean f26 16:27:49 well, why not? 16:28:04 i would rather changes be in sooner 16:28:35 dgilmore: Right, F26 16:28:40 no 16:28:46 no to extending it 16:28:55 I'll leave that piece of the proposal alone for now. We can discuss it once it's up 16:29:03 /me stops sidetracking 16:29:04 okay 16:29:06 #topic #1614 FHS exception for /snap 16:29:07 .fesco 1614 16:29:08 https://fedorahosted.org/fesco/ticket/1614 16:29:09 dgilmore: #1614 (FHS exception for /snap) – FESCo - https://fedorahosted.org/fesco/ticket/1614 16:29:13 I guess... seems like it doesn't matter too much before the other steps, but ok 16:29:32 * jsmith doesn't really care... 16:29:34 did maxamillion get in touch with folks from other distros about this? 16:29:38 maxamillion: any news? 16:29:39 I guess I'm OK with it 16:30:18 BTW, if we're going to do an exception, can we please do one that isn't specific to any one piece of software? 16:30:31 I tried, no response :/ 16:30:47 I sent emails to people from debian and opensuse, I even re-ping'd about mid-week and still no response 16:30:51 I mean, does flatpak get its own root directory too? 16:30:59 for what it's worth, upstream is now working on making it possible to move /snap to another location 16:31:07 tibbs: not to the best of my knowledge, no 16:31:11 I suggested /var/lib/snapd/snaprun, and I think zyga is going with that 16:31:13 Pharaoh_Atem, that's good... 16:31:15 Pharaoh_Atem++ 16:31:23 maxamillion: use my fas name 16:31:32 tibbs: it doesn't. 16:31:41 Pharaoh_Atem: what's your fas name? :) 16:31:43 If that's the case, I'm more inclined to be +0 or -1 on this... 16:31:44 maxamillion: ngompa 16:31:45 That was actually an example. 16:31:47 ngompa++ 16:31:48 maxamillion: Karma for ngompa changed to 3 (for the f24 release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:31:49 \o/ 16:31:59 tibbs: flatpak puts stuff in /opt 16:32:00 jsmith: +1 16:32:08 geez, just realized that zodbot still thinks it's f24 16:32:13 dgilmore: really? ... ugh :/ 16:32:17 dgilmore: ? no 16:32:18 maxamillion: yep 16:32:25 dgilmore: ugh 16:32:25 dgilmore: what stuff? 16:32:26 /opt is OK if they went through lanananana or whatever it is to get an identifier. 16:32:26 and it needs the rpms to be rebuilt 16:32:42 so... why don't we use the relocation feature in rpm with this? 16:32:46 Pharaoh_Atem: it is the f24 release cycle. f24 is released. 16:32:53 nirik: everything for flatpak is in /opt 16:32:57 dgilmore: not here. 16:33:05 I have nothing but google junk in /opt 16:33:16 it uses /var/lib/flatpak 16:33:19 having random crap in /opt is not okay 16:33:37 nirik: that what I have talked about with them 16:33:37 nirik: +1 16:34:01 it wouldn't have passed review with /opt usage. 16:34:15 I get the feeling people don't actually *know* you can't do this 16:34:21 because vdsm had a similar problem 16:34:23 nirik++ 16:34:27 err, has 16:34:33 nirik++ 16:34:33 jsmith: Karma for kevin changed to 20 (for the f24 release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:34:33 We do have guidelines for /opt, and there's a registry for stuff under it. 16:34:53 nirik: sorry https://fedoraproject.org/wiki/Workstation/BuildingFlatpaks?rd=Workstation/BuildingXdgApps /app not /opt 16:34:58 right, there's also someone on the epel list that wants to bring in newer gcc/tools and they package them under /opt 16:35:08 https://fedoraproject.org/wiki/Packaging:Guidelines#Limited_usage_of_.2Fopt.2C_.2Fetc.2Fopt.2C_and_.2Fvar.2Fopt 16:35:10 vdsm is using /rhev without telling anyone 16:35:30 Pharaoh_Atem: they are fixing that 16:35:40 dgilmore: thats in the bind/runtime... not on the installed system 16:35:43 can we get back on track? 16:35:44 moving to /run/ 16:35:59 so snaps 16:36:03 Pharaoh_Atem: it's a violation of the FPG, then 16:36:11 and I think that page could well be out of date 16:36:13 I think we need to defer a week for maxamillion to further investigate 16:36:19 * Rathann goes to file a bug 16:36:38 Rathann: for what?> 16:36:55 for vdsm using /rhev 16:37:00 snapd has one remaining PR to fix it: https://github.com/snapcore/snapd/pull/1745 16:37:03 Rathann: there is alrteady one 16:37:21 dgilmore: no, there isn't one open 16:37:30 as far as I know, after this is done, upstream will make a release next week of snapd and snap-confine with a configurable location 16:37:33 +1 for waiting a week 16:37:46 so I'm okay with delaying this a week 16:37:55 Rathann: they asked me about it this week 16:37:58 that way maxamillion can poke with sharp pointy sticks 16:38:01 +1 to waiting a week, I'm hoping I can get some more responses 16:38:02 Rathann: but it is currently off topic 16:38:10 or some at all really 16:38:12 right 16:38:24 thanks to Pharaoh_Atem for providing information and keeping up with upstream 16:38:34 #info maxamillion to investigate more, reevaluate next week 16:38:58 everyone okay to move on? 16:39:09 +1 16:39:12 yes 16:39:16 yes 16:39:17 #topic #1617 Council update on Third Party Software policy 16:39:18 .fesco 1617 16:39:18 https://fedorahosted.org/fesco/ticket/1617 16:39:19 dgilmore: #1617 (Council update on Third Party Software policy) – FESCo - https://fedorahosted.org/fesco/ticket/1617 16:39:36 * nirik proposed some wording there, changes welcome 16:40:41 nirik: I liked the proposed changes 16:40:45 Just as an aside, I'm not happy with the general attitude in the proposed policy 16:40:52 I'm also fine with nirik's language 16:40:57 Sir_Gallantmon: how so? 16:41:05 wording looks good to me but wanted to know more about dnf usage with non-free 16:41:28 paragan: i asked mattdm to follow up on your question. he's working with aday and can probably answer better from an implementation standpoint 16:41:29 Sir_Gallantmon: This is the wrong venue for that discussion. The Council makes decisions based on policy, FESCo decides how to implement it 16:41:40 paragan: I suppose someone could file a RFE on dnf... but right now, you are just out of luck from there. Just like you are for say offline updates. 16:42:16 jwb, thanks 16:42:16 nirik: I think your wording is fine to move ahead with. If it needs tweaking down the road... we'll tweak it down the road. 16:42:23 nirik, then let's wait for any update 16:42:52 paragan: I'd prefer to provide something that the GNOME folks can move ahead with for now 16:43:03 And amend the policy if needed to support other mechanisms 16:43:11 sgallagh: agreed 16:43:25 I am guessing that the implementation will depend on metadata_enabled, which is a repo definition that only is supported in PackageKit/gnome-software 16:43:28 Proposal: Accept nirik's changes for Third Party Software Policy 16:43:38 maxamillion: +1 16:43:38 dgilmore: yeah. 16:43:42 +1 16:43:46 sgallagh, agree but would like to get some feedback on my query 16:44:12 paragan: Absolutely. I just don't think we need to burn a week waiting for it :) 16:44:22 +1, I think it sounds fine 16:44:24 maxamillion, +1 16:44:31 +1 16:44:33 +1 16:44:42 +1 16:44:48 +1 16:44:53 +1 16:46:00 #accepted Accept nirik's changes for Third Party Software Policy (9:+ 0:- 0:0) 16:46:10 * dgilmore thinks that is right 16:46:55 sure. 16:47:23 Sir_Gallantmon: feel free to share additional concerns on the council ticket or #fedora-devel, #fedora-council if you need to. 16:47:39 #topic #1619 Sponsorship for packager needs clarification again 16:47:39 .fesco 1619 16:47:40 dgilmore: #1619 (Sponsorship for packager needs clarification again) – FESCo - https://fedorahosted.org/fesco/ticket/1619 16:47:40 https://fedorahosted.org/fesco/ticket/1619 16:47:48 Please discuss on this ticket for Sponsor policy text only not on the given reference bug 16:48:16 I think the bug thing was just miscommunication. Hopefully everyone talked and is back to ok now... 16:48:50 yes I am fine as said above 16:49:22 that said, we can add those things I listed to the policy, but there is absolutely no way that we can list everything. So, IMHO it's better to just say "sponsors can sponsor anyone anytime they like" and leave it to their judgement. I know we want the review queue down, but sometimes it's not practical to force people to review other packages. 16:49:26 Can we have some amendment to existing text to cover more cases? 16:49:35 given nirik's comments, I'm not sure what's currently missing from the policy 16:50:24 maxamillion, I was not clear that a person with single package submission who is also upstream developer can get sponsorship just on that single submission 16:50:26 I kind of agree with nirik: I'd rather reduce it down to "Sponsors are trusted to make their own decision about when sponsorship is earned" and maybe something about a path to FESCo if someone is abusing it 16:50:32 nirik: agreed. 16:50:53 nirik: +1 16:50:54 sgallagh: +1 16:50:59 +1 16:51:01 should we amend the guidelines to say jus thtat? 16:51:02 that* 16:51:15 I'm +1 for that -- I don't see anyone abusing the process 16:51:34 +1 16:51:46 should we have a formal proposal? 16:51:56 I mostly just don't want to raise the bar for contributions to make it more difficult for newcomers to join, I like to believe we can trust the Sponsors (which is how they became Sponsors in the first place) 16:52:52 * dgilmore will be right back. I need to relocate 16:52:53 Proposal: Package sponsorship is clarified to be simply "Sponsors are trusted to make their own decision about when sponsorship is earned" and that if someone believes this is being abused, they should file a ticket with FESCo/ 16:53:10 well, where is that added? 16:53:10 +1 16:53:11 sgallagh: +1 16:53:20 the sponsor page has a lot of text... 16:54:08 though I still find it not specific 16:54:13 https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group 16:54:19 I am okay at least for some change text 16:54:51 Also if we think we can trust on Sponsor then why even need to keep other sub sections 16:54:57 perhaps a new heading under 'convince someone to sponsor you' and list 'Other' and say sponsors may choose to sponsor you for any other reason they wish. 16:55:05 paragan: that's the point. sponsorship _isn't_ something that is specific 16:55:48 Just have a single line in that Policy "Sponsors are trusted to make their own decision about when sponsorship is earned" 16:56:19 I am fine with that single line 16:56:20 * dgilmore is relocated 16:56:39 proposal: add new section to how to get sponsored page that notes that sponsors can choose to sponsor for any reason, etc 16:56:47 nirik: +1 16:56:56 dgilmore: I think that puts you in violation of the packaging guidelines :-P 16:56:56 nirik: +1 16:57:00 nirik: +1 16:57:05 ha 16:57:06 nirik: +1 16:57:08 sgallagh: ??? 16:57:13 +1 16:57:23 dgilmore: "(12:56:20 PM) ***dgilmore is relocated" 16:57:30 nirik, +1 16:57:53 anything is fine as long as text is getting amended 16:58:01 +1 16:58:07 sgallagh: sorry I had surgey this week and was i pain and need to move to somewhere more comfortable. and not in the mood for sarcasm 16:58:48 dgilmore: Sorry to hear it. I wasn't being sarcastic, just making a joke. RE: https://fedoraproject.org/wiki/Packaging:Guidelines#Relocatable_packages 16:59:09 #accepted add new section to how to get sponsored page that notes that sponsors can choose to sponsor for any reason, etc (8:+ 0:- 0:0) 17:00:34 #topic #1620 Decide what to do when package is retired and nothing replaces it 17:00:37 directly 17:00:39 .fesco 1620 17:00:41 dgilmore: #1620 (Decide what to do when package is retired and nothing replaces it directly) – FESCo - https://fedorahosted.org/fesco/ticket/1620 17:00:42 https://fedorahosted.org/fesco/ticket/1620 17:01:10 this has long been an issue 17:01:40 I thought we resolved this on upgrades with the switch to --distrosync by default 17:01:53 sgallagh: why would it be? 17:01:59 I'm fine with either option 2 or 3 17:02:03 Doesn't that remove packages that aren't known to the repos? 17:02:20 I think we have a partial solution for that already: dnf/PackageKit distro upgrades and the free standing dnf --allowerasing flag can make the depsolvers remove packages on upgrades if it can't otherwise resolve the transaction 17:02:32 we long ago (extras days?) talked about a metapackage for these... and decided not to do that. 17:02:41 sgallagh: no 17:02:46 3) doesn't work; it's too complicated to maintain (see many fedup issues) 17:02:53 nirik: tibbs mentioned that ;) 17:03:15 nirik: Yeah, apparently eight years ago according to tibbs 17:03:20 * nirik nods 17:03:23 Something like that. 17:03:24 sgallagh: I wet to do distro-sync from f23 to f25 this morning on a machine and dnf-langpacks were broken 17:03:52 I could hear the laughter through the network cable, but times change… 17:04:02 I, for one, think upgrades should be allowed to fail and the user should be asked if they want to autoremove problematic packages and retry 17:04:32 * nirik isn't a fan of any solution here. ;( 17:04:49 Problems I can foresee with that metapackage: unretirement or name-reuse would be a pain in the neck, as would the ever-growing metadata on that package. 17:04:52 nirik: nor i. mostly because i think it's a case by case basis anyway 17:05:07 I'm thinking that having the single package which obsoletes things but which isn't necessarily installed by default at least gives the end user a switch they can turn on or off. 17:05:27 we could maybe put a list of blocked packages into yum metadata and then dnf could remove those on distro upgrades 17:05:30 tibbs: If it's not installed by default, it is basically useless 17:05:33 if it's not installed by default it wouldn't help tho? 17:05:36 I'd make it opt-out, if anything 17:05:54 But note that it _still_ won't cover the solution of third party repos, or packages that you just download from somewhere. 17:06:08 guys, i think trying to engineer a solution here is admirable but perhaps not time well spent. 17:06:18 jwb: indeed 17:06:19 exactly, hence the distro upgrade tools should handle this gracefully 17:06:35 Rathann: there is no one right answer 17:06:43 I know 17:06:52 it's what I said in the ticket, too 17:07:31 I guess I agree with jwb... its case by case. In the case of dnf-langpacks, what took over that? it should obsolete it... 17:07:52 adamwill wanted FPC to provide the right answer. All we could do from our end is suggest a packaging thing. 17:07:52 but if the tools do handle such cases, the user is not left wondering what to do 17:08:24 we do the metapackage thing for that in Mageia 17:08:36 we have a task-obsolete package that has those for being able to do upgrades 17:09:11 while it works, it requires people having the ability to freely edit package sources 17:09:20 while this is the norm in Mageia, this is not the case in Fedora 17:09:34 I don't even know if the Fedora tooling allows such a case 17:10:08 a metapackage would be error prone, need constant tending and also take away the choice from the user in some cases. 17:10:10 Pharaoh_Atem: If we wanted that to happen, it wouldn't be too hard 17:10:15 * jsmith has a hard stop in five minutes :-/ 17:10:38 the other bit is regularly culling it 17:10:42 I put an alternative proposal in the ticket 17:10:44 we reset task-obsolete after a release 17:10:49 Fedora would do it after two 17:11:35 kalev: would need to run it by dnf maintainers for feasability... and createrepo 17:11:37 but the biggest thing is that everyone would have to be diligent about it 17:11:51 kalev: that would make already too big metadata bigger 17:12:09 After looking into this discussion I think this problem is case by case basis, whichever solution fits to such problems, should be used to fix it and cannot be generalized. 17:12:14 also, if it didn't keep track of versions it would be bad for users choice... 17:13:14 a metapkg-obsolete package could be useful for ultimate removals, but may not be quite so necessary given dnf's distro-sync capability 17:13:30 if we were still primarily using yum or supporting it, I would say that metapkg-obsolete is the right choice 17:13:58 i'm against the metapackage, sorry 17:13:59 distro-sync doesn't solve the problem tho. ;) 17:14:06 and yum also had that. 17:14:36 it's because you're trying to solve a void. you can't do that without choice. 17:14:39 do we have something to propose 17:14:46 or should we just think about it more? 17:15:24 * jsmith has to go, sorry... 17:15:28 Proposal: This is an intractable problem that has no common solution. Handle on a case by case basis. 17:15:34 +1 17:15:37 +1 17:15:39 +1 17:15:42 +1 17:16:43 +1 17:16:54 +1, I guess 17:17:10 (Though I don't necessarily believe that it is "intractable" 17:17:32 #accepted This is an intractable problem that has no common solution. Handle on a case by case basis. (6:+ 0:- 0:0) 17:17:40 in·trac·ta·ble 17:17:40 ˌinˈtraktəb(ə)l/ 17:17:41 adjective 17:17:41 hard to control or deal with. 17:17:41 "intractable economic problems" 17:17:41 synonyms: unmanageable, uncontrollable, difficult, awkward, troublesome, demanding, burdensome 17:17:41 "intractable problems" 17:18:11 #topic Next week's chair 17:18:16 jwb: :D 17:18:18 is there something we can/should do about dnf-langpacks now? 17:18:39 nirik: I think dnf itself should obsolete it 17:18:46 making dnf obsolete them was proposed 17:18:52 its removed the functionality 17:19:03 #undo 17:19:03 Removing item from minutes: 17:19:13 sounds reasonable to me. is there a bug or ? 17:19:43 one thing I want to ask here 17:19:54 should we add obsoletes versioned? 17:20:06 I proposed it in dnf.spec as 17:20:09 paragan: yes, but no provides 17:20:12 Obsoletes: dnf-langpacks 17:20:36 okay I will ask dnf developers to add version there 17:20:43 Obsoletes: dnf-langpacks <= 17:20:57 dgilmore, thanks 17:21:03 that allows it to come back with little pain 17:21:12 yeah 17:21:16 versions are best 17:21:41 sure will get it updated in upstream dnf.spec 17:21:51 paragan: cheers 17:21:53 https://bugzilla.redhat.com/show_bug.cgi?id=1366793 17:22:55 okay 17:22:59 we done? 17:23:03 * nirik nods 17:23:07 yes 17:23:31 #topic Next week's chair 17:23:45 who wants to do next week? 17:24:18 I can do it next week 17:24:55 #action Rathann to run next weeks meeting 17:24:59 thanks Rathann 17:25:12 #topic Open Floor 17:25:55 i will give a few minutes the wrap up 17:27:11 #endmeeting