2025-03-27 19:01:00 <@yselkowitz:fedora.im> !startmeeting ELN SIG 27 March '25
2025-03-27 19:01:02 <@meetbot:fedora.im> Meeting started at 2025-03-27 19:01:00 UTC
2025-03-27 19:01:02 <@meetbot:fedora.im> The Meeting name is 'ELN SIG 27 March '25'
2025-03-27 19:01:09 <@yselkowitz:fedora.im> !meetingname eln
2025-03-27 19:01:10 <@meetbot:fedora.im> The Meeting Name is now eln
2025-03-27 19:01:16 <@yselkowitz:fedora.im> !topic Init process
2025-03-27 19:01:27 <@tdawson:fedora.im> !hi
2025-03-27 19:01:28 <@zodbot:fedora.im> Troy Dawson (tdawson)
2025-03-27 19:01:39 <@davide:cavalca.name> !hi
2025-03-27 19:01:41 <@zodbot:fedora.im> Davide Cavalca (dcavalca) - he / him / his
2025-03-27 19:01:41 <@salimma:fedora.im> !hi
2025-03-27 19:01:43 <@zodbot:fedora.im> Michel Lind (salimma) - he / him / his
2025-03-27 19:03:53 <@conan_kudo:matrix.org> !hi
2025-03-27 19:03:55 <@zodbot:fedora.im> Neal Gompa (ngompa) - he / him / his
2025-03-27 19:04:11 <@rcallicotte:fedora.im> !hi
2025-03-27 19:04:12 <@zodbot:fedora.im> Robby Callicotte (rcallicotte) - he / him / his
2025-03-27 19:04:41 <@yselkowitz:fedora.im> welcome Robby Callicotte do you want to introduce yourself and your interest in ELN?
2025-03-27 19:04:54 <@salimma:fedora.im> ohai Robby
2025-03-27 19:06:19 <@rcallicotte:fedora.im> Thank you yselkowitz .  I just dropped by to listen in.  I'm a member of CentOS Alt Images SIG and at my $DAYJOB I handle the OS stuff (planning etc)
2025-03-27 19:06:51 <@yselkowitz:fedora.im> np welcome
2025-03-27 19:06:54 <@yselkowitz:fedora.im> let's get started
2025-03-27 19:07:03 <@yselkowitz:fedora.im> !topic New Business
2025-03-27 19:07:40 <@yselkowitz:fedora.im> !link https://src.fedoraproject.org/rpms/python-zope-i18nmessageid/pull-request/3
2025-03-27 19:08:10 <@yselkowitz:fedora.im> thanks for merging Michel Lind UTC-6
2025-03-27 19:08:18 <@yselkowitz:fedora.im> oh and there's a first build
2025-03-27 19:08:20 <@gmoro:matrix.org> !hi
2025-03-27 19:08:22 <@zodbot:fedora.im> Guilherme Moro (guilhermemoro)
2025-03-27 19:08:38 <@yselkowitz:fedora.im> that leaves only 3 ELN and 1 ELN Extras F42FTBFS left
2025-03-27 19:08:51 <@salimma:fedora.im> yup, I was just building it. do we need it for F42 too or just rawhide?
2025-03-27 19:09:41 <@yselkowitz:fedora.im> *I* only need it for rawhide and ELN, but it didn't rebuild for F42
2025-03-27 19:09:52 <@sgallagh:fedora.im> !hi
2025-03-27 19:09:53 <@zodbot:fedora.im> Stephen Gallagher (sgallagh) - he / him / his
2025-03-27 19:10:10 <@yselkowitz:fedora.im> !link https://github.com/fedora-eln/eln/issues/238
2025-03-27 19:10:10 <@sgallagh:fedora.im> I'm sort of here, but busy with other things. Please ping directly if you need my input.
2025-03-27 19:10:53 <@yselkowitz:fedora.im> Michel Lind UTC-6 Davide Cavalca this involves you iirc
2025-03-27 19:11:26 <@davide:cavalca.name> So this one is needed for Chef, among other things 
2025-03-27 19:11:43 <@davide:cavalca.name> I agree that we should probably drop the obsoletes on the RHEL side
2025-03-27 19:12:17 <@yselkowitz:fedora.im> can we bump the release to 100+, and is the Requires: libxcrypt needed?
2025-03-27 19:12:54 <@davide:cavalca.name> I'm pretty sure the requires is needed, but it's been a while since I've poked at it. [@michel:one.ems.host](https://matrix.to/#/@michel:one.ems.host) do you remember?
2025-03-27 19:13:09 <@conan_kudo:matrix.org> it is needed
2025-03-27 19:13:16 <@davide:cavalca.name> I don't like the idea of bumping the release. It's kind of a bad precedent and would just paper over the problem 
2025-03-27 19:13:27 <@davide:cavalca.name> This does need to be kept in sync with libscrypt
2025-03-27 19:13:38 <@davide:cavalca.name> This does need to be kept in sync with libxcrypt
2025-03-27 19:13:50 <@conan_kudo:matrix.org> the compat library is built on top of the regular one
2025-03-27 19:13:59 <@conan_kudo:matrix.org> IIRC
2025-03-27 19:14:03 <@davide:cavalca.name> Yeah
2025-03-27 19:14:23 <@salimma:fedora.im> one sec
2025-03-27 19:14:42 <@yselkowitz:fedora.im> but e.g. https://koji.fedoraproject.org/koji/rpminfo?rpmID=41827501 shows no dep on `libxcrypt.so.2`?
2025-03-27 19:15:06 <@yselkowitz:fedora.im> but e.g. https://koji.fedoraproject.org/koji/rpminfo?rpmID=41827501 shows no dep on `libcrypt.so.2`?
2025-03-27 19:15:07 <@conan_kudo:matrix.org> it's been a while since I looked at it, but IIRC it's a split out of some functions that still may call into the main library
2025-03-27 19:15:14 <@salimma:fedora.im> I think we try to keep it in sync with the RHEL package because the spec is based on it, not sure if it can be made independent -- I'll have to take a look
2025-03-27 19:15:21 <@conan_kudo:matrix.org> that might have changed in newer versions though
2025-03-27 19:15:49 <@conan_kudo:matrix.org> if it's done through dlopen then it won't show up that way
2025-03-27 19:16:05 <@conan_kudo:matrix.org> same reason I have to depend on sdl3 for sdl2-compat manually
2025-03-27 19:16:08 <@salimma:fedora.im> it's basically a standard '-epel' package - stream dropped the compat stuff, we ship only the compat stuff. like iptables-legacy being shipped in iptables-epel
2025-03-27 19:16:16 <@yselkowitz:fedora.im> ugh ok but is that what it's doing?
2025-03-27 19:16:23 <@yselkowitz:fedora.im> dlopen I mean
2025-03-27 19:16:28 <@salimma:fedora.im> I'll need to check again, I don't think any of us remember
2025-03-27 19:16:35 <@conan_kudo:matrix.org> I think that's what it did originally, I don't know if it still does now
2025-03-27 19:16:39 <@salimma:fedora.im> fwiw we've been trying to get Chef to fix this since... 2019. almost 6 years now
2025-03-27 19:16:46 <@conan_kudo:matrix.org> they may have fully split things apart since
2025-03-27 19:16:53 <@salimma:fedora.im> so ... I also would dearly love this to die. as I do *all* my -epel packages
2025-03-27 19:17:08 <@davide:cavalca.name> It's not just chef to be clear, tons of 3rd party stuff needs this
2025-03-27 19:17:11 <@conan_kudo:matrix.org> wow that's... a long time
2025-03-27 19:17:57 <@yselkowitz:fedora.im> yeah well the libxcrypt maintainer really didn't want -compat in RHEL 10 even, but VDDK is in the same boat
2025-03-27 19:18:13 <@salimma:fedora.im> yeah. the company imploded post acquisition... you're familiar with how that goes
2025-03-27 19:18:26 <@davide:cavalca.name> https://github.com/chef/omnibus/issues/890 fyi
2025-03-27 19:18:34 <@salimma:fedora.im> also they do those clowny omnibus style RPMs and pretended that insulates them from system dependencies, which is a fiction
2025-03-27 19:18:48 <@salimma:fedora.im> and turned off RPM requires generator so we find out the hard way, the RPM happily installs
2025-03-27 19:18:54 <@davide:cavalca.name> yeah I was about to say, the "right" solution is to grudgingly accept this is still needed and put it back into RHEL
2025-03-27 19:19:43 <@conan_kudo:matrix.org> the juice isn't really worth the squeeze here
2025-03-27 19:19:50 <@rcallicotte:fedora.im> seems to be the norm now with some automation tools
2025-03-27 19:19:50 <@yselkowitz:fedora.im> and that's what happened for 10, but they really really seriously this time don't want it in 11, you know how it goes
2025-03-27 19:20:05 <@conan_kudo:matrix.org> GitLab made this a popular approach
2025-03-27 19:20:06 <@davide:cavalca.name> yep, I know
2025-03-27 19:20:10 <@conan_kudo:matrix.org> it's super annoying
2025-03-27 19:20:46 <@conan_kudo:matrix.org> this whole thing reminds me that Puppet still requires `lsb_release(1)`
2025-03-27 19:21:00 <@conan_kudo:matrix.org> it's not my problem anymore, but I feel bad for everyone who still has to deal with it
2025-03-27 19:21:17 <@yselkowitz:fedora.im> can you guys look into the -compat->libxcrypt dependency side of this at least?
2025-03-27 19:21:29 <@davide:cavalca.name> yeah, we'll follow up on that
2025-03-27 19:21:35 <@salimma:fedora.im> yeah but if Chef does not need it we can orphan it and let someone who needs it more own it
2025-03-27 19:21:41 <@salimma:fedora.im> will do
2025-03-27 19:21:47 <@yselkowitz:fedora.im> !action Davide and Michel to follow up on libxcrypt-compat
2025-03-27 19:21:54 <@salimma:fedora.im> Salt just went this route too, which is sad
2025-03-27 19:22:49 <@yselkowitz:fedora.im> !link https://github.com/fedora-eln/eln/issues/239
2025-03-27 19:23:44 <@yselkowitz:fedora.im> this came up a couple weeks ago but didn't find a quick resolution so here we are
2025-03-27 19:24:08 <@conan_kudo:matrix.org> the only fix is to adjust upstream code to handle nmap-ncat
2025-03-27 19:24:09 <@yselkowitz:fedora.im> cloud-init 25.1 added a dep on netcat's `nc` which is incompatible with the nmap-ncat `nc` in RHEL and ELN
2025-03-27 19:24:32 <@conan_kudo:matrix.org> there is no quick resolution if nmap-ncat is missing something that cloud-init requires
2025-03-27 19:24:36 <@conan_kudo:matrix.org> but I can go look
2025-03-27 19:25:36 <@yselkowitz:fedora.im> I would think that there has got to be another way to do it that doesn't specifically require netcat
2025-03-27 19:26:04 <@conan_kudo:matrix.org> if new code needs to be written, this will need to be taken up with the RHEL cloud-init maintainers
2025-03-27 19:27:13 <@yselkowitz:fedora.im> unfortunately we're probably the only ones who care about one nc over the other
2025-03-27 19:27:15 <@salimma:fedora.im> this .. seems like something that should be solved internally at RH?
2025-03-27 19:27:27 <@yselkowitz:fedora.im> annoying that they're not fully compatible with each other though
2025-03-27 19:27:30 <@salimma:fedora.im> either fix the code to use the nc that's available or allow the nc that is needed in
2025-03-27 19:27:31 <@salimma:fedora.im> yeah
2025-03-27 19:27:40 <@conan_kudo:matrix.org> I am actually surprised the RHEL maintainers didn't chime in during the PR review upstream
2025-03-27 19:27:52 <@conan_kudo:matrix.org> they are supposed to be tracking this
2025-03-27 19:28:24 <@yselkowitz:fedora.im> well, here we are, we caught it
2025-03-27 19:28:52 <@sgallagh:fedora.im> Conan Kudo: It's pretty easy to miss that they aren't 100% compatible with one another.
2025-03-27 19:29:10 <@sgallagh:fedora.im> For most common actions, they are.
2025-03-27 19:30:07 <@conan_kudo:matrix.org> I guess I'll poke upstream and ask about this :/
2025-03-27 19:30:12 <@salimma:fedora.im> (aside: commented on the libxcrypt task. I can file an MR fixing the obsolete, which should be pinned to a version and not float since... *why*)
2025-03-27 19:30:22 <@yselkowitz:fedora.im> !action Yaakov to remind the RHEL maintainer
2025-03-27 19:30:57 <@yselkowitz:fedora.im> I would think the obsolete should not happen e.g. `%if 0%{?rhel} >= 11`
2025-03-27 19:31:19 <@yselkowitz:fedora.im> because they shouldn't be blocking EPEL from providing libxcrypt-compat
2025-03-27 19:31:32 <@yselkowitz:fedora.im> and RHEL major version upgrades don't rely on Provides/Obsoletes
2025-03-27 19:31:42 <@conan_kudo:matrix.org> the obsolete could be dropped entirely if it's been in place long enough
2025-03-27 19:31:44 <@salimma:fedora.im> that too. allow one release since it was obsoleted and no more
2025-03-27 19:31:56 <@salimma:fedora.im> oh right
2025-03-27 19:32:01 <@conan_kudo:matrix.org> obsoletes are only supposed to exist for 26 months
2025-03-27 19:32:07 <@salimma:fedora.im> anyway, I don't want to derail this
2025-03-27 19:32:16 <@salimma:fedora.im> wait... 26 months is very specific. how do we get there?
2025-03-27 19:32:26 <@salimma:fedora.im> oh Fedora
2025-03-27 19:32:29 <@conan_kudo:matrix.org> yup
2025-03-27 19:32:40 <@conan_kudo:matrix.org> the lifetimes for two fedora releases is 26 months
2025-03-27 19:32:56 <@conan_kudo:matrix.org> it actually is probably shorter due to overlapping lifecycles
2025-03-27 19:33:02 <@conan_kudo:matrix.org> but the maximum should be 26 months
2025-03-27 19:33:53 <@conan_kudo:matrix.org> that said, there has been some discussion about maintaining obsoletes for rhel upgrades to reduce the complexity of in-place upgrades
2025-03-27 19:34:05 <@conan_kudo:matrix.org> last I heard, no firm policy was in place for that yet
2025-03-27 19:34:28 <@yselkowitz:fedora.im> regardless I don't think it applies here though
2025-03-27 19:34:45 <@yselkowitz:fedora.im> anything further on those points?
2025-03-27 19:35:05 <@conan_kudo:matrix.org> yeah libxcrypt was introduced in f28
2025-03-27 19:35:38 <@conan_kudo:matrix.org> the compat library was introduced in f30
2025-03-27 19:35:49 <@conan_kudo:matrix.org> so now it's safe to drop across the board
2025-03-27 19:36:32 <@salimma:fedora.im> what matters is when the compat library was first dropped surely - looking at when it was first in Fedora does not really matter
2025-03-27 19:36:41 <@salimma:fedora.im> but anyway, we'll sort this out, no need to derail the meeting further
2025-03-27 19:37:26 <@salimma:fedora.im> oh... it's still in the fedora package so it's probably easier to fix right now
2025-03-27 19:37:39 <@conan_kudo:matrix.org> that's why I explained all this :)
2025-03-27 19:37:54 <@conan_kudo:matrix.org> it's easier to push a fix into rhel if it also applies to fedora
2025-03-27 19:38:41 <@yselkowitz:fedora.im> !topic Old business
2025-03-27 19:38:51 <@salimma:fedora.im> I mean, c11s does not exist yet so if we fix this in Fedora (and we have enough provenpackagers) c11s will inherit by defualt
2025-03-27 19:39:03 <@salimma:fedora.im> interesting timing
2025-03-27 19:39:43 <@yselkowitz:fedora.im> we're 2+ months since the F42 mass rebuild and I'm still running into packages which are F42FTBFS, so I'm not sure there are enough PPs...
2025-03-27 19:39:47 <@yselkowitz:fedora.im> but anyway...
2025-03-27 19:40:06 <@yselkowitz:fedora.im> !link https://github.com/fedora-eln/eln/issues/229
2025-03-27 19:40:35 <@yselkowitz:fedora.im> background: a different team is using ELN to start assigning packages for RHEL 11 already based on ELN
2025-03-27 19:40:39 <@salimma:fedora.im> speaking of myself this PP does not have enough time to fix other people's packages this cycle
2025-03-27 19:40:42 <@salimma:fedora.im> too many brokenness
2025-03-27 19:41:00 <@conan_kudo:matrix.org> same statement
2025-03-27 19:41:08 <@conan_kudo:matrix.org> I've been firefighting almost continuously since February
2025-03-27 19:41:37 <@yselkowitz:fedora.im> but they didn't understand to use CR, so they used the composes to try to determine ELN content
2025-03-27 19:42:00 <@yselkowitz:fedora.im> in the process they found some issues that were fixable, and some known issues
2025-03-27 19:42:02 <@salimma:fedora.im> is this just a documentation issue?
2025-03-27 19:42:04 <@salimma:fedora.im> or a training issue
2025-03-27 19:42:14 <@salimma:fedora.im> but if they find issues that's good I guess
2025-03-27 19:42:30 <@yselkowitz:fedora.im> yeah I'm working with them on it now
2025-03-27 19:43:09 <@yselkowitz:fedora.im> and while I'm happy to fix issues in the composes, that's not blocking ultimately because CR is the source of truth for ELN
2025-03-27 19:43:53 <@yselkowitz:fedora.im> our composes are in a bit better shape now, and more of them even pass repoclosure (a separate issue)
2025-03-27 19:43:57 <@yselkowitz:fedora.im> but HA is still a mess
2025-03-27 19:44:41 <@yselkowitz:fedora.im> because the bulk of HA is supposed to be placeholders, for packages which exist in Fedora but are built with vendored deps in RHEL (and therefore the specs are quite different)
2025-03-27 19:45:36 <@yselkowitz:fedora.im> if we actually needed the content then we'd use an eln branch, but since this is HA then the thought was placeholders would suffice
2025-03-27 19:45:50 <@salimma:fedora.im> oof, that's tricky
2025-03-27 19:46:01 <@yselkowitz:fedora.im> and while placeholders aren't normally supposed to be built, in this case they are because of ELN Extras
2025-03-27 19:46:13 <@salimma:fedora.im> seems like... seeding ELN with the package specs that would end up in EL11 is a good idea indeed
2025-03-27 19:46:23 <@salimma:fedora.im> can eln extras use HA? that seems odd
2025-03-27 19:46:34 <@yselkowitz:fedora.im> so in short, the packages are in HA but as they are in Fedora but not as in RHEL, and therefore there's a bunch of extra deps there
2025-03-27 19:46:41 <@salimma:fedora.im> or rather, should they be able to? I thought ELN Extras are meant for things that could end up in EPEL, and EPEL does not use HA
2025-03-27 19:47:03 <@yselkowitz:fedora.im> it doesn't affect the ELN package list but it does affect anyone *using* the ELN HA repo
2025-03-27 19:47:29 <@yselkowitz:fedora.im> so, first off, does anybody using ELN repos care?
2025-03-27 19:48:26 <@tdawson:fedora.im> Not I
2025-03-27 19:48:29 <@nhanlon:beeper.com> nor I
2025-03-27 19:48:36 <@nhanlon:beeper.com> (hi, super late, sorry)
2025-03-27 19:48:44 <@salimma:fedora.im> not really
2025-03-27 19:48:53 <@yselkowitz:fedora.im> but EPEL can have packages which are in HA, and that's what's happening here, and hence they're being built, but shipped in HA because that's how they are in RHEL
2025-03-27 19:49:01 <@yselkowitz:fedora.im> it's a weird corner case
2025-03-27 19:49:11 <@salimma:fedora.im> ah right
2025-03-27 19:49:15 <@salimma:fedora.im> so the leakage goes the other way
2025-03-27 19:49:48 <@davide:cavalca.name> This is going to happen for all the layered products 
2025-03-27 19:50:12 <@yselkowitz:fedora.im> well, not really
2025-03-27 19:50:19 <@davide:cavalca.name> Should we loop in whoever owns these on the RH side? Like, I personally don't care, but I assume they probably might?
2025-03-27 19:50:23 <@yselkowitz:fedora.im> assuming you mean RHEL addons such as HA
2025-03-27 19:50:33 <@davide:cavalca.name> Yeah, that's what I meant 
2025-03-27 19:51:04 <@yselkowitz:fedora.im> so SAP/SAPHANA are mostly RHEL-specific packages which are *not* in Fedora, and therefore the placeholders act as expected
2025-03-27 19:51:32 <@yselkowitz:fedora.im> but placeholders for packages which *are* in Fedora but very different in RHEL, well, those can end up getting built
2025-03-27 19:51:35 <@salimma:fedora.im> yeah. the issue is with packages that overlap with EPEL - this has been discussed in EPEL meetings too fwiw
2025-03-27 19:51:51 <@salimma:fedora.im> and the consensus is "since EPEL does not target HA if you enable both at the same time you get to keep both pieces"
2025-03-27 19:52:07 <@salimma:fedora.im> I'm sure Troy Dawson put it more delicately than I just did :/
2025-03-27 19:52:55 <@conan_kudo:matrix.org> but yeah, EPEL historically doesn't care about addons since they aren't generally available
2025-03-27 19:53:02 <@yselkowitz:fedora.im> 1. Maintain an eln branch (possibly based on c10s) of these (supposed) placeholder packages, and build those for ELN (and convert the placeholders to real packages)
2025-03-27 19:53:02 <@yselkowitz:fedora.im> so the possible "fixes" enumerated in the ticket are:
2025-03-27 19:53:02 <@yselkowitz:fedora.im> 3. OR leave the status quo as a known "issue" (there would at least be content in HA, and the package list in CR is correct, but it's confusing).
2025-03-27 19:53:02 <@yselkowitz:fedora.im> 2. OR exclude these packages from the HA compose, which wouldn't leave much left there (they would then move to ELN Extras, as they are listed there)
2025-03-27 19:53:26 <@tdawson:fedora.im> I believe I put it less delicately :)  but yes, you are correct in what you say.
2025-03-27 19:53:42 <@yselkowitz:fedora.im> (2) would essentially be the EPEL approach, kick them out of ELN HA and let them land in ELN Extras
2025-03-27 19:54:34 <@yselkowitz:fedora.im> or (3) we just don't care, and there's no issue with HA vs Extras because it's all one compose
2025-03-27 19:54:49 <@salimma:fedora.im> I lean towards 1) but the HA engineers at RH need to maintain them
2025-03-27 19:55:06 <@davide:cavalca.name> Yes, this
2025-03-27 19:55:10 <@salimma:fedora.im> but I would point out that with option 1) we have to make sure ELN Extras workload cannot inherit from them
2025-03-27 19:55:26 <@salimma:fedora.im> because... I don't want to accidentally have my dependencies resolved by HA - it won't be correct for EPEL
2025-03-27 19:55:39 <@tdawson:fedora.im> Although (1) would be the "best" thing to do ... I don't see the HA maintainers doing it.
2025-03-27 19:55:50 <@yselkowitz:fedora.im> well that's the other thing, since it's all one compose then you can't have the same package both ways
2025-03-27 19:56:02 <@conan_kudo:matrix.org> option 2 is probably the reasonable choice
2025-03-27 19:56:12 <@tdawson:fedora.im> I'm leaning towards (2) until someone actually comes to us and says they are using the HA repo and need the packages in there.
2025-03-27 19:56:33 <@salimma:fedora.im> without a way to isolate HA builds I think (2) is more realistic
2025-03-27 19:56:51 <@tdawson:fedora.im> I didn't even know we HAD a real HA repo in ELN.  I thought it was pretty much empty, like the other ones.
2025-03-27 19:57:23 <@yselkowitz:fedora.im> the more you know 😁
2025-03-27 19:57:39 <@salimma:fedora.im> oof, almost time
2025-03-27 19:57:52 <@yselkowitz:fedora.im> oh wow thanks for pointing that out
2025-03-27 19:58:10 <@davide:cavalca.name> I will reiterate that I think we should be having this conversation with the HA maintainers in RHEL
2025-03-27 19:59:15 <@salimma:fedora.im> quick follow up from last meeting - I just filed the PR tracking conda
2025-03-27 19:59:15 <@salimma:fedora.im> https://github.com/minimization/content-resolver-input/pull/1403
2025-03-27 19:59:15 <@salimma:fedora.im> 
2025-03-27 19:59:41 <@yselkowitz:fedora.im> ok we'll follow up next week
2025-03-27 19:59:45 <@yselkowitz:fedora.im> unless there's a conflict?
2025-03-27 20:00:13 <@tdawson:fedora.im> No conflict for me
2025-03-27 20:00:24 <@salimma:fedora.im> not that I know of for me
2025-03-27 20:00:34 <@yselkowitz:fedora.im> !info Next meeting on Thursday 03 April 15:00 EDT
2025-03-27 20:00:43 <@yselkowitz:fedora.im> timezones will be back in sync next week
2025-03-27 20:00:46 <@davide:cavalca.name> Should be fine
2025-03-27 20:00:50 <@salimma:fedora.im> oh right
2025-03-27 20:00:53 <@yselkowitz:fedora.im> and we're at time
2025-03-27 20:01:09 <@yselkowitz:fedora.im> thank you all for the lively discussions, see you in channel
2025-03-27 20:01:12 <@zodbot:fedora.im> salimma has already given cookies to yselkowitz during the F41 timeframe
2025-03-27 20:01:13 <@yselkowitz:fedora.im> !endmeeting