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