<@salimma:fedora.im>
18:01:23
!startmeeting FESCO (2026-01-20)
<@meetbot:fedora.im>
18:01:23
Meeting started at 2026-01-20 18:01:23 UTC
<@meetbot:fedora.im>
18:01:24
The Meeting name is 'FESCO (2026-01-20)'
<@salimma:fedora.im>
18:01:29
!meetingname fesco
<@meetbot:fedora.im>
18:01:31
The Meeting Name is now fesco
<@salimma:fedora.im>
18:01:34
!group members fesco
<@zodbot:fedora.im>
18:01:36
Members of fesco: Dave Cantrell, Fabio Valentini, Máirín Duffy, Jef Spaleta, Kevin Fenzi, ngompa (@conan_kudo:matrix.org, @ngompa:fedora.im, @pharaoh_atem:opensuse.org, @ngompa:kde.org, @ngompa:almalinux.im), salimma (@michel-slm:matrix.org, @salimma:fedora.im), Stephen Gallagher, Timothée Ravier, Zbigniew Jędrzejewski-Szmek
<@nirik:matrix.scrye.com>
18:01:39
morning
<@salimma:fedora.im>
18:01:42
!topic Init Process
<@salimma:fedora.im>
18:01:46
!hi\
<@salimma:fedora.im>
18:01:48
!hi
<@zodbot:fedora.im>
18:01:49
Michel Lind (salimma) - he / him / his
<@salimma:fedora.im>
18:01:50
morning Nirik
<@siosm:matrix.org>
18:02:00
!hi
<@decathorpe:fedora.im>
18:02:00
!hi
<@zodbot:fedora.im>
18:02:01
Fabio Valentini (decathorpe) - he / him / his
<@zodbot:fedora.im>
18:02:02
Timothée Ravier (siosm) - he / him / his
<@mohanboddu:fedora.im>
18:02:07
!hi
<@zodbot:fedora.im>
18:02:08
Mohan Boddu (mohanboddu)
<@salimma:fedora.im>
18:02:19
up to 4 fesco members already, we are close to quorum
<@mheon:matrix.org>
18:02:24
!hi
<@zodbot:fedora.im>
18:02:26
No Fedora Accounts users have the @mheon:matrix.org Matrix Account defined
<@conan_kudo:matrix.org>
18:02:34
!hi
<@zodbot:fedora.im>
18:02:36
Neal Gompa (ngompa) - he / him / his
<@dcantrell:fedora.im>
18:02:45
!hi
<@zodbot:fedora.im>
18:02:46
Dave Cantrell (dcantrell) - he / him / his
<@duffy:fedora.im>
18:02:48
!hi
<@zodbot:fedora.im>
18:02:50
Máirín Duffy (duffy) - she / her / hers
<@conan_kudo:matrix.org>
18:02:55
Matt Heon: you should add your MXID to your FAS account to get it recognized
<@sgallagh:fedora.im>
18:03:00
!hi
<@zodbot:fedora.im>
18:03:02
Stephen Gallagher (sgallagh) - he / him / his
<@luap99:holzinger.dev>
18:03:04
!hi
<@zodbot:fedora.im>
18:03:07
Paul Holzinger (luap99)
<@mjw:fedora.im>
18:03:07
!hi
<@salimma:fedora.im>
18:03:32
I count 8 ... are we missing someone?
<@zodbot:fedora.im>
18:03:38
Mark Wielaard (mjw) - he / him / his
<@salimma:fedora.im>
18:03:44
(we can wait a bit longer)
<@salimma:fedora.im>
18:03:57
oh zbyszek
<@amerey:fedora.im>
18:04:42
!hi
<@zodbot:fedora.im>
18:04:44
Aaron Merey (amerey)
<@salimma:fedora.im>
18:05:09
I called the meeting at 1 past, so let's move to tickets at 6 past (in 1 minute)
<@zbyszek:fedora.im>
18:06:20
I'm here.
<@salimma:fedora.im>
18:06:39
sweet
<@zbyszek:fedora.im>
18:06:39
Sorry, computer trouble.
<@zbyszek:fedora.im>
18:06:46
!hi
<@zodbot:fedora.im>
18:06:47
Zbigniew Jędrzejewski-Szmek (zbyszek)
<@salimma:fedora.im>
18:07:07
!topic #3520 F44 Change Proposal: Restrict ptrace for unprivileged users to child processes to match kernel default
<@salimma:fedora.im>
18:07:11
!fesco 3520
<@zodbot:fedora.im>
18:07:13
● **Assignee:** py0xc3
<@zodbot:fedora.im>
18:07:13
**fesco #3520** (https://pagure.io/fesco/issue/3520):**F44 Change Proposal: Restrict ptrace for unprivileged users to child processes to match kernel default [SystemWide]**
<@zodbot:fedora.im>
18:07:13
● **Last Updated:** 4 hours ago
<@zodbot:fedora.im>
18:07:13
● **Opened:** a month ago by alking
<@zodbot:fedora.im>
18:07:13
<@conan_kudo:matrix.org>
18:07:44
ping Mark Wielaard
<@mjw:fedora.im>
18:07:51
pong
<@salimma:fedora.im>
18:09:23
do we have Chris (py0xc3)here?
<@py0xc3:fedora.im>
18:09:29
Yes.
<@py0xc3:fedora.im>
18:09:33
!hi
<@zodbot:fedora.im>
18:09:34
Christopher Klooz (py0xc3) - he / him / his
<@py0xc3:fedora.im>
18:10:46
I try to be more passive and only answer questions, and leave things to FESCo, as I think most things have been discussed and documented quite often at this time. Not increasing repetition :)
<@duffy:fedora.im>
18:11:09
this ticket seems really fraught with governance disagreement and technical disagreement
<@decathorpe:fedora.im>
18:11:45
on the other hand, I do think the clarity of the proposal suffers a bit from wanting to incorporate too much feedback 😅
<@duffy:fedora.im>
18:12:44
do we have a general principle of favoring development needs over user needs?
<@mjw:fedora.im>
18:13:11
yes, I tried to help out clarify things, but that just got reverted and "summarized" in a way I felt didn't match reality, so I gave up.
<@salimma:fedora.im>
18:13:14
not sure if this is a general principle but we did do frame pointers which favor developers
<@nirik:matrix.scrye.com>
18:13:21
no, I don't think so
<@decathorpe:fedora.im>
18:14:32
speaking for myself: I think wanting to align on a "more secure" default (with other popular distributions) is worthwhile, so I am +1 to the "desirable end state". the thing that is less clear ... is how to get there.
<@py0xc3:fedora.im>
18:14:44
I don't agree to this "reality" but let's focus on the final proposal.
<@sgallagh:fedora.im>
18:15:06
Michel Lind UTC: That didn't really *penalize* users, though. (The minor performance impact didn't really seem to get noticed by anyone)
<@siosm:matrix.org>
18:15:16
I'm +1 as well to the direction but the route is confusig
<@siosm:matrix.org>
18:15:21
I'm +1 as well to the direction but the route is confusing
<@salimma:fedora.im>
18:15:23
true
<@py0xc3:fedora.im>
18:16:02
The proposal is to remove the package. That does the job. The file is an addition, a secondary thing, that can go along with it or not.
<@mjw:fedora.im>
18:16:36
We have a policy right now that is maintainer by various package maintainers that would break when this proposal would be "approved"
<@conan_kudo:matrix.org>
18:16:54
we do?
<@py0xc3:fedora.im>
18:16:55
So getting the kernel default is achieved by removing the package.
<@duffy:fedora.im>
18:17:01
that other popular distros do what's being proposed, and we want our users to be more secure... that seems like the user vote and users might unknowingly be at risk for the sake of developer convenience.
<@duffy:fedora.im>
18:17:10
but how much is the risk
<@duffy:fedora.im>
18:17:18
is there a risk assessment, what's the worst case scenario
<@decathorpe:fedora.im>
18:17:27
can you rephrase that? I'm not sure I understand what you're trying to say.
<@mjw:fedora.im>
18:17:39
We do things different from other distros
<@fche:fedora.im>
18:18:01
Fabio Valentini: methinks what he means is that this change would cause regressions in several tools, their maintainers should be involved.
<@zbyszek:fedora.im>
18:18:01
At this point, the scope of the change is so unclear, that I think approving it would be just bad governance.
<@conan_kudo:matrix.org>
18:18:16
It's important to note that our risk profile is different from other distributions
<@py0xc3:fedora.im>
18:18:20
If a user has third party software that is broken or captured (e.g. security updates not done), that package could take over e.g., firefox with credentials etc. Our own packages, the same, but I assume here the risk is lower. The problem is we have many users with third party needs. more than other distros
<@py0xc3:fedora.im>
18:18:29
If a user has third party software that is broken, malicious or captured (e.g. security updates not done), that package could take over e.g., firefox with credentials etc. Our own packages, the same, but I assume here the risk is lower. The problem is we have many users with third party needs. more than other distros
<@py0xc3:fedora.im>
18:18:42
If a user has third party software that is broken, malicious or captured (e.g. security updates not done), that package could take over dataof e.g., firefox with credentials etc. Our own packages, the same, but I assume here the risk is lower. The problem is we have many users with third party needs. more than other distros
<@conan_kudo:matrix.org>
18:18:45
we have fairly strong system wide MAC, among other things
<@py0xc3:fedora.im>
18:18:45
If a user has third party software that is broken, malicious or captured (e.g. security updates not done), that package could take over data of e.g., firefox with credentials etc. Our own packages, the same, but I assume here the risk is lower. The problem is we have many users with third party needs. more than other distros
<@conan_kudo:matrix.org>
18:18:49
most distributions don't have that
<@salimma:fedora.im>
18:18:58
we're 12 minutes in - the agenda is a bit short today so I'll let this discussion continue a bit longer, but let's wrap it up by 25 past
<@py0xc3:fedora.im>
18:19:09
MAC does not much within the account. SELinux confinement cannot be used within. We test that for years.
<@mjw:fedora.im>
18:19:15
We have an existing package that provides a default yama scope which other packages can rely on if they need the default nterprocess syscalls to work.
<@siosm:matrix.org>
18:20:00
elfutils-libs-0.194-1.fc43.x86_64
<@siosm:matrix.org>
18:20:00
$ rpm -q --whatrequires default-yama-scope
<@siosm:matrix.org>
18:20:00
gdb-headless-16.3-6.fc43.x86_64
<@siosm:matrix.org>
18:20:00
$ rpm -q --whatrecommends default-yama-scope
<@decathorpe:fedora.im>
18:20:08
I can give a concrete example - sequoia-pgp upstream devs were confused to see that we're the "odd distro out" and don't restrict ptrace by default. they were worried that this can be used to exfiltrate secret key material from processes even if they are "encrypted at rest" (i.e. ssh-agent / gpg-agent / etc.)
<@siosm:matrix.org>
18:20:24
it should be a recommends for both here, not a require.
<@mjw:fedora.im>
18:20:42
The issue is that we would certainly like to make this policy/package better match requirements, but just removing the package doesn't do that.
<@amerey:fedora.im>
18:20:53
Debian does not restrict ptrace either I believe
<@decathorpe:fedora.im>
18:21:09
debian does not, but ubuntu and Arch do, AIUI.
<@mjw:fedora.im>
18:21:19
Right. When the policy was created we didn't have weak dependencies yet
<@py0xc3:fedora.im>
18:21:21
Yes, Debian is the only one I could identify that also disabled the kernel default. Also due to breaking developer needs.
<@sgallagh:fedora.im>
18:21:28
Fabio Valentini: Can ptrace read arbitrary memory locations? I'm woefully under-educated on this API.
<@decathorpe:fedora.im>
18:21:51
Stephen Gallagher: I'm not sure about the details, but apparently this is a concern, yes.
<@duffy:fedora.im>
18:21:52
zbyszek: by scope of change incomplete - you mean there isn't a clear plan to remove elfutils-default-yama-scope?
<@nirik:matrix.scrye.com>
18:22:00
I think at the least this change should have all the involved parties on board. Right now that doesn't seem like the case...
<@mjw:fedora.im>
18:22:31
There are various ways to limit that though.
<@conan_kudo:matrix.org>
18:22:47
my core concern is that automatic backtracing and problem reporting for the KDE Edition to upstream KDE should not break regardless of what we're doing
<@conan_kudo:matrix.org>
18:22:55
DrKonqi needs to continue working
<@fche:fedora.im>
18:22:55
i'm certainly biased in favour of the status quo, but wouldn't mind putting together a new Change proposal that makes the yama bit optional but also embraces developer needs, a compromoise
<@fche:fedora.im>
18:22:59
would promise not to be too wordy
<@salimma:fedora.im>
18:23:01
I'd be happy voting for a more minimal change that basically converts all the requires on default-yama-scope to recommends / suggests
<@nirik:matrix.scrye.com>
18:23:10
and it further sounds like we don't want to just remove the package entirely, we want to change it from always installed to only when developers need it?
<@decathorpe:fedora.im>
18:23:19
sure, there are mitigations (like making a prctrl from the process to disable external tracing, or making an SELinux policy for it?)
<@salimma:fedora.im>
18:23:20
so users who feel strongly for this (or spins) can have that package removed properly
<@mjw:fedora.im>
18:23:54
So I agree, I just don't know how to get there. I feel I have tried to help get us somewhere that the existing package maintainers agree on, but the proposal is such a massive wall of text it is hard to explain things clearly
<@py0xc3:fedora.im>
18:23:58
I wonder about this. We have a default way to achieve the disabling. The existing file for systemd.
<@duffy:fedora.im>
18:24:12
Conan Kudo: how do ubuntu, arch, et. al. who've done what the change proposal asks handle dr konqi
<@conan_kudo:matrix.org>
18:24:15
I'd like this change to be resubmitted for F45 with a version that has Mark Wielaard and Chris (py0xc3) as co-owners, and thus implicitly agree on what we should be doing
<@py0xc3:fedora.im>
18:24:16
I wonder about this. We have a default way to achieve the disabling. The existing file for systemd. 20-yama-ptrace.conf
<@nirik:matrix.scrye.com>
18:24:36
but we want it to NOT be disabled when developers need to use it...
<@conan_kudo:matrix.org>
18:24:38
well, a lot of them have variations of "it doesn't work" or "doesn't give useful data"
<@conan_kudo:matrix.org>
18:24:47
I'd rather not have us be in that pile
<@zbyszek:fedora.im>
18:24:54
Yes. There is no discussion of how this is handled in gdb and others, what happens on existing systems in upgrade.
<@salimma:fedora.im>
18:25:00
being able to remove the override sounds better to me than installing a second override to override the first override :P
<@duffy:fedora.im>
18:25:06
Conan Kudo: ok and what kind of user base does dr konqi have in fedora
<@conan_kudo:matrix.org>
18:25:25
100% of KDE users have it as we install it and configure it with Plasma desktop and mobile
<@siosm:matrix.org>
18:25:33
it's the second desktop in terms of users
<@decathorpe:fedora.im>
18:25:37
not *quite* true - I think it was mentioned on the mailing list that services like abrt already use CAP_USE_PTRACE (?) and would not be affected by this
<@conan_kudo:matrix.org>
18:25:41
it's how crash reporting and feedback reporting works for Plasma
<@py0xc3:fedora.im>
18:25:42
By the default, the kernel enables ptrace_scope which disables ptrace in many cases, the file 20-yama-ptrace.conf disables ptrace_scope so that ptrace can be used freely. Given we have the file explicitly with documentation for developers, I was wondering about the need for the package. That's what I just meant :)
<@salimma:fedora.im>
18:25:49
we're 19 mins in - do folks want to continue discussing this, or should we carry on in the fesco issue until next week?
<@salimma:fedora.im>
18:26:04
Please +1 if we want to continue this for 15 mins
<@py0xc3:fedora.im>
18:26:05
(so 20-yama-ptrace.conf is not enabled by default)
<@mjw:fedora.im>
18:26:19
Yes, concetrating on just yama is kind of odd. There are multiple layers that interact.
<@decathorpe:fedora.im>
18:26:21
Michel Lind UTC: I don't think punting to next week will buy us anything, we need to decide what to do
<@nirik:matrix.scrye.com>
18:26:31
Chris (py0xc3): but we don;'t want them to have to read thru stuff and find a magic file, we want to set it for them when they have say gdb installed or whatever
<@siosm:matrix.org>
18:26:34
-1 to discussing. I think we agree that the proposal needs to be trimmed down in size to be more to the point
<@salimma:fedora.im>
18:27:04
I count that as a +1 to continue discussing now
<@conan_kudo:matrix.org>
18:27:05
Proposal: FESCo kicks the proposal back and Chris (py0xc3), Mark Wielaard, and Frank Ch. Eigler figure out a new proposal for F45 that FESCo can vote on.
<@nirik:matrix.scrye.com>
18:27:07
So, perhaps we should take Frank Ch. Eigler up on making a new proposal and trying to get all others onboard?
<@siosm:matrix.org>
18:27:08
and include an impact assesment for the most common tools
<@sgallagh:fedora.im>
18:27:10
Proposal: The Change is rejected as-is. It may be resubmitted for Fedora 45 after being revised for clarity.
<@duffy:fedora.im>
18:27:24
Conan Kudo: dr konqi is installed by default for kde users, kde is the 2nd desktop in terms of user base size, so this is a desktop-specific tool? (as opposed to abrt which i dont believe is desktop specific?)
<@decathorpe:fedora.im>
18:27:27
do we? I mean ... how is this handled on ubuntu / Arch? I doubt that they ship an override file with gdb to disable a "security feature" ...
<@conan_kudo:matrix.org>
18:27:32
Yes.
<@mjw:fedora.im>
18:27:36
I am OK with that, but can we then please start from scratch?
<@sgallagh:fedora.im>
18:27:39
As my proposal is functionally the same as Conan Kudo 's, I withdraw it
<@conan_kudo:matrix.org>
18:27:53
Mark Wielaard: that's up to y'all to figure out
<@sgallagh:fedora.im>
18:27:53
+1
<@salimma:fedora.im>
18:27:53
thanks. I was about to ask that one of you withdraw
<@mjw:fedora.im>
18:28:04
The current Change Proposal is such a massive wall of text, I don't know where to start...
<@salimma:fedora.im>
18:28:10
+1 for Conan Kudo's proposal
<@siosm:matrix.org>
18:28:12
+1
<@decathorpe:fedora.im>
18:28:18
+1
<@zbyszek:fedora.im>
18:28:26
+1
<@dcantrell:fedora.im>
18:28:30
+1
<@nirik:matrix.scrye.com>
18:28:32
+1 to the proposal
<@mjw:fedora.im>
18:29:02
But I think I can work with Frank to get a more precise text. I just don't know if Chris agrees with that.
<@fche:fedora.im>
18:29:11
let's try.
<@salimma:fedora.im>
18:29:37
we have 6 - Máirín DuffyStephen Gallagher?
<@salimma:fedora.im>
18:29:44
why am I short one person
<@duffy:fedora.im>
18:29:52
+1 to kick it back
<@sgallagh:fedora.im>
18:30:29
I count +8
<@salimma:fedora.im>
18:30:36
yeah I missed Neal's vote, sorry
<@conan_kudo:matrix.org>
18:30:37
+1 for my own proposal
<@salimma:fedora.im>
18:30:44
stephen?
<@py0xc3:fedora.im>
18:30:44
We have done this many times. It ends up with me earning thumbs down and others reformulating texts that "I claim things" etc. Every discussion starts with fixing that ptrace_scope must remain disabled. So it is ok if others want to do a proposal. I am happy if it develops to something useful. But I have done this now 6 or 7 times. I hope you understand. But if there is anything concrete to be done in this way, feel free to let me know, I am happy to contribute, PR or so
<@sgallagh:fedora.im>
18:30:48
Oh right, +9
<@salimma:fedora.im>
18:30:55
I assume +1 since you had a similar one
<@sgallagh:fedora.im>
18:31:13
Michel Lind UTC: I also made an explicit +1 vote
<@zbyszek:fedora.im>
18:31:32
+1 for own proposal is implicit,
<@salimma:fedora.im>
18:31:35
!agreed FESCo rejects the current proposal, and asks Chris (py0xc3), Mark Wielaardand Frank Ch. Eiglerto figure out a new proposal for F45
<@nirik:matrix.scrye.com>
18:31:39
Chris (py0xc3): perhaps this time let the others write the framework and then just review/input on it later?
<@conan_kudo:matrix.org>
18:31:41
this time, FESCo is saying _we expect an F45 proposal with all three of you on it_
<@nirik:matrix.scrye.com>
18:32:02
but however it can work
<@conan_kudo:matrix.org>
18:32:08
so there's some incentive hopefully to get it figured out
<@py0xc3:fedora.im>
18:32:09
I am happy to any proposal I have knowledge about to give feedback ;)
<@zbyszek:fedora.im>
18:32:40
I don't think we should be so prescriptive about details.
<@py0xc3:fedora.im>
18:32:59
Sure 👍️
<@salimma:fedora.im>
18:33:08
yeah, I would like more consensus next time but I don't necessarily require three people to be forced to co-write something :)
<@salimma:fedora.im>
18:33:16
anyway, let's move on
<@salimma:fedora.im>
18:33:21
!topic #3526 Change: Java21RemovedEarlierThenScheduled
<@salimma:fedora.im>
18:33:30
!fesco 3526
<@zodbot:fedora.im>
18:33:31
● **Opened:** a month ago by alking
<@zodbot:fedora.im>
18:33:31
● **Last Updated:** 5 hours ago
<@zodbot:fedora.im>
18:33:31
● **Assignee:** jvanek
<@zodbot:fedora.im>
18:33:31
<@zodbot:fedora.im>
18:33:31
**fesco #3526** (https://pagure.io/fesco/issue/3526):**Change: Java21RemovedEarlierThenScheduled**
<@salimma:fedora.im>
18:34:04
we were just trying to figure out the details about the logging iirc? otherwise we're ok with the proposal
<@conan_kudo:matrix.org>
18:34:22
I mean, I don't understand the proposal either, but I'm fine handwaving that a bit
<@decathorpe:fedora.im>
18:34:22
+1 to the proposal, minus doing weird RPM scriptlets
<@fche:fedora.im>
18:34:30
s/Then/Than/ eeek :)
<@nirik:matrix.scrye.com>
18:34:37
I'm still +1 to the change, but would love the scriptlets sorted... but that doesn't need to be in this ticket? or does it if it's continent on approval?
<@conan_kudo:matrix.org>
18:34:57
well, we can't have scriptlets that have a chance of failing for whatever reason
<@salimma:fedora.im>
18:35:08
as long as it doesn't break immutable systems ... at this stage I'm ok with just +1 ing it
<@conan_kudo:matrix.org>
18:35:09
rpm now fails the transaction on any nonzero error code
<@sgallagh:fedora.im>
18:35:10
I agree: +1 to the change and the details can be worked out as it is implemented
<@nirik:matrix.scrye.com>
18:35:20
They don
<@decathorpe:fedora.im>
18:35:23
I'm pretty sure they just don't do anything there
<@conan_kudo:matrix.org>
18:35:29
so things like accessing devices and ttys and whatever can randomly cause failure
<@sgallagh:fedora.im>
18:35:32
Obviously, if this fails to work on immutable OSes, that's a detail to work out :)
<@nirik:matrix.scrye.com>
18:35:33
They don't fail, they just are useless and print to stdout
<@siosm:matrix.org>
18:35:38
No atomic variants include java AFAIK
<@salimma:fedora.im>
18:35:39
yeah
<@decathorpe:fedora.im>
18:35:59
it's a dep of LibreOffice? isn't that preinstalled on Silverblue?
<@conan_kudo:matrix.org>
18:36:03
my only concern is that unnecessary scriptlets create a risk of catastrophic failure
<@conan_kudo:matrix.org>
18:36:08
No.
<@decathorpe:fedora.im>
18:36:12
oh
<@siosm:matrix.org>
18:36:13
I agree that the scriplet things is not great but I don't think we should block the proposal on that
<@salimma:fedora.im>
18:36:14
we have the FPC request from Fabio Valentinito clarify scriptlet usage anyway
<@salimma:fedora.im>
18:36:16
https://pagure.io/packaging-committee/pull-request/1518
<@salimma:fedora.im>
18:36:29
so we can just not focus on that since I don't think we should decide that here
<@conan_kudo:matrix.org>
18:36:49
beside the horrifying scriptlet, it's fine +1
<@siosm:matrix.org>
18:36:49
LibreOffice would be a Flatpak but we don't enven include it (it's too big)
<@conan_kudo:matrix.org>
18:36:55
besides the horrifying scriptlet, it's fine +1
<@salimma:fedora.im>
18:36:56
so I see a +1 in the ticket from nirikand a -1 from Fabio
<@decathorpe:fedora.im>
18:37:06
I updated that to +1 I think
<@salimma:fedora.im>
18:37:10
ah
<@duffy:fedora.im>
18:37:20
is there any concern about precedent setting here
<@salimma:fedora.im>
18:37:22
two +1s - anyone else? @!zbyszekI'm not sure if your +1 was to the whole proposal
<@dcantrell:fedora.im>
18:37:28
+1 from me
<@conan_kudo:matrix.org>
18:37:36
what precedent are you thinking of?
<@zbyszek:fedora.im>
18:37:45
It was.
<@conan_kudo:matrix.org>
18:37:45
earlier removal in the form of a Change is perfectly reasonable
<@duffy:fedora.im>
18:37:57
Conan Kudo: using rpm scriptlets as a user messaging system for change mgmt
<@conan_kudo:matrix.org>
18:37:58
it's been done before, even if it's a bit rare
<@salimma:fedora.im>
18:38:00
I just realized I forgot to do the vote count for the previous ticket, will fix in the summary
<@conan_kudo:matrix.org>
18:38:08
oh yes, this is not allowed in Fedora at all
<@duffy:fedora.im>
18:38:29
i'm +1 if we can say something like "approval of this proposal does not amount to approval of scriplets as user change management"
<@duffy:fedora.im>
18:38:38
or something just to make sure this isnt brought back up later as a set precedent
<@conan_kudo:matrix.org>
18:38:40
there are both philosophical and technical problems with those scriptlets
<@conan_kudo:matrix.org>
18:38:48
yes I'm fine with that
<@nirik:matrix.scrye.com>
18:39:06
sure, we can note that... hopefully it will be addressed by fpc.
<@salimma:fedora.im>
18:39:12
we can say "we approve this proposal, noting that FPC will decide on the proposed usage of scriptlets"
<@salimma:fedora.im>
18:39:20
ah nirik got there first
<@conan_kudo:matrix.org>
18:39:30
I think it is important we do explicitly deny that part since it is scoped in the Change
<@salimma:fedora.im>
18:39:48
ok - someone want to wordsmith it now and we can re-vote, just to be sure?
<@sgallagh:fedora.im>
18:39:59
Revised Proposal: "This Change is approved conditionally so long as it does not use RPM scriptlets to communicate with the user."
<@conan_kudo:matrix.org>
18:40:12
wfm +1
<@salimma:fedora.im>
18:40:24
that's an explicit rejection of the scriptlets though - I thought we want FPC to decide that
<@nirik:matrix.scrye.com>
18:40:27
but thats us taking over for fpc isn't it?
<@salimma:fedora.im>
18:40:31
yeah
<@conan_kudo:matrix.org>
18:40:52
we can make it a one-off and have FPC smith a dedicated rule
<@conan_kudo:matrix.org>
18:40:59
I don't think that part if controversial
<@nirik:matrix.scrye.com>
18:41:07
I'm not sure we need to really worry about it... if we approve this and fpc later approves a 'no don't do that' the package will need to obey that like every other package
<@sgallagh:fedora.im>
18:41:10
nirik: I'm viewing it as a technical architecture decision. As Neal Gompa (Fedora) mentioned: it can break DNF pretty badly
<@zbyszek:fedora.im>
18:41:14
-1 to the revised version
<@salimma:fedora.im>
18:41:30
yeah, that's why I want to just note that FPC will be weighing on that part, we should not pre-judge what will happen
<@conan_kudo:matrix.org>
18:41:52
we already have bad things from third party ISVs, we don't need it from our own packages too
<@zbyszek:fedora.im>
18:42:01
I think the wording is sloppy
<@zbyszek:fedora.im>
18:42:34
The wording in the fpc proposal is also bad.
<@decathorpe:fedora.im>
18:42:37
I'm strong -1 to put things into log files that should just be part of the Release Notes / Upgrade Docs, and this is what should happen here too
<@salimma:fedora.im>
18:42:53
Proposal: FESCo approves this Change Proposal, noting that the use of scriptlet for notification is subject to the FPC review of https://pagure.io/packaging-committee/pull-request/1518
<@decathorpe:fedora.im>
18:43:26
+1 to this updated proposal, this is fine with me.
<@nirik:matrix.scrye.com>
18:43:33
+1
<@dcantrell:fedora.im>
18:43:39
+1
<@salimma:fedora.im>
18:43:44
and if zbyszek does not like that PR he can suggest changes there :)
<@conan_kudo:matrix.org>
18:43:46
+1
<@duffy:fedora.im>
18:43:48
+1
<@zbyszek:fedora.im>
18:43:49
+1
<@salimma:fedora.im>
18:44:13
we're on +7 - Timothée Ravier (travier)Stephen Gallagher?
<@sgallagh:fedora.im>
18:44:34
+1
<@siosm:matrix.org>
18:44:54
+1
<@salimma:fedora.im>
18:44:59
!agreed (+9, 0, -0) FESCo approves this Change Proposal, noting that the use of scriptlet for notification is subject to the FPC review of https://pagure.io/packaging-committee/pull-request/1518
<@salimma:fedora.im>
18:45:15
thanks! moving on
<@salimma:fedora.im>
18:45:17
!topic #3497 Update qtkeychain, qxmpp and Kaidan on f43 and f42
<@salimma:fedora.im>
18:45:21
!fesco 3497
<@zodbot:fedora.im>
18:45:23
**fesco #3497** (https://pagure.io/fesco/issue/3497):**Update qtkeychain, qxmpp and Kaidan on f43 and f42**
<@zodbot:fedora.im>
18:45:23
● **Assignee:** Not Assigned
<@zodbot:fedora.im>
18:45:23
● **Last Updated:** 58 minutes ago
<@zodbot:fedora.im>
18:45:23
● **Opened:** 3 months ago by fed500
<@zodbot:fedora.im>
18:45:23
<@salimma:fedora.im>
18:45:35
last week we were waiting on the COPR impact check IIRC
<@decathorpe:fedora.im>
18:45:49
this just had a new comment asking for more time
<@salimma:fedora.im>
18:45:57
ah woops, I missed that
<@conan_kudo:matrix.org>
18:45:57
yeah, asking for one more week
<@conan_kudo:matrix.org>
18:46:02
just an hour ago
<@conan_kudo:matrix.org>
18:46:06
so not surprising you missed it
<@salimma:fedora.im>
18:46:11
we don't need to vote for this do we?
<@conan_kudo:matrix.org>
18:46:17
nope
<@conan_kudo:matrix.org>
18:46:20
just defer
<@salimma:fedora.im>
18:46:22
yeah ok, moving on
<@salimma:fedora.im>
18:46:34
!info this ticket will be discussed next week
<@conan_kudo:matrix.org>
18:46:36
probably put an info though for logs
<@salimma:fedora.im>
18:46:47
for a sec I thought I got the command wrong
<@conan_kudo:matrix.org>
18:46:57
lol no race of messages
<@salimma:fedora.im>
18:46:58
I should have said next meeting, oh well. next week is close to Connect
<@salimma:fedora.im>
18:47:12
!topic #3530 Change: Podman6
<@salimma:fedora.im>
18:47:19
!fesco 3530
<@zodbot:fedora.im>
18:47:20
**fesco #3530** (https://pagure.io/fesco/issue/3530):**Change: Podman6**
<@zodbot:fedora.im>
18:47:20
<@zodbot:fedora.im>
18:47:20
● **Opened:** a month ago by alking
<@zodbot:fedora.im>
18:47:20
● **Last Updated:** 6 hours ago
<@zodbot:fedora.im>
18:47:20
● **Assignee:** lsm5
<@conan_kudo:matrix.org>
18:47:35
ping Matt Heon Mohan Boddu lsm5
<@salimma:fedora.im>
18:47:37
omg I might be able to go home at a sane hour
<@sgallagh:fedora.im>
18:47:40
I discussed this with Mohan Boddu recently. I have *concerns*
<@conan_kudo:matrix.org>
18:47:57
the discussion I've seen so far worries me
<@salimma:fedora.im>
18:48:06
I don't see this discussed yet (apologies if I miss it) - what will be the concern if we delay this to F45?
<@nirik:matrix.scrye.com>
18:48:11
Michel Lind UTC: you just jinxed it. ;)
<@mheon:matrix.org>
18:48:11
Here and ready to answer questions
<@dcantrell:fedora.im>
18:48:17
(I have a hard stop in 10 mins, fwiw)
<@salimma:fedora.im>
18:48:20
:P
<@sgallagh:fedora.im>
18:48:28
Michel Lind UTC: There's a lot of pressure from our big sponsor to get this in for F44
<@mohanboddu:fedora.im>
18:48:30
I am here and so does Matt Heon and Paul Holzinger
<@duffy:fedora.im>
18:48:32
(i have a hard stop in 10 as well)
<@salimma:fedora.im>
18:48:59
we're on our penultimate issue luckily and this is the last serious one (hopefully. I'm not insulting anyone as I wrote the next change proposal)
<@sgallagh:fedora.im>
18:49:07
However the reality is that they will definitely not meet the Beta timeline and might not even meet the GA timeframe for landing all of the incompatible changes
<@nirik:matrix.scrye.com>
18:49:12
I'm +1 to this, but... I think we need to carefully watch things and if it doesn't end up in time for beta, we defer...
<@decathorpe:fedora.im>
18:49:14
the timeline for the 6.0 update looks concerningly tight to me. I don't think F44 Beta should ship with a version that doesn't handle the migration
<@salimma:fedora.im>
18:49:31
nuclear option: delay F44 :P
<@nirik:matrix.scrye.com>
18:49:53
ah, I might not be up on all the latest of the discussion then. I thought there was still a hope to make beta for things.
<@conan_kudo:matrix.org>
18:50:01
my biggest concern is that the N-2 upgrade path is basically gauranteed to be broken
<@salimma:fedora.im>
18:50:16
only in beta, or also in final?
<@conan_kudo:matrix.org>
18:50:17
there is no salvaging that with the current plans
<@sgallagh:fedora.im>
18:50:33
Without any guarantees on how long it would be delayed, I won't vote for that.
<@mohanboddu:fedora.im>
18:50:44
As I mentioned in the change proposal, the only breaking change that might not be able to land is the config change, which should be ready for the final GA
<@conan_kudo:matrix.org>
18:50:46
and I've personally been bitten by Podman upgrades like this before, and I'm extremely wary of the fact it isn't handled at all
<@mheon:matrix.org>
18:51:03
To be clear: N-2 is only broken for users on Bolt, which from everything I've seen is a very small minority.
<@mheon:matrix.org>
18:51:18
Not contending we shouldn't do anything about it
<@sgallagh:fedora.im>
18:51:25
Mohan Boddu: Last week you told me you were very concerned that it would *not* make GA. And I told you that a major change in config formats is not something I'm comfortable landing after Beta.
<@luap99:holzinger.dev>
18:51:48
users must upgrade to 5.8 first (and run podman after reboot) which then handles the migration, but yes if users skip that which are still on boltddb the upgrade path gets broken
<@duffy:fedora.im>
18:52:00
"Users still relying on deprecated components (slirp4netns, cgroups v1, BoltDB) will need to migrate to the supported alternatives before upgrading." <= is the impact here that users will need to take longer to upgrade to fedora, or that they'll be broken and it'll be a *surprise* migration for them
<@conan_kudo:matrix.org>
18:52:06
my line in the sand here is that you need to come up with a way to handle automatic transitions even at beta time, even if it means shipping two versions of podman in the same source package and creating a wrapper to trigger upgrades
<@duffy:fedora.im>
18:52:08
because taking longer to upgrade - ok.
<@conan_kudo:matrix.org>
18:52:22
my line in the sand here is that you need to come up with a way to handle automatic transitions even at beta time, even if it means shipping two versions of podman in the same source package and creating a wrapper to trigger upgrades (like how PgSQL used to do it)
<@mohanboddu:fedora.im>
18:52:39
Stephen Gallagher: Oh, sorry for the misunderstanding, I meant that it wont be ready for Beta release not the final release
<@conan_kudo:matrix.org>
18:52:48
it is not okay to require stepwise upgrades in Fedora without automatic handling of that case
<@siosm:matrix.org>
18:53:09
As much as I would like those changes as well, it's difficult to approve this if this is not ready by beta time.
<@zbyszek:fedora.im>
18:53:10
This would be easier if there was a standalone command to migrate the db. Having to install and run a specific OS version is a very heavyweight requirement.
<@duffy:fedora.im>
18:53:11
Conan Kudo: by n-2 do you mean say an f42=>f44 direct upgrade with no f43 in the middle? or what do you mean by n-2
<@conan_kudo:matrix.org>
18:53:23
yes
<@luap99:holzinger.dev>
18:53:34
but f42 also will have podman 5.8
<@duffy:fedora.im>
18:53:36
Conan Kudo: is that a common path? do we state we support that?
<@conan_kudo:matrix.org>
18:53:40
yes
<@salimma:fedora.im>
18:53:49
so if we say podman 6 require podman 5.8 if podman is installed, that should be safe to prevent an accidnetal upgrade right?
<@duffy:fedora.im>
18:53:50
Conan Kudo: yes to which and where is your data from
<@sgallagh:fedora.im>
18:53:56
Mohan Boddu: OK, if there's a *chance* of the config change landing before Beta, I'm listening.
<@mohanboddu:fedora.im>
18:54:01
Well, as part of the OS upgrade, we suggest updating before upgrading, so this should be caught by that update.
<@salimma:fedora.im>
18:54:01
if you have the old one it will refuse to do the transaction
<@mheon:matrix.org>
18:54:18
Other maintainers have some reservations about shipping >1 Podman version in the same package - in the case someone actually finds it, even if it's not in PATH, they can potentially make bad things happen. Having different versions of the same underlying libraries acting at the same time has caused serious problems in the past.
<@conan_kudo:matrix.org>
18:54:19
it is supported and documented, commonality does not matter (though I am aware that it is a thing people recommend somewhat frequently)
<@conan_kudo:matrix.org>
18:54:31
err
<@mohanboddu:fedora.im>
18:54:32
Well, as part of the OS upgrade, we suggest updating before upgrading, so this should be caught by that.
<@siosm:matrix.org>
18:54:35
Máirín DuffyThe official update policy is that updates form N-2 to N are supported.
<@luap99:holzinger.dev>
18:54:51
as for as migration on f44 we could offer a copr package or something with podman 5.8 still I suppose. I am not sure we can reasonably extract the migration code in a stand alsoe tool
<@siosm:matrix.org>
18:55:04
we don't support that for Atomic Desktops variants and CoreOS has a different update model
<@conan_kudo:matrix.org>
18:55:09
we do not require it, and we cannot enforce it, so it's advisory at best
<@jspaleta:fedora.im>
18:55:28
im not sure that's true... because it requires a restart of the podman service to trigger the migration.. updating on the commandline toolks..doesnt ensure that.
<@luap99:holzinger.dev>
18:55:28
shipping podman 6 and podman 5.8 as part of the same rpm runs into problems as we cannot guarantee that things work when you run two different version in parallel
<@duffy:fedora.im>
18:55:30
we shuold require it. it's like asking for your arm to be gnawed off by angry gnomes to not
<@mheon:matrix.org>
18:55:42
I was thinking about that Paul, and in theory it should be possible to do a very stripped-down 5.8 binary that basically removes every entrypoint except `system migrate`...
<@sgallagh:fedora.im>
18:55:52
We (FESCo) don't need to architect the upgrade path here. It's sufficient to say that we require that it works.
<@decathorpe:fedora.im>
18:55:59
also, just doing the update won't actually trigger the migration, only all users *running* podman before doing the upgrade would?
<@mheon:matrix.org>
18:56:08
But that would take time, and I think our biggest concern about the 44 timeframe is already not having enough time to deliver certain things
<@zbyszek:fedora.im>
18:56:09
Yep.
<@nirik:matrix.scrye.com>
18:56:29
can we run the migration in scriptlets on upgrade to 6 from 5.8?
<@conan_kudo:matrix.org>
18:56:32
fwiw, you can make the old version a non-path binary and just use some kind of check to run the old version first, then switch to the new version
<@conan_kudo:matrix.org>
18:56:44
that's what pgsql used to do because it has the same problem
<@luap99:holzinger.dev>
18:56:50
yes and after a reboot, or you need to run the migration command explicitly
<@sgallagh:fedora.im>
18:56:59
nirik: Please, no scriptlets. A systemd unit run on the first time podman.service starts would be great, though
<@nirik:matrix.scrye.com>
18:57:10
sure, that works too.
<@conan_kudo:matrix.org>
18:57:14
(I keep saying used to, because they accidentally on purpose didn't for f43 and we got a bunch of people complaining about broken databases on upgrade)
<@salimma:fedora.im>
18:57:15
let's try to get somewhere in the next 3 mins, since dcantrell and duffy need to leave
<@siosm:matrix.org>
18:57:34
I think that's the plan (service on boot)
<@nirik:matrix.scrye.com>
18:57:36
Conan Kudo: they actually ship the old binaries in the upgrade package...
<@conan_kudo:matrix.org>
18:57:56
hmm then it didn't fire or something? anyway for later
<@sgallagh:fedora.im>
18:58:04
OK, I'd like to submit a proposal. Give me a moment to wordsmith it.
<@nirik:matrix.scrye.com>
18:58:14
Conan Kudo: they _skipped_ a version is what happened. ;(
<@duffy:fedora.im>
18:58:16
im going to say what one of my unstated assumptions are here - i think the podman 6 upgrade is important and strategic. freedom friends FEATURES FIRST. it sounds like a feature that would be a headliner in release notes and in the press when we release. the sort of thing that *might* (i think this is council purview) be worth pushing dates out for.
<@duffy:fedora.im>
18:58:29
if that understanding / assumption is incorrect LMK
<@luap99:holzinger.dev>
18:58:33
we cannot really do scriptlets and the likes, podman's db is per user which means root, and all regular users need to get migrated so all users which use podman need to run it after the update
<@salimma:fedora.im>
18:58:42
Máirín Duffyyeah I'm with you there
<@decathorpe:fedora.im>
18:59:00
Máirín Duffy: that sounds about right. it still shouldn't land if it breaks stuff though
<@mheon:matrix.org>
18:59:08
Paul beat me to it, but I'll add that our ability to migrate users who explicitly opted into the old database in the config file is also limited
<@duffy:fedora.im>
18:59:10
im +1 if my assumption is correct, and maybe a caveat can we have a checkpoint / revisit around beta time?
<@conan_kudo:matrix.org>
18:59:12
that's reason enough to say these kinds of transitions need to be handled with even more care than the average
<@salimma:fedora.im>
18:59:17
I think if there's a reasonable plan (let's wait for Stephen's wordsmithing) I'm fine approving it, and we can deal with it later if we need to either delay F44 or abort the change - obviously we won't delay the release forever
<@duffy:fedora.im>
18:59:22
i have to go ☹️
<@sgallagh:fedora.im>
18:59:31
Proposal: Podman 6 is approved to land in Fedora 44 with the following conditions:
<@sgallagh:fedora.im>
18:59:31
1. If the complete set of incompatible changes is not at least in the updates-testing repo by Beta Freeze, the Contingency Plan must be invoked.
<@sgallagh:fedora.im>
18:59:31
2. Upgrades must be cleanly supported from Fedora 42.
<@salimma:fedora.im>
18:59:47
+1
<@conan_kudo:matrix.org>
18:59:59
Stephen Gallagher: F42 GA, but otherwise +1
<@nirik:matrix.scrye.com>
19:00:05
+1
<@decathorpe:fedora.im>
19:00:10
clarify: by Beta Freeze -> at the *start* or *during* the beta freeze?
<@salimma:fedora.im>
19:00:11
uh I wonder how a paragraph will look in the agreed command :P
<@conan_kudo:matrix.org>
19:00:16
(the reason is anyone can downgrade to the GA package at any time)
<@siosm:matrix.org>
19:00:39
F42 GA would be very difficult
<@sgallagh:fedora.im>
19:00:52
Conan Kudo: I'm not committing to that. If we need to put out an update in F42 to make it work and document that, I consider it acceptible (though not ideal)
<@salimma:fedora.im>
19:00:52
if the upgrade fails if you have the wrong version that's good enough for me fwiw
<@luap99:holzinger.dev>
19:00:54
I would like to know what the second point means in practise? what does cleanly supported mean?
<@decathorpe:fedora.im>
19:00:59
(that sounds like an edge case of an edge case of an edge case now)
<@zbyszek:fedora.im>
19:01:03
Can we make that "end of beta freeze"?
<@salimma:fedora.im>
19:01:03
just don't leave people in a broken state
<@nirik:matrix.scrye.com>
19:01:18
well, if 6 requires 5.8, it would just not upgrade until the user upgraded to 5.8
<@conan_kudo:matrix.org>
19:01:19
we're already in that state now, the problem is that if an upgrade is starting from GA podman then it's broken
<@conan_kudo:matrix.org>
19:01:30
and GA podman + everything else upgrade is a reasonable case
<@conan_kudo:matrix.org>
19:01:42
because you can _always_ downgrade to GA
<@salimma:fedora.im>
19:01:48
ideally we can also check if the configs are already migrated but idk if that'd be possible in RPM
<@decathorpe:fedora.im>
19:01:56
not sure I follow what you mean here?
<@decathorpe:fedora.im>
19:01:56
also it wouldn't account for atomic systems AIUI
<@decathorpe:fedora.im>
19:01:56
<@conan_kudo:matrix.org>
19:02:06
it is possible with triggers
<@conan_kudo:matrix.org>
19:02:19
I do this for fedora upgrade transitions in KDE
<@salimma:fedora.im>
19:02:23
I guess nirik and I are talking about the same thing - have podman 6 Requires: (podman >= 5.8 if podman)
<@conan_kudo:matrix.org>
19:02:26
but it's not "nice"
<@siosm:matrix.org>
19:02:28
you can do this migration in scriplets, this must happen in a service unit
<@nirik:matrix.scrye.com>
19:02:48
yes, that same thing...
<@salimma:fedora.im>
19:02:52
ideally we can also test if the system is migrated or not - idk, a %pre check that fails if it finds the old settings?
<@sgallagh:fedora.im>
19:02:54
If they can make it work with the GA package, great. If it works with F42+latest updates, that's good enough for mo
<@siosm:matrix.org>
19:02:56
there are details about that in the discussion on github
<@sgallagh:fedora.im>
19:02:58
If they can make it work with the GA package, great. If it works with F42+latest updates, that's good enough for me
<@conan_kudo:matrix.org>
19:03:12
the thing is, it's already the case it works with F42 latest updates
<@sgallagh:fedora.im>
19:03:14
Conan Kudo: Good vs. Good Enough
<@decathorpe:fedora.im>
19:03:25
would that have any effect on ostree systems at all?
<@mheon:matrix.org>
19:03:37
We can test if root is migrated easily enough, but each user has an independent database; I don't think we can reasonably verify each user's Podman installation is safe in the RPM
<@salimma:fedora.im>
19:03:39
hmm, not sure
<@nirik:matrix.scrye.com>
19:03:53
I will also note that we have no critera for GA upgrades.
<@luap99:holzinger.dev>
19:03:54
well the issue is each db is per user, so you would need to query all user which doesn't seem realistic?
<@salimma:fedora.im>
19:04:02
that's probably good enough
<@conan_kudo:matrix.org>
19:04:06
my suggestion is to wrap the podman executable with a script that calls podman to test and check, then do the needful
<@salimma:fedora.im>
19:04:12
perfect is the enemy of good etc
<@nirik:matrix.scrye.com>
19:04:15
"For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed. "
<@salimma:fedora.im>
19:04:47
ok we're over 15 mins in on this, let's vote on one of the proposals
<@salimma:fedora.im>
19:04:51
should we do nirik's?
<@nirik:matrix.scrye.com>
19:05:11
I'm not sure I had one? you mean Stephen Gallagher's ?
<@zbyszek:fedora.im>
19:05:23
Accessing home areas might not even be possible, e.g. with NFS or homed.
<@salimma:fedora.im>
19:05:25
the "for each one". but yeah we can vote on Stephen's
<@salimma:fedora.im>
19:05:42
this
<@nirik:matrix.scrye.com>
19:05:46
I was just quoting our actual release critera that QE actually tests.
<@nirik:matrix.scrye.com>
19:06:01
+1 still to that proposal
<@siosm:matrix.org>
19:06:08
https://github.com/containers/podman/issues/27628#issuecomment-3612525963
<@conan_kudo:matrix.org>
19:06:20
Matt Heon, Paul Holzinger: let's talk after the meeting about how to do this, I think this is doable to solve so even GA people or folks manually selecting boltdb are correctly handled
<@zbyszek:fedora.im>
19:06:34
Once again, can we make that end of beta freeze?
<@siosm:matrix.org>
19:06:37
+1
<@sgallagh:fedora.im>
19:06:44
Conan Kudo: If you can make it work, that's *great*. I'm all for it. I just don't want to block on it.
<@siosm:matrix.org>
19:06:54
+1 for end of beta freeze
<@salimma:fedora.im>
19:06:54
I think fabio was waiting to vote on whether this si beginning or end of beta freeze
<@conan_kudo:matrix.org>
19:06:58
why end? end of freeze is the release for updates
<@zbyszek:fedora.im>
19:06:58
That'd give more time
<@sgallagh:fedora.im>
19:06:59
zbyszek: I missed that comment.
<@luap99:holzinger.dev>
19:07:09
Conan Kudo: sounds good
<@conan_kudo:matrix.org>
19:07:31
not fixing this is way too dangerous and speculative
<@decathorpe:fedora.im>
19:07:39
yes. because "by beta freeze" was too vague for me
<@salimma:fedora.im>
19:07:40
so I have +5 at the moment (stephen, me, Conan Kudo, nirik, Timothée Ravier (travier))
<@nirik:matrix.scrye.com>
19:07:41
How would that work? if it's not ready we couldn't pull it from beta.. you mean pull it after beta already goes out?
<@siosm:matrix.org>
19:07:44
This is the issue the talks about the details of the design for the database migration
<@salimma:fedora.im>
19:07:48
and I guess we lost dcantrell and duffy
<@conan_kudo:matrix.org>
19:07:48
we'd look sloppy for breaking podman installs
<@sgallagh:fedora.im>
19:07:49
I picked "beginning" because I figured we might need the Freeze period to invoke the Contingency Plan
<@decathorpe:fedora.im>
19:07:51
is that ... at the start? at the end? in between?
<@zbyszek:fedora.im>
19:07:55
Yeah, so podman6 could go out in that batch
<@conan_kudo:matrix.org>
19:08:08
yeah but we explicitly don't want that
<@conan_kudo:matrix.org>
19:08:19
because then there's basically no stabilization time
<@salimma:fedora.im>
19:08:21
we can do it end of freeze with a test day
<@nirik:matrix.scrye.com>
19:08:35
I think there might be slight wiggle room after beta freeze starts, but definitely end is too late.
<@conan_kudo:matrix.org>
19:08:52
no more than two weeks after beta freeze starts
<@conan_kudo:matrix.org>
19:09:05
freeze is a month, we need some ice in the churn
<@nirik:matrix.scrye.com>
19:09:09
I don't think we should add this here.
<@nirik:matrix.scrye.com>
19:09:19
if more time is needed we can address it then
<@sgallagh:fedora.im>
19:09:29
nirik: Counter-Proposal, then?
<@nirik:matrix.scrye.com>
19:09:29
freeze is 3 weeks I thought?
<@salimma:fedora.im>
19:09:41
checking the schedule
<@siosm:matrix.org>
19:09:44
freeze is 3 weeks
<@siosm:matrix.org>
19:09:50
2 weeks in sounds good
<@salimma:fedora.im>
19:09:54
beta 02-17 freeze, early target 03-10, target date 1 03-17
<@siosm:matrix.org>
19:09:57
https://fedorapeople.org/groups/schedule/f-44/f-44-key-tasks.html
<@salimma:fedora.im>
19:10:03
so 3 weeks to early target
<@salimma:fedora.im>
19:10:08
4 weeks to target date 1
<@conan_kudo:matrix.org>
19:10:11
yeah
<@conan_kudo:matrix.org>
19:10:20
we usually miss early target anyway :)
<@nirik:matrix.scrye.com>
19:10:25
Counter: by beta freeze.
<@nirik:matrix.scrye.com>
19:10:27
start
<@zbyszek:fedora.im>
19:10:33
2 weeks sounds good
<@conan_kudo:matrix.org>
19:10:44
I'm also fine with start of freeze, but two weeks in is the latest I think is reasonable
<@nirik:matrix.scrye.com>
19:10:46
If more time is needed, we can discuss that then
<@nirik:matrix.scrye.com>
19:11:04
I don't think we should now because we don't know what state things will be then
<@salimma:fedora.im>
19:11:05
if we are pretty sure podman would miss it we are just wasting another vote though
<@salimma:fedora.im>
19:11:30
though I guess that will be the QA people voting not us
<@sgallagh:fedora.im>
19:11:32
nirik: That's exactly what I wrote in my proposal, no?
<@mohanboddu:fedora.im>
19:11:52
If everyone is okay, then we would like to have that wiggle room, if we miss it we miss the F44 release
<@nirik:matrix.scrye.com>
19:12:01
yes, I do not support moving it _now_ to end of beta freeze or two weeks into beta freeze or anything like that
<@salimma:fedora.im>
19:12:35
we can say we approve if it's ready at the beginning of beta freeze, but would recommend QA allows slippage of up to 2 weeks?
<@zbyszek:fedora.im>
19:12:35
Ok. So +1 to the proposal that was voted
<@sgallagh:fedora.im>
19:12:42
Mohan Boddu: Is that your way of saying "we definitely won't be ready in time for the start of Beta Freeze"?
<@nirik:matrix.scrye.com>
19:14:12
I cannot speak for QE, but landing some big thing 2 weeks into beta freeze probibly isn't something that would like. ;)
<@siosm:matrix.org>
19:14:30
yeah :/
<@mohanboddu:fedora.im>
19:14:37
Stephen Gallagher: Not exactly
<@salimma:fedora.im>
19:14:53
I count +6 in - let's say this is for the beginning of the freeze and the proposal owners can sort out delays later with QE
<@salimma:fedora.im>
19:14:58
Fabio Valentinilast vote?
<@nirik:matrix.scrye.com>
19:15:34
we have an entire exception process for freezes even.
<@salimma:fedora.im>
19:15:39
yep
<@decathorpe:fedora.im>
19:15:58
Michel Lind UTC: can I have a final version of the proposal please?
<@salimma:fedora.im>
19:16:06
Podman 6 is approved to land in Fedora 44 with the following conditions:
<@salimma:fedora.im>
19:16:06
2. Upgrades must be cleanly supported from Fedora 42.
<@salimma:fedora.im>
19:16:06
1. If the complete set of incompatible changes is not at least in the updates-testing repo by beginning of Beta Freeze, the Contingency Plan must be invoked.
<@decathorpe:fedora.im>
19:16:08
I lost track of FE start +~- 1/2/3 weeks ...
<@salimma:fedora.im>
19:16:28
I think there's no consensus to pre-grant the delay, so we might as well vote for start of freeze first
<@decathorpe:fedora.im>
19:16:31
+1 to this, thanks.
<@salimma:fedora.im>
19:16:37
if people really want we can do a second vote just for pre-clearing a delay
<@salimma:fedora.im>
19:16:53
1. If the complete set of incompatible changes is not at least in the updates-testing repo by beginning of Beta Freeze, the Contingency Plan must be invoked.
<@salimma:fedora.im>
19:16:53
2. Upgrades must be cleanly supported from Fedora 42.
<@salimma:fedora.im>
19:16:53
!agreed (+7, 0, -0) Podman 6 is approved to land in Fedora 44 with the following conditions:
<@sgallagh:fedora.im>
19:17:00
Probably best to let adamw and Kamil Páral know that this may be a risk.
<@salimma:fedora.im>
19:17:21
yeah - Mohan Boddudo you want to handle that?
<@adamwill:fedora.im>
19:17:46
hi.
<@salimma:fedora.im>
19:17:55
we have summoned an Adam
<@adamwill:fedora.im>
19:18:05
major podman version landing two weeks after freeze? just file it on that pile of fire over there, thanks
<@salimma:fedora.im>
19:18:35
well, we punted that to QE :) - feel free to approve or deny if there's a request
<@sgallagh:fedora.im>
19:18:43
adamw: Early warning is better than a surprise, no?
<@adamwill:fedora.im>
19:18:46
note "two weeks after freeze" is "two days before go/no-go"
<@salimma:fedora.im>
19:18:56
now Adam won't sleep for the next few weeks
<@mohanboddu:fedora.im>
19:19:09
Hey adamw, I will let you know when we get close to the beta freeze, but yeah, just a heads up
<@salimma:fedora.im>
19:19:18
plot twist: Adam became a Podman developer to help implement the features
<@salimma:fedora.im>
19:19:41
ok - it's getting late in Europe and I guess Adam is already informed now, so let's go to our last topic?
<@nirik:matrix.scrye.com>
19:19:49
please
<@salimma:fedora.im>
19:19:56
!topic #3541 Change: CommonLicenses
<@salimma:fedora.im>
19:20:03
!fesco 3541
<@zodbot:fedora.im>
19:20:05
● **Assignee:** salimma
<@zodbot:fedora.im>
19:20:05
<@zodbot:fedora.im>
19:20:05
● **Opened:** 4 days ago by alking
<@zodbot:fedora.im>
19:20:05
**fesco #3541** (https://pagure.io/fesco/issue/3541):**Change: CommonLicenses**
<@zodbot:fedora.im>
19:20:05
● **Last Updated:** 3 hours ago
<@salimma:fedora.im>
19:20:27
there are some late updates from me and Neal on Discourse - apologies, the questions came at an inopportune time for me
<@decathorpe:fedora.im>
19:20:39
I have to say I don't understand David's comment on the ticket about "need to make sure licenses actually match" and "churn"
<@nirik:matrix.scrye.com>
19:20:59
I'm still -1... I think the yummy to trouble ratio isn't good enough.
<@salimma:fedora.im>
19:21:07
I took it to mean only convert packages if the license they ship exactly match, at least at the beginning? probably better to be safe
<@salimma:fedora.im>
19:21:47
yeah the yummy to trouble ratio is the reason Conan Kudoand I wanted to make this an optional thing at the beginning - so basically it's a low effort "we package this, this is how to use it, you don't have to"
<@salimma:fedora.im>
19:22:05
but if asked for we can help do some conversions
<@nirik:matrix.scrye.com>
19:22:36
So, the gain here is some disk space? I suspect there may be better things to target for that...
<@salimma:fedora.im>
19:22:41
the concern.. zbyszek has I think? -- that if packagers manually opt in they do it inconsistently makes sense
<@salimma:fedora.im>
19:22:46
not just disk space
<@salimma:fedora.im>
19:23:11
also that if the upstream projects don't ship some license texts, and it's in common-licenses that's a signal that "you don't need to contact upstream"
<@nirik:matrix.scrye.com>
19:23:35
thats not great. Contacting upstream and getting them to fix their thing is a advantage IMHO
<@salimma:fedora.im>
19:24:01
in Rust land at least that's actually a big part of the manual process of packaging - this won't help for licenses like MIT but for some other licenses that do not contain the author copyrights this will save some time
<@siosm:matrix.org>
19:24:02
Ideally I would prefer we start pushing upstream to cleanup their license text to use the standard one instead of a customized one but that's going to take a while
<@salimma:fedora.im>
19:24:45
our packaging guidelines say SHOULD in that scenario iirc - we only require it for licenses like MIT where the license requires distribution
<@decathorpe:fedora.im>
19:25:20
> this won't help for licenses like MIT
<@decathorpe:fedora.im>
19:25:20
if it's SPDX "MIT" then that's actually a well-defined license text and it *would* work for that - SPDX-MIT is not a family like old Fedora-MIT
<@decathorpe:fedora.im>
19:25:20
<@siosm:matrix.org>
19:25:27
For Atomic variants, license files that are 100% the same are already de-duplicated so there will be no space gains
<@zbyszek:fedora.im>
19:25:34
The current proposal seems like a missed opportunity: a lot of work for small benefits. This should really be automated, not a chore.
<@salimma:fedora.im>
19:25:40
I might try and dig out how Debian adopts their policy, which the CP is inspires by - their debian/copyright file lists all license texts except for those in their shared common licenses package
<@salimma:fedora.im>
19:26:11
but they all require the author copyright to be in that file, right? that's the main problem even if the rest is standard
<@conan_kudo:matrix.org>
19:26:15
SPDX-MIT is not well defined either
<@conan_kudo:matrix.org>
19:26:21
it's an entire family of licenses
<@decathorpe:fedora.im>
19:26:30
that's not a mandatory part no
<@salimma:fedora.im>
19:26:51
anyway ... yeah Conan Kudoshould we defer this to F45 and rethink? maybe we can focus on deduplication
<@conan_kudo:matrix.org>
19:27:08
the policy change and the package creation should be decoupled
<@conan_kudo:matrix.org>
19:27:15
common-licenses can exist before we change anything
<@conan_kudo:matrix.org>
19:27:46
it probably _should_ be decoupled regardless
<@salimma:fedora.im>
19:27:50
ok - scope this down to making the new package as described in the Change Proposal, but expressly say this is for reference purpose only for other packagers?
<@salimma:fedora.im>
19:27:56
then we can have that policy talk later
<@conan_kudo:matrix.org>
19:28:03
works for me
<@decathorpe:fedora.im>
19:28:09
wfm2
<@nirik:matrix.scrye.com>
19:28:44
so, you want to change the scope for f44 ? or resubmit for f45?
<@salimma:fedora.im>
19:28:48
Proposal: FESCo approves this change, but it must clearly indicates that for the time being, other packages must still ship their own license texts as before
<@salimma:fedora.im>
19:29:01
change the scope for f44 - no point deferring for a smaller scope
<@decathorpe:fedora.im>
19:29:15
at this point, does this really still need to be a CP?
<@nirik:matrix.scrye.com>
19:29:23
I'm -1 to voting on a thing that is not the current proposal. Counter: edit the proposal and we revisit next week?
<@salimma:fedora.im>
19:29:24
additional context: we submitted a Flock talk on this topic, so maybe the discussion there can inform any policy implementation for f45
<@salimma:fedora.im>
19:29:42
I think it can be a self-contained change at this point instead of system wide, or we can even skip that
<@salimma:fedora.im>
19:29:50
but yes we can vote on a revision at the next meeting
<@nirik:matrix.scrye.com>
19:30:07
or yeah, if it's just a package it could not be a proposal... depending
<@salimma:fedora.im>
19:30:08
should we vote to defer or we can just say if nobody object I'll defer
<@zbyszek:fedora.im>
19:30:31
I think we can keep the proposal, since it's already there.
<@salimma:fedora.im>
19:30:32
I'm also happy just introducing a new package and skipping any additional vote
<@conan_kudo:matrix.org>
19:31:23
probably not
<@nirik:matrix.scrye.com>
19:31:29
so, withdraw this for now and just do a new package and revisit new proposal for f45?
<@conan_kudo:matrix.org>
19:31:38
fine with me
<@salimma:fedora.im>
19:31:41
sure
<@zbyszek:fedora.im>
19:31:41
Ok, change owners decide. I think we'll approve whatever.
<@salimma:fedora.im>
19:32:17
!agreed Change Owners are withdrawing this change, and will just submit common-licenses as a package and defer policy changes to a new proposal for F45
<@siosm:matrix.org>
19:32:18
+1
<@salimma:fedora.im>
19:32:22
well that's easy
<@salimma:fedora.im>
19:32:27
now we need to find next week's chair
<@salimma:fedora.im>
19:32:35
one sec
<@salimma:fedora.im>
19:32:42
!topic Next week's chair
<@decathorpe:fedora.im>
19:32:55
I will or won't be on a train, a metro, or in a hotel room at this time next week, depending on ... *waves about*
<@salimma:fedora.im>
19:33:01
we should discuss when we get to open floor if we even have a meeting next week
<@salimma:fedora.im>
19:33:17
because yeah, I'll be in Brussels
<@zbyszek:fedora.im>
19:33:30
I'll be traveling next week too...
<@conan_kudo:matrix.org>
19:33:36
traveling as well
<@decathorpe:fedora.im>
19:33:44
skip next week, meet in 14 days?
<@sgallagh:fedora.im>
19:33:48
I am not going to FOSDEM and will be around, so if we have a meeting, I can chair it
<@salimma:fedora.im>
19:33:51
should we decide first on when we'll have the next meeting? or we can just try to hold it and check for quorum
<@salimma:fedora.im>
19:34:09
we have stephen and nirik, we don't know about duffy and dcantrell
<@zbyszek:fedora.im>
19:34:25
Stephen to hold a meeting all by himself!
<@salimma:fedora.im>
19:34:30
and fabio, neal, zbyszek and me are definitely out
<@salimma:fedora.im>
19:34:38
who did we miss? oh Timothée Ravier (travier)
<@salimma:fedora.im>
19:34:51
if travier is also definitely out we can basically say next meeting is in two weeks
<@sgallagh:fedora.im>
19:34:54
zbyszek: I talk to myself all the time, what else is new?
<@salimma:fedora.im>
19:35:10
stephen suddenly passes 100 changes next week
<@salimma:fedora.im>
19:35:19
Benevolent Dictator of Fedora Linux
<@conan_kudo:matrix.org>
19:35:33
lol
<@sgallagh:fedora.im>
19:35:35
Michel Lind UTC: Benevolent? 👀
<@salimma:fedora.im>
19:35:40
Bandit?
<@siosm:matrix.org>
19:35:45
I should be available next weel. I'm not going to FOSDEM. OK to skipping as well
<@salimma:fedora.im>
19:36:00
ok, any of you who are around want to chair?
<@salimma:fedora.im>
19:36:03
I count three people
<@sgallagh:fedora.im>
19:36:10
I think I can do Feb 3
<@nirik:matrix.scrye.com>
19:36:11
so we could try next week and if no quorum, then oh well
<@salimma:fedora.im>
19:36:14
I guess ideally someone who can chair either next week or the week after
<@salimma:fedora.im>
19:36:16
yeah
<@salimma:fedora.im>
19:36:31
or have two volunteers, one for each week
<@salimma:fedora.im>
19:36:37
if nobody volunteers for Jan 27 let's just skip it
<@sgallagh:fedora.im>
19:37:14
I'm available to chair both
<@siosm:matrix.org>
19:37:27
I can try chairing at one point but maybe not right now as I definitely need to refresh my memory on some rules
<@sgallagh:fedora.im>
19:37:32
But if we do have it next week, I'd prefer not to do both
<@siosm:matrix.org>
19:37:32
and the process
<@salimma:fedora.im>
19:37:35
!action Stephen Gallagherwill chair next meeting. If there is no quorum on Jan 27 Stephen will chair on Feb 3
<@salimma:fedora.im>
19:37:53
yeah, if next week there is a meeting you can pick someone else to do the next one
<@salimma:fedora.im>
19:37:58
thanks Stephen!
<@salimma:fedora.im>
19:38:03
!topic Open Floor
<@zodbot:fedora.im>
19:38:15
salimma gave a cookie to sgallagh. They now have 256 cookies, 3 of which were obtained in the Fedora 43 release cycle
<@salimma:fedora.im>
19:38:19
sorry this took longer than expected
<@zodbot:fedora.im>
19:38:47
zbyszek gave a cookie to sgallagh. They now have 257 cookies, 4 of which were obtained in the Fedora 43 release cycle
<@zodbot:fedora.im>
19:38:58
yselkowitz gave a cookie to sgallagh. They now have 258 cookies, 5 of which were obtained in the Fedora 43 release cycle
<@conan_kudo:matrix.org>
19:39:34
I've got one thing to ask
<@salimma:fedora.im>
19:39:40
go for it
<@conan_kudo:matrix.org>
19:39:58
I'd like to ask if it'd be okay to mark the PK-DNF5 change as FastTrack approved
<@conan_kudo:matrix.org>
19:40:16
the dnf5 backend code was merged upstream today and I'm preparing to rip out the dnf4 code upstream too
<@salimma:fedora.im>
19:40:24
!fesco 3542
<@zodbot:fedora.im>
19:40:26
**fesco #3542** (https://pagure.io/fesco/issue/3542):**Change: PackageKit-DNF5**
<@zodbot:fedora.im>
19:40:26
<@zodbot:fedora.im>
19:40:26
● **Opened:** 4 days ago by alking
<@zodbot:fedora.im>
19:40:26
● **Last Updated:** an hour ago
<@zodbot:fedora.im>
19:40:26
● **Assignee:** ngompa
<@conan_kudo:matrix.org>
19:40:36
it's already got +7
<@salimma:fedora.im>
19:40:37
we should vote on whether to make it fast track I guess?
<@sgallagh:fedora.im>
19:40:43
Conan Kudo: Is there a particular reason to rush it?
<@conan_kudo:matrix.org>
19:41:19
mostly the squishy time-squeeze thing going on with FOSDEM and afterward
<@conan_kudo:matrix.org>
19:41:26
it's okay if the answer is no, but I figured I'd ask
<@nirik:matrix.scrye.com>
19:41:50
I think with +7 we can mark it approved now?
<@zbyszek:fedora.im>
19:41:56
If you set it to fast track, it'd get approved immediately, by the procedure.
<@conan_kudo:matrix.org>
19:42:05
yeah, that's why I'm asking rather than just doing it 😅
<@sgallagh:fedora.im>
19:42:10
The week is nominally there to allow time for dissent.
<@sgallagh:fedora.im>
19:42:24
But I'm ambivalent about this particular case.
<@sgallagh:fedora.im>
19:42:34
It's not particularly controversial
<@salimma:fedora.im>
19:42:38
for completeness let's vote on it? if nobody -1s now we can say we approve
<@salimma:fedora.im>
19:42:45
+1 to approve now
<@nirik:matrix.scrye.com>
19:42:57
not sure we still have quorum, but +1
<@decathorpe:fedora.im>
19:43:07
+1
<@zbyszek:fedora.im>
19:43:09
Maybe do that, @--mention those who didn't vote, and mark it as approved tomorrow?
<@zbyszek:fedora.im>
19:43:31
+1 to the vote
<@siosm:matrix.org>
19:43:37
+1 from me. I don't think this is controversial
<@salimma:fedora.im>
19:43:51
yeah - worst case Neal has to wait 3 days then we can mark it approved in 7 days
<@sgallagh:fedora.im>
19:43:53
Huh... I thought I'd +1 ed the ticket
<@zbyszek:fedora.im>
19:44:09
Sorry, my laptop has issues, and I'm doing the meeting on a phone and hating it.
<@salimma:fedora.im>
19:44:11
yeah but we didn't +1 for a fast track in the ticket
<@conan_kudo:matrix.org>
19:44:12
I can do that
<@sgallagh:fedora.im>
19:44:17
So that makes it +8, missing only duffy.
<@zbyszek:fedora.im>
19:44:24
Everything is slow.
<@conan_kudo:matrix.org>
19:44:29
it also auto approves if all nine +1
<@conan_kudo:matrix.org>
19:44:37
regardless of fast track
<@conan_kudo:matrix.org>
19:44:43
if I remember rightly
<@sgallagh:fedora.im>
19:44:48
No, it doesn't
<@sgallagh:fedora.im>
19:45:02
Again, the point is to allow for a full week of possible counterpoints to land
<@salimma:fedora.im>
19:45:34
should we just wait 3 days, that seems cleaner than trying to think through the procedure right now
<@salimma:fedora.im>
19:45:47
we can approve it immediately (I can do that) instead of waiting for the next meeting
<@salimma:fedora.im>
19:46:01
sorry, not immediately, I meant as soon as it gets to 7 days
<@sgallagh:fedora.im>
19:46:16
Once it's approved in the ticket, it's approved.
<@salimma:fedora.im>
19:46:27
yup. we just need someone to remember to do that
<@sgallagh:fedora.im>
19:46:32
The email is just a formal announcement to the rest of the project.
<@salimma:fedora.im>
19:46:37
rather than next monday when "oh I'm running the meeting tomorrow"
<@sgallagh:fedora.im>
19:47:03
But like I said, if we want to just say "go ahead, it's approved" right now, I don't care enough to stop it
<@salimma:fedora.im>
19:47:56
ok - just to be safe I'll ping the ones who have not voted and give them a day
<@salimma:fedora.im>
19:48:01
any other topic before we close?
<@siosm:matrix.org>
19:49:03
nothing from me
<@siosm:matrix.org>
19:49:10
leaving for dinner :)
<@salimma:fedora.im>
19:49:19
alright, thank you everyone for coming!
<@sgallagh:fedora.im>
19:49:23
🏃
<@salimma:fedora.im>
19:49:27
!endmeeting