16:34:39 <dgilmore> #startmeeting RELENG (2015-01-19)
16:34:39 <zodbot> Meeting started Mon Jan 19 16:34:39 2015 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:34:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:34:47 <dgilmore> #meetingname releng
16:34:47 <zodbot> The meeting name has been set to 'releng'
16:34:47 <dgilmore> #chair dgilmore nirik tyll sharkcz bochecha masta pbrobinson
16:34:47 <zodbot> Current chairs: bochecha dgilmore masta nirik pbrobinson sharkcz tyll
16:34:48 <dgilmore> #topic init process
16:35:05 * bochecha is here
16:35:09 * sharkcz is here
16:35:22 * pingou here
16:36:44 * nirik is here
16:37:17 <dgilmore> #meetingname releng
16:37:17 <zodbot> The meeting name has been set to 'releng'
16:37:17 <dgilmore> #chair dgilmore nirik tyll sharkcz bochecha masta pbrobinson
16:37:17 <zodbot> Current chairs: bochecha dgilmore masta nirik pbrobinson sharkcz tyll
16:37:23 <dgilmore> gahh
16:37:31 <dgilmore> #topic Secondary Architectures updates
16:37:32 <dgilmore> #topic Secondary Architectures update - ppc
16:37:39 <dgilmore> oh well
16:37:51 * masta is here
16:37:52 <dgilmore> sharkcz: want to give an update since pbrobinson is sleeping
16:38:38 <sharkcz> Peter works on mashing updates, rawhide builds are now stuck at libproxy, but this being slowly solved
16:39:40 <dgilmore> cool
16:40:07 <dgilmore> anything else to look out for on ppc?
16:40:52 <sharkcz> hm, no
16:40:57 <dgilmore> okay
16:40:58 <dgilmore> #topic Secondary Architectures update - s390
16:41:05 <dgilmore> how is s390 looking?
16:41:46 <sharkcz> s390 looks better :-) roughly a week behind primary, there is a little issue in glibc, the maintainer works on it
16:42:25 <sharkcz> eclipse will need work
16:42:50 <dgilmore> okay :(
16:42:55 <dgilmore> poor eclipse
16:43:02 <sharkcz> and there is an issue s390 (32bit) in gcc5, but jakub works on it
16:43:07 <dgilmore> how big is the littel issue with glibc?
16:43:30 <dgilmore> sharkcz: can we work on a plan to drop s390 support?
16:43:48 <sharkcz> they enabled -werror and there is a warning
16:44:13 <sharkcz> yes, we do, but it is a slow process
16:45:09 <dgilmore> okay. I would really like to see us drop it
16:46:43 <dgilmore> anything else?
16:46:54 <sharkcz> nope
16:46:57 <dgilmore> #topic Secondary Architectures update - arm
16:47:15 <dgilmore> I know rawhide was stuck on python on aarch64
16:47:23 <dgilmore> well arm is just aarch64 now
16:47:24 <nirik> so with f19 going eol, we should be able to repurpose those 32bit arm builders right?
16:47:28 <dgilmore> since f19 is eol
16:47:33 <dgilmore> nirik: we should
16:47:33 * nirik nods
16:47:49 <dgilmore> i believe that the python issue has been sorted
16:48:10 <nirik> easiest would just be rebuilding them f21 and adding them in as builders... but that might make more primary builds use arm...
16:48:29 <dgilmore> it shouldn
16:48:36 <dgilmore> shouldn't
16:48:53 <dgilmore> but koeschi really should force the use of arm and not x86_64
16:49:16 <nirik> ok.
16:49:35 <nirik> I can try and do those sometime this week. Might need certs for them for primary...
16:49:49 <dgilmore> there is quite a few issues that need sorting out for koeschi
16:49:58 <dgilmore> same certs will work.
16:50:05 <dgilmore> will need to add the hosts to koji first
16:50:22 <dgilmore> and tweak the ansible rules for them
16:50:54 <dgilmore> okay lets move on to tickets
16:51:01 <nirik> ok
16:51:20 <dgilmore> nirik: lets chat about what to do with the arm boxes out of meeting
16:51:26 <dgilmore> #topic #5931 [Proposal] Move new branch and unretire requests to pkgdb2
16:51:27 <nirik> yep. fine with me
16:51:33 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5931
16:51:54 <dgilmore> pingou: thanks for the update in the ticket
16:52:09 <dgilmore> #info update in ticket https://fedorahosted.org/rel-eng/ticket/5931#comment:12
16:52:40 <pingou> I need one change on the JSON output to make my life simpler and then checking if a package is in RHEL and in all arches should be done :)
16:53:01 <pingou> (currently pkgdb2 only checks if the package is in RHEL or not, does not take the arch into account)
16:53:02 <dgilmore> cool
16:53:18 <nirik> cool. I'd say we should roll out to prod, and then test with some limited few packages first, then announce and change docs.
16:53:32 <dgilmore> I agree
16:53:35 <pingou> I probably have to adjust a little FMN for the 'message' when a request is blocked/denied
16:53:56 <pingou> but things are looking good :)
16:53:58 <dgilmore> lets get it rolled out. get some further testing then send an announcement to devel-announce@
16:54:04 <dgilmore> as well as updating the wiki
16:54:13 <pingou> sounds good
16:54:24 <pingou> I can probably have it in stg by next wek
16:54:27 <pingou> week*
16:54:32 <dgilmore> sounds good
16:54:37 <pingou> where we can poke at it a little if you like
16:54:43 <dgilmore> would be nice to have done and rolled out for devconf
16:55:08 <pingou> sounds duable, except for last minute mistakes/errors/bugs :)
16:55:15 <dgilmore> sure
16:56:03 <dgilmore> #action pingou to deploy in stage by the end of this week for testing next week
16:56:28 <dgilmore> #action everyone test in stage when it is ready
16:56:42 <dgilmore> #info desire to have deployed by devconf
16:57:02 <dgilmore> anything else?
16:57:32 <pingou> until testing, nothing for me :)
16:57:36 <nirik> nope, next++
16:58:07 <dgilmore> #topic #5963 Orphaned vulnerable packages in EPEL
16:58:19 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5963
16:58:35 <dgilmore> so apparently some were missed first go arround.
16:58:42 <dgilmore> I have not dug into them
16:58:49 <dgilmore> so I do not have a lot of info
16:58:56 <dgilmore> tyll_: anything on your end?
17:00:56 <nirik> lets ask for update in ticket next time we see him.
17:01:44 <dgilmore> sure
17:01:55 <dgilmore> #action tyll_ give update in ticket
17:02:08 <dgilmore> #topic #6039 koji database read-only access request
17:02:13 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6039
17:02:33 <dgilmore> I think there is only one table where there could be sensitive info
17:02:33 <nirik> did you get a chance to check if there's anything that needs to stay private in there?
17:02:41 <dgilmore> but sudo is not working on the db box right now
17:03:13 <dgilmore> was going to check but can't get where i need to
17:03:15 <nirik> hum.
17:03:24 <nirik> ok, we can check out of meeting?
17:05:37 <dgilmore> got on via lockbox
17:05:43 <dgilmore> it is okay
17:06:04 <dgilmore> #info there is no sensitive data in the db
17:06:17 <pingou> \ó/
17:06:38 <nirik> cool.
17:06:45 <nirik> I can set up the publishing.
17:08:11 <dgilmore> #action nirik to set up publishing the db
17:08:20 <dgilmore> #topic #6059 untag f21 GA builds from f21-updates-testing
17:08:41 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6059
17:08:42 <sharkcz> I think this was done quite soon after the GA
17:08:59 <dgilmore> I do not know why this ticket has the meeting keyword
17:09:20 <sharkcz> I though it was already closed
17:09:25 <dgilmore> sharkcz: it is something that bodhi should do and a bug should be filed in bodhi to do the right thing
17:09:46 <sharkcz> but did someone clean the tag manually this time?
17:10:03 <dgilmore> sharkcz: I did
17:10:06 <sharkcz> ah, ok
17:10:11 <nirik> close ticket, move on. ;)
17:10:22 <dgilmore> already closed
17:10:36 <dgilmore> #topic #6064 extend srpm-excluded-arch.py so it can read srpms from multiple dirs
17:10:46 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6064
17:11:17 <sharkcz> IMO it would be useful (like we do in buildrawhide for rawhide) but what others think about it?
17:11:52 <sharkcz> I'll ask someone in our team to implement it
17:12:04 <dgilmore> it wouldn't hurt
17:12:19 <nirik> sure. seems fine to me.
17:12:23 <dgilmore> implementing shouldnt be too hard
17:12:40 <dgilmore> sharkcz: just need to make sure that that latest nvr for a package is used
17:12:50 <sharkcz> yep
17:13:15 <dgilmore> sharkcz: so that if a package is Excluded in GA but an update unexcludes it we get things right
17:13:25 <dgilmore> and vice versa
17:13:50 <dgilmore> we should scream loudly if a packed excludes an arch post release
17:13:51 <sharkcz> yep :-) it will make managing the shadow configs for released fedora easier
17:14:37 <dgilmore> #info we should make a big angry list of packages excluded on an arch post release
17:14:48 <sharkcz> we can make it print a warning of an arch is dropped
17:15:10 <dgilmore> sharkcz: longer term I want to run koji-stalk in infra and have the configs etc managed automatically
17:15:22 <dgilmore> so that buidls just happen and are really transparent
17:15:23 <sharkcz> yes, that would be nice
17:15:50 <dgilmore> but that will take some work on tooling to manage the workflows and detect when things break to get people attention
17:15:51 <nirik> reminds me, smooge said there was a new s390 hub machine that arrived... we should try and add it into infra/ansible, etc...
17:16:10 <dgilmore> nirik: we need to rebuild all the secondary infra using ansible
17:16:13 <nirik> yep.
17:16:23 <dgilmore> and tie them all into fas, ansible, etc
17:16:24 <nirik> this is a good chance for a first one tho. ;)
17:16:30 <dgilmore> sure :)
17:16:42 <sharkcz> no objections :-)
17:17:17 <dgilmore> #info no objections to extending the functionality
17:17:32 <nirik> we should now have a pretty reasonable koji_hub role. :) Since I am redoing the primary ones.
17:17:48 <dgilmore> nirik: :) good
17:18:10 <dgilmore> I think we can skip the other tickets as there is no updates for them.
17:18:24 <dgilmore> #topic Open Floor
17:18:31 <dgilmore> I have a few things to go over
17:18:40 <nirik> we have a number of old tickets laying around. Some can just be closed... a few I guess I could add meeting to?
17:18:48 <dgilmore> we have f22 branching on Feb 10
17:19:07 <dgilmore> nirik: yeah, I really need to traiage them all
17:19:16 <dgilmore> triage
17:19:18 <pingou> I'll be around, just back from devconf
17:19:23 <pingou> (for branching)
17:20:17 <dgilmore> pbrobinson and I will be in Brno for it
17:20:48 <bochecha> I'll also be in Brno at that time, if needed
17:21:11 <dgilmore> we are planning to have a workshop on distill the week before devconf
17:21:19 <dgilmore> its supposed to be open sourced before then
17:21:33 <dgilmore> but it may be too late for f22
17:21:34 <pingou> fingers crossed
17:21:41 <dgilmore> we will see
17:22:01 <bochecha> oh, nice
17:22:03 <dgilmore> we also need to sit down with bcl and get koji to build livecds using lmc in koji
17:22:11 <dgilmore> it works in mock now
17:22:29 <dgilmore> though we do have the current situation where mock is not playing nice
17:23:20 <dgilmore> so at the point where we should be stable and having things purring along like a kitty having its belly rubbed we are going to be wrestling with lions and tigers with no saftey
17:24:08 <nirik> as always. ;)
17:24:52 <nirik> dgilmore: could you (or I can) file a mock bug on that thing? IMHO it's much nicer to have bugs filed so we can point interested people at them than try and explain over and over and also helps keep things open.
17:24:53 <dgilmore> nirik: for distill we will need to have some builders seperate
17:25:03 <dgilmore> they will need a slightly different setup
17:25:07 <nirik> ok
17:25:08 <dgilmore> and have to be in a special channel
17:25:22 <dgilmore> nirik: I will file a bug
17:25:46 <nirik> if we can get staging builders happy again we could test there.
17:25:57 <dgilmore> #action dgilmore to file bug against mock for current breakages
17:26:38 <dgilmore> #info need to work with bcl on transition to lmc for livecds
17:27:14 <dgilmore> #info likely to have new toolfor composes before devconf
17:27:32 <pingou> oh cool
17:27:45 <pingou> is that the very fast one I heard about?
17:28:00 <pingou> (I don't know its name)
17:28:04 <dgilmore> so I am flying to Brussels for fosdem on Jan 29 so that I can get with the CentOS guys to talk about ways that CentOS and Fedora can work together on EPEL
17:28:16 <dgilmore> pingou: its not that fast
17:28:29 <dgilmore> pingou: I do not know really what it will get us
17:28:51 <dgilmore> I have a few things then i have another topic in my head to bring up
17:29:23 <dgilmore> I am hoping to workout ways to enable people with CentOS accounts and not fas accounts to contribute to epel directly
17:29:42 <dgilmore> nirik: how we can do that I am not 100% sure but I think it would be good to do
17:30:11 <dgilmore> there will likely be a need for infra to work with CnetOS infra on things
17:30:17 <nirik> hum. ok.
17:30:18 <pingou> if CentOS deploys an epsilon instance that would already help quite a bit (thinking from a pkgdb auth pov)
17:30:56 <dgilmore> pingou: I am not 100% sure what they have
17:31:22 <dgilmore> we would likely need to have acls so that CentOS folks can only get epel acls
17:31:40 <dgilmore> and if you wanted fedora acls to help there also then you need a fas account
17:31:55 <nirik> well, is a fedora account really such a burden?
17:31:55 <dgilmore> there is likely some legal wrangling to be done I am sure
17:32:07 <dgilmore> nirik: not really but people can be silly
17:32:18 <dgilmore> they will contribute to CentOS but not Fedora
17:32:38 <dgilmore> maybe we say that they need a fas account
17:32:53 <dgilmore> but we have some way to sponsor them and restrict the accounts to epel
17:33:07 <dgilmore> I really do not know exactly how it would all work
17:33:26 <dgilmore> I just know I would like to make sure that we can enable people to contribute
17:33:50 <pingou> fas group epel-packager with their own sponsoring rules
17:33:55 <dgilmore> I will open a ticket to track things
17:34:02 <nirik> pingou: could work
17:34:12 <pingou> and integration w/ pkgdb should be duable
17:34:24 <dgilmore> if people can think on it and provide some ideas that would be fantastic
17:34:32 <pingou> dgilmore: I'll be at fosdem, but arriving only on Friday if you need me
17:34:44 <dgilmore> pingou: I arrive friday morning
17:34:49 <dgilmore> I have a overnight flight
17:34:55 <pingou> ok :)
17:35:03 <dgilmore> pingou: so I will make sure to add you to the invite list for the meeting
17:35:04 <pingou> dgilmore: don't wait for me at the airport ;-)
17:35:17 * pingou lands in the late afternoon
17:35:23 * dgilmore is 8:10am
17:35:27 <dgilmore> not waiting
17:35:36 <pingou> nope :)
17:36:48 <dgilmore> I think we should skip the meeting on the 2nd of Feb as at least myself and pbrobinson will be traveling to Brno. not sure what travel plans others have
17:37:00 <dgilmore> but we can discuss that next week
17:37:20 <dgilmore> Does anyone have anything else to bring up for open floor?
17:37:29 <sharkcz> I have one item
17:37:29 <dgilmore> I have one biggish thing I want to bring up
17:37:34 <nirik> I had one or two. ;)
17:37:37 <sharkcz> small one
17:37:50 <dgilmore> nirik: lets do your's then sharkcz's
17:38:32 <nirik> ok. I have koji01/koji02 built up... x86_64/rhel7/ansible. I am waiting on getting darkserver plugin for rhel7, then I think they should be good to switch over to.
17:39:12 <dgilmore> okay
17:39:13 <nirik> also I hope to make a kojipkgs ansible setup and get an updated kojipkgs01 setup
17:39:15 <dgilmore> sounds good to me
17:39:18 <nirik> sometime soon
17:39:40 <dgilmore> what I saw koji01 looked okay
17:39:53 <nirik> oh... I need an updated koji-theme package
17:40:04 <nirik> I hacked around the change on the system, but an updated package would be good.
17:40:11 <dgilmore> nirik: okay. can do
17:40:28 <dgilmore> the git repo for it is in my fedorapeople account
17:40:30 <nirik> it's just the httpd 2.2 to 24 change... 'grant all' etc
17:40:57 <dgilmore> I really need to get all the arches updated and I want to get some work done to make access to the different kojis easier
17:41:00 <nirik> anyhow, I guess thats all I had.
17:41:07 <nirik> Oh... wait.
17:41:07 <dgilmore> nirik: cheers.
17:41:23 <dgilmore> #action dgilmore to update the koji theme package
17:41:27 <nirik> so, a while back we redid fas servers. There's one old one left...
17:41:33 <nirik> fas01... which does the koji certs.
17:41:36 <dgilmore> okay
17:41:51 <nirik> I'd like some help testing that fas01.stg is working right for certs before I redo fas01 in production.
17:41:58 <nirik> if anyone has some time to assist me on that. ;)
17:42:00 <dgilmore> okay
17:42:00 <nirik> thats all I had
17:42:12 <dgilmore> we will have to sync the data from the prod server
17:42:30 <dgilmore> there is some dynamic data we will need
17:43:02 <nirik> ok, that will be good to know.
17:44:09 <sharkcz> my is package/tag sync to secondary kojis - I saw few packages (eg. perl-Module-CoreList) which I had manually unblock for f22, also f21-updates/f21-updates-testing tag contents are not being synced, so it's 2 issues in fact I think :-)
17:44:44 <sharkcz> probably just matter of updating the configs
17:44:59 <dgilmore> sharkcz: hrrm maybe things did not get updated when we branched
17:46:03 <sharkcz> do you want a ticket opened?
17:47:18 <dgilmore> sharkcz: please
17:47:21 <sharkcz> np
17:48:53 <dgilmore> anything else?
17:49:54 <dgilmore> ill assume no
17:50:03 <dgilmore> so ill go to the big elephant
17:50:15 <dgilmore> #topic minimal buildroots and caching etc
17:50:57 <dgilmore> I know at least some of you have been following the thread on devel@ to remove gcc gcc-c++ and make from the default minimal buildroot
17:51:17 <dgilmore> a big immediate win is to switch teh srpm to use fedpkg-minimal
17:51:25 <dgilmore> it has a crap ton less deps
17:51:35 * nirik nods
17:52:36 <dgilmore> I do not know that we wil gain a lot by removing the few things, but it would be cleaner if someone comes along and says oh i want to rebuild foo srpm and they have to dig into why it fails to build
17:52:49 <dgilmore> it seems at least half of the the srpms will need updating
17:52:59 <dgilmore> but the fulle xtent of teh work is not known
17:54:00 <dgilmore> the caching side thread I see as a big distraction. it makes tracking the minimal buildroot contents for builds and making thinsg reproducable much much harder
17:54:13 <dgilmore> most repos are used on a give host once or twice
17:54:35 <dgilmore> so for caching to give any benefit the complexity of tracking things will be much higher
17:54:40 <nirik> right.
17:55:18 <dgilmore> I am not sure if making the cache and unpacking it etc is any quicker than doing the install from scratch
17:55:23 <nirik> IMHO, I am actually against the gcc/g++ change unless someone actually figures out the packages needing them and mass fixes them. It's just too much makework to dump on maintainers.
17:55:42 <dgilmore> I am against removing make
17:55:53 <dgilmore> im less so against gcc/g++
17:56:19 <dgilmore> a lot of the packages that do not use gcc/g++ likely use make
17:56:28 <nirik> true.
17:56:44 <dgilmore> the java ones etc probably not
17:56:56 <dgilmore> but a lot of python and perl modules likely use make files
17:57:04 <sharkcz> python-* probably don't use make, while perl-* does
17:57:20 <dgilmore> it really all needs a large analysis
17:57:29 <sharkcz> +1
17:57:39 <dgilmore> sharkcz: some python-* uses make some setup.py
17:58:10 <dgilmore> I will help people interested in doing the analysis  get the data they need
17:58:12 <sharkcz> yep, and the analysis will show what's the majority
17:58:24 <dgilmore> but I am not interested in doing it myself
17:58:48 <dgilmore> I suspect that the wins will all me small individually but will add up on a whole
17:59:12 <dgilmore> but Its a massive undertaking to work it out and will make many things much much harder
17:59:27 <sharkcz> other large classes are golang-* and nodejs-*
18:00:02 <dgilmore> So i wanted to get everyones take on it. make sure that we were all aware of the different aspects
18:00:02 <nirik> well, IMHO the reason for the changes would be that it's more correct...
18:00:22 <nirik> I think the speed/caching/whatever issues are hiding that part. ;)
18:00:42 <dgilmore> we do not all have to have the same opinions but should have the same understandinsg of why they are and the risks associated with the different paths
18:01:48 <dgilmore> nirik: right. in the FPC ticket Vit admited that it was really about making his builds faster and that was all
18:01:58 <dgilmore> since he deals in ruby
18:02:13 <dgilmore> but he missed the bigger win in the srpm creation task
18:02:14 <nirik> ok.
18:02:38 <nirik> yep. Lets get that done and see if it helps him out
18:03:00 <dgilmore> https://fedorahosted.org/fpc/ticket/490#comment:10
18:03:37 <dgilmore> I see no problem in making things more correct. But that is a massive undertaking
18:03:37 <bochecha> I think it's fine to remove these things from the buildroot (gcc/g++/make/whatever), whether it actually saves some time or it's merely "more correct", but I also have no interest in doing it myself...
18:04:27 <bochecha> maybe we could just come up with a list of things anyone wanting this would have to figure out (e.g list of impacted packages, commit to fixing them yourself, time savings, ...) and agree to do it if all those conditions are met?
18:04:42 <dgilmore> I also think some things like fedora-release and redhat-rpm-config should be explicitly defined
18:04:51 <dgilmore> not just relied on implicitly
18:05:06 <dgilmore> bochecha: sure
18:05:35 <bochecha> dgilmore, being responsible for a downstream in another life, having those -release and -rpm-config explicitly BuildRequired in spec files made my life worse
18:06:08 <bochecha> (because I had to patch specfiles to change them to our own $vendor-release and $vendor-rpm-config)
18:06:14 <dgilmore> bochecha: by explictly defined i mean in the minimal buildroot
18:06:31 <bochecha> well, isn't that what they are right now?
18:06:33 <dgilmore> bochecha: Vit proposed
18:06:44 <dgilmore> "rpm-build shadow-utils" as the minimal buildroot
18:06:49 <bochecha> wow
18:07:04 <bochecha> oh, you were quoting Vit above, I thought it was your opinion :)
18:07:16 <dgilmore> with thinsg like fedora-release and redhat-rpm-config only pulled in via deps
18:07:36 <bochecha> having to explicitly require $vendor-release and $vendor-rpm-config seems crazy
18:07:48 <dgilmore> bochecha: well not in the specs
18:08:00 <dgilmore> rpm-build would magically pull them in
18:08:09 <bochecha> ah
18:08:14 <dgilmore> bochecha: https://fedorahosted.org/fpc/ticket/490#comment:12
18:08:29 <bochecha> but then, if rpm-build is in the minimal buildroot, that changes nothing :)
18:09:30 <dgilmore> I could run some test on buildroot initialisation time on the builders
18:09:41 <dgilmore> in vits test the win at most was about 20 seconds
18:11:19 <dgilmore> in the end we need to keep an open mind and if people want to do the work we shouldnt stand in the way. But we also need to make sure its not half done then decided it is too hard and we are left having to clean up things
18:12:37 <dgilmore> I think I have covered what I wanted to here.  I have try to be active on the threads about it and give factful information. trying to educate people as to why we do things the way we do as I go
18:12:54 <dgilmore> so if no one has anymore ill wrap up the meeting
18:15:00 <nirik> yep. +1 on all the educating.
18:16:40 <dgilmore> #endmeeting