Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer j.scha...@email.de, 2014-08-02, 09:33: I'm not familiar enough with the kind of disaster that may happen when linking C++11 compiled code to C++98 libraries Crashes, I suppose. I also do not see any advised fix or how to prevent the situation. There's not much that can be done, other than: - porting pdf2htmlEX to C++98 (unlikely to be feasible); - not uploading the package yet; - keeping your fingers crossed that nothing bad will happen. I did not realize you were offering to sponsor the package but I'm very happy about it :) I set myself as owner of this RFS bug, which I think is supposed to indicate sponsoring willingness. :-) I uploaded the new version. There's a new typo: comparision - comparison I also noticed that the software allows to set ENABLE_SVG=ON which enables generating SVG backgrounds and converting type-3 fonts. But this feature requires CairoFontEngine, CairoRescaleBox and CairoOutputDev from the poppler sources. Should I integrate the required files into the upstream tarball so that we can build with ENABLE_SVG=ON? Embedding a copy of (a part of) Poppler doesn't seem appealing to me. :-( It would be ideal if Poppler provided the required headers files, and perhaps moved Cairo*.o to a separate library (they are currently part of libpoppler-glib). But I have a hunch Poppler maintainers won't like this idea... I also noticed that the required files are shipped by the emscripten binary package. But it'd be quite messy to depend on that binary package for the sources it ships for a different purpose. Yeah, let's not go that way. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi, Quoting Jakub Wilk (2014-08-04 23:03:54) * Johannes Schauer j.scha...@email.de, 2014-08-02, 09:33: I'm not familiar enough with the kind of disaster that may happen when linking C++11 compiled code to C++98 libraries Crashes, I suppose. I also do not see any advised fix or how to prevent the situation. There's not much that can be done, other than: - porting pdf2htmlEX to C++98 (unlikely to be feasible); - not uploading the package yet; - keeping your fingers crossed that nothing bad will happen. I would suggest going for the last option and handle problems once they appear in practice. I uploaded the new version. There's a new typo: comparision - comparison I created a new patch fix-spelling. But since this is the only correction we have so far I guess we wait with forwarding it to upstream until there are more changes than just a single letter? I also noticed that the software allows to set ENABLE_SVG=ON which enables generating SVG backgrounds and converting type-3 fonts. But this feature requires CairoFontEngine, CairoRescaleBox and CairoOutputDev from the poppler sources. Should I integrate the required files into the upstream tarball so that we can build with ENABLE_SVG=ON? Embedding a copy of (a part of) Poppler doesn't seem appealing to me. :-( It would be ideal if Poppler provided the required headers files, and perhaps moved Cairo*.o to a separate library (they are currently part of libpoppler-glib). But I have a hunch Poppler maintainers won't like this idea... Just in case I filed wishlist bug #757055 I also noticed that the required files are shipped by the emscripten binary package. But it'd be quite messy to depend on that binary package for the sources it ships for a different purpose. Yeah, let's not go that way. Agreed. In case #757055 gets resolved we can revisit this feature. I uploaded a new version that fixes the spelling mistake you found. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi, Quoting Jakub Wilk (2014-08-01 22:31:46) * Johannes Schauer j.scha...@email.de, 2014-07-30, 07:24: I do not understand why it fails for you but not for me. How did you run the tests? I ran sadt(1) in the freshly-unpacked source tree. I ran `adt-run -o /tmp/log --source pdf2htmlex_0.11+ds-1.dsc --- schroot sid-amd64-sbuild` This is what the adt-run manpage says about the --source option: By default the package will also be built and the resulting binaries will be used to satisfy test dependencies Presumably it also means that the built tree is used for running tests. (What I've been doing in my packages, as a defensive strategy against accidentally testing against not-installed code, is to copy all the bits necessary to run tests from the package directory to $ADTTMP, then chdir to $ADTTMP, and run tests from there.) I think the last bit makes most sense. I changed the test accordingly. Notice that there is also a dedicated git repository for tests. https://github.com/coolwanglu/pdf2htmlEX-tests But I'd have to ask upstream about copyright first. Also, maybe they can integrate that repository into their releases which would avoid having to make the upstream tarball generation more complex. Have you seen this thread on d-devel@? https://lists.debian.org/53ccf007.6020...@debian.org Yes, but how is it relevant to this? I'm a bit worried, because pdf2htmlex is built in C++11 mode, but it links to libraries built in C++98 mode. If I understand correctly, this is potentially a recipe for disaster. Maybe. I'm not familiar enough with the kind of disaster that may happen when linking C++11 compiled code to C++98 libraries and the thread does not expand much on that. I also do not see any advised fix or how to prevent the situation. What the thread is about is to ensure that the source is compiled with a C++11 capable compiler. I never tested building with an older compiler. Now, it's probably not something that would stop me from uploading the package. Just wanted to make sure that you are aware of this problem. I did not realize you were offering to sponsor the package but I'm very happy about it :) Upstream did a new release a few days ago. It turned out that it allows to drop nine patches because they integrated them. On the other hand I had to add another patch to be able to build with an older version of libfontforge. I uploaded the new version. I also noticed that the software allows to set ENABLE_SVG=ON which enables generating SVG backgrounds and converting type-3 fonts. But this feature requires CairoFontEngine, CairoRescaleBox and CairoOutputDev from the poppler sources. Should I integrate the required files into the upstream tarball so that we can build with ENABLE_SVG=ON? I also noticed that the required files are shipped by the emscripten binary package. But it'd be quite messy to depend on that binary package for the sources it ships for a different purpose. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer j.scha...@email.de, 2014-07-30, 07:24: I do not understand why it fails for you but not for me. How did you run the tests? I ran sadt(1) in the freshly-unpacked source tree. I ran `adt-run -o /tmp/log --source pdf2htmlex_0.11+ds-1.dsc --- schroot sid-amd64-sbuild` This is what the adt-run manpage says about the --source option: By default the package will also be built and the resulting binaries will be used to satisfy test dependencies Presumably it also means that the built tree is used for running tests. (What I've been doing in my packages, as a defensive strategy against accidentally testing against not-installed code, is to copy all the bits necessary to run tests from the package directory to $ADTTMP, then chdir to $ADTTMP, and run tests from there.) Have you seen this thread on d-devel@? https://lists.debian.org/53ccf007.6020...@debian.org Yes, but how is it relevant to this? I'm a bit worried, because pdf2htmlex is built in C++11 mode, but it links to libraries built in C++98 mode. If I understand correctly, this is potentially a recipe for disaster. Now, it's probably not something that would stop me from uploading the package. Just wanted to make sure that you are aware of this problem. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi, Quoting Jakub Wilk (2014-07-28 23:08:11) I do not understand why it fails for you but not for me. How did you run the tests? I ran sadt(1) in the freshly-unpacked source tree. I ran `adt-run -o /tmp/log --source pdf2htmlex_0.11+ds-1.dsc --- schroot sid-amd64-sbuild` Both invocations work now. Nevertheless I fixed this by overriding the --data-dir path with an environment variable as well. I still think it would be better not to pass --data-dir at all. Unlike build-time tests, as-installed tests have the capability of verifying that all the required files are installed, and that they are installed in a place where the software actually expects them. Let's not ruin this advantage by instructing the software where WE expect the files to be. :-) Your reasoning makes lots of sense. I changed things accordingly. Could you set HOME to a non-existent directory in the test script, just like you did in d/rules? Done. Could you remove the “The information above should follow the Patch Tagging Guidelines …” template from d/p/control-test-executable-name? Woops... thanks for noticing! I uploaded the new version to mentors. Have you seen this thread on d-devel@? https://lists.debian.org/53ccf007.6020...@debian.org Yes, but how is it relevant to this? cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer j.scha...@email.de, 2014-07-28, 07:18: The DEP-8 tests fail here. I see lots of errors like this: Error: Cannot open file /home/jwilk/pdf2htmlex-0.11+ds/share/base.min.css for embedding Command return code 1: /usr/bin/pdf2htmlEX --data-dir /home/jwilk/pdf2htmlex-0.11+ds/share --dest-dir /tmp/tmpTajvy6 /home/jwilk/pdf2htmlex-0.11+ds/test/test_data/2-pages.pdf I suppose you shouldn't pass --data-dir when testing the installed version. I do not understand why it fails for you but not for me. How did you run the tests? I ran sadt(1) in the freshly-unpacked source tree. Nevertheless I fixed this by overriding the --data-dir path with an environment variable as well. I still think it would be better not to pass --data-dir at all. Unlike build-time tests, as-installed tests have the capability of verifying that all the required files are installed, and that they are installed in a place where the software actually expects them. Let's not ruin this advantage by instructing the software where WE expect the files to be. :-) Could you set HOME to a non-existent directory in the test script, just like you did in d/rules? Could you remove the “The information above should follow the Patch Tagging Guidelines …” template from d/p/control-test-executable-name? Have you seen this thread on d-devel@? https://lists.debian.org/53ccf007.6020...@debian.org -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi, Quoting Jakub Wilk (2014-07-26 18:35:23) * Johannes Schauer j.scha...@email.de, 2014-07-26, 12:37: upstream responded and I updated their name with the one they told me. Perhaps also update patch headers? Done. I used the (fairly incomplete) testsuite of pdf2htmlEX to run a DEP-8 test. The DEP-8 tests fail here. I see lots of errors like this: Error: Cannot open file /home/jwilk/pdf2htmlex-0.11+ds/share/base.min.css for embedding Command return code 1: /usr/bin/pdf2htmlEX --data-dir /home/jwilk/pdf2htmlex-0.11+ds/share --dest-dir /tmp/tmpTajvy6 /home/jwilk/pdf2htmlex-0.11+ds/test/test_data/2-pages.pdf I suppose you shouldn't pass --data-dir when testing the installed version. I do not understand why it fails for you but not for me. Nevertheless I fixed this by overriding the --data-dir path with an environment variable as well. I don't think the patch description is grammatically correct. I believe that instead of “Allow to control …”, it should be “Allow us to control …” or “Allow controlling …”. It seems that the word allow allows both, gerund and infinitive to follow it. Either should be grammatically fine. I changed it nevertheless to Allow controlling because I don't have a strong opinion on this. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer j.scha...@email.de, 2014-07-26, 12:37: upstream responded and I updated their name with the one they told me. Perhaps also update patch headers? I used the (fairly incomplete) testsuite of pdf2htmlEX to run a DEP-8 test. The DEP-8 tests fail here. I see lots of errors like this: Error: Cannot open file /home/jwilk/pdf2htmlex-0.11+ds/share/base.min.css for embedding Command return code 1: /usr/bin/pdf2htmlEX --data-dir /home/jwilk/pdf2htmlex-0.11+ds/share --dest-dir /tmp/tmpTajvy6 /home/jwilk/pdf2htmlex-0.11+ds/test/test_data/2-pages.pdf I suppose you shouldn't pass --data-dir when testing the installed version. I don't think the patch description is grammatically correct. I believe that instead of “Allow to control …”, it should be “Allow us to control …” or “Allow controlling …”. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer j.scha...@email.de, 2014-07-18, 12:00: But there's a good reason --dry-run is described as “unsafe” in the mktemp manpage. What is the reason? I thought the reason for it being called unsafe was that if you use --dry-run first and then create the directory with that name yourself then somebody else could hijack that location in the meantime. That's right. But this is no problem for this use case. If an attacker can predict what the victim's $HOME is going to be, they can overwrite arbitrary files by creating a $HOME/.FontForge/prefs symlink. More sophisticated attacks might be also possible. Your d/copyright says: Files: * Copyright: 2012 WANG Lu coolwan...@gmail.com Shouldn't it be s/WANG Lu/Lu Wang/? The latter seems to be the spelling used in the code. More importantly, some files have newer copyright dates. For example, src/pdf2htmlEX.cc reads: // Copyright (C) 2012-2014 Lu Wang coolwan...@gmail.com Please bump date in d/changelog. :-) From the wishlist department: You might want to implement DEP-8 tests. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi, Quoting Jakub Wilk (2014-07-17 13:36:47) export HOME=`mktemp --dry-run` This sets HOME literally to `mktemp --dry-run`. I think you wanted to say: export HOME=$(shell mktemp --dry-run) oh shoot it's not shell, it's make... while that method will surely also yield a nonexistant home directory I see why that method is inferior ^^ But there's a good reason --dry-run is described as “unsafe” in the mktemp manpage. What is the reason? I thought the reason for it being called unsafe was that if you use --dry-run first and then create the directory with that name yourself then somebody else could hijack that location in the meantime. But this is no problem for this use case. So how about something like this instead: export HOME=$(CURDIR)/nonexistent This is a good solution. As we have control about the directories in $(CURDIR) we can guarantee that no directory named like that exists during build time. I'll use it. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi, Quoting Jakub Wilk (2014-07-16 21:21:15) Now --download-current-version is broken: $ uscan --download-current-version --destdir . uscan warning: In debian/watch no matching hrefs for version 0.11 in watch line https://github.com/coolwanglu/pdf2htmlEX/releases .*/v(\d[\d\.]*)\.tar\.gz It think you need to drop dversionmangle to fix it. you are right! Though it is quite strange that `uscan --destdir . --force-download` works and `uscan --download-current-version --destdir .` does not. On the other hand I now better understand how version mangling works. I indeed needed to remove dversionmangle. This kept working because uversionmangle will also mangle the links from the upstream site. So now instead of adapting the Debian version to be the upstream version (by removing +ds) the upstream version is adapted to the Debian version (by adding +ds). What do we do about debian-watch-file-should-dversionmangle-not-uversionmangle until #753772 is fixed? Ignore it or create an override? If that is all, then all then I only need somebody to sponsor this :) Do you mean _me_? It's been less than a weak, I haven't even warmed up yet. ;-P good to hear - that means many more suggestions will be coming my way :) I noticed that when you run pdf2htmlEX for the first time, ~/.FontForge/ gets created. This is not itself a problem (even though personally I hate dotfiles with passion). The problem is that it will also happen at build time, thanks to the test suite. Creating dotfiles at build time is a no-no. I guess the simplest way to fix it is to set HOME to something non-existent in debian/rules. Is creating files outside the build directory and not in $TMPDIR a policy violation? I already gather statistics of file system access using the machinery to find unused build dependencies (the thing I wrote about on d-devel). But the gathered data could easily be used to find this kind of things as well. Would that make sense? I would have to adapt the call to sbuild though because by default, sbuild sets $HOME to /sbuild-nonexistent and thus, no dotfiles are created. Anyways, I set $HOME to a nonexistant directory in debian/rules. I think it would be good to add a comment to d/copyright explaining that upstream clarified the license; or maybe cherry pick the commit: https://github.com/coolwanglu/pdf2htmlEX/commit/6e8d5396cdad Currently it might be not obvious to a person who didn't read this RFS thread (such as ftp-master) that your copyright matches upstream intentions. Correct. I cherry picked the relevant parts of the upstream commit. I see you have lots of patches. Which of them are upstreamable? Which of them have been already forwarded? You can answer the questions by adding appropriate Forwarded: headers to the patches. :-) All done. :) cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer j.scha...@email.de, 2014-07-17, 08:31: What do we do about debian-watch-file-should-dversionmangle-not-uversionmangle until #753772 is fixed? Ignore it or create an override? Either way works for me. Is creating files outside the build directory and not in $TMPDIR a policy violation? Policy doesn't say anything about it explicitly. It could be argued, that if the package create such files, then there's no sane way to implement policy-compliant clean target. The clean target “must undo any effects that the ‘build’ and ‘binary’ targets may have had, except that it should leave alone any output files created in the parent directory by a run of a ‘binary’ target”. I already gather statistics of file system access using the machinery to find unused build dependencies (the thing I wrote about on d-devel). But the gathered data could easily be used to find this kind of things as well. Would that make sense? Sounds good to me. :-) All done. :) Hmm, I don't see the new package on mentors.d.n. Did you upload it? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi, Quoting Jakub Wilk (2014-07-17 09:46:58) * Johannes Schauer j.scha...@email.de, 2014-07-17, 08:31: What do we do about debian-watch-file-should-dversionmangle-not-uversionmangle until #753772 is fixed? Ignore it or create an override? Either way works for me. okay then I'll leave things as they are because #753772 seems uncontroversial enough such than one can assume that debian-watch-file-should-dversionmangle-not-uversionmangle should go away in the near future. Is creating files outside the build directory and not in $TMPDIR a policy violation? Policy doesn't say anything about it explicitly. It could be argued, that if the package create such files, then there's no sane way to implement policy-compliant clean target. The clean target “must undo any effects that the ‘build’ and ‘binary’ targets may have had, except that it should leave alone any output files created in the parent directory by a run of a ‘binary’ target”. Good argument. All done. :) Hmm, I don't see the new package on mentors.d.n. Did you upload it? whoops... I indeed forgot. It is uploaded now and should appear online any minute. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
You added: export HOME=`mktemp --dry-run` This sets HOME literally to `mktemp --dry-run`. I think you wanted to say: export HOME=$(shell mktemp --dry-run) But there's a good reason --dry-run is described as “unsafe” in the mktemp manpage. So how about something like this instead: export HOME=$(CURDIR)/nonexistent ? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi, Quoting Jakub Wilk (2014-07-16 00:26:09) uscan does this automatically when repacking upstream tarballs. I don't believe this is the case. And the .orig.tar you uploaded to mentors certainly contains debian/: indeed, you are right! I fixed it and the upstream tarball now comes without the ./debian directory. I don't want to uselessly increase the amount of dependencies of the resulting binary package (even though libpython is probably present on most systems). It wouldn't increase the amount of packages required to run pdf2htmlex, at least not for the time being, because libfontforge depends on libpython. Right. The reason linking to unneeded libraries is bad is because it makes Packages a tiny bit bigger, makes dependency resolved a tiny bit slower, and becomes burdensome when one of the libraries change SONAME. Thanks for educating me :) I didnt think of especially the SONAME change. Though on the other hand it seems I managed to patch the build system such that it will not use libpython anymore (see patch no-libpython). That's much better. Now, can you do the same with gunicode? :-) It turns out that doing so was just as simple! :D What is your opinion about the tarball repacking and the Files-Excluded in debian/copyright? I don't like it, but I'm not going to stop anybody from using it. Then I think I will keep using it. I do see that using debian/copyright is the wrong place for repacking information but I find it easier to list the excluded files in a declarative way instead of embedding yet another fragile repack script. I do not think there is another way to state the excluded files from the original upstream tarball without using a turing complete language than using Files-Excluded. Once there is, I'll immediately switch to it. Note that currently uscan would generate .orig.tar with wrong version; see bug #753772. I can confirm that I was missing a uversionmangle in my debian/watch. This is fixed now. Thanks a lot for your help! If that is all, then all then I only need somebody to sponsor this :) cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer j.scha...@email.de, 2014-07-16, 08:36: Note that currently uscan would generate .orig.tar with wrong version; see bug #753772. I can confirm that I was missing a uversionmangle in my debian/watch. This is fixed now. Now --download-current-version is broken: $ uscan --download-current-version --destdir . uscan warning: In debian/watch no matching hrefs for version 0.11 in watch line https://github.com/coolwanglu/pdf2htmlEX/releases .*/v(\d[\d\.]*)\.tar\.gz It think you need to drop dversionmangle to fix it. If that is all, then all then I only need somebody to sponsor this :) Do you mean _me_? It's been less than a weak, I haven't even warmed up yet. ;-P I noticed that when you run pdf2htmlEX for the first time, ~/.FontForge/ gets created. This is not itself a problem (even though personally I hate dotfiles with passion). The problem is that it will also happen at build time, thanks to the test suite. Creating dotfiles at build time is a no-no. I guess the simplest way to fix it is to set HOME to something non-existent in debian/rules. I think it would be good to add a comment to d/copyright explaining that upstream clarified the license; or maybe cherry pick the commit: https://github.com/coolwanglu/pdf2htmlEX/commit/6e8d5396cdad Currently it might be not obvious to a person who didn't read this RFS thread (such as ftp-master) that your copyright matches upstream intentions. I see you have lots of patches. Which of them are upstreamable? Which of them have been already forwarded? You can answer the questions by adding appropriate Forwarded: headers to the patches. :-) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer j.scha...@email.de, 2014-07-13, 22:23: If you look at the upstream repository you'll see a Debian directory Oops, I missed it. (Wouldn't it make sense to remove it from .orig.tar?) uscan does this automatically when repacking upstream tarballs. I don't believe this is the case. And the .orig.tar you uploaded to mentors certainly contains debian/: $ tar -tf pdf2htmlex_0.11+ds.orig.tar.gz --wildcards '*/debian' pdf2htmlEX-0.11+ds/debian/ pdf2htmlEX-0.11+ds/debian/changelog pdf2htmlEX-0.11+ds/debian/source/ pdf2htmlEX-0.11+ds/debian/source/format pdf2htmlEX-0.11+ds/debian/rules pdf2htmlEX-0.11+ds/debian/pdf2htmlex.NEWS pdf2htmlEX-0.11+ds/debian/dirs pdf2htmlEX-0.11+ds/debian/copyright pdf2htmlEX-0.11+ds/debian/pdf2htmlex.README pdf2htmlEX-0.11+ds/debian/compat pdf2htmlEX-0.11+ds/debian/pdf2htmlex.TODO pdf2htmlEX-0.11+ds/debian/control Removing useless linking against libpython2.7.so.1.0 was easily fixed by not build depending on python-dev. Hmm, that doesn't sound right. It means that a user building in a non-minimal environment can get a package with or without libpython2.7-dev in Depends, depending on which packages they had installed. I think I prefer to live with the dpkg-shlibdeps warnings, than to have this sort of non-determinism. Right. So how about a Build-Conflict with the appropriate binary package? I tend to think of Build-Conflicts as a weapon of last resort. I don't want to uselessly increase the amount of dependencies of the resulting binary package (even though libpython is probably present on most systems). It wouldn't increase the amount of packages required to run pdf2htmlex, at least not for the time being, because libfontforge depends on libpython. The reason linking to unneeded libraries is bad is because it makes Packages a tiny bit bigger, makes dependency resolved a tiny bit slower, and becomes burdensome when one of the libraries change SONAME. Though on the other hand it seems I managed to patch the build system such that it will not use libpython anymore (see patch no-libpython). That's much better. Now, can you do the same with gunicode? :-) What is your opinion about the tarball repacking and the Files-Excluded in debian/copyright? I don't like it, but I'm not going to stop anybody from using it. Note that currently uscan would generate .orig.tar with wrong version; see bug #753772. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer j.scha...@email.de, 2014-07-12, 20:32: 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? That's 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 Oops, I missed it. (Wouldn't it make sense to remove it from .orig.tar?) 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 don't think there's anything left from the original packaging. You can put only your name with clear conscience. :-) 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.? That's what I meant, yes. On the other hand it uses MIT as the short name in the section Example 4. Complex. How odd… 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? LICENSE says “or (at your option) any later version”. Admittedly the latter also says “is licensed under GPLv3”… For extra confusion, upstream's d/copyright says “License: GPL-2 or GPL-3”, but in both license paragraphs they write “or (at your option) any later version”. I could clarify with upstream. Please do. :-) It would be nice if the TMPDIR environment variable was honoured. Good catch! How did you find that? By reading the source. :-) 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? Yup. libfontforge calls tmpfile(3), which doesn't honour TMPDIR. :-( 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. Hmm, that doesn't sound right. It means that a user building in a non-minimal environment can get a package with or without libpython2.7-dev in Depends, depending on which packages they had installed. I think I prefer to live with the dpkg-shlibdeps warnings, than to have this sort of non-determinism. 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. Hmm, yes, in this case the warning is only about ELF dependency, not about Debian package dependency. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi again, Quoting Jakub Wilk (2014-07-13 20:24:00) 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 Oops, I missed it. (Wouldn't it make sense to remove it from .orig.tar?) uscan does this automatically when repacking upstream tarballs. I don't think there's anything left from the original packaging. You can put only your name with clear conscience. :-) well, now you helped me so much I could start putting your name in ;) I could clarify with upstream. Please do. :-) I did ask upstream at https://github.com/coolwanglu/pdf2htmlEX/issues/387 Removing useless linking against libpython2.7.so.1.0 was easily fixed by not build depending on python-dev. Hmm, that doesn't sound right. It means that a user building in a non-minimal environment can get a package with or without libpython2.7-dev in Depends, depending on which packages they had installed. I think I prefer to live with the dpkg-shlibdeps warnings, than to have this sort of non-determinism. Right. So how about a Build-Conflict with the appropriate binary package? I don't want to uselessly increase the amount of dependencies of the resulting binary package (even though libpython is probably present on most systems). Though on the other hand it seems I managed to patch the build system such that it will not use libpython anymore (see patch no-libpython). What is your opinion about the tarball repacking and the Files-Excluded in debian/copyright? I'm not even a DD so if you tell me that the current way I do it is wrong than of course I'll change it and use a repack script instead :) cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi, Quoting Jakub Wilk (2014-07-11 23:48:15) * Johannes Schauer j.scha...@email.de, 2014-07-11, 21:33: How did you find them? I ran codespell but that didnt find the ones you found. I read carefully the source code. :-) (I admit that vim's spell checking helped me a bit.) I just discovered that my Vim spell checking was broken. I fixed it and thus was able to fix some more misspellings. Thank you for your manual effort of compiling the list in your last email! :) I'm unsure how I should handle the minified js. Surely it is desirable to include the minified js in the output pdf2htmlex generates Probably, but is it worth the trouble? The non-minified version is only 8 kilobytes bigger. That's negligible overhead, IMHO. Maybe. But if 100 people convert 10 files each that's already 8M saved. I'll see how much effort it takes to let it use the minified version and will give up if it's too much trouble. but that means that pdf2htmlex has to ship a minified version of compatibility.js from the libjs-pdf package. Hmm, there is no protection against the two versions getting of sync. Which means that there is no guarantee that we are shipping source for the minified version. :( But setting Built-Using: pdf.js would guard against that, would it not? The only disadvantage then would be that a rebuild of pdf2htmlex would be needed every time pdf.js releases a new version. Should the minified version not be shipped by libjs-pdf instead? What is the right way to do this? I see a few ways to go forward: 1) Stop worrying and love the bomb^Wunminified JS. 2) Ask pdf.js maintainers to provide compatibility.min.js, and wait patiently until they implement it (or not). 3) Keep minifying compatibility.js yourself, but use Built-Using to ensure we always have the source. I filed a wishlist bug against pdf.js (#754533) and at the same time introduced a Built-Using: pdf.js. Should pdf.js decide to ship a minified version in the future I can remove the Built-Using. I wouldn't say “In contrast to other converters …” in the package description. It sounds a bit like an advertisement. And it means that changes in other packages could make your package description inadequate. I find the latter part a strong argument and rephrased the description. Priority should be probably optional. Done. Section should be text or maybe graphics; probably not misc. I chose text because I guess most people use pdf for that or associate pdf with that rather than a graphics format. In debian/rules you have this: ( cd logo; ./update_png.sh; ) You don't need parentheses here. You should use between the statements (see Policy §4.6). Thanks. I updated myself on the relevant policy section and the inner workings of make. Indeed the changed directory only affects the subshell and thus does the right thing even without parenthesis. Semicolon is replaced with as well. dh_clean deletes all files listed in debian/clean. If you took advantage of this, you wouldn't need to override dh_auto_clean. This is indeed a much nicer method than overriding dh_auto_clean. Fixed. The watch file doesn't work here: $ uscan --destdir . --force-download pdf2htmlex: Version (0.11) available on remote site: https://github.com/coolwanglu/pdf2htmlEX/archive/v0.11.tar.gz (local version is 0.11+ds, mangled local version number 0.11) Could not read .//coolwanglu/pdf2htmlEX/archive/pdf2htmlEX-0.11.tar.gz: No such file or directory at /usr/bin/mk-origtargz line 310. uscan: error: mk-origtargz --package pdf2htmlex --version 0.11 --compression gzip --directory . --copyright-file debian/copyright .//coolwanglu/pdf2htmlEX/archive/pdf2htmlEX-0.11.tar.gz gave error exit status 2 Somehow it didnt come to my mind to use --force-download to test whether my watch file was able to download an archive in addition to picking the right version. Thanks! The problem was created because the uscan manpage explicitly recommends to use a filenamemangle for github projects. Apparently this does the wrong thing as it also affects the filename used in the download url. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer j.scha...@email.de, 2014-07-12, 09:40: Hmm, there is no protection against the two versions getting of sync. Which means that there is no guarantee that we are shipping source for the minified version. :( But setting Built-Using: pdf.js would guard against that, would it not? It would guard against the possibility of losing source. But it could still happen that compatibility.js and compatibility.min.js versions (in /usr/share/pdf2htmlEX/) don't match. Is the non-minified version used by pdf2htmlEX at runtime at all? I think it isn't, but I could be wrong. If it's not, then maybe get rid of the symlink, and drop libjs-pdf from Depends? I filed a wishlist bug against pdf.js (#754533) and at the same time introduced a Built-Using: pdf.js. I don't think it worked: dpkg-genchanges: warning: unknown information field 'Built-Using' in input data in general section of control info file Built-Using should be used in the binary stanza, not in the source stanza. Please see Policy §7.8. uscan: error: mk-origtargz --package pdf2htmlex --version 0.11 --compression gzip --directory . --copyright-file debian/copyright .//coolwanglu/pdf2htmlEX/archive/pdf2htmlEX-0.11.tar.gz gave error exit status 2 […] The problem was created because the uscan manpage explicitly recommends to use a filenamemangle for github projects. Apparently this does the wrong thing as it also affects the filename used in the download url. Not quite. AIUI, the problem is that uscan expects that filenamemangle will strip directory components from the filename. The uscan manpage suggests using filenamemangle=s/(?:.*)?v?(\d[\d\.]*)\.tar\.gz/project-$1.tar.gz/ which strip them (note .*), but your filenamemangle wouldn't. That said, the fact that uscan doesn't strip directory components after applying filenamemangle sounds like a bug in uscan, with potential security implications... -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi, Quoting Jakub Wilk (2014-07-12 11:50:39) It would guard against the possibility of losing source. But it could still happen that compatibility.js and compatibility.min.js versions (in /usr/share/pdf2htmlEX/) don't match. okay. Indeed that's undesirable. Is the non-minified version used by pdf2htmlEX at runtime at all? I think it isn't, but I could be wrong. If it's not, then maybe get rid of the symlink, and drop libjs-pdf from Depends? Yes it is. You can check that it is used by running the test suite like this: `( cd obj-*-linux-gnu; ctest -V; )`. You will see that it aborts because it cannot find compatibility.min.js in ./share. You have to run the test suite like that because it wrongly shows success even though the tests fail. I'll have to fix that and report it upstream. The file share/manifest or /usr/share/pdf2htmlEX/manifest controls what gets included into the final pdf. It is the @compatibility.min.js line in that file which makes compatibility.min.js be included by the function HTMLRenderer::embed_file in src/HTMLRenderer/general.cc. compatibility.js is optional though. It is only useful for compatibility with older browsers. This even if not the minified version, I'd like to include compatibility.js in the output. I don't think it worked: dpkg-genchanges: warning: unknown information field 'Built-Using' in input data in general section of control info file Built-Using should be used in the binary stanza, not in the source stanza. Please see Policy §7.8. whoops. Sorry. I removed the Built-Using because while it retains the original source, it will not fix the version skew :/ I guess I use the unminified version of compatibility.js until bug#754533 is resolved. Not quite. AIUI, the problem is that uscan expects that filenamemangle will strip directory components from the filename. The uscan manpage suggests using filenamemangle=s/(?:.*)?v?(\d[\d\.]*)\.tar\.gz/project-$1.tar.gz/ which strip them (note .*), but your filenamemangle wouldn't. oooh - indeed that makes more sense now. Thanks a ton for all your very constructive and helpful advice :) cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer j.scha...@email.de, 2014-07-12, 13:06: Is the non-minified version used by pdf2htmlEX at runtime at all? I think it isn't, but I could be wrong. If it's not, then maybe get rid of the symlink, and drop libjs-pdf from Depends? Yes it is. You can check that it is used by running the test suite like this: `( cd obj-*-linux-gnu; ctest -V; )`. You will see that it aborts because it cannot find compatibility.min.js in ./share. You have to run the test suite like that because it wrongly shows success even though the tests fail. I'll have to fix that and report it upstream. The file share/manifest or /usr/share/pdf2htmlEX/manifest controls what gets included into the final pdf. It is the @compatibility.min.js line in that file which makes compatibility.min.js be included by the function HTMLRenderer::embed_file in src/HTMLRenderer/general.cc. I don't doubt that compatibility.min.js is needed. What I questioned is whether we ever need compatibility.js in the binary package. I guess I use the unminified version of compatibility.js until bug#754533 is resolved. Sounds good to me. Who is the copyright holder for the files in debian/? According to the copyright file it's WANG Lu. :-P The machine-readable debian/copyright file specification advices against using “MIT” as the short license name. Short license name for GPL version 3 or a later version is “GPL-3+”, not “GPL-3”. s/On On/On/ IMO information about which files where excluded .orig.tar doesn't belong in d/copright, especially when they weren't excluded for license reasons. Speaking of which, how exactly was the .orig.tar generated? It would be nice if the TMPDIR environment variable was honoured. 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. What is default-jre-headless in Build-Depends for? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package pdf2htmlex * Package name: pdf2htmlex Version : 0.11+ds-1 Upstream Author : WANG Lu coolwan...@gmail.com * URL : http://github.com/coolwanglu/pdf2htmlEX * License : GPL3, MIT, CC-BY-3.0 Section : misc It builds those binary packages: pdf2htmlex - Converts PDF to HTML while retaining most formatting To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pdf2htmlex This is the most advanced PDF to HTML converter that I have seen so far. I was looking for a way to publish the scientific papers I wrote over the years and I wanted to offer a way such that one could view them without having to use a PDF viewer. Unfortunately it seems that the existing options for converting PDF to HTML are missing many features which make them unusable for complex PDF as those produced by latex for scientific conferences and journals (multi column, complicated figures). While not 100% pixel perfect, pdf2htmlEX produces HTML pages that are absolutely readable for all the content I tried. Using the fallback mode it is even possible to view them with javascript disabled. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Control: owner -1 ! * Johannes Schauer j.scha...@email.de, 2014-07-11, 13:48: http://mentors.debian.net/package/pdf2htmlex Direct link to .dsc: https://mentors.debian.net/debian/pool/main/p/pdf2htmlex/pdf2htmlex_0.11+ds-1.dsc fix-spelling seems to be mainly about fixing the use - as minus sign in manpage... Could split the patch into two, one for hyphens, another for actual spelling mistakes? More typos I found: contributers - contributors actualy - actually positionig - positioning cosider - consider tempory - temporary deconstructign - deconstructing matices - matrices new_line_stauts - new_line_status Someting - something natrual - natural negaive - negative othere - other optimzation - optimization cannnot - cannot Inactiviy - Inactivity calulating - calculating lanauges - languages costy - costly What is ./debian/pdf2htmlex.README for? Is debian/dirs really needed? It should be normally job for upstream build system to create the directories it needs. adequate says: pdf2htmlex: broken-symlink /usr/share/pdf2htmlEX/compatibility.js - ../javascript/pdf/compatibility.js -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi, wow, thanks a lot for looking into this! :D Quoting Jakub Wilk (2014-07-11 20:59:44) fix-spelling seems to be mainly about fixing the use - as minus sign in manpage... Could split the patch into two, one for hyphens, another for actual spelling mistakes? okay. Done. More typos I found: contributers - contributors actualy - actually positionig - positioning cosider - consider tempory - temporary deconstructign - deconstructing matices - matrices new_line_stauts - new_line_status Someting - something natrual - natural negaive - negative othere - other optimzation - optimization cannnot - cannot Inactiviy - Inactivity calulating - calculating lanauges - languages costy - costly How did you find them? I ran codespell but that didnt find the ones you found. The ones you found are now fixed in the packaging. What is ./debian/pdf2htmlex.README for? That should've been pdf2htmlex.docs. Fixed. Is debian/dirs really needed? It should be normally job for upstream build system to create the directories it needs. It is not needed. Removed, thanks! adequate says: pdf2htmlex: broken-symlink /usr/share/pdf2htmlEX/compatibility.js - ../javascript/pdf/compatibility.js I fixed that too. The dependency on libjs-pdf was missing. I'm unsure how I should handle the minified js. Surely it is desirable to include the minified js in the output pdf2htmlex generates but that means that pdf2htmlex has to ship a minified version of compatibility.js from the libjs-pdf package. Should the minified version not be shipped by libjs-pdf instead? What is the right way to do this? Thanks! cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer j.scha...@email.de, 2014-07-11, 21:33: How did you find them? I ran codespell but that didnt find the ones you found. I read carefully the source code. :-) (I admit that vim's spell checking helped me a bit.) I'm unsure how I should handle the minified js. Surely it is desirable to include the minified js in the output pdf2htmlex generates Probably, but is it worth the trouble? The non-minified version is only 8 kilobytes bigger. That's negligible overhead, IMHO. but that means that pdf2htmlex has to ship a minified version of compatibility.js from the libjs-pdf package. Hmm, there is no protection against the two versions getting of sync. Which means that there is no guarantee that we are shipping source for the minified version. :( Should the minified version not be shipped by libjs-pdf instead? What is the right way to do this? I see a few ways to go forward: 1) Stop worrying and love the bomb^Wunminified JS. 2) Ask pdf.js maintainers to provide compatibility.min.js, and wait patiently until they implement it (or not). 3) Keep minifying compatibility.js yourself, but use Built-Using to ensure we always have the source. I wouldn't say “In contrast to other converters …” in the package description. It sounds a bit like an advertisement. And it means that changes in other packages could make your package description inadequate. Priority should be probably optional. Section should be text or maybe graphics; probably not misc. In debian/rules you have this: ( cd logo; ./update_png.sh; ) You don't need parentheses here. You should use between the statements (see Policy §4.6). dh_clean deletes all files listed in debian/clean. If you took advantage of this, you wouldn't need to override dh_auto_clean. The watch file doesn't work here: $ uscan --destdir . --force-download pdf2htmlex: Version (0.11) available on remote site: https://github.com/coolwanglu/pdf2htmlEX/archive/v0.11.tar.gz (local version is 0.11+ds, mangled local version number 0.11) Could not read .//coolwanglu/pdf2htmlEX/archive/pdf2htmlEX-0.11.tar.gz: No such file or directory at /usr/bin/mk-origtargz line 310. uscan: error: mk-origtargz --package pdf2htmlex --version 0.11 --compression gzip --directory . --copyright-file debian/copyright .//coolwanglu/pdf2htmlEX/archive/pdf2htmlEX-0.11.tar.gz gave error exit status 2 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
