15:00:02 #startmeeting FESCO (2018-12-03) 15:00:02 Meeting started Mon Dec 3 15:00:02 2018 UTC. 15:00:02 This meeting is logged and archived in a public location. 15:00:02 The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:02 The meeting name has been set to 'fesco_(2018-12-03)' 15:00:06 #meetingname fesco 15:00:06 The meeting name has been set to 'fesco' 15:00:10 #chair nirik, maxamillion, jsmith, jforbes, zbyszek, tyll, sgallagh, contyk, bowlofeggs 15:00:10 Current chairs: bowlofeggs contyk jforbes jsmith maxamillion nirik sgallagh tyll zbyszek 15:00:16 #topic init process 15:00:20 .hello psabata 15:00:21 contyk: psabata 'Petr Šabata' 15:00:21 .hello2 15:00:22 .hello2 15:00:23 jsmith: jsmith 'Jared Smith' 15:00:25 morning. 15:00:26 jforbes: jforbes 'Justin M. Forbes' 15:00:39 apologies for not sending out the reminder 15:01:02 .hello2 15:01:03 bowlofeggs: bowlofeggs 'Randy Barlow' 15:01:23 .hello2 15:01:24 maxamillion: maxamillion 'Adam Miller' 15:01:55 yay, quorum 15:02:13 * contyk gives it another minute 15:02:56 ok 15:03:13 so we have no new business if I don't count the non-existent gpg ticket 15:03:27 we have a bunch of follow-ups, though 15:03:34 #topic F29 – rebase of dnf, libdnf, dnf-plugins-core, dnf-plugins-extras 15:03:37 .fesco 2016 15:03:39 contyk: Issue #2016: F29 – rebase of dnf, libdnf, dnf-plugins-core, dnf-plugins-extras - fesco - Pagure.io - https://pagure.io/fesco/issue/2016 15:03:40 https://pagure.io/fesco/issue/2016 15:03:53 .helloe2 15:03:55 .hello2 15:03:56 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:04:05 so we have +3 in the ticket 15:04:19 the dnf team believes this is needed 15:04:22 i'll be +1 15:04:36 +1 here as well 15:04:37 sorry for being late again, this meeting time is complicated for me 15:04:55 +1 15:05:04 It seems everyone else is +1... I'm still considering voting +0. I still feel there's an impedance mismatch between the way DNF is being developed and the Fedora releases, which could bite us. 15:05:43 jsmith: true, in general. I don't think this particular case qualifies a problematic. 15:05:45 i do wish he answered my question 15:06:31 * contyk nods 15:06:39 "It is a huge release that fix a lot of problems. But the problem for one user could mean a feature for other." 15:06:45 "We slightly improved behavior list conf class (now behave like python list or like in dnf-2.7.5) and removed behavior of append conf list class. It was requested but some users already could require formal behavior." 15:07:10 I think this should be read as "strictly speaking, not bw compatible, but we hope it doesn't matter in practice" 15:07:30 hmm that does sound not great actually 15:07:59 agreed but I think in this case it really doesn't matter in practice 15:08:58 I think it should be backwards compatible, old version there's a list-like data type that's immutable but now it's a proper mutable iterator 15:09:20 proposed #agreed FESCo approves of the DNF stack rebase (+6, 1, -0) 15:09:45 so not *technically* backwards compatible but anyone using it isn't going to notice because it shouldn't affect currently working code 15:09:47 I am +1, it has been in testing for a decent amount of time, though I would like to see pbrobinson comment as to whether his issue was addressed. 15:10:18 ok 15:10:27 a slightly reluctant +1 from me 15:10:27 #agreed FESCo approves of the DNF stack rebase (+7, 1, -0) 15:10:43 #topic Enabling pm_request in fedoraproject koji 15:10:46 .fesco 2004 15:10:48 contyk: Issue #2004: Enabling pm_request in fedoraproject koji - fesco - Pagure.io - https://pagure.io/fesco/issue/2004 15:10:49 https://pagure.io/fesco/issue/2004 15:11:21 so it's a little unclear what the next step here is 15:11:24 I don't think there's much to discuss here until there's another concrete proposal 15:11:32 Agreed... 15:11:34 * nirik nods 15:11:55 * contyk nods 15:12:07 yeah we need someone to implement something on this one 15:12:09 Right, we gave a list of requirements. It's up to them now 15:12:12 nothing we can do at this point 15:12:28 #info We're waiting for another concrete proposal to resolve this 15:12:36 #topic Ursa Major (modules in buildroot) enablement 15:12:40 .fesco 2003 15:12:42 contyk: Issue #2003: Ursa Major (modules in buildroot) enablement - fesco - Pagure.io - https://pagure.io/fesco/issue/2003 15:12:43 https://pagure.io/fesco/issue/2003 15:12:50 so, any more questions here? 15:13:22 actually yes 15:13:39 You said: "It would also require additional changes to UM to understand the defaults structure and how to properly load them" 15:14:02 How much work, some estimate? 15:14:05 EOQ 15:14:20 I don't think maintaining a list would be very hard... so I think this defaults thing is a sidetrack 15:14:25 ah, I see the last comments -- you would still prefer that over a separate config 15:14:26 * sgallagh arrives late 15:15:02 an estimate... 15:15:09 nirik: If it proves to be, a ticket could always be opened stating so 15:15:16 well, UM has a simple config that tells it what names+streams go into which tags 15:15:18 zbyszek: Could we agree that automating that would be a great thing to do, but in the interest of getting UM in production, we could temporarily maintain the list manually? 15:15:34 contyk: yes I would, I think it'd make things simpler. But if there are technical reasons to prefer a differnt approach, I won't be obstinate 15:15:35 with this it would need to know where the defaults are stored, understand the branching schema and map it to tags somehow 15:15:42 and then parse the defaults 15:16:26 I don't know how long it would take as I don't know how busy the people behind the project are 15:16:57 sgallagh: +1 15:17:16 i don't think fesco needs to be too particular about how requirements are met, just what the requirements are 15:17:29 sgallagh: +1 15:17:41 mizdebsk also says he would like to ues buildroot-only modules; if we do this, these building blocks would need to go into repos 15:17:59 that might be developer friendly, not so much end user friendly 15:18:00 yep 15:18:36 contyk: How would they not be end-user friendly? 15:18:47 so in the end how pratical is the idea of a 'buildroot' repo, thats just the repodata pointing to the modular/non modular repos? (that we can publish for end users) 15:18:53 * sgallagh assumes we're not talking about making them default streams 15:19:00 sgallagh: see the mess we have in f29 :) 15:19:07 sgallagh: we are 15:19:27 zbyszek's proposal is to only include default streams in the ursine buildroot 15:19:36 so if you want to have such modules, they need to be default 15:19:39 hmm 15:20:05 There's no middle ground? Like, "All default streams go into the ursine buildroot, plus this manual exception list"? 15:20:26 couldn't that easily lead to conflicts? 15:20:27 * sgallagh thinks 15:20:45 well, I'd like to have that 15:21:11 bowlofeggs: I'd like to assume that manual curation means some human avoiding conflicts 15:21:49 what if initially there isnt'a conflict, and then someone comes along later and needs the default stream/ 15:21:57 I'm against the "temporarily maintain the list be hand", I'd personally reject the change until everything is fully automated 15:22:13 I've seen too many infrastructure decisions be "temporary" and then live for a decade 15:22:33 not specifically in Fedora, but in general 15:22:41 maxamillion: I tend to agree... 15:23:12 sometimes you need the thing sooner than automating it would take. 15:23:32 i personally feel ok leaving that decision to infra though 15:23:35 maxamillion: Well, I suppose it wouldn't be too hard to write a script to read from fedora-module-defaults and output the ursa major config format 15:23:36 i agree in general 15:23:51 i just dont' think fesco should tell infra whether to automate or not 15:23:57 sgallagh: that might be easier than adding support to UM directly, yes 15:23:59 Better long-term if UM did this automatically, but we could at least "automate" it as part of the compose 15:24:02 I also tend to err on the side of caution when considering something that might place more burden on a packager ... it's already a thankless job and I'm not super excited about Ursa Major to begin with 15:24:26 will this place burden on packagers? 15:24:47 or does it just make a buildroot of all module default stream packages? 15:24:51 * nirik notes epel8 is pretty limited if at all until we have ursa major 15:24:55 bowlofeggs: it was my understanding that's by RelEng pushed back and it was brought to FESCo in the first place 15:24:56 my proposal adds one extra task 15:25:06 maxamillion: I think the burden is only on packagers who decide they wish to use it. 15:25:10 that's why* 15:25:11 Yeah, a script to dump fedora-module-defaults sounds like a workable solution 15:25:14 maxamillion: I don't think it was pushback. I think they wanted assurance we agreed. 15:25:19 if a packager wanted their module to be in the buildroot, they would submit a PR to the config 15:25:25 maxamillion: ah interesting, i hadn't noticed taht 15:25:38 the problem is that it makes non koji users life more difficult.. unless we can make them a buildroot repo or some other solution 15:26:13 is there a problem with buildroot repos? 15:26:19 besides being somewhat expensive 15:26:36 jforbes: I don't disagree, but if more and more of the fundamental components that are building blocks for upstream projects become modularized in Fedora, then the packagers won't have a choice 15:27:00 nirik: wait, who's a non koji user? 15:27:11 the reason releng brough it to fesco was the non koji user case... 15:27:11 COPR 15:27:26 or local mock 15:27:28 copr, mock on a local machine, rpmbuild on a local machine 15:27:42 ah ok 15:28:08 if you take foo.src.rpm from fedora and try and build it in those and it needs something from a module it will fail. 15:28:15 yeah, -1 to the whole thing then until it can be figured out how to not introduce that burden on packagers 15:28:32 contyk: the problem with PRs to enable modules is that they will often have to be created by maintainers of packages which BuildRequire something which is a module, and not by maintainers of the module itself. 15:28:39 yeah i think rpmbuild users are important 15:28:59 * till__ agrees with maxamillion and bowlofeggs 15:29:02 well, thats why I suggested making a buildroot repo 15:29:03 zbyszek: that's an interesting thought 15:29:24 maxamillion: so what burden are you referring to? 15:29:28 rpmbuild is the easier part to handle, because if some a buildreq is installed locally it just works 15:30:17 Though perhaps more convoluted as to how the replicate the success in mock 15:30:36 if you generate repo for the build tag, everyone can just consume that 15:30:43 contyk: having to figure out where to find the deps in module correlation as compared to how it is now, because today everything resides in the single source of truth 15:30:44 jforbes: well what if we allow non-default stream as proposed? how would the rpmbuild user know which stream is needed? 15:30:56 contyk: I can't do that in mock on my laptop 15:30:58 and what if rpmbuild user has the default stream? 15:31:01 contyk: we don't really want to point the world at koji do we? 15:31:18 bowlofeggs: right, that was the more convoluted piece I was referring to 15:31:26 so 15:31:48 mock config files support modules (according to msuchy) 15:32:00 the config files are also distributed with mock; they could just list the modules we include the buildroot 15:32:13 of course that means someone would need to keep these configs up to date 15:32:16 as long as we don't change them too quickly... 15:32:23 * contyk nods 15:32:34 but it's an option which doesn't rely on koji repos 15:32:41 nirik: if modularity takes off, I'm pretty sure we'll be changing them pretty quickly 15:32:53 contyk, and doesn't work with buildroot-only modules 15:32:53 contyk: that sounds ok to me i think 15:33:08 mizdebsk: it doesn't? 15:33:15 zbyszek: well, quicker than the modules go to stable? 15:33:39 contyk, how does user get the module if it's not in repos on mirrors, but only in koji? 15:33:51 contyk, depending on mock cofigs is going to be a PITA for packagers that fork the configs to add their own package repo 15:34:01 mizdebsk: point 15:34:16 * nirik notes mock configs are seperate from mock these days... 15:34:32 contyk, which is pretty much what you have to do to work on packages not yet included in the distro 15:34:45 we have modules that won't be on the mirrors? 15:34:53 we already do 15:34:55 bowlofeggs: that's the building block modules 15:35:12 why do those exist? 15:35:21 we could get mock changed to support including other config files so that the module config lives in its own file that can be included by forked configs 15:35:26 we also have packages that are not included in the repos 15:35:44 that is also news to me 15:35:53 tyll, that would solve this, yes 15:35:57 glibc32? not sure there are any others.... 15:36:03 is there a list of building block modules? 15:36:03 nirik: yes :) 15:36:20 tyll, mock already does support including config files 15:36:44 tyll: not readily available but can be put together 15:36:55 nirik, cisco codec? 15:36:57 tyll: all modules in MBS for your platform minus all modules included in the compose 15:37:15 I suppose... sure. 15:38:53 contyk, not sure how to compute this in my head :-) 15:38:54 feels like we have more confusion and questions than last week 15:38:59 this all seems very complicated 15:39:09 it's hard for me to get a clear model in my mind of it all 15:39:58 so there are two main issues, if I understand it 15:40:08 so perhaps another proposal... we could allow it to be setup/enabled for epel8 only while we sort out fedora cases? 15:40:21 one is the configuration and how to automate it so that packagers don't have to care 15:40:39 and the other is how to make the buildroot available to non-koji users; the only option is probably a buildroot compose 15:41:08 nirik, epel8 doesn't really require ursa-major as all the packages are included in existing external repo 15:41:59 mizdebsk: they are? in the appstream repo? wouldn't yum4 see those as modular with the modular repodata? 15:42:00 * contyk would like to have this ready for f30 rather than in 2020 15:42:33 contyk: yes, I think that if we answer those two questions, we are good 15:42:38 contyk: but couldn't we do a buildroot compose where we point the actual packages at the other existing repos? 15:43:23 nirik: not sure I follow 15:43:27 nirik, koji repos are not modular, koji repo is a single, non-modular repo created from epel8 packages with rhel8 repos merged in, mock in koji sees non-modular repos 15:44:10 ursa-major does not add modules to koji repos, it adds contents of modules; koji repos, with or without ursa-major, are still not modular - they don't include modulemd 15:44:49 contyk: repodata doesn't have to be a relative directory 15:44:58 mizdebsk: well, no epel8 repos actually exist yet... my understanding from the beta is we have a base repo (traditional rpms) and a appstream repo (modules). If we add them both as external repos, the appstream one will not have non modular repodata and not work? 15:45:02 So we could create a buildroot repo whose repodata merely pointed to other existing repos 15:45:24 Instead of copying all the files into it 15:45:25 but what other existing repos? 15:45:42 Everything/$arch/ and Modular/$arch/ 15:45:50 nirik, Appstream also contains tradtiotional RPMS AFAIU 15:45:51 nirik, no, koji repo will see all rpms from appstream, from all module streams 15:45:56 nirik, maybe also extra modules 15:46:23 ok. 15:46:24 that would behave differently from the koji environment 15:46:59 1. Modular/$arch/ doesn't have to match the config, and 15:47:09 2. as mizdebsk said, in koji it all appears ursine 15:47:16 in that case could we do the same for Fedora? Just include Modular as another repo? 15:47:18 here that wouldn't be the case 15:48:21 nirik: No. That way leads to disaster. 15:48:36 would it for epel8 as well? 15:48:40 i agree with sgallagh, not a good idea 15:48:40 There are packages in the Fedora Modular repos that would upgrade each other unexpectedly 15:49:28 nirik: Representative example: I have both Node.js 10.x (LTS) and Node.js 11.x (experimental) modules in Fedora right now. 15:49:46 The 11.x would replace the 10.x ones if the module metadata doesn't cause it to be filtered out 15:50:14 sgallagh, how is this handled with UM? 15:50:25 it's not 15:50:33 UM includes what you tell it to include 15:50:52 Right, if you tell UM to include both, it'll do so (and things will go wrong) 15:51:40 so 15:51:48 should we move the discussion to the ticket again? 15:51:55 with focus on the two main questions I noted earlier? 15:52:10 I don't think we can solve it here 15:52:19 What it releng's stance on maintaing a list by hand, would they be OK with doing that? 15:52:36 zbyszek: note they already maintain the defaults in the same manner 15:52:59 releng is already doing waaaay too much by hand 15:53:14 right, and it'd be 2x as much work possibly 15:53:16 but again, i think we can just authorize requirements and not demand an implementation 15:53:54 zbyszek: If someone shows me what the UM config file format is, I'll write a damned git hook for the defaults repo to generate it for us 15:54:06 bowlofeggs: right, but that's a question that weighs on the requirements that we specify, whether we ask for something automatic, or just a list kept somewhere 15:54:18 sgallagh: OK, so that'd mean automation 15:54:22 zbyszek: i think we should not ask for either of those 15:54:31 sgallagh: it's a simple JSON 15:54:36 zbyszek: i think we should leave that up to the implementors 15:55:05 bowlofeggs: but this is also visible externally, because w/o automatism, we have to ask packagers to open PRs/tickets to add modules 15:55:34 zbyszek: I don't think it's a prerequisite, but it's both easy enough and valuable enough that yes it will happen. 15:55:36 we could go for the combined approach, as suggested earlier 15:55:51 generate part from the defaults, append some other manually maintained config for special cases 15:55:58 I think that's fairly reasonable 15:56:12 +1 15:56:15 +1 15:56:19 why would the manual config not conflict with the automated configs? 15:56:28 it could 15:56:40 there's always a potential for error 15:56:41 tyll: It *could*, but i'm trusting that rel-eng and FESCo aren't unaware of this 15:56:41 zbyszek: that's a fair point 15:57:13 I'd also like to express that I think it should be a REAL exception that causes us to use something other than the defaults. 15:57:32 i still worry about someone adding something that is non-default and then someone else later needing default 15:57:45 allowing non-default seems like a path to problems 15:57:48 sgallagh, how easy would it be for rel-eng to verify that someting does not conflict? 15:57:51 you could add a CI check for that 15:57:52 bowlofeggs: I'm perfectly comfortable treating the exception list like the defaults services list 15:57:59 Requires a FESCo decision to add to it 15:58:22 well, the building blocks or whatever modules wouldn't be default right? 15:58:30 sgallagh: that might be more stomachable 15:58:31 they wouldn't 15:58:37 they could be 15:58:39 sgallagh, if we do not have an exception list, a FESCo dcision would also be required to get it created 15:58:53 mizdebsk: well, if they are, I wouldn't call them building blocks 15:58:58 tyll: I'm good with that 15:59:01 contyk, module can have default stream and yet not be included in repos 15:59:21 mizdebsk: ...yes, that's true 15:59:33 * nirik thinks this is getting pretty far into implementation... and we still haven't answered the 2 base questions contyk noted. 15:59:46 hi guys.. looking at this conversation, I am seeing a lot of people talking past each other with no clear consensus on what they are talking about. Everyone seems to have different ideas about what modules/ursamajor/etc are doing and solving and this is the 3-4th meeting like this. 16:00:28 smooge, I guess the problem is that the ticket is about enabling UM, which is already an implementation :-) 16:02:32 smooge: that's a fair point 16:02:47 i do feel like i don't fully understand modules, why we have some that don't get shipped in repos, why we want to allow rpms to depend on modules (especially non-default ones), and probably also things i don't realize that i don't understand ☺ 16:03:33 the non shipped ones are things used to build other modules that maintainer don't want to support for building *, only specific stuff.... 16:04:00 :) 16:04:31 as, as proposed above -- can we continue this in the ticket? 16:04:43 I think we identified two major pain points 16:04:45 for epel8 at least the case for rpms to depend on modules is to allow smaller add on things... like python or php or whatever packages that could be modules, but a module for 1 package is really overkill. 16:05:07 contyk: +1 16:05:30 contyk: and who can answer those two points in the ticket? 16:05:32 contyk: +1 16:05:42 zbyszek: I hope we can figure it out together 16:05:56 ok, I hope so too ;) 16:06:00 contyk: +1 16:06:02 contyk: +1 to moving on 16:07:21 #info There two major points that need to be addressed regarding Ursa Major. #1 Make it painless for package maintainers and releng to maintain the UM config, and #2 Make it reasonably easy for non-koji users to consume our buildroot content 16:07:37 #info We will discuss these topics in the ticket 16:07:42 * contyk nods 16:07:44 ack 16:07:54 ok, onwards 16:07:58 #topic The FTBFS cleanup policy is not happening 16:08:03 .fesco 1973 16:08:05 contyk: Issue #1973: The FTBFS cleanup policy is not happening - fesco - Pagure.io - https://pagure.io/fesco/issue/1973 16:08:07 https://pagure.io/fesco/issue/1973 16:08:19 It *is* happening ;) 16:08:19 I put this on the agenda just to check the status 16:08:45 good! 16:08:56 #info It *is* happening! 16:09:00 #topic Action needed: Orphan packages will be retired if they remain orphaned for six weeks 16:09:04 .fesco 1970 16:09:06 contyk: Issue #1970: Action needed: Orphan packages will be retired if they remain orphaned for six weeks - fesco - Pagure.io - https://pagure.io/fesco/issue/1970 16:09:07 https://pagure.io/fesco/issue/1970 16:09:10 same thing here 16:10:36 #info Also ongoing 16:10:53 #topic https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implementation 16:10:59 this one doesn't have a ticket, still 16:11:10 last week we decided to wait 16:11:28 any news here? 16:11:39 maintainers for gpg and gpg2 are all for it 16:11:43 .hello2 16:11:44 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 16:12:01 I'm +1 16:12:07 +1 16:12:12 +1 16:12:12 so am I, +1 16:12:30 I am still +1 16:12:44 +1here 16:12:55 i thought we were gonna wait for bcotton to file a ticket? 16:12:57 but i'm +1 16:13:58 that would make sense but it wasn't what the minutes said :) 16:14:18 but the change's been ready for wrangler for weeks 16:14:42 bowlofeggs: it seems to have fallen through the cracks in the process 16:14:59 I don't think we gain anything by waiting, it seems rather noncontroversial 16:15:12 agreed 16:15:31 yeah i'm not against +1ing it 16:15:36 it's a good change 16:15:41 The bonus is we get to finally handle a ticket before it's even opened 16:16:20 #agreed GnuPG2 as the default GPG implementation approved (+7, 0, -9) 16:16:38 alright, that's all for today 16:16:40 precog FESCp 16:16:44 contyk, there is a typo in the agreed 16:16:52 contyk, too many against 16:16:59 -9 16:17:01 haha 16:17:05 #undo 16:17:05 Removing item from minutes: AGREED by contyk at 16:16:20 : GnuPG2 as the default GPG implementation approved (+7, 0, -9) 16:17:09 7 of us approved an unapproved it 16:17:10 #agreed GnuPG2 as the default GPG implementation approved (+7, 0, -0) 16:17:18 better? :) 16:17:22 :) 16:17:25 contyk++ 16:17:25 tyll: Karma for psabata changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:17:40 #topic Next week's chair 16:17:54 I won't be around next week 16:17:59 any volunteers? 16:18:27 *crickets 16:18:31 I can do it 16:18:33 * tyll will be travelling 16:18:41 thanks, zbyszek 16:18:45 zbyszek wins the prize! 16:18:49 #action zbyszek will chair the next meeting 16:18:53 so I am guessing we will still be meeting the 10th and 17th, but skip 24th and 31st? 16:19:00 #topic Open Floor 16:19:10 nirik: good point 16:19:17 nirik: seems right 16:19:22 nirik: +1 16:19:32 nirik: +1 16:20:27 nirik, +1 16:21:04 #info No FESCo meetings on Dec 24 & Dec 31 16:21:19 anything else? 16:22:20 alright 16:22:24 #endmeeting