15:00:02 <zbyszek> #startmeeting FESCO (2021-01-06)
15:00:02 <zodbot> Meeting started Wed Jan  6 15:00:02 2021 UTC.
15:00:02 <zodbot> This meeting is logged and archived in a public location.
15:00:02 <zodbot> The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:02 <zodbot> The meeting name has been set to 'fesco_(2021-01-06)'
15:00:02 <zbyszek> #meetingname fesco
15:00:02 <zbyszek> #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
15:00:02 <zodbot> The meeting name has been set to 'fesco'
15:00:02 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku cverna dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
15:00:05 <zbyszek> #topic init process
15:00:09 <zbyszek> Welcome to the New Year!
15:00:14 <zbyszek> .hello2
15:00:15 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:00:23 <nirik> morning
15:00:32 <bcotton> .hello2
15:00:33 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:00:44 <decathorpe> .hello2
15:00:45 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
15:01:05 <zbyszek> Hi bcotton, thank you for marking some tickets as "accepted" during the break
15:01:34 <zbyszek> sgallagh said he might be a few minutes late
15:01:52 <King_InuYasha> .hello ngompa
15:01:53 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com>
15:02:00 <King_InuYasha> hey y'all
15:02:03 <sgallagh> .hello2
15:02:03 <bcotton> community projects mean there's never really time off ;-)
15:02:03 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:02:07 <sgallagh> (Made it)
15:03:28 <zbyszek> We have quorum, but let's wait a bit. mhronock at least should join.
15:03:31 <zbyszek> Oh.
15:03:34 <mhroncok> here I am
15:03:37 <mhroncok> sorry, got distracted
15:04:10 <ignatenkobrain> .hello2
15:04:11 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Raits' <igor.raits@gmail.com>
15:04:21 <sgallagh> Welcome back, ignatenkobrain !
15:04:26 <King_InuYasha> yay!
15:04:34 <King_InuYasha> almost everyone is here!
15:04:36 <zbyszek> cverna, piiiiing
15:04:37 <decathorpe> so many people
15:05:02 <dcantrell> .hello2
15:05:03 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
15:05:15 <zbyszek> OK, let's go then.
15:05:16 <zbyszek> #topic #2473 updates policy is out of date
15:05:16 <zbyszek> .fesco 2473
15:05:17 <zodbot> zbyszek: Issue #2473: updates policy is out of date - fesco - Pagure.io - https://pagure.io/fesco/issue/2473
15:05:50 * nirik didn't have time to go over in detail the addtional pr... I think it mostly looked fine tho
15:06:28 <zbyszek> * there is a plot
15:06:47 <decathorpe> same here. I can look at it later and give +1 on the ticket
15:06:58 <nirik> also I see there's changes 4 hours ago. I havent looked at any of those since I was asleep.
15:07:04 <dcantrell> I also have not read the latest changes
15:07:48 <zbyszek> I think that once we've resolved that ticket, we can start working on improvements and simplifications to the policy.
15:07:52 <dcantrell> but can read later and vote in the ticket
15:08:10 <zbyszek> Just trying to undertand what the rules are is (at least for me) very hard.
15:08:36 <mhroncok> also, some of the infor from bodhi maintainer seems confusing
15:08:42 <nirik> yeah, theres lots of them and they acreeted over time
15:09:46 <zbyszek> #info We'll vote in the ticket.
15:09:52 <King_InuYasha> in principle, I'm +1 to the changes, but I've come away more confused about this stuff now than I was before
15:10:24 <zbyszek> King_InuYasha: if the proposed text is not clear, suggestions are welcome. Even to the level of "previous description was better".
15:10:46 <King_InuYasha> I'll take a look later in the day and see if I can give some useful feedback
15:10:53 <King_InuYasha> it seems to have churned a bit in the past few days
15:10:59 <zbyszek> OK.
15:11:02 <zbyszek> Moving on.
15:11:03 <zbyszek> #topic #2535 F34 Change: Enable systemd-oomd by default for all variants
15:11:07 <zbyszek> .fesco 2535
15:11:08 <zodbot> zbyszek: Issue #2535: F34 Change: Enable systemd-oomd by default for all variants - fesco - Pagure.io - https://pagure.io/fesco/issue/2535
15:11:48 <sgallagh> zbyszek: Why did you add this to the meeting agends?
15:11:50 <ignatenkobrain> any specific reasons for this one to be on the meeting?
15:12:00 <nirik> I'm +1 to the change (sorry for not yet voting in ticket)
15:12:10 <sgallagh> Just to make sure that it doesn't trigger the auto-acceptance?
15:12:31 <decathorpe> I'm concerned that enabling it for all variants is not yet a good idea
15:13:01 <mhroncok> "Should other desktop-oriented Spins be excluded from this Change for now?"
15:13:07 <mhroncok> that is a valid concern
15:13:15 <zbyszek> I added it, because the scope is divisive to some extent: for which editions should this be enabled? Also some poeople suggested postponing to F35.
15:13:24 <mhroncok> I was waiting to get some answer before voting
15:13:25 <nirik> I think they can exclude themseleves if they want? but we should make it clear that it's fine if they do.
15:13:42 <decathorpe> I think at least Spins with DEs that don't support separate systemd scopes for applications should be able to opt out, if they wish
15:13:53 <dcavalca> nirik: that was indeed our plan and anitazha had updated the proposal to make it clearer
15:14:07 <zbyszek> Hi dcavalca!
15:14:17 <dcavalca> hello!
15:14:40 <King_InuYasha> zbyszek, dcavalca: can we do something similar to the zram generator where if configuration is missing, oomd does nothing?
15:14:45 <nirik> and thats just excluding systemd-oomd from install? or ?
15:14:52 <decathorpe> dcavalca: that's great, I didn't see those changes. +1
15:15:17 <King_InuYasha> or do we need to go to the level of making sure oomd itself is subpackaged out and only pulled in by Workstation, Server, Cloud, and KDE?
15:15:35 <zbyszek> #info changes since the initial submission: https://fedoraproject.org/w/index.php?title=Changes%2FEnableSystemdOomd&type=revision&diff=599660&oldid=599481
15:15:40 <mhroncok> https://fedoraproject.org/w/index.php?title=Changes%2FEnableSystemdOomd&type=revision&diff=599660&oldid=599481
15:15:41 <dcavalca> nirik: easiest is probably to add the DE unit to the exclude list in that case
15:15:46 <mhroncok> too late
15:16:14 <dcavalca> which would leave oomd enabled, but refrain from killing the DE and any of its children
15:16:35 <King_InuYasha> ah, that'd work, yes
15:16:48 <King_InuYasha> that effectively makes it do nothing and allows DEs to catch up eventually
15:17:22 <dcavalca> yeah, that was the idea
15:17:25 <nirik> hum, ok.
15:17:27 <zbyszek> dcavalca: "add the DE unit to the exclude list" — I don't think that's useful, because that'd mean that the userspace oomkiller is not effective.
15:17:39 <nirik> bug on systemd to get something added?
15:17:47 <zbyszek> Instead, we prolly want to keep earlyoom enabled there instead.
15:18:20 <King_InuYasha> zbyszek: earlyoom is not used there
15:18:23 <anitazha> hello! for configuration we do like the idea zbyszek proposed about keeping the configuration in a separate package to make it easier to opt in/out. if there's nothing setting the ManagedOOM*= properties systemd-oomd doesn't do anything even if it's running
15:18:24 <decathorpe> well, earlyoom is only enabled for Workstation and KDE, isn't it?
15:18:28 <King_InuYasha> yeah,
15:18:44 <King_InuYasha> this just lets us get rid of earlyoom in Workstation and KDE
15:18:55 <zbyszek> Ah, OK.
15:18:58 <dcavalca> I suspect having some editions use earlyoom and some oomd could also be confusing for users
15:19:49 <zbyszek> So... do we want to split out oomd to a subpackage?
15:20:18 <decathorpe> zbyszek: I think so, yes. it would allow spins to exclude that package in comps, right?
15:20:21 <dcantrell> if oomd and earlyoom are needed, a subpackage makes sense to me.  makes it a little more clear to users what you have and what pieces are available for editions
15:20:38 <King_InuYasha> decathorpe: in kickstarts, but yes
15:20:52 <decathorpe> King_InuYasha: tometo tomato
15:21:34 <nirik> A subpackage would be easier than a list, but... then users may install it thinking it would work and get surprised. But I don't suppose thats a big use case
15:21:44 <zbyszek> anitazha: so, systemd-oomd.rpm and systemd-oomd-defaults.rpm? Or just one?
15:21:53 <sgallagh> I'm going to vote 0 on this one, because I definitely haven't been following closely enough to have a sensible opinion.
15:22:24 <mhroncok> I abstain as well
15:22:28 <mhroncok> same reason
15:22:31 <anitazha> i think just systemd-oomd-defaults.rpm is enough unless we really want to split out systemd-oomd the binary
15:23:09 <dcavalca> agreed, my impression is that we shouldn't need to split out the binary itself to do what we want here
15:23:38 <decathorpe> maybe the Minimization people would want to have it split out?
15:24:03 <zbyszek> OK, we'll hash out those details later, we don't need to do this here.
15:24:23 <zbyszek> We're (+4,0,0) in the ticket, and (0,2,0) here.
15:24:25 <dcantrell> I do like that adding *more* packages sometimes helps minimization.  :)
15:24:32 <zbyszek> Does anyone else want to vote?
15:25:23 <decathorpe> I am +1 now
15:25:46 <zbyszek> nirik?
15:25:59 <sgallagh> zbyszek: nirik voted +1 in the ticket during the meeting
15:26:05 <nirik> I'm +1. I added to the ticket a bit ago
15:26:10 <zbyszek> Thanks.
15:26:39 <zbyszek> #agree APPROVED (+5, 2, 0)
15:26:54 * zbyszek needed to check the syntax. It's been a while.
15:27:03 <King_InuYasha> agreed, I think?
15:27:07 <zbyszek> #undo
15:27:07 <zodbot> Removing item from minutes: AGREED by zbyszek at 15:26:39 : APPROVED (+5, 2, 0)
15:27:11 <mhroncok> both
15:27:12 <zbyszek> #agree APPROVED (+6, 2, 0)
15:27:28 <sgallagh> One is an alias for the other, IIRC
15:27:29 <zbyszek> #topic #2532 F34 Change: Enable spec file preprocessing
15:27:29 <zbyszek> .fesco 2532
15:27:30 <zodbot> zbyszek: Issue #2532: F34 Change: Enable spec file preprocessing - fesco - Pagure.io - https://pagure.io/fesco/issue/2532
15:27:49 <King_InuYasha> :(
15:27:58 <dcantrell> I am still finding and catching up on all the discussion on this one, but from what I've read so far I am -1
15:28:04 <zbyszek> I didn't read through the full discussion yet...
15:28:18 <sgallagh> I wrote a long reply this morning to the ticket that I lost in a network hiccup, but the tl;dr version was -1 from me for F34, willing to reconsider in F35.
15:28:46 <King_InuYasha> the underlying disagreement here from me is that the use-cases for spec file preprocessing assume that we don't care about canonicity of spec files in src.fedoraproject.org
15:29:22 <King_InuYasha> and I think that we *do* want our spec files to the source of truth for versioning, behaviors, and sources
15:29:25 <dcantrell> I'll agree with that
15:29:26 <King_InuYasha> rather than something else
15:30:06 <dcantrell> to mhroncok's point, I feel this entire effort possibly has some merit for other automated build systems (e.g., copr, or somewhere else)
15:30:07 <King_InuYasha> it was unfortunate that dcantrell's rpminspect was used as an example, but it also demonstrates my point, because that spec file is for upstream builds, not explicitly Fedora ones
15:30:17 <nirik> I wonder if we couldn't get upstream more interested in solving this in a better way
15:30:24 <sgallagh> I'm open to the idea that src.fp.o is authoritative, rather than specifically the RPM spec file.
15:30:29 <zbyszek> Though... it's much less true than it used to be. %generate_buildrequires, fancy %py_ macros...
15:31:03 <dcantrell> King_InuYasha: it's true, I don't build from the upstream repo.  that's all "source code" in my mind, so much like a pkg-config script being a template in an upstream project
15:31:17 <King_InuYasha> it's the same way I handle upstream spec files too
15:31:27 <King_InuYasha> sgallagh: the problem is that people use src.fp.o in non-Fedora contexts because the only _real_ thing needed on top is rpm macros, which everyone has
15:31:42 <King_InuYasha> e.g. Mageia and openSUSE regularly pull specs from us and use in their distros
15:31:45 <King_InuYasha> and vice versa
15:31:49 <sgallagh> King_InuYasha: Yeah, I get that.
15:32:15 <zbyszek> King_InuYasha: so if we push something to rpm upstream, everyone is better off?
15:32:16 <King_InuYasha> that said, this does have value with things like copr
15:32:19 <King_InuYasha> zbyszek: yes
15:32:26 <sgallagh> What I meant is just that I don't have a problem *inherently* with preprocessing so long as all of the decision logic is in the repo.
15:32:35 <King_InuYasha> sgallagh: ah, yes, that I can get behind
15:33:05 <King_InuYasha> I believe pingou is working on a proposal for F35 for the rpmautospec stuff
15:33:32 <King_InuYasha> which lines up more with the way we handle spec file automation
15:33:40 <dcantrell> this proposal has it tied to the host environment, so yeah putting the decision logic in the repo makes more sense
15:34:22 <King_InuYasha> plus, there's just something that bothers me about having three layers of templating
15:34:35 <dcantrell> *yes*
15:34:44 <King_InuYasha> jinja, m4/macros, and shell magic to construct a spec file
15:34:50 <sgallagh> King_InuYasha: Never, under any circumstances, should you read the nsswitch code of glibc :)
15:34:52 <King_InuYasha> at that point, we should be talking about a new spec file format upstream
15:34:53 <dcantrell> it's like an onion
15:35:00 <King_InuYasha> sgallagh: ugh
15:35:35 <sgallagh> Weren't we talking about Conary a few years back?
15:35:36 * sgallagh ducks
15:35:40 * King_InuYasha snorts
15:35:52 <zbyszek> So... can we continue the discussion (fedora-devel and the ticket) for now?
15:35:59 <dcantrell> so for proposals like this we should consider asking a question about how this makes packaging better or easier, with an example.  like, would this make the texlive package better?
15:36:08 <dcantrell> yeah, that's fine, to the mailing list!
15:36:10 * King_InuYasha shudders
15:36:13 * dcantrell raises sword
15:36:39 <zbyszek> dcantrell: you mean you want to quickly fuzz the implementation with an impossible use case? That's good CI!
15:36:49 <dcantrell> :)
15:37:15 <zbyszek> #info We'll continue the discussion on fedora-devel and in the ticket.
15:37:20 <zbyszek> #topic Next week's chair
15:37:33 <zbyszek> Volunteers?
15:38:01 <sgallagh> I may have a conflict for the first 30 minutes next week.
15:38:59 <zbyszek> OK, I'll do it again.
15:39:06 <zbyszek> #action zbyszek will chair the next meeting.
15:39:08 * mhroncok has a very unknown schedule for Q1 (moving to a new home)
15:39:15 <zbyszek> #topic Open Floor
15:39:18 <decathorpe> zbyszek: thanks!
15:39:37 <dcantrell> zbyszek: thanks, I have two conflicts next wed that I'm trying to move, but that's unknown for me right now
15:39:42 <bcotton> zbyszek: i have a thing
15:39:55 <dcantrell> also, Happy New Year, everyone
15:39:56 <King_InuYasha> I'm on-call next week :/
15:40:05 <sgallagh> zbyszek: If you want, I can do the ticket housecleaning on Tuesday in preparation.
15:40:38 <zbyszek> sgallagh: thanks, but I think it's not necessary. I do c&p and have a nice emacs macro defined for formatting.
15:40:57 <sgallagh> zbyszek: Sure, just figured I'd offer
15:41:06 <zbyszek> sgallagh: it is appreciated.
15:41:12 <zbyszek> bcotton?
15:41:19 <dcantrell> zbyszek: share the emacs macro?
15:41:55 <zbyszek> dcantrell: it's not saved, just f3-reformat the first one-f4, f4, f4, f4...
15:42:03 <dcantrell> oh, ha, ok
15:42:11 <dcantrell> thought you had a fesco-specific macro
15:42:13 <bcotton> so unless you all say "OMG NO DO NOT DO THIS", I'm going to start being a little more picky with system-wide change proposals that don't have anything for docs at submission time
15:42:34 <mhroncok> bcotton: as an example?
15:42:53 * sgallagh suspects the Node.js one...
15:42:54 <bcotton> this was requested by our glorious FPL in response to https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 and similar where we've had a lot of user questions/confusion by changes in behavior
15:43:44 <decathorpe> oh, the firefox addon problem
15:43:49 <mhroncok> yes, be more picky please
15:43:55 <mhroncok> especially with user facing changes
15:43:56 <bcotton> it won't be a "you must have fully-formed docs before you submit", but i will ask change owners to at least broadly outline their plans. then around the change complete (100%) milestone, I'll review the plans and nudge change owners who haven't implemented any docs
15:44:09 <zbyszek> bcotton: sounds good
15:44:14 <decathorpe> bcotton: sounds good
15:44:17 <mhroncok> +1 to nudging
15:44:21 * mhroncok likes nudging
15:44:22 <bcotton> it won't result in change deferal or anything, just be being a professional pest
15:44:38 * sgallagh prefers bludgeoning, but nudging is acceptable too
15:44:55 * sgallagh polishes up his clue-by-four
15:45:01 <nirik> nudging good.
15:45:05 <bcotton> i'm also going to clarify the proposal guidance for things that require packaging policy changes to link to the fpc ticket or pull request
15:45:42 <bcotton> in an ideal world, code isn't 100% complete unless docs are complete too, but i think if we tried to enforce that we'd just see people skipping the changes process, which is coutnerproductive
15:45:45 <dcantrell> all sounds good
15:45:48 <bcotton> anyway, that's enough of me talking
15:46:06 <zbyszek> https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents is a bit like this too. Just not enough docs.
15:46:28 <sgallagh> Or value...
15:46:43 <sgallagh> Sorry, that's an overstatement
15:46:49 <bcotton> 🔥🔥🔥
15:46:59 <sgallagh> I suppose I should say that there's not enough explanation of the value
15:47:00 <decathorpe> heh
15:47:23 <mhroncok> sgallagh++
15:47:23 <zodbot> mhroncok: Karma for sgallagh changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:47:27 <King_InuYasha> :/
15:47:51 <King_InuYasha> bcotton: I like the idea of requiring FPC tickets/PRs for packaging policy changes
15:48:33 <bcotton> King_InuYasha: matthew's idea was that folks should at least open a placeholder issue prior to submitting the proposal, sort of like the releng check
15:48:40 <King_InuYasha> makes sense
15:48:57 <zbyszek> I think there's broad agreement.
15:49:02 <mhroncok> ack
15:49:05 <zbyszek> Any other topics?
15:49:32 <zbyszek> I'll close in a minute if no.
15:49:52 <mhroncok> not for me
15:50:07 <zbyszek> Thanks all. See you next week.
15:50:07 <zbyszek> #endmeeting