<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 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 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 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 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>