Meeting started at 2025-07-16 15:25:10 UTC

The Meeting name is 'CentOS Hyperscale SIG'

morning folks, apologies for the late start

!hi

!hi

Gabriele Mambrini (gmambro) - he / him / his

!hi

Neal Gompa (ngompa) - he / him / his

let's get started

I think we now have the bulk of our packages on gitlab

we should probably go over what's left on git.centos.org and finish moving them over

also infra has a working exported for pagure, so we can consider moving the repos on pagure.io if we want to now

though I don't think there's any rush there

also infra has a working exporter for pagure, so we can consider moving the repos on pagure.io if we want to now

anybody else has followups?

from me, mostly that I've been holding off on rebasing to 6.15 because of reports of a btrfs bug in upstream and fedora

do we know if this has been resolved yet?

remind me what the bug is?

it's the random corruption bug that has been discussed in the the Fedora Btrfs matrix room and Fedora discourse

one example: https://discussion.fedoraproject.org/t/157232

upstream report: https://lore.kernel.org/linux-btrfs/283624a8-dc79-4dd0-b6e5-9d5e83e31648@gmx.com/T/#t

ok will follow up on that

upstream report: https://lore.kernel.org/linux-btrfs/fce139db-4458-4788-bb97-c29acf6cb1df@cachyos.org/

awesome thanks

this has also held back the Asahi rebases too, because I *really* don't know what's going on here

that's it for me

moving on

!hi

Michel Lind (salimma) - he / him / his

we can now build SIG content from gitlab in copr

I've started playing with this to rebuild a subset of our packages for ELN in https://copr.fedorainfracloud.org/coprs/g/centoshyperscale/eln-main

automated rebuilds don't work yet, I filed an issue for those: https://github.com/fedora-copr/copr/issues/3789

also I think there's a bug somewhere in the build chain (possibly in mock) where it builds the src.rpm _before_ the chroot is populated, resulting in the wrong macros being used

only in COPR right?

woops

this is a problem e.g. for systemd where we have conditional patches, leading to https://copr.fedorainfracloud.org/coprs/g/centoshyperscale/eln-facebook/build/9277399/ failing

I haven't tried reproing this outside of COPR

also we'll be speaking at centos showcase and fossy later this month

```

Bad file: /builddir/build/SOURCES/FB_only_bump_netlink_timeout_to_infinity.patch: No such file or directory

Bad file: /builddir/build/SOURCES/0001-pam_systemd-Make-pam_systemd-256-backwards-compatibl.patch: No such file or directory

```

this looks like incorrect packaging anyway IMHO

the best practice is to always ship all sources and patches, but only conditionally apply them

these are gated by the facebook macro

so the srpm is identical and can be built even if the macros change

I know conditional sources are bad, but it's tricky to do conditional application when using autopatch

yeah... I have been fixing some packages like this to avoid this issue

you can with ranged patches

unless one lists all the patches one by one, which is a pain to maintain

I can help with this if needed

oh yeah that'd be great, thanks

just have ranges e.g. 1000-2000 == facebook

fwiw, this is why I use ranges for backports, proposed changes, and downstream only ones

https://gitlab.com/CentOS/Hyperscale/rpms/systemd/-/blob/c10s-sig-hyperscale/systemd.spec

this is sadly not very well documented, but yeah it's a great feature. I normally just cheat and look at existing specs

I think the only exceptional patch where I've done it differently is in btrfs-progs

because btrfs-progs has to build on systems without the feature

next topic?

anybody else has announcements?

oh right we have the hangout later today

feel free to join us there

oh actually, I'm not sure

I have it on my calendar, but it's not on the fedora calendar

we do

https://calendar.fedoraproject.org/list/centos-sig-hyperscale/

fedocal does this thing where 1 month = 28 days

it doesn't send the ics monthly thing

so it drifts and I need to fix it periodically

yeah, it does not do "nth week of the month" sadly

I think EPEL folks were grouching about this in a recent meeting too

(surely someone just need to implement the logic once in a Python module and everyone can reuse it...)

yeah

we're running out of time

going to jump directly to

for folks to bring up any closing words

we should rename that to open floor

yeah