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