16:00:13 #startmeeting RELENG (2023-05-23) 16:00:13 Meeting started Tue May 23 16:00:13 2023 UTC. 16:00:13 This meeting is logged and archived in a public location. 16:00:13 The chair is jednorozec. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 16:00:13 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:13 The meeting name has been set to 'releng_(2023-05-23)' 16:00:13 #meetingname releng 16:00:13 #chair nirik sharkcz pbrobinson phsmoura dustymabe jednorozec 16:00:13 The meeting name has been set to 'releng' 16:00:13 Current chairs: dustymabe jednorozec nirik pbrobinson phsmoura sharkcz 16:00:13 #topic init process 16:01:13 morning. 16:02:01 evening 16:02:42 hello 16:03:52 I dont have much for today meeting 16:03:55 but 16:03:59 .releng 11431 16:04:00 jednorozec: Issue #11431: On new package repository creation add a gitignore with *.src.rpm - releng - Pagure.io - https://pagure.io/releng/issue/11431 16:04:11 I see there are some comments from today 16:04:30 I had a few, can go after yours. ;) 16:04:44 so do we want to do that? 16:04:51 so yeah, Im not sure where that is initally setup? 16:04:58 since fedpkg is supported way of doing things 16:06:37 I guess the toddler sets up new repos and would be the place to add it? but then it would be a commit right? or can it be done as part of the setup? 16:06:56 I mean, if it's easy to do it seems good... but I''m not sure it's going to be easy to do. 16:07:25 I dont think it is that easy 16:07:44 Hello folks! 16:07:58 hum, might be it could be added to a template dir for new repos 16:07:59 so as you saind easiest way is to put it in the toddler but that is a nogo since there are usecases that require no commits 16:08:50 nirik, any docs at hand on how? 16:09:19 I'm looking at git man pages. :) Not clear so far. 16:09:36 so we are on the same docs :D 16:09:40 so, this would be a good case for why we might want to ask devel about it... lots of smart people there might see a way to do it. 16:10:02 yup that is the comments from today 16:10:20 let me add one suggesting that as-well 16:11:11 sure, you want to post about it? or try and get the reporter to? 16:11:25 I will try them to do that if not I will 16:11:54 it looks like there might be a config option we could set that reads excludes from a file... and then have a global file... 16:12:20 but then we would have to touch all repos. ;( 16:12:38 yeah 16:12:41 anyhow, yeah, needs more investigation/discussion... 16:12:53 also, we could exclude more than *.src.rpm 16:12:59 that was the only one from me 16:13:05 (like *.tar.gz *.tar.bz2 *.tar.xz, etc) 16:13:58 but also 'fedpkg upload/new-sources' modifies a local .gitignore... so we would have to handle that. 16:14:00 anyhow, ok... 16:14:25 .releng 11385 16:14:27 nirik: Issue #11385: Silverblue aarch64 installer image compose always fails on F38 and Rawhide - releng - Pagure.io - https://pagure.io/releng/issue/11385 16:14:49 so, f38 GA doesn't have a silverblue aarch64 install iso. 16:14:57 it didn't compose at the time. 16:15:12 But there's desire to make one or the like. 16:15:31 We have done this before for spins, not sure its as easy for ostree installers, but perhaps? 16:16:30 any objection to doing that? ie, makeing a silverblie aarch64 install iso and putting it somewhere for folks that need it? or should we just tell them to wait for f39 and use f37 for now? 16:16:30 hmm 16:16:42 nope lets do that 16:16:55 I think we did that for 37 and some spins 16:16:57 I think we basically would just need to find the GA failed one and redo it with similar/same config. 16:17:05 yeah. 16:17:21 do you want me to do that? 16:17:39 I think we put them in a releases/unofficial dir... which was confusingly named, but yeah 16:18:07 let me check the docs if we have any 16:18:38 yeah, if you could that would be great. 16:18:40 docs? ha. 16:18:53 https://dl.fedoraproject.org/pub/alt/unofficial/releases/ 16:18:55 naive me 16:19:13 that might need some cleanup 16:19:40 possibly so yes. The name confuses people too... but I am not sure what a better one would be off hand. 16:20:04 nah naming problem is a real thing 16:20:07 anyhow, if you could do that that would be great. Happy to help... 16:20:17 yup I have assigned that ticket 16:21:17 I know I had one more... looking for it. 16:21:34 whats the status on the h264 stuff? off to cisco? 16:21:57 can we close 11358 now? 16:21:58 yup 16:22:01 its out 16:22:05 to cisco 16:22:07 .releng 11358 16:22:08 nirik: Issue #11358: Sync RCs to alt/stg dl.fp.o - releng - Pagure.io - https://pagure.io/releng/issue/11358 16:22:13 I will close it once confirmed by them 16:22:37 yup 16:22:37 there is a PR by patrikp[m] 16:22:46 not sure about the state of it 16:23:16 I asked him to extend it with one more thing 16:23:17 ah yeah, I thought it was merged, perhaps not yet. 16:23:41 this one 16:23:47 .releng 7337 16:23:48 jednorozec: Issue #7337: Emit fedmsg when candidate composes are synced to stage - releng - Pagure.io - https://pagure.io/releng/issue/7337 16:24:14 ok. cool. 16:24:15 with that we can automate the sync to RH internal mirrors 16:24:29 and I have one less thing to forget about! 16:24:48 excellent! 16:26:26 I can't recall the other thing I had... oh well. 16:26:42 should we triage tickets? or any other topics? 16:26:51 oh 16:27:00 compose-tracker is updated in staging 16:27:13 if it works ok I will update the prod tmrw 16:28:06 sounds great. 16:28:08 #topic ticket triage 16:28:13 https://pagure.io/releng/issues?status=Open&order_key=last_updated&order=asc 16:28:45 this one 16:28:48 .releng 9841 16:28:49 jednorozec: Issue #9841: Provide a way to differentiate Beta vs RC compose in .composeinfo file - releng - Pagure.io - https://pagure.io/releng/issue/9841 16:28:54 related to internal sync 16:29:12 so we missed .composeinfo file in some of the RC composes 16:29:33 and nothing happened, it seems that its just a legacy thing 16:30:04 not sure on this one... 16:30:13 so if we do the change to the script that generates it it might not do any harm 16:30:37 after some internal discussions I understand why thay need it 16:30:53 it is a pain to import it into pxe 16:31:17 do we even publish that composeinfo? I guess we take it from pungi and tweak it? 16:31:33 we publish the composeinfo.json 16:31:39 and that is all the same information 16:31:42 +more 16:31:46 in json format 16:32:06 I think that is used by other stuff 16:32:46 I don't think we publish that either do we? 16:33:09 https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/compose/metadata/composeinfo.json 16:33:13 the problem is that we compose a full compose and then split it out to fedora and fedora-secondary and it's all now lies in the compose info. ;) 16:33:27 ahhhh 16:33:34 well yeah, there, but when we sync it to main mirrors we don't copy that 16:34:02 probably not 16:34:36 previously I dint think of this request as usefull 16:34:52 so, I guess perhaps we should ask them if this is still the case? 16:34:59 it is 16:35:12 I talked to mike about a month ago 16:35:14 ok. hum... 16:35:20 pungi generates that composeinfo? 16:35:26 and actually I am doing it manually with each RC sync to internal mirrors 16:35:40 I just edit it there 16:35:57 I think we do that 16:36:23 https://pagure.io/releng/blob/main/f/scripts/build_composeinfo 16:36:39 maybe I am mistaken but that is something i seen in the logs 16:37:12 ok. I don't understand the flow. ;) 16:37:51 you run that script and then copy that to internal? 16:38:16 nope, output of that script is part of the compose data 16:38:24 that is the .composeinfo 16:38:46 I just replace the name 16:40:24 https://pagure.io/pungi-fedora/blob/main/f/nightly.sh#_153 16:40:30 yeah, so in nightly.sh we replace... 16:40:31 so yeah its that script 16:40:31 yeah. 16:40:56 so is that in order to fix it for our wacky splitting? 16:41:03 should we just try it for one nightly see what breaks? 16:41:40 hmm 16:41:42 I see 16:41:52 So: pungi writes it out, we then delete it and make a new one with our script and sync that out right? 16:41:52 so we split it and build the composeinfo for each dir 16:42:05 yes it seems that way 16:42:30 I'm not sure how to add what they want tho 16:43:17 I mean say we make a RC-1.1 for Beta. Then we make a RC-1.2 and its the one we ship... 16:43:43 if we marked it 'RC-1.1" somewhere in composeinfo wouldn't that just break assumptions that it's the exact thing we ship 16:44:01 and wouldn't RC-1.2 == Beta, so how do you tell those apart? I mean, it's the same, but... 16:44:35 I guess if this is the only thing using the composeinfo... 16:45:04 there might be some QA stuff there was another ticket 16:45:18 adam commented and was not opposed, we might break things 16:45:49 but when is better time to break things that between releases? 16:45:52 this sounds to me like something better adjusted on the other end. ;) 16:46:03 uff 16:46:05 I tried 16:46:09 ie, can't their system call it 'Fedora-33-YYYYMMDD' or something? 16:46:28 but the controllers code that does the PXE magick is just to much perl for me 16:46:36 😭 16:46:42 Fedora-XX-YYYYMMDDNN 16:46:49 hmmm 16:47:16 what if composeinfo had that in there for them to feed off of it? 16:47:25 so, are they using the .composeinfo on our master mirrors? or from their local synced mirror? 16:47:36 or does it already (and soerry for walking in and spouting something stupid ) 16:47:39 from their 16:48:06 so, we could perhaps modify it when we sync it? so their local copy gets something else? but thats kinda bad too... 16:48:25 that is kind of what ido now 16:48:30 I skip the file 16:48:42 update it and put it in place 16:49:00 the perl magick picks the new file and starts the import 16:49:07 smooge: yeah, so like from the last rc for f38 we have: 16:49:10 [product] 16:49:10 family = Fedora 16:49:10 name = Fedora-38 16:49:10 version = 38 16:49:21 but if we change those it's a lile... 16:49:35 well I was thinking something like 16:49:46 date = YYMMDD 16:49:53 build = NN 16:50:07 a release candidate should be the exact thing we release if it passes. We should not say it's something else. ;) 16:50:19 right 16:50:29 sure, we could, but it's not really. I am not sure if that will break other consumers (if any) of this 16:51:01 so the only other consumer I remember I think was something in the website? 16:51:22 i think that was the file they were basing some stuff out of 16:51:26 I don;t think it uses it anymore... 16:51:31 ah ok 16:51:45 but we have no idea. It's been something we publish on the master mirrors. Any joe could use it. ;) 16:51:55 the info they were wanting was similar in that they needed to know if there were multiple builds 16:52:07 yup 16:52:19 but yeah. I expect we break MIT or CERN by adding stuff without some sort of RFC 16:52:30 perhaps we could just script the sync to internal? ie, have it tweak the file and sync it? At least that would save some time? 16:52:32 the problem is that RC-1.1 and 1.2 and 1.2 do not differ in the composeinfo 16:52:42 nirik, yes 16:52:53 that is probably the best way to handle it now 16:52:58 right. it's too generic of a config. 16:53:47 ok, let me close it that and once we get messages emitted by RC composes we will drop the whole sync thing to internal people 16:53:51 there is a json version that has more info 16:54:25 they will use the same automations they use now for syncing rawhide 16:54:38 https://kojipkgs.fedoraproject.org/compose/38/Fedora-38-20230413.1/compose/metadata/composeinfo.json 16:54:53 but it's not something we have shipped because of the split 16:55:07 ie, you can see there that this was 'RC-1.6' 16:55:14 yup 16:55:29 that is why I was confused why they want it 16:55:34 but yeah, pile of perl to change that... and I bet they have no development cycles. 16:55:48 well, we don't sync/publish that json... 16:55:57 (that I know of) 16:56:38 yup its legacy thing maintained by one person I think... 16:56:53 running in every office around the world... 16:57:11 anyhow we are near the dedicated meeting time 16:57:21 #open floor 16:57:25 #topic open floor 16:58:15 I don't think I had anything more. Oh, you still have on your list the toolbx container add to fedora-pungi and the odcs stuff right? 16:58:43 yes 16:58:54 I was looking into the toolbox thing 16:58:57 cool. ;) never a dull minutes. 17:01:34 #endmeeting