16:01:29 <mboddu> #startmeeting RELENG (2019-04-18)
16:01:29 <zodbot> Meeting started Wed Apr 17 16:01:29 2019 UTC.
16:01:29 <zodbot> This meeting is logged and archived in a public location.
16:01:29 <zodbot> The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:29 <zodbot> The meeting name has been set to 'releng_(2019-04-18)'
16:01:29 <mboddu> #meetingname releng
16:01:29 <zodbot> The meeting name has been set to 'releng'
16:01:29 <mboddu> #chair nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu dustymabe ksinny jednorozec
16:01:29 <mboddu> #topic init process
16:01:29 <zodbot> Current chairs: dustymabe jednorozec ksinny masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll
16:02:08 <bcotton> .hello2
16:02:09 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:02:39 <mboddu> bcotton: Hello, welcome to the party!
16:02:44 <bcotton> hello!
16:02:52 <mboddu> bcotton: What drink would you like to have? :P
16:03:14 <bcotton> bourbon, neat :-)
16:03:30 <nirik> morning
16:03:48 * nirik has arrived just in time for bourbon. hurray!
16:04:14 <mboddu> bcotton: Woah, bourbon neat, thats something :D
16:04:19 <mboddu> nirik: Haha :D
16:04:55 <mboddu> bcotton: I dont know whether you went to Kentucky Derby or not, but there you can find a bourbon based mojito and it was really good
16:05:20 <mboddu> bcotton: But next I see you, I will get you a bourbon drink :)
16:05:22 <bcotton> mboddu: i've never been, but i do make Hot Browns and drink bourbon on Derby day :-)
16:05:43 <mboddu> :)
16:05:54 <mboddu> Okay, lets get the real party started :)
16:06:24 <mboddu> I have 2 big tickets and 1 simple ticket to discuss
16:06:34 <mboddu> #topic #8265 RFC: Separate target for Rust packages
16:06:40 <mboddu> #link https://pagure.io/releng/issue/8265
16:06:51 <mboddu> ignatenkobrain: You around?
16:07:01 <ignatenkobrain> yup
16:07:15 <mboddu> As far as I understand, Igor wants something like coreos-continuous thing for rust packages
16:07:23 <nirik> whats the goal here? to stop shipping these in rawhide?
16:08:19 <ignatenkobrain> yes. 1) not ship things to rawhide 2) make builds faster (because repos will be smaller)
16:08:29 <ignatenkobrain> so that repo regen won't take such long time
16:09:01 <ignatenkobrain> it doesn't seem that MBI thing is not going further (since there is still no HW, nor any decision)
16:09:26 <nirik> so it would be completely seperate? or in the rawhide inheritence tree?
16:10:46 <mboddu> ignatenkobrain: Also, what happens to the crates that are built using this separate tag?
16:11:01 <ignatenkobrain> nirik: it would inherit from rawhide
16:11:15 <ignatenkobrain> mboddu: they would stay within that tag and would be used only there
16:11:30 <nirik> they wouldn't need to be signed? or would they?
16:12:37 <mboddu> Are they ever be consumed by anyone?
16:12:44 <mboddu> If yes, then I guess they should be signed
16:12:55 <nirik> just as a buildroot I think?
16:13:22 <ignatenkobrain> as a buildroot. Having shipped them in a dist-repo would be nice too, but is not necessary
16:14:15 <ignatenkobrain> and we would definitely need src repo generation in it (otherwise it would be pointless)
16:15:03 <nirik> the current mixed in src repo handling? or the seperate SRPMS/ repo handling thats proposed to upstream but not in yet
16:15:54 <mboddu> Also, whats the advantage here? I mean, all this work and does it provide the return benefit?
16:16:32 <ignatenkobrain> nirik: for now (since it doesn't get shipped anywhere) we can live with mixed one
16:16:34 <mboddu> Other than the improving the repo regen
16:17:11 <ignatenkobrain> mboddu: 1) build-only content doesn't get shipped to users, or shipped as separate repo 2) repo regen speed, more freedom to test updates (I am looking at you, rawhide gating)
16:17:56 <mboddu> Okay
16:18:12 * nirik doesn't get the gating thing. How does this give you more freedom?
16:18:42 <nirik> because it bypasses what they expect the flow to be?
16:19:28 <ignatenkobrain> yes, I can untag broken builds without worrying what will happen because it won't be shipped to users
16:20:02 <ignatenkobrain> I can have bunch of non-installable packages there and it won't be catched by tooling which says "no broken deps in rawhide"
16:20:37 <nirik> how does having non installable packages work for even the buildroot case?
16:21:10 <mboddu> Good point, I didn't think of that
16:21:12 <mizdebsk> the packaging workflow gain can be huge; i am using a separate koji instance (called MBI above) for the same reason
16:21:37 <ignatenkobrain> nirik: because some of subpackages can be broken for quite a while
16:21:53 <ignatenkobrain> but we don't care about them
16:23:02 <nirik> ok
16:24:20 <mboddu> So, in order to complete this
16:24:28 <nirik> well, I'm not sure if I like this or not... but I haven't had much time to think about it...
16:25:11 <mboddu> mizdebsk: "the packaging workflow gain can be huge" what do you mean?
16:27:07 <mizdebsk> maybe i can give you an example; today a packager pinged me and asked whether we can remove a package from javapackages-tools module
16:27:23 <mizdebsk> i said "ok, lets block it in koji and see what happens"
16:27:24 <nirik> so, this is basically a side tag we just never merge right? or is it in the inheritence differently?
16:27:32 <mizdebsk> package blocked, koschei caught dependency issues
16:27:45 <mizdebsk> i pushed some fixes without thinking too much
16:28:02 <mizdebsk> and this way with almost no effort i was able to retire package and replace it with something else
16:28:35 <mizdebsk> that would not be possible in rawhide; it would be much harder, it would require up-front investigation what would break, what would need to be fixed
16:28:51 <mizdebsk> verifying whether it's actually possible to fix stuff, *before* actually retiring the package
16:30:27 <mizdebsk> i hope that shows the picture
16:31:27 <mboddu> mizdebsk: Kinda, just needed to think a bit
16:32:02 <mboddu> nirik: I thought it will be inherited from the base tag not the buildroot of rawhide, am I thinking it wrong here?
16:35:09 <nirik> dunno, I am not clear on it, which is why I asked.
16:37:18 <mboddu> mizdebsk, ignatenkobrain : Can you comment on the ticket with what exactly you need in koji to make it work, then nirik and I can take a look and will probably will come back to with more questions or we might complete your request.
16:37:55 <mboddu> Does that sound okay to everyone?
16:37:58 * nirik wonders if we would need to adjust koji-gc.
16:39:02 <ignatenkobrain> ok
16:39:38 <mizdebsk> i don't maintain any rust packages, so technically i don't "need" this tag, but i understand what issues ignatenkobrain is having with package maintenance and i think that this tag would be a solution to many of them
16:40:55 <mboddu> ignatenkobrain, mizdebsk : Thanks guys
16:41:28 <mboddu> #info ignatenkobrain and/or mizdebsk will comment on the changes they need in koji and we will proceed further based on the changes.
16:42:57 <mboddu> Okay, the 2nd big ticket is not a releng issues, seems like something related to flatpak itself
16:43:18 <mboddu> FYI - https://pagure.io/releng/issue/8291
16:43:54 <nirik> mboddu: see otaylor's post to the list... might be a issue with user/system flatpaks and updates.
16:44:13 <mboddu> nirik: Will take a look, thanks
16:44:18 <mboddu> #topic Open Floor
16:44:30 <mboddu> nirik: I wanted to talk to you about s390x builders
16:44:40 <mboddu> https://pagure.io/releng/issue/8293
16:45:37 <mboddu> Does all the s390x builders have 2 cpu's? buildvm-s390x-[01:15].s390.fp.o
16:46:47 <nirik> I can check...
16:47:11 <nirik> they are really fast cpus tho.
16:48:27 <nirik> please stand by while my ssh tries to connect.
16:48:37 * nirik plays elevator music
16:48:39 <mboddu> nirik: Haha :D
16:49:27 <nirik> I'm fine reducing the weight... if it causes a blockage we can always readjust it.
16:49:52 <nirik> yes, there are 2 5ghz cpus.
16:51:03 <mboddu> nirik: Okay, "$ koji edit-host --capacity=2 buildvm-s390x-[01:15].s390.fp.o" that's it, right?
16:51:49 <nirik> yeah... althought does it need a freeze break?
16:52:17 <mboddu> nirik: Just to be sure, I will send an FBR
16:52:22 <mboddu> s/an/a/
16:52:34 <nirik> one thing to note:
16:52:57 <nirik> I have been watching the varnish server there since yesterday and it's had 0 503's related to backend fetching...
16:54:01 <nirik> so it may be that they are doing ok now...
16:54:19 <nirik> or that there is just less network saturation right now
16:54:50 <mboddu> nirik: Hmmm, but what is downside of reducing the capacity? Even with 4, the s390x vms cannot run 4 things at a time, right?
16:55:22 <nirik> well, it's not number of things, its a weight... so reducing the number means it does less things at the same time.
16:56:04 <nirik> it's a trade off. If it's doing twice as many jobs, does it do them more than 2x slower?
16:56:13 <mboddu> Okay
16:56:58 <mizdebsk> with lower capacity it's more likely that a few scratch builds of big packages will block real builds for hours
16:57:20 <nirik> true...
16:58:16 <mboddu> So, whats the final call? Reducing or not
16:58:30 <mboddu> If I have to say, reduce them so that we wont hit any issues in the future
16:59:14 <nirik> I'm fine either way, but we should re-evaluate how they are doing down the road if we do change it...
17:00:07 <mboddu> nirik: Sure, and we can hold it until freeze for now
17:02:07 <mboddu> #info Since everything seems to be fine now, we will make the change after the F30 Final freeze.
17:02:55 <mboddu> Thanks everyone for joining
17:03:00 <mboddu> #endmeeting