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