18:00:01 #startmeeting FESCO (2022-01-18) 18:00:01 Meeting started Tue Jan 18 18:00:01 2022 UTC. 18:00:01 This meeting is logged and archived in a public location. 18:00:01 The chair is mhroncok. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:02 The meeting name has been set to 'fesco_(2022-01-18)' 18:00:02 #meetingname fesco 18:00:02 The meeting name has been set to 'fesco' 18:00:07 #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, mboddu, tstellar, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor 18:00:07 Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mboddu mhroncok nirik sgallagh tstellar zbyszek 18:00:10 #topic init process 18:00:13 .hello2 18:00:14 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 18:00:16 .hello2 18:00:16 .hello churchyard 18:00:17 dcantrell: dcantrell 'David Cantrell' 18:00:19 mhroncok: churchyard 'Miro Hrončok' 18:00:33 .hello ngompa 18:00:34 Eighth_Doctor: ngompa 'Neal Gompa' 18:00:48 morning 18:01:12 hi everyone 18:01:30 .hello2 18:01:31 bcotton: bcotton 'Ben Cotton' 18:01:44 .hello tstellar 18:01:45 tstellar: tstellar 'Tom Stellard' 18:01:50 I see 6 fesco memebers 18:01:54 *members 18:02:09 5? 18:02:26 6. 18:02:31 Nvm. 18:02:41 #topic #2711 F36 Change: Enable fs-verity in RPM 18:02:49 .fesco 2711 18:02:50 mhroncok: Issue #2711: F36 Change: Enable fs-verity in RPM - fesco - Pagure.io - https://pagure.io/fesco/issue/2711 18:03:26 any news here? 18:03:35 good news, I submitted support for PGP keys and signatures for the kernel 18:03:35 I am not completely caught up on this thread 18:03:44 hello o/ 18:04:05 .hello sgallagh 18:04:06 StephenGallagher: sgallagh 'Stephen Gallagher' 18:04:10 that would allow usage of only one key to produce fsverity signatures 18:04:22 the same used to sign RPM headers 18:04:32 robertosassu: thats cool. 18:04:51 I still need to add a verify_pgp_signature() call in the fsverity code 18:04:55 I still think we need a overall plan here... 18:05:05 robertosassu: good to hear that. Do you have any idea what is the timeframe for those patches upstream? 18:05:19 and to modify the fsverity tool for the signature with the GPG key 18:05:48 so far, there was a general discussion on PGP signatures 18:05:56 if this is the safest option 18:06:02 not on the patch set itself 18:06:48 nirik: +1 18:06:50 probably reviewing the code would speed up acceptance of the patches 18:07:05 I assume the Fedora kernel maintainers would not like to carry downstream patches for this feature? 18:07:25 Thats the general policy yeah. 18:07:36 the original patch set was from David Howells 18:07:47 I adapted it to run with the current kernel 18:09:19 what are the next steps here for fesco? 18:09:52 I'm not comfortable on a vote until the kernel patchset has been reviewed upstream and we know if it's accepted or not 18:10:38 assuming they accept it, is that all that we need? 18:10:43 I guess fsverity could still work with the current kernel, but by having a secondary key 18:11:04 just two minor things: 18:11:20 small patch to verify a PGP signature from fsverity 18:11:26 (in the kernel) 18:11:30 I'd really like to be able to enable this and protect users from something... rather than just saying 'here it is, enable it if you know how and want to figure out how to use it yourself' 18:11:44 dcavalca: you're one of the owners of the fs-verity proposal. What's you take on this new approach? 18:11:49 modification of the user space tool to sign with a GPG key 18:12:01 agreed, I'd like to see an outline of how this gets enabled in fedora 18:12:23 however, I am also ok with the enablement plan being a separate change proposal 18:12:32 sorry, I'm multitasking between three meetings atm 18:12:37 if that's the case, I'd like this proposal to note that 18:12:38 robertosassu: is there a writeup of this proposal? 18:12:50 not yet 18:12:57 I'd be happy to review it and comment from the fsverity side 18:12:57 I could send an email to the devel list 18:13:09 I'm all for joining forces if we can 18:13:15 cool 18:13:17 cool 18:13:28 I suppose we punt this again... 18:13:36 * nirik wonders if we could at least use this to validate /boot contents for folks... 18:14:08 you mean secure boot? 18:14:23 * mhroncok waits until the discussion clearly ends 18:14:30 well, no, but yes, there's overlap. 18:14:41 anyhow, I can post to the list 18:14:55 ok 18:15:00 thanks 18:15:05 #topic #2721 F36 Change: DIGLIM 18:15:06 For this proposal, I asked about impact on RPM build times, but I have not seen a response yet. 18:15:11 .fesco 2721 18:15:12 mhroncok: Issue #2721: F36 Change: DIGLIM - fesco - Pagure.io - https://pagure.io/fesco/issue/2721 18:15:27 ops, I should have missed it 18:15:30 ^ That comment was meant for fs-verity. 18:15:36 tstellar: thanks 18:15:37 ah, ok 18:15:44 I think we just talked about this 18:15:45 #undo 18:15:45 Removing item from minutes: 18:16:12 anything else for fs-verify? 18:16:16 it seems we talked about fsverity and DIGLIM all at once 18:16:31 Eighth_Doctor: not really, they are still separate proposals. 18:16:41 I'll note that mass rebuild is tomorrow, so if either/both of these wanted mass rebuild, it's gonna be f37s 18:16:48 yes, both have in common the idea to use PGP keys and signatures 18:17:14 I think we're basically at the point now of both being punted to F37 18:17:20 tstellar: we do plan to share more data on build times and other metrics 18:17:23 no mass rebuild needed for DIGLIM 18:17:23 there's no way anything is getting done now 18:17:44 #topic #2721 F36 Change: DIGLIM 18:17:46 .fesco 2721 18:17:46 hopefully soon, now that folks are back from the holidays 18:17:47 mhroncok: Issue #2721: F36 Change: DIGLIM - fesco - Pagure.io - https://pagure.io/fesco/issue/2721 18:18:20 so, we are kinda in the same situation here, right? 18:18:20 ok, no changes here about the kernel part 18:18:26 I have not read the entire mailing list discussion on this one either 18:18:29 Various people made this comment when the discussion started on fedora-devel… With kernel patches required (at least for the DIGLIM stuff), F36 was never a realistic option. 18:18:55 DIGLIM is already working on Fedora 34 18:19:01 and fsverity will require adjustments to our signer infra 18:19:34 at least as it stands today 18:20:09 robertosassu: but "Scope" lists kernel patches that are not upstream… I thought that we need those for the proposal to work. 18:20:27 maybe if you could comment on the kernel mailing list, we could have a discussion 18:20:41 and maybe the maintainers are more convinced to accept the patches 18:21:13 robertosassu: can you share a link to the lkml thread? 18:21:16 yes, the patches are not upstream, but DIGLIM works by just modifying the kernel 18:21:27 ok, one sec 18:21:34 dcavalca: see https://fedoraproject.org/wiki/Changes/DIGLIM#Scope 18:21:42 ah, right 18:21:45 so same as stated before, kernel patches have to be accepted upstream before we can discuss the fedora feature 18:21:46 thanks zbyszek 18:21:50 right? 18:21:57 yes 18:22:21 robertosassu: you might also want to talk to fedora kernel folks in #kernel:fedoraproject.org to see if kernel folks there may be interested in reviewing upstream too 18:22:31 I guess if Fedora is interested in having this feature, this could help for the acceptance 18:22:41 kernel maintainers likes to have concrete use cases 18:22:42 Yes, but with a caveat. robertosassu makes a good point that kernel maintainers might look at this more quickly if we give this (even a provisional) green light. 18:22:49 Right. 18:23:22 yes, and I think we can accept with the upstream merge proviso 18:23:24 ok, I will also talk to the Fedora kernel folks 18:23:26 I'm in favor of that 18:23:30 I will poke folks on my end as well to see if someone can help review these 18:23:36 (I'm pretty sure we've even done this before for this reason) 18:23:39 thanks 18:24:53 https://lwn.net/Articles/880263/ 18:25:01 this is an article about DIGLIM 18:25:17 also Phoronix mentioned it 18:25:41 https://www.phoronix.com/scan.php?page=news_item&px=Fedora-DIGLIM-Proposal 18:26:15 does anybody here think fesco should take some action now about this? e.g. vote about a specific proposal, etc.? 18:26:15 from a process standpoint, i think it's fine for FESCo to say "sure, so long as it lands upstream" and then evaluate at the contingency deadline 18:26:48 yup 18:26:50 I'd prefer to wait on the kernel review to be done 18:27:21 the previous version was reviewed by Greg Kroah Hartman 18:27:41 sorry, I meant whether or not it will be accepted 18:27:49 ok 18:28:11 * zbyszek would like to have more time to evaluate the two proposals 18:28:27 dcantrell: assuming this lands in mainline kernel today, waht do we do? 18:28:38 I'd prefer to accept it with a proviso it can't be implemented without upstream acceptance 18:28:54 If the patches aren't going to be accepted in the kernel, then discussing the feature for Fedora is kinda pointless? 18:28:56 mhroncok: we just vote in the next meeting 18:28:56 I mean, it is OK to say we need something to happen to decide, but we can anticipate the thing happening (or not happening) 18:28:59 like anything else 18:29:02 I don't understand the urgency 18:29:16 is there urgency? 18:29:24 Fabio Valentini: the acceptance helps motivate upstream review 18:29:26 acceptance now would help to resume the discussion 18:29:38 yes 18:29:42 what I want to avoid is the outcome where the kernel does not accept it and we have provisionally accepted it, then we all have to discuss it again etc 18:30:05 I'm fine with saying "if this is accepted into the mainline kernel, we will discuss enabling it in Fedora" 18:30:10 they don't like adding things without use-cases or an OSS user in mind 18:30:28 perhaps we shouldn't like that either. ;) 18:30:37 :) 18:31:08 the kernel discussion can certainly see the fedora proposals 18:31:11 and the fesco ticket 18:31:23 we can note that we've discussed it and are waiting on the kernel acceptance decision 18:31:29 this seems perfectly valid to me 18:31:35 cool 18:31:39 and sadly, lkml reviews tend to die on the vine without some kind of "push" 18:32:01 I think the fact that we are discussing this is enough for the kernel maintainers. I don't think it needs provisional acceptance to get in. 18:32:06 then those of us here who care about it should join that discussion 18:32:35 we are on this topic for ~15 minutes. who wants to continue? 18:32:54 I'm all set 18:33:14 dcantrell, ok, also mentioning that Fedora is interested would also help 18:33:49 #topic #2731 F36 Change: Relocate RPM database to /usr 18:33:56 .fesco 2731 18:33:57 mhroncok: Issue #2731: F36 Change: Relocate RPM database to /usr - fesco - Pagure.io - https://pagure.io/fesco/issue/2731 18:34:48 dcantrell: you tagged this with meeting 18:34:57 * nirik isn't sure how to feel about this one. I mean, it probibly doesn't hurt, but it seems like it's not that helpfull either for most cases. 18:34:57 I did. I caught up on the thread this morning 18:35:07 otherwise it would have been approved now with +3,1,-0 18:35:12 I have to say that the more I read about this, the less I like it. 18:35:14 which is not much honestly 18:35:35 Aside from my objection to putting the db in /usr, the recent thread posts also note that the proposal itself is fairly weak with regards to benefits to fedora and the entire thing is narrow focused on rpm-ostree 18:35:56 okay, to be blunt, I didn't make this proposal for rpm-ostree 18:36:03 they already override the rpmdb path and do their own thing 18:36:27 and they'll continue to ignore Fedora defaults until the end of time unless we deliberately rationalize them 18:37:00 * nirik nods. 18:37:02 the proposal notes this is for rpm-ostree, so if that wasn't the catalyst, what was 18:37:03 * zbyszek thinks the proposal is good enough in its current state. 18:37:14 This change proposal was explicitly made because I'm trying to make incremental progress to supporting a snapshot+rollback regime in regular Fedora 18:37:30 that basically reduces the benefit list to opensuse+napshots 18:37:37 people keep asking for it, and I'm trying my best to incrementally make progress to enable the feature 18:37:45 it's not for rpm-ostree, it's for traditional RPM installations and rpm-ostree installations to align 18:37:59 mhroncok: making things more similar between Fedora variants is also a benefit. 18:38:11 well, the tangential benefit is the rpmdb path will be the same across the board 18:38:11 .hi 18:38:12 dustymabe: dustymabe 'Dusty Mabe' 18:38:15 sorry I'm late 18:38:24 it's not why I want it, but it's a benefit for Fedora 18:38:24 if there's no concern about each edition and spin having a different location for rpmdb then... ok that'd be interesting to know i guess 18:38:31 *snapshots 18:38:31 * mhroncok thinks to much about taking a nap :D 18:38:47 I think rwmjones would murder us if we allowed all the spins to have different paths 18:38:50 honestly, this change dos not feel like it has a wide acceptance by the community 18:38:59 I don't see how the rpmdb in /usr is required for snapshots. But I've mentioned my thoughts on this. /usr is the wrong location for that data. upstream rpm agrees 18:39:08 but whatever, if you guys want to vote on this, do it 18:39:09 (rwmjones works on libguestfs and OS recovery tooling) 18:39:31 "/usr is the wrong location for that data." -- it definitively feels wrong 18:39:43 "upstream rpm agrees" -- that should be a strong indicator 18:39:50 I disagree, but not completely. 18:39:53 Both statements are wrong. 18:40:06 zbyszek: go ahead 18:40:06 The change proposal says upstream RPM agrees on the new location. 18:40:19 mhroncok: upstream rpm believes there should be a dedicated location for this stuff 18:40:19 `/usr/lib` is definitively wrong. That doesn't mean it doesnt' have a home somewhere in the `/usr` tree. 18:40:23 upstream rpm agreed on /usr/lib/sysimage five years ago, otherwise we wouldn't have put the proposal together at all 18:40:29 tstellar: the mailing list states otherwise 18:40:34 yep 18:40:40 we already had this discussion upstream 18:40:43 cmurf[m]: yeah, I don't think rpm upstream is opposed. 18:40:58 when SUSE wanted to put it in /usr/share/rpm, upstream and openSUSE threw pitchforks 18:40:59 dcantrell: So, which one is right? 18:41:25 we debated it upstream and came to the consensus that we should use /usr/lib/sysimage/rpm 18:41:31 I'm referring to comments from Panu indicating he did not agree with the /usr location, but otherwise doesn't want to stand in the way of this change. 18:41:38 that's different than being in agreement 18:41:50 StephenGallagher: there is no effective difference between most of directories under /usr/lib. (/usr/local is special, and some other places). But otherwise whether it's /usr/lib or /usr/libexec or anything else just doesn't make any *practical* difference. 18:42:02 Panu is an important voice, but not the whole of the RPM upstream. 18:42:13 dcantrell: that was my impression as well. 18:43:30 I don't really want to rehash the mailing list discussion. I got plenty of hate mail from this story making LWN. But, I maintain that /usr is fundamentally the wrong location for this type of data. I really want people to hear that. This is not opposition to new stuff, it's about organizing things on the system. 18:44:21 dcantrell: look at this way: if you do snapshots, then you want this to be together with /usr. If you don't do snapshots, it makes no difference. 18:44:42 yeah i don't agree that it's the wrong location, it's metadata about that location 18:44:48 Didn't somebody mention that the FHS actually has a location for this stuff (/usr/var), it's just that nobody uses it? That would seem to be a good compromise ... 18:44:56 cmurf[m]: the rpmdb describes the entire system 18:45:09 decathorpe: FHS is dead. Let's not take it too seriously. 18:45:10 dcantrell: I tend to agree, but what about the argument that it's capturing the state of /usr and only updated when /usr is updated? 18:45:15 I don't know if rpm-ostree blocks `/usr/var` like it does `/usr/etc` 18:45:20 arguably if you want a package manager touching arbitrary paths, it either needs a database that knows about all snapshots everywhere, or it needs to put rpmdb in each arbitrary path to know the state of that path 18:45:26 zbyszek: snapshots in a variety of forms can already happen today with that data living in /var. rsync can do it 18:45:47 there is no one single system the instant you make one snapshot 18:46:03 dcantrell: sure, but this type of snapshot falls into the second category of "don't care". 18:46:06 tstellar: if rpm supported multiple databases, the conversation would be different. but since we have a single db right now, we have to live with that. it doesn't just capture what's in /usr 18:46:10 zbyszek: I don't care whether FHS is dead or not, but I like that particular idea. 18:46:49 * mhroncok seems to have some connection issues 18:46:57 frankly, I'm fine with `/usr/var` too 18:47:20 the only issue with it is how much kvetching we're going to get from libsolv, rpm-ostree, and everyone else about adding yet another path 18:47:23 I find /usr/var less objectionable 18:47:37 i'm fine with any location other than /var, frankly 18:47:40 and again, I don't know if rpm-ostree blocks `/usr/var` like it does `/usr/etc` 18:48:41 right now, libsolv upstream is trying to drop `/usr/share/rpm` (which is what rpm-ostree is migrating _from_), openSUSE uses `/usr/lib/sysimage/rpm` (which rpm-ostree is migrating _to_), and we'd do `/usr/var/lib/rpm`? 18:49:17 decathorpe: I think that there are many good ideas in FHS, and I think we should always have it in mind when talking about fs paths. But at the same time it's a historical document (last minor revision 7 years ago), that is not taking into account how things are changing. 18:49:19 /not-var/rpm ? 18:49:23 * mhroncok hides 18:49:27 Whatever we decide on, it's better be good, because I don't see us changing the path again anytime soon ... 18:49:37 but if it makes it go through, fine, I'll deal with all the crap of getting everyone to deal with yet another rpmdb path 18:50:03 * Eighth_Doctor envisions rwmjones being very upset at him over this... 18:50:04 I don't think we should do something that others aren't. 18:50:05 decathorpe: that's kind of why I think this is a larger discussion than just moving something out of /var 18:50:25 Fedora CoreOS will likely go along with it since it's not that hard for them, but for (open)SUSE.... sigh i think it's likely they stick with what they have 18:50:44 Frankly, I think part of the problem is that RPM really shouldn't handle arbitrary paths, but that can of worms is already open... 18:50:52 yeah, I'm pretty sure Richard Brown and Richard Jones are both going to be pissed about it 18:51:00 larger discussion happened on rpm-maint in 2017 and /usr/lib/sysimage was the outcome of that discussion 18:51:27 From a practical standpoint, I suppose I'm fine with that location. 18:51:32 I agree that if /usr/lib/sysimage was the outcome of that discussion, we should probably not come up with yet another path 18:51:37 Maybe we also symlink /usr/var/sysimage there :) 18:51:49 the reality is /usr/lib/sysimage is not perfect but it's less bad than /var/lib and basically other folks beat us to the punch due to need 18:51:53 So does upstream already default to /usr/lib/sysimage/rpm ? 18:52:13 cmurf: Well, if /usr/lib/sysimage actually were the new default location in RPM upstream, the discussion would be different. But it isn't. 18:52:22 upstream defaults to /var/lib/rpm and has no plan to change it 18:52:56 where do we stand with votes? 18:53:12 I think we probably need a formal proposal 18:53:18 I'll make one 18:53:18 Eighth_Doctor and zbyszek are +1 18:53:28 I am kinda almost there 18:53:35 StephenGallagher: go ahead 18:53:41 Is there a difference between voting 0 and -1 ? 18:53:47 Proposal: FESCo accepts that `/usr/lib/sysimage` is the de-facto standard between distributions and approves this Change 18:53:51 tstellar: no 18:53:53 tstellar: not for the result 18:54:05 StephenGallagher: +1 18:54:06 StephenGallagher: +1 18:54:17 Stephen Gallagher: I disagree with that statement. The de-facto standard is /var/lib/rpm ... 18:54:17 Stephen Gallagher: +1 18:54:17 tstellar: Not in this case; the only practical difference is in the ticket, where a -1 mandates a meeting and a 0 does not. 18:54:21 StephenGallagher: -1 18:54:44 StephenGallagher: -1 18:54:59 Fabio Valentini: No, that's the RPM upstream default. If other distros have already settled on `/usr/lib/sysimage`, then it's the "de-facto" standard. 18:55:16 StephenGallagher: I guess weak +1. It doesn't harm things, it's just a bunch of work for not much gain. ;) 18:55:19 StephenGallagher: from all the RPm distros out there... 18:55:20 or distro-facto standard 18:55:23 only 2 use it? 18:55:25 OpenSUSE and ... which others? ... 18:55:35 and well, also, -1 to the proposal. 18:55:51 not approved 18:56:00 I count +5, -4... 18:56:06 let em recheck 18:56:08 *me 18:56:14 I was implicit in the proposal 18:56:17 +1 for clarity 18:56:21 oh, StephenGallagher's +1 :D 18:56:24 I forgot 18:56:45 I see +5,0,-3 18:56:47 Fabio Valentini: it probably doesn't matter, but CentOS Hyperscale is changing to this path too 18:56:54 openSUSE, SUSE, CoreOS and rpm-ostree based systems... 18:57:04 mohan is missing 18:57:11 all rpm-ostree systems do this too (Photon OS, CBL-Mariner, etc.) 18:57:22 Oh, you're right. I miscounted. 18:57:32 #agreed FESCo accepts that `/usr/lib/sysimage` is the de-facto standard between distributions and approves this Change (+5,0,-3) 18:57:39 But we have +5, which means it passes. Three people reserve the right to complain later ;-) 18:57:46 :) 18:58:22 does anybody have anything else to note for this topic? 18:58:33 I do, actually. 18:58:39 go 18:58:47 `/usr/lib/sysimage` is already reserved in `filesystem` in EL8+ and Fedora ;) 18:59:08 What would it take to resurrect the FHS process with Fedora and OpenSUSE driving it together? 18:59:15 To avoid such decisions in the future. 18:59:34 StephenGallagher: it would take time, energy, money and possibly more 18:59:46 Stephen Gallagher: I think getting the right people into a room to restart it 19:00:00 we actually had a discussion about this in the CentOS Hyperscale hangout last month 19:00:14 and if we can get the right people, we could restart it 19:00:14 In a practical sense, wouldn't it be enough to start a draft and invite comment? 19:00:38 incidentally, our monthly hangout is tomorrow :) 19:00:51 StephenGallagher: that's a way to do it, yes 19:01:03 it would still take time, energy, money and possibly more :D 19:01:08 StephenGallagher: for me, the new FHS is filesystem-hierarchy(7) maintained as part of systemd upstream. 19:01:15 mhroncok: Netizens are nothing if not willing to "correct" bad proposals :) 19:01:36 I think the most effective approach would be to just add more stuff there, as appropriate. 19:02:01 systemd-fhsd 19:02:01 It describes modern linux systems as they are. 19:02:25 OK, I'll ruminate on this and come back another day 19:02:27 * Eighth_Doctor cringes 19:02:43 Sorry for prolonging the discussion 19:02:47 StephenGallagher++ 19:02:47 mhroncok: Karma for sgallagh changed to 3 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:02:47 no worries 19:02:50 zbyszek++ 19:02:55 I have file-hierarchy(7) but not filesystem-hierarchy(7) on my system 19:03:06 dcantrell: yep, it's "file-", sorry. 19:03:15 #info https://www.freedesktop.org/software/systemd/man/file-hierarchy.html 19:03:17 moving on to the next topic? 19:03:21 i'll volunteer (to get a bloody nose, which should be added to the sweat, equity and tears list for any worthwhile effort) 19:03:35 I've got `hier(7)` too... 19:03:56 sure 19:04:18 That's the page you go to if you need to look up the location of yp directory ;) 19:04:53 #topic Next week's chair 19:05:18 I almost forgot to run this meeting but I guess I can try better next week 19:05:33 but if somebody else wants to do it... 19:05:51 I haven't done it in a while 19:06:16 StephenGallagher: is that a general statement or you volunteering to do it? :) 19:06:41 It was me hedging to see if anyone else jumped in more conclusively ;-) 19:06:42 I'll take it 19:06:45 #action StephenGallagher will chair next meeting 19:06:49 thank you 19:06:54 #topic Open Floor 19:06:58 np 19:07:00 the floor is yours 19:07:44 if you have something, speak up 19:08:18 (there seem to be a FHS discussion on #fedora-devel) 19:08:27 I'll end the meeting 19:08:32 thanks everybody for coming 19:08:32 https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/167 — this is for F36 change. 19:08:45 postponing that 19:08:48 mhroncok++ 19:08:48 dcantrell: Karma for churchyard changed to 6 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:08:56 Eighth_Doctor or mhroncok: can you merge it? 19:09:13 zbyszek: I can, but I have not reviewed the code yet 19:09:37 zbyszek: it still fails the CI 19:09:51 I brought it up here because I'm not sure what the policy is… It's an accepted change, but it hasn't seen much response from the maintainers. 19:09:52 Hardened: hello-cpp: Overall: FAIL (due to MAYB results). 19:11:04 mhroncok: see https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/167#comment-94208 19:11:16 zbyszek: I'll look and merge accordingly 19:11:22 once it passes CI 19:11:44 hmm 19:11:45 Eighth_Doctor: see the link above, the CI failure is unrelated. 19:11:46 seems like it confuses annocheck? 19:11:46 zbyszek: let's continue this discussion there? 19:11:46 am I still online? 19:11:51 that test I could waive 19:12:10 Yeah, let's continue the discussion in the ticket. 19:12:13 mhroncok: yes, I can read your messages. 19:12:23 zbyszek: I'll merge it after doing a final review 19:12:31 Eighth_Doctor++ 19:12:44 decathorpe: thanks 19:12:52 Eighth_Doctor thanks! 19:13:18 I'll end the meeting, second attempt 19:13:25 ..... 19:13:32 .... 19:13:33 Let me… 19:13:36 just joking 19:13:43 zbyszek-- 19:13:48 ... 19:13:48 np 19:13:52 .. 19:13:58 * The dislike button has been disabled * 19:14:01 . 19:14:03 #endmeeting