14:33:56 #startmeeting RELENG (2017-06-26) 14:33:56 Meeting started Mon Jun 26 14:33:56 2017 UTC. The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:33:56 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:33:56 The meeting name has been set to 'releng_(2017-06-26)' 14:33:56 #meetingname releng 14:33:56 The meeting name has been set to 'releng' 14:33:56 #chair dgilmore nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin 14:33:56 Current chairs: Kellin dgilmore masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll 14:33:59 #topic init process 14:34:17 morning 14:34:24 * masta is here 14:34:56 * dustymabe too 14:35:09 #topic #6847 Splitting fedora-repos into edition-specific variants (F27 timeframe) 14:35:15 https://pagure.io/releng/issue/6847 14:35:17 * sharkcz is here 14:35:19 lets get started 14:35:42 I am very against splitting the package into multiple. 14:35:53 dgilmore: +1 14:36:02 as we would have to update them all and in the past we failed at that which is why we have the packaging we now have 14:36:24 i like the 'inject a variable' approach 14:36:26 but we should be able to figure out a way to give mattdm what he wants 14:37:06 it will also need coordinating with mirrormanager to make sure its all understood on that side 14:38:48 does anyone have any opinion? 14:39:35 I agree that injection a variable sounds like the best way forward 14:39:53 hey tyll :) welcome 14:40:01 but dnf folks didn't want to do that? or ? 14:40:42 ah they just don't have it implemented... they are not against it. 14:40:44 #agreed releng feels that the most appropriate way forward is with the injection of a variable into the url 14:40:57 nirik: it just may take longer 14:41:01 yeah 14:41:07 but I think its the best way forward 14:41:19 .hello maxamillion 14:41:20 maxamillion: maxamillion 'Adam Miller' 14:41:27 sorry I'm late, attempting to multi-task 14:42:39 #topic #6822 using include statements in pungi-fedora 14:42:43 bad maxamillion 14:42:50 https://pagure.io/releng/issue/6822 14:43:08 dustymabe: did you do up a PR? 14:43:31 not sure why the meeting keyword was not removed after we had discussed 14:43:51 dgilmore: not yet - koji hadn't been synced to stg when I was originally looking at this 14:43:58 so none of my test pungi runs would work 14:44:10 okay 14:44:11 it is now synced to stg so I'm unblocked but haven't got back around to it yet 14:44:30 dustymabe: indeed 14:44:31 #info waiting on a PR from dustymabe to show how he would like to see things changed 14:44:36 dustymabe: bah, tab-fail ... sorry 14:44:39 dgilmore: indeed :) 14:44:51 i believer no one was agianst it 14:45:03 we were just not totally sure what was being proposed 14:45:09 believe even 14:46:04 #topic #6799 [koji] Add configuration for module build service content generator 14:46:11 https://pagure.io/releng/issue/6799 14:47:29 I think the only change I would like to propose here is that mbs also uploads teh logs on teh json generation 14:47:36 not sure how invasive that would be 14:47:52 threebean: any idea? 14:48:55 * threebean reads up 14:50:40 eh, should be possible. 14:50:43 but will take a code change. 14:51:02 threebean: cool 14:51:09 will file an issue to track it. 14:51:12 can we add it in later? 14:51:21 I think it wou,ld be usefult to have as part of the auditability 14:51:29 I think so 14:51:29 (for now at least, the logs are accessible on mbs-backend01 in the journal) 14:51:53 threebean: thats not public and open and transparent :D 14:52:21 yup, yup. 14:52:25 but it is auditable! 14:53:15 #agreed that under the condition we add the logs creating the json to the upload we can add the content generator 14:53:56 oh - wait. we need to implement this first before we can turn on the CG? 14:55:28 not having the CG is effectively blocking (or slowing) bodhi dev work atm. 14:55:59 threebean: no, you need to agree to prioritize doing it and agree to doing it as quickly as possible 14:56:05 gotcha. 14:56:22 we can queue it up for next sprint (starting wednesday). 14:56:48 cool thanks 14:57:32 #topic broken dependencies 14:57:53 hey tyll so you had some things to raise over cleaning up of broken deps? 14:59:00 dgilmore: thx, yes, usually we retire all pkgs with broken deps for the final freeze 14:59:41 however, there are still a lot of pkgs with broken deps (about 87) 15:00:29 So I was wondering if we have also another option to maybe just block the packages in a way that they will not be in the Everything repo but could still be added as an update later 15:01:37 well, we could untag all builds of that package so there are none in the tag... 15:01:38 the only way to do that would be to block them in the f26-compose tag 15:01:41 here is a list of all pkgs and the archs they have broken deps in: https://paste.fedoraproject.org/paste/AtaI4nsPqBDMvw7jm1z5IA 15:01:43 but then they would get GCed 15:02:28 tyll: what is the arches? 15:03:39 dgilmore: in the repo for that arch there is a broken dependency 15:04:03 tyll: so does that mean they are not broken on other arches? 15:04:15 the pkgs where it is just some arches should be "easily" fixable by adding some excludearch/exlusivearch and making them non-noarch 15:04:26 maxamillion: origin is in that list 15:04:32 dgilmore: yes, some of them for example require docker which is not available everywhere 15:04:51 dustymabe: yeah, it shouldn't be 15:04:59 dustymabe: I don't know why it's getting listed there 15:05:05 tyll: asterisk: x86_64, armhfp, ppc64le, aarch64, ppc64, i386 15:05:15 I thought jsmsaid he was working to fix that 15:05:26 maxamillion: origin: ppc64 15:05:36 the info is from this report: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NR6YEE577F5N22S6BII53LC5LIWFQMJZ/ 15:05:38 maxamillion: it apparently has broken deps on ppc64 15:05:45 maxamillion: there is no docker on ppc64 15:05:51 dgilmore: ah 15:06:00 dgilmore: ppc64 isn't a primary arch, why is this an issue? 15:06:21 maxamillion: with the merge of the arches we pick up things like that now 15:06:30 maxamillion: likely it should have a ExcludeArch ppc64 15:06:58 #info We should try and get the deps sorted out, 15:07:21 maxamillion: you should be getting daily emails that the deps are broken 15:07:49 threebean: do you have ideas on how we could make the broken deps notifications more effective 15:08:17 dgilmore: asterisk-dahdi seems to be a broken subpackage on all archs 15:08:18 dgilmore: alright, will do 15:08:39 tyll: but the dep was getting added back 15:08:51 dgilmore: I have to excludearch for armv7hl right because of a golang compiler bug also :/ 15:08:52 dgilmore: maybe it is not yet in stable? 15:09:18 tyll: https://koji.fedoraproject.org/koji/buildinfo?buildID=897526 its in updates-testing still 15:10:07 java-1.8.0-openjdk: x86_64, i386 15:10:10 that seems bad 15:10:23 dgilmore: java will be fixed with the next push 15:10:44 dgilmore: at least there is an update for the missing dep 15:10:54 tyll: okay 15:11:08 I think we should try push people to fix things 15:11:09 https://bodhi.fedoraproject.org/updates/FEDORA-2017-e898ddd8ca 15:11:40 contyk: modularity-testing-framework: ppc64 15:12:09 * contyk reads the backlog 15:12:20 the upcoming notification of the pkgs being retired got at least some pkgs being fixed 15:12:31 (at least in testing) 15:13:13 contyk: that package has broken deps on ppc64 and is at risk of being kicked out 15:13:35 dgilmore: because of golang? it's not mine, I don't know much about it 15:13:36 tyll: so an option would be to block in the -compose tag 15:13:42 but I can prod its owners 15:13:52 but that would not make the package be removed from the nightly composes 15:15:44 #info We need to figure out how to deal with broken deps better, from notifications to cleaning up 15:16:21 a bunch of them seem to be packages that should add "ExcludeArch: ppc64" 15:16:38 because of docker not being supported on ppc64 15:16:52 I have some time later to fix at least the pkgs that only require exludearch updates 15:17:32 but we will need to get the fixed packages through freeze. 15:17:44 nirik: indeed 15:17:59 they can be proposed as FE's 15:18:21 adamw: how would you feel about 80 odd updates to fix broken deps as FE's 15:18:24 ? 15:19:41 when we just block the pkgs in the compose we should have a deadline until they get properly retired 15:21:00 sure 15:22:07 do we have a proposal? 15:23:40 6 weeks is the usual deadline we give for orphaned pkgs so it sounds like a good candidate 15:25:08 #agreed we will block all the packages in f26-compose, and give 6 weeks for things to be cleaned up. If the updates get stable or FE's for final we will unblock to get them included in F26 15:25:13 sound good? 15:25:21 yes 15:25:25 +1 15:25:39 +1 15:26:04 sounds like a plan 15:26:22 #action to make sure mboddu and Kellin are aware of the agreed upon process 15:26:31 #topic open floor 15:26:39 does anyone have anything to bring up? 15:27:17 if not will wrap up? 15:27:37 #endmeeting