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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
