Re: Bug#200355: ITP: csound -- incredibly powerful and versatile software synthesis program
> "ju" == Junichi Uekawa <[EMAIL PROTECTED]> writes: >> Everything in csound was relicensed LGPL a couple of months >> ago. Now literally *everything* in csound is LGPL. The page >> above is old and obsolete, and should probably be changed. The >> funny part is that the only one that pushed hard enough to have >> a clear GPL statement (though with an exception) before this >> happened was me with the babo opcode. Now all these problems >> are gone. ju> That is wonderful. csound was one of the larger 'almost free' ju> projects around. We can then concentrate on other things than ju> mimic csound. (well, csound has a pretty difficult interface ju> to play with... ) Just to let you know, we are in contact with the original submitter of the ITP in order to cooperate on the packaging. bye, andrea -- Andrea Glorioso[EMAIL PROTECTED] AGNULA/DeMuDi Technical Managerhttp://www.agnula.org/ "There's no free expression without control on the tools you use"
Re: Bug#200355: ITP: csound -- incredibly powerful and versatile software synthesis program
On Tue, Jul 08, 2003 at 04:58:50PM +0200, Andrea Glorioso wrote: > > "fpl" == Francesco P Lovergine <[EMAIL PROTECTED]> writes: > > fpl> I wonder if that classic package can stay in our archives > fpl> (also non-free). Did you check deeply its license at BATH? > fpl> IMHO it's simply a nightmare... > > fpl> http://www.cs.bath.ac.uk/pub/dream/Copyrights > > As far as I know, much work has gone into csound to ensure that all > copyright holders agreed to switching the license of the whole work to > GNU LGPL. Again, AFAIK all copyright holders have given their > permission, and the work can rightfully be considered libre software. > > I'm putting Nicola Bernardini, one of Csound authors, to see if he can > help us clarify the matter. > > If necessary, we (as the AGNULA project) will clarify things with the > relevant persons (although we are packaging it now and we did check > that we could do it). > That's great. And my compliments to csound team. PS: Nice hear you again, Adrea. -- Francesco P. Lovergine
Re: Bug#200355: ITP: csound -- incredibly powerful and versatile software synthesis program
> "fpl" == Francesco P Lovergine <[EMAIL PROTECTED]> writes: >> If necessary, we (as the AGNULA project) will clarify things >> with the relevant persons (although we are packaging it now and >> we did check that we could do it). >> fpl> That's great. And my compliments to csound team. As you might have seen, the licensing conditions should be cleared out. Lest there are other issues pending, we are going to work on the package with the original proposer and upload it ASAP. fpl> PS: Nice hear you again, Adrea. Thank you. It's nice to be here (although on a very limited time basis, unfortunately). bye, andrea -- Andrea Glorioso[EMAIL PROTECTED] AGNULA/DeMuDi Technical Managerhttp://www.agnula.org/ "There's no free expression without control on the tools you use"
Re: removing the "draft" from the DDP policy
Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> writes: > I am still wating for Adam patches (it's been a while). However, I do not > want to change it from a draft into a official policy. I just want to add > it to the DDP website documentation and mark it _there_ as a draft. The > fact that it's not even listed in the DDP website reduces it usefulness. That's fine with me. > So, I was basicly asking (probably wrongly worded) to: > > a) add a link to the draft from w.d.o/doc/ddp (currently hidden under > w.d.o/doc/docpolicy) > > b) add it to the list of developers' manuals (w.d.o/doc/index and > w.d.o/doc/devel-manuals) > > Of course, I'm not going to change it's status. It will still be called a > 'draft' but it will be given wider exposure. Few people (as demonstrated by > the discussion at -devel and the fact that people at -legal are not aware > of the license section) are aware that we are drafting a policy for > documentation in the Debian project. Seems ok to me. > > Did Adam indicated he stopped doing rewrite of ddp-policy? Did I miss > > something? (Sorry for my long absense from [EMAIL PROTECTED]) > > No he did not, but still, there have been few updates of the document > itself (and I did tell Adam to go ahead and hack it as needed) I've been working on a branch of it actually. I had serious problems with the *scope* of the policy -- it seemed to be more extensive and detailed in places than it needed to be. I have a pretty bad backlog of stuff going on right now. -- ...Adam Di Carlo...<[EMAIL PROTECTED]>...http://www.onshored.com/>
Bug#200770: ITP: ladcca -- linux audio developers configuration and connection API
Package: wnpp Version: unavailable; reported 2003-07-10 Severity: wishlist * Package name: ladcca Version : 0.3.1 Upstream Author : Bob Ham * URL : http://www.some.org/ * License : GPL2 Description : linux audio developers configuration and connection API LADCCA is a session management system for JACK and ALSA audio applications on GNU/Linux. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux xdv 2.4.19-686 #1 Thu Aug 8 21:30:09 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C
Bug#199917 - A consensus on handling Mozilla plugins?
On Thu, Jul 03, 2003 at 10:15:58PM +0200, Jerome Warnier wrote: > Package: mozilla-bonobo > Version: 0.3.0-1 > Severity: normal > > /usr/lib/mozilla/plugins/libmozilla_bonobo.so should be located > elsewhere than in Mozilla's own plugins directory. > /usr/lib/mozilla/plugins/libmozilla_bonobo.so should just be a link to > the real library, somewhere in /usr/lib or so, because Mozilla is not > necessarily installed, while mozilla-firebird or another may be there. Hey everyone, There are currently 5 packages in unstable that dump plugins under /usr/lib/mozilla/plugins, not to mention several more contrib/non-free installers that do the same thing. http://packages.debian.org/cgi-bin/search_contents.pl?word=%2Fusr%2Flib%2Fmozilla%2Fplugins&version=unstable Does anyone have any suggestions as to how to handle plugins for mozilla, mozilla-snapshot and now mozilla-firebird in such a way that plugins are automatically symlinked/delinked whenever a new mozilla-like browser is installed? Where should they go? If I were to start writing an update-mozilla-plugins script for use in mozilla packages, what pitfalls might I encounter? Cheers, Andrew "Netsnipe" Lau -- -- * Andrew "Netsnipe" Lau Computer Science & Student Rep, UNSW * * # apt-get into itDebian GNU/Linux Package Maintainer * * * * 1024D/2E8B68BD: 0B77 73D0 4F3B F286 63F1 9F4A 9B24 C07D 2E8B 68BD * -- pgpOAMBamD7wb.pgp Description: PGP signature
Re: Bug#199917 - A consensus on handling Mozilla plugins?
On Fri, Jul 11, 2003 at 03:36:55AM +1000, Andrew Lau wrote: > On Thu, Jul 03, 2003 at 10:15:58PM +0200, Jerome Warnier wrote: > There are currently 5 packages in unstable that dump plugins under > /usr/lib/mozilla/plugins, not to mention several more contrib/non-free > installers that do the same thing. > > http://packages.debian.org/cgi-bin/search_contents.pl?word=%2Fusr%2Flib%2Fmozilla%2Fplugins&version=unstable > > Does anyone have any suggestions as to how to handle plugins for > mozilla, mozilla-snapshot and now mozilla-firebird in such a way that > plugins are automatically symlinked/delinked whenever a new mozilla-like > browser is installed? Where should they go? IMO, plugins that use the Netscape 4 Plugin API (i.e., all plugins that I know about) should install into /usr/lib/npapi/plugins/, and browsers should add this to their plugin path. The directory doesn't matter. It could be /usr/lib/mozilla/plugins/ or /usr/lib/netscape/plugins. "npapi" is more descriptive of the interface that the plugins actually use, though. > If I were to start writing an update-mozilla-plugins script for use in > mozilla packages, what pitfalls might I encounter? There's really no need. Browsers just need to add a common directory to their plugin path. See also: #179175, #169404. dave...
Bug#200793: ITP: libdaemon -- leightweight C library for daemons
Package: wnpp Version: unavailable; reported 2003-07-10 Severity: wishlist * Package name: libdaemon Version : 0.2 Upstream Author : Lennart Poettering * URL : http://www.stud.uni-hamburg.de/~lennart/projects/libdaemon/ * License : GPL Description : leightweight C library for daemons libdaemon is a leightweight C library which eases the writing of UNIX daemons. It consists of the following parts: * A wrapper around fork() which does the correct daemonization procedure of a process * A wrapper around syslog() for simpler and compatible log output to Syslog or STDERR * An API for writing PID files * An API for serializing UNIX signals into a pipe for usage with select() or poll() Routines like these are included in most of the daemon software available. It is not that simple to get it done right and code duplication cannot be a goal. The new version of ifplugd depends on this library, that's why it is needed. Greetings, Oliver -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux debian 2.4.21 #3 Thu Jun 26 14:08:29 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=de_DE
Re: Bug#199917 - A consensus on handling Mozilla plugins?
David Schleef wrote: > The directory doesn't matter. It could be /usr/lib/mozilla/plugins/ > or /usr/lib/netscape/plugins. "npapi" is more descriptive of the > interface that the plugins actually use, though. /usr/lib/npapi is meaningless to most user who will know mozilla/plugins and netscape/plugins. Cheers T. pgptoSyB4mzHn.pgp Description: PGP signature
Re: Bug#199917 - A consensus on handling Mozilla plugins?
On Thu, Jul 10, 2003 at 09:45:17PM +0200, Thomas Viehmann wrote: > David Schleef wrote: > > The directory doesn't matter. It could be /usr/lib/mozilla/plugins/ > > or /usr/lib/netscape/plugins. "npapi" is more descriptive of the > > interface that the plugins actually use, though. > > /usr/lib/npapi is meaningless to most user who will know > mozilla/plugins and netscape/plugins. And?? What does it matter? So /usr/lib/npapi is meaningless to the user. The /usr/lib/mozilla/plugins directory could be a symlink back to /usr/lib/npapi/plugins. As could the /usr/lib/netscape/plugins directory. I'm sure that there are many directories that are meaningless to several users. -- Jamin W. Collins Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
Re: Bug#200770: ITP: ladcca -- linux audio developers configuration and connection API
On Thursday 10 July 2003 18:35, Guenter Geiger (Debian/GNU) wrote: > * URL : http://www.some.org/ > * License : GPL2 > Description : linux audio developers configuration and connection API > > LADCCA is a session management system for JACK and ALSA audio > applications on GNU/Linux. Can you supply the URL of the project please ? And while you're at it, I'd in fact switch the short description and the long one, it says much more than the meaning of the raw abbreviation. One question also, JACKs homepage says it was written primarily for Linux does that mean it also runs on top of other kernels? ;) Uli
Re: Please remove RFCs from the documentation in Debian packages
On Sat, Jul 05, 2003 at 04:40:36PM -0500, Branden Robinson wrote: > On Fri, Jul 04, 2003 at 12:53:56AM -0400, David B Harris wrote: > > Except for the title, the DFSG is very content-agnostic. It can be > > applied equally well to software, fiction, nonfiction, images, what have > > you. > > I think that's a feature. Apparently, some people think it's a bug. Let's call it an accidental feature. -- Larry Wall ;)
Re: but I want the GNU versions of packages
On Mon, 30 Jun 2003 13:58:54 +0100, Colin Watson wrote: > On Mon, Jun 30, 2003 at 09:31:39AM +0200, Roland Mas wrote: > > Dan Jacobson (2003-06-28 07:57:55 +0800) : > > > Gentlemen, after I installed "Debian GNU/Linux", I found I had to > > > take extra steps to get the GNU version of a program installed, as > > > some other leading brand alternative was in its stead. > > > > > > So what is the single command to apt-get install all the GNU > > > versions of everything? > > > > I humbly suggest "apt-get install task-gnu-only". Of course, someone > > will have to make and maintain that task package, but once done, there > > you are. Or you could start a Debian-GNU-Only subproject. > > One question: what's the point? Surely you want the best, not > necessarily the GNU version (which might be an incredibly bleeding-edge > pre-alpha thing, like for example mailutils was not so long ago)? bleeding-edge pre-alpha thing... well task-gnu-only will include the Hurd, won't it? ;) -- Robert Millan
