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