16:40:38 <dgilmore> #startmeeting
16:40:38 <zodbot> Meeting started Mon Mar  3 16:40:38 2014 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:40:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:40:50 <dgilmore> #meetingname releng
16:40:50 <zodbot> The meeting name has been set to 'releng'
16:41:17 <dgilmore> #admin tyll nirik dwa
16:41:25 <dgilmore> #topic roll call
16:41:27 * tyll is here
16:41:28 <dgilmore> whos here?
16:41:29 * nirik waves
16:41:33 <bochecha> dgilmore, #chair, not #admin :P
16:41:35 * bochecha is here too
16:41:48 <dgilmore> bahh
16:41:53 <janeznemanic> hi
16:41:57 <dgilmore> #chair tyll nirik dwa
16:41:57 <zodbot> Current chairs: dgilmore dwa nirik tyll
16:42:05 <dgilmore> hi bochecha and janeznemanic
16:44:31 * sharkcz is here
16:45:07 <dgilmore> #chair sharkcz
16:45:07 <zodbot> Current chairs: dgilmore dwa nirik sharkcz tyll
16:45:27 <dgilmore> no idea where masta is he doesnt seem to be online
16:45:58 <dgilmore> ok lets get started
16:46:03 <dgilmore> #topic tickets
16:46:08 <dgilmore> https://fedorahosted.org/rel-eng/report/10
16:46:17 <dgilmore> we have three for today
16:46:32 <dgilmore> #topic
16:46:37 <dgilmore> #topic https://fedorahosted.org/rel-eng/ticket/5854
16:46:42 <dgilmore> ticket 1
16:47:00 <dgilmore> there has been no update in 2 weeks
16:47:46 <dgilmore> since masta is not here not much to do
16:47:48 <tyll> #info masta wants to work on it
16:48:00 <dgilmore> #topic https://fedorahosted.org/rel-eng/ticket/5362
16:48:09 <dgilmore> xz compression for metadata
16:48:38 <dgilmore> does any one want to take on the action items?
16:49:10 <tyll> I believe someone volunteered but I do not remember who
16:49:23 <bochecha> otherwise, I could look at it
16:49:44 <dgilmore> #info owners needed for action items
16:50:42 <tyll> 17:03:54 <dgilmore> #action dgilmore to take ownership of implementing from http://meetbot.fedoraproject.org/teams/releng/releng.2014-02-17-16.34.log.html
16:50:53 <dgilmore> there we go
16:50:58 <dgilmore> I owe patches
16:51:13 * dgilmore has not looked at it
16:52:24 <dgilmore> #info dgilmore already said he will look at it and needs to
16:52:24 <dwa> (belatedly, I'm here)
16:52:40 <dgilmore> welcome dwa
16:53:07 <dgilmore> okay I have nothing to update
16:53:23 <dgilmore> #topic https://fedorahosted.org/rel-eng/ticket/5859
16:53:45 <dgilmore> so there is no reason the meeting was skipped
16:54:05 <dgilmore> but I did a poor job of communicating i would not be available
16:54:18 * dgilmore is still getting used to having regular meetings
16:54:58 <dgilmore> that said
16:55:18 <dgilmore> next week i will be on PTO monday through Wednesday
16:55:41 <dgilmore> so that means either we skip the meeting or someone else needs to run it
16:56:15 <dgilmore> does anyone have an opinion?
16:56:27 <sharkcz> for the record /me is also on PTO next week Mon thru Wed
16:56:53 * nirik should be around, but is fine with skipping
16:57:13 <tyll> I am for skipping, since there might not be much to talk about anyhow and usually dgilmore knows the answers to most questions if any arise
16:57:24 <dgilmore> thats fine
16:57:37 <dgilmore> #info, will be skipping next weeks meeting
16:58:28 * dgilmore does realise he needs to change and do better about communicating
16:58:42 <dgilmore> bad habits to break
16:59:02 <tyll> dgilmore:  will you be around on 2013-03-17? It would be the date for the next meeting then
16:59:38 <dgilmore> tyll: yep i will be
16:59:52 <tyll> #info next meeting will be on 2013-03-17
17:00:03 * dgilmore has no travel planned after this weekends trip
17:00:18 <dgilmore> lets get the secondary arch updates real quick
17:00:27 <dgilmore> #topic secondary arch updates
17:00:34 <dgilmore> #topic secondary arch updates: s390x
17:00:39 <dgilmore> sharkcz: your up :)
17:00:45 <dgilmore> you're
17:01:53 <sharkcz> rawhide blocked by couple issues - glibc, strigi, gsl, systemtap (actually it crashes in docs generation)
17:02:05 <dgilmore> ewww
17:02:14 <dgilmore> getting help on them?
17:02:15 <sharkcz> strig and gsl are common to ppc
17:02:22 <sharkcz> yes, for some
17:02:42 <dgilmore> is strigi and gsl endian issues?
17:02:57 <sharkcz> most likely
17:03:05 <sharkcz> they fail in test suites
17:03:20 <dgilmore> okay
17:03:54 <dgilmore> anything else?
17:04:01 <sharkcz> nope
17:04:16 <dgilmore> #info sharkcz reports issues with glibc, strigi, gsl, systemtap blocking rawhide
17:04:27 <dgilmore> #topic secondary arch updates: ppc
17:04:34 <dgilmore> dwa: you're up
17:05:12 <sharkcz> ppc adds ruby to the list, it's being worked on by IBM
17:05:27 <dgilmore> okay
17:05:32 <dgilmore> where is ppc64le?
17:05:34 <dwa> right now we're bootstrapping ppc64le
17:05:54 <dwa> running into weird problems with rpm ordering in yum with glibc, so looking at that first
17:06:02 <dgilmore> okay
17:06:47 <dwa> (it's horrible and weird but the toolchain team is looking at it..)
17:06:50 <dgilmore> dwa: hopefully we can get ppc64le built and caught up by the time we get to the f21 mass rebuild
17:06:58 <dwa> when will that be?
17:07:14 <dgilmore> to be clear it will share koji with ppc64 and ppc
17:07:18 <dgilmore> dwa: no idea yet
17:07:25 <dwa> ok
17:07:45 <dgilmore> depends on features and schedule coming out
17:07:48 <dwa> dgilmore: I thought the bootstrap process called for a temporarily-separate koji instance for one of the last stages before it gets integrated in
17:08:17 <dgilmore> dwa: no, it calls for rebuilt in koji
17:08:26 <dgilmore> which i guess could be a external koji
17:09:08 <dgilmore> dwa: just making sure that no one will expect a ppc64le.koji.fedoraproject.org
17:09:33 <dgilmore> im expecting that f21 will end up being scheduled for october
17:09:59 <dgilmore> mass rebuild probably in early may
17:10:04 <dgilmore> depending on features
17:11:01 <dgilmore> #info sharkcz reports same issues as s390 with addition of ruby
17:11:21 <dgilmore> #info dwa gives status update on ppc64le bootstrap
17:12:19 <dgilmore> dwa: anything you want to bring up?
17:12:57 <dwa> dgilmore: not for the meeting
17:13:36 <dgilmore> dwa: cool
17:13:51 <dgilmore> #topic secondary arch updates: arm
17:14:00 <dgilmore> aarch64 is getting there
17:14:26 <dgilmore> there has been some issues with atlas that were fixed this last week
17:14:50 <dgilmore> we need to look at what media etc to produce and how to produce them
17:15:09 <dgilmore> look into producing disk images
17:15:26 <dgilmore> still a long way to go
17:16:02 <dgilmore> there is a bug in teh secondary arch sync script that keeps deleting the tree that i need to fix
17:16:27 <dgilmore> #info there was an atlas bug holding some things up
17:16:56 <dgilmore> #actiond dgilmore to fix bug in sync script that keep deleting the aarch64 tree
17:17:01 <dgilmore> #action dgilmore to fix bug in sync script that keep deleting the aarch64 tree
17:17:13 <dgilmore> #topic open floor
17:17:31 <dgilmore> anyone have anything they want to bring up?
17:17:45 <bochecha> I have a couple of stuff pending, that need someone to review
17:17:52 <dgilmore> bochecha: okay?
17:17:54 <bochecha> is now the right time to mention them? (first releng meeting)
17:17:59 <dgilmore> bochecha: sure
17:18:03 <bochecha> so, there's this, first:https://fedorahosted.org/rel-eng/ticket/5846#comment:14
17:18:19 <bochecha> which should be enough to move away from md5 for the lookaside cache
17:18:32 <dgilmore> bochecha: need to sit down and look at  it
17:18:52 <bochecha> fwiw, I tested it against our own lookaside at $dayjob
17:18:58 <dgilmore> bochecha: id like to have a plan to migrate the existing content to sha256
17:19:15 <bochecha> dgilmore, do you want me to work on a script that does it?
17:19:21 <dgilmore> making hardlinks to a sha256summed directory
17:19:29 <dgilmore> bochecha: sure
17:19:34 <bochecha> as mentioned, I have a lookaside, so I can test thinsg
17:19:34 <tyll> I thought I somewhere mentioned that looking at the hash-size alone will make it hard to migrate to SHA-3
17:19:35 <dgilmore> if you want to
17:19:42 <bochecha> tyll, oh?
17:19:54 <bochecha> sha3 has the same size as another one?
17:20:04 <tyll> bochecha: yes, it will have similar sizes
17:20:05 <bochecha> (note that sha3 is not yet in python's hashlib, iirc)
17:20:46 <bochecha> well, I had earlier patches which allowed a different migration path: https://fedorahosted.org/rel-eng/ticket/5846#comment:4
17:20:52 <tyll> I belive it is not decided which hash lengths will be specified, but it will be something like 128, 256 or 512 bits
17:20:54 <dgilmore> i dont know that we need to dynamically work it out
17:21:11 <dgilmore> id rather when we switch, we switch
17:21:21 <dgilmore> and dont allow new uploads in md5
17:21:34 <tyll> Therefore IMHO it would be better to explicitly name the digest when one is specified
17:23:38 <bochecha> then the patch I had attached in comment 4 might be closer to what we want
17:24:26 <bochecha> fedpkg could use a hash we choose and not make that configurable any more, and the config value becomes a « fallback » for when the chosen hash doesn't match
17:24:45 * masta looks in
17:25:09 <bochecha> e.g we chose to go with sha512 which gets hardcoded in fedpkg/pyrpkg, and the current lookasidehash config stays at md5
17:25:16 <bochecha> uploads are made with sha512 only
17:25:33 <bochecha> and downloads are first verified with sha512, and if they don't match then verified with md5
17:25:36 <dgilmore> bochecha: well the has should only be set in fedpkg
17:26:01 <bochecha> what do you mean?
17:26:05 <dgilmore> pyrpkg is used elsewhere by other things that cant be expected to be changed
17:26:10 <bochecha> right
17:26:21 <dgilmore> we shouldnt be changing apis
17:26:44 <bochecha> but I'm thinking that having the hash in the config file doesn't have much value, as we don't really expect people to change it, and upload differently hashed stuff, right?
17:27:33 <dgilmore> people cant go changing it as they see fit
17:29:21 <dgilmore> having the hash in the sources file has some benefit
17:29:33 <dgilmore> you know exactly what was used in order to verify
17:30:01 <bochecha> except for the current ones that don't have the hash name
17:30:12 <bochecha> for these, you need a fallback value
17:30:19 <bochecha> (which is what I was saying in comment 5)
17:30:25 <bochecha> sorry, comment 7
17:30:40 <dgilmore> so if we changed it later to sha512 or sha3 or some other hashing algorithm  we will always know explictly that sha256 was used to verify the tarball
17:31:11 <bochecha> I don't disagree with that
17:31:17 <dgilmore> bochecha: easily handled by a if statement
17:31:46 <bochecha> my point is: if the hash name is not in the sources file, then what hash type do you use?
17:32:23 * bochecha doesn't want to drag the meeting too long though, so maybe we should discuss this at another time?
17:32:29 <dgilmore> bochecha: Its an implementation detail
17:32:34 <dgilmore> so should only be in fedpkg
17:33:04 <dgilmore> bochecha: you changed the rpkg api
17:33:10 <dgilmore> which affects many things
17:33:29 <dgilmore> we can't do that unless we have a really really good reason
17:33:32 <bochecha> I know, I maintain a pyrpkg-based tool :)
17:33:41 <dgilmore> and honestly I don't see this as one
17:33:46 <tyll> instead of adding the digest to the sources file, the sources could be named matching the algorighm, e.g. sources.sha256 - then sha256sum -c can still be used
17:34:14 <bochecha> ok, so I'll try and rework that without changing the pyrpkg API
17:34:17 <dgilmore> tyll: could be an option
17:34:35 <bochecha> just to be clear, it's ok to change internal code in pyrpkg, as long as it doesn't break the API, right?
17:34:55 <dgilmore> bochecha: right
17:35:17 <dgilmore> bochecha: if we really really need to add extra arguments we can
17:35:21 <dgilmore> just make them optional
17:35:36 <bochecha> sure
17:35:37 <dgilmore> that way existing users will work
17:36:08 <bochecha> I didn't think those patches were perfect anyway, I through them out there quickly to discuss them, now I have a clearer idea of the requirements :)
17:36:46 <dgilmore> I dont see any valid reason to change pyrpkg for this
17:36:54 <dgilmore> it should be self contained in fedpkg
17:37:31 <bochecha> well, I can see other *pkg tools wanting to move away from md5 by reusing that same code, which would be nicer to have in the library rather than duplicated in each tool, but..
17:37:39 <dgilmore> we do want to make sure that existing checksums will continue to verify
17:38:05 <bochecha> (I know I'd like to move away from md5 at work, and I'd rather do it in a way that is compatible with what Fedora does)
17:38:09 <dgilmore> bochecha: well its an implementation detail
17:38:22 <dgilmore> they may not care to verify old sources
17:38:34 <dgilmore> and just change the hash algorithm
17:39:03 <bochecha> true
17:40:02 <dgilmore> thats not for us to decide
17:41:22 * bochecha has other stuff to discuss, but we're already overtime, so I don't mind keeping it for later
17:41:33 <dgilmore> okay
17:41:38 <dgilmore> bochecha: what else?
17:41:47 <dgilmore> i have one thing i want to bring up too
17:41:52 <bochecha> a trivial koji patch: https://lists.fedoraproject.org/pipermail/buildsys/2014-January/004246.html
17:42:07 <bochecha> which only received feedback from masta, if I'm not confusing the names
17:42:15 <dgilmore> bochecha: ill have to talk to the main koji devs about it
17:42:33 <bochecha> fwiw, I'm running in production with that patch since before I submitted it upstream
17:42:34 <dgilmore> bochecha: and he is noiot a koji dev at all
17:42:39 <dgilmore> okay
17:43:00 <bochecha> and it's working perfectly, whereas I was having problems without it (kojid wasn't cleaning up old buildroots at all)
17:44:19 <dgilmore> bochecha: okay, ill bring it up with the main koji devs
17:44:26 <bochecha> cool, thanks :)
17:44:40 <dgilmore> anything else?
17:45:01 <bochecha> the usual: koji-mash :P
17:45:29 <dgilmore> i need to review it :)
17:46:05 <nirik> oh, that reminds me...
17:46:13 <bochecha> I know, I don't expect we make any progress on it during the meeting, I just wanted to make sure I nagged you about it everyday :]
17:46:16 <nirik> would a koji-punji be of use?
17:46:16 <bochecha> that's all for me
17:46:32 <dgilmore> nirik: maybe.
17:46:42 <nirik> that would be nice to be a real task.
17:46:47 <dgilmore> leads into what I was wanting to bring up
17:47:50 <dgilmore> so after talking with the internal releng guys in Brno we are trying to get some code opened
17:48:10 <dgilmore> that would allow us to do a few more things
17:48:20 <dgilmore> and give us some more people to work on the tools
17:49:26 <dgilmore> right now we are getting management to okay it and then legal to review it
17:49:31 <dgilmore> and make sure its all okay
17:49:55 <masta> sounds good
17:50:32 <dgilmore> not really a lot to say about it
17:50:45 <dgilmore> if that falls through then we will need a different approach
17:50:56 <bochecha> what kind of code is there?
17:51:46 <dgilmore> bochecha: its a compose management thing
17:53:28 <dgilmore> anything anyone wants to bring up?
17:53:51 <tyll> I don't
17:53:55 <dgilmore> if not ill close the meeting
17:54:49 <dgilmore> #endmeeting