ITP lame
LAME Ain't an MP3 Encoder I'm surprised that lame hasn't been packaged already. Was it discussed and rejected previously? Original source available from http://www.sulaco.org/mp3 Licence is 100% GPL'ed code since May 2000 There is a possible problem with the Fraunhoffer (sp?) patent on mp3 but I don't know much about the implications of that. comments welcomed etc, johno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP magellan
Magellan is a personal information manager under development for KDE 2.0. I am a close friend of the project leader and we've discussed this several times. More details available from http://www.kalliance.org The license is the MIT license. I am not assuming that KDE will or will not make it into Woody. I do think that we can start to package software that depends on QT 2.2/KDE 2.0 since Qt is now dual licensed under the QPL/GPL. http://www.linuxplanet.com/linuxplanet/reports/2269/1/ johno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
possible problem with ftp archive
Hi all, I've noticed something that seems odd to me. On ftp.uk.debian.org/debian/dists/potato/main/source theres a bunch of files (.dsc .diff .orig etc) appearing in this directory. Is this the correct behaviour? Is this related to the switch to package pools? I'm curious because the same thing isn't happening for the various binary-* directories and I've seen no explanation for it anywhere. thanks johno -- How many times do users of Windows need to be kicked in the head? It's as if we have a community of people who, upon discovery of 'kick me' signs attached to their backs, do nothing -- and then complain when they eventually do get kicked. -- Evan Leibovitch writing about the "ILOVEYOU" virus.
Re: possible problem with ftp archive
These files include such things as fvwm, koules and xbill. There doesn't seem to be any tools specifically for building packages. I know the source for all the packages is kept under the source directory, but these files aren't in their subcategory directory. eg we have ftp.debian.org/debian/dists/potato/main/source/xcal_4.1.orig.tar.gz but it used to be ftp.debian.org/debian/dists/potato/main/source/misc/xcal_4.1.orig.tar.gz Thats why I am asking "why change it?" johno On Tue, 26 Dec 2000 22:52:33 Bob Nielsen wrote: > > This is what you should expect to find in a Debian source directory. > > These files are used to build packages. See 'man dpkg-source'.
Re: Questions about testing
On Tue, 02 Jan 2001 05:38:36 Branden Robinson wrote: > > Consider that when I manage to hork up X, I know about it within > hours of > dinstall. Likewise, a few days ago when Wichert busted the vim > postinst, > he was told about it quite fast indeed. > > I don't have any concrete recommendations for how to take this into > account, but I certainly think that a 14-day waiting period for > packages > like these is excessive. I agree with you. Lots of popular packages shouldn't need 2 weeks for obvious bugs to be noticed, but I think that most packages should wait 2 weeks to get reasonable quality in testing. That means that not all packages should have the same waiting time. Is there some way that maintainers could take responsibility for deciding how long the waiting period should be? I don't know very much about the details of how the archive is managed. I'd suggest a default of 14 days and probably some minimum time period as well. On a slightly related topic, packages that are updated everyday are a big headache for those of us that are living at the end of a modem, because we have to update many 10's of packages a day == lots of downloading. Its not a problem these days, but it was awkward just after kde and xfree4 were added to woody. (I'm not trying to dictate how people do their job, just pointing out my experiences.) I'd like to see some kind of policy that says that in general packages shouldn't be updated more than twice a week. I know I'm probably in a minority here though and I'll be told to apt-get update twice a week ;) but I'd like to hear if there are good reasons why this would be bad policy. cheers, johno
Re: Developer Behavior
On Mon, 08 Jan 2001 16:17:42 Vince Mulhollon wrote: > > 5) A Debian Developer will never knowingly run a production server > on > "unstable" and will never encourage a non-developer to run > "unstable". For the record I object to any Code of Condust that includes this clause. btw I'm a Ham operator and I recognise the value of the rules we operate by. I don't see any connection between this clause and anything related to Ham radio. johno
Re: Solving the compression dilema when rsync-ing Debian versions
There was a few discussions on the rsync mailing lists about how to handle compressed files, specifically .debs I'd like to see some way of handling it better, but I don't think it'll happen at the rsync end. Reasons include higher server cpu load to (de)compress every file that is transferred and problems related to different compression rates. see this links for more info http://lists.samba.org/pipermail/rsync/1999-October/001403.html johno
