16:00:16 <jednorozec> #startmeeting RELENG (2022-03-01)
16:00:16 <zodbot> Meeting started Tue Mar  1 16:00:16 2022 UTC.
16:00:16 <zodbot> This meeting is logged and archived in a public location.
16:00:16 <zodbot> The chair is jednorozec. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:16 <zodbot> The meeting name has been set to 'releng_(2022-03-01)'
16:00:16 <jednorozec> #meetingname releng
16:00:16 <jednorozec> #chair nirik sharkcz pbrobinson pingou phsmoura mboddu dustymabe ksinny jednorozec
16:00:16 <jednorozec> #topic init process
16:00:16 <zodbot> The meeting name has been set to 'releng'
16:00:16 <zodbot> Current chairs: dustymabe jednorozec ksinny mboddu nirik pbrobinson phsmoura pingou sharkcz
16:00:28 <nirik> morning
16:00:34 <bittin> afternoon
16:02:35 <jednorozec> afternoon it is :)
16:03:12 <nirik> it's always morning somewhere. ;)
16:03:21 <jednorozec> right ;)
16:04:21 <jednorozec> so
16:04:34 <jednorozec> .releng 10663
16:04:35 <zodbot> jednorozec: Issue #10663: Clean, or Remove epel8-playground repo - releng - Pagure.io - https://pagure.io/releng/issue/10663
16:04:43 <jednorozec> how do I do this?
16:04:52 * mboddu is sorta here
16:05:37 <bittin> rm -R /epel8-playground vim mirrorlist.fedora ? no to be honest dunno :p
16:07:02 <nirik> jednorozec: repoint the latest link here https://kojipkgs.fedoraproject.org/compose/epel/ to an empty repo that has all the same repos as the existing playground repo
16:07:15 <nirik> or wait, we already deleted it from the sync
16:07:50 <bittin> seems to not have synced since 31th January 2022
16:08:08 <jednorozec> yeah we removed it
16:08:32 <nirik> so, yeah, I guess just delete it and sync in a empty repo and run the updatefilelist command
16:09:29 <nirik> jednorozec: make sense? or want me to do it? or ?
16:09:49 <jednorozec> I want to do it actually
16:10:21 <nirik> the update command should be: 'sudo -u ftpsync /usr/local/bin/update-fullfiletimelist -l /pub/fedora-secondary/update-fullfiletimelist.lock -t /pub epel'
16:10:41 <jednorozec> ok I have seen this on the machines
16:11:22 <mboddu> For sync in a empty repo, you can use one of the empty repos in /mnt/koji/composes/updates/
16:11:24 <nirik> you will need to run from one of the compose* machines (those have rw to the mirror volume)
16:12:06 <jednorozec> ack
16:12:42 <jednorozec> lets move to next thing
16:12:48 <jednorozec> .releng 10671
16:12:49 <zodbot> jednorozec: Issue #10671: fedora:37 image tag missing from Fedora Registry - releng - Pagure.io - https://pagure.io/releng/issue/10671
16:13:14 <jednorozec> So this is not a issue right it is just confusing
16:13:31 <jednorozec> becaus we provide f37-arch
16:13:48 <jednorozec> but f37 is actually rawhide
16:13:48 <nirik> yeah, I think so...
16:14:03 <jednorozec> so they expect f37 but should use rawhide
16:14:08 <nirik> I thought for a min it was related to container builds not working, but it's not. ;)
16:14:42 <jednorozec> My question is should we change something? and create f37 tag that will just point to rawhide until branching
16:14:56 <bittin> symlink?
16:15:17 <jednorozec> or just explain it better somewhere in docs?
16:16:07 <nirik> hum.
16:16:36 <nirik> the rawhide tag seems to be f36
16:17:00 <bittin> but thats now Branched hm
16:17:05 <nirik> ) skopeo inspect docker://registry.fedoraproject.org/fedora:rawhide | grep versio
16:17:05 <nirik> n
16:17:05 <nirik> "version": "36"
16:18:12 <nirik> I'd say we should make the f37 tag, as it's easier than trying to document...
16:18:21 <nirik> and we should fix rawhide to point to 37 :)
16:20:54 <jednorozec> huh
16:20:55 <jednorozec> https://pagure.io/releng/blob/main/f/scripts/sync-latest-container-base-image.sh
16:21:01 <mboddu> nirik: That version comes from - https://pagure.io/pungi-fedora/blob/main/f/fedora.conf#_340
16:21:07 <jednorozec> https://pagure.io/releng/blob/main/f/scripts/sync-latest-container-base-image.sh#_38
16:21:38 <mboddu> I wonder we didn't get a rawhide container image since we branched?
16:21:56 <nirik> possible. they have been failing. ;(
16:22:56 <mboddu> Thats not entirely true, we got one from last night https://koji.fedoraproject.org/koji/buildinfo?buildID=1926723
16:23:20 <nirik> * registry.fedoraproject.org/fedora:rawhide: image not known
16:23:30 <jednorozec> https://registry.fedoraproject.org/repo/fedora/tags/
16:23:33 <nirik> there's errors you can see in the latest crons
16:24:15 <mboddu> Yeah, I am looking at them
16:24:40 <nirik> ha, some of them are armv7 images...
16:24:51 <nirik> we need to apparently clean that up from dropping it.
16:25:26 <jednorozec> so that was another thing
16:25:26 <leothecat> .hello leo
16:25:27 <zodbot> leothecat: leo 'Leo Puvilland' <leo@craftcat.dev>
16:25:35 <VipulSiddharth[m> .hello siddharthvipul1
16:25:36 <zodbot> VipulSiddharth[m: siddharthvipul1 'Vipul Siddharth' <siddharthvipul1@gmail.com>
16:25:44 <jednorozec> what about having only active releases + rawhide there?
16:26:22 <nirik> where? on registry.fedoraproject.org ?
16:26:31 <mboddu> https://pagure.io/releng/blob/main/f/scripts/sync-latest-container-base-image.sh#_33 should be fixed to remove armhfp
16:26:44 <jednorozec> nirik, yes
16:26:52 <mboddu> ^^ for f37 or higher
16:26:55 <nirik> https://pagure.io/releng/issue/10658 is the ticket on container builds not working. I guess it's just layered ones.
16:27:11 <mboddu> And then also remove any refs armhfp in https://pagure.io/pungi-fedora/blob/main/f/fedora.conf
16:27:20 <nirik> jednorozec: thats pretty rude and not what we have done in the past. I don't think we should do that without a lot of noise...
16:27:44 <nirik> ie, someone has a build that pulls f33 image or whatever... if we remove it, it breaks their build.
16:27:58 <nirik> or if someone wants to look at fedora 30 image to track a bug down.
16:27:58 <jednorozec> nirik, ok but f30?
16:28:13 <jednorozec> hmm
16:28:15 <jednorozec> ok
16:28:33 <nirik> we also don't nuke the repos (just move them to archive)...
16:28:50 <jednorozec> yes and user has to change yum.repo to use it
16:28:58 <nirik> no?
16:29:24 <jednorozec> wait, If I just download and install f28 lets say it will point to archive?
16:29:40 <jednorozec> everything will just work?
16:29:51 <nirik> yes. mirrormanager points them to archive.
16:29:54 <nirik> but it's all working
16:30:05 <nirik> curl "https://mirrors.fedoraproject.org/metalink?repo=fedora-30&arch=x86_64"
16:30:14 <jednorozec> so I have it confused with centos
16:30:55 <nirik> yeah, on the centos side they disable them entirely after eol...
16:31:11 <nirik> perhaps we could too, but it would be a change...
16:31:22 <jednorozec> yeah
16:31:37 <nirik> anyhow, we should fix the container stuff...
16:31:56 <jednorozec> yeah so we will create f37 tag with rawhide content.
16:32:06 <jednorozec> THis will require minor changes
16:33:01 <mboddu> jednorozec: https://pagure.io/releng/pull-request/10677 should fix it
16:33:05 <jednorozec> some doc change to mention this in branching doc
16:33:11 <mboddu> +1's please
16:34:00 <mboddu> ^^ we already have that change listed in the docs, but now we need to update the script couple more places, thats all
16:34:21 <mboddu> Once thats merged, I will run the script manually once
16:34:58 <nirik> that fixes the arm thing, but not the f37 label ?
16:35:11 <jednorozec> right
16:35:39 <nirik> so, +1 to fix that anyhow. ;)
16:36:23 <mboddu> I guess once the push finally completes, it will create the f37 tag
16:36:25 <mboddu> I can check
16:36:58 <jednorozec> so should I merge it
16:37:09 <jednorozec> when on it mobrien opened PR yesterday to the same script
16:37:17 <nirik> anyhow, we don't need to solve this now, but we should fix it. ;)
16:37:19 <jednorozec> https://pagure.io/releng/pull-request/10674
16:37:45 <jednorozec> yeah, I got my question answered we will create the tag and point it to the rawhide
16:37:57 <nirik> oh, I wonder...
16:38:54 <nirik> oh, nevermind.
16:39:20 <mboddu> nirik: Yup, I was right and 37 tag is created
16:39:37 <mboddu> $ skopeo inspect docker://registry.fedoraproject.org/fedora:rawhide | grep 37                2067ms  Tue 01 Mar 2022 04:36:30 PM UTC
16:39:37 <mboddu> "37-aarch64",
16:39:37 <mboddu> "37-ppc64le",
16:39:37 <mboddu> "37-s390x",
16:39:37 <mboddu> "37-x86_64",
16:39:39 <mboddu> "37"
16:39:41 <mboddu> "version": "37"
16:39:43 <mboddu> "sha256:46de948267ebdcbee851d3c844899cb5f9c372526c0aabae44fdc756fd5ff773"
16:39:45 <mboddu> "DISTTAG=f37container",
16:39:47 <mboddu> "FGC=f37",
16:39:49 <nirik> so it wasn't because the script was erroring on arm?
16:40:01 <mboddu> It is because of the script erroring on arm
16:40:19 <mboddu> I merged my PR, ran a manual sync and thats it
16:41:24 <mboddu> Hope I am making sense
16:41:28 <jednorozec> hm
16:41:34 <jednorozec> but the UI didnt pick it up
16:41:59 <mboddu> IIRC, UI runs as a cron to update...
16:42:03 <nirik> thats on a cron
16:42:06 <jednorozec> ok
16:42:08 <nirik> yeah, hourly?
16:42:16 <mboddu> Yeah, something like that
16:42:28 <jednorozec> mboddu, will you post the skopeo output in the ticket please?
16:42:32 <mboddu> Sure
16:42:38 <mboddu> And will close the ticket
16:42:51 <jednorozec> thank you very much
16:43:24 <jednorozec> .releng 10666
16:43:25 <zodbot> jednorozec: Issue #10666: PackageKit-gtk3-module i686 missing from x86_64 repos - releng - Pagure.io - https://pagure.io/releng/issue/10666
16:43:29 <nirik> thanks everyone
16:44:57 <nirik> so, we can add it I guess... but...
16:44:57 <jednorozec> so I am confused
16:45:24 <jednorozec> is this missing from repos or missing from multilib?
16:45:56 <mboddu> nirik: but what? We can add it to https://pagure.io/pungi-fedora/blob/main/f/fedora.conf#_215 and for f36 branch and also for bodhi pungi configs
16:46:09 <nirik> multilib...
16:46:33 <mboddu> As long as we support i686 we have to support multilib
16:46:35 <nirik> I am confused as to a) why it's needed on multilib systems ,and b) why can't packagekit adjust to make it multilib
16:47:30 <mboddu> I am not sure of a) but for b), even if they make it, we have to allowlist it right?
16:48:04 <nirik> no. pungi already automatically does multilib based on some rules.
16:48:19 <mboddu> ^ I am not aware of that
16:48:21 <nirik> the whitelist is just overriding that and including something that doesn't match the rules.
16:49:05 <mboddu> Maybe thats what happening and we need to add it to whitelist?
16:49:31 <nirik> well, apparently it was multilib a while back, so likely something changed in the packaging.
16:49:34 <jednorozec> so they opened PRs
16:49:35 <jednorozec> https://src.fedoraproject.org/rpms/PackageKit/pull-request/7
16:51:53 <nirik> oh yeah, fake -devel package... fun
16:53:23 <nirik> so, meh, I guess we can add it to pungi... I just hate to do that...
16:53:36 <nirik> also sounds like theres anyother subpackage that should be there (based on the pr's)
16:54:07 <mboddu> Yeah, its a pain
16:54:39 <nirik> ah ha
16:55:08 <nirik> I think this is a python-multilib bug
16:55:37 <nirik> it handles gtk2 but not gtk3 modules
16:55:50 <jednorozec> hm
16:56:00 <mboddu> Ahhh good catch nirik
16:57:48 <nirik> I can update the bug.
16:57:53 <nirik> ticket. both. whatever
16:57:59 <jednorozec> thnaks
16:58:41 <jednorozec> so your are right nirik gtk2-modules is mentioned in multilib.py
16:59:08 <jednorozec> #topic Open Floor
17:00:30 <nirik> should we file a bug on that? or leave it to reporters?
17:00:38 <nirik> .whoowns python-multilib
17:00:39 <zodbot> nirik: owner: jgreguske; admin: lsedlar
17:01:24 <jednorozec> nirik, I am looking into it and will open PR to multilib
17:02:24 <nirik> jednorozec++
17:04:38 <jednorozec> #endmeeting