PDF files and dh_compress
I'm sorry if this question was discussed before but I couldn't google it up and think that it is too early to raise on -dev. I've got finally annoyed enough by compressed pdf.gz in -doc packages that I decided to check if that is required (deb pol, or dev ref?) and/org common practice. Let me first reveal some numbers characterizing current situation: Total number of pdf files present in sid: > apt-file search .pdf | grep '\.pdf\(\.gz\)*$' >| pdf.files > wc -l pdf.files 2485 pdf.files How many pdfs lie outside of doc (just out of curiosity): > grep -v 'usr/share/doc' pdf.files | wc -l 476 And whatever is within share/doc, gzipped: > grep 'usr/share/doc/.*\.pdf\.gz$' pdf.files | wc -l 1095 raw pdf: > grep 'usr/share/doc/.*\.pdf$' pdf.files | wc -l 914 So approx 50/50, so half people do adjust debian/make to exclude .pdfs. I'm lazy to spot some dependency here -- may be cdbs takes care about keeping them not compressed automatically? And if we look only at -doc packages which are intended to provide a documentation (ie ready to be readable information, not another gzipped single file ball needed to be decompressed before viewing) > grep 'usr/share/doc/[^/]*-doc/.*\.pdf\.gz$' pdf.files | wc -l 253 > grep 'usr/share/doc/[^/]*-doc/.*\.pdf$' pdf.files | wc -l 573 the situation is slightly better: > 2/3 are keeping PDFs uncompressed in -doc packages. This simple algebra shows though that there is no agreement/clear policy (or at least it is not followed) on how PDFs should be handled. Of cause pdfs are not as highly compressed as with gzip -9 but they are zipped internally and usually are less than 10% larger than their .pdf.gz versions. And at least I would expect all -doc packages to have uncompressed .pdfs since neither of the pdf viewers to me experience handle transparent decompression of pdf.gz Few questions now: So is there a recommendation anywhere in dev ref or deb policy regarding the PDF files? Shouldn't it be recommended (withing dev ref or deb policy) to keep PDFs not compressed with gzip on top (at least in -doc packages)? Obviousely dh_compress doesn't bother checking if there is a good reason to compress the file (like some threshold gain, after which file has to be compressed). I doubt that it is worth implementing, but I think it should at least take care about not compressing pdf's in -doc packages. What do you think? As always, depending on the answers to previous questions, may be it is worth to provide linda/lintian warnings about twice compressed files or at least compressed pdfs in -doc packages. Thank you in advance -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpe4RsO0wuAt.pgp Description: PGP signature
Re: gnash: /usr/lib/libXcursor.la does not exist
Hi, It seems to be enough just with rebuilding gtkglext debian package. A binNMU has been scheduled so it will probably be solved soon. Thanks :) Miry --- Brendon Higgins <[EMAIL PROTECTED]> escribió: > Hi > > Loïc Minier wrote (Sunday 07 May 2006 6:48 am): > > On Sat, May 06, 2006, Miriam Ruiz wrote: > > > /bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory > > > libtool: link: `/usr/lib/libXcursor.la' is not a valid libtool archive > > > > grep -l Xcursor.la /usr/lib/*.la > > will list the libtool archives which still reference this file, the > > packages shipping these files should be updated not to reference > > Xcursor.la (rebuilt). > > There is a hack floating around that basically involves taking a meat > cleaver > to all the files that reference Xcursor.la and others that have gone along > with it which no longer exist. > > I'm trying to find the line I saw a while ago, but Google is failing me. The > > idea is you grep for all the la files that reference libXcursor.la, and just > > remove that reference from them. It's a pretty nasty hack, but it can be > done, and it seems to work. Best you don't take my word for it until you > find > a confirmation of this idea, though. > > Relevent discussion here (plus many others in debian-x): > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354674 > > Peace, > Brendon > __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnash: /usr/lib/libXcursor.la does not exist
Hi Loïc Minier wrote (Sunday 07 May 2006 6:48 am): > On Sat, May 06, 2006, Miriam Ruiz wrote: > > /bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory > > libtool: link: `/usr/lib/libXcursor.la' is not a valid libtool archive > > grep -l Xcursor.la /usr/lib/*.la > will list the libtool archives which still reference this file, the > packages shipping these files should be updated not to reference > Xcursor.la (rebuilt). There is a hack floating around that basically involves taking a meat cleaver to all the files that reference Xcursor.la and others that have gone along with it which no longer exist. I'm trying to find the line I saw a while ago, but Google is failing me. The idea is you grep for all the la files that reference libXcursor.la, and just remove that reference from them. It's a pretty nasty hack, but it can be done, and it seems to work. Best you don't take my word for it until you find a confirmation of this idea, though. Relevent discussion here (plus many others in debian-x): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354674 Peace, Brendon pgpAIzn1p3hBF.pgp Description: PGP signature
Seeking for sponsor for a download manager called "wxDownload Fast"
Hi, I'm developing a download manager for a fill years, and I like to see this program in the debian tree. So, If some DD is interested in sponsor this program, please let me now. Program name === wxDownload Fast Project page: === http://dfast.sf.net Description: === A multithread download manager created using the library wxWidgets. Characteristics: === * Allows to carry through download of some archives simultaneously, and allow to split the downloads in some lowered parts. * Allows to schedule a download * Allows to organize the archive already downloaded * Allows to continue one download interrupted of the point where had stopped * The messages sent/received for the program when connecting to servers HTTP/FTP or for local downloads(file://) * It can be translated with easiness for any language. Being available initially in Portuguese[Brazil], Spanish and English * Allows to connect in FTP servers(only FTP) which need password * Generate the MD5 of the downloaded archives, facilitating the verification In the project page there is a debian package (for the unstable tree) to download. Thanks!! Max Velasques -- - Do you want portability? Try wxWidgets (www.wxwidgets.org)
Re: C Tutorial ?
Michelle Konzack <[EMAIL PROTECTED]> writes: > Since I am using Debian GNU/Linux since 1999 (Slink, 2.1) > successfuly, my four daughters (17, 14, 12 and 7years) too... > > Now Laila (14) want to start coding in C and GTK and she need > really good tutorials (with real examples). OK, we have found > allready "libgtk2.0-doc" which is perfectl written. Note that programming GTK+ in C is not "C programming", it's "GObject programming". This requires that you know not only about how objects are implemented on a fundamental level by the C++ compiler (virtual method despatch with vtables, typeinfo, inheritance, polymorphism, RTTI etc.), but how to re-implement these concepts in C. And, in addition, several features from smalltalk such as properties. If your daughter wants to learn C, that's great, but GTK+ isn't really what you do first with C; it's what you do once you've mastered C *and* C++, and then decided to use C instead. I.e. it's not something you would want to intimidate a beginner with (or many experienced programmers!), and is not generally a good choice. If it was me, I'd stay with PyGTK! For learning "plain" ISO C, I would suggest one of the many C books that cover all the C89 language basics. If it covers C99, that's even better. If she still wants to learn to use GTK+, she might find this useful: http://people.debian.org/~rleigh/gtk/ogcalc/ (PDF and source code examples) Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpKmoRQXeEei.pgp Description: PGP signature
Re: How can I simply test building a package with a different compiler version?
Hi! > Using this should work: > MAKEFLAGS="CXX=g++-4.1" svn-buildpackage > > make will behave as if it has been called using `make CXX=g++-4.1' That's it, it works! Thanks to all for the help! Regards, Fabian pgp3CORM3uj7r.pgp Description: PGP signature
Re: gnash: /usr/lib/libXcursor.la does not exist
Hi, On Sat, May 06, 2006, Miriam Ruiz wrote: > /bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory > libtool: link: `/usr/lib/libXcursor.la' is not a valid libtool archive grep -l Xcursor.la /usr/lib/*.la will list the libtool archives which still reference this file, the packages shipping these files should be updated not to reference Xcursor.la (rebuilt). Bye, -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gnash: /usr/lib/libXcursor.la does not exist
Hi, I'm getting some errors building gnash when reaching the linking step: ranlib .libs/libgnashbackend.a creating libgnashbackend.la /bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory libtool: link: `/usr/lib/libXcursor.la' is not a valid libtool archive Talking to upstream, they told me they're not linking directly with X in any step, so the problem must be somewhere in Debian. The package is available temporarily at http://baby.yi.org/packages/gnash/ and the full building log is: http://baby.yi.org/packages/gnash/gnash_0.0.20060506-1_i386.build It seems ( http://bugs.debian.org/347352 ) that it's not just me who is getting this error. Do you know if it's something in my package, in the building system or I shall just wait for whatever bug in Debian (due to the latest xorg transition) to be fixed? Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Yorick (scientific interpreted language) & plug-ins
On Fri, 5 May 2006, Thibaut Paumard wrote: Actually, if I stay with the one-package-per-plugin approach, I was thinking of providing a virtual package that would pull out yorick and all the plugins (except perhaps the most specialised). Would that make sense? In that case, I also need to think of a reasonable versionning. (the above looks OK). I think what you want is a meta package that pulls in all the components, The virtual package is a bit different.[0] You could have a meta package called yorick-standard-plugins or something like that which depends on yorick and the plugins you think are fundamental. [0] http://www.debian.org/doc/debian-policy/ch-relationships.html Cheers, Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED]http://www.iit.edu/~segre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lopster
Franz Pletz <[EMAIL PROTECTED]> wrote: > W: lopster; A binary links against a library it does not use symbols from > This package contains a binary that links against a library that is > not in the Depends line. This may also be a bug in the library which > does not have a shlibs file. > > I've doublechecked the output of both ldd and objdump -p for > /usr/bin/lopster but was not able to identify a library in a package > which isn't in Depends. The program works without any problems, though. > Any advice? See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360391 This may be a false positive by linda. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: lopster
I'm searching for a sponsor for the lopster package. I've done a lot of cleanups in a few places because the package wasn't actively maintained for a long period of time. Also, a new upstream release has been packaged. The diff is available from: http://franz-pletz.org/debian/lopster The package is lintian and pbuilder-clean, though a small warning of linda persists: W: lopster; A binary links against a library it does not use symbols from This package contains a binary that links against a library that is not in the Depends line. This may also be a bug in the library which does not have a shlibs file. I've doublechecked the output of both ldd and objdump -p for /usr/bin/lopster but was not able to identify a library in a package which isn't in Depends. The program works without any problems, though. Any advice? Thanks, Franz -- Franz Pletz \ The Internet treats censorship as www: http://franz-pletz.org/ \ damage and routes around it. email: [EMAIL PROTECTED] \ -- John Gilmore signature.asc Description: Digital signature
Re: RFS : aircrack-ng --- Wireless WEP/WPA cracking utilities
Bonjour Le Vert, I'm not sure of your CC to ftpmaster, so I've removed that CC. I'm looking for a sponsor to upload the new version of aircrack-ng. I have already uploaded the 0.3 release but my sponsor has no time for me for now... I've taken a look and it looks like a very good package, good work! I've got some very small details: You might consider updating the package to the latest policy version 3.7.2 while you're at it. I don't like the directory "stuff" under debian/. Stuff doesn't mean anything. May I suggest to move the manpages subdir of that to just under debian/, or even just put the manpage straight into debian/? The 2-level deep structure for one manpage is just a bit overkill if you ask me. But in any case, don't name stuff "stuff", or things "things", but make sure people can actually know what's in it. You did forward your patches to upstream? There's still an "aircrack" package in Debian, but you say it's dead upstream. Did you persue any effort to have this newer version replace the aircrack package or are there reasons to keep both in Debian? As said, looks good and I hope someone can sponsor you. bye, Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
