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