15:00:13 #startmeeting FESCO (2019-10-21) 15:00:14 Meeting started Mon Oct 21 15:00:13 2019 UTC. 15:00:14 This meeting is logged and archived in a public location. 15:00:14 The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:14 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:14 The meeting name has been set to 'fesco_(2019-10-21)' 15:00:14 #meetingname fesco 15:00:14 The meeting name has been set to 'fesco' 15:00:14 #chair nirik, ignatenkobrain, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor 15:00:14 Current chairs: bookwar contyk ignatenkobrain jforbes mhroncok nirik otaylor sgallagh zbyszek 15:00:16 #topic init process 15:00:18 .hello2 15:00:19 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:00:23 .hello2 15:00:24 .hello2 15:00:25 jforbes: jforbes 'Justin M. Forbes' 15:00:28 sgallagh: sgallagh 'Stephen Gallagher' 15:00:28 morning 15:00:32 .hello psabata 15:00:32 .hello churchyard 15:00:32 contyk: psabata 'Petr Šabata' 15:00:36 mhroncok: churchyard 'Miro Hrončok' 15:01:03 .hello2 15:01:03 .hello2 15:01:03 bookwar: bookwar 'Aleksandra Fedorova' 15:01:07 otaylor: otaylor 'Owen Taylor' 15:01:19 That's 6...7...8...9, wow. 15:01:25 Let's roll. 15:01:28 #topic #2241 F32 Self-Contained Change: Better Thermal Management for the Workstation 15:01:31 .fesco 2241 15:01:32 zbyszek: Issue #2241: F32 Self-Contained Change: Better Thermal Management for the Workstation - fesco - Pagure.io - https://pagure.io/fesco/issue/2241 15:01:51 .hello2 15:01:52 ignatenkobrain_: Sorry, but you don't exist 15:01:57 .hello2 ignatenkobrain 15:02:03 .hello ignatenkobrain 15:02:04 ignatenkobrain_: Sorry, but you don't exist 15:02:07 ignatenkobrain_: ignatenkobrain 'Igor Gnatenko' 15:02:08 Hmm, apparently I can't count to 9. Sorry ignatenkobrain_ 15:02:18 =) 15:02:27 zbyszek: Still running an early Pentium? 15:02:39 still no word from change owner(s)? 15:02:44 * sgallagh wonders if that joke still works or if everyone else on FESCo are too young to get it now 15:03:10 sgallagh: we still get it 15:03:20 sgallagh: it rings a bell 15:03:23 In that case: I apologize 15:03:53 Proposal: The change is rejected 15:04:10 +1 to mhroncok 15:04:15 +1 15:04:17 perhaps we could bump the thread on the list and give them a week? 15:04:45 I actually think somebody replied 15:04:48 They've had time and based on the list discussion I think it's not ready 15:04:48 actually they did reply to ignatenkobrain_ 15:04:51 let me quickly check 15:04:57 +1 to reject for F32 15:05:20 (Please remind them that they can resubmit for F33 if they resolve the raised issues) 15:05:32 Christian Kellner replied to the thread after all 15:05:40 they can even resubmit on f32 if they resolve the raised issues 15:05:54 but I think the right action is to reject now and thye can resubmit it 15:06:08 the deadlines are in December 15:07:10 * nirik isn't sure what info we are not wanting to update... 15:07:16 * contyk is distracted by a meeting 15:07:52 I guess the change should at least say that they want to ship a db and not mention the non free tool 15:08:11 Hmm, I think nirik has a point 15:08:18 On Mon, 2019-09-23 at 16:29 +0200, Igor Gnatenko wrote: 15:08:18 > So what are we going to do about this in F32? Are we going to create 15:08:18 > configuration files or we will provide some page how to create it 15:08:19 > yourself? Does Intel provide one? 15:08:19 The idea, as already mentioned by Hans in another thread, was to indeed 15:08:21 to both: 1) to have a separate package that includes configuration 15:08:23 files for different systems and then have thermald pick up the right 15:08:25 configuration for current system. 2) Additionally we were discussing a 15:08:27 way for users to submit such files to be included. But the this is an 15:08:29 optional step and could be done later as well. 15:08:42 * nirik nods 15:08:44 that's what they wrote as a reply. So to me it is clear that it is not ready at this point, but rather on the "ideas" 15:09:13 So... should we ask them to clarity the implementation and the tradeoffs ( 15:09:14 Right, I would be fine with the change given that, and the implementation of not starting thermald if a valid entry for the machine wasn't present. He mentioned such in the ticket 15:09:20 err in the thread 15:09:25 free vs. non-free software, local vs remote db, etc.) ? 15:09:53 the change page needs updating/more info for sure. 15:10:17 counter-proposal: ask the change owners to fill in the change page, revisit in two weeks 15:10:25 +1 15:10:26 zbyszek: +1 15:10:27 zbyszek: +1 15:10:31 zbyszek, +1 15:10:38 +1 15:10:46 +1 15:11:05 +1 15:11:12 zbyszek: +1 15:11:20 #agreed Ask the change owners to fill in the change page, revisit in two weeks (+9, 0, 0) 15:11:29 #topic #2246 Create a rule to get newly Fedora branched composes sooner 15:11:32 .fesco 2246 15:11:33 zbyszek: Issue #2246: Create a rule to get newly Fedora branched composes sooner - fesco - Pagure.io - https://pagure.io/fesco/issue/2246 15:12:26 * nirik is sorry we got to discussing in ticket... ;( 15:12:37 so what I think needs to happen: discussion on devel, specific proposal for fesco 15:12:51 what happened: discussion on devel, new discussion on fesco ticket :( 15:13:17 I don't mind dicsussin specific proposals at fesco level at all 15:13:19 yeah, lets perhaps try and go back to list? I can restart things there and point to the ticket? 15:13:24 but there is no specific proposal IMHO 15:13:30 ack 15:13:51 nirik: sounds good 15:14:17 and perhaps try and cull something more specific out of the ticket 15:14:52 #action nirik to restart the discussion on fedora-devel 15:15:17 Yeah, I don't think we should try to discuss this here, it's more appropriate for fedora-devel and releng lists... 15:15:24 Let's move on. 15:15:29 #topic #2230 FESCo blocker bug: Broken upgrades via libgit2 15:15:29 .fesco 2230 15:15:30 zbyszek: Issue #2230: FESCo blocker bug: Broken upgrades via libgit2 - fesco - Pagure.io - https://pagure.io/fesco/issue/2230 15:15:39 note, there is a new comment 15:15:55 I don't think it's FESCo's job to litigate the solution. 15:16:00 I think the dnf hack is fine. 15:16:19 We agreed that the problem needed to be solved. 15:16:34 sgallagh: and we agreed that we'll cote again baout the proposed solution 15:16:39 *vote 15:16:57 +1 to the workaround in dnf. 15:17:04 (and that was good, becasue the first attempt was clearly not good) 15:17:17 I personally don't give a damn which of the two proposals we implement. 15:17:23 there are 3 things to vote on basically 15:17:26 * nirik sees not much activity on the packagekit/gnome-software end. ;( 15:17:53 nirik: and I'm afraid that we won't see nay if it's not decided as a fesco blocker 15:17:58 *any 15:18:07 isn't dnf hack is enough for gnome-software? 15:18:26 ignatenkobrain_: No, because it's at the DNF layer, not the libdnf layert 15:18:32 ah, I see 15:18:34 right 15:19:14 If carrying the compat package forward is all that is needed to resolve this, that seems pretty simple and uncontroversial. 15:19:23 I am fine (as libgit2 maintainer) to add libgit2_0.28 package in f31 but only if somebody will fix this issue during the lifecycle of f31. otherwise we will have to keep this workaround forewer 15:19:26 agreed 15:19:27 sgallagh: it has caveats 15:19:30 s/forewer/forever/ 15:19:53 or, rather, until f34 15:20:15 ignatenkobrain_: Honestly, the compat package approach is probably the correct one for libgit2, since it has numerous dependents that don't all move at the same time. 15:20:19 well, dnf already hacked around it, seems like a shame to keep the compat thing another cycle 15:20:34 sgallagh, well, there is libgit2, libgit2_0.27, libgit2_0.26 15:20:45 packaging guidelines say that unversioned one should be the latest 15:21:04 ignatenkobrain_: If there *is* an unversioned one, yes. 15:21:15 I'd suggest that it should just always be versioned and leave it at that 15:21:38 the dnf workaround is the good kind of workaround 15:21:50 mhroncok: How do you mean? 15:21:57 it just works 15:22:02 it does exactly what we want 15:22:10 I would appreciate if somebody would actually look at the issue with gnome-software. Otherwise we will never fix this issue. 15:22:28 * nirik was going to ask kalev, but he's not online at the moment. 15:22:32 I can do so later tho 15:22:41 the compat package workaround: shifts the problem to the next release. removes the ability to dnf install libgit2 15:22:55 Hmm, I think the idea to create libgit2_0.28 is OK. 15:23:03 mhroncok, well, it will have to stay until F34 15:23:04 note that it cannot provide libgit2 15:23:09 because F31 → F33 upgrade path 15:23:20 ignatenkobrain: and what happens at that point? 15:23:40 mhroncok: Why is that an issue? 15:23:40 mhroncok: "removes the ability to dnf install libgit2 15:24:18 mhroncok: "removes the ability to dnf install libgit2" — are you sure? If you do 'dnf module reset...' you should be able to install either libgit2 or libgit2_0.28. 15:24:24 ... IIUC. 15:24:43 If you don't do 'dnf module reset ...', then only the second one. 15:24:44 zbyszek: so, libgit2 module is no more, correct? 15:24:48 well, the module would need a module install... 15:24:58 or at least no default stream 15:25:13 but users have it still enabled and it juts blocks anything thatvprovides libgit2 15:25:21 Jaroslav wrote: F31: Module "libgit2" has no default stream 15:25:26 so we need to remember: never provie libgit2 15:25:27 right 15:25:30 Proposal: #action nirik to ask kalev about workaround in packagekit/gnome-software and block release on this fix. If it is complicated, ignatenkobrain will create libgit2_0.28 package. 15:25:44 it is complicated 15:25:51 I think that we can all agree on 15:26:04 mhroncok: sure, but in theory it should be able to do the same thing dnf did 15:26:11 ignatenkobrain_: +1 15:26:12 and it should 15:26:19 ignatenkobrain_: +1 15:26:33 True, but even with both dnf and gnome-software patches, we don't cover all upgrade paths... 15:26:36 ignatenkobrain_: +1 15:26:44 ignatenkobrain_: +1 15:26:47 but we likely need to know really soon... since even making the package and adding it could take a day or two, then we need a compose and all testing, etc. 15:27:16 zbyszek: you mean distro-sync/upgrade bare from dnf? 15:27:24 nirik: yes 15:27:27 -1, the module reset woraround is clearly superior to the compat package and if we allow the compat package, it just means nobody would do the reset IMHO 15:27:56 also, as soon as we do that, dnf will likely try to drop their hack 15:27:58 I'm going to vote 0 here. I see benefits to either approach. 15:28:05 mhroncok: but isn't the module reset already in updates-testing? I understood the compat package to be an addition on top. 15:28:16 and instead of good, worse, we will end up with worse, worse 15:28:29 zbyszek: it is in updatest testing, yes 15:28:40 well, there will have to be a hack sometime, although I suppose over time it would affect less people 15:28:56 as long as we don't reset the stream 15:29:06 it will affect everybody who was ever affected, until they reinstall 15:29:18 sure, but fresh f31 installs won't be affeected 15:29:45 * zbyszek counts 15:30:08 nirik: yes, either way 15:30:26 the reset solution also has a limited scope 15:30:55 even if we don't solve the modular upgrade path in a general way during f32, we just change the if conditional for 31 or 32 and the hack dies with F30 EOL 15:31:24 so we're at +5, 1, -1 15:31:36 while the compat package means dragging the hack until we solve this properly, which we cannot promise we will 15:31:38 who hasn't voted. ;) 15:32:11 otaylor, bookwar ? 15:32:33 mhroncok: I agree the compat package is undesireable... but I don't know if it's worth slipping if we can't solve the gnome-software case soon... 15:32:44 we can 15:32:51 if we make people to do it 15:33:02 this was known for months 15:33:02 s/can't/don't/ 15:33:15 the dnf repsonse was CANTFIX 15:33:29 if fesco haven't mede it a blocker, it would not be fixed there 15:33:29 sure, we can, I am just saying I don't think we should. But thats just me.... 15:33:57 OK, #agreed (+5, 1, -1) 15:34:03 #agreed (+5, 1, -1) 15:34:10 in the worst case, I'll ask sgallagh to maintain this compat package :) 15:34:13 +1 too, sorry 15:34:18 nirik: I agree with you on that point in particular 15:34:29 #action nirik to ask kalev about workaround in packagekit/gnome-software and block release on this fix. If it is complicated, ignatenkobrain will create libgit2_0.28 package. 15:34:47 ignatenkobrain_: I accept that condition 15:35:13 I would like to see all three solutions in place... 15:35:36 * nirik would like to avoid the compat package 15:35:53 * ignatenkobrain_ too 15:36:10 #topic Next week's chair 15:36:24 volunteers? 15:36:42 it's a holiday in CZ 15:36:43 * contyk is on vacation for the next three meetings 15:37:01 I'll be able to join from a cellphone, but not chair 15:37:21 I can chair 15:37:30 contyk: enjoy! 15:37:46 #action ignatenkobrain_ to chair next meeting 15:37:52 :beers: 15:37:52 pingou: thanks! 15:37:53 #topic Open Floor 15:37:58 zbyszek++ 15:38:10 I had a quick item... 15:38:32 nirik: go ahead 15:38:40 * sgallagh fears that phrase 15:38:55 :D 15:39:04 rawhide multipackage gating is needing testing... would it be ok to add 2 dummy packages to the collection to use for this? They could even be something like uuid's... just one package that depends on another? 15:39:37 I can offer some of my packages for such testing :) 15:39:42 nirik: I see no problem with that. We can Obsoletes and remove them later 15:39:42 Can't you just use some normal package? 15:40:01 also, isn't it possible to test it in stg? 15:40:02 Or use ignatenkobrain_'s wild rust stuff 15:40:05 if there's some normal ones we could use thats fine... I just don't know of any off hand that might not disrupt users. 15:40:06 we can name them something cool, so we can do dnf install happiness 15:40:13 sgallagh, that's exactly what I meant 15:40:18 nirik, I have 800+ rust ones :) 15:40:48 sure, but they need to be rebuilt a lot of times per day... if there's a pair like that let me know and we can use those. ;) 15:41:16 nirik, just ping me later the day and we will arrange :) 15:41:28 nirik: or use libgit, it's already fubar :D 15:41:29 ok, cool. 15:41:33 ha ha ha 15:41:34 mhroncok, lol 15:41:48 don't call my packages fubar! 15:41:55 * ignatenkobrain_ runs away 15:41:57 dnf install fubar? 15:41:59 So... what's the best place to read up on the rawhide gating? 15:42:26 pingou, doesn't work =( 15:42:36 https://fedoraproject.org/wiki/Changes/GatingRawhidePackages 15:42:37 zbyszek: It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard'. 15:42:41 Didn't you see it? :) 15:42:43 zbyszek: currently mostly the wiki 15:42:52 the original proposal 15:43:27 we have a ci space in fedora docs 15:43:35 fedora-ci/docs repo on pagure 15:43:51 we need to consolidate docs there 15:44:24 https://docs.fedoraproject.org/en-US/ci/ 15:44:36 https://github.com/fedora-infra/bodhi/issues/2322 15:44:42 is the ticket about docs 15:45:07 Thanks. 15:45:33 Do we want to talk about Modularit or is the discussion on fedora-devel enough? 15:46:01 I wouldn't mind to meta talk about it 15:46:04 :kill_it_with_fire: 15:46:30 contyk: and I are working something up to put on the list today. 15:46:37 ignatenkobrain_: modularity or the dicussion? 15:46:46 I'd prefer to hold off on more circular discussion until we do that, if that's alright 15:46:53 sgallagh: +1 15:46:55 likewise 15:46:55 I haven't had a chance to go through the list and read it yet, so I'm not entirely ready to vote on anything related 15:46:59 mhroncok, both :) 15:47:20 I need to catch up with the latest mails in that thread, too 15:47:24 OK, anyone has anything else then? 15:47:38 nothing here 15:47:39 contyk, latest 170 emails? :) 15:48:03 ignatenkobrain_: oh, it's just that few? most of them are duplicates anyway 15:48:06 ignatenkobrain_: ~80 :) 15:48:16 * sgallagh sighs 15:48:22 I'll close in a minute... 15:48:32 * sgallagh has actually read them all, much to his regret... 15:48:44 * nirik ran a 'how many posters in this thread' last week... it was pretty small. ;) 15:48:47 sgallagh, don't regret, enjoy :) 15:48:49 sgallagh++ 15:49:35 Thanks all. 15:49:37 #endmeeting