Re: RFS: xpdf (updated package)
On Wed, Jun 02, 2010 at 10:38:33PM -0400, Michael Gilbert wrote: Dear mentors, I am looking for a sponsor for the new version 3.02-3 of my package xpdf. It builds these binary packages: xpdf - Portable Document Format (PDF) suite xpdf-common - Transitional package for xpdf xpdf-reader - Transitional package for xpdf xpdf-utils - Transitional package for poppler-utils The package appears to be lintian clean. The upload would fix these bugs: 351279, 461411, 548182, 548183, 548184, 548185, 576543, 576683, 577031, 577086, 577917, 578892 I have updated the package to use poppler instead of its own rendering code, which is a fairly significant but very useful/important change. This change is for sure quite significant. BTW, do you know if the internal code in xpdf is equivalent feature wise to poppler? I know that poppler was a spin-off of the rendering code of xpdf. Do you know how much they deviate one from another? The reason of my question is that there are several pdf viewers in the repository based on poppler. One of them is evince which often crashes on large pdf files. In these cases xpdf was an old-and-slow-but-always-working solution. -- Stanislav -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100603073321.ga20...@kaiba.homelan
Re: RFS: xpdf (updated package)
Here is what I get: $ dget -u http://mentors.debian.net/debian/pool/main/x/xpdf/xpdf_3.02-3.dsc $ cd xpdf-3.02 $ dpkg-buildpackage -rfakeroot -us -uc ... xpdf/config.h:36:1: warning: xpdfCopyrightAmp redefined In file included from xpdf/GlobalParams.cc:9: /usr/include/poppler/poppler-config.h:72:1: warning: this is the location of the previous definition xpdf/GlobalParams.cc: In member function ‘CMap* GlobalParams::getCMap(GooString*, GooString*, Stream*)’: xpdf/GlobalParams.cc:2542: error: no matching function for call to ‘CMapCache::getCMap(GooString*, GooString*, Stream*)’ /usr/include/poppler/CMap.h:98: note: candidates are: CMap* CMapCache::getCMap(GooString*, GooString*) make[1]: *** [xpdf/GlobalParams.o] Error 1 make[1]: Leaving directory `/home/mathieu/Projects/Workgroup/Mathieu/code/xpdf-3.02' make: *** [build] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 with: $ apt-cache policy libpoppler-dev libpoppler-dev: Installed: 0.8.7-3 Candidate: 0.8.7-3 Version table: 0.12.4-1 0 200 http://ftp.fr.debian.org testing/main Packages 100 http://ftp.fr.debian.org unstable/main Packages *** 0.8.7-3 0 500 http://ftp.fr.debian.org lenny/main Packages 500 http://security.debian.org lenny/updates/main Packages 100 /var/lib/dpkg/status I was trying to check if the 'new' xpdf would handle the following PDF: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562104 Thanks On Thu, Jun 3, 2010 at 4:38 AM, Michael Gilbert michael.s.gilb...@gmail.com wrote: Dear mentors, I am looking for a sponsor for the new version 3.02-3 of my package xpdf. It builds these binary packages: xpdf - Portable Document Format (PDF) suite xpdf-common - Transitional package for xpdf xpdf-reader - Transitional package for xpdf xpdf-utils - Transitional package for poppler-utils The package appears to be lintian clean. The upload would fix these bugs: 351279, 461411, 548182, 548183, 548184, 548185, 576543, 576683, 577031, 577086, 577917, 578892 I have updated the package to use poppler instead of its own rendering code, which is a fairly significant but very useful/important change. I think it would be good to get additional testing/feedback in experimental to make sure this hasn't introduced regressions or other problems. I've done quite a bit of testing over the past week, and it seems to work fine so far, but I think testing from a wider audience is prudent. The logic for such a huge change is to reduce the security maintainence burden for squeeze since there are issues are often disclosed in the xpdf rendering codebase; aka poppler. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/x/xpdf - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/x/xpdf/xpdf_3.02-3.dsc I would be glad if someone uploaded this package for me. Best wishes, Michael Gilbert -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100602223833.e270c169.michael.s.gilb...@gmail.com -- Mathieu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik35zq33m3h4xnrx23aciy5spmzgwaf4cbzv...@mail.gmail.com
Re: RFS: xpdf (updated package)
Le Thu, Jun 03, 2010 at 11:33:21AM +0400, Stanislav Maslovski a écrit : The reason of my question is that there are several pdf viewers in the repository based on poppler. One of them is evince which often crashes on large pdf files. In these cases xpdf was an old-and-slow-but-always-working solution. Dear Michael, I share the same worries: evince still does not manage to pick up japanese fonts for some documents, while currently xpdf does. However, with the 3.02-3 update that you propose, it can not anymore… I can not share the test document because it is a cost estimate, but if it helps I can communicate it to you privately. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100603074424.ga8...@kunpuu.plessy.org
RFS: windowlab (updated package)
Pinging, interval one month, due to lack of response after rebuilding the submitted packaging. Dear mentors, This packaging of windowlab_1.40-1 has a revised formulation of the copyright file, compared to the previous suggestion. In debian/copyright a clarification has been inserted, stating that the external code that the upstream author include in release 1.40 in fact originates with libglut, and thus conforms to the corresponding statement made on that library's author. Thus the present windowlab_1.40 is DFSG conformant. It builds these binary packages: windowlab - small and simple Amiga-like window manager The package appears to be lintian clean and builds well using pbuilder. The upload would fix the bug 575793. The upstream author has resolved an otherwise blocking call in X.org. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/w/windowlab - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/w/windowlab/windowlab_1.40-1.dsc Kind regards Mats Erik Andersson 2459 41E9 C420 3F6D F68B 2E88 F768 4541 F25B 5D41 Subscriber to: debian-mentors, debian-devel-games, debian-perl, debian-ipv6, debian-qa -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100603083918.ga17...@mea.homelinux.org
RFS: squidguard (updated package, many fixes, DMUA)
Dear mentors, I am looking for a sponsor for the new version 1.4-1 of my package squidguard. it supplants the very old version 1.2. And I would be most grateful if a kind sponsor would set the DM-Upload-Allowed (DMUA) bit. It builds these binary packages: squidguard - filter and redirector plugin for Squid squidguard-doc - filter and redirector plugin for Squid - Documentation The package appears to be lintian clean. The upload would fix these bugs: 372709, 385093, 403875, 491673, 514636, 535158, 541602, 548489, 576169 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/squidguard - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/s/squidguard/squidguard_1.4-1.dsc I have created a git repository: - Vcs-Git: git://git.debian.org/git/collab-maint/squidguard.git - Vcs-Browser: http://git.debian.org/?p=collab-maint/squidguard.git Some more infos about squidguard: - Homepage: http://www.squidguard.org I would be glad if someone uploaded this package for me. Kind regards Joachim Wiedorn signature.asc Description: PGP signature
Re: RFS: trimage
Hey all, I uploaded a new version of trimage, with version number 1.0.2-1 and using python-support instead of python-central as suggested. However, I now get a lintian error on native-package-with-dash-version. I'm at loss what to do and my Google-fu is failing me. I build the source package with dpkg-buildpackage -i -S -kB47A6629 on ubuntu jaunty (so just a simple signed source built) Can anyone give me some pointers? The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/trimage - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/trimage/trimage_1.0.2-1.dsc Kind regards, Kilian -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c078eb9.6030...@kilianvalkhof.com
Re: RFS: xpdf (updated package)
On Thu, 03 Jun 2010 09:40:12 +0200, Mathieu Malaterre wrote: $ dget -u http://mentors.debian.net/debian/pool/main/x/xpdf/xpdf_3.02-3.dsc $ cd xpdf-3.02 $ dpkg-buildpackage -rfakeroot -us -uc [..] dpkg-buildpackage: failure: debian/rules build gave error exit status 2 $ apt-cache policy libpoppler-dev libpoppler-dev: Installed: 0.8.7-3 Candidate: 0.8.7-3 Version table: 0.12.4-1 0 200 http://ftp.fr.debian.org testing/main Packages 100 http://ftp.fr.debian.org unstable/main Packages *** 0.8.7-3 0 500 http://ftp.fr.debian.org lenny/main Packages 500 http://security.debian.org lenny/updates/main Packages 100 /var/lib/dpkg/status Builds fine in a cowbuilder sid chroot; so a versioned build dependency on libpoppler-dev seems necessary. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: David Bowie: Diamond Dogs signature.asc Description: Digital signature
Re: RFS: trimage
On Thu, Jun 03, 2010 at 01:15:05PM +0200, Kilian Valkhof wrote: Hey all, I uploaded a new version of trimage, with version number 1.0.2-1 and using python-support instead of python-central as suggested. However, I now get a lintian error on native-package-with-dash-version. I'm at loss what to do and my Google-fu is failing me. Have you checked that your upstream tarball is named correctly ? It should be trimage_1.0.2.orig.tar.gz. If it's not found, dpkg-source will assume there is no upstream and that you are building a Debian native package. Nick -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100603113550.ga5...@leverton.org
Re: RFS: trimage
Nick Leverton wrote: On Thu, Jun 03, 2010 at 01:15:05PM +0200, Kilian Valkhof wrote: Hey all, I uploaded a new version of trimage, with version number 1.0.2-1 and using python-support instead of python-central as suggested. However, I now get a lintian error on native-package-with-dash-version. I'm at loss what to do and my Google-fu is failing me. Have you checked that your upstream tarball is named correctly ? It should be trimage_1.0.2.orig.tar.gz. If it's not found, dpkg-source will assume there is no upstream and that you are building a Debian native package. Thanks, I now have that, lintian gives me an empty-debian-diff error. Because, well, I wrote this app and am packaging it, there is nothing to diff with. What is the argument to not make a native package, by the way? Kind regards, Kilian -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c079581.7030...@kilianvalkhof.com
Re: RFS: projectcenter.app (updated package)
В Wed, 02 Jun 2010 21:40:19 +0300, Yavor Doganov написа: Явор Доганов wrote: I am looking for a sponsor for the new version 0.5.3~20100601-1 of my package projectcenter.app. Please don't upload this, it is buggy. I'll work on fixing it and will followup accordingly. Should be OK now -- I reuploaded the fixed package to mentors.d.n; same version/URL/etc. Sorry for the snafu. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hu8b3i$c8...@dough.gmane.org
Re: RFS: trimage
On Thu, Jun 03, 2010 at 01:44:01PM +0200, Kilian Valkhof wrote: Nick Leverton wrote: Have you checked that your upstream tarball is named correctly ? Thanks, I now have that, lintian gives me an empty-debian-diff error. Because, well, I wrote this app and am packaging it, there is nothing to diff with. What is the argument to not make a native package, by the way? Debian native package format is intended for things which are only of any use for Debian itself, like dpkg and apt. As you've seen, dpkg-source uses indications like absence of an upstream tarball and absence of a dash in the version number to guess what it is supposed to be producing. For packages which might be useful on any distro or even outside of Linux, it's preferred to keep the debian/ directory (containing your packaging) out of the normal tarball, and to incorporate it in the .diff.gz. This helps because, when Policy changes or when some need for change in the packaging comes to light, you don't need to make a whole new upstream release, and the other non-Debian distros don't need to know about the Debian change. I guess you have all your packaging already in the tarball, which is why you have an empty diff.gz file. If you can separate it out, there will be less Debian cruft for other distros, and the Debian packaging will be separated from the package's own functional changes. Nick -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100603135014.ga8...@leverton.org
RFS: xburst-tools
Dear mentors, I am looking for a sponsor for my package xburst-tools. * Package name: xburst-tools Version : 0.0+201006-0.1 Upstream Author : Xiangfu Liu xiangf...@gmail.com * URL : http://projects.qi-hardware.com/index.php/p/xburst-tools/ * License : GPLv3 Section : misc It builds these binary packages: xburst-tools - tools for Ingenic XBurst CPU USB boot and NAND flash access one of the Ingenic Xburst device is [Ben NanoNote] http://www.qi-hardware.com The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/x/xburst-tools - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/x/xburst-tools/xburst-tools_0.0+201006-0.1.dsc I would be glad if someone uploaded this package for me. Please give me some feedback of the source code. Kind regards Xiangfu Liu http://www.openmobilefree.net -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c07d55e.70...@gmail.com
Re: RFS: trimage
Nick Leverton wrote: On Thu, Jun 03, 2010 at 01:44:01PM +0200, Kilian Valkhof wrote: Nick Leverton wrote: Have you checked that your upstream tarball is named correctly ? Thanks, I now have that, lintian gives me an empty-debian-diff error. Because, well, I wrote this app and am packaging it, there is nothing to diff with. What is the argument to not make a native package, by the way? Debian native package format is intended for things which are only of any use for Debian itself, like dpkg and apt. As you've seen, dpkg-source uses indications like absence of an upstream tarball and absence of a dash in the version number to guess what it is supposed to be producing. For packages which might be useful on any distro or even outside of Linux, it's preferred to keep the debian/ directory (containing your packaging) out of the normal tarball, and to incorporate it in the .diff.gz. I have: /trimage_1.0.2.orig.tar.gz (containing the whole source but not debian/) /trimage_1.0.2.diff.tar.gz (containing just debian/) /trimage-1.0.2/ (from which I build, containing both) Yet the empty-debian-diff error persists. What am I doing wrong? Kilian -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c07e917.6090...@kilianvalkhof.com
Re: RFS: xpdf (updated package)
Hi, there.
On Jun 03 2010, Stanislav Maslovski wrote:
This change is for sure quite significant. BTW, do you know if the
internal code in xpdf is equivalent feature wise to poppler? I know
that poppler was a spin-off of the rendering code of xpdf. Do you know
how much they deviate one from another?
I have been keeping in touch with Michael about such smaller version of
xpdf and, in fact, I started a xpdf-poppler project, that I announced at
http://rb.doesntexist.org/blog/2010/05/27/please-let-me-zoom-my-documents/
and that I am hosting at
http://github.com/rbrito/xpdf-poppler/
Unfortunately, Michael didn't inform me that some Gentoo people had been
already working on this, but that's not a problem and I will adopt the
changes that he has in his codebase.
Now addressing some of your concerns, I have already spent the last 3 or
4 days on the code of xpdf and the its rendering is by parts of a
page, in contrast with that of epdfview and evince, which render a whole
page in memory and, in particular, if you choose a large zoom factor,
they barf on that.
The reason of my question is that there are several pdf viewers in the
repository based on poppler. One of them is evince which often crashes
on large pdf files. In these cases xpdf was an
old-and-slow-but-always-working solution.
I have some questions here:
* What do you mean by old? Old looking, perhaps, but thats due to its
use of lesstif, right? Or did you mean anything else?
* What do you mean by slow? In most cases, I think that it is, at
least, of the same speed as others, even if using poppler.
I have not yet benchmarked the differences between pure xpdf and
xpdf+poppler, but I would say that they are very minor.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100603174338.ga2...@ime.usp.br
Re: RFS: xpdf (updated package)
Dear Charles,
On Jun 03 2010, Charles Plessy wrote:
I share the same worries: evince still does not manage to pick up japanese
fonts for some documents, while currently xpdf does. However, with the 3.02-3
update that you propose, it can not anymore…
Just as a quick question, if you use xpdf with the poppler backend, do
you have poppler-data installed? It contains the character mappings
established by adobe for fonts...
Actually, can you use any poppler-based (evince, epdfview, okular etc)
document viewer to view your Japanese documents with poppler-data
installed? If you can, what results do you get?
I can not share the test document because it is a cost estimate, but
if it helps I can communicate it to you privately.
If you could share any problematic document, that would be very nice.
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100603174727.gb2...@ime.usp.br
Re: RFS: trimage
I have: /trimage_1.0.2.orig.tar.gz (containing the whole source but not debian/) /trimage_1.0.2.diff.tar.gz (containing just debian/) /trimage-1.0.2/ (from which I build, containing both) Yet the empty-debian-diff error persists. What am I doing wrong? Oops and of course the should NOT be in that directory, but in the parent directory of /trimage-1.0.2 For instance my winff package looks like: ~/winff ~/winff/winff-1.2.0/ ~/winff/winff_1.2.0-2.debian.tar.gz ~/winff/winff_1.2.0.orig.tar.gz I didn't create the debian tar manually, but let the package builder create it (in my case pbuilder). Paul signature.asc Description: OpenPGP digital signature
Re: RFS: trimage
I have: /trimage_1.0.2.orig.tar.gz (containing the whole source but not debian/) /trimage_1.0.2.diff.tar.gz (containing just debian/) /trimage-1.0.2/ (from which I build, containing both) Yet the empty-debian-diff error persists. What am I doing wrong? Of course it should be /trimage_1.0.2-your-debian-version.diff.tar.gz (containing just debian/) If it was not created correctly, most likely your version in the changelog is incorrect. It should be 1.0.2-your-debian-version. Paul signature.asc Description: OpenPGP digital signature
Re: RFS: xpdf (updated package)
* Rogério Brito rbr...@ime.usp.br, 2010-06-03, 14:43: This change is for sure quite significant. BTW, do you know if the internal code in xpdf is equivalent feature wise to poppler? I know that poppler was a spin-off of the rendering code of xpdf. Do you know how much they deviate one from another? I have been keeping in touch with Michael about such smaller version of xpdf and, in fact, I started a xpdf-poppler project, Count me as one who won't use such a bastardized version of xpdf. Font handling in poppler is brain-dead (see bug #528808) and xpdf serves me currently as a is-this-PDF-broken-or-is-it-only-poppler tester. -- Jakub Wilk signature.asc Description: Digital signature
Re: RFS: xpdf (updated package)
Hi, Jakub.
On Jun 03 2010, Jakub Wilk wrote:
* Rogério Brito rbr...@ime.usp.br, 2010-06-03, 14:43:
I have been keeping in touch with Michael about such smaller
version of xpdf and, in fact, I started a xpdf-poppler project,
Count me as one who won't use such a bastardized version of xpdf.
Thank you very much for your warm reception. :-)
,[ dict bastard ]
| 8 definitions found
| (...)
|
| From The Collaborative International Dictionary of English v.0.48 [gcide]:
|
| Bastard \Bastard\, a.
| 1. Begotten and born out of lawful matrimony; illegitimate.
| See {Bastard}, n., note.
| [1913 Webster]
|
| 2. Lacking in genuineness; spurious; false; adulterate; --
| applied to things which resemble those which are genuine,
| but are really not so.
| [1913 Webster]
|
| That bastard self-love which is so vicious in
| itself, and productive of so many vices. --Barrow.
| [1913 Webster]
| (...)
`
One can argue that both of these meanings *do* apply to xpdf. In fact,
xpdf is, right now, more or less abandoned by its upstream and while
very precious, it would need addressing many of its problems.
People would not have the need of a project in the veins of poppler
otherwise.
Font handling in poppler is brain-dead (see bug #528808) and xpdf
Just as a notice here:
* it works perfectly well here with my setup and xpdf-poppler;
* the document doesn't embed fonts, which is disapproved by (almost)
everyone---I do that myself, since it is allowed, but I do know that
many people may have problems otherwise;
* it may not be apparent, but I am a person that lives by TeX.
Besides that, it seems to work fine with poppler5 here and if you had no
response from the poppler maintainer in Debian, that's perhaps a problem
that should, indeed, be addressed.
serves me currently as a is-this-PDF-broken-or-is-it-only-poppler
tester.
You may be exaggerating here, since xpdf is not very strict in its
adherence to the PDF standard. I don't even know if Adobe's reader
follows the definition of the standard.
I would welcome, though, any patches, suggestions, or even brainstorms
etc to xpdf-poppler.
I know that you are qualifed enough to work with pdf and djvu files
based on your work with packages like pdf2djvu, ocrodjvu and similars
(and I have nothing but thank you once again for your work on that).
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100603190020.gc2...@ime.usp.br
Re: RFS: xpdf (updated package)
On Thu, Jun 03, 2010 at 02:43:38PM -0300, Rogério Brito wrote: Hi, there. On Jun 03 2010, Stanislav Maslovski wrote: This change is for sure quite significant. BTW, do you know if the internal code in xpdf is equivalent feature wise to poppler? I know that poppler was a spin-off of the rendering code of xpdf. Do you know how much they deviate one from another? I have been keeping in touch with Michael about such smaller version of xpdf and, in fact, I started a xpdf-poppler project, that I announced at http://rb.doesntexist.org/blog/2010/05/27/please-let-me-zoom-my-documents/ and that I am hosting at http://github.com/rbrito/xpdf-poppler/ Unfortunately, Michael didn't inform me that some Gentoo people had been already working on this, but that's not a problem and I will adopt the changes that he has in his codebase. Now addressing some of your concerns, I have already spent the last 3 or 4 days on the code of xpdf and the its rendering is by parts of a page, in contrast with that of epdfview and evince, which render a whole page in memory and, in particular, if you choose a large zoom factor, they barf on that. Yes, I also had a similar idea of how does it work. The reason of my question is that there are several pdf viewers in the repository based on poppler. One of them is evince which often crashes on large pdf files. In these cases xpdf was an old-and-slow-but-always-working solution. I have some questions here: * What do you mean by old? Old looking, perhaps, but thats due to its use of lesstif, right? Or did you mean anything else? Well, I mean that it has been around for quite a while. I think I have been using it since at least 10 years ago. * What do you mean by slow? In most cases, I think that it is, at least, of the same speed as others, even if using poppler. Currently scrolling in xpdf is visually slower than in evince (yes, I know about that compiler-related bug #577031: I am using a version which is not affected). I have not yet benchmarked the differences between pure xpdf and xpdf+poppler, but I would say that they are very minor. Then the diffrence in scrolling between evince and xpdf is probably only because xpdf renders by parts. -- Stanislav -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100603201939.ga11...@kaiba.homelan
Overriding upstream build system
Hi all, I'm trying to release the new gsoap libraries as dynamic libraries, as I know I need to release a -dev package with the static libraries and I'm not able to patch the autotools files used by gsoap but I know how to get the desired result using cmake may I provide a CMakelist.txt as a patch and use cmake to build my package? TIA Stefano -- Stefano Canepa aka sc: s...@linux.it - http://www.stefanocanepa.it Three great virtues of a programmer: laziness, impatience and hubris. Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall) signature.asc Description: Digital signature
Re: Overriding upstream build system
Am 03.06.2010 23:18, schrieb Stefano Canepa: Hi all, I'm trying to release the new gsoap libraries as dynamic libraries, as I know I need to release a -dev package with the static libraries and I'm not able to patch the autotools files used by gsoap but I know how to get the desired result using cmake may I provide a CMakelist.txt as a patch and use cmake to build my package? Why not if you lower the world wide pain with your patch? But it may be better to push upstream to accept your patch and switch to cmake or he should fix his autofoo. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c081dfc.4010...@debian.org
RFS: presage
Dear mentors, I am looking for a sponsor/reviewer for my package presage. * Package name: presage Version : 0.8.2-1 Upstream Author : Matteo Vescovi matteo.vesc...@yahoo.co.uk * URL : http://presage.sourceforge.net/ * License : GPL2 Section : devel It builds these binary packages: libpresage-data - intelligent predictive text entry platform (data files) libpresage-dev - intelligent predictive text entry platform (development files) libpresage1 - intelligent predictive text entry platform (shared library) presage- intelligent predictive text entry platform (tools and demos) presage-doc - intelligent predictive text entry platform (documentation) presage-gprompter - intelligent predictive GTK+ text editor presage-pyprompter - intelligent predictive wxPython text editor python-presage - intelligent predictive text entry platform (Python binding) The package appears to be lintian clean. The upload would fix these bugs: 468820 My motivation for maintaining this package is: I am the upstream maintainer. I would like to have this package in Debian in order help other packages that are planning to use predictive text functionality (such as on-screen keyboards and accessibility tools). This is my first attempt at packaging for Debian. I know that starting with packaging a library or a multiple binary package is generally frowned upon... but I decided to do the work anyway because I genuinely care about making this package available in Debian. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/presage - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/presage/presage_0.8.2-1.dsc I would be glad if someone reviewed/uploaded this package for me. Thank you for your time, - Matteo Vescovi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100603215148.gb19...@burrow
RFS: tina (adopted, updated a lot, turned non-native)
Dear mentors, I am looking for a sponsor for the new version 0.1.11-1 of the package tina. This is an adoption attempt (ITA #466331), which updates the Debian packaging a lot and converts the package to a non-native one with pretty much no changes to the actual sources, just extracted into a separate tarball and hosted on my website. Of course, I realize it would be quite the cheeky thing to mention DM-Upload-Allowed on the very first adoption upload, but if the sponsor who decides to take a look is already familiar with my work on other packages, well, what can I say but something about being very grateful ;) There is a single binary package: tina - Text-based personal information manager It has been tested with lintian and pbuilder. The upload would fix these bugs: 466331 (ITA) The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/t/tina/tina_0.1.11-1.dsc I would be glad if someone uploaded this package for me. JFYI, here's my adoption changelog entry: tina (0.1.11-1) unstable; urgency=low * New maintainer. Closes: #466331 * Convert tina to a non-native package. * Use debhelper 7: - create debian/compat - add a dependency on debhelper = 7 - minimize the rules file by using the dh(1) utility - add misc:Depends to the binary package * Remove the obsolete prerm script - tina has not been creating the /usr/doc/tina link for some time now. * Convert to the 3.0 (quilt) source format with no changes. * Add a watch file. * Bump Standards-Version to 3.8.4: - add the Homepage field * Improve the package synopsis a bit and reflow the long description. * Convert the copyright file to rev. 135 of the proposed DEP 5 format and add my copyright notice on the Debian packaging files. * Add the Vcs-Svn and Vcs-Browser source control fields. * Use dpkg-buildflags from dpkg-dev = 1.15.7~ to obtain CFLAGS, CPPFLAGS, and LDFLAGS; no longer rely on dpkg-buildpackage to set them by default. * Pass -Werror to the compiler if the non-standard werror build option is set. * Add the 01-warnings patch to fix some compiler warnings. * Use a debhelper override to pass -Wstrict-prototypes at build time, since the configure script chokes on it. * Use build hardening by default unless the non-standard nohardening build option is set. -- Peter Pentchev r...@ringlet.net Fri, 04 Jun 2010 02:58:13 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 signature.asc Description: Digital signature
RFS: keynav (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for the new version 0.20100601.2912-1 of my package keynav. (Programming language: C) The package is lintian clean. It builds the binary package: keynav keynav (0.20100601.2912-1) unstable; urgency=low . * New upstream release * Bump Build-Depends: libxdo-dev (= 2.20100524.2888) for libxdo.so.2 * Update debian/watch * Remove debian/clean, fixed upstream Description: a keyboard-driven mouse cursor mover Keynav makes your keyboard a fast mouse cursor mover. You can move the cursor to any point on the screen with a few key strokes. It also simulates mouse click. You can do everything mouse can do with a keyboard. The package can be found on mentors.debian.net: - - dget http://mentors.debian.net/debian/pool/main/k/keynav/keynav_0.20100601.2912-1.dsc I would be glad if someone uploaded this package for me. :-) Kind regards Wen-Yen Chuang - -- My GPG key is signed by Debian Developer Masayuki Hatta. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwIXp4ACgkQdEpXpumNYVlfgACdFSlchybnsNaJ6pFhsUSA6piI oV0AnipK3XhLeIhgOgGjzjaJMzJCj4hs =dR1k -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c085e9e.4030...@calno.com
Re: RFS: xburst-tools
On Fri, Jun 4, 2010 at 12:16 AM, Xiangfu Liu xiangf...@gmail.com wrote: I am looking for a sponsor for my package xburst-tools. Here is a review: Please get the 2 patches upstream. Please add DEP-3 headers top the patches and remove the default headers. One of the patches adds a patch to the top level directory, please make it patch the code instead SInce you are upstream, please move as much as of the build system upstream and out of the debian/ directory, which is meant to be a wrapper around the upstream build system. -- bye, pabs http://wiki.debian.org/PaulWise http://bonedaddy.net/pabs3/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin5ksp8vqrpupayxdrnj0mcvfwcvl-jlq8mm...@mail.gmail.com
Re: RFS: xburst-tools
On Fri, Jun 4, 2010 at 10:49 AM, Paul Wise p...@debian.org wrote: On Fri, Jun 4, 2010 at 12:16 AM, Xiangfu Liu xiangf...@gmail.com wrote: I am looking for a sponsor for my package xburst-tools. Here is a review: Bah, hit send too early, sorry for the double mail. Please remove these prebuilt files from the debian/ directory and don't add them to the upstream tarball. ./debian/xburst_stage1.bin ./debian/xburst_stage2.bin ./debian/stage1.bin You include an embedded code copy (or fork) of the Qi bootloader. Please remove it and package Qi separately. I wonder if usbboot/ is also an embedded code copy. Please use 'make distcheck' to produce a tarball for release and for the Debian orig.tar.gz The README.source indicates that this requires a cross-compiler for MIPS in the $PATH. Since we don't have one in Debian yet, your package cannot be uploaded as-is. You could however, build and upload from a MIPS machine with gcc installed. I stopped here, there are way too many huge issues to consider reviewing it fully. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinuuf8gnapmbn3joq9vwiq1mcmxpqbvjmo7k...@mail.gmail.com
Re: RFS: xburst-tools
On Fri, Jun 4, 2010 at 10:58 AM, Paul Wise p...@debian.org wrote: On Fri, Jun 4, 2010 at 10:49 AM, Paul Wise p...@debian.org wrote: On Fri, Jun 4, 2010 at 12:16 AM, Xiangfu Liu xiangf...@gmail.com wrote: I am looking for a sponsor for my package xburst-tools. Here is a review: I stopped here, there are way too many huge issues to consider reviewing it fully. PS: I think it is really really awesome that Qi Hardware / Sharism are trying to get their hardware supported by plain Debian, please do not get discouraged by my review. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinlt06tzqsttsngik2deqmgxiyrpijwviweo...@mail.gmail.com
Re: RFS: xpdf (updated package)
On Thu, 3 Jun 2010 16:44:24 +0900 Charles Plessy wrote: Le Thu, Jun 03, 2010 at 11:33:21AM +0400, Stanislav Maslovski a écrit : The reason of my question is that there are several pdf viewers in the repository based on poppler. One of them is evince which often crashes on large pdf files. In these cases xpdf was an old-and-slow-but-always-working solution. Dear Michael, I share the same worries: evince still does not manage to pick up japanese fonts for some documents, while currently xpdf does. However, with the 3.02-3 update that you propose, it can not anymore… Hi, Note that the poppler-data package has a newer version of Adobe's Japanese cMap, which probably introduced this problem. Some things you may want to take a look at: 1. According to their NEWS file, some cMap resources were dropped in version 0.4; which may include stuff needed by your pdfs. You may want to try restoring those. 2. As another option, you may want to try replacing the cMap data in /usr/share/poppler/cMap/Adobe-Japan1 with that provided by the xpdf-japanese package. 3. Also, there is a (mostly empty) Adobe-Japan2 cMap there, which may be getting used by default, and that would probably be wrong. Anyway, this seems more like a bug in poppler-data and should be reported there. In terms of xpdf performance, can those concerned please try files that they consider big with the poppler-ized version and compare that to the original xpdf so we can actually quantify the impact (if there even is one). Speculating doesn't really get us anywhere. We need a quantified impact. Again, I want to upload this package to experemental first for testing purposes; and large file handling would be a very good set of tests. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100604002907.ae35aae6.michael.s.gilb...@gmail.com
Re: RFS: xpdf (updated package)
On Thu, 3 Jun 2010 13:28:27 +0200 gregor herrmann wrote: On Thu, 03 Jun 2010 09:40:12 +0200, Mathieu Malaterre wrote: $ dget -u http://mentors.debian.net/debian/pool/main/x/xpdf/xpdf_3.02-3.dsc $ cd xpdf-3.02 $ dpkg-buildpackage -rfakeroot -us -uc [..] dpkg-buildpackage: failure: debian/rules build gave error exit status 2 $ apt-cache policy libpoppler-dev libpoppler-dev: Installed: 0.8.7-3 Candidate: 0.8.7-3 Version table: 0.12.4-1 0 200 http://ftp.fr.debian.org testing/main Packages 100 http://ftp.fr.debian.org unstable/main Packages *** 0.8.7-3 0 500 http://ftp.fr.debian.org lenny/main Packages 500 http://security.debian.org lenny/updates/main Packages 100 /var/lib/dpkg/status Builds fine in a cowbuilder sid chroot; so a versioned build dependency on libpoppler-dev seems necessary. Thanks for spotting this! I've just uploaded xpdf with a versioned depenedency on libpoppler-dev: http://mentors.debian.net/debian/pool/main/x/xpdf Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100604003645.03d15eb9.michael.s.gilb...@gmail.com
Re: RFS: xpdf (updated package)
On Fri, 4 Jun 2010 00:29:07 -0400 Michael Gilbert wrote: On Thu, 3 Jun 2010 16:44:24 +0900 Charles Plessy wrote: Le Thu, Jun 03, 2010 at 11:33:21AM +0400, Stanislav Maslovski a écrit : The reason of my question is that there are several pdf viewers in the repository based on poppler. One of them is evince which often crashes on large pdf files. In these cases xpdf was an old-and-slow-but-always-working solution. Dear Michael, I share the same worries: evince still does not manage to pick up japanese fonts for some documents, while currently xpdf does. However, with the 3.02-3 update that you propose, it can not anymore… Hi, Note that the poppler-data package has a newer version of Adobe's Japanese cMap, which probably introduced this problem. Some things you may want to take a look at: 1. According to their NEWS file, some cMap resources were dropped in version 0.4; which may include stuff needed by your pdfs. You may want to try restoring those. 2. As another option, you may want to try replacing the cMap data in /usr/share/poppler/cMap/Adobe-Japan1 with that provided by the xpdf-japanese package. 3. Also, there is a (mostly empty) Adobe-Japan2 cMap there, which may be getting used by default, and that would probably be wrong. Anyway, this seems more like a bug in poppler-data and should be reported there. Actually, it looks like this is already reported: http://bugs.debian.org/495800 Perhaps some help is needed since the last activity there was almost two years ago. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100604010041.300f3caa.michael.s.gilb...@gmail.com
Re: RFS: xpdf (updated package)
Le Thu, Jun 03, 2010 at 02:47:27PM -0300, Rogério Brito a écrit : Just as a quick question, if you use xpdf with the poppler backend, do you have poppler-data installed? It contains the character mappings established by adobe for fonts... Thanks, Rogério for the helpful answer. I was very surprised that installation of poppler-data solved my problem for evince but not for xpdf, but after reading Michael's answers, it looks that there is an explanation. I recommand to solve this before uploading xpdf to main. By the way, I really think that poppler-data shoud be installed by default on computers configured for office work. We can not expect users to figure out that they need this package to see CJK characters. I reported #584503 against poppler to propose to have libpoppler recommend poppler-data. Have a nice week-end, -- Charles -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100604053736.gb9...@kunpuu.plessy.org
