16:06:08 #startmeeting RELENG (2019-06-20) 16:06:08 Meeting started Wed Jun 19 16:06:08 2019 UTC. 16:06:08 This meeting is logged and archived in a public location. 16:06:08 The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:06:08 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:06:08 The meeting name has been set to 'releng_(2019-06-20)' 16:06:08 #meetingname releng 16:06:08 The meeting name has been set to 'releng' 16:06:08 #chair nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu dustymabe ksinny jednorozec 16:06:08 #topic init process 16:06:08 Current chairs: dustymabe jednorozec ksinny masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll 16:06:59 .hello2 16:07:00 dustymabe: dustymabe 'Dusty Mabe' 16:07:10 * dustymabe waves at mboddu 16:07:14 Hello dustymabe 16:07:49 mboddu: i don't have anything for today - just saying hey 16:08:26 * sharkcz is here to say hello at least :-) 16:08:32 .hello2 16:08:33 bcotton: bcotton 'Ben Cotton' 16:09:18 Since sharkcz is here, lets check on alt arches 16:09:23 * nirik had this down later or something... 16:09:24 morning 16:09:28 #topic Alternate Architecture Updates 16:10:10 #info nirik is still blocked on s390x moving to KVM 16:10:13 things should be looking pretty good, but we still wait on the builder migration under kvm 16:10:19 sharkcz: ^ anythign else other than that? 16:10:26 nope 16:10:31 Thanks sharkcz 16:10:47 #info Everything is looking good other than kvm migration 16:11:49 #topic #8080 rsync temporaries under /alt/risc-v 16:11:55 #link https://pagure.io/releng/issue/8080 16:12:12 nirik: ^ I know you were working on it? Can you share some light on what it is? 16:12:31 * mboddu has no clue about it 16:12:48 I have no idea... thats the risc-v secondary arch folks syncing their data... 16:12:53 we have to ask them how they do it. 16:13:21 I guess ask if anyone has seen it still, or if it's solved? 16:13:42 nirik: Okay, I will ping in the ticket 16:14:09 #action mboddu will ping in the ticket to ask if its been resolved and also document the process 16:16:25 #topic #8421 allow coreos team to regen coreos distrepos 16:16:30 #link https://pagure.io/releng/issue/8421 16:16:49 we need to fix dist-repo generation. 16:17:01 Now that tag2distrepo is part of koji plugin, they lost the repo generation ability 16:17:14 I think puiterwijk was going to add this to kojira... but I am not sure what the status is. 16:17:32 No, I think mizdebsk was going to take that to upstream. 16:17:41 ah, ok. 16:17:42 I talked about it with him, and he said he'd be happy to look at it 16:17:45 * mboddu waves at puiterwijk 16:17:52 * puiterwijk waves back 16:17:59 Thanks puiterwijk 16:18:00 so, we are waiting for that, but perhaps we put the cron back until it's there? 16:18:21 Yeah 16:18:32 #info mizdebsk is working on fixing the dist repo generation (probably adding it to kojira) 16:18:35 nirik: +1 16:19:15 #info For the mean time, we will renable cron job that generates the dist repos 16:19:25 nirik: ^ Is that okay? 16:20:23 well, sure, thats what I suggest. 16:20:32 there's a infra ticket on this too 16:20:55 nirik: Okay, just confirming before I put it in the ticket :) 16:21:19 hum.... hang on. 16:22:29 I guess this needs to be fedmsg based... so wonder if it's worth the effort. I guess it depends on how long until kojira handles it. 16:23:20 and how often they change repos. 16:24:25 nirik: Hmmm, are there any consequences if we enable the message listener? 16:25:14 what message listener? tag2distrepo? 16:25:20 nirik: Yes 16:25:42 well, yeah, it could fight with the koji plugin 16:26:00 or generate many more repo regens 16:26:36 nirik: Well, until kojira supports the repo regen, there wont be multiple repo regens 16:26:48 But I am not sure if anything else gets affected 16:27:04 Or, we could create a cron job, which runs every 30 mins or so 16:29:06 I'm confused... 16:29:50 puiterwijk: what exactly does the koji plugin do... sees tags and requests a dist-repo? if so, what do we need kojira for? 16:30:15 nirik: yep. 16:30:28 nirik: the problem is that we do *not* want kojira to interfere. 16:30:31 Which it does right now 16:30:50 Basically, right now, kojira sees any "repo" equally, whether they're buildroot repos or dist repos. And it will clean them up after a timeout 16:31:00 (which I think is a day or something) 16:31:03 ah, so the 1 week timeout issue? 16:31:05 Yes 16:31:08 (it's a week by default) 16:31:14 Right. It's some huge number 16:31:51 ok, that makes sense. in that case lets just gen them every monday and friday or something until kojira can leave them alone 16:32:01 or... up it to 6 months or something 16:32:03 Yeah, that works. 16:32:12 nirik: I don't think we want 6 months 16:32:19 Actually, never mind that remark. 16:32:39 * puiterwijk forgot for a second that buildroot repos are just repodata with pointers for a second there. 16:32:57 Although I'm not entirely sure about distrepos. Those might be full copies of the signed RPMs 16:33:42 Cant we separate them? Like having x days for buildroot repos and y days for dist repos? 16:33:46 they are seperate 16:33:47 I thought thats what mizdebsk is fixing 16:33:49 yes, that is what we need 16:33:52 kojira has seperate config for each 16:33:54 correct 16:34:07 we just want the dist-repo one to be infinity 16:34:11 nirik: huh, it does? When I checked the code, it didn't 16:34:21 nirik: well, the non-latest repos should be nuked 16:34:30 ;how soon (in seconds) to clean up expired repositories. 1 week default 16:34:30 ;deleted_repo_lifetime = 604800 16:34:30 ;how soon (in seconds) to clean up dist repositories. 1 week default here too 16:34:30 ;dist_repo_lifetime = 604800 16:34:37 ah, okay 16:34:46 nirik++ 16:34:58 But we do only want to retain the "latest" one for that long. I think that upping that would also delay removing the others 16:35:11 Though given the number of pcakages we have i nthose tags, it might not be that big a deal 16:35:34 So sure. Let's just up dist_repo_lifetime to 6 months for now, and see if those become too big 16:35:43 yeah, it looks like it has no understanding of latest currently 16:35:50 it just does the timeout 16:35:54 Yeah. 16:36:01 And for that, it considers every repo identically 16:36:21 So, iirc, the fix is, upping ;dist_repo_lifetime and then divide non-latest vs latest and add different values for each, latest for long time and non-latest for shorter time 16:36:23 Anyway, as said, it might not be that big a deal. Let's just up it to 6 months 16:36:32 s/iirc/iiuc/ 16:36:38 mboddu: we'd want "latest" to be "indefinite" :) 16:36:48 I think that that would be the kojira change we should submit upstream. 16:37:06 (since "dist repos" sound like "repos for distribution", so I'd say you always want those available) 16:37:20 so perhaps up to 6 months and also file a ticket on koji so we don't forget and hit it in 6 months. ;) 16:37:21 Okay, long time = indefinite :D 16:37:37 nirik: if we up it to 6 months, we will probably never hit it anymore :) 16:37:59 Because most of our active tags will see at least 1 tag in those 6 months, a new repo is generated, which again is around for 6 months 16:38:20 true. ok. 16:38:24 sold. lets up it. 16:38:46 * mboddu will be back in 5 min 16:39:19 mboddu: no, 6 months :P 16:39:30 har 16:41:18 * mboddu is back 16:41:45 puiterwijk: I ordered oneplus 7 pro and it got delivered now, need to sign for the package delivery 16:42:17 nice 16:42:28 did you get one for everyone? :) 16:42:29 nirik: ^ Oh, you must be interested as well :) 16:42:59 nirik: This is not as cheap as the samsung tizen phone I got for you, or else I would have :) 16:43:08 So, let me summarize it 16:43:15 Well, dist-repo thing 16:43:24 * nirik was just pushing the change 16:45:00 #info We will be increasing the dist_repo_litetime to 6 months and then koji ticket will be filed to keep the latest rpm generated dist-repos indefinitely and non-latest rpm generated dist-repos to have shorter time which will be set in the config 16:45:07 nirik: ^ Have I got it right? 16:45:48 nirik, puiterwijk: Now I read about the ticket, I think its about permissions rather than retention - https://pagure.io/releng/issue/8421 16:46:13 well, we don't likely need the ticket anymore... we could do it I guess tho 16:46:15 That ticket is permissions, yes. 16:46:17 But I guess if event based, that shouldn't be a problem 16:46:33 mboddu: but the last comment is about the timeout issue 16:46:41 they shouldn't need those perms? 16:46:56 right 16:46:59 they shouldn't 16:47:15 so, close -> we fixed this so it shouldn't happen again 16:47:30 mboddu: this ticket is now done with the timeout. "Today we had an issue where the distrepo yum repos for our coreos tags went away" - this was the timeout 16:47:45 they wanted another solution, which is to get permission to regen themselves. But if we keep it for 6 months, they don't need that 16:47:49 nirik: I guess, its more like, if the repo is generated when you tag a build, then why do you need permissions 16:48:08 right, they should not... 16:48:16 puiterwijk: ack 16:48:29 * nirik closed https://pagure.io/fedora-infrastructure/issue/7872 which was the infra version of that same issue 16:48:37 thanks 16:51:37 * mboddu also closed releng the ticket 16:51:46 * mboddu really cant type 16:51:51 I closed the releng ticket :D 16:53:39 But "releng the ticket" phrase is sounding funny, now I need to find a situation where I can use it :D 16:54:23 thats like 'do the needfull' 16:55:05 haha :) 16:55:11 #topic Open Floor 16:55:21 Anyone got anything to share? 16:56:02 rawhide status? 16:56:11 Right 16:57:01 #info Oz finally moved to python3 and we moved everything to python3 which broke some stuff and we fixed all them, thanks to nirik 16:57:03 nirik++ 16:57:22 So, things have been broken a while. Initially it was due to moving everything to python3. I worked through those bugs as best I could and they were fixed this weekend/early this week. Now we are dealing with things that broke whiile composes were out... kde broken deps (fixed), and now a aarch64/ppc64le cloud bug in rpm/python/dnf/something 16:57:29 yep 16:57:35 I should mail the list too 16:58:04 of course I need to actually finish reading my email and not being in meetings for that. :) 16:58:14 #info After moving to python3, we faced issues with KDE broken deps, rdieter fixed them for us 16:58:34 #info Now, we have facing aarch64 cloud bug, pwhalen is looking into it 16:59:00 nirik: Hehe, I wish we have clones like puiterwijk does :P 16:59:23 nirik: FYI, I will be going to India after FLOCK and will be on vacation for a week and then work from India for couple of weeks later and then return to the States 16:59:39 ok 17:00:18 nirik: I will be working on F31 beta freeze from India 17:00:40 nirik: Also, mass branching is right after flock, so I will be working from Brno with Tomas on mass branching 17:01:25 ok 17:01:32 oh look, my next meeting. 17:01:37 puiterwijk: ^ This reminded me, we need to fix the creation of dist-git branches during mass branching 17:01:47 Thanks nirik for joining 17:01:57 * mboddu is done with meetings today, knocks the wood 17:02:17 puiterwijk: It seems like repospanner wont work with the existing script we got 17:02:26 Anyhoo 17:02:30 Thanks everyone for joining 17:02:31 Correct. Not hard to fix. 17:02:48 puiterwijk: Awesome, we can work on it later, thanks again :) 17:02:50 It's just that right now, the script is trying to bypass everything and inject stuff on the filesystem 17:02:52 #endmeeting