Re: [FLAME WARNING] Linux Standards Base and Debian
Wed, May 09, 2001 at 02:14:20PM -0800 wrote: > this choice of using the rpm binary format should be reconsidered > IMNSHO. i don't really care whether you use the debian ar+tar+gzip, > or just plain .tar.gz, just use something i can extract *anywhere* > with the most basic and standard tools, without having to go and > compile rpm or some rpm archive extracter. This is a very important point. I hope those involved in the standardization effort will consider this point. Even in non emergency situations I have attempted to extract data from an rpm on a machine withouth rpm (documentation, for example) and have not been successful. David > > -- > Ethan Benson > http://www.alaska.net/~erbenson/
Re: Bug#96638: ITP: libkudzu
> > kudzu was dead, but I guess not. What I would like is to have a real > > hardware > > detection system that continues after the main installation. That way when > > new > > hardware is added to the system we could help the user make the necessary > > software changes. > > Is there already policy on how this hardware detection should be > implemented? Not as far as I know. I tend to think that Progeny's discover would be a good start, but only because I have looked at it and it is already Debian-centric. But kudzu has a longer history, who knows. In any case I expect this is for after woody. David
Re: [users] Re: Where's lame
Lame cannot be included in Debian, please see: http://www.debian.org/devel/wnpp/unable-to-package -David Mon, May 07, 2001 at 03:22:33PM -0400 wrote: > hi developers, > this is my first message, i hope it's appropriate. there's talk going > on on the users mailing list about lame and its absence from the > package tree. i would like to adopt the lame mp3 encoder as a debian > package and was wondering if there are any objections? is there > already a maintainer? can this packet be debianized? > > thanks, > > martin; (greetings from the heart of the sun.) > \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] > -- > humpty was pushed. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to implement a renamed package
> Thanks, - I know this and have done it previously in the case of > zicq and krolden. However, what I really wanted to know is, how > this (or any other) procedure can take care that the users of the > old package will get the renamed package automatically updated with > 'apt-get upgrade'? Oh, I see, the simple replaces and conflicts won't work there (I just tested it on some dummy packages because I thought it would, but you are right, it doesn't.) > Otherwise, the new (renamed) upstream version > could be easily overlooked and the users would just wonder why the > old package is removed from the archives. > As far as I know the standard procedure depends on the active > selection of the renamed package, and the only replacement-effect is > that it will remove the old package when it is installed. But the > problem is: How shall the user know that the new package replaces > another package with a different name? I haven't found anything better than Ben Burton's suggestion of the dummy package foo that depends on newfoo, that isn't very graceful, I'll admit. David
Re: how to implement a renamed package
Sat, May 05, 2001 at 08:43:30PM +0200 wrote: > Hello, > > I am maintaing the Debian package puzzle and have a problem > with the new upstream version. The package and program has been > renamed by upstream to tree-puzzle, because there was a conflict > with another program named puzzle. > I was considering to make a new package tree-puzzle which conflicts > and replaces puzzle, but this way the users of puzzle would not get > the automatical upgrade of this new upstream version with 'apt-get > upgrade'. > Thus, how can I automatically replace the package puzzle with the > new package tree-puzzle? This is discussed in the Developer's Reference [1]: 9.3 Replacing or renaming packages Sometimes you made a mistake naming the package and you need to rename it. In this case, you need to follow a two-step process. First, set your debian/control file to replace and conflict with the obsolete name of the package (see the Debian Policy Manual for details). Once you've uploaded that package, and the package has moved into the archive, file a bug against ftp.debian.org asking to remove the package with the obsolete name. [1] : http://www.debian.org/doc/developers-reference/ch-archive-manip.en.html#s9.3 > > Greetings, > Guenter > > -- > Linux: Who needs GATES in a world without fences? > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: English translation list
> Absolutely seconded. I have, for example, create a GRUB Howto in French, > simply because it sounds to me stupid to try to write an "original" text > that is not the best I can make (I don't say it's good, I just say it is > better in the native language). > I'd like to see the list as well. By the way, I would be happy to translate the GRUB HOWTO. If you can send me a pointer to the sgml source that would be great. David
Re: Two debconf issues
> > for some, I need rather complex text processing. Since perl isn't > > essential, writing the script in perl would make the package depend on > > perl while this is unnecessary for normal operation. Would this be > > acceptable or should I find a better solution? > > > > If you use debconf you are using perl (-: of course awk is your friend and > mine. > It is likely that Randolph Chung's cdebconf http://packages.debian.org/testing/utils/cdebconf.html will be a complete and compatible alternative to the perl version in the future. In that case it would be that fact that perl-base is 'priority required' that allows you to avoid a dependancy on perl rather than the fact that you are using debconf. There has been discussion of making perl not required, but it remains to be seen if that will happen. David
Re: How to remove a package from ftp.debian.org?
Fri, Apr 27, 2001 at 04:52:58PM +0200 wrote: > Subject says it all. Do I have to file a bug against ftp.debian.org? > yes http://www.debian.org/doc/developers-reference/ch-archive-manip.en.html#s-removing-pkgs David P.S. this sort of question can probably be best asked on -mentors. > Michael > -- > Michael Meskes > Michael@Fam-Meskes.De > Go SF 49ers! Go Rhein Fire! > Use Debian GNU/Linux! Use PostgreSQL! > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: macdebian?
Oui, va voir : http://www.debian.org/ports/m68k/ http://www.debian.org/ports/powerpc/ David Wed, Apr 25, 2001 at 10:06:49PM +0200 wrote: > il y a-t-il une version de debian pour Mac? > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FYI: dh_upx compresses i386 executables
Sun, Apr 22, 2001 at 11:52:55PM -0700 wrote: > On Sun, Apr 22, 2001 at 11:39:07PM -0700, David Whedon wrote: > > Recent versions of upx can compress a linux bzImage (I've seen 13% shaved > > off > > a bzImage). debian-installer may use it to squeeze more onto the single > > floppy (kernel + initrd with modules). > > Isn't that slightly redundant? to some extent, yes. >A bzImage is compressed in the first place. indeed. > If anything, it should compress the vmlinux. I haven't tried that, if that ends up with something smaller, that's cool. I was just using a bzImage already, so I compressed it, it was smaller, and it booted, no need to look deeper than that. David > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FYI: dh_upx compresses i386 executables
Recent versions of upx can compress a linux bzImage (I've seen 13% shaved off a bzImage). debian-installer may use it to squeeze more onto the single floppy (kernel + initrd with modules). David Sat, Apr 21, 2001 at 06:25:10PM -0700 wrote: > On Sat, 21 Apr 2001, John H. Robinson, IV wrote: > > > however, on something like boot-floppies, this might be a goddess-send. > > No, it isn't. gzip -9 already applied to the floppies is very close to > the gziped upxed binary size. I tried upx on the boot floppies last > release (from which this claim is based). > > Andrew Lenharth > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: mserv
http://www.mserv.org/ License is BSD. Description: local centralised multiuser music environment Mserv is a music server designed to do a number of things better than most systems designed to play mp3s: . Supports any type of client using standard TCP protocol Stores information on mp3 (bitrate, duration, name, author, genre, date produced, last play date) in on-disk database. Stores rating information supplied by the user (awful, bad, neutral, good, superb). Has a comprehensive queuing system (track, album, random album, etc) Random play chooses the songs that people currently on-line want to hear using their ratings of the songs. Search facilities, status information, statistics, etc. User management facilities, four levels of users, encrypted passwords. Talker style communication (say, emote etc.) Play, next, pause, stop, repeat, volume, bass, treble settings. On-line and off-line track information editing. Advanced filter facilties (e.g. 'john=superb', '!good', 'year>1990', 'duration<180', 'genre=pop', 'john=good|fred=unheard' etc.) Built-in telnet client (see manual). Library interface, no need to write TCP code. Comes with command line shell program for interfacing and web client to this shell program for web-based control. Uses an external player to output, and is known to support mpg123 and freeamp - this could be used to broadcast the output or support other players. Comes with a setuid wrapper for mpg123-compatible players that can increase the nice level for low-capability processors.
