Bug#694257: fdk-aac: who knows more?

2013-05-09 Thread Adam M. Costello
Fabian Greffrath :

> Is fdk-aac finally the first *free* high-quality AAC encoder or is it
> just the next *non-free* one after FAAC?

>From what I've read, FAAC is not a high-quality AAC encoder.  As far as
I know, fdk-aac is the only high-quality open-source AAC encoder.

I don't know if fdk-aac is DFSG-free, or GPL-compatible, but even if
it's neither, Debian could still package it, right?  There's also a
command-line tool, fdkaac, that uses it.

Of course, the library would be much more useful if avconv could use it.
If libfdk-aac is GPL-incompatible, what does that imply?  That avconv
must not require libfdk-aac to be present at runtime?  Could it check
for the existence of libfdk-aac and dlopen() it if it's found?  Would
that make them independent enough that their licenses wouldn't need to
be compatible?

It's a shame that various open-source licenses fight each other and thus
impede rather than promote the development of free software.

AMC


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130509210531.klz~@nicemice.net



Bug#308725: ITP: dhcpv6 -- a stateful address autoconfiguration protocol for IPv6

2005-05-12 Thread Adam M
On 5/12/05, Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> wrote:
> On Wed, May 11, 2005 at 08:03:34PM -0500, Adam M. wrote:
> 
> [...]
> 
> > Current upstream does not appear to be very active. I'm not yet certain
> > whether I will make this a Debian package or Upstrea/Debian patch.
> 
> So maybe it would be good idea to package some more active project named
> dibbler? Its author wants to package his software for Debian.

Well, I just DL dibbler. The source code is C++, while dhcpv6 is C
only. The source code for dibbler is much, much larger than dhcpv6.
Dibbler also seems it wants to be a stateless server, like radvd in
addition to DHCPv6 server.

The last revision of dibbler seems to be in December 2004. The last
revision of dhcpv6 is about a year ago.

>From the sources, Dibbler seems to have a linux, windows 2k and xp
ports. dhcpv6 is more for the BSD environment only.

I don't know. I really think that maybe it would be best of dibbler
AND dhcpv6 were packaged separately. It seems these two packages are
complimentary, like Apache and webfs. Also, I do not think dibbler's
client could ever be part of base due to its size. The upstream
tarball contains the dibbler-client at about 1 meg.

- Adam



Bug#308725: ITP: dhcpv6 -- a stateful address autoconfiguration protocol for IPv6

2005-05-12 Thread Adam M
On 5/12/05, Peter Samuelson <[EMAIL PROTECTED]> wrote:
> 
> [Adam M.]
> >   Description : a stateful address autoconfiguration protocol for IPv6
> >  DHCPv6 is a stateful address autoconfiguration protocol for IPv6, a
> >  counterpart to IPv6 stateless address autoconfiguration protocol.
> 
> Please specify whether your package provides a client, a server, or
> both.  If it's only a client, or only a server, you should probably
> rename the package accordingly (see the DHCPv4-related packages).

This was meant as a ITP: 

One binary will include the client, and another the server

> It wouldn't hurt to mention that the stateless server is the Debian
> package 'radvd' and doesn't require specific client software other than
> iproute or whatever.

Yes, radvd is the stateless server and the kernel has the "client" for
auto-self-configuration.

> >  It can either be used independently or it can coexist with its
> >  counterpart protocol. This protocol uses client/server mode of
> >  operation but can also provide support through a Relay Agent.
> 
> Is the Relay Agent provided by this package as well, or by a separate
> Debian package, or does Debian not have one at all?

I don't think there is one. The sources do have a dhcp6relay.c, but
that is not compiled. The relay agent is in the TODO list. I guess the
Relay Agent should have been lowercase!

- Adam



Bug#308725: ITP: dhcpv6 -- a stateful address autoconfiguration protocol for IPv6

