Re: RFS: kplayer
On Mon, Jun 04, 2007 at 12:47:39AM -0500, Richard A. Johnson wrote: Dear mentors, I am looking for a sponsor for my package kplayer. * Package name: kplayer Version:0.6.2 Upstream Author:kiriuja [EMAIL PROTECTED] * URL:http://kplayer.sourceforge.net * License:GPL Section:kde It builds these binary packages: kplayer- KDE multimedia player frontend for MPlayer what is the improvement or things that kmplayer wouldn't do ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpPTL6a1lWkc.pgp Description: PGP signature
Re: About peless
[back to list, again] -=| Giorgio Pioda, Sun, 03 Jun 2007 15:33:35 +0200 |=- I've cleaned up the peless package: http://web.ticino.com/gfwp/debian/peless-1.125/peless_1.125-1.dsc *generated from a tar.gz to have md5sums correspondence *watch file corrected and tested *changelog cleaned up (only 1 entry, initial release (Closes...) Good. Thanks. I have three more little things to mention :) * The .desktop file is invalid, try checking it with desktop-file-validate. As a result, peless is nowhere in the gnome menu. There is also two warnings * The debian/copyright should point to http://developer.berlios.de/project/showfiles.php?group_id=1681 as download location, since one currently used results in something else being downloaded, perhaps some unreleased version. * The debian/menu entry has no icon. Can you add one? Note that menufiles use images in xpm format. It would be best if the .xpm is generated in build time from .png to avoid mismatches if the icon changes in the future. -- damJabberID: [EMAIL PROTECTED] signature.asc Description: PGP signature
Re: RFS: kplayer
On Monday 04 June 2007, Pierre Habouzit wrote: | On Mon, Jun 04, 2007 at 12:47:39AM -0500, Richard A. Johnson wrote: | Dear mentors, | | I am looking for a sponsor for my package kplayer. | | * Package name: kplayer |Version: 0.6.2 |Upstream Author: kiriuja [EMAIL PROTECTED] | * URL: http://kplayer.sourceforge.net | * License: GPL |Section: kde | | It builds these binary packages: | kplayer- KDE multimedia player frontend for MPlayer | | what is the improvement or things that kmplayer wouldn't do ? KMplayer is nothing more than a simple KPart plugin for Konqueror that imitates or mimics the realplayer, media player, quicktime, and flash plugins. KPlayer is a stand alone front end to MPlayer that offers WAY more functionality than KMPlayer. Plus KPlayer has the KIO-Slave connections that allow different types of connections to your media. You can use KPlayer to connect via SSH (fish:/) or HTTP and even secure HTTP with a password. Simply KMPlayer is a Konqui plugin, KPlayer is a full fledged media player/front end. -- Richard A. Johnson [EMAIL PROTECTED] GPG Key: 0x2E2C0124 signature.asc Description: This is a digitally signed message part.
notifying the user about an incompatible upgrade
What is the best way to notify the user or administrator when a new version of a package changes the format of a configuration file in a backwards-incompatible way? These options occurred to me: Try to upgrade the user's old configuration automatically. Document it in NEWS. Print a warning on stderr. Use a debconf note. Send an email to root or some other system user. I'd appreciate any advice. -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: Xnee (updated package) Second try
Dear mentors, I am looking for a sponsor for the new version 2.06-1 of my package xnee. It builds these binary packages: xnee - an X evironment emulator and recorder The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/x/xnee - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/x/xnee/xnee_2.06-1.dsc I would be glad if someone uploaded this package for me. Kind regards Jeremiah Cushman Foster -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About md5sums of debian sources
On Sat, Jun 02, 2007 at 12:26:22PM -0400, Simon wrote: screwing that up. I don't see why the build system isn't just extended to handle bz2 files, it's one of the things that bugs me about debian packaging. That's happening - support for bzip2 compressed tarballs is in dpkg-dev in etch so it can now be enabled in dak when someone gets round to it. There's a policy of making sure that source packages can be unpacked on at least the current stable release so until etch was released it wasn't going to be enabled in the archive. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: RFS: kplayer
This package is already available at www.debian-multimedia.org I would say there's a reason why it isn't in the official repositories. Christian is a DD so he doesn't need any sponsor ;) -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About md5sums of debian sources
On 6/2/07, Roberto C. Sánchez [EMAIL PROTECTED] wrote: Because on some architectures, there are not 2 GHz dual-core or quad-core CPUs available. Making them take double or triple the time for a 10% gain space is probably not acceptable. It's not about saving space, it's about handling upstream release archives with a minimum of modifications. I agree about the performance concerns, and gzip has a very high performance to compression rate ratio, but handling upstream files unmodified saves developers time, and avoids the confusion about the origin of a tarball.
Re: notifying the user about an incompatible upgrade
Hello, On Mon, 04 Jun 2007, Eric Cooper wrote: What is the best way to notify the user or administrator when a new version of a package changes the format of a configuration file in a backwards-incompatible way? These options occurred to me: Try to upgrade the user's old configuration automatically. Document it in NEWS. Print a warning on stderr. Use a debconf note. Send an email to root or some other system user. I don't think there is a generic answer. The answer would depend on the kind of service provided by the package. For example, if the package provides an important service and automatic upgradation of the old config files is likely to break, then it may even be a good idea to have the new package with a new name. Then you could keep both packages maintained for a while with a clear indication to the users that one is deprecated. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About md5sums of debian sources
On Mon, Jun 04, 2007 at 09:31:24PM -0400, Simon wrote: On 6/2/07, Roberto C. Sánchez [EMAIL PROTECTED] wrote: Because on some architectures, there are not 2 GHz dual-core or quad-core CPUs available. Making them take double or triple the time for a 10% gain space is probably not acceptable. It's not about saving space, it's about handling upstream release archives with a minimum of modifications. I agree about the performance concerns, and gzip has a very high performance to compression rate ratio, but handling upstream files unmodified saves developers time, and avoids the confusion about the origin of a tarball. Yes. But then what of projects like OpenOffice.org and gcc? OOo releases their sources in .tar.bz2 files of the following sizes: 117 MB, 28 MB, 16 MB, 70 MB and 28 MB. Gcc releases their sources in .tar.bz2 files of the following sizes: 42 MB, 4 MB, 18.1 MB, 957 KB, 5 MB, 10 MB, 193 KB, 4 MB. Now, according to http://db.debian.org/machines.cgi, the arm and m68k machines avaiable are: elara - (206 MHz StrongARM, 64 MB RAM) europa - (206 MHz StrongARM, 128 MB RAM) leisner - (184 MHz ARM, 60 MB RAM) kullervo - (50 MHz 68060, 112 MB RAM) I am relatively certain that on those machines, the speed boost of using gzip compression over bzip2 compression is probably quite necessary in the ability of those machines which are being used as buildds to keep up. If you search for gzip bzip2 comparisons or benchmarks you will also see, that depending on the benchmark and the files tested, bzip2 can take a great deal longer (some bench marks reported times of up to triple that of gzip) to decompress with bzip2. In addition, bzip2 hogs memory. One benchmark [0] on the OOo 1.1.4 sources showed that when using compression level 9, the sources compressed to 78768334 bytes for gzip and 72223858 for bzip2 (a savings of ~6 MB). However, the decompression time was 38.2s for bzip2 and 3.1 seconds for gzip. That is a difference of more than order of magnitude. The difference for the Linux 2.6.11 sources was even bigger! To say nothing of the fact that bzip2 required about quadruple the amount of memory on decompression. Regards, -Roberto [0] http://tukaani.org/lzma/benchmarks -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: About md5sums of debian sources
On Tue, 2007-06-05 at 00:54 -0400, Roberto C. Sánchez wrote: I am relatively certain that on those machines, the speed boost of using gzip compression over bzip2 compression is probably quite necessary in the ability of those machines which are being used as buildds to keep up. This would suggest that the decompression time (with bz2) is a dominating factor in building software on these machines.. is it? Or is it just supposition? -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: About md5sums of debian sources
On Tue, Jun 05, 2007 at 02:59:16PM +1000, Robert Collins wrote: On Tue, 2007-06-05 at 00:54 -0400, Roberto C. Sánchez wrote: I am relatively certain that on those machines, the speed boost of using gzip compression over bzip2 compression is probably quite necessary in the ability of those machines which are being used as buildds to keep up. This would suggest that the decompression time (with bz2) is a dominating factor in building software on these machines.. is it? Or is it just supposition? Good point. For things like OOo, gcc and linux, probably not. But I imagine that the memory issues is much more relevant. If bzip2 hogs lots of memory, it will push into swap, which will slow things down even more. Of course, there is also the perspective that every little bit helps. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
