Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi,
wow, amazing that you are still investing your time in improving my packaging -
thanks a lot! :D
Quoting Jakub Wilk (2014-07-12 18:24:26)
> I don't doubt that compatibility.min.js is needed. What I questioned is
> whether we ever need compatibility.js in the binary package.
Indeed. I missed the "non-" of "non-minified" in your message. The non-minified
version was indeed not used and in fact some other non-minified file there are
not used either so I just deleted them since it's fine to only ship the
minified versions in the binary package as long as the source package has the
real versions, right?
> Who is the copyright holder for the files in debian/? According to the
> copyright file it's WANG Lu. :-P
Indeed it was. If you look at the upstream repository you'll see a Debian
directory there which I used as a start for my packaging. Now I nearly changed
everything. So I'm not sure anymore what would be appropriate as the copyright
of the packaging itself. Probably putting both our names would be most fitting?
I guess I just didnt pay attention to that because I put little importance on
having my name as the copyright holder as long as the license is free enough
for me to make all modifications I want to it.
> The machine-readable debian/copyright file specification advices against
> using “MIT” as the short license name.
I'm currently reading
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ and you
probably mean the part where it says "There are many versions of the MIT
license. Please use Expat instead, when it matches."? On the other hand it uses
MIT as the short name in the section "Example 4. Complex".
On the other hand, the license seems to also exactly fit the wording of the
Expat license so I did s/MIT/Expat/ for clarity.
> Short license name for GPL version 3 or a later version is “GPL-3+”, not
> “GPL-3”.
I do not think the package is GPL-3+. Have a look at README.md where it says
the license is GPL-3 (without a "or later"). Or do you see it different
anywhere else? I could clarify with upstream.
> s/On On/On/
Yeah.. I'd like to have some standardized copy-pastable debian/copyright
paragraphs for the standard licenses in /usr/share/common-licenses so that this
kind of stuff does not happen :/
> IMO information about which files where excluded .orig.tar doesn't belong in
> d/copright, especially when they weren't excluded for license reasons.
Why not? debian/copyright lists the copyright of all files in the upstream
source. Since I removed some files from it I list those in debian/copyright,
saying that I will not state copyright information about those files as they
have been removed.
Indeed the files I removed were DFSG free. I only removed them to not have
redundant copies of files that are otherwise in Debian. This in turn made it
easier to write debian/copyright.
If not listing them in Files-Excluded, should I instead write a repack script
which is called by uscan?
> Speaking of which, how exactly was the .orig.tar generated?
The first one manually (by removing the items listed in Files-Excluded) and
then by uscan. Since uscan understands Files-Excluded in debian/copyright it
did the repacking for me and I didnt have to write a repack script or a
get-orig-source target in debian/rules.
I thought this was the most elegant way to achieve this.
Which way is better?
> It would be nice if the TMPDIR environment variable was honoured.
Good catch! How did you find that? I fixed that and will forward the patch to
upstream.
There are still other accesses to /tmp without honoring TMPDIR but I cannot
find the piece of code that makes these. It's just calling stat on /tmp,
creating an empty file with random name and then deleting it without writing
into it. Maybe one of the other libraries does it?
> In the build log I see:
>
> dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/pdf2htmlex/usr/bin/pdf2htmlEX was not linked against libgunicode.so.3 (it uses none of the library's symbols)
> dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/pdf2htmlex/usr/bin/pdf2htmlEX was not linked against libpython2.7.so.1.0 (it uses none of the library's symbols)
>
> It would be nice to get rid of these warnings.
Removing useless linking against libpython2.7.so.1.0 was easily fixed by not
build depending on python-dev.
I do not think that not linking against libgunicode.so.3 would avoid a useless
dependency because libgunicode.so.3 is shipped by the libfontforge1 package and
pdf2htmlEX links against libfontforge.so.1 and libgutils.so.1 which are both
from the libfontforge1 package.
> What is default-jre-headless in Build-Depends for?
that was to execute the java jar files that the source package shipped in the
3rd party directory (like yui-compressor). This is not needed anymore as the
dependency on yui-compressor draws that in anyways. Fixed.
cheers, josch
Reply to: