15:34:00 <dgilmore> #startmeeting RELENG (2017-02-20)
15:34:00 <zodbot> Meeting started Mon Feb 20 15:34:00 2017 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:34:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:34:00 <zodbot> The meeting name has been set to 'releng_(2017-02-20)'
15:34:00 <dgilmore> #meetingname releng
15:34:00 <zodbot> The meeting name has been set to 'releng'
15:34:00 <dgilmore> #chair dgilmore nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu
15:34:00 <zodbot> Current chairs: dgilmore masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll
15:34:03 <dgilmore> #topic init process
15:34:14 <ignatenkobrain> .hello ignatenkobrain
15:34:15 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
15:34:19 <marc84> hi everyone
15:34:27 <mboddu> .hello mohanboddu\
15:34:28 <zodbot> mboddu: Sorry, but you don't exist
15:34:34 <mboddu> .hello mohanboddu
15:34:36 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
15:34:42 <nirik> .hello kevin
15:34:43 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
15:34:48 <puiterwijk> .hello puiterwijk
15:34:49 <sharkcz> .hello sharkcz
15:34:49 <zodbot> puiterwijk: puiterwijk 'Patrick "マルタインアンドレアス" Uiterwijk' <puiterwijk@redhat.com>
15:34:52 <zodbot> sharkcz: sharkcz 'Dan Horák' <dan@danny.cz>
15:36:36 <maxamillion> .hello maxamillion
15:36:39 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:36:40 <dgilmore> #topic #6601 Migrate the rel-eng tickets from (old) trac
15:36:44 <Son_Goku> .hello ngompa
15:36:45 <zodbot> Son_Goku: ngompa 'Neal Gompa' <ngompa13@gmail.com>
15:36:48 <dgilmore> https://pagure.io/releng/issue/6601
15:36:53 <dgilmore> lets get moving
15:37:39 <dgilmore> nirik: I asked pingou to join, while we wait a quick sec do you have any update?
15:37:55 <nirik> no. I also asked him to join. :)
15:38:02 <nirik> he's around, so hopefully soon here.
15:38:36 <bowlofeggs> .hello bowlofeggs
15:38:37 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <randy@electronsweatshop.com>
15:38:41 <dgilmore> to note here
15:39:08 <nirik> hey pingou. Any chance to look at the releng ticket mess ? :)
15:39:34 <pingou> yeah, we should
15:39:39 <dgilmore> Last week threebean set up a process to sync the pagure issues into a internal red hat issue tracker so that mboddu's and my management chain have more visibility into what's going on in Fedora
15:40:09 <pingou> that might be fun if we push the old tickets
15:40:16 <dgilmore> pingou: indeed
15:40:21 <nirik> yeah, they will get a flood. ;)
15:40:36 <pingou> or I'll poke threebean before doing the final push
15:40:55 <dgilmore> we likely want open ones synced
15:41:11 <dgilmore> pingou: so I guess you are saying you have not looked at it?
15:41:26 <dgilmore> fedorahosted.org is being shut down next week right?
15:41:44 <Son_Goku> does that also include the project /releases folders that people are still using?
15:41:57 <pingou> dgilmore: I started, you know when I was asking for the read access back
15:42:05 <Son_Goku> because there are a number of projects that are still using those
15:42:19 <dgilmore> Son_Goku: that is off topic for this discussion
15:42:29 <dgilmore> pingou: okay
15:42:32 <Son_Goku> for shutting down fedorahosted.org?
15:42:32 <nirik> yes, it includes everything (except lists.fedorahosted.org)
15:42:39 <dgilmore> pingou: what is it going to take to get resolved?
15:42:50 <pingou> time and some hair splitting
15:43:08 <dgilmore> do we know the problem issues?
15:43:25 <pingou> issue identifiers is the issue
15:43:36 <pingou> we'll need to decide which identifiers we want to keep stable
15:43:49 <dgilmore> I am confused now
15:43:51 <pingou> because I doubt we'll be able to squeeze all the FH tickets in b/w the pagure ones
15:44:11 <dgilmore> as I understood the problem there was some conflicts with attachments to issues?
15:44:38 <dgilmore> pingou: what do you mean by b/w?
15:44:39 <pingou> conflicts w/ attachments? no idea what you're referring to
15:45:04 <nirik> the last problem was usernames of ticket filers
15:45:11 <dgilmore> pingou: that when nirik tried to import the issues it failed as there was issue with some attachements
15:45:13 <nirik> because email2trac had been used
15:45:32 <nirik> so instead of username they had "Foo bar baz <foobar@example.com>"
15:45:50 <dgilmore> afaik most of that was all spam
15:46:00 <nirik> there was an attachment issue at one point... but yeah lots of issues.
15:46:03 <pingou> in b/w as in: there is a gap in the identifier used on the pagure side, so we thought we would squeeze the FH tickets in this gap on pagure, but I'm not 100% sure it'll work
15:46:12 <nirik> dgilmore: all the ones left were legit.
15:46:23 <nirik> we have now:
15:46:45 <ignatenkobrain> +++++
15:46:53 <nirik> tickets filed in pagure when it first was setup === tickets imported from trac, but incompletely === more tickets after that
15:47:10 <nirik> pingou: it should still work if we can fix the imported ones
15:47:43 <nirik> so what we need to do is dump them all out, fix the issue filer on those email2trac ones and reimport then entire thing?
15:47:51 <pingou> yup
15:47:58 <pingou> that's at least my idea
15:48:20 * nirik nods.
15:48:40 <dgilmore> not sure if every email would resolve to a fas account
15:48:40 <ignatenkobrain> +++
15:48:45 <dgilmore> ignatenkobrain: ?
15:48:52 <ignatenkobrain> oh god
15:48:58 <ignatenkobrain> my keyboard is broken
15:49:00 <ignatenkobrain> sorry
15:49:05 <dgilmore> okay
15:49:08 <nirik> dgilmore: yeah, some are obvious
15:49:12 <nirik> some not so much so
15:49:13 <pingou> I'll likely want to release 2.13 before we import so that loading the tickets is done via its own service
15:49:31 <nirik> if we cant figure it we should just set them to nobody or something
15:49:36 <pingou> +
15:49:38 <pingou> 1
15:50:14 <dgilmore> #info current status is that issues had been filed via email2trac, we can not resolve all emails to fas accounts.
15:50:30 <dgilmore> #info we should set all unknown to nobody
15:50:30 <nirik> https://fedorahosted.org/rel-eng/query?reporter=~%3C&col=id&col=summary&col=status&col=type&col=milestone&col=component&order=priority
15:50:50 <nirik> 109 ticket commits, but less than 109 tickets
15:50:56 <dgilmore> #info pingou wants to wait until 2.13 of pagure is deployed
15:51:02 <nirik> no, that might actually be 109 tickets
15:51:11 <dgilmore> pingou: when do you plane to do the deployment
15:51:22 <dgilmore> #info we have until Feb 28 to complete task
15:51:51 <dgilmore> https://fedorahosted.org/rel-eng/ticket/26 we could probably just delete
15:52:03 <pingou> dgilmore: got 2 PRs to review and merge, then we'll see what's left in the PR queue but I'd like to do it this week, sooner rather than later
15:53:31 <dgilmore> pingou: please do if you can
15:53:59 <dgilmore> anything else to cover here?
15:54:24 <dgilmore> #topic #6577 Fedora 26 mass rebuild
15:54:25 <dgilmore> https://pagure.io/releng/issue/6577
15:54:36 <dgilmore> so the mass rebuild from ourside is done
15:55:47 <nirik> yep.
15:56:07 <ignatenkobrain> looks like pkgconf change is fine
15:56:09 <nirik> I think next time we might want to look at using the second sign vault and another sign bridge so we dont' backlog signing
15:56:34 <pingou> +1 yeah
15:56:35 <dgilmore> #action mboddu to run the scripts that output failure and needs rebuild lists for at least 4 more weeks
15:56:57 <dgilmore> nirik: not sure thats really possible
15:57:08 <nirik> yeah, it might not be easy... just a thought.
15:57:18 <puiterwijk> dgilmore: it should with the new sigul version...
15:57:34 <puiterwijk> The new one has automatic syncing between two vaults
15:57:35 <dgilmore> http://dl.fedoraproject.org/pub/alt/mass-rebuild/f26-failures.html
15:57:40 <dgilmore> http://dl.fedoraproject.org/pub/alt/mass-rebuild/f26-need-rebuild.html
15:58:20 <nirik> well, as long as we don't change valut content...
15:58:27 <dgilmore> https://bugzilla.redhat.com/show_bug.cgi?id=1423041
15:58:46 <puiterwijk> nirik: you'd still want to sync logs I think :). But yes, that'd make it even easier
15:58:51 <dgilmore> puiterwijk: I do not think thats the issue
15:59:05 <dgilmore> more I am wondering about how load balancing the requests would work
15:59:14 <nirik> well, we don't really do anything with logs currently, but meh..
15:59:22 <nirik> it wouldn't work to load balance it.
15:59:30 <nirik> I am saying to make 2 seperate ones
15:59:44 <dgilmore> nirik: they would start stomping on each other
15:59:51 <dgilmore> trying to sign the same rpms
16:00:07 <nirik> well, if one is doing mass rebuilds and the other all the rest... there should be no overlap?
16:00:22 <puiterwijk> Not if you keep the m separate. One bridge01 and one bridge02
16:00:42 <dgilmore> nirik: the load balancing of that still has to happen
16:00:45 <puiterwijk> (you probably don't even need two bridges, but that's another addition for the future)
16:00:50 <nirik> yeah. but perhaps it's all too much complexity and people should just be more patient. ;)
16:01:07 <dgilmore> but I guess running two instances of robosignatory configured differently could do that
16:01:10 <puiterwijk> dgilmore: the idea was to just add a second bridge that uses the second vault.
16:01:19 <puiterwijk> Yep
16:01:42 <dgilmore> we will hit similiar issues in the next week
16:01:54 <dgilmore> when we make a f27 key and have to resign all of rawhide
16:02:43 <dgilmore> #info signing everything slowed down signing overall
16:02:56 <nirik> the other option might be to add some kind of scheduling to robosign...
16:03:08 <dgilmore> #info going forward we could look at ways to make signing scale better
16:03:12 <nirik> ie, prefer some tags over others
16:03:14 <puiterwijk> dgilmore: for next time, I would suggest to juse use the standard autosigning for the mass rebuild... IF it had been setup in advance, we wouldn't have had any problems
16:03:30 <puiterwijk> Or at least less
16:03:42 <dgilmore> puiterwijk: there will be some
16:03:55 <puiterwijk> Sure. But way less, and especially no further problems when merging in
16:04:04 <dgilmore> and we will hit the probnlem likely worse when moving rawhide to the new key
16:04:15 <puiterwijk> Yeah, agreed.
16:04:16 <dgilmore> as nothing will have been autosigned with the f27 key
16:04:44 <nirik> well, if we manually sign f27 with a small batch number... then enable it in robosign...
16:04:50 <nirik> it might not be that disruptive
16:05:18 <dgilmore> nirik: as we do things today. we have a window of about 2 days to sign everything with the f27 key
16:05:33 <puiterwijk> Right. What day are you planning to create that key? Depending on that, I might have chance to look at the prioritization/scaling...
16:05:33 <dgilmore> I guess we should make the f27 key this week
16:06:05 <dgilmore> #action dgilmore to make f27 key today/tomorrow
16:06:07 <puiterwijk> Okay, this week is a 99% "no" on time for me, unless I can get an ack from people to drop other stuff
16:06:19 * dgilmore is taking this afternoon off as MAson is off school
16:06:34 <nirik> if we have a key I can start manually signing with it. ;)
16:06:36 <bowlofeggs> you can use this for the f27 signing key: 367316
16:06:43 <puiterwijk> bowlofeggs: yeah, no
16:06:46 <bowlofeggs> haha
16:06:49 <dgilmore> https://fedoraproject.org/wiki/Releases/26/Schedule
16:07:04 <dgilmore> we have branching next week
16:07:10 <dgilmore> on Tuesday
16:07:30 <dgilmore> lets change topics as I think mass rebuild is done
16:07:47 <dgilmore> #topic Fedora 26 movement
16:08:08 <dgilmore> #info this week we need to make the Fedora 27 gpg key for rpms
16:08:28 <dgilmore> #info this week we need to branch all of the compose configs for Fedora 26
16:08:50 <dgilmore> https://pagure.io/pungi-fedora
16:09:04 <dgilmore> https://pagure.io/fedora-kickstarts/
16:09:17 <dgilmore> https://pagure.io/fedora-lorax-templates
16:09:29 <dgilmore> https://pagure.io/fedora-atomic
16:09:52 <dgilmore> https://pagure.io/workstation-ostree-config
16:10:04 <dgilmore> all need branching
16:10:12 <maxamillion> random side note, do have a doc that references all of those and what their purpose in the releng pipeline is?
16:10:32 <dgilmore> https://github.com/rpm-software-management/mock will need an update with new mock configs
16:10:41 <dgilmore> maxamillion: likely not
16:10:46 <mboddu> dgilmore: I can help with branching
16:11:05 <dgilmore> https://docs.pagure.org/releng/
16:11:15 <maxamillion> dgilmore: we probably should ... if I can find some time this week I'll write one up
16:11:18 <dgilmore> mboddu: its all on you to do.
16:11:25 <mboddu> dgilmore: okay
16:12:07 <nirik> dgilmore: ignatenkobrain had a topic and has to leave soon...
16:12:12 <dgilmore> we will also need to branch https://pagure.io/fedora-repos https://pagure.io/fedora-release
16:12:26 <dgilmore> nirik: okay thats news to me
16:12:28 <ignatenkobrain> I don't need to leave soon, but at least I need to know when I should come back :)
16:12:34 <dgilmore> we can look at that after this
16:12:41 <nirik> oh, sorry, misunderstood then
16:13:06 <dgilmore> ignatenkobrain: well random topics are at the end of the meeting in open floor
16:13:14 <nirik> side note on fedora-repos: it would be nice if we had a link from f26 key to rawhide or f27 key to rawhide when we change it. Would help updates.
16:13:24 <dgilmore> today we are going to have to cut some things short as we are running out of time
16:13:24 * nirik should file an issue
16:13:53 <ignatenkobrain> dgilmore: I wouldn't name it as random because we discussed that topic on ML and Kevin proposed to join next meeting and discuss thing
16:14:43 <dgilmore> #info all packages for rawhide have to be signed with the f27 key and autosigning setup by COB Monday, so that as soon as we land all the changes for branching rawhide switches to f27 keys
16:15:01 <dgilmore> ignatenkobrain: its not in a issue with the meeting keyword?
16:15:06 <dgilmore> ignatenkobrain: if so its random
16:15:10 <dgilmore> as its not in the agenda
16:15:15 <ignatenkobrain> dgilmore: no one told me to do this =(
16:15:25 <dgilmore> ignatenkobrain: afaik its widely known
16:15:27 <ignatenkobrain> moreover, I didn't see agenda in ML for today's meeting
16:15:29 <Son_Goku> dgilmore, it is not
16:15:37 <dgilmore> https://fedoraproject.org/wiki/ReleaseEngineering/Meeting_Process
16:15:41 <Son_Goku> I didn't even know and I'm only here because ignatenkobrain reminded me
16:15:54 <dgilmore> Son_Goku: whats not?
16:16:01 <Son_Goku> what the agenda was and stuff
16:16:10 <Son_Goku> hell, I didn't even know a meeting was today until he told me
16:16:13 <ignatenkobrain> well, let's don't discuss this now..
16:16:22 <Son_Goku> anyway, brr
16:16:54 <dgilmore> I think that all gives a quick overview of the f26 branching status and what has to be done this week
16:17:19 <dgilmore> ignatenkobrain: what is your topic as I am not aware of it
16:17:41 <ignatenkobrain> dgilmore: the porting releng tools to DNF
16:17:53 <dgilmore> #topic porting releng tools to DNF
16:17:53 <ignatenkobrain> unfortunately I was not able to get overview in ML
16:18:15 <dgilmore> ignatenkobrain: there is no clear overview sadly
16:18:16 <ignatenkobrain> this is becoming more and more hot topic
16:18:25 <dgilmore> some of it is waiting on dnf to be suitable
16:18:34 <nirik> I tried to outline what I thought the current status was... it's not super clear what to do currently.
16:18:35 <dgilmore> some of it is waiting on people to port tools
16:18:49 <dgilmore> We still have to fully support yum as well as dnf
16:18:57 <dgilmore> and it needs to be configurable
16:19:13 <Son_Goku> well, live and ARM images are using DNF now
16:19:26 <dgilmore> ignatenkobrain: afaik with your working with lsedlar pungi is almost ready
16:19:38 <dgilmore> Son_Goku: Live has used dnf for years
16:19:45 <dgilmore> well over a year
16:19:51 <ignatenkobrain> we (Rust SIG) are started with packaging rust crates and we are just stuck because for our needs we MUST use rich deps
16:19:54 <ignatenkobrain> there's no other way
16:19:54 <dgilmore> when we switched to livemedia-creator
16:20:19 <dgilmore> and arm will be considered supported as soon as we drop using appliance-creator which we will be doing this week
16:20:39 <Son_Goku> appliance-creator is already using dnf, so what you decide to break by switching tools again is up to you
16:20:42 <maxamillion> ignatenkobrain: there's a couple things that are to be ported to dnf that's on my TODO list that I hope to get to this week
16:20:48 <nirik> dgilmore: is there any current news on koji signed repos?
16:20:55 <dgilmore> ignatenkobrain: until we sort out changes for bodhi we are stuck with yum
16:21:08 <ignatenkobrain> dgilmore: what kind of changes?
16:21:09 <dgilmore> nirik: there was movement on signed repos last week
16:21:11 <maxamillion> ignatenkobrain: I'm going to add dnf support to pymultilib and then port mash to use that (hopefully)
16:21:17 <dgilmore> ignatenkobrain: its not really known
16:21:23 <dgilmore> ignatenkobrain: it could be using signed repos
16:21:28 <dgilmore> it could be porting mash
16:21:29 <Son_Goku> maxamillion: that should resolve the bodhi issue
16:21:43 <ignatenkobrain> dgilmore: I need some faster solution
16:21:48 <maxamillion> Son_Goku: it'll be a little time before all that stuff goes live in the infra, but hopefully
16:21:48 <dgilmore> python-multilib while not directly relying on yum relies on yum
16:22:00 <dgilmore> you can only pass it yum repo objects
16:22:22 <dgilmore> ignatenkobrain: we have a goal of supporting dnf fully by f27
16:22:23 <Son_Goku> it needs to be refactored to support dbo too
16:22:45 <ignatenkobrain> dgilmore: f27 is quite far =(
16:23:02 <maxamillion> Son_Goku: dbo?
16:23:02 <dgilmore> Son_Goku: I know that lsedlar was looking at throwing the python-multilib code away and using something cleaner
16:23:09 <Son_Goku> dgilmore: that might be better
16:23:11 <maxamillion> dgilmore: wait, what?
16:23:14 <dgilmore> ignatenkobrain: we have 1 week to land changes for f26
16:23:19 <Son_Goku> maxamillion: I call dnf base objects "dbo"
16:23:38 <maxamillion> dgilmore: should I not add dnf support to pymultilib and port mash over then?
16:23:41 <maxamillion> Son_Goku: ah
16:24:03 <Son_Goku> when livecd-tools was ported from yum to dnf, that's what we moved to
16:24:08 <dgilmore> maxamillion: basing a multilib python module on pungi's code not mash's as python-multilib does today
16:24:08 <Son_Goku> dnf.Base objects
16:24:13 <ignatenkobrain> dgilmore: so what would be some solution to implement within this week to support rich deps?
16:24:26 <ignatenkobrain> I can spend time on this and do work
16:24:29 <dgilmore> ignatenkobrain: we do not have any capacity to do anything
16:24:46 <ignatenkobrain> dgilmore: you do have capacity -> ignatenkobrain
16:24:47 <dgilmore> ignatenkobrain: all of the options need a lot of work.
16:24:57 <dgilmore> ignatenkobrain: its all more than 1 weeks work
16:25:04 <ignatenkobrain> that suck
16:25:11 <Son_Goku> well, actually
16:25:12 <dgilmore> ignatenkobrain: Ideally we would move to signed repos in koji
16:25:12 <Son_Goku> I don't think so
16:25:19 <Son_Goku> we can ignore koji for the most part
16:25:23 <dgilmore> that needs signed repos to go in
16:25:26 <ignatenkobrain> dgilmore: I think I've seen code of signed repos...
16:25:27 <Son_Goku> pungi is almost done
16:25:33 <dgilmore> and its needs bodhi to be changed to call and use it
16:25:36 <ignatenkobrain> and basically it's bloated with yum, no?
16:25:46 <Son_Goku> and if maxamillion and ignatenkobrain can knock out mash, we're golden for F26
16:25:51 <dgilmore> but it would also need a python multilib module that supported yum and dnf
16:26:02 <Son_Goku> that knocks out all the hot paths that cause issues
16:26:16 <dgilmore> ignatenkobrain: we could port mash to configurably use dnf or yum
16:26:26 <ignatenkobrain> dgilmore: that works for me as a temporary solution
16:26:51 <dgilmore> ignatenkobrain: its a lot of throwaway work
16:26:59 <Son_Goku> not really
16:27:07 <dgilmore> our long term plan has to been to kill mash entirely
16:27:17 <Son_Goku> that's been said for two years now
16:27:22 <Son_Goku> at this point, it's not happening
16:27:28 <dgilmore> as it has been to kill appliance-tools and livecd-tools
16:27:37 <nirik> things take time to get done. ;)
16:27:57 <dgilmore> particullary when majorly under resourced
16:28:00 <ignatenkobrain> dgilmore: for me it doesn't matter because I want to make Fedora 1st class support of Rust and because of this thing I just can't
16:28:34 <ignatenkobrain> so even it's throwaway work, but if it will allow me to do my other job -- I'm fine with it
16:28:49 <Son_Goku> and besides, it's more example code for how to use DNF
16:28:53 <Son_Goku> which is always good
16:28:54 <dgilmore> ignatenkobrain: to me the best thing is to have a multilib python module that can use yum or dnf
16:29:16 <dgilmore> then have pungi, koji signed-repos and potentially mash use that
16:29:30 <ignatenkobrain> dgilmore: so 1) port pymultilib to support both yum and dnf 2) port mash to pymultilib ?
16:29:31 <dgilmore> then we have just one code base for multilib implementation
16:29:45 <Son_Goku> ignatenkobrain, sounds like that's what he wants
16:29:56 <maxamillion> yeah, that's what's on my TODO list
16:30:10 <maxamillion> but it sounds like lsedlar is considering going a different route so I'll want to sync with him first
16:30:11 <dgilmore> ignatenkobrain: sure, though talk to lsedlar as he was looking at basing a new module from pungi's multilib code and not mash's
16:30:32 <nirik> well, and 3) port mash to dnf right?
16:30:39 <nirik> (configurably)
16:30:58 <ignatenkobrain> nirik: I thought that once we port mash to pymultilib it will not depend on yum ?
16:31:00 <Son_Goku> nirik: 3 is implied by 1 and 2
16:31:01 <dgilmore> nirik: mash would need some work to have a config option to use dnf
16:31:09 <maxamillion> nirik: pymultilib would be dnf or yum on the backend and if mash it ported to that then why 3) ?
16:31:16 * dgilmore notes that it would only come into play for f26 and up
16:31:33 <nirik> I'm not so sure of that, but ok
16:31:46 <dgilmore> as dnf and yum give different results we must not change how multilib is done in stable releases
16:31:49 <ignatenkobrain> dgilmore: I don't care THAT much about older versions at this moment
16:32:18 <ignatenkobrain> but I care about upcoming release
16:32:21 <ignatenkobrain> which is f26
16:32:21 <nirik> maxamillion: because I am not sure mash only uses yum for multilib... but I could be wrong. I recall it passing around a bunch of yum objects
16:32:27 <dgilmore> ignatenkobrain: bodhi will be enabled for f26 on 2017-03-07
16:32:45 <dgilmore> ignatenkobrain: we also need to get a dnf using pungi in use this week
16:32:54 <dgilmore> and afaik that may not be possible yet
16:32:55 <ignatenkobrain> dgilmore: so basically we have 2 weeks to make all things done?
16:33:01 <dgilmore> ignatenkobrain: 1 week
16:33:16 <Son_Goku> half a week
16:33:24 <maxamillion> nirik: ah ok
16:33:27 <ignatenkobrain> 3 is next fri
16:33:28 <dgilmore> ignatenkobrain: before branching next tuesday
16:33:31 <nirik> 15minutes! :) sorry...
16:33:32 <ignatenkobrain> ah god
16:33:50 <Son_Goku> ignatenkobrain: you have four days to save the world :)
16:34:06 <dgilmore> ignatenkobrain: though the mash changes could land a little after branching
16:34:16 <dgilmore> but we really should get pungi in place this week
16:34:41 <ignatenkobrain> I don't really agree how it has been done, but doing it differently will take lot more time
16:35:11 <dgilmore> ignatenkobrain: mboddu has been lookinga t whats needed to port everything to dnf
16:35:22 <dgilmore> which is more than just this problem space
16:35:31 <dgilmore> in order to move to python3
16:35:48 <ignatenkobrain> dgilmore: for this topic I'm interested only in paths which block us from rich deps
16:35:54 <dgilmore> in which case we will hit different issues
16:36:48 <dgilmore> ignatenkobrain: I think the only things that will be effected right now is composes and updates, however there is probably corner cases where things will break
16:36:59 <dgilmore> like broken deps reports for branched and rawhide
16:37:17 <ignatenkobrain> composes == pungi, right?
16:37:24 <ignatenkobrain> updates == bodhi + mash + ...
16:37:31 <dgilmore> which is generated by the spam-o-matic script in mash
16:37:37 * ignatenkobrain is not that experienced with releng pipeline
16:37:39 <dgilmore> ignatenkobrain: correct
16:38:15 * dgilmore would like to wrap this up as we are over time
16:38:53 <ignatenkobrain> dgilmore: can you summarize please?
16:39:00 <ignatenkobrain> ;)
16:40:05 <dgilmore> #info shortest path to using dnf is to have a multilib python module that supports yum and dnf, porting pungi and mash to using those. koji signed repos can then switch to and use it also
16:40:11 <dgilmore> was doing so
16:40:29 <ignatenkobrain> sounds like a plan
16:40:45 <dgilmore> #info that does not account for any other pieces where we have scripts and tools that use yum
16:40:59 <dgilmore> #info so there may be unknown breakage if we changed over
16:41:13 <nirik> spam-o-matic might not be too hard to move... it's just using repoclosure I think...
16:41:38 <dgilmore> #info pungi would need to land this week and mash would need to get its way to the bodhi-backend before alpha freeze on 2017-03-07
16:41:47 <dgilmore> nirik: its in mash
16:41:52 <nirik> yep.
16:42:08 <dgilmore> so i am assume it will handled in getting mash done
16:42:10 <nirik> does pungi use repodiff? I think mash does also for it's reports
16:42:44 <dgilmore> nirik: the diff is in compose-utils https://pagure.io/compose-utils
16:43:01 <nirik> ok
16:43:26 <dgilmore> I have been meaning to file an issue to make the compose repot more useful
16:43:35 <nirik> ignatenkobrain: does that tell you what to work on then?
16:43:53 <ignatenkobrain> nirik: it does
16:44:02 <nirik> (and BTW, many thanks for your time on things... it is appreciated. )
16:44:07 <dgilmore> ignatenkobrain: I would really like the long standing dnf usability bugs fixed first
16:44:18 <dgilmore> but I guess that they will still languish
16:45:02 <Son_Goku> dgilmore: badger jsilhan about those :)
16:45:05 <dgilmore> part of me does not want to migrate to dnf as we will lose valuable debuging information
16:45:11 <Son_Goku> wut
16:45:25 <Son_Goku> dnf 2.0 has nearly all of the info that yum presented
16:45:40 <dgilmore> dnf 2.0 is my mind is not close to useful
16:45:50 <ignatenkobrain> hopefully, dnf 3.0 will be complete and proper rewrite
16:45:58 <dgilmore> its a little better but it is still missing most of what we need
16:46:09 <ignatenkobrain> but I would not expect that to happen in near 1yr
16:46:38 <dgilmore> mboddu: would you like to present some of your findings?
16:46:41 <ignatenkobrain> dgilmore: without complete redesign it's not possible to do some things =(
16:47:31 <mboddu> dgilmore: all of the tools and their respective yum usage is in taiga stories, let me find the stories
16:49:10 <mboddu> https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-tooling/us/691
16:49:56 <mboddu> the spreadsheet has all the list of tools and yum usage
16:50:20 <dgilmore> mboddu: can you please give a brief summary
16:51:37 <mboddu> dgilmore: sure
16:54:31 <mboddu> I created the above spreadsheet which has the releng tools that needs dnf porting. I looked at Pungi, Mash, Fedora-Packager and Releng scripts and listed out all the imports of yum. I am currently looking at releng scripts to port to dnf.
16:56:28 <dgilmore> what spreadsheet?
16:56:50 <dgilmore> lets really wrap up we are nearly 30 minutes over
16:57:08 <mboddu> dgilmore: sorry, I linked to the taiga ticket which has the link to the spreadsheet. https://mohanboddu.fedorapeople.org/yum-dnf.ods
16:57:58 <dgilmore> mboddu: so the summary is what?
16:58:14 <dgilmore> how much work are we looking at and what is the impact?
16:58:26 <dgilmore> it may be some scripts we just no longer need
16:59:41 <dgilmore> lets take this out of band
16:59:47 <dgilmore> #topic open floor
16:59:58 <dgilmore> does anyone have anything else they want to cover?
17:00:19 <dgilmore> #info s390 builder situation looks to be getting resolved soon
17:01:00 <Son_Goku> what situation?
17:01:06 <Son_Goku> the merging into primary koji or something else?
17:02:49 <Son_Goku> dgilmore: awesome
17:03:14 <dgilmore> thanks bowlofeggs
17:03:19 <dgilmore> lets wrap up
17:03:33 <dgilmore> #endmeeting