16:01:00 #startmeeting FESCO (2017-08-11) 16:01:00 Meeting started Fri Aug 11 16:01:00 2017 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:00 The meeting name has been set to 'fesco_(2017-08-11)' 16:01:00 #meetingname fesco 16:01:00 #chair maxamillion dgilmore jwb nirik jforbes jsmith kalev sgallagh Rathann 16:01:00 #topic init process 16:01:00 The meeting name has been set to 'fesco' 16:01:00 Current chairs: Rathann dgilmore jforbes jsmith jwb kalev maxamillion nirik sgallagh 16:01:06 .hello sgallagh 16:01:07 sgallagh: sgallagh 'Stephen Gallagher' 16:01:08 morning 16:01:11 .hello kevin 16:01:12 .hello jforbes 16:01:13 nirik: kevin 'Kevin Fenzi' 16:01:17 jforbes: jforbes 'Justin M. Forbes' 16:01:31 .hello kalev 16:01:32 kalev: kalev 'Kalev Lember' 16:02:40 Hmm, I hope we have quorum today. We have at least two topics that can't really wait 16:02:56 .hello jsmith 16:02:57 jsmith: jsmith 'Jared Smith' 16:03:09 There we go 16:03:38 I'm going to go out of order today and take care of the (likely) quick items first. 16:03:59 .hello maxamillion 16:04:00 maxamillion: maxamillion 'Adam Miller' 16:04:19 #topic #1721 Non-responsive maintainer process for caillon, and retiring xchat 16:04:19 .fesco 1721 16:04:20 sgallagh: Issue #1721: Non-responsive maintainer process for caillon, and retiring xchat - fesco - Pagure - https://pagure.io/fesco/issue/1721 16:04:48 I think we just dropped the ball here. 16:05:23 Proposal: orphan all of caillon's packages and announce this. If xchat should go away, someone can pick up ownership and retire it 16:05:26 let's just go on with the orphaning here, caillon has been gone for a long while now 16:05:29 * kalev nods. 16:05:29 +1 16:05:38 +1 16:05:44 +1 16:05:46 +1 16:05:50 +1 16:06:24 sure, +1 16:06:29 #agreed orphan all of caillon's packages and announce this. If xchat should go away, someone can pick up ownership and retire it (+6, 0, -0) 16:06:36 nirik: Would you mind doing the mass-orphaning? 16:06:55 well, I can try, but not sure the new process yet... but I can find out. 16:06:55 * sgallagh wonders if this process is accounted for in the new pagure world 16:07:11 #action nirik to orphan caillon's packages 16:07:17 Thank you 16:07:26 #topic #1758 ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev) 16:07:26 .fesco 1758 16:07:36 sgallagh: Issue #1758: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev) - fesco - Pagure - https://pagure.io/fesco/issue/1758 16:07:46 I really have no desire to take over this package. I was just trying to help out. 16:08:01 and in fact I have not had time to try and update f26/f25 yet either 16:08:30 I would suggest that we need a compat- package with the old soname for f26/f25 as 3rd party repos might link with it 16:08:49 afaik, we're not supposed to prefix them with compat- anymore 16:08:59 We don't need to resolve that part of it here. 16:09:04 just name them 16:09:16 Proposal: orphan the package and announce it. 16:09:24 Either someone will step up... or they won't 16:09:31 kalev: well, it's got a lot of CVEs. ;) Most of them just fuzzier reported, but still. 16:09:53 nirik: right, that's why I think we should push it out to f25/f26, but that doesn't mean breaking binary compatibility 16:09:55 69 or so fixed in the 6.x package a few more were 7.x only 16:10:09 nirik: if we keep the old soname as well, we can make sure we don't break packages that fail to rebuild etc 16:10:10 sgallagh: +1 16:10:20 * kalev wants to make sure that fedora is usable for 3rd party repos as well. 16:10:42 kalev: Sounds like you're volunteering to pick it up :) 16:10:54 sgallagh: +1 (reluctantly) 16:11:05 I'm happy to help do the work this time, but don't really want to pick up it's regular maintainance 16:11:23 jsmith: If it's critical to be in the distro, someone will pick it up out of necessity 16:11:26 sgallagh: +1 16:11:34 sgallagh: +1 16:11:41 +1 for the record 16:12:04 +1 16:12:09 #agreed orphan the package and announce it. (+6, 0, -0) 16:12:19 so are we leaving this persons other packages? 16:12:25 and just orphaning this one? 16:12:32 .fasinfo hubbitus 16:12:33 sgallagh: User: hubbitus, Name: Pavel Alexeev, email: pahan@hubbitus.info, Creation: 2008-07-11, IRC Nick: , Timezone: Europe/Moscow, Locale: en, GPG key ID: , Status: active 16:12:36 sgallagh: Approved Groups: cla_fedora cla_done packager fedorabugs cvsl10n cla_fpca provenpackager 16:13:17 https://admin.fedoraproject.org/pkgdb/packager/hubbitus/ for list of packages. don't know how to get that from pagure yet 16:14:03 https://src.fedoraproject.org/user/hubbitus 16:14:47 He seems active on PEL 16:14:51 (but thats all the ones they have commit on, not owner) 16:15:12 what's PEL? EPEL? 16:15:19 I found http://hubbitus.info/wiki/Blog:Remmina_for_EPEL7 which is a blog post from only a couple months ago 16:15:26 kalev: Sorry, EPEL 16:16:01 So I presume that Pavel has just abandoned ImageMagick 16:16:21 did the person asking for ImageMagick update do the nonresponsive maintainer correctly? as in, was hubbitus CC-d and everything? 16:16:30 I suggest we only orphan this for now and revisit if any of his other packages get proposed down the road 16:16:52 kalev: no, I don't think so. 16:16:53 was he CC'd to the fesco ticket? I've heard of complaints recently that people aren't CC'd and don't know when their things are getting discussed 16:16:56 * kalev nods 16:17:02 they were just concerned about ImageMagick 16:17:53 WORKSFORME 16:17:54 I think maybe just orphan ImageMagick for now and if someone wants they can start proper nonresponsive maintainer process so they know what's at stake? 16:18:10 kalev: +1 16:18:12 kalev: that's what I was thinking 16:18:16 I like that approach 16:18:57 * nirik nods +1 16:19:45 +1 16:19:57 +1 16:20:10 +1 kalev 16:21:19 #agreed just orphan ImageMagick for now and if someone wants they can start proper nonresponsive maintainer process so they know what's at stake? (+5, 0 , -0) 16:21:26 #topic #1758 The maintainer for ixpdimm_sw has left. 16:21:26 .fesco 1757 16:21:27 sgallagh: Issue #1757: The maintainer for ixpdimm_sw has left. - fesco - Pagure - https://pagure.io/fesco/issue/1757 16:22:24 So, this is a request to short-circuit the non-responsive maintainer process 16:22:59 I'm fine with it -- given the circumstances of this case 16:23:26 Proposal: Reassign ixpdimm_sw to rutvijk 16:23:30 yep. +1 16:23:39 * nirik was checking that their fas email was really @intel 16:23:41 I'm in favor; it's going to be put in good hands 16:23:43 * kalev is fine with it as well. or could add them as co-maintainers as well, if that works better with our process rules 16:23:46 +1 makes sense here, not your usual unresponsive maintainer 16:23:59 +1 16:24:04 * mhroncok notes that rutvijk is not in packagers group 16:24:05 +1 16:24:07 kalev: I'd prefer to reassign it and leave the original as comaintainer, if anything 16:24:14 That way the default assignee is known to be active. 16:24:24 mhroncok: I'll sponsor them 16:24:29 sgallagh++ 16:24:30 mhroncok: Karma for sgallagh changed to 6 (for the f26 release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:24:31 +1 (both to the proposal, and to sgallagh's most recent comment) 16:24:33 sgallagh: that sounds like a good middle ground 16:24:57 Does the current maintainer have an @intel address? That would be dead 16:25:09 OK, rephrasing the proposal... 16:25:40 Proposal: Change the owner of ixpdimm_sw to rutvijk and leave the original owner as a co-maintainer 16:25:52 +1 16:25:58 +1 16:26:00 jforbes: ... did intel go under? 16:26:08 sgallagh: +1 16:26:23 maxamillion: no, they left Intel according to the ticket 16:26:28 maxamillion: no, the original maintainer left has left 16:26:30 oh ok 16:26:31 ha 16:26:34 sorry, I missed tht 16:26:34 maxamillion: He means that if they left intel, their email wouldn't work 16:26:35 that* 16:26:37 err, nm 16:26:37 right 16:26:44 thanks 16:27:01 .whoowns ixpdimm_sw 16:27:01 sgallagh: nkothapa 16:27:05 .fasinfo nkothapa 16:27:06 sgallagh: User: nkothapa, Name: Namratha Kothapalli, email: namratha.n.kothapalli@intel.com, Creation: 2016-05-06, IRC Nick: None, Timezone: US/Mountain, Locale: en, GPG key ID: None, Status: active 16:27:09 sgallagh: Approved Groups: fedorabugs packager cla_done cla_intel 16:27:25 Right, so that email address won't reach them in any case 16:28:11 * nirik nods 16:28:29 sgallagh: +1, for the record 16:28:59 #agreed Change the owner of ixpdimm_sw to rutvijk and leave the original owner (nkothapa) as a co-maintainer (+5, 0, -0) 16:29:08 #action sgallagh to sponsor rutvijk as a packager 16:29:41 Actually, is that still a thing in pagure-world? Or does any package owner automatically become a packager? 16:30:13 they still have to be in the packager grou 16:30:15 group 16:30:33 ok 16:31:10 #topic #1753 Consider adding sssd-kcm to one of the default comps groups 16:31:10 .fesco 1753 16:31:11 sgallagh: Issue #1753: Consider adding sssd-kcm to one of the default comps groups - fesco - Pagure - https://pagure.io/fesco/issue/1753 16:32:31 So, this is part of https://fedoraproject.org/wiki/Changes/KerberosKCMCache 16:32:31 I'll defer to sgallagh's option, don't really know much about sssd 16:32:36 opinion, I mean. 16:33:22 So what this does is make it possible to use the KCM Cache in Fedora. 16:33:34 Jakub slightly overstated "by default" in the ticket. 16:34:14 But alongside other changes going in for KerberosKCMCache, it will replace the KEYRING cache type as the default 16:34:37 probably @core group 16:34:41 Works for me -- consider me +1 16:34:52 sure, +1 16:35:19 As previously discussed, the main advantage here is that caches will be namespaced for use with containers. Which currently they cannot be with the KEYRING 16:35:43 +1 from me 16:35:44 We've already approved the Change, so I'm +1 to this 16:35:48 +1 here 16:36:14 +1 now that sgallagh was +1 as well :) 16:36:16 Proposal: Add sssd-kcm to @core 16:36:30 (To make it clear exactly which group we're putting it in) 16:36:50 +1 16:37:16 (I'll assume existing votes stand unless anyone dislikes the location) 16:37:56 #agreed Add sssd-kcm to @core (+6, 0, -0) 16:37:57 +1 16:38:11 #action sgallagh to send comps PR 16:38:22 OK, that's all of the easy ones. 16:38:37 #topic #1760 F27 approved Changes not in MODIFIED status (considered as not testable) 16:38:37 .fesco 1760 16:38:39 sgallagh: Issue #1760: F27 approved Changes not in MODIFIED status (considered as not testable) - fesco - Pagure - https://pagure.io/fesco/issue/1760 16:39:21 Do we want to go through these one at a time? 16:39:47 * nirik might be able to scare up some of the owners on irc.... 16:40:01 I also pinged all of them in the ticket yesterday, hoping they'd come 16:40:13 I'm here for the Platfrom python Stack 16:40:21 * ignatenkobrain is here ;) 16:40:29 * otaylor is here 16:40:31 .hello pviktori 16:40:32 pviktori: pviktori 'Petr Viktorin' 16:40:47 (me and Sir_Gallantmon are here for Packaging Rust apps/libs) 16:40:54 * nirik pinged bowlofeggs in another channel 16:41:09 OK, let's take it from the top of the list, then 16:41:42 +1 16:41:47 #topic Incomplete Changes - 32 bit UEFI Support 16:41:55 nirik: i'm here, how can i help? 16:42:10 bowlofeggs: We're going through https://pagure.io/fesco/issue/1760#comment-457099 16:42:21 We'll get to yours next 16:42:32 nirik: Do you know anything about the 32-bit EFI? 16:42:34 pjones doesn't seem around. No idea the status. 16:42:56 .hello ngompa 16:42:57 Sir_Gallantmon: ngompa 'Neal Gompa' 16:43:03 Proposal: Wait one more week, then drop the change if no response. 16:43:07 Proposal: Defer to F28 unless pjones reports that it's already done and just not updated 16:43:22 sgallagh: +1 16:43:27 +1 16:43:32 nirik: To which? 16:43:33 jsmith: sorry, I like the wording on sgallagh's :D 16:43:39 sgallagh: +1 16:43:43 +1 sgallagh 16:43:52 +1 to my own, FTR 16:44:12 sorry, yeah, to sgallagh's. This cycle is short and busy and I don't think we can wait too long... 16:44:17 I'm +1 to either/both 16:44:20 My thoughts exactly 16:44:43 #agreed Defer to F28 unless pjones reports that it's already done and just not updated (+6, 0, -0) 16:45:29 #topic Incomplete Changes - Bodhi Non-RPM Artifacts 16:45:39 @bowlofeggs What's the status on this? 16:45:41 ok, i'm unsure how to classify this one 16:45:53 bodhi's code is now flexible enough to have support for other types 16:46:03 and it has *most* of what is needed for modules 16:46:07 but it can't yet mash modules 16:46:16 so in one sense, yeah we can add more types to bodhi now 16:46:29 but i don't have a complete second type yet that can be tested 16:46:35 so maybe it's not ready for testing? 16:46:55 I'd say it's not ready for testing 16:47:07 i feel like having it mash module would prove that it can handle multiple types, while right now it can only theoretically do so, if that makes sense 16:47:14 yeah i think that's reasonable 16:47:20 * nirik nods. 16:47:20 however, I'm not sure this is a Change in the sense that it's something user facing, it seems more like an infra or releng change 16:47:30 i have two on this list - could we do my other one next too while i'm here? 16:47:32 so I'm kind of on the fence about how to handle it 16:47:34 do we need this for after branching? or just after release? 16:47:40 maxamillion: yeah it's a little weird to be a change 16:47:52 the Change process is also something we use for advertising stuff (both internally in Fedora and to the outside world); is this in a state where it needs to be advertised? 16:48:11 nirik: we need this to be able to ship module updates. so probably during branching (so we can have a module updates-testing repo) 16:48:29 ok, and thats next tuesday. ;) 16:48:33 haha 16:48:38 well, bodhi enablement actually... 16:48:42 well, we don't yet have a patch ready for modules 16:48:51 mashing modules i mean 16:48:53 which is the 29th 16:49:06 i can't say for certain we will have it by then 16:49:12 That's somewhat alarming. This is a prerequisite for some of the other Changes to be complete :-/ 16:49:19 i'm waiting on the factory 2 team to finish that patch 16:49:25 langdon ^^ 16:49:40 * langdon looks up 16:49:57 bowlofeggs: this was a mash patch, or moving to bodhi using pungi and patching it in there? 16:50:26 nirik: the goal is to have bodhi use pungi to "mash" modules 16:50:35 i probably shouldn't say "mash" anymore 16:50:46 ok, that is confusing... yeah. ;) since 'mash' is it's own thing 16:50:50 yeah 16:51:11 we need a new word! 16:51:13 there is a WIP PR for this at least: https://github.com/fedora-infra/bodhi/pull/1697 16:51:18 * maxamillion gets the paint options for the bikeshed 16:51:20 "repo making" 16:51:22 This is why we should never use the same word as a verb and a noun :-p 16:51:52 sgallagh: we should google that 16:51:58 unfortunately, there are two entirely different implementations of getting bodhi to use pungi proposed in PRs right now :/ 16:52:06 jforbes: Thank you for that 16:52:16 the other is: https://github.com/fedora-infra/bodhi/pull/1676 16:52:24 anyways, yeah let's say it's not ready for testing 16:52:35 (and can we do my erlang one next too, while i'm here? ☺) 16:52:43 bowlofeggs: +1 16:52:46 bowlofeggs: The problem with that is that "not ready for testing" at this phase means "defer to the next Fedora release" 16:52:59 bowlofeggs: what sgallagh said 16:53:00 Which is going to be problematic for other dependent projects 16:53:09 yeah, i see 16:53:22 Like the Modularization of Server and Cloud 16:53:25 would that mean we can't deploy a bodhi that can do this during the bodhi enablement period? 16:53:35 Without Bodhi updates, we can't ship errata 16:53:44 that's actually why I question this as a Change ... it's seems like a RelEng or Infra concern and I don't know if it needs to be a Change 16:53:53 like, could we *say* we are targeting f28 but then say "oh look, we got it done!" next month? 16:54:06 bowlofeggs: I think what we need is a firm commitment that you could meet that date 16:54:08 ultimately I'd defer it's release schedule to Infra and/or RelEng (or both?) 16:54:22 if so, then I'm okay with exempting this from the deferral rule 16:54:33 makes sense 16:54:48 phew 16:54:57 sgallagh: since i am not involved in implementing the final bits of the change, i can't personally make such a commitment. my piece of the work was refactoring bodhi to be flexible for more types, but the module "mashing" is being done by others 16:55:18 i will say that maxamillion and i have been talking about adding containers to bodhi at the flock bodhi hack session 16:55:19 bowlofeggs: Can you give names so we can get them in here? 16:55:25 so that would also "prove" that this works 16:55:29 * nirik knows dustymabe was testing this in stg recently... so I suspect it may be further along than thought 16:55:41 sgallagh: mcurlej is the main developer working on "module mashing" 16:55:42 nirik: not the multi-type stuff I think 16:55:50 yeah, that's on the list 16:55:52 perhaps only ostree... 16:55:55 nirik: I think that Dusty was only looking at pungi for updates 16:55:56 I'll be doing that at Flock 16:55:56 nirik: dustymabe has been working to get ostrees 16:56:07 (and ostrees as a result, yeah) 16:56:12 if maxamillion and i get containers into bodhi at flock, that would count i think as "testable" 16:56:38 maxamillion, bowlofeggs: Are you good with staking Fedora's schedule on that? If you are, I'm on board 16:56:43 i think a container "masher" will be easier - i think we'll just use skopeo and it should be simple 16:57:08 sgallagh: i feel comfortable with that. maxamillion? 16:57:24 sgallagh: keep in mind that that is orthogonal to modules 16:57:37 yeah, I'm on board 16:57:44 sgallagh: like, this would just prove that bodhi *can* handle multiple types, but not that it can do modules 16:57:49 and it sounds like modules is your concern? 16:58:05 so like, adding containers to bodhi doesn't help modules get mashed, if that makes sense 16:58:06 Proposal: Bodhi non-RPM Artifacts is expected to be ready by bodhi enablement, so we give it a pass today. 16:58:21 +1, I guess 16:58:23 and the change is vague - it doesn't say which non-RPM artifact should work 16:58:25 bowlofeggs: Right, but it's a dependency. 16:58:28 +1 16:58:35 just that *some* artifact should work 16:58:40 sgallagh: indeed 16:58:50 +1 16:58:50 sgallagh: +1 16:58:54 bowlofeggs, i would really like to get to a hard date on module mashing/etc .. is that a question for threebean? 16:59:18 langdon: yeah, or mcurlej (who's doing the work) 16:59:18 +1. Beta might be a good date for a hard date? can we reevaluate this at Beta release? 16:59:23 +1 16:59:25 sure 16:59:27 #agreed Bodhi non-RPM Artifacts is expected to be ready by bodhi enablement, so we give it a pass today. (+6, 0, -0) 16:59:36 kalev: Seems reasonable 16:59:59 thanks for the poke sgallagh 16:59:59 #topic Incomplete Changes - True Noarch Erlang Packages 17:00:15 ok this one i'd say should be pushed to f28 unfortunately 17:00:22 i got the two things i thought would need to be changed done 17:00:30 but there was a sneaky third thing that i didn't anticipate 17:00:35 and i just haven't gotten it yet ☹ 17:00:36 * sgallagh nods 17:00:43 It happens. 17:00:46 indeed it does 17:00:53 rebar (the erlang build tool) didn't work with the changes i made to erlang and the rpm macros 17:00:54 Proposal: Noarch Erlang is deferred to F28 17:01:00 +1 17:01:01 +1 17:01:04 +1 17:01:06 +1 17:01:20 +1 17:01:42 +1 17:01:44 #agreed Noarch Erlang is deferred to F28 (+6, 0, -0) 17:01:55 bowlofeggs: Thanks for joining us 17:02:02 sure, thank you for the discussion! 17:02:12 #topic Incomplete Changes - Graphical Applications as Flatpaks 17:02:25 otaylor, kalev: Thoughts? 17:02:40 So, it's not meaningfully testable now 17:03:38 otaylor: So it should bake for another release, would you say? 17:03:41 as much as I'd like to see this, I think it makes sense to continue working on this in rawhide (F28) after F27 as branched 17:03:44 Almost allof the code is written, I plan to chase people to get things landed at Flock 17:03:55 It's not meaningful to work on "in rawhide" because it's all infrastructure 17:04:42 I think it's reasonable to say that I should stop chasing people to get things landed if it doesn't happen by the beta freeze 17:05:25 Proposal: extend the deadline for Flatpak to three days before Beta Freeze 17:05:32 (The three days being time to back things out if needed) 17:05:38 I think it probably makes sense to continue chasing people, just that we should try and build F28 rpms as flatpaks once this lands, to avoid potentially disrupting F27 17:05:57 +1 to sgallagh 17:06:12 +1 to sgallagh 17:06:28 sorry.. a bit of a side note.. but isn't this like the bodhi change? there is no "release dep" for shipping flatpaks.. 17:06:35 is there? 17:07:01 yeah, this is more of a internal thing... except we want to trumpet it if its ready 17:07:01 FYI, three days before Beta Freeze is the day after the end of Flock 17:07:06 kalev: I agree that people shoudln't be making changes to their f27 rpms during the freeze. But you can build flatpaks off of private branches, so it doens't force you to work in f28 17:07:46 * nirik is fine revisiting before beta freeze to see where things are at. 17:08:00 otaylor: Will you be at Flock? 17:08:02 langdon: yeah, it's a change proposal for f27 largely because it does involve infrastructure changes, and so needs to be coordinated with the release schedule. 17:08:10 sgallagh: Yes, definitely. 17:08:30 Perhaps you could give a readout during the "What did we do / Demo Day" block on the last day? 17:09:04 sgallagh: I have a talk about it, though it's against hte factory-2.0 talk that mbonnet is doing, which is unfortunate 17:09:18 sgallagh: I can recap during that block 17:09:21 otaylor, sure.. and to nirik's point, it is good pr.. but.. I am not sure you should defer it to f28 even if it is a month late.. 17:09:21 Thanks 17:09:59 but /me goes back to reading/writing email.. poke if i should come back and provide more crazy :) 17:10:21 otaylor: do you have a hackfest scheduled for Flock around this stuff? There's a reasonable amount of planning that's going to need to go into the deployment to stage but if it's code complete by flock, I'd definitely like to get things up and running in stage infra 17:10:30 we have always had problems landing things between releases... but we will have to come up with better ways with all the modularity work. ;) 17:10:32 So can we get more votes on my proposal? 17:10:35 Proposal: extend the deadline for Flatpak to three days before Beta Freeze 17:10:37 +1 17:10:40 +1 17:10:41 +1 17:11:08 +1 17:11:28 nirik, for sure :) 17:12:13 +1 17:12:13 maxamillion: I don't, no. Not sure there would be room to schedule one without running into other hackfests that the relevant people are also in 17:12:35 +1 17:12:39 #agreed extend the deadline for Flatpak to three days before Beta Freeze (+6, 0, -0) 17:12:39 otaylor: alright, we'll get it sorted 17:13:05 ignatenkobrain has asked that we jump to the Rust topic because he needs to drop soon 17:13:20 #topic Incomplete Changes - Packaging Rust applications/libraries 17:13:26 * otaylor needs to run, thanks everybody! 17:13:32 So we've landed RPM 4.14 today in Rawhide. Work has been done in RPM, libsolv, dnf, libdnf and whatnot. rustr2pm tooling is ready. FPC approved Packaging Guidelines for Rust on last meeting. 17:14:52 Release Engineering is not ready and I can't get any clue about any status about it... I've been asking since February question: "what needs to be done to support rich deps?" and proposing mine and Sir_Gallantmon's help.. However, rel-eng didn't provide any things which should be done 17:15:04 https://lists.fedoraproject.org/archives/list/rel-eng@lists.fedoraproject.org/thread/CSOOHPG2S6PTXMO5Y3OU57HBLNTX3AQZ/ <-- for reference 17:15:06 ignatenkobrain: So if I understand correctly, this effort is blocked on Rel Eng not having cycles to update some of the tools? 17:15:36 sgallagh: no, it's blocked by rel-eng not giving any information what needs to be done 17:15:59 * ignatenkobrain is a resource and I can spend time helping with things, but no one from rel-eng can answer question "what to do" 17:16:05 I think partly it's not fully known what tools will break 17:16:19 mash for sure. but there's plans to replacee it with pungi 17:16:33 possibly koji hub since it reads rpm info 17:16:38 I don't think we need to go *too* far into the details here. 17:17:02 Is there any realistic expectation that if releng answered you right this minute that it would be ready for F27? 17:17:02 yeah, just pondering. I really don't know. we would need to really try and test it to find out what would break. 17:17:04 so I would really like to get this change in F27 (because things like https://fedoraproject.org/wiki/Changes/StratisStorage depend on it) 17:17:18 can't this work without rich deps? 17:17:24 we spent time with releng during f26 cycle to get this ready for f27 17:17:30 kalev: no. 17:17:36 We tried 17:17:47 It went really badly 17:17:48 sgallagh: yes, it might be doable 17:18:43 also for reference, FPC approved our guidelines here https://pagure.io/packaging-committee/issue/705 17:19:00 I am out of ideas how to get information from release engineering.. 17:20:06 FESCo doesn't really have any influence over rel-eng 17:20:27 So if you cannot proceed without rel-eng and rel-eng isn't helping... I'm inclined to vote to defer this Change 17:20:27 back 17:20:30 phone died 17:21:15 as far as I'm aware, there's only three things that need to be done: 17:21:17 ignatenkobrain: the problem of "why you can't get info from releng" I think is because releng literally doesn't know the scope of what's going to break ... this is new territory 17:21:20 * nirik answered as best he could in https://pagure.io/releng/issue/6889 17:21:22 1. mash -> pungi for bodhi 17:21:34 2. pungi dnf resolver for f27+ 17:21:53 3. extricate yum code out of koji and port to dnf 17:22:08 I concur with sgallagh. we're on tight schedule for F27 and sounds like it would be safer to have this as a F28 feature 17:22:09 3 can not happen, upstream is going to support yum for years to come 17:22:13 upstream koji * 17:22:26 maxamillion: that can be done as a module that chooses resolvers 17:22:56 and it really only uses yum for repo parsing 17:22:59 Pharaoh_Atem: fair, that could be an option and just have it default to yum for backwards compat ... but that's a non-trivial amount of work and F27 is on a tight time table 17:23:08 I started splitting this out as pyrpmmd a few months ago 17:23:17 Pharaoh_Atem: rocking +1 17:23:21 https://pagure.io/pyrpmmd 17:23:33 Pharaoh_Atem: is there a pull request for koji somewhere we can try and get some attention on? 17:23:55 not yet, no, but I can produce one this weekend 17:24:17 I got demoralized from lack of info from releng some time back, so I hadn't worked on it much lately 17:24:25 Proposal: Defer this Change to F28 and FESCo will try to get rel-eng's attention focused on it 17:24:31 sgallagh: +1 17:24:50 * Pharaoh_Atem grumbles that this will get delayed again anyway 17:24:57 just like has the last two times we've tried this 17:25:03 sgallagh: that would work for me if one could guide me to someone who is able to get something out of rel-eng ;) 17:25:13 sgallagh: +1 17:25:24 +1 17:25:35 ah, you already wrote it here ;) 17:25:41 +1 17:25:42 so ignore me 17:26:10 +1 FTR 17:26:11 perhaps we could try a rawhide rust test package after branching and get a more accurate list of broken things (but that won't get all of them... ) 17:26:34 #agreed Defer this Change to F28 and FESCo will try to get rel-eng's attention focused on it (+5, 0, -0) 17:26:44 nirik: works for me, we (Rust SIG) has 150+ of them in COPR ;) 17:26:54 nirik: we were supposed to do this during F26!!! 17:27:05 I'm sorry, I can't keep my cool about this anymore 17:27:26 dgilmore literally told me he would turn it on for Rawhide during the F26 development cycle 17:27:29 well, we have a ton of things to do... this is was not on the top of the pile. 17:27:33 so that we would use it for F27 17:27:40 I'm sorry it didn't work out. 17:28:20 I'm just disappointed 17:28:26 this keeps happening 17:28:26 I'm sorry it didn't work out either, but FESCo's job is to make sure F27 goals are realistic. changing this for F27 is not realistic at this point 17:28:38 although I am sure many here would like to see this change happen (me included) 17:28:49 kalev: +1 17:28:52 kalev: +1 17:28:59 kalev: +1 17:28:59 kalev: it's not that it's being delayed to F28, it's that it *keeps* getting delayed because there's no way to get releng be on ball about this 17:29:10 me too. I can try and help (but I have limited cycles too) 17:29:13 it doesn't matter if I do work on this, it never gets deployed 17:29:18 (i am also disappointed, because i have a rust package too ☹, but yeah f27 is so soon) 17:29:59 well, it happened along at the same time as modularity, ostrees, flatpacks, 10,000 other things... thats life sometimes... 17:30:18 and a very short f27 cycle to boot 17:30:27 and yet all these things somehow manage to get their stuff done? 17:30:29 nirik: modularity under the hood will use rich deps anyway.. 17:30:36 like he said 17:30:43 #topic Incomplete Changes - Java 9 17:30:52 * Pharaoh_Atem grumbles and walks away 17:31:14 sgallagh: thanks for bringing topic earlier, so I can go now! 17:31:18 did option 1 1. mash -> pungi for bodhi solve this problem? 17:31:21 Apologies, but I've got another ${DAYJOB} meeting, so I'll be mostly-absent for the rest of the meeting :-( 17:31:30 ignatenkobrain: Thank you and Pharaoh_Atem for participating. I wish we had better new :( 17:31:31 *news 17:32:01 Does anyone have any news at all about Java 9? 17:32:15 dustymabe: mash -> pungi fixes nearly everything 17:32:25 I don't see an openjdk 9 package in Koji 17:32:27 Pharaoh_Atem: then you'll get what you want I think 17:32:34 we've got a pretty clear path forward 17:32:41 dustymabe: Pharaoh_Atem: nirik: let's move to #fedora-releng 17:32:43 maybe I'm being too optimistic 17:32:51 ignatenkobrain: +1 17:33:03 dustymabe, Pharaoh_Atem Would you mind moving to #fedora-releng? This meeting is going to be long already :-| 17:33:29 moving now 17:33:30 Proposal: Defer Java 9 to F28 17:33:34 Thanks 17:33:39 sgallagh: +1 17:33:42 +1 17:33:43 +1 17:34:14 +1 17:34:16 its still under review. 17:34:18 +1 17:34:39 #agreed Defer Java 9 to F28 (+5, 0, -0) 17:35:29 I'll skip KCM cred cache because we approved the things blocking it earlier 17:35:39 #topic Incomplete Changes - Modular Release 17:35:55 This one has me nervous. 17:36:01 @threebean Are you around? 17:36:06 I am 17:36:07 sgallagh: same 17:36:08 * threebean reads up 17:36:30 threebean: https://pagure.io/fesco/issue/1760#comment-457099 17:36:31 We 17:36:38 The Change is not listed as testable 17:36:46 What is the actual status? 17:38:13 oh, there's so many pieces. give me a moment to list them. 17:38:44 on MBS, I think we're still waiting on the modularity group to get the module guidelines approve before we can open up the MBS to the whole packager group. 17:38:52 not sure of the status there, but, waiting for word. 17:39:02 MBS is tesetable though, yes? 17:39:05 testable* 17:39:15 yeah - no substantial changes from f26 there. 17:39:17 can be tested ... however that should be written with real words and without typos 17:39:22 threebean: alright 17:39:33 freshmaker is significantly new. 17:39:46 right 17:40:22 we're code complete for module rebuilds in freshmaker, but are currently waiting for the request for resources to proceed with fedora-infra. 17:40:39 things have been busy. so, no live systems there yet to test. 17:40:47 * nirik was hoping to have our prod openshift up today, but... yeah, swamped. 17:41:07 https://pagure.io/fedora-infrastructure/issue/6183 17:41:11 * threebean nods 17:41:43 OK, but it sounds like this is all proceeding at least. 17:41:44 threebean: any update on the security review before the MBS flood gates are opened? 17:41:59 for the compose bit - the change is mostly about releng config changes to set up the f27 server compose. 17:42:01 but we haven't branched yet, so that's not a thing. 17:42:11 Proposal: extend the deadline to three days before Beta Freeze 17:42:14 no major code changes in pungi planned. this is all just "set up the compose like we did for f26" 17:43:00 maxamillion: nothing new there yet. there was one major issue which was about more granular acls from koji's point of view. as I understand it that is being worked on on the koji side, but there's not much we can do in mbs until that's done. :/ 17:43:17 threebean: ah 17:43:35 if people are concerned about bodhi+modules, the PR is here https://github.com/fedora-infra/bodhi/pull/1697 17:43:40 it's concerning that's blocked and so many other things are still in flight 17:43:43 sgallagh: +1 17:43:57 sgallagh: +1 17:44:00 mcurlej was able to get bodhi mashing modules in the staging environment. it's a matter of cleaning up the PR, etc. 17:44:10 sgallagh: +1 17:44:22 sgallagh: +1 17:44:30 #agreed extend the deadline to three days before Beta Freeze (+5, 0, -0) 17:44:46 #topic Incomplete Changes - Modular Server 17:45:16 I think we're actually in pretty good shape here. We got a testable image built last week, right langdon ? 17:45:29 So this should probably just be moved to MODIFIED 17:46:32 awesome 17:46:35 * nirik runs for some more coffee. back in a tick 17:46:37 sounds good 17:47:55 Hmm, I just checked with some other folks. Looks like we had a compose, but not a fully-testable image yet 17:48:17 But we're expecting the issues with robosignatory to be resolved either today or Monday 17:48:42 I'll politely request that we get an extension since we're close :) 17:49:01 sgallagh: what issues is that? 17:49:11 The code I've seen for modularity has hit production a few hours ago 17:49:35 Yeah, contyk tells me he expects that the fixes are in place, we just haven't done a new compose with them yet 17:49:46 ah okay 17:49:53 ah ok 17:49:54 We still need to finish getting the installer module cleaned up as well. So probably next week it'll be ready for general testing. 17:50:15 yeah, if it's expected to be code complete and the only thing standing in the way of being test read is a compose, I'm good to extend 17:50:23 Proposal: Defer decision for one week 17:50:28 sgallagh: +1 17:50:28 +1 17:50:34 +1 17:50:40 +1 17:51:30 nirik: Vote? 17:51:39 ohh .. sorry.. wasn't looking 17:51:56 langdon: no worried, looking good 17:52:22 I think you can just go on for deferred status, that doesn't sound like an important thing to have majority vote for 17:52:28 ok 17:52:41 #topic Incomplete Changes - No More Alphas 17:52:45 * langdon read scrollback.. sounds about right... but langdon is still very stressed 17:52:48 yeah, without majority we'd defer anyways 17:53:13 langdon: Good, if you were relaxed, I'd have to panic. 17:53:21 sgallagh, lol 17:53:42 +1 17:55:00 So, I guess this is testable insofar as we skipped the Alpha release... 17:55:05 sgallagh: +1 17:55:14 +1 17:55:45 Proposal: Consider it testable 17:55:47 +1 17:55:47 =1 17:56:00 the wiki changes have been proposed by adamw 17:56:02 +1 17:56:19 +1 17:56:31 * adamw heartily approves of this delicious fudge 17:56:31 as long as adamw is ok with the current state, I think we can consider it testable 17:56:33 om nom nom 17:56:46 i mean, it'd be nice if we had the compose gating in place, i guess. 17:57:15 adamw: Do you have anything to add before I move on? 17:57:26 not beyond what i wrote in the tickets, no 17:57:29 * sgallagh wants to finish this meeting before Flock starts :) 17:57:35 it'd be good to know what dgilmore thinks of the current state, though 17:57:42 he's out until monday... 17:57:45 ah 17:57:53 * adamw keeps trying to dodge the blame for this change but it's just not working 17:58:14 #agreed Consider it testable (+5, 0, -0) 17:58:26 #topic Incomplete Changes - NSS Default File Format SQL 17:59:21 I thought this was done. 17:59:49 I'm trying to find evidence either way. 17:59:51 Please hold 18:00:09 *music plays* 18:01:27 I can't tell from the package 18:01:38 I'm trying to figure out if upstream changed the default and it got picked up in a rebase 18:02:30 OK, I officially have no idea 18:02:53 Proposal: Defer to F28 unless it's found to already have been implemented in Rawhide 18:03:08 +1 18:03:54 sgallagh: +1 18:04:08 +1 18:04:12 +1 18:04:34 #info We cannot find any clear evidence whether this has been implemented yet in Rawhide 18:04:54 +1 18:04:58 #agreed Defer to F28 unless it's found to already have been implemented in Rawhide (+5, 0, -0) 18:05:17 #topic Incomplete Changes - PHP 7.2 18:05:38 There are no 7.2 builds yet in Koji 18:05:48 Proposal: Defer PHP 7.2 to Fedora 28 18:05:52 deferred by owner - https://bugzilla.redhat.com/show_bug.cgi?id=1474939 18:05:58 Oh, ok 18:06:01 No action required then 18:06:21 #topic Incomplete Changes - Platform Python Stack 18:06:28 we have it testable in copr. due to the late approval we just finished that today. will move to rawhide ASAP 18:06:34 Ticket says the owners claim they can make it in time 18:06:52 Proposal: Extend deadline to three days before Beta Freeze 18:06:56 also not sure if we should wait for releng approval before we do so 18:07:08 does it need any releng help to get this done? 18:07:17 mhroncok: What is needed from releng ? 18:07:18 kalev: no 18:07:20 sgallagh: +1 18:07:26 sgallagh: +1 18:07:27 Release engineering: #6917 (a check of an impact with Release Engineering is needed) 18:07:31 https://pagure.io/releng/issue/6917 18:07:36 then I think you don't need to wait for releng approval 18:07:41 was asked by jkurik to include this to the change page 18:07:47 or just ping on irc to get it quickly, in #fedora-releng 18:07:49 seems to be some new rule I didn't know about 18:08:16 mhroncok: I think they may want to know if rel-eng tools will need to be updated to look for platfom-python 18:08:20 I think it's fine to land asap 18:08:33 ok, will push it to rawhide asap 18:08:35 Yeah, I'd prefer to land it now and back it out if things go wrong 18:08:41 * kalev concurs. 18:08:49 land as soon as possible please 18:09:42 will do next week, there are some full-time provenpackagers on this 18:09:52 #info Changes are ready and will be pushed next week 18:10:00 Do we need to vote, or just move on? 18:10:24 just move on 18:10:27 eh, I say move on but a vote is probably good for posterity 18:10:33 I don't care, either way 18:10:38 #topic Incomplete Changes - Reduce Initial Setup Redundancy 18:10:46 #info deferred by Change Owner 18:10:48 bye, thanks 18:10:54 thanks mhroncok 18:10:55 #topic Incomplete Changes - Remove krb5-appl 18:11:10 I spoke with the Change Owner yesterday, this was blocked on a miscommunication. It's all done. 18:11:26 +1 18:11:28 excellent 18:11:29 #info Communication failure. This Change is ready 18:11:46 #info Incomplete Changes - Switch libidn-using applications to IDNA2008Switch libidn-using applications to IDNA2008 18:11:48 great 18:11:55 #info Deferred by Change Owner 18:12:07 ... and that's the ball game 18:12:12 #topic Next week's chair 18:12:25 I can, haven't done it in a while 18:12:26 I'll be out next week (traveling to see the eclipse) 18:12:40 #info kalev to chair the 2017-08-18 meeting 18:12:47 #topic Open Floor 18:13:13 thanks kalev ! 18:13:22 * sgallagh sets a short fuse because we're running late :) 18:13:37 sgallagh: +1 18:13:42 * nirik may also not be around next friday 18:13:58 but luckily I don't have to travel anywhere to see the eclipse. ;) 18:14:05 nirik: lucky!!! 18:14:07 thanks for hosting sgallagh! (that was a marathon) 18:14:08 sgallagh++ 18:14:09 maxamillion: Karma for sgallagh changed to 7 (for the f26 release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:14:14 Thanks 18:14:15 thanks sgallagh 18:14:19 #endmeeting