Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi,
Quoting Jakub Wilk (2014-07-11 23:48:15)
> * Johannes Schauer <j.schauer@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
Reply to: