[Debichem-devel] dl-poly-classic_1.10+dfsg-1_amd64.changes REJECTED

[Sean Whitton]

Hello Michael,

On Sun 23 Feb 2020 at 05:44PM +01, Michael Banck wrote:

> Hi,
>
> On Sun, Feb 23, 2020 at 09:18:18AM -0700, Sean Whitton wrote:
>> On Sun 23 Feb 2020 at 02:48PM +01, Michael Banck wrote:
>> > To be more constructive, are you ok with some elaborate scheme where we
>> > first pipe LICENSE.pdf through pdftotxt or whatever (which appears to
>> > have semi-sensible output), and then purge the PDF before repackaging?
>>
>> This is fine with me though you would have to ensure the text does
>> actually come out identical.
>
> It turns out upstream is on gitlab these days as I found out earlier
> today so I filed a bug and they just closed it via
> I happened to stumble over their upstream gitlab earlier today as dd

I think you're referring to this:
<https://gitlab.com/DL_POLY_Classic/dl_poly/-/commit/116f1e72440d9b85d0a0356f29c2ea26d688ba8f>

> 1.) Keep LICENSE.pdf in the orig.tar.gz and patch in upstream's new .md
> version via debian/patches on the grounds that this gives the user that
> unpacks the source package the source of LICENSE.pdf.
>
> 2.) Package current git master instead of the 0.10 release.
>
> I'd prefer 1.) but if you think only 2.) (or some additional
> purging/repackaging of LICENSE.pdf) is the only acceptable solution, we
> can do that.
>
> Or do you think the LICENSE.md in git is not appropriate as source for
> LICENSE.pdf and something else (what?) is required for that?

The question is whether the License.md they just added is actually the
source of the LICENSE.pdf file.  To be honest I don't think we have any
reason to think that; upstream may have just copied and pasted the text
into a markdown file.

Given this, you would have to add LICENSE.pdf to your existing
DFSG-filtering process.  It can't end up as part of your upload.

Then there are two options:
1) package current git master
2) use debian/patches to backport upstream's commit adding License.md

I am fine with either of these but Stuart's concern is answered only by
(1).

-- 
Sean Whitton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debichem-devel/attachments/20200223/637ff8e5/attachment.sig>