[Debichem-devel] dl-poly-classic_1.10+dfsg-1_amd64.changes REJECTED
Michael Banck
mbanck at debian.org
Sun Feb 23 16:44:45 GMT 2020
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
> Just a reminder, you'll want to suffix +dfsg to the upstream version
> number when doing the repacking.
We already have that because we throw away the user manual (which is a
PDF with no source as well), sigh...
> > Or maybe just add the .txt (as a Debian patch), as there is really no
> > artistic add-ons in the PDF to the text whatsoever, and I hope we are
> > not going to argue about the margin sizes or font types etc.
>
> I think this is okay but it wouldn't satisfy Stuart's concern that
> someone downloading only the .orig.tar should be able to find the
> license text there.
So I two possibilties:
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?
Michael
More information about the Debichem-devel
mailing list