17:00:47 #startmeeting RELENG (2018-03-08) 17:00:47 Meeting started Thu Mar 8 17:00:47 2018 UTC. The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:47 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:47 The meeting name has been set to 'releng_(2018-03-08)' 17:00:47 #meetingname releng 17:00:47 The meeting name has been set to 'releng' 17:00:47 #chair dgilmore nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin 17:00:47 Current chairs: Kellin dgilmore masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll 17:00:47 #topic init process 17:03:02 howdy 17:03:21 masta: How is it going? long time no see :) 17:03:23 .hello Kellin 17:03:24 Kellin: Sorry, but you don't exist 17:03:31 .hello kellin 17:03:32 Kellin: kellin 'Kellin' 17:04:15 mboddu, goes well, and you? 17:04:29 morning 17:05:11 masta: going well, but crazy 17:05:34 nirik: did my patch message hit the infra mailing list? 17:06:04 which one? I think I +1ed one yesterday? 17:06:18 Okay, lets get started 17:06:24 #topic #7317 Changes/Remove GCC from BuildRoot 17:06:31 #link https://pagure.io/releng/issue/7317 17:07:17 I just want to bring this topic and see whats going to affect and what we need to do 17:08:35 I'm sure some packages will break... but up to maintainers to fix them 17:08:46 yep. 17:08:55 Yes 17:09:17 there is an assumption gcc will be there, so I guess to find those we can do mass rebuild 17:09:24 But is it safe to assume that we dont need to include gcc changes in mass rebuild? 17:09:59 not sure what you mean... yeah, next mass rebuild should fail them 17:09:59 Once its removed 17:11:14 is there another mass rebuild before Beta? 17:11:19 I suppose a email to devel asking folks to be explicit in their BR's in terms of their desired tool-chain 17:11:22 nirik: Sorry, I was confused about glibc 17:11:38 masta: BR? 17:11:44 build require 17:12:06 masta: Yeah, right, they should add that to their spec files 17:12:50 no, we only do mass rebuiilds at most once per cycle 17:13:18 there have been reminders to devel list about this. 17:13:26 nirik: We did twice for f27, but thats a special case 17:13:47 yeah, very much an exception 17:14:00 Yes 17:14:18 So, what are the steps to follow here? 17:14:44 And does anyone know what ignatenkobrain meant by 3rd mass rebuild in his comment https://pagure.io/releng/issue/7317#comment-498006 ? 17:14:50 not much for us to do other than when the change owner is ready remove gcc and move on 17:15:06 mboddu: he is doing mass rebuilds locally to him to tell what packages need fixing 17:15:49 nirik: Oh okay 17:15:50 .hello2 17:15:51 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 17:15:57 mboddu: I am performing mass-scratch-rebuilds on my server 17:16:10 * mboddu trying to find the mail on devel list 17:16:15 so last weekend I performed 2nd one 17:16:18 ignatenkobrain: Okay, Kevin just told me about it 17:16:45 and thanks for doing that ignatenkobrain. :) 17:17:10 Yes, thanks ignatenkobrain 17:17:14 ignatenkobrain++ 17:17:14 mboddu: Karma for ignatenkobrain changed to 9 (for the f27 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:18:00 so basically my question is when can it really happen (removal of gcc) ? 17:18:20 I would prefer sooner than later to give people time to sort any appearing issues 17:18:37 * nirik nods. anytime seems ok to me... this is for f29? or ? 17:18:47 yes, f29 17:18:48 So, I guess what we can do here, wait for ignatenkobrain 3rd mass rebuild, fix what ever packages he can fix and once thats done, we will remove gcc from 17:18:52 nirik: f29 17:18:58 cool. 17:19:43 this sounds good to me 17:20:21 ignatenkobrain_: So, will you let us know when your work is done and any stats on them? like what still needs to be fixed... 17:20:28 yup 17:20:36 And then we will remove gcc 17:20:44 ack 17:21:42 #info ignatenkobrain will let releng/infra know about his 3rd mass scratch rebuilds and once thats done we will remove gcc from buildroot 17:21:54 Okay, moving on 17:22:37 #topic #7227 [RFE] Add new repositories for modular[-updates[-testing]] 17:22:43 #link https://pagure.io/releng/issue/7227 17:22:58 I want to bring this up to get a status update on where we are standing 17:24:12 AFAIK, we are still waiting on a compose and currently two issues with pungi is fixed in pungi-4.1.22-7.fc27 with missing Container variant and important one module rpms ending up in Everything repo 17:24:46 nirik: ^ I have a question here, how should we remove the existing module rpms from Everything repo once its fixed? 17:25:10 Assuming they were not removed by traditional rpms 17:30:25 well... I guess we can see after this compose. 17:30:33 It might make an empty repo for them 17:30:56 Okay :) 17:32:12 And then we have bodhi work, which is being worked by Patrick and Randy, bodhi 3.5.0 is deployed and we were able to push f28-u-t and Patrick will test pushing f28m-u-t later today 17:32:21 Am I missing anything? 17:32:48 hopefully rawhide will finish... needs mbs changes to make modules for it. 17:32:59 (does anyone know what ticket/bug is tracking that?) 17:34:50 Well, I am currently worried about f28, but I dont know about the ticket thats tracking mbs changes 17:38:30 #info For branched/f28 compose - We got a new pungi which will not mix modular rpms into Everything repo and then waiting on new systemd to get into f28 and bodhi 3.5.0 is deployed which will support modules which will be tested on modules later today 17:38:39 sure. hopefully we are close 17:41:26 Okay, moving on 17:41:41 #topic Alternate Architectures Update 17:42:21 Does anyone know what the status on slow s390x atomic composes? Can we fix them even though s390x box is not located in PHX? 17:45:07 I guess that would be slow, not being in PHX 17:45:33 * masta looks for the s390 atomic logs 17:45:38 masta: It was too slow, we had to kill them since they were taking like 8 hrs or so(iirc) 17:45:54 I don't know the details there, but I think some folks were working on making them faster. 17:47:43 is s390/atomic disabled, or killed as they happen? 17:47:55 I'd be happy to take a look 17:47:57 nirik: We tried a new pungi, but it didn't help much 17:48:13 masta: We killed them and disabled them 17:51:13 #info Work is going on to make s390x atomic composes faster 17:51:21 #topic Open Floor 17:51:27 Has anybody got anything? 17:51:46 I have one item... 17:53:15 nirik: Go ahead 17:53:16 I might try and move the splitting of fedora_koji forward after freeze... will need some playing with the settings in koji, but it needs to get done sometime. I'm open to ideas on what to name the volumes... I was thinking just archive01 02 03, etc... 17:54:05 nirik: are you talking about https://pagure.io/releng/issue/6805? 17:54:52 yeah. 17:55:09 Okay, how are you splitting them? 17:55:19 since then koji has added more multivolume support. 17:55:34 You can now tell it what volume to put things on based on what tag(s) they are in. 17:56:02 Then cant you name the volumes by tags/releases? 17:56:03 so I was planning on 10TB volumes, and just add old releases to it until it's nearly full, then make the next, etc. 17:56:22 well, if the first one has fc6, f7, f8, f9, f10 on it, what do you call it? 17:56:34 and I don't know in advance how many will fit. 17:57:14 We can call them f10 which has everything less than or equal to f10 17:57:19 I suppose we can rename them later if we want... just change the mount and the database 17:57:36 but can you tell me how many will fit in the first 10TB? 17:57:42 And next one has only 3 releases, then f13(f11,f12,f13) 17:58:05 that also sounds confusing to me, as f8 for example will be on... the f10 volume? 17:58:22 I suppose we could do seperate volumes for each release. 17:58:28 but the old ones will be very small. 17:59:04 nirik: why not figure out the size in a pre-process, and then make a LV to fit 105 pct , rather than one size fits all? 17:59:11 nirik: I like 1 release on each volume, but it doesn't make sense for the initial releases 17:59:18 that would permit useful nameing ? 18:00:43 orc_fedo: would need a lot of work I suspect. 18:00:44 nirik: If its possible, name them in a way we know what release is in what volume, thats all 18:02:05 #info nirik is planning to split fedora_koji sometime after freeze as koji now support multiple volumes 18:02:14 We are over the scheduled time 18:02:20 lets close the shop now 18:02:27 Thanks everyone for joining 18:02:43 thx all 18:02:46 #endmeeting