Paul Wise <pabs@debian.org> writes: > On Tue, Jul 2, 2013 at 7:35 PM, Stewart Smith wrote: > >> I'll investigate this first thing in the morning (it's getting late), >> although it looks as though the tar.gz didn't fully download (yes, it's >> really 135MB) > > Looks like your tarball is named incorrectly (tar.gz instead of > orig.tar.gz) and your website returns a HTTP 302 code (redirect) and > some HTML for the orig.tar.gz URL rather than a 404. I'll ensure our process includes putting the tarball up named correctly. The tarball in that directory should be the right one when named correctly though (unless I brain-farted and got it wrong :) >> Yep, we typically do this. We use a key for the company rather than our >> individual ones for our current repositories. Is this an acceptable >> approach for packages going into Debian? Or should we just have the few >> individuals sign it if they're involved? > > It is a reasonable approach for upstream tarballs. Uploads to Debian > need to be signed by one of the keys in the developer keyring or a > subkey of one of those keys. My guess is the reasonable thing to do is ensure that a few of us have keys in the keyring then so that there's some redundancy (after all, we have to let people take vacation :) >> We'd need to depend on very specific 5.1, 5.5 and 5.6 versions of both >> MySQL and Percona Server (which isn't yet packaged) and we'd also have >> to patch it. >> >> Our short/medium term plan is to do away with having multiple server >> source trees and binaries. We instead plan to just make a modified MySQL >> branch where we just include the needed (modified) source. In an ideal >> world the needed code would be buildable as a library and we'd get the >> needed patches upstream. It is not an ideal world however :( > > I see, maybe you have chosen the way of least pain. We try to :) >> I'm not really attached either way... It appears that it may not be >> worth having it. I'll defer to the experts on this one. > > Maybe ask your userbase if they need it? I'll reach out through our support org. I suspect we'd be fine without it. >> I'll bring it up there. We would see that as simply a patch that's >> needed for that version to be included in that Os and thus not an issue. > > The danger is if that approach to interpretation if the policy were to > change. Okay. I'll bring it up on debian-devel and see if we need changes (it just means I probably get to talk trademark law more... which is generally something I try to avoid :) >> It's certainly something we may be interested at looking at... I guess >> we'll see what the buildds say :) >> >> We do have a test suite. It does (of course) depend on having server >> binaries around to run backup and restore with. Our CI infrastructure >> currently uses just binary tarballs of various server versions, but this >> probably isn't ideal for Debain so we'll have to come up with another >> solution. One thing to consider is that (like MySQL) running the test >> suite takes a non-trivial amount of time. > > Please do enable the test suite for Debian builds and run them with > the binaries built during the build process. The problem we'll have to solve is running against MySQL (and Percona Server) versions... and I'm not sure the best way to wrangle that (we probably have to fix a bug or two in the test suite to ensure it works against an installed binary - we currently download binary tarballs and run against them). -- Stewart Smith
Attachment:
pgpW56RKsbyWq.pgp
Description: PGP signature