14:35:01 <dgilmore> #startmeeting RELENG (2017-03-20)
14:35:01 <zodbot> Meeting started Mon Mar 20 14:35:01 2017 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:35:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:35:01 <zodbot> The meeting name has been set to 'releng_(2017-03-20)'
14:35:01 <dgilmore> #meetingname releng
14:35:01 <zodbot> The meeting name has been set to 'releng'
14:35:02 <dgilmore> #chair dgilmore nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin
14:35:02 <zodbot> Current chairs: Kellin dgilmore masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll
14:35:04 <dgilmore> #topic init process
14:35:31 <mboddu> .hello mohanboddu
14:35:32 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
14:35:33 <nirik> morning
14:35:40 <Kellin> .hello Kellin
14:35:41 <zodbot> Kellin: Sorry, but you don't exist
14:35:44 <Kellin> .hello kellin
14:35:45 <zodbot> Kellin: kellin 'None' <kellin@retromud.org>
14:37:31 <sharkcz> .hello sharkcz
14:37:32 <zodbot> sharkcz: sharkcz 'Dan Horák' <dan@danny.cz>
14:38:18 <dgilmore> Kellin: case is important :P
14:38:22 * bowlofeggs lurks in the shadows
14:38:37 * dgilmore pulls bowlofeggs ouot of the shadows
14:38:39 <bowlofeggs> hahaha
14:38:45 <bowlofeggs> nooo the liiiight
14:38:50 <Kellin> dgilmore: that seems to be ... the case
14:40:45 <dgilmore> threegone: I guess you are not around
14:43:06 <dgilmore> #topic #133 Enable Signed Repository Metadata
14:43:13 <dgilmore> https://pagure.io/releng/issue/133
14:44:26 <dgilmore> So I think there is value in signing the repodata
14:44:34 <dgilmore> we do it for the openh264 repo
14:44:47 <dgilmore> though having signed repodata has shown up issues in dnf
14:45:00 * nirik nods
14:45:29 <dgilmore> there was a few bugs reported over where dnf stores the gpg keys
14:46:02 <dgilmore> does someone want to take ownership to scope out the work to make this happen?
14:46:03 <maxamillion> .hello maxamillio
14:46:04 <zodbot> maxamillion: Sorry, but you don't exist
14:46:05 <maxamillion> .hello maxamillion
14:46:07 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
14:46:10 <maxamillion> sorry I'm late
14:46:18 <dgilmore> robosignatory should be able to sign it all
14:46:34 <mboddu> dgilmore: I am interested
14:46:40 <dgilmore> but having pungi, mash, etc make calls or something make the calls is needed
14:47:18 <dgilmore> mboddu: do you have the spare cycles for it?
14:47:27 <dgilmore> you already have a lot on your plate
14:47:58 <mboddu> dgilmore: how important is it? when do we want it to be done?
14:48:00 <nirik> I think also dnf couldn't download/ask you for the key right?
14:48:23 <dgilmore> nirik: possibly
14:48:30 <dgilmore> mboddu: I would like it for f27
14:48:44 <nirik> IMHO this is low pri. It doesn't gain us any additional security really. ;)
14:49:32 <dgilmore> https://bugzilla.redhat.com/show_bug.cgi?id=1398868
14:49:40 <mboddu> dgilmore: then I am not sure, but I can help out if someone else is interested in taking a lead.
14:49:52 <dgilmore> nirik: there is additional internal preasures to have it
14:50:11 <dgilmore> its something that is wanted in Red Hat, and we should do first in Fedora
14:50:14 <nirik> as long as you use metalinks... but anyhow.
14:51:45 <dgilmore> nirik: https://bugzilla.redhat.com/show_bug.cgi?id=1247644 was the bug for being unable to read the gpg keys when run as a user
14:52:19 <dgilmore> I am not really sure that the firs bug is a dupe of the second
14:52:33 <nirik> yeah, the first one is... yeah.
14:53:12 <dgilmore> nirik: but was closed as a dupe
14:53:12 <linuxmodder> .fas linuxmodder
14:53:13 <zodbot> linuxmodder: linuxmodder 'Corey W Sheldon' <sheldon.corey@openmailbox.org>
14:53:18 <linuxmodder> super late today sorry folks
14:53:42 <dgilmore> anyway, this is something I want us to work on, scope and get in place
14:53:49 <dgilmore> I would like it for Fedora 27
14:54:00 <dgilmore> linuxmodder: no problem
14:54:23 <dgilmore> #info the work needs to be scoped, it would be a good f27 target
14:54:46 <linuxmodder> dgilmore,  just curious why is 26 too close of a target ?
14:55:37 <dgilmore> linuxmodder: it involves changes to the whole toolchain
14:55:53 <dgilmore> we are beyond the point of making such changes for f26
14:56:09 <dgilmore> we need to have everything in place for alpha
14:57:08 <dgilmore> #topic #6482 fix bodhi buildroot overrides with secure-boot packages
14:57:16 <dgilmore> https://pagure.io/releng/issue/6482
14:57:23 <linuxmodder> ah didn't realize it was so heavy in tooling side to do makes sense
14:58:11 <dgilmore> I think the right solution here is to adjust the policy to allow bodhi to tag the packages into the override tags
14:58:44 <dgilmore> does anyone disagree?
14:59:19 <linuxmodder> still reading one sec
14:59:20 <nirik> sounds good to me. just needs to be done. ;)
14:59:28 <dgilmore> yep
14:59:29 <Kellin> is that option 2 on the list?
14:59:38 <dgilmore> Kellin: it is
14:59:47 <Kellin> also - what do buildroot overrides do/allow?
15:00:22 <linuxmodder> +1 from me dgilmore  on the sec-boot
15:00:56 <dgilmore> we need a line like https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/koji_hub/templates/hub.conf.j2#n112
15:01:20 <linuxmodder> Kellin,  allow you to override any defualts like size/ or scripting or in this case vars for things like signed files for secure boot
15:01:40 <dgilmore> Kellin: its a process that lets people get a build of a package into the buildroot in order to build against it
15:02:11 <linuxmodder> the only ones presently missing are what shim adn peseign right dgilmore ?
15:02:12 <dgilmore> Kellin: it allows you to build related changes to submit as a single update
15:02:33 * masta_ looks in, reads up.
15:03:01 * linuxmodder waves to masta
15:03:39 <dgilmore> #agreed we will make hub policy changes to allow bodhi to tag the secure boot changes.
15:03:48 <Kellin> dgilmore: so in specific to secureboot, what would an override usecase look like?
15:04:45 * Kellin goes with the flow so we can move on, but has some concerns (which may be unfounded due to newbie-understanding) as to what overriding in secureboot building does in terms of security on the signing chain.
15:04:46 <dgilmore> Kellin: I am not sure I understand your question
15:04:59 <nirik> if say you wanted to build a new kernel with a new pesign... you build the pesign package, add an override for it, and then build the kernel, and then you can submit both in the same update as an update.
15:05:42 <Kellin> so it bundles them in the release stream instead of having to ensure two packages get released at the same time?
15:05:45 <masta> oh that sounds nice, what nirik jsut wrote
15:05:50 <Kellin> nirik: ^^
15:06:09 <dgilmore> or it could be that grub2 made changes, a grub2 theme needs to build against the new grub2 build
15:06:20 <dgilmore> Kellin: no
15:06:31 <dgilmore> Kellin: lets take this out of the meeting
15:06:42 <Kellin> dgilmore: that's what I was about to say, this is me not understanding, I trust your judgement
15:06:49 <dgilmore> #6156 Specifying groups in scm changes
15:06:57 <dgilmore> https://pagure.io/releng/issue/6156
15:07:24 <dgilmore> this is an old issue
15:08:12 <mboddu> dgilmore: you missed topic
15:08:47 <dgilmore> #undo
15:08:47 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x4c560d90>
15:08:49 <dgilmore> #undo
15:08:49 <zodbot> Removing item from minutes: AGREED by dgilmore at 15:03:39 : we will make hub policy changes to allow bodhi to tag the secure boot changes.
15:08:56 <dgilmore> #agreed we will make hub policy changes to allow bodhi to tag the secure boot changes.
15:09:03 <dgilmore> #topic #6156 Specifying groups in scm changes
15:09:09 <dgilmore> https://pagure.io/releng/issue/6156
15:09:11 <dgilmore> this is an old issue
15:09:59 <dgilmore> maybe we just ask if this is still an issue
15:10:25 <maxamillion> +1
15:10:37 <dgilmore> #info asking if the issue still exists
15:10:41 <dgilmore> #topic #5911 Rules for private/topic branches in dist-git
15:10:49 <dgilmore> https://pagure.io/releng/issue/5911
15:11:19 <dgilmore> so our policy is that we do not remove branches period
15:12:14 <dgilmore> this is another old issue
15:12:32 <nirik> we could fix this...
15:12:37 <nirik> but it would be some work.
15:12:51 <dgilmore> It would need a lot of work in koji
15:13:34 <dgilmore> https://pagure.io/releng/issue/6671 is somewhat related
15:14:12 <Kellin> so why would we want/need private branches and, subsequently, why would we want to delete the branches at all?  it feels like an odd request to me
15:14:34 <maxamillion> Kellin: +1
15:14:35 <linuxmodder> nirik,  why is that just for regression test capability ?
15:14:37 <dgilmore> https://pagure.io/releng/issue/5843 is an issue that needs to be resolved in order to even think about it
15:14:47 <linuxmodder> the not deleting policy i mean
15:15:15 <dgilmore> Kellin: because people want to say prep a majour update and not affect whats stable
15:15:43 <dgilmore> Kellin: particullary when they are collaborating with someone else on the change
15:16:13 <dgilmore> linuxmodder: can you please restate your question
15:16:19 <nirik> yeah, for collabrotating on something thats not ready yet
15:16:20 <linuxmodder> why not just use and external repo and git-dist or whatever it is ?
15:16:39 <Kellin> dgilmore: but wouldn't that be something done in upstream on a shared branch and then merged into dist-git after that work was good?
15:16:41 <nirik> there are also often mistakes. people make a local branch for something and accidentally push it
15:17:02 <nirik> Kellin: not if its fedora packaging work... upstream wouldn't do that normally
15:17:10 <dgilmore> Kellin: they may not directly be involved in upstream
15:17:26 <linuxmodder> nirik,  could we not just set no forced push or something for that last case
15:17:45 <dgilmore> linuxmodder: we have no forced pushes turned on
15:18:08 <linuxmodder> dgilmore,  so not sure I get the pushing part that nirik was asaying then
15:18:17 <dgilmore> the reason we do not delete branches period is because we have no ability to  control what branch a build is done from
15:18:30 <dgilmore> as long as the ref is accesable the build can complete
15:18:35 <maxamillion> dgilmore: I'm with Kellin on this, I think upstream is a more appropriate place and if they aren't directly related with upstream, this would be a perfect example of a time to get started contributing upstream
15:18:40 <nirik> right. so if someone pushes a branch and then does a build from it, then we have to keep it forever
15:18:43 <linuxmodder> its from folks that already have push auth then and oopsie push a branch to bodhi and not the upstream or whatever other repo?
15:18:48 <maxamillion> that's just my $0.02
15:18:50 <dgilmore> maxamillion: its not up to us
15:19:01 <maxamillion> dgilmore: how isn't it?
15:19:11 <dgilmore> maxamillion: and upstream git looks nothing like dist-git
15:19:29 <maxamillion> dgilmore: git is git, you can clone it all over the place
15:19:35 <dgilmore> maxamillion: how is it up to us? the packager does not have to be involved in upstream,a nd mostly is not
15:19:58 <nirik> another case people have mentioned is pushing a bunch of changes for maintainer to review and merge if they like... then remove the branch...
15:20:04 <dgilmore> maxamillion: sure. but a code git repo and the packlage git repo do not look anything teh same content wise
15:20:09 <linuxmodder> that is a same, its semi expected at first but 200 commits later t's not
15:20:42 <linuxmodder> and dist-git makes that change yes dgilmore  ?
15:20:51 <linuxmodder> please pardon my packaging ignorance
15:21:50 <maxamillion> I'll agree to disagree because I'm apparently out of touch on this one, but I think this is wrong and it will pollute dist-git repos ... if we want that kind of functionality then wait for distgit in pagure and allow things to be forked and send pull requests ... people can work on the forks
15:22:05 <Kellin> dgilmore: so we're talking about a major packaging change, ala swapping from having a list of Patch##: <filename> to the git list scripts some folks are using?
15:22:47 <dgilmore> maxamillion: compare https://github.com/python/cpython to https://src.fedoraproject.org/cgit/rpms/python3.git/tree/
15:23:04 <dgilmore> linuxmodder: makes what change?
15:23:07 <linuxmodder> with maxamillion  here
15:23:24 <linuxmodder> the content change from code git and package git
15:23:39 <dgilmore> maxamillion: pagure on dist git may help here
15:23:49 <maxamillion> dgilmore: I'm extremely familiar, but nothing says I can't git clone https://src.fedoraproject.org/cgit/rpms/python3.git/tree/ to where ever I want and work collaboratively from there ... I can even effectively fork it to github if I wanted
15:23:51 <nirik> Note: we already allow pushing branches, just not deleting them
15:23:53 <maxamillion> dgilmore: it's all just git
15:23:56 <dgilmore> Kellin: not necessarily
15:24:25 <dgilmore> maxamillion: I think you are out of touch here
15:24:34 <nirik> maxamillion: sure, but you add overhead... the other people have to sign up, get commits, etc... which they may well already have in dist git
15:24:53 <masta> So.... does this topic hinge on kojid scm policies on private branches?
15:24:58 <dgilmore> maxamillion: people can go and work on it elsewhere, they do not want to
15:25:00 <linuxmodder> why can't we presently treat them like a PR does dgilmore  tho
15:25:19 <dgilmore> they want tod o it in dist-git because of acls etc
15:25:20 <Kellin> so color me crazy here, but if they are making huge changes to the actual package, and it's not upstream, doesn't that go against our ideology of pushing things upstream first by promoting the ability to go around upstream when deemed necessary?
15:25:23 <linuxmodder> where merge is accepted branch nuked -- or is that just a pagure cap
15:25:25 <dgilmore> and its closest to the source
15:25:33 <maxamillion> dgilmore: right, my point is that if we want something like this then we should add it via pagure instead of just shoe-horn it in with private branches that need to be garbage collected
15:25:37 <Kellin> that's where I'm not following
15:25:55 <dgilmore> Kellin: no. packaging work is diofferent ot upstream work
15:26:21 <dgilmore> maxamillion:  perhaps. this issue has been open for 2 years
15:26:28 <dgilmore> and predates the possibility of pagure
15:26:42 <masta> so does dist-git need to consult with kojid on if a private branch is safe to remove?
15:26:44 <linuxmodder> upstream aiui is all code Kellin packing is not
15:26:51 * dgilmore is misstyping all over the place
15:27:00 <maxamillion> dgilmore: ok?
15:27:09 <dgilmore> maxamillion: no
15:27:14 <maxamillion> dgilmore: no what?
15:27:29 <linuxmodder> so how does /would it determine garbage collect on a private then dgilmore
15:27:34 <Kellin> having come recently from being a packager, I'm struggling to think of a task as a packager that I'd do that I'd consider a "major change" worthy of a separate private branch
15:27:36 <nirik> currently private branches are never removed.
15:27:44 <dgilmore> Ithink this discussion is going nowhere fast
15:27:45 <maxamillion> dgilmore: I don't see why the age of the ticket is relevant, why limit the possibility of a solution to the parameters of what was capable two years ago?
15:28:04 <dgilmore> maxamillion: was meant for masta
15:28:25 <nirik> yeah, perhaps list or out of meeting discussion could be good here.
15:28:28 <Kellin> yeah
15:28:29 <linuxmodder> likely possible re-tooling aspect  maxamillion  but I'm also grasping for straws on that myself
15:28:53 <Kellin> +1 nirik on taking this to a mailing list and discussing this out of meeting further
15:28:55 <masta> dgilmore, okay, that makes it easier. For fear of removing a giturl that was used in a released build.
15:29:08 <dgilmore> masta: kojid can not tell you anything
15:29:21 <linuxmodder> I'm for a ML push on this
15:29:46 <dgilmore> masta: we would need to talk to kojihub in order to see if commits to be removed were used in real builds
15:29:59 <dgilmore> maxamillion: the problem is that it is a long standing thing
15:30:03 <nirik> we could fix this serveral ways... disallow all non standard branches, disallow builds from non standard branches, require tags to build from and disallow tagging non standard branches, etc.
15:30:14 <dgilmore> there are a bunch of brnahces out there today people want removed
15:30:18 <dgilmore> we have told them no
15:30:22 <maxamillion> I have another meeting
15:30:23 <maxamillion> o/
15:30:36 <dgilmore> any changes we make need to account for historical realities
15:30:43 <masta> well, the taskid of a build has an SCM giturl used in that build, I figured that would be consulted prior to removing a branch... you know. using 'git branch -ar --contains=[git hash here]'
15:30:46 <dgilmore> we can set a different path going forward
15:31:32 <dgilmore> we also have the potential changes to branching that modulatirty is pushing for
15:31:48 <dgilmore> in that there will be no more f25 or f26 branches
15:32:05 <dgilmore> but there would be say 2.4.4 branch for http
15:32:16 <dgilmore> and 4.10 branch for kernel
15:32:55 <masta> whoa
15:33:10 * dgilmore needs to run
15:33:16 <dgilmore> I have another meeting
15:33:23 <dgilmore> mboddu: can you finish up please
15:34:22 <mboddu> dgilmore: I need to run to a meeting as well
15:35:18 <dgilmore> #endmeeting