16:11:12 <mboddu_temp> #startmeeting RELENG (2019-05-23) 16:11:12 <zodbot> Meeting started Wed May 22 16:11:12 2019 UTC. 16:11:12 <zodbot> This meeting is logged and archived in a public location. 16:11:12 <zodbot> The chair is mboddu_temp. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:11:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:11:12 <zodbot> The meeting name has been set to 'releng_(2019-05-23)' 16:11:13 <mboddu_temp> #meetingname releng 16:11:13 <zodbot> The meeting name has been set to 'releng' 16:11:13 <mboddu_temp> #chair nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu dustymabe ksinny jednorozec 16:11:13 <mboddu_temp> #topic init process 16:11:13 <zodbot> Current chairs: dustymabe jednorozec ksinny masta maxamillion mboddu mboddu_temp nirik pbrobinson pingou puiterwijk sharkcz tyll 16:11:20 <nirik> morning 16:12:21 <bcotton> .hello2 16:12:22 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com> 16:12:24 <mboddu_temp> How many nicks do I have now? mboddu, bhujji and now mboddu_temp 16:12:41 * mboddu_temp blames VPN 16:13:23 <mboddu_temp> And for some reason I cannot send messages on #fedora-releng channel 16:13:56 <nirik> not identified? 16:14:13 <mboddu_temp> May be 16:14:26 <mboddu_temp> Anway, lets get started 16:14:30 <mboddu_temp> #topic #8373 Using https://github.com/coreos/fedora-coreos-config/ as input for FCOS builds 16:14:38 <mboddu_temp> #link https://pagure.io/releng/issue/8373 16:15:45 * nirik is fine with them hosting wherever... 16:16:22 <mboddu_temp> I am fine with it as well, but I would like to know why they want to use github, rather than pagure 16:17:37 <mboddu_temp> If its some features they are missing or anything else, we can try to capture them and probably see if we can add those features to pagure 16:18:10 <nirik> likely it's just convient with their other work... 16:18:31 <mboddu_temp> For me its not the github vs pagure that worries me, its not using pungi to compose these artifacts, oh well... 16:19:30 * nirik has to step away for a min, back in a min or two 16:21:59 <mboddu_temp> #topic #7498 Support on-the-fly tarball generation in Koji 16:22:07 <mboddu_temp> #link https://pagure.io/releng/issue/7498 16:23:04 * dustymabe arrives late 16:23:26 * nirik back 16:23:34 <mboddu_temp> Its been a while we discussed this, but always ready initiative might fix this 16:24:44 <nirik> I'd have to re-read it... I don't recall what my opinion was on it 16:26:01 <dustymabe> mboddu_temp: nirik let me know if you have questions on the previous topic 16:26:20 <dustymabe> if we have a decision please post it in the issue 16:26:22 <mboddu_temp> dustymabe: We ack'd it, so you are good to use GH 16:26:31 <mboddu_temp> dustymabe: I already did 16:27:40 <mboddu_temp> nirik: I think its the reproducibility factor what we worried about, which is still an issue 16:28:25 <dustymabe> thanks! 16:31:34 <nirik> well, I think thats a misunderstanding on what they wanted... which I also had 16:34:03 <nirik> well, not sure. 16:34:13 <nirik> I guess I need to re-read it fully 16:36:19 <mboddu_temp> What if we generate the tarball on fly and upload it to lookaside cache? I think that would solve all the issues 16:37:34 <mboddu_temp> Also, at the same time, I am not sure how always ready initiative is going to handle this, since they are also trying to solve the same thing 16:37:38 <nirik> I don't know that it would 16:37:51 <nirik> when you say 'we' who do you mean? 16:38:17 <nirik> right now any maintainer can pull a git commit and make a tar.gz and upload it. 16:38:31 <nirik> but I don't think that fixes the issues they want to. 16:39:51 <mboddu_temp> nirik: "we" = automated koji build 16:39:57 <nirik> if we depend on remote, it means net and their side has to be up for our builds to work... 16:40:29 * mboddu_temp will be back in a min 16:40:33 <nirik> if remote git repo is down... build fails? 16:41:41 * mboddu is back and no more a vigilante :P 16:41:43 <mboddu> nirik: That is true 16:41:59 <mboddu> There are lot of corner cases to think about 16:42:47 <mboddu> To make pingou happy we can say "This automated tar ball generation feature only supports if you host your code on pagure" :P 16:43:38 <mboddu> Lets punt it to next week and we can come back with more reading/thinking/info 16:45:29 <dustymabe> TBH i'd be interested in something like this too 16:46:34 <dustymabe> if remote git repo is down... build fails? - only if source tarball is not already in lookaside ? 16:46:38 * nirik isn't worried about reproducablity... just availability 16:47:03 <nirik> there is no source tarball tho... it's checking out a git repo to make one 16:47:33 <nirik> once it does check it out and make one it's in the src.rpm so we have it forever, but if the remote is down we can't build. 16:47:57 <mboddu> nirik: If the remote is down, they cannot make a tarball as well (unless he has the local copy), so that case is still a problem right now 16:48:03 <nirik> I suppose we could punt back to a uploaded version if needed 16:48:35 <nirik> right, thats the only problem I think... 16:50:20 <nirik> I can ask for a actual workflow in the ticket... 16:50:43 <mboddu> But reproducability is still something that we should consider 16:50:46 <mboddu> nirik: ack 16:50:54 <mboddu> Thats a good idea and see what they will say 16:51:10 <nirik> mboddu: well, we can reproduce, but it's just more work 16:51:46 <mboddu> nirik: I mean, if the remote changes the hash then there is no way to reproduce it 16:52:15 <mboddu> Not that it happens, but just a worry 16:52:20 <nirik> sure there is... we have the src.rpm... we know at the time it was built the hash 0xdeadbeef was _this_ exact source we have in the src.rpm 16:52:34 <mboddu> Oh right 16:52:47 <nirik> but we can't simply rebuild it, because it would try and pull 0xdeadbeef down again and if they changed hashes it would fail. 16:53:27 <mboddu> Yes, probably a flag saying to build it from lookaside cache what I uploaded rather than using the remote 16:57:20 <mboddu> Anyway, its almost time 16:57:24 <mboddu> #topic Open Floor 16:57:33 <mboddu> Anything? 16:58:38 <nirik> f28 goes eol next week... 16:59:09 <nirik> so, at that point we will need to make ppc64 rhel7 builders just for epel builds, or get epel to drop ppc64 16:59:39 <mboddu> Is 2nd an option at all ;) 17:00:03 <nirik> not sure. I asked in epel-devel list and I think we will discuss at todays meeting. 17:00:05 <mboddu> #info Fedora 28 goes EOL next Tue, May 28th 2019 17:00:08 <nirik> it's kinda a poor thing to do 17:00:29 <mboddu> nirik: Oh, for real? I thought you were just joking 17:00:29 <nirik> but not sure how many ppc64 users epel6/7 have... older hardware might be stuck on it 17:01:02 <nirik> I kinda want to avoid having rhel builders... sitting there doing nothing but epel6/7 builds 17:01:12 <mboddu> Okay 17:01:24 <mboddu> Anyway, thats all for today 17:01:29 <mboddu> Thanks everyone for joining 17:01:37 <mboddu> #endmeeting