RFS: renaissance (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.9.0-4 of my package renaissance. It builds these binary packages: librenaissance0 - GNUstep GUI Framework - library files librenaissance0-dev - GNUstep GUI Framework - development files renaissance-doc - GNUstep GUI Framework - documentation The package appears to be lintian clean. The upload would fix these bugs: 583103 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/renaissance - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/r/renaissance/renaissance_0.9.0-4.dsc I would be glad if someone uploaded this package for me. -- 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/8739x1or1d.gnus_not_unix!%ya...@gnu.org
Re: RFS: xburst-tools
On Sat, Jun 05, 2010 at 12:38:15PM +0800, Paul Wise wrote: On Sat, Jun 5, 2010 at 12:13 PM, Jonathan Nieder jrnie...@gmail.com wrote: This part was my doing, sorry. It should be possible to build these on mipsel [...], but that makes it difficult for people without access to a non-pocket-sized MIPS machine to test the build process. From http://db.debian.org/machines.cgi?sortby=architecturesortorder=asc I infer that there is not even a mipsel porterbox available to DDs. A temporary solution to this would be to find a sponsor with a Debian mips/mipsel install on MIPS hardware. Is there any reason qemu-mipsel isn't good enough? You can find a detailed howto at: http://www.aurel32.net/info/debian_mips_qemu.php but if you want just an usable system ASAP, go straight to: http://people.debian.org/~aurel32/qemu/mipsel/ and two wgets and apt-get install qemu later, you're one command away from fully working lenny. It's not a speed demon so dist-upgrade further will take a while, but then, the real thing isn't fast either... Meow! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
RFS: pidgin-microblog (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.3.0-1 of my package pidgin-microblog. It builds these binary packages: pidgin-microblog - Microblogging plugins for Pidgin The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pidgin-microblog - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pidgin-microblog/pidgin-microblog_0.3.0-1.dsc I would be glad if someone uploaded this package for me. Kind regards Karolina Kalic -- Karolina WWW: http://www.karolina.in.rs -- 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/aanlktimaqctkpssgeve8i85xkkglqgbrv6dmq0yj0...@mail.gmail.com
Re: RFS: xburst-tools
On Sat, Jun 5, 2010 at 7:21 PM, Adam Borowski kilob...@angband.pl wrote: Is there any reason qemu-mipsel isn't good enough? There was a concern (flamewar) a few years ago that doing that would result in broken binaries. I don't know how true that would be today or if it is now consider acceptible. -- 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/aanlktilz-yqwgfphlw6zgp0gfbbf6ltg4ktchpizh...@mail.gmail.com
Re: RFS: xburst-tools
On Sat, Jun 05, 2010 at 07:59:58PM +0800, Paul Wise wrote: On Sat, Jun 5, 2010 at 7:21 PM, Adam Borowski kilob...@angband.pl wrote: Is there any reason qemu-mipsel isn't good enough? There was a concern (flamewar) a few years ago that doing that would result in broken binaries. I don't know how true that would be today or if it is now consider acceptible. qemu-user-*, I can understand that. But qemu-system-*, which emulates the whole machine? Unless there is some insidious bug in qemu which shows up only for some rare opcode or for some corner case of hardware access, I can't see how it is supposed to produce broken binaries. Unless you get close to the metal, things either work or not. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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/20100605122112.ga7...@angband.pl
Re: RFS: xpdf (updated package)
On Sat, 5 Jun 2010 02:20:22 +0400 Stanislav Maslovski wrote: On Fri, Jun 04, 2010 at 04:05:21PM -0400, Michael Gilbert wrote: I can't say anything definitive, but I can speculate that it will not be a problem, and here is the logic: xpdf's rendering code is itself essentially an older version of poppler. I doubt the poppler developers have intentionally made that code itself any slower, and it was possible to interface xpdf to poppler without a significant rewrite (a couple minor few-line patches and a bunch of variable renaming that doesn't have any impact). Hence any performance differences to be found between evince and xpdf will reside in the non-poppler code. Restated; even with switch to poppler, the original xpdf zoom/display logic remains, and that will be the primary driving factor for performance. But even so, it should be tested. BTW, where did you get it from that my main concerns are about speed? You seem to be focused only on this. Actually, my point was quite the contrary, please re-read my mails. We already have a poppler-based viewer which is reasonably fast - it is evince, but unfortunately it does not work enough well with every possible pdf file (often crashes). Technically evince is xpdf-based; poppler is just the name of the xpdf code that was turned into a shared library. The same conclusions for crashiness can be reached via the same speculative logic that I made for performance. On the other hand, xpdf opens all files without any problems, but can be a bit slower in scrolling sometimes. The last is not a problem. I am simply afraid that with your change xpdf will follow evince's path and there will be no reliable pdf viewer in the repository anymore. If you can pinpoint some example files that crash evince but work fine in xpdf, I will test them. So far, I have not encountered any issues myself. Gentoo has been shipping xpdf-poppler for a few years now, and I haven't seen any complaints of your nature there (although I have not done an exhaustive search). 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/20100605122415.76100151.michael.s.gilb...@gmail.com
RFS: autojump
Dear mentors, I am looking for a sponsor for my package autojump. * Package name: autojump Version : 8-1 Upstream Author : Joel Schaerer joel.schae...@laposte.net * URL : http://wiki.github.com/joelthelion/autojump/ * License : GPL3 Section : shells It builds these binary packages: autojump - shell extension to jump to frequently used directories jumpapplet - autojump notification icon, to jump to frequently used directories The package triggers one lintian warning about a duplicated “to” word in the description “allows you to jump to frequently used directories”, which I overrode. The upload would fix the corresponding ITP bugs #580891. My motivation for maintaining this package is: I discoverd this little utility and found it useful and worth to be integrated to Debian. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/autojump - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/a/autojump/autojump_8-1.dsc I would be glad if someone uploaded this package for me. Kind regards, -- Tanguy Ortolo signature.asc Description: Digital signature
Re: RFS: xpdf (updated package)
Le samedi 05 juin 2010, Michael Gilbert a écrit : If you can pinpoint some example files that crash evince but work fine in xpdf, I will test them. So far, I have not encountered any issues myself. Gentoo has been shipping xpdf-poppler for a few years now, and I haven't seen any complaints of your nature there (although I have not done an exhaustive search). I never saw any file that made Evince crash, but I saw some files that Xpdf renders perfectly and where Evince does not display at all some fonts. For instance the LaTeX fontspec package's documentation, that you can find at http://tanguy.ortolo.eu/tmp/fontspec.pdf. I have often used Xpdf as a fallback when Evince was unable to correctly display a file. Making them use the same renderer would just leave me completely unable to read those files, so if it happens, I would try very hard to keep an old version of Xpdf as long as I can. :-/ -- Tanguy Ortolo signature.asc Description: Digital signature
Re: RFS: xpdf (updated package)
On Sat, Jun 05, 2010 at 12:24:15PM -0400, Michael Gilbert wrote: On Sat, 5 Jun 2010 02:20:22 +0400 Stanislav Maslovski wrote: On the other hand, xpdf opens all files without any problems, but can be a bit slower in scrolling sometimes. The last is not a problem. I am simply afraid that with your change xpdf will follow evince's path and there will be no reliable pdf viewer in the repository anymore. If you can pinpoint some example files that crash evince but work fine in xpdf, I will test them. So far, I have not encountered any issues myself. Gentoo has been shipping xpdf-poppler for a few years now, and I haven't seen any complaints of your nature there (although I have not done an exhaustive search). See, for example evince bug #584711: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584711 -- 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/20100605204531.ga31...@kaiba.homelan
Re: RFS: xpdf (updated package)
Hi again, Charles.
On Jun 04 2010, Charles Plessy wrote:
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.
You're welcome, as always. (And it is nice to receive some of your
e-mails once in a while).
I was very surprised that installation of poppler-data solved my
problem for evince but not for xpdf,
Great that this worked. I suspected that it would be the case.
but after reading Michael's answers, it looks that there is an
explanation. I recommand to solve this before uploading xpdf to main.
I am trying to work with Michael, but it seems that my mails to him are
not getting through. :-) (Michael, let us join forces in this, pal).
A very simplified version of the facts is this: CJK fonts need way more
than the 256 different characters. Therefore, for backwards
compatibility, we have to jump through many hoops to map to make things
work. Part of that job is to map CID fonts to Unicode characters, use
CMaps etc.
To cut a long story short, you can install the xpdf-japanese package,
or, since you already have poppler-data installed, you can simply add
these lines to your .xpdf and see if things work:
,[ .xpdfrc ]
| cidToUnicode Adobe-Japan1/usr/share/poppler/cidToUnicode/Adobe-Japan1
| toUnicodeDir /usr/share/poppler/cMap/Adobe-Japan1/
| toUnicodeDir /usr/share/poppler/cMap/Adobe-Japan2/
| cMapDir Adobe-Japan1/usr/share/poppler/cMap/Adobe-Japan1/
| cMapDir Adobe-Japan2/usr/share/poppler/cMap/Adobe-Japan2/
`
Please let me know if things work with that, as I am integrating support
to rich documents on the xpdf tree that I am starting to maintain. Some
extra lines may be needed, depending on how you have things installed.
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.
Sure, I have been bitten by this problem many times in the past and I
did not know that there were some nasty patents in this.
I reported #584503 against poppler to propose to have libpoppler
recommend poppler-data.
Yes, even though poppler-data was non-free, it is now in main and I
don't know why it hasn't been added to recommends already.
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/20100606032926.ga32...@ime.usp.br
Re: RFS: xpdf (updated package)
Hi, Jakub.
On Jun 04 2010, Jakub Wilk wrote:
* Rogério Brito rbr...@ime.usp.br, 2010-06-03, 16:00:
Thank you very much for your warm reception. :-)
Don't get me wrong: I believe that all PDF readers in Debian suck
and I appreciate that you want to change that state.
Ah, now your opinion is clearer.
However, I'd like you to bear in mind that some people are using xpdf
because of features that you are going to inadvertently kill
e.g. decent font handling or modest dependencies.
Just for the record, I am studying the way that the font handling may be
performed and don't substitute the Base14 fonts with anything else than
PostScript fonts.
Regarding the dependencies, I think that things tend to be smaller
rather than larger.
Regards,
--
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/20100606044922.gb32...@ime.usp.br
Re: RFS: xpdf (updated package)
On Jun 05 2010, Tanguy Ortolo wrote:
I never saw any file that made Evince crash, but I saw some files that
Xpdf renders perfectly and where Evince does not display at all some
fonts. For instance the LaTeX fontspec package's documentation, that
you can find at http://tanguy.ortolo.eu/tmp/fontspec.pdf.
I use fontspec every single day. For poppler-based viewers, install
poppler-data (see my other message to Charles Plessy).
I have often used Xpdf as a fallback when Evince was unable to correctly
display a file. Making them use the same renderer would just leave me
completely unable to read those files, so if it happens, I would try
very hard to keep an old version of Xpdf as long as I can. :-/
Well, I am in a similar situation: I use evince (actually, evince-gtk)
as a fallback for xpdf, but I am willing to have everything use fewer
dependencies, as long as the functionality is kept.
Heck, I even compile my own packages optimized for size (-Os) rather
than for speed (say, -O2 or -O3) with GCC. :-)
The only reason why I keep evince here is that I want to be able to read
djvu files also and I don't want to pull the entire qt4 libraries just
for a single program.
Regards,
--
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/20100606051014.ga2...@ime.usp.br
Re: RFS: xpdf (updated package)
On Do, 03 Jun 2010, 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
One more comment on that from the Debian TeX Team: As TeX is using
the xpdf code in several places, we (first Ubuntu patch, updated
regularly now by us and them together) patched the sources to
allow compilation with poppler and xpdf, and this was pushed also
upstream.
BUT: It is a BIG BIG BIG PITA Poppler people are simply completely
ignorant wrt to breaking API. If you look into the amount of
different patches we had to create for poppler 0.4, 0.6, 0.8, 0.10, 0.12
and so on, I am sure this will continue.
SO actually I considered to switch back to the embedded xpdf code
for Debian texlive packages, just to get rid of that stupid problems:
new poppler hits unstable, changes API at random, so texlive FTBFS
In fact I never got any answer on my (more polite than here) requests
from them.
I am not sure if basing anything new on poppler is actually a good idea.
Martin Schröder once at a BachoTeX conference gave a good overview
on different pdf libraries, and I hope with time a decent one will show
up and be used in as many places as possible. Poppler people unfortunately
do everything to make this fail.
Best wishes
Norbert
Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
ULLINGSWICK (n.)
An over-developed epiglottis found in middle-aged coloraturas.
--- Douglas Adams, The Meaning of Liff
--
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/20100606052122.ga7...@gamma.logic.tuwien.ac.at
