Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi,
Quoting Jakub Wilk (2014-08-01 22:31:46)
> * Johannes Schauer <j.schauer@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.6020002@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
Reply to: