17:01:31 #startmeeting RELENG (2018-09-20) 17:01:31 Meeting started Thu Sep 20 17:01:31 2018 UTC. 17:01:31 This meeting is logged and archived in a public location. 17:01:31 The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:31 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:31 The meeting name has been set to 'releng_(2018-09-20)' 17:01:31 #meetingname releng 17:01:31 The meeting name has been set to 'releng' 17:01:31 #chair nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin dustymabe 17:01:31 Current chairs: Kellin dustymabe masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll 17:01:31 #topic init process 17:02:04 hi 17:02:17 morning 17:02:19 puiterwijk: Hello, how is it going? 17:02:22 mboddu: I have one point I'd like to bring up. 17:02:28 * dustymabe waves 17:02:38 puiterwijk: Sure, we can start with open floor 17:02:44 Oh, I can also wait 17:02:58 Just wanted to point out I've got something for open floo 17:04:30 puiterwijk: I dont have anything, you can start 17:04:34 #topic Open Floor 17:04:48 * mboddu might have something, still reading the ticket... 17:04:57 Okay. So, it looked like for whatever reason, somewhere yesterday, rawhide was totally emptied out in /pub 17:05:31 I noticed this because the new-updates-sync script was taking way too long for normal, it spent very long at rawhide sync, and when I looked, most directories until where it was with syncing where empty 17:06:03 weird 17:06:12 puiterwijk: Huh, weird 17:06:27 n-u-s brought it all back, but I just wanted to bring it to the attention in case any scripts were changed yesterday 17:07:07 so we don't know why it got emptied ? 17:07:12 Nope. I have no clue 17:07:26 does n-u-s somehow empty it all before it gets added back ? 17:07:31 dustymabe: nope 17:07:34 Not that I know off, esp with freeze, we should know if things are changing with FBR's 17:07:35 It uses rsync with --delete-after 17:07:38 note that we have seen it get stuck. 17:07:47 does the nightly.sh script somehow still run and cause issues ? 17:07:48 (but thats possibly our nfs issues) 17:08:14 dustymabe: that might possibly be, yes. Though I'd find that weird, since it also just does rsync 17:08:16 dustymabe: Nope, nightly.sh also does the samething, rsync with --delete-after 17:08:46 do they both run today? i.e. are we doing two rsyncs when we should only be doing it in n-u-s ? 17:08:54 Anyway, I'll see whether it happens again on my pushduty, and maybe the person next week can also make sure. 17:09:04 note that putting them all in this one place also means updates can be slower to go out. 17:09:31 nirik: yep. Maybe it's an idea to add more cron jobs, where each cron job is for a single release-request combo. 17:09:54 The n-u-s script should be able to accept arguments for it (if not, it's simple enough to add), and then we just create multiple cron entries 17:09:59 Though it will hit NFS harder 17:10:01 but that might overload nfs... but yeah 17:10:28 nirik: or we could do one for request=stable and one for request=testing and one for rawhide. Or something like that 17:10:29 or just split out rawhide/branched 17:10:37 Yeah 17:11:16 Anyway, I do not have any further information right now. Just wanted to bring it up so people on pushduty can watch for it 17:11:22 * masta looks in 17:11:31 Thanks pui 17:11:37 you're welcome, mbo 17:11:48 :P 17:12:21 I think I like request=testing,stable and rawhide, that way it will be easier during freezes 17:12:28 Also, just realized: if it's n-u-s or nightly.sh that deletes it all, the fedmsg on #fedora-releng should say it. 17:12:36 mboddu: the sync script isn't applied for freeze. 17:12:58 Or rather, it will sync whether there's freeze or not, because it only syncs out when a new updates push goes out, which there isn't while pre-GA 17:13:48 puiterwijk: True 17:14:51 puiterwijk: While you are here, I want to bring up https://pagure.io/releng/issue/7827 17:15:05 Nothing is decided yet, but just want to give you a heads up 17:15:15 * mboddu not sure atm what and how this should be handled 17:16:23 hum. 17:16:46 That's fun 17:17:18 puiterwijk: Indeed, I had a little talk with qa about it today morning to check if its a actual blocker or not 17:17:36 And? 17:17:44 Currently they are going to add it to commonbugs for f29 beta, but want to fix by final 17:17:50 ok 17:20:09 puiterwijk: If you have any comments/suggestions, please add them to the ticket when you got time 17:20:40 Will try to look later 17:20:41 Its going to be crazy to change the tagging structure based on some criteria 17:21:38 Yep. This is going to be somewhat really complicated 17:22:00 well, mbs just needs to know for flatpaks, don't tag them into fNN-modular 17:22:11 Right 17:22:16 fNN-flatpaks 17:22:18 ? 17:22:30 sure, wfm 17:23:27 nirik: Yeah, but I am not sure how crazy that logic going to be 17:24:11 Anyway, other than that, I dont have much for this meeting 17:24:32 I just wanted to bring that issue under the radar 17:25:09 so I had something to just note also: 17:25:42 #info nirik has synced production src.fedoraproject.org git repos and pagure db to staging, also pdc database. 17:25:49 let me know if you hit any issues with it. 17:26:46 Okay, thanks nirik 17:27:03 nirik: Just wondering, how long did it take? 17:28:07 not too long. The git repos I synced over night... been doing the databases this morning 17:29:59 nirik: Okay 17:30:24 mboddu: could you re-add that module now for f29 and f30? 17:30:41 modules/minimal-runtime? 17:31:11 nirik: Okay, sure 17:32:10 nirik: But the ticket says only f29 https://pagure.io/releng/issue/7732 17:48:13 * mboddu knocks on nirik's door :) 17:48:58 oh, ok, 29 is ok then 17:49:14 I'm in 2 meetings and debugging a networking problem with IT. ;) 17:50:07 nirik: Sure, I can understand, I just wanted to check if I missed the f30 check 17:50:17 Okay, that is all then 17:50:32 I will wait for 5 more min before closing this meeting 18:02:58 Thanks for joining 18:03:00 #endmeeting