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