14:30:57 #startmeeting RELENG (2017-06-19) 14:30:57 Meeting started Mon Jun 19 14:30:57 2017 UTC. The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:30:57 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:30:57 The meeting name has been set to 'releng_(2017-06-19)' 14:30:57 #meetingname releng 14:30:57 The meeting name has been set to 'releng' 14:30:57 #chair dgilmore nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin 14:30:57 Current chairs: Kellin dgilmore masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll 14:30:57 #topic init process 14:31:09 morning 14:31:11 .hello kellin 14:31:11 Kellin: kellin 'None' 14:34:46 Lets give few more min for people to join 14:36:47 * masta is here 14:37:52 .hello maxamillion 14:37:53 maxamillion: maxamillion 'Adam Miller' 14:39:01 Okay, lets start, I dont have much this week, so probably this will be a short meeting 14:40:27 this is great, pagure is not responding :( 14:40:33 * nirik pokes it 14:40:59 nirik: it worked, but its slow 14:41:23 #topic #6756 "ActionNotAllowed" when attempting "koji untag-build f27" 14:42:20 Last time we decided to add a stg tag in between and the compose process will tag them to the base tag and then start the actual compose 14:42:59 So, what are all the pieces that needs changing? 14:43:25 everything that interacts with rawhide tags. ;) 14:43:26 I am thinking fedpkg and pungi 14:43:40 autosign, pungi, fedpkg 14:43:57 nirik: yeah, autosign as well 14:44:34 .whoowns fedpkg 14:44:34 mboddu: cqi 14:44:35 so, perhaps we should id/create patches in ticket and then once all are made we can set a date for the cutover 14:45:47 which reminds me... whats the status of the dnf pungi work? 14:45:53 * nirik doesn't see lseldar 14:46:23 morning all 14:47:15 mboddu: neither pungi or fedpkg 14:47:16 morning dgilmore 14:47:28 mboddu: we would need to write a script to move the builds 14:47:44 dgilmore: I thought the idea was autosign would do that? 14:47:48 then make the compose process run it 14:48:07 however I thought we decided that not being able to untag was fine 14:48:10 * nirik re-reads the ticket 14:48:16 as it prevented other problems 14:49:34 dgilmore: I thought we wanted to give the maintainers the ability to untag the builds, I dont remember anything about other problems it prevented 14:49:42 I think the thought was that we could add a tag in there like stable releases and let people untag from that, but once it went out in a compose they could not... but I guess I am not sure if it's worth the work in the end. 14:50:10 that could also be a point for CI testing... 14:50:17 dgilmore: and yeah, we can add the script to nightly.sh to tag the builds to the base tag 14:50:19 nirik: yeah, seems reasonable 14:50:38 mboddu: indeed 14:50:49 but perhaps we should close this one and wait until we have some CI we want to hook in... 14:50:58 it should nto be a lot of work to write the script 14:51:09 nirik: yeah, likely best 14:51:29 and possibly open a new one about doing this so we don't forget. 14:51:33 mboddu: people sometimes just untag builds with bugs and leave the old one in place 14:51:36 dgilmore: yep, you are true 14:51:38 not fixing anything 14:51:55 as a result everyone who had updated would be stuck on the bad build 14:53:05 dgilmore: okay 14:54:58 So, the plan is to close this ticket for now and wait until we have CI in place and add the script to nightly.sh to tag builds from stg tag into base tag? 14:55:49 mboddu: seems to be a good plan to me 14:56:18 yeah, possibly a new ticket on that? I can file it if you like... 14:56:50 nirik: sure 14:57:50 #info Plan is to close this ticket and wait until we have CI in place and add a script to nightly.sh to tag builds from stg tag into base tag 14:59:08 Okay, lets move on 14:59:24 #topic #5911 Rules for private/topic branches in dist-git 14:59:34 #link https://pagure.io/releng/issue/5911 14:59:40 I dont think we need this anymore 15:00:06 Only thing to do here is make sure everyone is aware of the policy 15:00:59 I tagged this for the meeting 4 months ago 15:01:06 I forget why now 15:01:24 dgilmore: Cant it be solved by arbitrary branching by modularity? 15:01:26 * dgilmore notes to make it clear whats to be discussed when adding the meeting keyword 15:01:32 mboddu: no 15:02:02 mboddu: but arbitory branching makes the policy more necessary 15:02:23 we do need to ensure that real builds can not happen from forks 15:02:32 which afaik is being worked on 15:02:35 * nirik notes pingou was just working on this in #fedora-apps 15:02:46 then we could allow people to delete branches from thier forks 15:03:30 I'm hoping Koji builder plugin can fix part of the topic, preventing builds from private branches flowing into official non-scratch builds. 15:03:35 dgilmore, nirik : thanks for the update, can you link me to the policy if its available somewhere? 15:04:08 masta: sure, but no one is working on that 15:04:17 mboddu: its not docummented 15:04:39 I don't know the status. 15:04:43 mboddu: which is why I think I added the meeting keyword to talk about it and have someone write it up 15:04:44 we could ask pingou... 15:04:55 dgilmore: okay :) 15:05:12 dgilmore, probably true. I can try to add priority point to the topic in Koji side of things. 15:05:28 pingou: see /topic for ticket 15:05:37 masta: I do not think its a priority or needed 15:06:06 masta: the work to support pagure on distgit and arbitory branching likely makes the need for private branches go away 15:06:20 yeah, thats waht I am wondering... 15:06:35 I think private branch can go away with the forks 15:07:04 just use a fork to collaborate until things are ready to land on the main repo 15:07:16 pingou: right 15:07:25 pingou: +1 15:07:26 and have some way for koji to reject builds from fork branches? 15:07:33 and as long as we ensure no real builds come from forks people could delete them 15:07:44 which will solve a few historical complaints 15:07:51 nirik: https://pagure.io/koji/pull-request/421 koji already can do this 15:08:10 but we need to backport this patch to the rpm 15:08:41 well, or get another release to happen. ;) 15:08:42 relates to ticket https://pagure.io/releng/issue/6671 15:09:00 I don't know that there is one planned soon enough :/ 15:09:08 but yeah, that's another solution :) 15:11:58 so, close this ticket and move on? 15:12:33 nirik: +1 15:12:48 nirik: perhaps, but we should revist and make sure policy is documented and setup once we have all the changes in place 15:13:01 sure. 15:14:03 yeah, would be good to revisit in future. 15:15:51 #info Close the ticket for now and revisit to make sure policy is documented and setup once we have all the changes in place 15:17:57 #topic Alternative Architectures updates 15:18:10 Its been a while we got any update on alt aches 15:18:24 sharkcz, nirik : any updates? 15:18:47 nothing off hand 15:19:03 sharkcz: also, hows f26-beta for s390? 15:19:04 from builds point of view all looks good, the infra is still the bottleneck 15:19:39 mboddu: it's composed, I just need to send you an updated PR for the config 15:19:50 #info From builds point of view all looks good, the infra is still the bottleneck 15:20:19 sharkcz: nice 15:20:59 sharkcz: thanks for the update 15:21:03 np 15:21:09 #Open Floor 15:21:17 #topic Open Floor 15:21:25 finally sometime for open floor 15:21:36 anybody has anything to share? 15:21:40 I filed a ticket a while back on moving builds to different volumes. Did everyone see that? have any questions? 15:22:16 https://pagure.io/releng/issue/6805 15:23:44 nirik: just waiting to set it up and try move some builds 15:24:00 probibly we would want to wait until after final now I guess. 15:24:15 oh, and I plan to do a update/reboot cycle this week... tomorrow and wed... 15:24:48 mboddu: you are on updates? please coordinate with me tomorrow on when to push? 15:25:19 #info Splitting koji into two volumes will be done sometime after F26 final 15:25:29 nirik: sure 15:25:48 #info Infra planned to do a update/reboot cycle this week... tomorrow and wed... 15:26:19 anything else guys? 15:26:24 nirik: we need to make sure that the most recent mock did not go stable 15:26:40 ok... which one is that? 15:27:00 1.4.x builds 15:27:18 there was massive changes that I expect will break things for us 15:27:26 yeah, it didn't it looks like 15:27:35 and chroot was replaced with systemd-nspawn 15:27:40 :( 15:28:02 dgilmore, nirik : I just pushed the updates and it has mock-1.4.2-1.fc25 mock-1.4.2-1.fc26 mock-1.4.2-1.el7 15:28:21 mboddu: :( 15:29:01 dgilmore: whats going on here, removing cron and at for systemd timers and now this? 15:29:05 mboddu: those are the new ones for testing tho right? 15:29:11 not stable 15:29:11 they all look to be in -testing right now which is fine 15:29:30 mboddu: huh? 15:29:59 nirik, dgilmore : yes, they are for testing, not stable 15:30:35 dgilmore: https://pagure.io/fedora-comps/pull-request/134 15:31:10 dgilmore: planning on removing at in favor of systemd timers and seems like it got approved few min back 15:31:25 =/ 15:31:35 dgilmore, so the systemd-nspawn is default now? 15:32:04 any other issues with 1.4 ? 15:32:04 mboddu: not seen that so I have no comment 15:32:11 mboddu: thats just on the workstation media tho... you can install them if you like. 15:32:16 masta: it changes how it sets up the buildroots 15:32:22 and I do not think we want it 15:32:29 * nirik notes that timers really are not a replacement. they work differently 15:32:34 there are a lot of pieces in there that likely negatively effect us 15:32:48 but we have not tested and not been engaged in upstream 15:32:51 so ... 15:32:53 nirik: yes, but they are not default and timers work differently 15:33:29 mboddu: thats just for workstation not for everything 15:33:35 dgilmore, for testing, can we install the 1.4 on one of our staging builders? 15:33:43 and does not stop anyone from installing cron or at 15:33:59 masta: we will have to install it in stage 15:34:04 and do a bunch fo builds 15:34:26 yep, that sounds about right 15:35:07 can we cconditionaly NAK the bodhi update for mock 1.4 in the mean time? 15:35:34 masta: I had asked them to hold off on the buildsys list 15:37:14 anyway, we passed our schedule time, please take the remaining discussion to #fedora-releng 15:37:19 Thank you all for joining 15:37:24 #endmeeting