15:59:41 <mboddu> #startmeeting RELENG (2019-04-25)
15:59:41 <zodbot> Meeting started Wed Apr 24 15:59:41 2019 UTC.
15:59:41 <zodbot> This meeting is logged and archived in a public location.
15:59:41 <zodbot> The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:59:41 <zodbot> The meeting name has been set to 'releng_(2019-04-25)'
15:59:41 <mboddu> #meetingname releng
15:59:41 <zodbot> The meeting name has been set to 'releng'
15:59:41 <mboddu> #chair nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu dustymabe ksinny jednorozec
15:59:41 <zodbot> Current chairs: dustymabe jednorozec ksinny masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll
15:59:41 <mboddu> #topic init process
15:59:53 <nirik> morning
16:00:42 <mboddu> nirik: Morning, how goes?
16:01:05 * ksinny_ waves
16:01:17 <nirik> the usual. ;)
16:01:31 <ksinny_> My internet(on mobile network) is very slow, it may get disconnected
16:01:45 * mboddu is really sorry for ksinny_
16:01:53 <mboddu> So, lets get to that ticket first
16:02:02 <ksinny_> no problem at all :)
16:02:10 <mboddu> #topic #8294 coreos-pool and coreos-release koji tags request for FCOS
16:02:12 <bcotton> .hello2
16:02:13 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:02:17 <mboddu> #link https://pagure.io/releng/issue/8294
16:02:20 * mboddu waves at bcotton
16:02:26 <nirik> morning bcotton.
16:02:38 <nirik> How's the thought leader business? ;)
16:02:47 <bcotton> thriving ;-)
16:03:06 <mboddu> ksinny_: So, what exactly are these tags for? And whats the difference from coreos-continuous tag?
16:04:03 <mboddu> And do they need to follow a release, for ex, should the tags be inherited from any of the fedora base tags (fxx) or any other tags
16:04:32 <ksinny_> mboddu: packages tagged to coreos-pool tag is from where FCOS will be built for developmenet and production refs
16:05:14 <ksinny_> coreos-release tag will be used to tag builds which will make to FCOS releases(includes production refs)
16:05:14 <nirik> so this is for packages that override fedora packages that are needed by coreos for prod?
16:05:31 <ksinny_> This is to make sure that garbage policy are accordingly
16:05:32 <nirik> or this is just marking the existing fedora packages ?
16:05:57 <mboddu> I think its just marking the existing fedora packages, iiuc
16:06:07 <ksinny_> mboddu: Don't think they need to be inherited from any other tags
16:06:50 <ksinny_> we will create a dist-repo with all packages tagged to coreos-pool and will specify specific nvrs while running composes
16:08:09 <nirik> hum, so those likely could be large? if you tag in every fedora package you need?
16:08:10 <ksinny_> mboddu: coreos-continuous tag is mainly for ttsing new features which is not yet released for packages like rpm-ostree, ignition
16:09:37 <mboddu> ksinny_: How many packages are we talking here? Just a ball park number?
16:10:03 <ksinny_> nirik: yeah, this is mostly marking the existing packages. In some exception cases where some backport is needed then it may be the case to build a package directly to coreos-pool but for that I think it will first need to cerate repsective branch in dist-git
16:10:13 <mboddu> And also, how many composes per day?
16:11:29 <ksinny_> nirik: yeah, it will be a large repo since we will be using a single tag for all pcakges we want to include in FCOS build
16:11:44 <nirik> so, the fedora ga and fedora-updates tagged packages should not ever get gc'ed... I wonder if you could only tag in those packages that are not in those tags and use all the repos? or you need it to be seperate?
16:11:46 <mboddu> ksinny_: To build a package directly to coreos-pool you dont need a separate dist-git branch, you can use a build target, but if you need to apply your own patches and then build that package with the patch then you might need a separate dist-git branch
16:13:05 <ksinny_> mboddu: package list are mostly what we have at https://github.com/coreos/fedora-coreos-config/blob/master/fedora-coreos-base.yaml inlcuding all dependencies
16:14:27 <nirik> I guess it all sounds fine, but I am concerned with signing time... if we have to resign a pile of packages all the time it's going to take up a lot of robosign cycles...
16:14:37 <ksinny_> nirik: It can be gc'ed as per the gc policy we will have (don't think we had discussion about it yet)
16:15:14 <mboddu> nirik: Yeah, that was my next question, ksinny_ : do they need to be signed with a different key?
16:16:19 * masta looks in
16:16:33 <ksinny_> <nirik> so, the fedora ga and fedora-updates tagged packages should not ever get gc'ed... I wonder if you could only tag in those packages that are not in those tags and use all the repos? or you need it to be seperate?
16:16:50 <mboddu> That means, we need to have a pending area to get them signed and robosign config changes and stuff
16:16:55 <ksinny_> I think we can take this question on ticket to ge better answer
16:16:59 <ksinny_> get*
16:17:14 <nirik> yeah, lets add some questions and discuss more in ticket?
16:18:04 <ksinny_> mboddu: We are fine with using Fedora key
16:18:42 <ksinny_> I had a  related question in ticket "can we have dist-repo with pakcages having multiple keys"?
16:18:43 <mboddu> #info There are more questions that needs to be answered and all the questions will be asked in the ticket
16:19:15 <mboddu> ksinny_: fedora keys are based on a release though
16:19:41 <mboddu> ksinny_: Yes, you can
16:20:28 <nirik> huh, how does it do that? multiple copies?
16:21:03 <ksinny_> mboddu: yeah, but we will have packages in coreos-pool from multiple Fedora releases (since we are handling next(F31) and stable(F30)
16:21:14 <mboddu> nirik: Not sure how its handled internally though, probably a question to koji folks
16:22:15 <mboddu> ksinny_: And how are you going to do major releases?
16:23:42 <mboddu> ^ reason being, if you are using builds from different releases, is it going to be continuous release or you cut major releases?
16:24:14 <ksinny_> mboddu: Suppose Fedora major release hapened (eg. F30) , we will take those packages set and it will bake in into testing-devel and once it looks good we will do testing and then stable release
16:25:13 <ksinny_> Release will keep happening every two week with updated content from major release +updates-testing content(after getting baked in for some time in testing and then to stable)
16:26:44 <ksinny_> mboddu: https://github.com/coreos/fedora-coreos-tracker/blob/master/stream-tooling.md is a good document to get some answers
16:26:48 <mboddu> Simply put, if FCOS 1 (is the release name if we call it) it is based on F30 content, no F31 content and FCOS 2 will be based on F31 content
16:26:57 <mboddu> Is my understanding right?
16:27:35 <ksinny_> FCOS new release is going to have multiple streams which is a bit different than Atomic Host, so it can be confusing in beginning
16:28:14 <ksinny_> mboddu: yes, FCOS stable stream release will have content only from F30
16:28:40 <mboddu> So, when F31 goes stable, then FCOS stable will have both F30 and F31 content?
16:28:52 <mboddu> Or just F31 content?
16:29:01 <ksinny_> But we have a simltanious release with next stream(which tracks upcoming release i.e. F31). This is to let user see what is coming in next release
16:29:47 <ksinny_> mboddu: when F31 goes stable, FCOS stable stream release will be F31 based. next stream release will be on F32 (once branching takes place)
16:30:06 <mboddu> Okay
16:30:55 <ksinny_> This is a bit similar to how container linux does release. They have separate channels alpha, beta and stable
16:32:23 <mboddu> nirik: So, ^ if we keep using the fedora keys, then we have to change the configs everytime when we branch and a release goes stable
16:32:35 <mboddu> Which is not bad
16:32:41 <ksinny_> considering the discusion, does the request in ticket looks fine?
16:32:46 <nirik> or... perhaps we could version the coreos ones?
16:33:01 <nirik> just always make them when we make fedora tags...
16:33:18 <nirik> ie, coreos-release-30, coreos-release-31, coreos-pool-30, etc?
16:33:30 <nirik> or does that not work because they might have a mix?
16:34:11 <mboddu> nirik: ^ yes, which is why I started the discussion with "follow a release"
16:36:08 <ksinny_> Having coreos tags based on Fedora release may work but I might be missing something here, let's add this to the ticket
16:36:20 <nirik> I'm sure we can figure something that works... just need to try and do soemthing so it aligns best for both of us
16:36:31 <ksinny_> agree
16:36:42 <mboddu> nirik: +1
16:37:03 <nirik> we could just also sign those with fedora keys, but I don't know if another key is a requirement/desired
16:38:32 <ksinny_> nirik: As far as I am aware we don't need any other key
16:38:56 <mboddu> nirik: I guess we can make use of fedora release keys somehow
16:39:29 <jlebon> nirik: the great majority of packages we ship will be regular Fedora pkgs. wes should only have to spin our own for backports
16:39:40 <jlebon> so just those would have to be signed
16:40:10 <nirik> cool and you could get those from fedora ga/updates? or would everything need to be in one repo?
16:41:11 <jlebon> we'd like to keep them separate if possible so that adding to the pool is a controlled operation
16:41:25 <ksinny_> nirik: we need in a single repo sothat we can specify specific nvra during compose. If we use regular updates repo, latest may not be what we wnat
16:41:26 <ksinny_> want*
16:41:30 <jlebon> pulling from the regular repos is an issue since they can change from under us
16:42:26 <jlebon> we'll be using lockfiles anyway, though separating them gives us more control/certainty
16:42:56 <mboddu> jlebon, ksinny_ : Okay, makes sense
16:42:56 <nirik> hum, ok. but you don't care if they are signed by fedora keys or other key?
16:43:46 <jlebon> the backport ones? i think we'd rather they be signed by the fedora keys if possible :)
16:44:05 <nirik> ok, if we can version the tags then we can know what fedora key to sign them with
16:44:32 <ksinny_> For regular package, having them signed by Fedora key will be good. Does these packages needs to get resigned when we are just adding a new tag?
16:44:32 * dustymabe reads scrollback
16:44:54 <dustymabe> i think we'd like to have the tags unversioned and control things via the lockfile
16:44:58 <nirik> ksinny_: not if they are already signed, but if they aren't they would have to be
16:45:13 <nirik> dustymabe: then what key do we sign things with?
16:45:44 <dustymabe> nirik: could we just switch the default key at some cutover point?
16:45:53 <dustymabe> alternatively we could have several tags
16:46:07 <mboddu> dustymabe: several tags?
16:46:22 <dustymabe> i.e. fXX-coreos-pool that then aggregate into fedora-coreos-pool
16:46:31 <dustymabe> using inheritances
16:46:31 <nirik> also, it would be nice if we used inheritence here... since you mostly want the base fedora one?
16:47:32 <dustymabe> does that make sense?
16:47:35 <dustymabe> should I try to restate ?
16:48:15 <jlebon> could signing be done based on the buildroot that was used for the pkg?
16:48:44 <jlebon> then it just automatically switches over when we start backporting things from a newer release
16:48:47 <nirik> nope, robosign just knows when something was tagged and what the tag was, so it looks at it's rules and does that
16:48:48 <mboddu> jlebon: AFAIK, nope, its based on the tags
16:49:32 <dustymabe> nirik: so we could either manually update the rules when we cutover or we need multiple tags that then we aggregate into a generic tag
16:49:52 <dustymabe> is that right?
16:50:02 <jlebon> hmm, ok. in that case using subtags + inheritance like dustymabe suggested sounds good. though the issue then is that we have to pester you folks each release to get a new tag created :)
16:50:17 <dustymabe> each release probably isn't too bad
16:50:28 <nirik> jlebon: well, we can just add it to the tags we make on branching
16:50:31 <dustymabe> as long as it doesn't get more involved than that
16:50:33 <mboddu> dustymabe, jlebon : We can make them as part of branching
16:50:43 <jlebon> +1 nice
16:51:05 <nirik> but can we also make these tags children of the updates tag?
16:51:13 <dustymabe> nirik: how does inheritance work with dist-repo :?
16:51:27 <dustymabe> do I get all the packages in my parent too?
16:51:28 <nirik> dustymabe: it will follow it unless you pass --no-inherit
16:51:41 <dustymabe> ahh cool
16:51:50 <nirik> --noinherit rather
16:52:03 <dustymabe> jlebon: i wonder if we actually want to do something "smart" here
16:52:13 <nirik> oh, also, do you all need multilib?
16:52:40 <dustymabe> i.e. if we inherit from updates then when we make a dist-repo will it make a repo with all the packages from all of fedora or can we limit it to just packages we care about ?
16:52:42 <nirik> oh, no, nevermind
16:52:56 <nirik> it would do all of them.
16:53:14 <dustymabe> yeah we probably don't want to do that then - for efficiency sake
16:53:22 <nirik> unless noinherit, then it would do only the ones in that tag
16:53:44 <nirik> so you would have to add all the packages you care about specifically, and track them...
16:53:55 <dustymabe> yeah we plan to have tooling to do that anyway
16:54:08 <dustymabe> the tooling will actually look at what is in updates and then tag that into the tags we care about
16:54:29 <dustymabe> so it won't use inheritance but it will still use what is in fedora proper
16:54:33 <jlebon> (for the subset of pkgs in updates that we actually care about)
16:54:36 <dustymabe> jlebon: ksinny_ ^^ is that right ?
16:54:49 <nirik> ok.
16:54:50 <mboddu> I guess fxx-coreos-pool and fxx-coreos-release tags inheriting from fxx and generating the dist-repos with the fxx key is what is needed?
16:55:03 <ksinny_> dustymabe:  yeah, that's my understanding
16:55:11 <nirik> mboddu: well, they don't want that because that would get everything... all fedora packages
16:55:18 <dustymabe> mboddu: let me try to take what you set and modify it slightly
16:55:25 <dustymabe> we need:
16:55:41 <dustymabe> fxx-coreos-pool - i.e. f30-coreos-pool f31-coreos-pool
16:55:45 <mboddu> nirik: Yes, but the plan is to use --noinherit
16:56:01 <dustymabe> fedora-coreos-pool - inherits from fxx-coreos-pool
16:56:11 <mboddu> With inheritance, they dont need to add packages
16:56:14 <dustymabe> fedora-coreos-release
16:56:28 <nirik> mboddu: but they want to. ;)
16:56:30 <dustymabe> fedora-coreos-release - we manually tag into fedora-coreos-release
16:56:40 <mboddu> Okay
16:57:13 <dustymabe> do those three things I posted make sense?
16:57:22 <nirik> dustymabe: can you add this to the ticket? I think we are all on the same page now, just good to spell it out there.
16:57:24 <jlebon> dustymabe: yeah, that makes sense to me. then dist-repo on coreos-pool with inheritance.
16:57:28 <mboddu> dustymabe: So, why fedora-coreos-pool?
16:57:50 <jlebon> to aggregate into a single repo
16:58:13 <mboddu> Why not just use fxx-coreos-pool?
16:58:16 <dustymabe> mboddu: it's just a big ocean of packages we pull from - we have very fine granular control of what packages (NVR) actually get consumed on the build side
16:58:33 <ksinny_> so, in the end we will have only two dist-repos (fedora-coreos-pool and fedora-coreos-release) or dist-repos for all sub-releases?
16:58:50 <dustymabe> ksinny_: we don't even need a dist-repo for fedora-coreos-release IMHO
16:58:55 <jlebon> i think we only need a single dist-repo, on fedora-coreos-pool
16:59:01 <jlebon> with inheritance turned on
16:59:11 <dustymabe> the only point of fedora-coreos-release IIRC is for extended garbage collection policy
16:59:16 <ksinny_> dustymabe: I thought we will need it to replicate FCOS release builds
16:59:38 <dustymabe> ksinny_: no I don't think so because those will still be in fedora-coreos-pool too
16:59:41 <nirik> note: this will also require robosign and koji hub/gc changes.
16:59:47 <ksinny_> yeah, right
17:00:17 <mboddu> Okay, one last question, from the ticket "coreos-pool and coreos-release koji tags created (include arches aarch64, ppc64le, x86_64)"
17:00:19 <nirik> so we will have to change the dist-repo config when you want to change keys
17:00:25 <mboddu> Do you guys need a buildroot?
17:00:45 <dustymabe> jlebon: ^^ do you know the answer to that ?
17:01:01 <mboddu> nirik: Seems so
17:01:03 <jlebon> likely not
17:01:15 <jlebon> unless we need to backport something that affects the buildroot for other backports themselves
17:01:46 <jlebon> i guess that *could* happen? though doesn't seem likely
17:01:57 <nirik> we could punt it down the road until it does. ;)
17:01:58 <mboddu> jlebon: Then we will get to it when we have it
17:02:05 <mboddu> nirik: +1
17:02:19 <jlebon> +1
17:02:23 <ksinny_> +1
17:02:23 <dustymabe> should I update the ticket?
17:02:38 <mboddu> dustymabe: Yes please and I will create the tags later today
17:02:39 <ksinny_> dustymabe: should be add s390x arch as well?
17:02:40 <nirik> so yeah, it does mean when you want to move from f30 to f31 we will need to change the inheritence and dist-repo config to use the new key
17:02:49 <mboddu> ksinny_: No need or arches
17:02:54 <nirik> but that shouldn't hopefully be too hard
17:02:56 <mboddu> of*
17:03:19 <dustymabe> mboddu: let's focus on that statement for a sec
17:03:27 <dustymabe> oops i meant niric
17:03:36 <dustymabe> nirik | so yeah, it does mean when you want to move from f30 to f31 we will need to change the inheritence and dist-repo config to use the new key
17:03:46 <dustymabe> nirik: ^^ can you elaborate ?
17:04:24 <nirik> so say we have f30-coreos-pool -> fedora-coreos-pool
17:04:39 <nirik> and a dist-repo script to make a dist-repo from fedora-coreos-pool.
17:04:40 <mboddu> When stable stream changes from f30 to f31, then fedora-coreos-pool inheritance should change to f31-coreos-pool and change the key for the dist-repo
17:05:02 <dustymabe> ok i might be mistaken
17:05:08 <mboddu> ^ is what I think nirik meant
17:05:12 <dustymabe> let me illustrate something and you all tell me if it's not possible
17:05:16 <nirik> right, when you want f31-coreos-pool -> fedora-coreos-pool and the dist repo signed by f31 key, we have to change that
17:05:44 <dustymabe> I was thinking we could have f30-coreos-pool and f31-coreos-pool both -> fedora-coreos-pool
17:05:47 <nirik> it's just a koji command and a commit to the tag2repo config.
17:06:15 <dustymabe> i.e. fedora-coreos-pool is just an aggregate
17:06:31 <dustymabe> of both
17:06:43 <nirik> I don't think thats possible.
17:06:51 <nirik> a tag has a option for 'parent'
17:07:34 <nirik> so perhaps the versioned ones are not of use then?
17:07:54 <dustymabe> maybe - jlebon and ksinny_ were you thinking the same thing I was ?
17:08:07 <ksinny_> dustymabe: yeah
17:08:20 * jlebon reads scrollback
17:08:33 <jlebon> right yeah
17:08:41 <nirik> you can chain them... ie, f31-coreos-pool -> f30-coreos-pool -> coreos-pool
17:08:42 <jlebon> can't we inherit from multiple versioned tags?
17:08:59 <dustymabe> nirik: you can chain but one will overwrite the other right ?
17:09:02 <nirik> there might be some way I am not aware of. ;)
17:09:11 <dustymabe> i.e. systemd in f30 would override systemd in f31 ?
17:09:14 <nirik> yes, last one wins
17:09:25 <dustymabe> ok so let's go back to the original problem
17:09:52 <dustymabe> wanted: a tag that contains all the packages we would consume for FCOS (in various streams at the same time)
17:09:59 <nirik> I can ask koji folks... I might just be unaware...
17:09:59 <mboddu> dustymabe: You can chain them but the latest of them winds
17:10:06 <mboddu> wins*
17:10:15 <dustymabe> problem: if we build backports we want the backport signed with the tag for that release of fedora
17:10:29 <dustymabe> so that problem led us to versioned tags
17:10:50 <dustymabe> so.. we could do this:
17:11:04 <dustymabe> we have versioned tags that are used to stage builds
17:11:16 <jlebon> how about have no inheritance then, and just tag them into fedora-coreos-pool manually?
17:11:19 <dustymabe> and then we have a process that just tags them over into fedora-coreos-pool after they are signed
17:11:38 <jlebon> dustymabe: :)
17:11:45 <nirik> robosign can do that sure.
17:11:51 <dustymabe> oh nice
17:11:59 <jlebon> i suspect backports will be occasional, so it shouldn't be an issue for us
17:12:03 <dustymabe> nirik: can you describe that process in just a little more detail?
17:12:04 <jlebon> and it's something we could automate
17:12:12 <nirik> foo-1.0.fc30 just was tagged into f30-coreos-pool. Sign it, move it to fedora-coreos-pool
17:12:29 <dustymabe> so robosign can do that automatically for us based on configuration?
17:12:35 <nirik> tag2distrepo sees that and makes dist repo
17:12:49 <nirik> yes. but it needs to know what key to sign with
17:12:55 <jlebon> oh, that's great!
17:13:09 <nirik> but f30-coreos-pool likely gives the hint. :)
17:13:10 <jlebon> then it can use the originating tag name for that, right?
17:13:15 <dustymabe> yeah I think that solves our exact problem
17:13:47 <dustymabe> any gaps I'm not aware of ?
17:14:08 <mboddu> jlebon: Nope, it cant use tag names, its based on the config - https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/robosignatory/files/robosignatory.production.py#n116
17:14:39 <mboddu> dustymabe: One more question
17:14:40 <jlebon> mboddu: right gotcha, that should work fine for us too
17:14:44 <nirik> we probibly need to see how dist-repo handles multiple keys
17:14:52 <dustymabe> assuming this is a good option for us - can we discuss the naming of the versioned tags ?
17:15:00 <nirik> I see that it can... but not sure how it works, never used it
17:15:27 <nirik> dustymabe: you want to name them f30-dustymabe-rules? :)
17:15:32 <mboddu> So, when we change from f30 to f31, do we need to untag all the builds in fedora-coreos-pool?
17:15:46 <mboddu> Which were f30 based
17:16:08 <ksinny_> nirik: so, foo-1.0.fc30 and foo-1.0.fc31 can co-exist in fedora-coreos-pool tag and fedora-coreos-pool dist-repo, correct?
17:16:09 <dustymabe> nirik: I would suggest something like f30-coreos-builds-unsigned or something like that - not f30-coreos-pool
17:16:40 <nirik> ksinny_: yes. I think so.
17:16:42 <mboddu> dustymabe: f30-coreos-pending?
17:16:48 <dustymabe> mboddu: we'd prefer to have both foo-1.0.fc30 and foo-1.0.fc31 at the same time as ksinny_ mentioned
17:16:49 <ksinny_> cool
17:16:54 <nirik> yeah, pending is usually what we use or signing-pending
17:16:56 <dustymabe> mboddu: f30-coreos-pending works for me
17:17:02 <mboddu> or f30-coreos-builds-signing-pending
17:17:40 <mboddu> Sorry, f30-coreos-signing-pending
17:17:49 <dustymabe> mboddu: that works
17:18:02 <dustymabe> mboddu: regarding 'mboddu | So, when we change from f30 to f31, do we need to untag all the builds in fedora-coreos-pool?'
17:18:07 <dustymabe> i think we don't want to untag anything
17:18:19 <jlebon> could also be f30-coreos-backports since it'll only be used for backports
17:18:20 <dustymabe> we want them all in there
17:18:26 <mboddu> dustymabe: Yeah, I got that
17:18:39 <dustymabe> jlebon: but the tag gets removed after the rpm is signed
17:18:46 <nirik> backports might be more descriptive
17:18:55 <nirik> but yeah
17:19:10 <dustymabe> cool deal
17:19:14 <jlebon> gotcha
17:19:17 <dustymabe> any outstanding open items ?
17:19:21 <mboddu> dustymabe: Another question, from f30 to f31 move
17:19:41 <mboddu> dustymabe: Ahhh, nvm, I am good
17:19:51 <nirik> so whats your process for building a backport? commit to dist-git, build against whatever, tag into fNN-coreos-signing-pending ?
17:20:01 <dustymabe> :) - feel free to ask - this is the time where we need to work out kinks :)
17:20:09 <jlebon> nirik: yeah I think that's what we'll do
17:20:28 <dustymabe> nirik: we will/should have branches within dist-git we can use
17:20:40 <mboddu> dustymabe: Nope, I am good, I might ask couple more questions when I am doing it (my brain kicks in while doing something) :D
17:20:51 <dustymabe> and we should be able to target a release using those branches I think
17:20:56 <mboddu> something = work
17:21:03 <jlebon> nirik: we should be able to just do `fedpkg build --target=fNN-coreos-signing-pending`, right?
17:21:12 <dustymabe> nirik: this is where we have been discussing that: https://github.com/coreos/fedora-coreos-tracker/issues/79
17:21:18 <nirik> dustymabe: ok. sure, although note that we don't allow deleting branches there, so it would exist forever.
17:21:30 <mboddu> jlebon: Nope, thats why I asked about the buildroot
17:21:33 <nirik> jlebon: yep
17:21:41 <nirik> wait, no, mboddu is right
17:21:53 <nirik> you need to build against the regular fedora target and tag it in
17:21:54 <mboddu> fNN-coreos-signing-pending is just a tag
17:21:56 <jlebon> gotcha, so we'll have to tag as a separate step them
17:22:01 <dustymabe> nirik: right - it would exist forever
17:22:44 <dustymabe> nirik aren't there rules somewhere about 'if this dist-git branch then use this build-target/tag' ?
17:22:55 <mboddu> jlebon: But creating a build target is not hard
17:23:00 <mboddu> dustymabe: Its part of fedpkg
17:23:18 <jlebon> mboddu: it'd be nice, since it'd mean we wouldn't pollute the regular tags
17:23:35 <dustymabe> yeah we definitely don't want to piss off maintainers
17:23:37 <jlebon> re. fNN-coreos-backports, i think it'd be cool if those pkgs remained tagged, so we have an easy way to see what we've backported
17:23:53 <jlebon> can't robosignatory just add a tag instead of removing *and* adding?
17:24:19 <dustymabe> nirik: mboddu could we get you to look through https://github.com/coreos/fedora-coreos-tracker/issues/79 to see if you have any sage advice for us ?
17:24:20 <jlebon> sorry, meant fNN-coreos-signing-pending
17:24:23 <mboddu> jlebon: "can't robosignatory just add a tag instead of removing *and* adding?" what do you mean?
17:24:24 <dustymabe> maybe after the meeting
17:24:46 <mboddu> dustymabe: Sure
17:24:46 <jlebon> higher up, dustymabe said:
17:24:47 <jlebon> 13:18:39 < dustymabe> jlebon: but the tag gets removed after the rpm is signed
17:25:03 <jlebon> i interpreted that to mean it gets untagged when it's moved to fedora-coreos-pool
17:25:18 <dustymabe> jlebon: yes that is my interpretation as well
17:25:26 <nirik> I don't know if it can do that... would have to look.
17:25:56 <nirik> dustymabe: sure. Will look at some point... likely not now. ;)
17:25:57 <jlebon> cool, if so, then i think fNN-coreos-backports would be the best name. otherwise, then it's really just to hack around signing, so signing-pending is fine
17:26:00 <dustymabe> jlebon: we could do that another way - we could add backport to the release of each rpm we backport
17:27:05 <jlebon> dustymabe: not sure i follow
17:27:09 <dustymabe> i.e. foo-2.backport.fc29
17:27:19 <dustymabe> just add it into the NVRA
17:27:56 <dustymabe> should also make it clearer if people report bugs for the maintainers to identify it is an issue in a backport package
17:27:58 <jlebon> ahh gotcha. yeah, i think we need to do that regardless
17:28:11 <dustymabe> in that case what you are suggesting isn't needed I don't think
17:28:30 <nirik> note that if you do that as a dist tag you need to be carefull as many specs use that in conditionals.
17:28:33 <jlebon> anyway, didn't mean to distract from the important items :)
17:28:48 <dustymabe> nirik: use what ?
17:28:54 <nirik> so I think we have everything, mboddu: you good?
17:29:19 <mboddu> nirik: Yes
17:29:32 <mboddu> dustymabe: Are you going to comment on the ticket on what is needed?
17:29:33 <nirik> dustymabe: dist = fc30, so you if you replace/override that with 'dist=backport.fc30' conditionals in specs could break. :)
17:29:45 <nirik> but I guess you were talking about just manually adding it.
17:30:14 <jlebon> yeah, i don't think we would override the dist rpm macro
17:30:15 <dustymabe> yeah I was talking about rather than updating the release from 1 to 2 we update it from 1 to 2.backport
17:30:30 <dustymabe> but hadn't given it a lot of thought
17:30:35 <dustymabe> mboddu: yes I'll update the ticket
17:30:53 <mboddu> dustymabe: Thanks
17:31:09 <mboddu> Okay, one ticket and 1:30 min
17:31:27 <mboddu> I should definitely close this meeting, we are way over time
17:31:40 <dustymabe> the ticket was #8294 correct?
17:31:42 <mboddu> We can discuss it in #fedora-releng if anything more is needed
17:31:58 <mboddu> dustymabe: Yes, https://pagure.io/releng/issue/8294
17:32:05 <mboddu> Thanks everyone for joining
17:32:07 <jlebon> thanks all for all the help! 👍
17:32:13 <jlebon> mboddu++
17:32:13 <zodbot> jlebon: Karma for mohanboddu changed to 16 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:32:14 <dustymabe> thanka!
17:32:16 <jlebon> nirik++
17:32:16 <zodbot> jlebon: Karma for kevin changed to 42 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:32:20 <mboddu> #endmeeting