* 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
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
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
* 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
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
* 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
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
* 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
* 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
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
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
* 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
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
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
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
* 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
* 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
* 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
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
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
* 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
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
* 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
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
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
*
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
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:
* 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
28 matches
Mail list logo
