15:37:07 <dgilmore> #startmeeting RELENG (2014-09-22)
15:37:07 <zodbot> Meeting started Mon Sep 22 15:37:07 2014 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:37:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:37:12 <dgilmore> #meetingname releng
15:37:12 <zodbot> The meeting name has been set to 'releng'
15:37:12 <dgilmore> #chair dgilmore nirik tyll sharkcz bochecha masta pbrobinson
15:37:12 <zodbot> Current chairs: bochecha dgilmore masta nirik pbrobinson sharkcz tyll
15:37:13 <dgilmore> #topic init process
15:37:23 <dgilmore> who alls here?
15:37:35 * bochecha_ is here
15:37:45 * sharkcz is here
15:37:54 * nirik waves. hola.
15:38:12 <tyll> Hi there
15:39:20 <dgilmore> lets get started :)
15:39:41 * pbrobinson is here
15:39:54 <dgilmore> #topic #5931 [Proposal] Move new branch and unretire requests to pkgdb2
15:39:58 <dgilmore> pingu?
15:40:33 <dgilmore> i pinged pingu in #fedora-releng
15:40:43 <dgilmore> lets give him a minute
15:41:24 <pingou> I was AFK all last week, so nothing new compare to the week before for me
15:41:33 <dgilmore> okay cheers
15:41:42 <pingou> I still have some question and want to figure out some things
15:41:53 <tyll> #info nothing new
15:41:55 <pingou> I'll try to send an email about them this week
15:42:07 <dgilmore> #topic #5967 Enable source repo generation
15:42:09 <tyll> #action pingou seend an email about open questions
15:42:18 <dgilmore> #undo
15:42:18 <zodbot> Removing item from minutes: ACTION by tyll at 15:42:09 : pingou seend an email about open questions
15:42:19 <dgilmore> #undo
15:42:19 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x126c2990>
15:42:27 <dgilmore> #action pingou seend an email about open questions
15:42:27 <tyll> #action pingou seend an email about open questions
15:42:31 <dgilmore> bahh
15:42:34 <tyll> sorry
15:42:35 <bochecha_> ^_^
15:42:40 <dgilmore> tyll: its okay :)
15:42:41 <pingou> twice more work
15:42:45 <pingou> thanks guys! :D
15:42:45 <dgilmore> #topic #5967 Enable source repo generation
15:42:49 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5967
15:42:57 <dgilmore> so i failed to ask extra questions here
15:43:09 <dgilmore> #action dgilmore to actually ask questions
15:43:21 <dgilmore> #topic #4071 Block pushes to origin/ in gitolite ACLs
15:43:27 <dgilmore> https://fedorahosted.org/rel-eng/ticket/4071
15:43:53 <bochecha_> I've attached a patch that adds the hook to ansible
15:44:09 <tyll> #info < bochecha_> I've attached a patch that adds the hook to ansible
15:44:20 <bochecha_> but it would add it to new repos only (i.e the ones created after we'd deploy the patch)
15:44:46 <dgilmore> bochecha_: we would probably want to have a one off script to apply it to all repos
15:44:54 <bochecha_> dgilmore, that was my question :)
15:45:18 <bochecha_> I didn't wknow whether we wanted that, or something part of the ansible deployment that would check all hooks in all repos, making sure they have everything they need
15:45:33 <tyll> #action bochecha_ write a script to add hook to all existing repos
15:45:42 <bochecha_> if we go with a one off script, i'll start working on it tomorrow
15:45:46 <bochecha_> tyll, thanks :)
15:46:07 <tyll> in theory the script should be enough
15:46:51 <dgilmore> bochecha_: i think a one off script to run is fine
15:46:55 <bochecha_> alright
15:47:10 <nirik> we have a script already that checks the repos
15:47:17 <bochecha_> nirik, oh, any link to that?
15:47:23 <nirik> weekly I think? might be good to just be in there? check the hooks and add if not.
15:47:32 <bochecha_> nirik, definitely
15:47:42 <nirik> I can dig it up.
15:47:42 <dgilmore> thats probably fine also
15:48:03 <tyll> #info there is already a script to check repos weekly
15:49:02 <nirik> /usr/local/bin/git-check-perms I think is the one I was thinking of.
15:49:10 <nirik> we added fedmsg hooks in there in the past.
15:49:16 <tyll> #info /usr/local/bin/git-check-perms
15:50:16 <bochecha_> alright, I'll have a look, thanks
15:50:24 <nirik> cool
15:50:31 <dgilmore> bochecha_: echo "${refname}" | grep -q 'origin/' && exit 1 || exit 0
15:50:49 <dgilmore> bochecha_: shouldnt that be echo "${refname}" | grep -q '^origin/' && exit 1 || exit 0
15:50:58 <bochecha_> nope
15:51:04 <dgilmore> to make sure that it starts with origin/
15:51:09 <bochecha_> refname will be refs/head/origin/foobar
15:51:35 <bochecha_> so it could be « grep -q '^refs/head/origin/' » eventually
15:51:35 <dgilmore> okay we should fix up the grep then
15:51:45 <bochecha_> but not '^origin/'
15:51:51 <tyll> it might be always unintented to use origin/ in the refs
15:52:12 <tyll> /origin/ might be an alternative
15:52:17 <dgilmore> it would be silly if someone did but they could do foo/origin/
15:52:19 <bochecha_> sure
15:55:00 <tyll> #info regex in hook needs to be adjusted to not block valid branch names
15:55:56 <dgilmore> that's my only comment on it
15:56:31 * bochecha_ will fix tomorrow, along with working on the script
15:56:32 <dgilmore> lets move on
15:57:00 <dgilmore> #action bochecha to update the regex and provide script to do one off migration
15:57:08 <dgilmore> #topic #5329 RFE: Send branched report only when there is any change committed
15:57:15 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5329
15:57:24 <dgilmore> so this would need to go into buildbranched
15:57:35 <tyll> #info buildbranched needs to be adjusted for this
15:57:44 <dgilmore> and I thionk there is value in still sending it to remind people to fix broken deps
15:58:09 <dgilmore> however if people have fixed the deps and can't get them pushed stable due to freeze it is annoying
15:58:13 <tyll> this sounds valid to not do it
15:58:24 <tyll> to be a valid reason*
15:59:05 <tyll> #info sending the branched reports reminds people of fixing broken deps
15:59:52 <dgilmore> so im prettyu torn
15:59:58 <dgilmore> pretty torn
16:00:09 <dgilmore> hence why ive not looked at it at all
16:00:16 <tyll> We might add information that there is nothing new to report, but then someone needs to do the work
16:00:33 <dgilmore> it wouldn't be too hard to do
16:00:52 <dgilmore> check the repodiff output and see if there was any difference
16:01:15 <pbrobinson> I think there's still value in the report, it might be useful to be able to put a flag for when we're frozen to print a message to that effect so people realise why though
16:01:46 <nirik> it could even be always when there's 0 changed packages
16:01:48 <tyll> #info to implement, check the repodiff output
16:01:55 <dgilmore> there is a lot of value in it
16:02:12 <nirik> ie, always say "0 changes today, we may be frozen for a milestone... '
16:02:17 <dgilmore> I have no plans to work on this
16:02:33 <tyll> Is it an easyfix task?
16:02:55 <dgilmore> tyll: probably, I really do not think we want to fix it
16:03:26 <bochecha_> how about not sending the report if « there is no change AND there are no broken deps » ? :)
16:03:29 <dgilmore> but changing the output to say we may be frozen or to give a bit more info could be valuable
16:03:45 <tyll> yes, I meant adjusting the output
16:03:48 <pbrobinson> bochecha_: like that's ever going to happen :)
16:03:51 <dgilmore> bochecha_: sure, but to date that's exactly never
16:04:16 <bochecha_> « you don't want to recieve the email? fix your broken deps! »
16:04:53 <tyll> #info highlighting that no changes happened or that there might be a freeze can be an alternative
16:05:35 <dgilmore> #topic #5959 Enable keep-alive connections for koji (primary and secondaries)
16:05:41 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5959
16:05:54 <dgilmore> pbrobinson: anyone else, have we notcied any breakages
16:06:01 <dgilmore> tyll: did you check it works?
16:06:16 <tyll> I did not get to do performance checks :-/
16:06:38 <dgilmore> okay
16:06:43 <pbrobinson> no, it appears to be running OK AFAICT
16:06:53 <dgilmore> I know we hit timeoust much less often with mod_python
16:06:54 <pbrobinson> but TBH I've not been looking really closely
16:07:06 <dgilmore> we started getting time out issues only when we moved to mod_wsgi
16:07:39 <dgilmore> lets look at enabling everywhere after infra freeze is over tomorrow
16:08:08 <dgilmore> we can always revert if we notice it causing problems
16:08:46 <tyll> #info < dgilmore> lets look at enabling everywhere after infra freeze is over tomorrow
16:08:53 <tyll> #info no problems noticed so far
16:09:05 <tyll> #info no performance tests made
16:09:11 <dgilmore> it would be wednesday that we can enable itr
16:09:12 <dgilmore> it
16:10:23 <dgilmore> #topic #5963 Orphaned vulnerable packages in EPEL
16:10:31 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5963
16:10:57 <dgilmore> not sure what the status is here
16:11:06 <dgilmore> there is not much for releng to do though
16:11:23 <dgilmore> we either remove them, or they get a packager to update/fix them
16:11:35 <Sparks_too> .
16:11:44 <tyll> I was just wondering, what we want to do here. Last time I started retiring some packages and it cause some discussion, because some depended on one
16:11:55 <dgilmore> im pretty sure wordpress-mu was removed last week
16:12:12 <Sparks_too> These packages are all orphaned, FWIW.
16:12:19 <tyll> I can just retire them all if we agree this is ok
16:12:28 <Sparks_too> But I didn't check for dependencies.
16:12:46 <tyll> at least it will make people aware that they need to be taken care of
16:12:47 <dgilmore> tyll: seems we maybe need a process to find packages with open security bugs, then make a report and notify owners
16:13:02 <dgilmore> also notifying owners of packages that depend on them
16:13:08 <nirik> find, notify, give some time for someone to fix or take, retire. ;)
16:13:16 <dgilmore> it would be useful for fedora as well as epel
16:13:38 <tyll> yes, this requires some more work to script this
16:13:49 <dgilmore> yeah
16:14:17 <tyll> also the packages were announced on epel-devel iirc
16:14:18 <dgilmore> #action someone needs to write a script to pull info from bugzilla, look at package deps and do mass reporting
16:14:32 <dgilmore> okay
16:14:41 <dgilmore> it can be used for epel and fedora
16:15:01 <dgilmore> I see a lot of value in this
16:15:06 <Sparks_too> dgilmore: We may already have tools for this within RH.
16:15:16 <dgilmore> Sparks_too: if they are open great
16:15:17 <Sparks_too> dgilmore: Need to figure out licensing, etc.
16:15:43 <Sparks_too> dgilmore: Product Security uses them daily/hourly
16:16:03 <tyll> #info for dependency checks we can use the find_unblocked_retired.py script
16:16:03 * Sparks_too will talk with his boss
16:16:27 <tyll> #info there might be internal red hat scripts that might be used
16:16:52 <tyll> #action Sparks_too check which internal red hat scripts can be used
16:17:34 <tyll> So do we want to defer handling the packets mentioned in the ticket until we figured out the deps?
16:18:22 <dgilmore> tyll: yeah. i know some have been removed
16:19:20 <tyll> #info wait for dependency checks before moving on with the ticket
16:20:12 <nirik> sure, it's waited this long. ;)
16:21:52 <dgilmore> #topic #6000 automate creation of excludelist for koji-shadow
16:21:57 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6000
16:23:50 <sharkcz> I think a cron job would do the work until better solution is found
16:23:50 <dgilmore> this has been a long standing todo
16:23:51 <dgilmore> some kind of cron job would be sufficent
16:23:51 <dgilmore> maybe weekly or monthly?
16:23:51 <dgilmore> thinsg shouldnt change often
16:23:51 <sharkcz> I would prefer weekly
16:23:51 <dgilmore> but when they do we kinda need to know
16:23:57 <dgilmore> automating when people exclude or unexclude arches would be really useful
16:24:14 <dgilmore> often people exclude arches and do not follow the policy and file bugs etc
16:24:25 <dgilmore> detecting the changes would be good
16:24:25 <sharkcz> correct :-(
16:24:30 <bochecha_> could that be a fedmsg consumer?
16:24:42 <dgilmore> bochecha_: NO
16:24:45 <dgilmore> no
16:24:50 <bochecha_> for all fedmsg about git pushes, check the diff, if it adds an exclude arch,... ?
16:24:54 <dgilmore> opps sorry about that
16:25:25 <dgilmore> bochecha_: need to know of it removes it also
16:25:33 <bochecha_> sure, add/remove
16:25:39 <dgilmore> same for ExclusiveArch
16:25:43 <sharkcz> maybe analyze srpms from primary koji
16:25:53 <sharkcz> when they are built
16:25:55 <bochecha_> that's just searching for lines starting with "+" or "-" and containing "ExclusiveArch" or "ExcludeArch"
16:26:00 <dgilmore> bochecha_: today we work it out by looking at teh srpms
16:26:53 <dgilmore> sharkcz: i might look at adding it to buildbranched and build rawhide on primary
16:27:07 <dgilmore> and just drop it nightly into files in teh logs dir
16:27:18 <dgilmore> shouldn't take much
16:27:24 <sharkcz> yeah, sounds as an option
16:27:34 <tyll> #info maybe add a fedmsg watch to check for spec changes
16:28:04 <tyll> #info check whether maintainers follow policy for excluded archs
16:28:07 <dgilmore> but ideally catching when changes are made and making sure appropriate people are notified should happen alsdo
16:28:09 <sharkcz> tyll: I'd rather analyze the srpms, it would be more precise
16:28:10 <dgilmore> also
16:28:23 <dgilmore> so really we have two things here
16:28:42 <dgilmore> one is getting the lists of packages to exclude in koji-shadow
16:28:45 <tyll> #undo
16:28:45 <zodbot> Removing item from minutes: INFO by tyll at 16:28:04 : check whether maintainers follow policy for excluded archs
16:28:47 <tyll> #undo
16:28:47 <zodbot> Removing item from minutes: INFO by tyll at 16:27:34 : maybe add a fedmsg watch to check for spec changes
16:28:52 <tyll> #info check whether maintainers follow policy for excluded archs
16:28:54 <dgilmore> we can do that nightly with the compose
16:29:13 <dgilmore> the other is making sure people are following the ExcludeArch policy
16:29:22 <dgilmore> which effects all arches, primary included
16:29:35 <sharkcz> ack
16:29:39 <tyll> #info task one: get list of packages to exlucde in koji-shadow during nightly composes
16:29:49 <tyll> #undo
16:29:49 <zodbot> Removing item from minutes: INFO by tyll at 16:29:39 : task one: get list of packages to exlucde in koji-shadow during nightly composes
16:29:51 <tyll> #undo
16:29:51 <zodbot> Removing item from minutes: INFO by tyll at 16:28:52 : check whether maintainers follow policy for excluded archs
16:29:53 <tyll> #info task one: get list of packages to exlucde in koji-shadow during nightly composes
16:30:02 <tyll> #info task two: check whether maintainers follow policy for excluded archs
16:30:46 <tyll> #info get notified by changes for packages by analysing SRPMs or analyse commit with fedmsg (less precise)
16:30:53 <dgilmore> #action dgilmore to add to buildbranched and buildrawhide making the lists for koji-shadow
16:31:22 <dgilmore> lets move on
16:31:29 <dgilmore> #topic #5886 need method for distributing urgent fixes... urgently
16:31:35 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5886
16:31:45 <dgilmore> so this came up after heartbleed
16:31:58 <dgilmore> we had the fix ready quickly
16:32:01 <dgilmore> we got testing and karma quickly
16:32:20 <dgilmore> we had issues with bodhi at the time and it took over 24 hours to get it pushed out
16:32:48 * nirik isn't against the idea of a urgent repo, but will need work and we likely won't use it too often
16:32:53 <dgilmore> so one of teh proposals was to add a repo in fedora-release (now fedora-repos) thats always enabled
16:33:12 <dgilmore> where we could manually put signed rpms and get fixes out of band out quickly
16:33:29 <dgilmore> to date we would have used it once in 10 years
16:34:07 <dgilmore> we could do something like we do with the bleed repo for TC and RC composes
16:34:23 <tyll> we could use it for all/more security updates
16:34:33 <nirik> hopefully also bodhi2 improvements might allow for faster pushes in any case.
16:34:34 <pbrobinson> and by not using it often it will invariably break when you need it the most ;-)
16:34:47 <tyll> by using it more, we ensure that it actually works
16:34:49 <dgilmore> tyll: well we would likely flush the repo after a week
16:35:00 <dgilmore> once updates got out via the regular channels
16:35:29 <dgilmore> tyll: using it all the time is cumbersome
16:35:30 <nirik> dgilmore: so this urgent repo wouldn't use bodhi then? or it would?
16:35:46 <dgilmore> the only way to really use it is a mostly manual out of band process
16:36:00 <dgilmore> nirik: from what i understood it wouldnt
16:36:23 <tyll> once we have it manual, it should be easy to make it automatic and e.g. also create it when we push regular updates
16:36:25 <dgilmore> bodhi is a roadblock to getting hings out quickly
16:36:33 <dgilmore> tyll: not really no
16:36:38 <nirik> we would still have to deal with things like updateinfo tho... or people with the security yum plugin might not see the updates.
16:36:55 <dgilmore> nirik: updateinfo is something entirely in bodhi
16:37:08 <nirik> right, which is why it could be difficult.
16:37:25 <dgilmore> so the problem is this
16:37:34 <bochecha_> that being said, for bodhi 2 there are talks of having a kind of « monthly bundle » update stream (aka « Patch Tuesday »), so if we can do that, maybe we could have the exact opposite : an urgent update stream?
16:37:38 <dgilmore> say we just started a f19 and f20 push
16:37:45 <dgilmore> and we get something like heartbleed
16:37:58 <dgilmore> we cant use bodhi to push it for likely 8-12 hours
16:38:21 <nirik> with bodhi2 hopefully we have parallel mashing... so it takes a lot less time.
16:38:29 <dgilmore> where out of band we could likely get a build pushed out in about 15-20 minutes of it being completed
16:38:45 <dgilmore> but the out of band process doesnt scale
16:39:14 <nirik> also sometimes "urgent push this fix now" updates are borken/not fully tested right.
16:39:26 <nirik> we would need to be carefull to make sure it doesn't make things worse.
16:39:32 <dgilmore> nirik: rigth
16:39:33 <nirik> like the dbus security update long ago
16:39:34 <dgilmore> right
16:40:07 <dgilmore> I do not think we can fix this today
16:40:15 <tyll> so it is a question whether this is something that should be enabled by default or can be enabled by interested users
16:40:35 <dgilmore> but if we are going to add an urget fixes repo would be nice to have it in f21 from day 1
16:40:49 <dgilmore> tyll: it would be enabled by default
16:40:53 <tyll> or again have two repos with a testing and non-testing updates
16:41:02 <dgilmore> its more a question of how do we set it up and make it work
16:41:53 <dgilmore> tyll: i think it would be just one repo where we push things if the nature of the security fix deemed an urgent reponse
16:42:03 <dgilmore> like heartbleed
16:42:22 <dgilmore> using it as a regular security update repo is messy and ugly
16:42:52 <dgilmore> because you get to a point where security fixes rely on non security fixes
16:45:07 <dgilmore> the more that goes into the repo the harder it is to manage and longer ittakes to get out
16:47:18 <dgilmore> any other thoughts here?
16:47:41 <dgilmore> I guess we need to decide what exactly is wanted
16:47:50 <dgilmore> and work out how to make it work
16:48:11 <tyll> yes, I guess this needs to be cleared
16:48:17 <dgilmore> from my point of view something light weight and well understood would work best. to only be used in an emergency
16:48:35 <tyll> #info < dgilmore> I guess we need to decide what exactly is wanted
16:48:43 <tyll> #info < dgilmore> from my point of view something light weight and well understood would work best. to only be used in an  emergency
16:49:05 <dgilmore> I am kinda thinking that we put it under /pub/fedora/linux/updates/emergency/
16:49:24 <tyll> #info < dgilmore> I am kinda thinking that we put it under /pub/fedora/linux/updates/emergency/
16:49:31 <dgilmore> and use a process similliar to how we make the bleed repo
16:49:42 <dgilmore> with proper spelling
16:51:16 <dgilmore> anything else here?
16:51:51 <dgilmore> we are over time, and i would like to go over secondary arches since we have not gotten to them for awhile
16:52:16 <dgilmore> im going to take that as a no
16:52:18 <dgilmore> #topic Secondary Architectures updates
16:52:19 <dgilmore> #topic Secondary Architectures update - ppc
16:52:26 <dgilmore> pbrobinson: you're up amigo
16:55:32 <dgilmore> hrrm guess we lost him
16:56:02 <dgilmore> #topic Secondary Architectures update - s390
16:56:07 <dgilmore> sharkcz: you're up
16:56:10 * pbrobinson is here
16:56:13 <pbrobinson> sorry
16:58:07 <sharkcz> I'm over the rebuilds required for the ABI revert, so builds in f212 continue again
16:58:45 <dgilmore> sharkcz: okay
16:58:59 <dgilmore> sharkcz: have you tried to compose anything at all?
16:59:08 <dgilmore> as far as install trees go?
16:59:14 <sharkcz> not yet
16:59:55 <dgilmore> okay
16:59:56 <sharkcz> can try after the current (or next) shadow run ends, there are still some builds missing
17:00:09 <dgilmore> cool, hopefully they go okay
17:00:16 <dgilmore> will you just do a server compose?
17:00:23 <sharkcz> yes
17:00:26 <dgilmore> okay
17:00:33 <dgilmore> lets go back to ppc
17:00:42 <dgilmore> unless you have something else to add
17:00:51 <sharkcz> nope
17:00:51 <dgilmore> #topic Secondary Architectures update - ppc
17:00:57 <dgilmore> pbrobinson: take 2 ;)
17:01:09 <pbrobinson> so sharkcz probably know better the states of builds there, I'm going through the first round of composes now
17:01:25 <pbrobinson> but I think builds are looking pretty good
17:01:44 <sharkcz> builds are quite fine - http://ppc.koji.fedoraproject.org/koji/serverstatus - no major immediate issues
17:01:57 <pbrobinson> hoping to get a RC Alpha compose out the door this evening
17:02:17 <sharkcz> would be great
17:02:31 <dgilmore> okay
17:02:41 <dgilmore> and for now at least ppc will be server only?
17:03:01 <pbrobinson> sharkcz: be aware of this issue depending on how you run mock https://bugzilla.redhat.com/show_bug.cgi?id=1140886
17:04:15 <sharkcz> pbrobinson: thx
17:05:41 <pbrobinson> dgilmore: you want aarch64 update?
17:06:05 <dgilmore> pbrobinson: im waiting on my previous ppc question to be answered
17:06:27 <dgilmore> 17:02 < dgilmore> and for now at least ppc will be server only?
17:07:09 <sharkcz> yes
17:07:11 <dgilmore> do we not know that yet?
17:07:16 <dgilmore> okay
17:07:20 * bochecha_ really has to go
17:07:26 <dgilmore> i had heard that cloud may be an option on ppc
17:07:31 <sharkcz> there is potential for cloud too
17:07:32 <dgilmore> thanks bochecha_
17:07:46 <pbrobinson> ah, yes for now ppc will be server only
17:07:50 <dgilmore> if thats wanted it should be worked on now and not later in teh cycle
17:08:01 <dgilmore> okay
17:08:04 <dgilmore> #topic Secondary Architectures update - arm
17:08:13 <dgilmore> pbrobinson: you're up again
17:08:20 <pbrobinson> well by cloud it'll be a qcow image... so really a tiny subset of cloud...
17:08:40 <pbrobinson> so builds for both f21/22 are only a little way behind
17:08:46 <dgilmore> pbrobinson: that involves a cloud install tree and other bits
17:09:11 <pbrobinson> yep, I realise that, what I mean is there will be no docker/ec2 etc
17:09:13 <dgilmore> anyway we can deal with that out of band
17:09:18 <dgilmore> okay
17:09:40 <dgilmore> pbrobinson: I know we need to get a compose box setup in phx2 for aarch64
17:09:52 <pbrobinson> there's some issue with the sync of new packages over to at least arm.koji so it believes there's about 97 odd new packages that aren't packages
17:10:01 <dgilmore> do we want to do a Workstatsion compose along with server?
17:10:05 <pbrobinson> and then I was going to look at composes this week
17:10:13 <pbrobinson> I think we start with server and expand out from there
17:10:23 <dgilmore> need to debug owner-sync-pkgdb
17:11:01 <pbrobinson> yea, I need to find the repos where that is and then I was going to look.... once I have ppc composes in some definition of work state
17:11:21 <dgilmore> its in puppet which is only on lockbox
17:11:31 <dgilmore> pingou: any chance you have some time to look
17:11:46 <dgilmore> pingou: it seems owner-sync-pkgdb is not syncing to at least arm koji
17:12:33 <tyll> I need to go, too
17:14:10 <dgilmore> tyll: thanks
17:14:15 <dgilmore> will be wrapping up soon
17:17:08 <dgilmore> okay lets move on
17:17:19 <dgilmore> #topic Open Floor
17:17:26 <dgilmore> anyone have anything to bring up?
17:18:05 <dgilmore> I am going to take off at least Wednesday though Friday
17:18:10 <dgilmore> maybe a little longer
17:19:02 <nirik> good plan. ;)
17:19:12 <sharkcz> can I commit a script I crafted for the rebuilds on s390 to rel-eng git? I might be useful for someone in the future?
17:19:17 <dgilmore> ive had one day this year
17:19:25 <dgilmore> sharkcz: sure
17:20:02 <sharkcz> ok, will probably add it to some "misc" dir
17:20:13 <dgilmore> that is fine
17:20:36 <sharkcz> ok, it's really meant as one off helper, but not to be forgotten :-)
17:20:36 <dgilmore> probably should look to clean up scripts a bit
17:21:50 <dgilmore> okay if nothing else lets close up
17:22:03 <sharkcz> ok
17:22:10 <dgilmore> #endmeeting