[debian-mysql] mysql-5.7 remove dojo patch

[Lars Tangvald]

Hi,

I don't think we should have an override, since this is a legitimate 
issue in the source (the source files are there, but the source tarball 
shouldn't really have binaries).
Also, this is a bit tentative, but I think we can handle this upstream, 
meaning we shouldn't need the patch either, in the future.

--
Lars

On 11/08/2016 02:30 PM, Bjoern Boschman wrote:
> Hi,
>
> makes sense to me. I removed mysql-5.7/repack-no-ndb-frontend and 
> added a new branch mysql-5.7/dojo-lintian 
> <https://anonscm.debian.org/cgit/pkg-mysql/mysql.git/log/?h=mysql-5.7/dojo-lintian> 
> which includes a debian/source/lintian-overrides file.
> Source pkg would be lintian clean by now
> https://www.boschman.de/jenkins/job/mysql-5.7-source/17/
>
> Shall I merge that change to debian/master?
>
> Cheers
> B
>
> On Tue, Nov 8, 2016 at 12:45 PM Lars Tangvald 
> <lars.tangvald at oracle.com <mailto:lars.tangvald at oracle.com>> wrote:
>
>
>     On 11/08/2016 12:31 PM, Robie Basak wrote:
>     > Hi Bjoern,
>     >
>     > On Tue, Nov 08, 2016 at 11:10:10AM +0000, Bjoern Boschman wrote:
>     >> there's a option to repack upstream source.
>     >> I've created a branch that would include these changes:
>     >>
>     https://anonscm.debian.org/cgit/pkg-mysql/mysql.git/log/?h=mysql-5.7/repack-no-ndb-frontend
>     >> What do you and the rest of the team think about this approach?
>     > Thank you for proposing the branch!
>     >
>     > Repacking causes some additional pain for various reasons (eg.
>     cannot
>     > necessarily reproduce the same bit-identical tarball, so really
>     only a
>     > DD uploader should be producing it, so it can't be committed to
>     the VCS
>     > in advance since an uploader cannot be sure it isn't trojaned
>     without
>     > tedious verification). It's easier to stick to the upstream's
>     release
>     > tarball when possible.
>     >
>     > So I'd prefer to avoid repacking, which is why we tried to do it
>     with
>     > quilt in the first place IIRC. Technically AFAIK these files aren't
>     > actually non-DSFG to redistribute so are permitted to be part of the
>     > Debian source package; we just don't want them to form part of the
>     > binary packages for policy reasons ("binaries must be buildable from
>     > source that is non-minified", etc).
>     >
>     > OTOH, if maintaining the quilt patch (and lintian overrides, etc) is
>     > really becoming painful, then I'm fine with resorting to
>     repacking if we
>     > have to do it. And your use of Files-Excluded in
>     debian/copyright is the
>     > way I'd expect it to be done in this case - thanks.
>     >
>     > If you do push this, then please don't push the pristine-tar
>     branch to
>     > VCS yourself any more since then the first uploader of a particular
>     > upstream version will have to spend extra effort verifying it.
>     >
>     > That's my opinion anyway. I'd prefer not to do it this way, but
>     if the
>     > only people maintaining the exclusions want it this way, then fine.
>     >
>     > Lars, what's your opinion?
>     As you say, I don't think the files themselves are a violation (the
>     source for the minified js and swf files is also present, but the
>     compiled files cause a mess of lintian errors).
>     The biggest pain points of the patch are that it's really big, as
>     Bjoern
>     mentioned, and that we can't actually patch out the swf files, so we
>     still get a few lintian errors. It's ugly, but I don't think it's
>     a huge
>     problem. The change itself looks good to me as well, though I'd also
>     like to avoid repacking if possible. I can try another round of
>     queries
>     upstream to see if there's any chance of removing these files in
>     future
>     versions, and if that's a no we can revisit this?
>
>     --
>     Lars
>     >
>     > Please could you keep debian/changelog changes in separate commits
>     > though please? This makes cherry-picking easier. IOW, don't change
>     > debian/changelog in anything but its own commit, and there's no
>     need to
>     > update debian/changelog except before upload (we'll use git-dch to
>     > create changelog entries from git commit logs). We had a thread
>     about
>     > this a while back.
>     >
>     > Robie
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20161109/b795da06/attachment.html>