16:31:17 <dgilmore> #startmeeting RELENG (2015-02-09)
16:31:17 <zodbot> Meeting started Mon Feb  9 16:31:17 2015 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:31:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:31:29 <dgilmore> #meetingname releng
16:31:29 <zodbot> The meeting name has been set to 'releng'
16:31:29 <dgilmore> #chair dgilmore nirik tyll sharkcz bochecha masta pbrobinson
16:31:29 <zodbot> Current chairs: bochecha dgilmore masta nirik pbrobinson sharkcz tyll
16:31:30 <dgilmore> #topic init process
16:31:51 <dgilmore> who is here?
16:31:56 * pbrobinson is here
16:32:10 <janeznemanic> hi
16:32:10 <bochecha> I'm here
16:32:35 <dgilmore> hi janeznemanic
16:32:55 * masta is here
16:33:41 <dgilmore> lets get started
16:33:42 <dgilmore> #topic Secondary Architectures updates
16:33:43 <dgilmore> #topic Secondary Architectures update - ppc
16:33:51 <dgilmore> pbrobinson: how is ppc?
16:34:30 <pbrobinson> we're building, the secondary team is fixing up some rawhide build issues
16:34:48 <pbrobinson> stable releases are fine, had updates pushed late last week
16:35:51 <dgilmore> ready for branching tomorroew?
16:35:54 <dgilmore> tomorrow?
16:36:14 <pbrobinson> we should be, package state not a major issue there
16:36:20 <dgilmore> okay
16:36:35 <dgilmore> #topic Secondary Architectures update - s390
16:36:55 <dgilmore> sharkcz is on holidays but i believe things are okay
16:37:12 <dgilmore> #topic Secondary Architectures update - arm
16:37:15 <pbrobinson> should be about the same as ppc
16:37:41 <pbrobinson> we're looking pretty good
16:37:52 <pbrobinson> there's been a few breakages of late due to features landing like ghc
16:37:59 <pbrobinson> and likely some issues with gcc5
16:38:10 <pbrobinson> but other than that it's pretty close to mainline
16:38:46 <dgilmore> :) okay
16:39:22 <dgilmore> #topic #6016 Use fedpkg-minimal in Fedora buildroots
16:39:38 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6016
16:39:54 <bochecha> the package is approved, I'm not sure pbabinca had time to build it already or not
16:40:18 <dgilmore> once it is built we can get overrides and make the necessary changes
16:40:23 <bochecha> seems to be build in rawhide
16:40:30 <dgilmore> then fedora-packager can be removed from epel5
16:40:40 <bochecha> https://koji.fedoraproject.org/koji/buildinfo?buildID=609961
16:41:25 <dgilmore> awesome
16:41:44 <dgilmore> #topic #5959 Enable keep-alive connections for koji (primary and secondaries)
16:41:56 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5959
16:42:06 <pbrobinson> we've not seen issues on arm.koji when I enabled it there
16:42:23 <dgilmore> seems we should enable it everywhere
16:42:36 <pbrobinson> I can look at what's needed in ansible and send a patch to infra list
16:42:46 <dgilmore> cheers
16:43:08 <dgilmore> #action pbrobinson to send patch to infra list enabling keepalive
16:43:39 <dgilmore> #topic #6023 allow Peter Robinson to restart sigul bridges
16:43:48 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6023
16:44:02 <dgilmore> as of last week sysadmin-main members can restart the bridges
16:44:10 <dgilmore> I think that solves the issues raised
16:44:16 <dgilmore> and this ticket can be closed
16:45:31 <dgilmore> #topic #6027 secondary arch old mash trees cleanup
16:45:47 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6027
16:46:15 <pbrobinson> that's been on my todo list as well
16:46:21 <dgilmore> this is something that needs done for primary as well
16:46:22 <pbrobinson> Sorry, I'd forgot about this
16:46:47 <pbrobinson> yea, I was going to write the script, it fell through the craps
16:46:50 <pbrobinson> cracks even!
16:46:53 <dgilmore> it happens
16:47:42 <dgilmore> maybe bconoboy|afk can help you
16:48:52 <dgilmore> qa has recently been doing rawhide tests
16:48:59 <dgilmore> they point at the mash location
16:49:36 <dgilmore> given that rawhide has been failing quite a lot we should make sure that we keep the last full tree
16:49:48 <dgilmore> and bochecha can maybe help not bconoboy|afk
16:50:03 <bochecha> sure
16:50:16 <dgilmore> ideally we should have a couple of weeks worth of composes
16:51:36 <dgilmore> there is also updates tress to clean up
16:51:44 <dgilmore> along with branched and rawhide
16:52:06 <dgilmore> #topic #6096 add individual email addressses to Fedoras GPG keys
16:52:20 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6096
16:52:51 <dgilmore> we can not retroactively change anything
16:54:17 <dgilmore> but as we will make f23 keys tomorrow we should make a change there if we plan to
16:54:56 <dgilmore> We could use something like RPM-GPG-KEY-fedora-22-primary@fedoraproject.org or fedora-22-primary@fedoraproject.org
16:55:03 <dgilmore> was in the proposal
16:55:44 <dgilmore> I do not know that I like either but I also do not know of anything better
16:55:44 <pbrobinson> the later looks a little cleaner
16:56:09 <dgilmore> fedora-23-primary-gpg@fedoraproject.org maybe?
16:56:20 <dgilmore> the later is cleaner
16:56:33 <dgilmore> i just wonder if people would be confused
16:58:34 <dgilmore> #action will make a choice when making the keys
16:58:40 <dgilmore> #undo
16:58:40 <zodbot> Removing item from minutes: ACTION by dgilmore at 16:58:34 : will make a choice when making the keys
16:58:51 <dgilmore> #action dgilmore will make a choice when making the keys
16:59:11 <dgilmore> #topic #6100 create bsd-style checksum files for CHECKSUM files
16:59:22 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6100
17:00:02 <dgilmore> I am not opposed to this but we would need to dig into the different places where CHECKSUM's are made and change the command flags
17:01:10 <dgilmore> there may be scripts that do other checking that could break
17:01:20 <dgilmore> but I am not sure what they would be
17:01:35 <bochecha> if they use xxxsum -c then they should work just fine
17:01:41 <dgilmore> right
17:01:46 <bochecha> if they try to parse the stuff on their own, well...
17:01:53 <dgilmore> but if they do thier own parsing they may break
17:02:05 <dgilmore> so lets attempt it
17:02:12 <dgilmore> see how it goes
17:02:44 <dgilmore> some of the places we make CHECKSUM's are in the releng git repo
17:02:44 <dgilmore> and some is in pungi
17:03:13 <dgilmore> #action dgilmore to make this happen
17:03:21 <dgilmore> #topic open floor
17:03:33 <dgilmore> anyone have anything they want to discuss?
17:03:44 <bochecha> we've made some progress on the move away from md5 for the lookaside cache
17:04:00 <bochecha> one point we need to decide, is the format of the sources file
17:04:32 <bochecha> we could use the BSD style, like in the previous topic
17:04:53 <dgilmore> I would be okay with that
17:05:00 <bochecha> one problem though is that a sources file might end up containing both md5 (an existing archive) and sha512 (a newly uploaded archive)
17:05:19 <bochecha> which brzks verification with md5sum -c or sha512sum -c
17:05:35 <bochecha> we were wondering with pavol if we shouldn't instead have the hashtype in the file name
17:05:39 <bochecha> like sources-sha512
17:05:40 <bochecha> or something
17:06:11 <dgilmore> I do not like the idea of multiple sources files
17:07:18 <bochecha> me neither, it means painful merging of the files
17:07:26 <bochecha> (e.g if a tarball is present in both, which one do you use?)
17:07:39 <dgilmore> or code in fedpkg to update all files when one is updated
17:07:52 <bochecha> right, moving from md5 to sha512 as well
17:08:00 <dgilmore> yep
17:11:31 <dgilmore> so when we update a file we generate new hashes for the other files already tehre
17:12:41 <bochecha> I would prefer putting all in one 'sources' file, with the BSD-style lines, and not worry about people getting warnings for the sha512 lines when they do « md5sum -c sources », or warnings about md5 lines when they do « sha512sum -c sources »
17:13:34 <dgilmore> an option I guess
17:13:50 <tyll> is it usual that the sources file is updated and not replaced?
17:14:10 <dgilmore> sometimes
17:14:27 <dgilmore> there is a bunch of packages with multiple tarballs
17:15:01 <bochecha> including packages with multiple tarballs because maintainers never replace the old ones
17:15:13 <dgilmore> we are mostly concerned with some corner cases
17:15:18 <bochecha> (so fedpkg ends up downloading them all, even though only the last one is needed)
17:17:42 <dgilmore> maybe we should write some docs/blogposts about ways to manage the sources in your package
17:18:50 <dgilmore> just a useful reminder on the options and what they do
17:22:11 <dgilmore> anyways I think using a standard tool and having the option to verify files using the sha tools would be good
17:24:15 <dgilmore> anything else?
17:24:33 <bochecha> branching is tomorrow, right?
17:24:42 <dgilmore> yes
17:24:56 <dgilmore> tomorrow is branching
17:25:13 <dgilmore> which means new keys, new tags/targets, enabling branched
17:25:22 <dgilmore> getting ready for a TC
17:25:43 <dgilmore> quicyte a few little things that need doing
17:25:47 <tyll> imho it is good to replace old hashes when files are updated otherwise it will nrver happen
17:26:36 <bochecha> tyll, sure, if maintainer runs new-sources with a few ones, one of which is an existing tarball, that would replace the md5 hash by the sha512 one
17:27:02 <bochecha> tyll, if they just add a new source, that wouldn't do anything to the existing sources, just append the new line
17:27:06 <bochecha> or do you mean it should?
17:28:07 <bochecha> (which means it should first download the old tarball, as it might not be present if the maintainer is uploading an additional one)
17:28:21 <tyll> bochecha: yes, or maybe just abort if there are different hashes and ask the maintainer to fix it
17:28:48 <tyll> it depends on how common the problem is
17:29:24 <tyll> if it happens rarely it is imho ok to ask to fix it manually
17:29:41 <bochecha> well, it would be fairly common, at least at first, as it would happen for every use of « fedpkg upload » after the migration for each package, until the first time someone uses « fedpkg new-sources » for each package
17:30:30 <tyll> I alwys use new-sources
17:30:47 <dgilmore> I generally use new-sources
17:30:54 <bochecha> maybe we should remove the upload command :-°
17:30:57 <dgilmore> but sometimes you need to add a tarball
17:31:03 <dgilmore> and upload is there for that
17:31:25 <dgilmore> I do not thing removing upload is a viable option
17:33:55 <tyll> only disallowing it if there is a md5 hash might be a good compromise
17:34:31 <bochecha> tyll, true, forcing a new-sources in such a case, to get all archives with sha512 in sources
17:34:54 <bochecha> that's actually a pretty good idea, it completely removes the worry about mixing hashes in a single file :)
17:35:09 <bochecha> I'll talk to pbabinca bout this tomorrow, and rework my patches
17:36:20 <tyll> at some point we also should enforce that all sources files use sha512, maybe for f23 or so
17:37:09 <bochecha> yeah, I already have a patch that eventually prevents uploading of md5sum when we get there, and we can script a mass-update of the sources file for the onew that never got updated as part of regular maintenance ;)
17:43:13 <dgilmore> bochecha: only time we could script updating it is when doinga  mass rebuild
17:43:19 <dgilmore> but I do not want to do it then
17:43:26 <dgilmore> because it will slow it down
17:44:07 <dgilmore> not sure we really want fedpkg build forcing it
17:48:16 <tyll> why does it need a rebuild?
17:48:59 <dgilmore> tyll: the sources files updates?
17:49:10 <tyll> dgilmore: yes
17:49:33 <dgilmore> tyll: I was saying the only way to easily force the update of all sources files is at mass rebuild time
17:49:48 <dgilmore> but downloading all the tarvballs and computing the sha512 will slow it done
17:50:25 <dgilmore> the only thing that could force people update it is to have fedpkg build force it
17:50:32 <dgilmore> since you can use git to commit
17:50:39 <tyll> we can get the sha512 sums from pkgs directly
17:50:43 <dgilmore> and the only time you use fedpkg is to build
17:51:04 <dgilmore> we can not easily do so
17:52:11 <dgilmore> tyll: http://pkgs.fedoraproject.org/lookaside/pkgs/fedora-release/fedora-release-22.tar.bz2/
17:52:35 <dgilmore> how would we know which is the sha512 that matches the tarball we are using?
17:52:59 <dgilmore> probably for most we could go and look and get it
17:53:07 <dgilmore> but there are cases we can not
17:53:13 <tyll> dgilmore: i meant computing it there
17:53:29 <dgilmore> tyll: it still takes a lot fo time
17:53:53 <bochecha> tyll, we're already going to do that, all the tarballs on the lookaside cache will be present under both their md5sum and sha512sum
17:54:25 <tyll> i can do it, when this is ready
17:54:43 <tyll> or fail trying
17:55:48 <dgilmore> we could maybe do it when we convert but it may catch people by surprise and cause conflicts
17:56:13 <dgilmore> lets discusss this later in #fedora-releng
17:56:18 * dgilmore is getting hungry
17:56:20 <tyll> we can do it after a while
17:56:28 <tyll> ok
17:57:21 <dgilmore> there is probably a few ways to do it
17:57:26 <dgilmore> lets look at the options
17:57:41 <dgilmore> if no one has anything else I will wrap up the meeting
17:58:27 <dgilmore> #endmeeting