2005-05-11 Thread Adam M
On 5/11/05, Hamish Moffatt <[EMAIL PROTECTED]> wrote:
> On Wed, May 11, 2005 at 08:03:34PM -0500, Adam M. wrote:
> > * Package name: dhcpv6
> >   Version : 0.10
> >   Upstream Author : ?? Not a single one - many...
> > * URL : http://dhcpv6.sourceforge.net/
> > * License : Mostly BSD, some LGPL and MIT/X
> >   Description : a stateful address autoconfiguration protocol for IPv6
> >  DHCPv6 is a stateful address autoconfiguration protocol for IPv6, a
> >  counterpart to IPv6 stateless address autoconfiguration protocol. It
> >  can either be used independently or it can coexist with its
> >  counterpart protocol. This protocol uses client/server mode of
> >  operation but can also provide support through a Relay Agent.
> 
> Err. I guess you are packaging an implementation rather than a protocol
> (I'm not sure how you would package a protocol). I think you may need to
> improve your description with that in mind.
> 
> s/protocol/server/ for example.

Right. Although the package will contain the server, the client and
possibly a relay. Well, probably 2 or 3 binary packages from one
source. But yes, s/protocol/{server,client,relay}/ in the one line
description. This long description should probably only be used for
the server and the client/relay have more terse long descriptions of
what they do, not a description of what DHCPv6 protocol is.

- Adam



Bug#308725: ITP: dhcpv6 -- a stateful address autoconfiguration protocol for IPv6

2005-05-11 Thread Adam M.
Package: wnpp
Severity: wishlist
Owner: "Adam M." <[EMAIL PROTECTED]>

* Package name: dhcpv6
  Version : 0.10
  Upstream Author : ?? Not a single one - many...
* URL : http://dhcpv6.sourceforge.net/
* License : Mostly BSD, some LGPL and MIT/X
  Description : a stateful address autoconfiguration protocol for IPv6
 DHCPv6 is a stateful address autoconfiguration protocol for IPv6, a
 counterpart to IPv6 stateless address autoconfiguration protocol. It
 can either be used independently or it can coexist with its
 counterpart protocol. This protocol uses client/server mode of
 operation but can also provide support through a Relay Agent.



Current upstream does not appear to be very active. I'm not yet certain
whether I will make this a Debian package or Upstrea/Debian patch. This
depends on how much of the code can be replaced by current libc
functionality.

I should get this package done within a month (so by mid-June) since I
will be doing some code reviewing and not just packaging.

- Adam


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#301083: ITP: libevolution-ruby -- revolution, ruby binding for the evolution mail client

2005-03-24 Thread Adam M.
David Moreno Garza wrote:

>On Thu, 2005-03-24 at 17:31 +, Henning Makholm wrote:
>  
>
>>Scripsit David Moreno Garza <[EMAIL PROTECTED]>
>>
>>
>>
>>>Revolution is a little Ruby binding to the excellent Evolution email
>>>client.
>>>  
>>>
>>Is it so little that it would be better to include it with the
>>evolution package?
>>
>>
>
>Not quite sure since:
>
>a) evolution, IMHO, doesn't need to depend on ruby.
>b) It is a 3rd-party software, not included officially by Novell.
>c) It is a ruby module itself, just as other several hundreds.
>
>But if evolution's maintainer thinks it could be a good idea (I don't),
>we can implement it in the near future, yes.
>  
>

With regards to a), I don't think you need to depend on ruby at all. The
reason is that the ruby bindings are only available for programs running
in a ruby interpreter (AFAIK). Thus, if you want to *use* the ruby
bindings, you then install ruby. If you do not install ruby, you do not
need or use the ruby bindings.

For example, if you package a libfoo package that is a C library, and
libfoo-dev contains the static part of the C library, then there is no
need to have libfoo-dev depend on the C compiler. Anyone that *uses* the
libfoo-dev library will need to install a C compiler regardless.

Thus, libevelution-ruby doesn't need to depend on Ruby. It only needs to
depend on evolution.

- Adam

PS. It may need build depend on ruby, rake, etc.. , but that is different.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]