15:02:13 <mboddu> #startmeeting RELENG (2020-10-27) 15:02:13 <zodbot> Meeting started Tue Oct 27 15:02:13 2020 UTC. 15:02:13 <zodbot> This meeting is logged and archived in a public location. 15:02:13 <zodbot> The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:02:13 <zodbot> The meeting name has been set to 'releng_(2020-10-27)' 15:02:13 <mboddu> #meetingname releng 15:02:13 <zodbot> The meeting name has been set to 'releng' 15:02:13 <mboddu> #chair nirik sharkcz pbrobinson pingou mboddu dustymabe ksinny jednorozec 15:02:13 <mboddu> #topic init process 15:02:13 <zodbot> Current chairs: dustymabe jednorozec ksinny mboddu nirik pbrobinson pingou sharkcz 15:02:19 <nirik> morning 15:02:29 <jednorozec> afternoon 15:02:36 <sharkcz> hi all 15:03:38 <mboddu> So, I have to cut short this meeting to 30 min as I have another meeting to attend 15:03:41 <mboddu> Lets get started 15:07:34 * nirik waits for it. ;) 15:09:11 <pingou> รณ/ 15:09:36 <mboddu> Sorry, my network got crashed while the system is being updated 15:09:38 * mboddu joined in another laptop 15:09:40 <mboddu> I dont know how much you guys have seen, but this meeting will be short due to another meeting in 20 min 15:09:43 <mboddu> pingou: Problems with rawhide :D 15:10:04 <pingou> on the top of iot? 15:10:31 <mboddu> iot? 15:10:49 <nirik> which rawhide problem? ;) 15:11:16 * pingou marks problems has solved 15:11:21 <pingou> there :) 15:11:56 <mboddu> Okay... :) 15:12:00 <mboddu> #topic #9821 Consider issues with a point release 15:12:09 <mboddu> #link https://pagure.io/releng/issue/9821 15:12:17 <mboddu> So... 15:12:44 <nirik> yeah, there seems to be 2 ways to do this... 15:12:45 <mboddu> We could a RC 1.3 and just do the sync as a normal release 15:12:52 <nirik> and they each cause problems 15:13:08 <mboddu> nirik: Go for it 15:13:55 <nirik> if we call it f34, it means we have to do branching/koji tags/etc... all really quickly. 15:14:18 <nirik> if we call it just f33 it's going to confuse people since we already released 33. 15:14:47 <nirik> 33.1 will break fedfind and bodhi and such... 15:15:18 <mboddu> Why would it confuse people? We release another rc and no one will notice it and just tell people we updated the images 15:15:19 <nirik> not sure what is best here. 15:15:28 <mboddu> No changes to links and everything works as well 15:15:32 <mboddu> as usual* 15:15:34 <nirik> if we are only doing images 15:16:04 <nirik> pxe will still be broken in that case. 15:16:20 <mboddu> How does pxe work? 15:16:57 <nirik> dhcp gives you a server and you download a kernel and initramfs from it, you boot and pull the installer image over to install. 15:18:17 <mboddu> Where does it pull the content from? 15:18:19 <nirik> so if we want that fixed also we should just sync the entire new compose over the old one... (with hardlinks) 15:18:33 <mboddu> Yes, which is what I am suggesting 15:18:40 <nirik> admin gets the vmlinuz/initramfs from us and puts it on their server. 15:19:17 <nirik> https://dl.fedoraproject.org/pub/fedora/linux/releases/33/Everything/x86_64/os/images/pxeboot/ 15:19:42 <nirik> but perhaps we decide thats not a big deal... I guess we need to decide the scope here. 15:20:00 <nirik> perhaps it's just x86_64 bootable images? 15:20:07 <mboddu> Yes, they are getting it from our mirrors, so I am suggesting full sync of the compose 15:20:45 <nirik> right, thats going to cause confusion, but might be the way to go 15:21:08 <mboddu> I feel like syncing bit and pieces might cause more confusion than everything 15:21:43 <mboddu> We just say, "Hey, we did a new compose for f33 which fixes the bootloader issue and they are just available at normal f33 downlodable locations" 15:21:48 <nirik> well, alternately if we just make x86_64 bootable media and pxe stuff we could put it in a 33.1/ dir, but that would break fedfind and similar. 15:21:48 <mboddu> But better worded :D 15:21:52 <sharkcz> can we limit the rc 1.3 to x86_64 only? I would like to avoid dropping some of the other (non-blocking) artifacts 15:22:03 <sharkcz> in case something fails 15:22:17 <nirik> the problem is the same as when an upstream re-releases something... 15:22:38 <mboddu> sharkcz: We already locked f33 tag, so nothing will be coming into it, we will just add shim to it and run a compose 15:22:47 <nirik> "I have this bug in f33!" "which f33?" "my f33 checksums no longer match but gpg says the checksum file is right" 15:23:12 <mboddu> Yeah, we need to be very vocal about it 15:23:13 <nirik> its really bad release engineering to release the same thing twice. 15:24:21 <mboddu> "Which f33?" issue will arise if we sync full compose or few images, to avoid that, we need to put it in a different dir and call it .1 release 15:24:30 <nirik> yep. 15:24:53 <nirik> so, perhaps I could add a list of questions to the ticket and we can try and see if we can get answers 15:25:01 <nirik> and that might help us decide which way to go? 15:25:08 <mboddu> And admins should know which images to pull for pxeboot and fedfind..., dont know? 15:25:18 <mboddu> +1 15:25:43 <pingou> hm, where is bodhi involved in the compose/release? 15:26:19 <nirik> well, thats another point of confusion... 15:26:30 <nirik> "hey shim says it's in updates, but it's in the base repo" 15:26:46 <nirik> and if we do a 33.1... "where is 33.1 in bodhi?" 15:27:37 * mboddu is back on multi monitor 15:27:39 <mboddu> Yeah, we could just tag it into f33? 15:27:47 <pingou> I'm more tempted by 33.1, but I don't quite understand why we care about bodhi for this 15:28:31 <mboddu> More like, base repo will have new shim where as according to bodhi, it will be in updates repo 15:29:31 <mboddu> Or just use https://dl.fedoraproject.org/pub/alt/unofficial/releases/ ? 15:29:32 <pingou> I like that problem more than the: checksums for F33 no longer match 15:30:54 <nirik> mboddu: which just looks bad... 15:31:17 <nirik> "In order to boot your computer with secure boot, please use this unofficial image..." 15:31:22 <mboddu> checksums matching is more like a problem if the users are in the dark, they downloaded 1.2 when we synced 1.3 their checksums will not match, but they can download 1.3 and match them again 15:31:38 <mboddu> nirik: Right 15:31:51 <mboddu> I understand, but throwing out the options 15:32:09 <nirik> yeah, we are gonna need to pick the 'least bad' 15:32:53 <pingou> +1 15:33:02 <sharkcz> +1 15:33:04 <mboddu> I feel like, run rc 1.3 and sync it to current releases/33 dirs 15:33:16 <pingou> mboddu: or they have the checksum from a previous download (for some reasons) 15:33:23 <mboddu> Seems like the least problamatic 15:33:41 <mboddu> pingou: Yeah, that too ;) 15:34:17 <pingou> for the new shim in base vs updates, how often do people check the content of the repo themselves? 15:34:19 <pingou> :) 15:35:32 <mboddu> Not much, but if they do, they will be confused 15:35:48 <pingou> so same for the checksums 15:36:05 <pingou> while checksums are more end-users and repo more power-users 15:36:36 <pingou> I do like nirik's idea to ask questions on the ticket and see from the response which way we go 15:37:18 <pingou> (we don't have the fix yet anyway right? so we don't need to answer it now, right?) 15:37:39 <nirik> yes, there is not a fix yet 15:37:50 <nirik> but we might also have to do arm images for another thing 15:38:11 <pingou> 2020 is soo much fun!! 15:38:53 <nirik> you bet 15:39:53 <mboddu> It is 15:39:57 <mboddu> Anyway, I need to run 15:40:24 <mboddu> Thanks nirik for offering to updating the ticket 15:40:29 <mboddu> I will comment on the ticket as well 15:40:38 <mboddu> Thanks everyone for joining 15:40:47 <mboddu> And sorry for all my rawhide problems 15:40:50 <pingou> thanks for chairing :) 15:40:58 <mboddu> Now its crashing both chromium and FF 15:41:12 <pingou> "this is probably fine" 15:41:18 <nirik> firefox is known. 15:41:23 <nirik> downgrade to -3 15:41:32 <mboddu> Yeah, I will try downgrading both 15:41:56 <nirik> or -2 15:41:58 <mboddu> #endmeeting