date:20020821

This an alternative solution to the -Bsymbolic/-Blocal approach that I
exposed before. It doesn't require any loader/linker code modifications
but requires more work by the library maintainers and is better done
with upstream consensus (but this isn't strictly necessary).

First, we must define versioned symbols for the conflicting libraries.
This must be done by creating version scripts with only one version tag
(otherwise unversioned objects will not be able to bind to versioned
symbols).
Here is an example: (note: this might not be completely correct for
libpng)
libpng2.ver:
LIBPNG_2.0 {global: png_*; local: *;};

libpng3.ver:
LIBPNG_3.0 {global: png_*; local: *;};

Then, a --version-script argument should be added to LDFLAGS and the
affected libraries and all the libraries that use them should be
rebuilt.

After we do this, however, we have a problem: programs linking to the
libraries will be built with versioned symbols.

This reduces binary compatibility since having objects with different
versions schemes will cause failure and having versioned objects using
unversioned ones will cause warning messages.

This can be easily fixed by creating a /usr/lib/dev directory and
modifying the GNU binutils package so that it is in front of the linker
search path.
Then, conflicting libraries can be built in a normal versioned version
and in an unversioned one that is installed in /usr/lib/dev and put in
the -dev package for the library.

Not building programs with versioned symbols works because the library
they use is always the first one in the search path. However, if the
program is unversioned and more than one of the conflicting libraries is
used, all libraries that are or use one of the conflicting libraries
which is not the one used by the main program must be compiled with
-fPIC (otherwise the library symbols will be resolved by the undefined
symbols in the main program resulting in the wrong library version being
used). This should already be the case for all libraries so this
shouldn't be a problem.



signature.asc
Description: This is a digitally signed message part

Re: RFC: OpenLDAP and TLS/SSL

Both problems can be solved by simply writing the version scripts so
that only a version tag is mentioned in each:
libpng2.ver:
LIBPNG_2.0 {global: png_*);

libpng3.ver:
LIBPNG_3.0 {global: png_*);

However, we'll still get a warning message if versioned binaries are
used with unversioned libraries.

BTW, libraries that use one the conflicting ones must be compiled with
-fPIC, but that should already happen.



signature.asc
Description: This is a digitally signed message part

Re: When bind9 reinstalls, no db.root

2002-08-21 Thread Scott K. Ellis

> Still, breaking bind's access to root name servers is particularly
> troublesome because it may tend to break all net access.  It may be
> worthwhile to remove db.root from the list of configuration files.
> Especially, because this list isn't something anyone should need to
> change.

I beg to disagree.  Changing db.root is the primary way to use an alternate
DNS root (either for an all-internal DNS, or to utilize an alternate DNS
root than NetSol's).  Just because you can't see why something might be
configured differently doesn't mean other people can't.

exim vs. exim-tiny (was: RFC: OpenLDAP and TLS/SSL)

2002-08-21 Thread David Pashley

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday 21 August 2002 2:57 pm, Stephen Frost wrote:
> * Torsten Landschoff ([EMAIL PROTECTED]) wrote:
> > Today I was convinced by Stephen Frost that I can just enable SSL support
> > in the OpenLDAP packages I maintain. No problem so far, but:
> >
> > - libldap2 is Priority: important
> > - this change will make it depend on libssl0.9.6
> > - libssl0.9.6 is Priority: standard
>
> [...]
>
> > Any suggestions welcome
>
> Hey all,
>
>   I already explained my feelings about this to Torsten but since we're
>   moving it to -devel I'll lay out my thoughts here too.
>
>   First off, crypto is important to us and I think we tend to feel that
>   it is important for our users as well.  Thus, I see libssl0.9.6 being
>   made Priority: Important as a good option.
>
>   If there are too many other issues with making libssl0.9.6 important
>   (though it only Depends: on libc and isn't very big?) then I would
>   think that we are very concerned about the size and would therefore
>   recommend that ldap support be removed from exim or exim be split into
>   exim-tiny for Important and exim-big with everything enabled.  Of
>   course, exim support being modified to be modular would be an
>   excellent option but would require a decent amount of work I think.
>
>   Not having any exim with support for mysql in Debian has been a
>   problem in the past for Debian users that I know.
>
As the main person in #exim on OPN, I've seen several people ask about exim 
with mysql or postgres support. There is a bug about having mysql support in 
exim in debian. (Wouldn't it be nice to have voting in debbugs?). I realise 
that exim does not have the sanest of build systems, but is there any chance 
of getting two exim packages built? Maybe the ability to choose a different 
patch to enable mysql et al support via a envvar. That way I can instruct 
people to rebuild exim.


- -- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9ZDvSYsCKa6wDNXYRAoU3AJ9WNEf5881o6GOp3aJxBrYj1cGbrwCfYEV5
KaZa7qbKprMMjdNqsf4l1q4=
=Ck+m
-END PGP SIGNATURE-

Bug#157799: ITP: anubis -- An outgoing mail processor.

2002-08-21 Thread Janusz A. Urbanowicz

Package: wnpp
Version: N/A; reported 2002-08-22
Severity: wishlist

* Package name: anubis
  Version : 3.4.0
  Upstream Author : Wojciech Polak <[EMAIL PROTECTED]>
* URL : http://anubis.sourceforge.net/
* License : GPL
  Description : An outgoing mail processor.


 Anubis is an outgoing mail processor, and provides the SMTP tunnel
 between the MUA and the MTA. It features extended regular expressions
 support, PerlRE support, TLS/SSL support, and GnuPG support.  

 It is ka kind of next generation of premail, but less cypherpunk oriented
 and more powerful.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux FUCKUP.fantastyka.net 2.4.18 #3 pon sie 19 16:24:30 CEST 2002 i686
Locale: LANG=pl_PL.ISO-8859-2, LC_CTYPE=pl_PL.ISO-8859-2

Re: When bind9 reinstalls, no db.root

On Wed, Aug 21, 2002 at 06:39:55PM -0500, Steve Greenland wrote:
> On 21-Aug-02, 15:10 (CDT), Marc Singer <[EMAIL PROTECTED]> wrote: 
> > It would help to have an example.  
> 
> I could have sworn I had a footnote about /etc/cron.allow, with a
> reference to the appropriate manpage :-). Okay, it's not the *best*
> example, because I don't actually ship a cron.allow, but the point is
> there: A missing cron.allow permits everybody to use crontab, while an
> empty cron.allow forbids use of crontab by anybody (except root, of
> course).

It does appear that there are a couple of good examples.  In fact,
this is not one of them since what you ought to ship is a cron.allow
that blocks everything, right?  That way the default behavior is
obvious to someone browsing the configuration. 

As far as I can tell, there aren't many 'dangerous' examples.  A
package may install a crontab file in cron.d that is deleted by the
user.  Apparently, apache2 performs directory scanning for
configuration files, too.  Examples such as BASH are definitely *not*
dangerous since the default file contains a single, innocuous
directive.  

As I wrote in another message, given that there is an override switch
in dpkg, that switch would be helpful if available in apt-get.

Re: RFC: OpenLDAP and TLS/SSL

Yes, unfortunately that situation triggers an assert... what a great
feature :(

So apart from the need to remove the unversioned-uses-versioned error,
we also to produce unversioned binaries.

The simplest way to this is is IMHO to add a /usr/lib/dev directory and
make it the first directory searched by ld (this should be possible by
either wrapping ld or adding it to linker scripts in the ld source).

Then when we build the library package, we build a versioned library for
the main package and an unversioned one for the -dev package that gets
put in /usr/lib/dev (rather than relinking, we may write a tool to strip
the versioning info).

This way, Debian/non-Debian unversioned binaries work properly with
Debian multiple versioned libraries because we patch the dynamic loader
(easy to do) and Debian binaries work with non-Debian libraries because
they are still unversioned.

How about this?



signature.asc
Description: This is a digitally signed message part

Re: When bind9 reinstalls, no db.root

On Wed, Aug 21, 2002 at 07:32:04PM -0400, Matt Zimmerman wrote:
> On Wed, Aug 21, 2002 at 04:23:16PM -0700, Marc Singer wrote:
> 
> > On Wed, Aug 21, 2002 at 07:06:22PM -0400, Matt Zimmerman wrote:
> > > _Any_ program whose default (Debian) configuration file specifies
> > > options which are different from the compiled-in defaults.
> > > 
> > > For specific examples, see almost any program on your system with a
> > > global config file.
> > 
> > Hand-waving doesn't constitute an example.
> 
> How about bash?  A missing /etc/bash.bashrc has a different effect than the
> default /etc/bash.bashrc.  A missing /etc/bash_completion has a different
> effect than the default /etc/bash_completion.  Missing /etc/skel/.bash* will
> avoid having any .bash* files copied into new users' home directories.  I
> think that you have bash installed (assuming you run Debian), so you now
> have an example that you can experiment with on your own system.  And you
> didn't have to go to the trouble of figuring it out for yourself.
> 
> You may shut up now.

This terse reply is obviously inappropriate.  If you are annoyed, stop
writing.

I was asking for real examples in order to discuss how the case of
bind and db.root is *not* a member of that set and how there may be a
genuine problem with the handling of installing over missing
configuration files.

As far as I can tell there is no way to pass --force-confmiss to dpkg
when using apt-get.  Perhaps this is the only real omission.  

Still, breaking bind's access to root name servers is particularly
troublesome because it may tend to break all net access.  It may be
worthwhile to remove db.root from the list of configuration files.
Especially, because this list isn't something anyone should need to
change.

Re: RFC: OpenLDAP and TLS/SSL

I forgot to consider what happens when a Debian-built versioned binary
is used with a non-Debian no-versioned library.

Here is Drepper's explanation:
The last case is if the object with the references uses symbol
versions but the object with the definitions has none.  In this case a
matching symbol is accepted unless the object's name matches the one
in the Elfxx_Verneed entry.  In the latter case this is a fatal error.
In fact, this should never have happened in the first place since it
would mean the list of required symbols was not correct and the steps
required in the last section therefore haven't detected a too old
version of an object file.

It seems that this would cause an error... Argh.
I'll look at the source to check whether this is true.

If it is, we also have to somehow setup the toolchain so that binaries
are built unversioned until everyone adopts versioning (or until
everyone patches the dynamic linker to avoid this fatal error).




signature.asc
Description: This is a digitally signed message part

Re: When bind9 reinstalls, no db.root

2002-08-21 Thread Steve Greenland

On 21-Aug-02, 15:10 (CDT), Marc Singer <[EMAIL PROTECTED]> wrote: 
> It would help to have an example.  

I could have sworn I had a footnote about /etc/cron.allow, with a
reference to the appropriate manpage :-). Okay, it's not the *best*
example, because I don't actually ship a cron.allow, but the point is
there: A missing cron.allow permits everybody to use crontab, while an
empty cron.allow forbids use of crontab by anybody (except root, of
course).

Steve

-- 
Steve Greenland

The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: RFC: OpenLDAP and TLS/SSL

On Thu, 2002-08-22 at 00:11, Henrique de Moraes Holschuh wrote:
> On Wed, 21 Aug 2002, Luca Barbieri wrote:
> > This is an another problem that would be easily and compatibly solved by
> > my ELF extension (until the library gets properly fixed upstream).
> 
> Yes and no. Versioned symbols are here NOW and can be used NOW, and they fix
> the issue cleanly without drawbacks:  they are as painful as a
> do-it-only-once global soname increase (which is quite painful though).
I just got a Great Idea(tm).

This is the explanation from Ulrich Drepper:

In case only the object file with the reference does not use
versioning but the object with the definition does, then the reference
only matches the base definition.  The base definition is the one with
index numbers 1 and 2 (1 is the unspecified name, 2 is the name given
later to the baseline of symbols once the library started using symbol
versioning).  The static linker is guaranteed to use this indeces for
the base definition.  If there is no symbol definition with such an
version index and there is exactly one version for which this symbol
is defined, then this version is accepted (this was mostly implemented
for dlopen() calls as it will normally not happen when the static
linker is used). 

However this the problem:

Otherwise, if more then one version of the symbol is
available, none of the definitions is accepted and the search
continues with the next object.

If we modify the loader so that it instead accepts the first one, this
first one will be correct for the main program.

So if we modify the loader to do this and recompile the conflicting
libraries and the ones that use them we can address both the short-term
and the long-term issues while still allowing symbols to overridden.

With unmodified loaders and multiple versioned libraries in a program,
the binaries will fail until they are recompiled to use versioned
symbols. However this isn't worse than the current situation that causes
them to pseudorandomly fail.

Furthermore, since the binary would fail I don't think that anything
relies on the existing behavior.

Also, there is no chance of creating incompatible ELF formats since the
format isn't changed.

How about this? This seems better than using my patch.

Am I missing something?

signature.asc
Description: This is a digitally signed message part

Re: When bind9 reinstalls, no db.root

2002-08-21 Thread Matt Zimmerman

On Wed, Aug 21, 2002 at 04:23:16PM -0700, Marc Singer wrote:

> On Wed, Aug 21, 2002 at 07:06:22PM -0400, Matt Zimmerman wrote:
> > _Any_ program whose default (Debian) configuration file specifies
> > options which are different from the compiled-in defaults.
> > 
> > For specific examples, see almost any program on your system with a
> > global config file.
> 
> Hand-waving doesn't constitute an example.

How about bash?  A missing /etc/bash.bashrc has a different effect than the
default /etc/bash.bashrc.  A missing /etc/bash_completion has a different
effect than the default /etc/bash_completion.  Missing /etc/skel/.bash* will
avoid having any .bash* files copied into new users' home directories.  I
think that you have bash installed (assuming you run Debian), so you now
have an example that you can experiment with on your own system.  And you
didn't have to go to the trouble of figuring it out for yourself.

You may shut up now.

-- 
 - mdz

Re: When bind9 reinstalls, no db.root

On Wed, Aug 21, 2002 at 07:06:22PM -0400, Matt Zimmerman wrote:
> On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote:
> 
> > For example...
> 
> _Any_ program whose default (Debian) configuration file specifies options
> which are different from the compiled-in defaults.
> 
> For specific examples, see almost any program on your system with a global
> config file.

Hand-waving doesn't constitute an example.

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

Re: When bind9 reinstalls, no db.root

2002-08-21 Thread Mark Brown

On Wednesday, August 21, 2002, at 09:08 PM, Marc Singer wrote:
Without a single example, I don't see how installing a configuration
file where there is none can have *any* affect on the system.
Admittedly, replacing a configuration file may be undesirable.
In addition to the example of configuration files that change compiled 
in defaults that has already been mentioned consider things like 
logcheck or apache2 which scan a directory   processing all files within 
it.

Re: When bind9 reinstalls, no db.root

2002-08-21 Thread Matt Zimmerman

On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote:

> For example...

_Any_ program whose default (Debian) configuration file specifies options
which are different from the compiled-in defaults.

For specific examples, see almost any program on your system with a global
config file.

-- 
 - mdz

Re: When bind9 reinstalls, no db.root

On Wed, Aug 21, 2002 at 03:12:37PM -0700, Marc Singer wrote:
> On Wed, Aug 21, 2002 at 09:21:39PM +0100, Colin Watson wrote:
> > On Wed, Aug 21, 2002 at 01:10:29PM -0700, Marc Singer wrote:
> > > It would help to have an example.  However, even if there is an
> > > example I don't see how db.root fits in this category.
> > 
> > Unfortunately there's no way for a package to override this aspect of
> > dpkg's conffile handling. It would have to be handled entirely in the
> > maintainer scripts in some different (and careful!) way.
> 
> Is the feature triggered for files appearing in /etc?

The documentation on conffiles is in section 11.7 of policy.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: When bind9 reinstalls, no db.root

2002-08-21 Thread Andreas Rottmann

Marc Singer <[EMAIL PROTECTED]> writes:

> Without a single example, I don't see how installing a configuration
> file where there is none can have *any* affect on the system.
> Admittedly, replacing a configuration file may be undesirable.
> 
There might be (and surely are) programs, that will, given the lack of
a config file, use their compiled-in defaults. So the installation of
a config file will change the configuration of the program, unless the
installed config file contains just the (also compiled-in) defaults.

Regards, Andy
-- 
Andreas Rottmann | [EMAIL PROTECTED]| [EMAIL PROTECTED] | 
[EMAIL PROTECTED]
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Re: When bind9 reinstalls, no db.root

On Wed, Aug 21, 2002 at 09:21:39PM +0100, Colin Watson wrote:
> On Wed, Aug 21, 2002 at 01:10:29PM -0700, Marc Singer wrote:
> > On Wed, Aug 21, 2002 at 03:00:52PM -0500, Steve Greenland wrote:
> > > To be, perhaps, a little more explicit: there are programs for which
> > > the existence of an empty configuration file means something completely
> > > different than a missing a configuration file[1]. Thus, for dpkg
> > > conffile handling, removing a configuration file is a legitimate "edit".
> > 
> > It would help to have an example.  However, even if there is an
> > example I don't see how db.root fits in this category.
> 
> Unfortunately there's no way for a package to override this aspect of
> dpkg's conffile handling. It would have to be handled entirely in the
> maintainer scripts in some different (and careful!) way.

Is the feature triggered for files appearing in /etc?

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

Re: RFC: OpenLDAP and TLS/SSL

On Wed, 21 Aug 2002, Luca Barbieri wrote:
> This is an another problem that would be easily and compatibly solved by
> my ELF extension (until the library gets properly fixed upstream).

Yes and no. Versioned symbols are here NOW and can be used NOW, and they fix
the issue cleanly without drawbacks:  they are as painful as a
do-it-only-once global soname increase (which is quite painful though).

It has the potential of encoding C++ ABI (or any other identifiers we need)
information as well, should that be desired.  -Bsymbolic (your modified
version of it) cannot fix that.

> concept that symbol names must be *globally* unique, not just unique to
> filename and that they either put the version number in the symbol (e.g.
> sasl1_explode vs. sasl2_explode) and use #define's to keep source
> compatibility or they use GNU/Solaris versioned symbols.

Yes.  We really should simply have *all* libraries using versioned symbols.
The version symbol "tag" could always be at least the library soname (i.e.
the ABI number, and library name).

Is there a reason for not doing the above? It's not like it would be
difficult to do (although it means a mass-recompile, but it certainly needs
not to be done all in one day...).  We could just try to set a standard that
linux-based OSes *distributions* always versions its symbols with the ABI
soname, and that's it...

That won't fix the breakage caused by C++ compilers, unfortunately. The C++
ABI number would have to be added to the library versioning tag, too.   It
can be done without changes to the linkers, by the makefiles [we just need a
way to query the compiling environment which stuff we should prefix/suffix
the symbol versioning with]. 

It's cleaner to just have another ELF field with the compiler ABI, and have
gcc and other C++ compilers for linux add that automatically...

> We should also alert upstream of this kind of problems _before_ new
> versions get released and binary compatibility makes them untouchable.

ABIs are not really upstream's responsability... unless it is a Linux-only
package, when upstream *might* take care of it, if they want to.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: When bind9 reinstalls, no db.root

On Wed, Aug 21, 2002 at 10:21:17PM +0200, Oliver Kurth wrote:
> On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote:
> > On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote:
> > > > > Sounds like you want dpkg --force-confmiss.
> > > > 
> > > > I wouldn't expect that since the documentation states:
> > > > 
> > > >  confmiss: Always install  a  missing  configuration
> > > >   file.  This  is  dangerous, since it means not pre-
> > > >   serving a change (removing) made to the file.
> > > > 
> > > > How could it be dangerous to install a *missing* configuration file?
> > > 
> > > If the default configuration data in the file do something you don't want.
> > 
> > For example...
> 
> autofs. First thing I do when I install autofs in at networked environmemt is
> rm /etc/auto.*
> because I want to use the NIS maps.

I don't think that example works for all of the auto.* files.  The
master file references the other files.  Removing the master
eliminates the references to the others.  However, adding auto.furball
won't affect autofs unless auto.master references it.


> 
> Greetings,
> Oliver
> -- 
> Oliver Kurth
> mailto:[EMAIL PROTECTED] http://leinekanal.de

Re: apt-get wants to upgrade package to same version?

2002-08-21 Thread Brian May

On Wed, Aug 21, 2002 at 03:44:54PM -0600, Jason Gunthorpe wrote:
> > Description: Dummy library package for Kerberos4 From KTH.
> >  This is a dummy package. It should be safe to remove it.
> >  installed-size: 76
> >  source: krb4

If you mean the spacing is different, that is my fault (I use vim in
mutt, and it automatically indents stuff pasted in using X... Arrghhh...
Need to disable that by default in my config I think).

Package: kerberos4kth1
Version: 1.1-11-2
Priority: optional
Section: net
Maintainer: Mikael Andersson <[EMAIL PROTECTED]>
Architecture: all
Filename: ./pool/krb4/kerberos4kth1_1.1-11-2_all.deb
Size: 57786
MD5sum: 330d49310a3264f037875e06a1328458
Description: Dummy library package for Kerberos4 From KTH.
 This is a dummy package. It should be safe to remove it.
installed-size: 76
source: krb4

vs

[504] [snoopy:unstable:bam] /home/ftp/pub/debian >dpkg -I
./pool/krb4/kerberos4kth1_1.1-11-2_all.deb
 new debian package, version 2.0.
 size 57786 bytes: control archive= 701 bytes.
 288 bytes,10 lines  control  
 229 bytes, 3 lines  md5sums  
 281 bytes, 9 lines   *  postinst #!/bin/sh
 208 bytes, 7 lines   *  prerm#!/bin/sh
 Package: kerberos4kth1
 Version: 1.1-11-2
 Section: net
 Priority: optional
 Architecture: all
 Installed-Size: 76
 Maintainer: Mikael Andersson <[EMAIL PROTECTED]>
 Source: krb4
 Description: Dummy library package for Kerberos4 From KTH.
  This is a dummy package. It should be safe to remove it.

The description looks the same now:

Description: Dummy library package for Kerberos4 From KTH.
 This is a dummy package. It should be safe to remove it.
Description: Dummy library package for Kerberos4 From KTH.
 This is a dummy package. It should be safe to remove it.
-- 
Brian May <[EMAIL PROTECTED]>

Re: apt-get wants to upgrade package to same version?

2002-08-21 Thread Jason Gunthorpe


On Thu, 22 Aug 2002, Brian May wrote:

> I ran dpkg-scanpackages on it myself, and haven't updated anything
> since (besides, if I had updated something, the MD5sum check would fail
> wouldn't it?)

Nope.
 
> Description: Dummy library package for Kerberos4 From KTH.
>  This is a dummy package. It should be safe to remove it.
>  installed-size: 76
>  source: krb4

vs
 
>  Description: Dummy library package for Kerberos4 From KTH.
>   This is a dummy package. It should be safe to remove it.
 
> What is different?

The description?

Looks like dpkg-scanpackages foobar'd you.

Jason

Re: apt-get wants to upgrade package to same version?

2002-08-21 Thread Brian May

On Wed, Aug 21, 2002 at 11:18:09AM -0600, Jason Gunthorpe wrote:
> If you do apt-cache show kerberos4kth1 after installing and look very
> carefully you will see that the two listed 1.1-11-2 stanzas are subtly
> different. The problem is that your package file does not
> accurately reflect the contents of the .deb. That is all.

I claim though that it it should be identical to the .deb file, because
I ran dpkg-scanpackages on it myself, and haven't updated anything
since (besides, if I had updated something, the MD5sum check would fail
wouldn't it?)

Packages entry:

Package: kerberos4kth1
Version: 1.1-11-2
Priority: optional
Section: net
Maintainer: Mikael Andersson <[EMAIL PROTECTED]>
Architecture: all
Filename: ./pool/krb4/kerberos4kth1_1.1-11-2_all.deb
Size: 57786
MD5sum: 330d49310a3264f037875e06a1328458
Description: Dummy library package for Kerberos4 From KTH.
 This is a dummy package. It should be safe to remove it.
 installed-size: 76
 source: krb4

[504] [snoopy:unstable:bam] /home/ftp/pub/debian >dpkg -I 
./pool/krb4/kerberos4kth1_1.1-11-2_all.deb
 new debian package, version 2.0.
 size 57786 bytes: control archive= 701 bytes.
 288 bytes,10 lines  control  
 229 bytes, 3 lines  md5sums  
 281 bytes, 9 lines   *  postinst #!/bin/sh
 208 bytes, 7 lines   *  prerm#!/bin/sh
 Package: kerberos4kth1
 Version: 1.1-11-2
 Section: net
 Priority: optional
 Architecture: all
 Installed-Size: 76
 Maintainer: Mikael Andersson <[EMAIL PROTECTED]>
 Source: krb4
 Description: Dummy library package for Kerberos4 From KTH.
  This is a dummy package. It should be safe to remove it.

What is different?

I wildly speculate that apt-get is making the assumption that package
version 1.1-11-2 will be exactly the same regardless of where it was
downloaded from, and is comparing the deb file against the Packages
entry from the unused/wrong source (priority==-1).
-- 
Brian May <[EMAIL PROTECTED]>

Sympa package: Seeking for co-developers

2002-08-21 Thread Jérôme Marant


Hi,

  I'm seeking for co-developers who have some interests in the
  sympa mailing list manager. I'm currently not using it but
  I know very well about the package so I think I can still
  be helpful in maintaining future versions.

  People who
  1/ are running Sympa on their servers (***)
  2/ have already used Debconf for packaging
  3/ have basic Perl knowledge
  4/ have basic MySQL/PostgreSQL knowledge (admin)

  are welcome. Not all skills are required but the more the better,
  as usual.

  Please contact me if interested. Thanks in advance.

  Cheers,

-- 
Jérôme Marant

http://marant.org

xmmsarts

2002-08-21 Thread Chris Boyle

(d-devel please cc me, I'm not subscribed)

On Wed, 2002-08-21 at 13:03, Steven Gardner wrote:
> I am checking to see if you are planning to fix the package bug with
> xmmsarts and when you think you would have the fix done.

I'm a little stuck for bandwidth / a machine that isn't on KDE 3 yet
(i.e. has KDE 2's libarts-dev) at the moment. If someone wants to just
do this:

  * Put build-deps back to libarts-dev for the moment, as
libarts1(-dev) (i.e. KDE 3) doesn't seem to be in
unstable yet (closes: #153595)

i.e. put that one build-dep back to libarts-dev (>= 4:2.2.2-1), and NMU,
it would be much appreciated.

Thanks,

-- 
Chris Boyle - Debian Developer (cmb) - aewm++, sapphire, xmmsarts
GPG: B7D86E0F, MSN: [EMAIL PROTECTED], ICQ: 24151961,
AIM: kerneloops, Yahoo: kerneloops, IRC: cmb on openprojects.net

Re: orphaning most (of my) packages

2002-08-21 Thread Thorsten Sauter

Hello,

> libphp-adodb (a php database abstraction layer, required for 'acidlab')

I'll like to adopte the libphp-adodb package from you.

I have created the packages with the new upstream version. You can
download it from:
ftp://jade.viastore.de/debian/pool/main/libp/libphp-adodb/

All current outstanding bugs are fixed with this version.



So, if noone is interessted...


Bye
Thorsten


-- 
Thorsten Sauter
<[EMAIL PROTECTED]>

(Is there life after /sbin/halt -p?)



pgpCS1m6fa0ip.pgp
Description: PGP signature

Thank You!

2002-08-21 Thread Monster Acct

Thank you for submitting your information to Delta Dallas. Your resume
or
request for information has been forwarded to the appropriate person.
If, after review, it is determined that there is a good match between
your
skills and any current opportunities one of our Recruiters will be in
contact with you via email or telephone. 

Unfortunately, due to the high number of responses that we receive on a
daily basis we are not
able to respond to each and every query. If there is not an immediate
opportunity that matches your skills we will keep your information on
file.

Again, thank you for your interest.

Re: RFC: OpenLDAP and TLS/SSL

On Wed, 2002-08-21 at 19:13, Henrique de Moraes Holschuh wrote:
> On Wed, 21 Aug 2002, Torsten Landschoff wrote:
> > Just explain why it is the right thing to do. And I would like to stay
> > binary compatible with RedHat etc. if at all possible. 
> 
> Well, apps like to be able to use libsasl, and libldap.  They also like to
> use libc.  And libc uses nss, which often admins want to use with nss-ldap.
> 
> So libc ends up dlopening nss-ldap, that links to libldap, and through it,
> to libsasl.
> 
> Now, apps often want libsasl2.  ldap uses libsasl1.  nss segfaults. It is
> the same libdb2/libdb3 hell we had a while back.
> 
> The proper fix is to have libsasl with versioned symbols, libldap with
> versioned symbols (so that we don't go all over the same problem when
> libldap gets updated -- right now the problem is sasl, not libldap).
> 
> Every lib and app that links to sasl needs to be recompiled, btw. The idea
> of versioning libldap now is to reduce the amount of recompiling we would
> need when the next libldap comes.
This is an another problem that would be easily and compatibly solved by
my ELF extension (until the library gets properly fixed upstream).

Anyway we really need to implant into the library developers' brains the
concept that symbol names must be *globally* unique, not just unique to
filename and that they either put the version number in the symbol (e.g.
sasl1_explode vs. sasl2_explode) and use #define's to keep source
compatibility or they use GNU/Solaris versioned symbols.

We should also alert upstream of this kind of problems _before_ new
versions get released and binary compatibility makes them untouchable.



signature.asc
Description: This is a digitally signed message part

Re: When bind9 reinstalls, no db.root

On Wed, Aug 21, 2002 at 01:10:29PM -0700, Marc Singer wrote:
> On Wed, Aug 21, 2002 at 03:00:52PM -0500, Steve Greenland wrote:
> > To be, perhaps, a little more explicit: there are programs for which
> > the existence of an empty configuration file means something completely
> > different than a missing a configuration file[1]. Thus, for dpkg
> > conffile handling, removing a configuration file is a legitimate "edit".
> 
> It would help to have an example.  However, even if there is an
> example I don't see how db.root fits in this category.

Unfortunately there's no way for a package to override this aspect of
dpkg's conffile handling. It would have to be handled entirely in the
maintainer scripts in some different (and careful!) way.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: When bind9 reinstalls, no db.root

2002-08-21 Thread Oliver Kurth

On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote:
> On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote:
> > > > Sounds like you want dpkg --force-confmiss.
> > > 
> > > I wouldn't expect that since the documentation states:
> > > 
> > >  confmiss: Always install  a  missing  configuration
> > >   file.  This  is  dangerous, since it means not pre-
> > >   serving a change (removing) made to the file.
> > > 
> > > How could it be dangerous to install a *missing* configuration file?
> > 
> > If the default configuration data in the file do something you don't want.
> 
> For example...

autofs. First thing I do when I install autofs in at networked environmemt is
rm /etc/auto.*
because I want to use the NIS maps.

Greetings,
Oliver
-- 
Oliver Kurth
mailto:[EMAIL PROTECTED] http://leinekanal.de


pgps2x4kwT8dp.pgp
Description: PGP signature

Re: When bind9 reinstalls, no db.root

On Wed, Aug 21, 2002 at 03:00:52PM -0500, Steve Greenland wrote:
> On 21-Aug-02, 14:42 (CDT), Josip Rodin <[EMAIL PROTECTED]> wrote: 
> > On Wed, Aug 21, 2002 at 12:32:00PM -0700, Marc Singer wrote:
> > > How could it be dangerous to install a *missing* configuration file?
> > 
> > If the default configuration data in the file do something you don't want.
> > 
> 
> To be, perhaps, a little more explicit: there are programs for which
> the existence of an empty configuration file means something completely
> different than a missing a configuration file[1]. Thus, for dpkg
> conffile handling, removing a configuration file is a legitimate "edit".
> 

It would help to have an example.  However, even if there is an
example I don't see how db.root fits in this category.

Re: When bind9 reinstalls, no db.root

On Wed, Aug 21, 2002 at 10:04:28PM +0200, Josip Rodin wrote:
> On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote:
> > > > > Sounds like you want dpkg --force-confmiss.
> > > > 
> > > > I wouldn't expect that since the documentation states:
> > > > 
> > > >  confmiss: Always install  a  missing  configuration
> > > >   file.  This  is  dangerous, since it means not pre-
> > > >   serving a change (removing) made to the file.
> > > > 
> > > > How could it be dangerous to install a *missing* configuration file?
> > > 
> > > If the default configuration data in the file do something you don't want.
> > 
> > For example...
> 
> I don't know, but I know plenty of default configuration files that set
> something up. Maybe "dangerous" is a bit extreme choice of words, but the
> negative effect isn't implausible.

Without a single example, I don't see how installing a configuration
file where there is none can have *any* affect on the system.
Admittedly, replacing a configuration file may be undesirable.

Moreover, in this case, db.root is not really a configuration file.
It is more like a library.  If I ask for a package to be reinstalled,
most users will expect all of the programs and libraries to be
installed.  

Are you sure you agree that db.root should not be reinstalled with
bind's programs?

> 
> -- 
>  2. That which causes joy or happiness.

Re: When bind9 reinstalls, no db.root

2002-08-21 Thread Josip Rodin

On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote:
> > > > Sounds like you want dpkg --force-confmiss.
> > > 
> > > I wouldn't expect that since the documentation states:
> > > 
> > >  confmiss: Always install  a  missing  configuration
> > >   file.  This  is  dangerous, since it means not pre-
> > >   serving a change (removing) made to the file.
> > > 
> > > How could it be dangerous to install a *missing* configuration file?
> > 
> > If the default configuration data in the file do something you don't want.
> 
> For example...

I don't know, but I know plenty of default configuration files that set
something up. Maybe "dangerous" is a bit extreme choice of words, but the
negative effect isn't implausible.

-- 
 2. That which causes joy or happiness.

Re: When bind9 reinstalls, no db.root

2002-08-21 Thread Steve Greenland

On 21-Aug-02, 14:42 (CDT), Josip Rodin <[EMAIL PROTECTED]> wrote: 
> On Wed, Aug 21, 2002 at 12:32:00PM -0700, Marc Singer wrote:
> > How could it be dangerous to install a *missing* configuration file?
> 
> If the default configuration data in the file do something you don't want.
> 

To be, perhaps, a little more explicit: there are programs for which
the existence of an empty configuration file means something completely
different than a missing a configuration file[1]. Thus, for dpkg
conffile handling, removing a configuration file is a legitimate "edit".

Steve

[1] E.g. /etc/cron.allow (crontab(1)).

-- 
Steve Greenland

The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: When bind9 reinstalls, no db.root

On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote:
> > > Sounds like you want dpkg --force-confmiss.
> > 
> > I wouldn't expect that since the documentation states:
> > 
> >  confmiss: Always install  a  missing  configuration
> >   file.  This  is  dangerous, since it means not pre-
> >   serving a change (removing) made to the file.
> > 
> > How could it be dangerous to install a *missing* configuration file?
> 
> If the default configuration data in the file do something you don't want.

For example...

Re: When bind9 reinstalls, no db.root

2002-08-21 Thread Josip Rodin

On Wed, Aug 21, 2002 at 12:32:00PM -0700, Marc Singer wrote:
> > > I'm confused by the behavior of apt-get install --reinstall.  I found
> > > out yesterday that the /etc/bind/db.root file was missing on my name
> > > server.  I was able to recover by linking to an old copy and
> > > restarting bind9.  However, when deleted the link and performed the
> > > --reinstall command, the db.root file was not restored.
> > 
> > Sounds like you want dpkg --force-confmiss.
> 
> I wouldn't expect that since the documentation states:
> 
>  confmiss: Always install  a  missing  configuration
>   file.  This  is  dangerous, since it means not pre-
>   serving a change (removing) made to the file.
> 
> How could it be dangerous to install a *missing* configuration file?

If the default configuration data in the file do something you don't want.

-- 
 2. That which causes joy or happiness.

Re: When bind9 reinstalls, no db.root

On Wed, Aug 21, 2002 at 08:24:58PM +0100, Colin Watson wrote:
> On Wed, Aug 21, 2002 at 12:09:57PM -0700, Marc Singer wrote:
> > I'm confused by the behavior of apt-get install --reinstall.  I found
> > out yesterday that the /etc/bind/db.root file was missing on my name
> > server.  I was able to recover by linking to an old copy and
> > restarting bind9.  However, when deleted the link and performed the
> > --reinstall command, the db.root file was not restored.
> 
> Sounds like you want dpkg --force-confmiss.

I wouldn't expect that since the documentation states:

 confmiss: Always install  a  missing  configuration
  file.  This  is  dangerous, since it means not pre-
  serving a change (removing) made to the file.

How could it be dangerous to install a *missing* configuration file?

Re: When bind9 reinstalls, no db.root

On Wed, Aug 21, 2002 at 12:09:57PM -0700, Marc Singer wrote:
> I'm confused by the behavior of apt-get install --reinstall.  I found
> out yesterday that the /etc/bind/db.root file was missing on my name
> server.  I was able to recover by linking to an old copy and
> restarting bind9.  However, when deleted the link and performed the
> --reinstall command, the db.root file was not restored.

Sounds like you want dpkg --force-confmiss.

-- 
Colin Watson  [EMAIL PROTECTED]

When bind9 reinstalls, no db.root

I'm confused by the behavior of apt-get install --reinstall.  I found
out yesterday that the /etc/bind/db.root file was missing on my name
server.  I was able to recover by linking to an old copy and
restarting bind9.  However, when deleted the link and performed the
--reinstall command, the db.root file was not restored.  I verified
that the file exists in the bind9 DEB and, in fact, is listed in the
bind9.list file.

My question is this.  How can the reinstall fail to install the file
when there is no extant file with the same name?

Re: RFC: OpenLDAP and TLS/SSL

2002-08-21 Thread Marco d'Itri

On Aug 21, Colin Watson <[EMAIL PROTECTED]> wrote:

 >Now that we have crypto in main, I think we should have fewer -ssl
 >packages, not more.
Agreed.

-- 
ciao,
Marco

Re: /bin/login hanging around

2002-08-21 Thread kcr

Russell Coker <[EMAIL PROTECTED]> writes:

> Why is it that /bin/login seems to hang around for the duration of the user's 
> session on other distributions but not on Debian?

Traditional Unix does it the we way do; login exec's the user's shell, etc.
Other distributions seem to come with whiz-bang pam modules that need to do
cleanup on logout, so login forks to run pam_close_session().; we don't
configure things like that by default. 

If you love the other distribution's behavior, set CLOSE_SESSIONS to yes in
/etc/login.defs.

This may become a default in future versions of the shadow package.

kcr

Keysigning/Meet in Italy

2002-08-21 Thread Brett Cundal

Hi all,

I'll be travelling in Italy for a few weeks this September and I
thought it might be fun to meet some Debian developers there for
coffee and keysigning. Reply off-list if interested. Thanks!

-- Brett


pgplcBE5su1fw.pgp
Description: PGP signature

Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System

2002-08-21 Thread Christian Marillat

Marc Leeman <[EMAIL PROTECTED]> writes:

[...]

> And yes, I am in trouble, most of the packages that ITP (mostly video
> related) depend on lame.

Marc ask in -legal.

Christian

Re: apt-get wants to upgrade package to same version?

2002-08-21 Thread Jason Gunthorpe

On Wed, 21 Aug 2002, Brian May wrote:

> On Tue, Aug 20, 2002 at 11:19:13PM -0600, Jason Gunthorpe wrote:
> > > apt-get knows that it has to get the file from:
> > > 
> > > deb http://snoopy.apana.org.au/~ftp/debian woody main
> > > 
> > > and the md5sum of the Packages file from this source, as quoted
> > > before matches exactly.
> > 
> > Er, the md5sum of the deb is not kept by dpkg after you install a .deb.

> This MD5sum matches that of the file on the server, exactly:

Just ignore the md5sum, it isn't (can't be!) used for anything like this.

If you do apt-cache show kerberos4kth1 after installing and look very
carefully you will see that the two listed 1.1-11-2 stanzas are subtly
different. The problem is that your package file does not
accurately reflect the contents of the .deb. That is all.

Jason

Re: orphaning most (of my) packages

2002-08-21 Thread Mako Hill

> razor ('needed' by spamasassin; needs updating)

I've check out the bug list and the package and I'd like to take this
on unless some more qualified wants it.

-- 
B. Mako Hill
[EMAIL PROTECTED]
http://people.debian.org/~mako/



pgpMmajL0klnq.pgp
Description: PGP signature

Re: How to transition to G++ 3.2 wthout any breakage

2002-08-21 Thread Davide Inglima - limaCAT

On Sunday 18 August 2002 20:36, Chris Cheney wrote:
> On Sun, Aug 18, 2002 at 06:09:18PM +0200, Luca Barbieri wrote:

>> For example, how about calc.cx KDE 3.0 packages that are obviously
>> necessary for any KDE user? I don't see any mention of GCC 3.2 on their
>> text file so I assume that they aren't ported.

> Why is KDE 3.0 obviously necessary for any KDE user? 

Not strictly necessary but it could be good :)
My very very short list: getting back from Kde 2.3 (on Kondara) to Kde 2.2
was painful because 2.3 had...

1) Features
Better CSS support in Konqueror
Kmail allowed you to have fonts for all the headers
Konqueror didn't break loading pages without an .htm or .html extension

2) Bugfixes
Anti-alias didn't break down randomly (and in konsole as well)
Font support didn't break down randomly giving you fonts you don't want
Konsole (IIRC) didn't left "dirty spots" on the screen using anti-aliased 
fonts

I admit that Debian Kde mantainer did a very good job, since this is
the most stable install of Kde 2.2 I've ever seen (Kde 2.2's kicker from
Mandrake did crash one day yes and the second too as well, forcing me to
restart it via alt-f2).

Anyway, that's only a list for which any kde user could appreciate a 
supplement of woody packages with the latest release of kde :), actually
using Kde 2.2 is good enough.

-- 
   Davide Inglima - limaCAT
 "Mana is rapidly disappearing from the World, even the"
   "Mana Tree has begun to wither" - Seiken Densetsu 3
   http://digilander.iol.it/nekochan/

Re: RFC: OpenLDAP and TLS/SSL

On Wed, 21 Aug 2002, Torsten Landschoff wrote:
> Just explain why it is the right thing to do. And I would like to stay
> binary compatible with RedHat etc. if at all possible. 

Well, apps like to be able to use libsasl, and libldap.  They also like to
use libc.  And libc uses nss, which often admins want to use with nss-ldap.

So libc ends up dlopening nss-ldap, that links to libldap, and through it,
to libsasl.

Now, apps often want libsasl2.  ldap uses libsasl1.  nss segfaults. It is
the same libdb2/libdb3 hell we had a while back.

The proper fix is to have libsasl with versioned symbols, libldap with
versioned symbols (so that we don't go all over the same problem when
libldap gets updated -- right now the problem is sasl, not libldap).

Every lib and app that links to sasl needs to be recompiled, btw. The idea
of versioning libldap now is to reduce the amount of recompiling we would
need when the next libldap comes.

As for RH, we should get them to version their libs exactly as we would be
doing as well. Same for the LSB requirements.  Versioning symbols is
backwards-compatible:  stuff compiled against non-versioned libs will work
with the versioned ones.

However, stuff compiled against the versioned libs will want a lib with that
exact versioning, and it will not accept the non-versioned libs AFAIK.

The versioning should use the soname, so that we avoid symbol clashes with
other versions of the same libs, AND with other libs as well.  This is how
glibc does it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: RFC: OpenLDAP and TLS/SSL

2002-08-21 Thread Torsten Landschoff

Hi Henrique, 

On Wed, Aug 21, 2002 at 12:16:38PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 21 Aug 2002, Torsten Landschoff wrote:
> > Today I was convinced by Stephen Frost that I can just enable SSL support
> > in the OpenLDAP packages I maintain. No problem so far, but:
> 
> What can I do to convince you that you need to help me convince the SASL
> maintainer to have versioned symbols so that LDAP can use SASL as well
> without segfaulting every damn system using ldap-nss?  And of course,
> version the LDAP symbols as well right now so that at the next LDAP soname
> change, we don't have ldap causing the trouble sasl is causing now?

Just explain why it is the right thing to do. And I would like to stay
binary compatible with RedHat etc. if at all possible. 

cu
Torsten


pgpd9XmgOWa2h.pgp
Description: PGP signature

Re: RFC: OpenLDAP and TLS/SSL

2002-08-21 Thread Torsten Landschoff

On Wed, Aug 21, 2002 at 03:52:12PM +0200, Oliver Kurth wrote:

> Hi Torsten :-)

Hi Oliver :)

> I would suggest that you make an extra -ssl package, along the lines of
> eg. fetchmai{,-ssl}l. It reduces dependencies and solves your problem. Maybe
> people want ldap, but not ssl.

I also like that solution better but it has the drawback of getting 
openssl into the base system and I really would like to have a GPL
compatible library there in the long run...

Thanks for your comments

Torsten

pgpJGFDA3owfl.pgp
Description: PGP signature

RE: CST81669854ID - A special excite game

2002-08-21 Thread MSN Customer Support

Thank you for your e-mail message to MSN webmaster. We would like to assist you with your question and request you go to the appropriate link below for the product you are inquiring about. The link will take you directly to that product’s online help with instructions on how you may contact us directly. This will provide you the timeliest response. For MSN Internet Access, go to http://supportservices.msn.com/us/help.asp. For Hotmail, go to http://www.hotmail.com, then click “Help” on the upper middle part of your screen. For MSN Messenger, go to http://messenger.microsoft.com, select the applicable Messenger client on the left navigation bar, then click "Help." For MSN Gaming Zone, go to http://support.microsoft.com/directory/content.asp?ID=FH;EN-US;gmz. For MSN MoneyCentral, go to http://support.microsoft.com/directory/content.asp?ID=FH;EN-US;mnyc&SD=GN&FR=0&LN=EN-US. For Microsoft Passport, go to http://www.passport.com/Consumer/ConsumerQA.asp?lc=1033. For Microsoft software applications such as Office or Windows, go to http://support.microsoft.com/directory/. For MSN Web Communities, Member Directory or support for files you have saved to MSN, go to http://communities.msn.com/home, then click “Help” on the upper middle part of your screen. For MSN Chat, go to http://chat.msn.com/default.msnw, then click “Help” on the upper middle part of your screen. For bCentral, go to http://www.bcentral.com/help/overview.asp. For MSNBC, go to http://www.msnbc.com/m/info/help.asp. For help with MSN.com, MSN Search or any other MSN property not mentioned above, go to http://www.msn.com, then click “Help” on the upper right-hand part of your screen. This is an unmonitored e-mail address so please be sure to go to one of the links above.We value your business and thank you for using the Microsoft network of web sites.--- Original Message --- From: debian-devel-announce@lists.debian.org To: [EMAIL PROTECTED] Sent: Aug 20 2002 9:10PM Subject: A special excite gameThis is a special excite gameThis game is my first work.You're the first player.I wish you would enjoy it.

Re: RFC: OpenLDAP and TLS/SSL

On Wed, 21 Aug 2002, Stephen Frost wrote:
>   I do wonder though why there is a fetchmail/fetchmail-ssl, is there
>   some good justification for keeping them seperate now that we have
>   crypto-in-main?

Just the fact that I have all but orphaned it and will not spend time
joining the two packages right now. RFA bug is in the BTS...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: RFC: OpenLDAP and TLS/SSL

On Wed, 21 Aug 2002, Torsten Landschoff wrote:
> Today I was convinced by Stephen Frost that I can just enable SSL support
> in the OpenLDAP packages I maintain. No problem so far, but:

What can I do to convince you that you need to help me convince the SASL
maintainer to have versioned symbols so that LDAP can use SASL as well
without segfaulting every damn system using ldap-nss?  And of course,
version the LDAP symbols as well right now so that at the next LDAP soname
change, we don't have ldap causing the trouble sasl is causing now?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

OpenSSL-linked exim

2002-08-21 Thread J.H.M. Dassen \(Ray\)

On Wed, Aug 21, 2002 at 16:19:48 +0200, Florian Weimer wrote:
> Exim is GPL, so the author currently does not allow the distribution of
> binaries which also contain OpenSSL code.

Quoting the NOTICE file from the Exim 3.36 source:
:Copyright (c) 1999 University of Cambridge
:
:This program is free software; you can redistribute it and/or modify it
:under the terms of the GNU General Public License as published by the Free
:Software Foundation; either version 2 of the License, or (at your option)
:any later version.
:
:In addition, for the avoidance of any doubt, permission is granted to link
:this program with OpenSSL or any other library package.

This seems to be intended as the kind of exception statement Debian needs in
order to be able to include OpenSSL-linked exim binaries (or
OpenLDAP-linked-against-OpenSSL exim binaries) in its main archive, although
people on debian-legal would probably point out that this doesn't spell out
permission to redistribute the result of such linking.

Philip, if I recall correctly, previous discussions on debian-legal have
resulted in a recommended phrasing for such an exception statement
(unfortunately, I can't seem to find a link for it at the moment); would you
please consider getting the NOTICE updated along the lines of that phrasing
so as to make it clear that redistribution of OpenSSL-linked exim binaries
is allowed?

Ray
-- 
"Perhaps they spent some of the time writing the patent application. That
task was surely harder than thinking of the technique."
RMS on Amazon's 1-Click(R) patent,
http://linuxtoday.com/story.php3?sn=13652

Re: RFC: OpenLDAP and TLS/SSL

2002-08-21 Thread Oliver Kurth

On Wed, Aug 21, 2002 at 03:05:48PM +0100, Colin Watson wrote:
> On Wed, Aug 21, 2002 at 03:52:12PM +0200, Oliver Kurth wrote:
> > On Wed, Aug 21, 2002 at 03:18:38PM +0200, Torsten Landschoff wrote:
> > > So - what should I do to handle this? Can the priority of libssl0.9.6 be
> > > easily changed? Or should I rather provide libldap2{,-ssl}? Technically
> > > it would not be a big deal since the interface of libldap2 does not
> > > change if you enable ssl. Also I wonder if a slapd package without 
> > > ssl would be in order. After all there are still people using Debian
> > > who are not allowed to import all that crypto stuff from the US.
> > 
> > I would suggest that you make an extra -ssl package, along the lines
> > of eg. fetchmai{,-ssl}l. It reduces dependencies and solves your
> > problem. Maybe people want ldap, but not ssl.
> 
> Now that we have crypto in main, I think we should have fewer -ssl
> packages, not more.

Alright, if this is consensus.

Greetings,
Oliver
-- 
debian/rules   http://zork.net/~nick/srom/


pgpEdmy7OQgov.pgp
Description: PGP signature

Re: RFC: OpenLDAP and TLS/SSL

2002-08-21 Thread Florian Weimer

Tore Anderson <[EMAIL PROTECTED]> writes:

> As far as I know, exim is the only package with priority: important that
> depend on libldap2.

Exim is GPL, so the author currently does not allow the distribution
of binaries which also contain OpenSSL code.

-- 
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT  fax +49-711-685-5898

Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System

> But you will lose a lot of fonctionnalities. This is the main reason
> I've never did an ITP for ffmpeg.

Yep, it's the same with nvrec. But I discussed this with my mentor, and
we're still not clear on this: if a package needs linking with some
troublesome package, does this break the DFSG?

I guess it depends if you consider "the software" as "the source" or
"the binary".

> > but since nvrec requires mp3lame I am trouble anyway ;)
> BTW the video codecs (MPEG4, MSMPEG4) are DFSG compliant ?

depends, unless an xvid version is written, cf. previous point.

In practice, this would mean that _anything_ that uses a lame call is
not fitted for debian?

And yes, I am in trouble, most of the packages that ITP (mostly video
related) depend on lame.


-- 
greetz, marc
 
Did you pay the new Support Fee?
 Key fingerprint = 890C E47F 1589 F240 9CC8  C60C 510A 63D3 D356 2DE1
Linux mykene 2.4.19-pre4 #1 Tue Apr 2 22:47:06 CEST 2002 i686 unknown


pgpsjiBzVLcmG.pgp
Description: PGP signature

ELF extension for starting symbol search from module dependencies

This is a proposal (including patches) for a GNU extension to the ELF
executable format that adds a flag that causes the dynamic loader to
start searching for symbols referenced by modules with the flag set from
the module itself and its immediate dependencies. If the symbol is not
found in this way, the dynamic linker continues the search as usual. 

This extension would be useful to allow to load in the same address
space multiple libraries that define identical symbols, that would be
used by different modules possibly unaware of each other's use of such
symbols. 

As a practical example, libpng.so.2 and libpng.so.3 define several
symbols with identical names. 
With the current ELF format, other libraries that want to use libpng
symbols will use the symbols of the libpng library that is used by the
main program rather than the one they are compiled with. 
Since GTK+ 2.0 uses libpng, this causes a major problem since GTK+
application must be recompiled to use the same libpng version that GTK+
uses. 
With this extension, GTK+ could be recompiled with the new flag set and
this problem would be solved. 

The extension is implemented using bit 0 of the value attached to the
DT_SYMBOLIC dynamic section entry. Current versions of the GNU dynamic
loader ignore this value and thus consider the object like one compiled
with the -Bsymbolic option. 

An option is added to the GNU linker to allow it to produce executables
with the flag set. The proposed name for the option is -Blocal. 
This option is treated like -Bsymbolic, but will cause the value
attached to the DT_SYMBOLIC entry to be written as 1 rather than 0. 

The attached patches implement the two modifications. The libc patch
also changes the -Bsymbolic list to be statically allocated rather than
malloc'ed and leaked. 


Patch for GNU binutils:

--- a/bfd/elflink.h 2002-07-17 20:38:29.0 +0200
+++ b/bfd/elflink.h 2002-08-21 15:27:17.0 +0200
@@ -3042,7 +3042,7 @@ NAME(bfd_elf,size_dynamic_sections) (out
   if (info->symbolic)
{
  if (! elf_add_dynamic_entry (info, (bfd_vma) DT_SYMBOLIC,
-  (bfd_vma) 0))
+  (bfd_vma) (info->local ? 1 : 0)))
return false;
  info->flags |= DF_SYMBOLIC;
}
--- a/include/bfdlink.h 2002-07-17 20:38:29.0 +0200
+++ b/include/bfdlink.h 2002-08-21 15:27:58.0 +0200
@@ -216,6 +216,10 @@ struct bfd_link_info
   /* true if BFD should pre-bind symbols in a shared object.  */
   boolean symbolic;
 
+  /* true if BFD should pre-bind symbols in a shared object and tell
+ dynamic linker to start searching from local dependencies.  */
+  boolean local;
+   
   /* true if BFD should export all symbols in the dynamic symbol table
  of an executable, rather than only those used.  */
   boolean export_dynamic;
--- a/ld/ldmain.c   2002-07-17 20:38:29.0 +0200
+++ b/ld/ldmain.c   2002-08-21 15:27:08.0 +0200
@@ -234,6 +234,7 @@ main (argc, argv)
   link_info.emitrelocations = false;
   link_info.shared = false;
   link_info.symbolic = false;
+  link_info.local = false;  
   link_info.export_dynamic = false;
   link_info.static_link = false;
   link_info.traditional_format = false;
--- a/ld/lexsup.c   2002-05-24 00:10:11.0 +0200
+++ b/ld/lexsup.c   2002-08-21 15:26:52.0 +0200
@@ -133,6 +133,7 @@ int parsing_defsym = 0;
 #define OPTION_NO_DEFINE_COMMON(OPTION_SPARE_DYNAMIC_TAGS + 1)
 #define OPTION_NOSTDLIB(OPTION_NO_DEFINE_COMMON + 1)
 #define OPTION_MULTILIB_DIR(OPTION_NOSTDLIB + 1)
+#define OPTION_LOCAL   (OPTION_MULTILIB_DIR + 1)
 
 /* The long options.  This structure is used for both the option
parsing and the help text.  */
@@ -283,6 +284,8 @@ static const struct ld_option ld_options
   '\0', NULL, NULL, ONE_DASH },
   { {"Bsymbolic", no_argument, NULL, OPTION_SYMBOLIC},
   '\0', NULL, N_("Bind global references locally"), ONE_DASH },
+  { {"Blocal", no_argument, NULL, OPTION_LOCAL},
+  '\0', NULL, N_("Bind global references locally and start searching from 
local dependencies"), ONE_DASH },  
   { {"check-sections", no_argument, NULL, OPTION_CHECK_SECTIONS},
   '\0', NULL, N_("Check section addresses for overlaps (default)"), 
TWO_DASHES },
   { {"no-check-sections", no_argument, NULL, OPTION_NO_CHECK_SECTIONS},
@@ -924,6 +927,10 @@ parse_args (argc, argv)
case OPTION_SYMBOLIC:
  link_info.symbolic = true;
  break;
+   case OPTION_LOCAL:
+ link_info.symbolic = true;
+ link_info.local = true;
+ break;  
case 't':
  trace_files = true;
  break;


Patch for GNU libc:

--- a/elf/dl-deps.c 2001-09-21 16:52:54.0 +0200
+++ b/elf/dl-deps.c 2002-08-21 14:55:17.0 +0200
@@ -261,7 +261,8 @@ _dl_map_object_deps (struct link_map *ma

Re: RFC: OpenLDAP and TLS/SSL

On Wed, Aug 21, 2002 at 03:52:12PM +0200, Oliver Kurth wrote:
> On Wed, Aug 21, 2002 at 03:18:38PM +0200, Torsten Landschoff wrote:
> > So - what should I do to handle this? Can the priority of libssl0.9.6 be
> > easily changed? Or should I rather provide libldap2{,-ssl}? Technically
> > it would not be a big deal since the interface of libldap2 does not
> > change if you enable ssl. Also I wonder if a slapd package without 
> > ssl would be in order. After all there are still people using Debian
> > who are not allowed to import all that crypto stuff from the US.
> 
> I would suggest that you make an extra -ssl package, along the lines
> of eg. fetchmai{,-ssl}l. It reduces dependencies and solves your
> problem. Maybe people want ldap, but not ssl.

Now that we have crypto in main, I think we should have fewer -ssl
packages, not more.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: RFC: OpenLDAP and TLS/SSL

2002-08-21 Thread Stephen Frost

* Oliver Kurth ([EMAIL PROTECTED]) wrote:
> On Wed, Aug 21, 2002 at 03:18:38PM +0200, Torsten Landschoff wrote:
> > - libldap2 is Priority: important
> > - this change will make it depend on libssl0.9.6
> > - libssl0.9.6 is Priority: standard
> 
> I would suggest that you make an extra -ssl package, along the lines of
> eg. fetchmai{,-ssl}l. It reduces dependencies and solves your problem. Maybe
> people want ldap, but not ssl.

Oliver,

  Personally I think we should do our best to avoid the ssl vs.
  non-ssl dual packages.  I think much of the point of crypto-in-main
  was to do away with having so many dual packages.

  I do wonder though why there is a fetchmail/fetchmail-ssl, is there
  some good justification for keeping them seperate now that we have
  crypto-in-main?

Thanks,

Stephen

pgpNdJz5f8OpA.pgp
Description: PGP signature

Re: png2/3 problem apparently successfully solved with -Bsymbolic

2002-08-21 Thread Daniel Jacobowitz

On Wed, Aug 21, 2002 at 12:04:40AM +0200, Luca Barbieri wrote:
> On Tue, 2002-08-20 at 23:56, Henrique de Moraes Holschuh wrote:
> > On Tue, 20 Aug 2002, Luca Barbieri wrote:
> > > On Tue, 2002-08-20 at 23:28, Henrique de Moraes Holschuh wrote:
> > > > On Tue, 20 Aug 2002, Luca Barbieri wrote:
> > > > > Why?
> > > > > Can't we just use it in Debian?
> > > > 
> > > > Are you mad? What happens if the ELF format or gnu upstream start using 
> > > > that
> > > > value for something else?
> > > We notify them of the problem.
> > > Furthermore the patch can be immediately sent to the glibc maintainers.
> > 
> > This is sort of like asking your wife if she did not like the new color you
> > paint*ed* the entire house with.
> But that field has at least 32 bits and anyway there are other place
> where extensions could be put so it's just a matter of having them put
> the extension in another place.
> 
> So yes, it is equivalent to declaring ownership of bit 0 of the
> DT_SYMBOLIC value but I don't think this will piss anyone off especially
> given the comment from GNU endorsing an extension like this.

The comment is old.  I don't think that attitude is current.  I suspect
that Ulrich will not look kindly at this sort of local linker hackery. 
And, yet again, you're ignoring the technical
implementation/maintenance burden of such a patch.

There will be _NO_ local linker hacks of this nature in Debian.  Drop
it.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Re: RFC: OpenLDAP and TLS/SSL

2002-08-21 Thread Stephen Frost

* Torsten Landschoff ([EMAIL PROTECTED]) wrote:
> Today I was convinced by Stephen Frost that I can just enable SSL support
> in the OpenLDAP packages I maintain. No problem so far, but:
> 
> - libldap2 is Priority: important
> - this change will make it depend on libssl0.9.6
> - libssl0.9.6 is Priority: standard
[...]
> Any suggestions welcome

Hey all,

  I already explained my feelings about this to Torsten but since we're
  moving it to -devel I'll lay out my thoughts here too.

  First off, crypto is important to us and I think we tend to feel that
  it is important for our users as well.  Thus, I see libssl0.9.6 being
  made Priority: Important as a good option.

  If there are too many other issues with making libssl0.9.6 important
  (though it only Depends: on libc and isn't very big?) then I would
  think that we are very concerned about the size and would therefore
  recommend that ldap support be removed from exim or exim be split into
  exim-tiny for Important and exim-big with everything enabled.  Of
  course, exim support being modified to be modular would be an
  excellent option but would require a decent amount of work I think.

  Not having any exim with support for mysql in Debian has been a
  problem in the past for Debian users that I know.

Thanks,

Stephen

pgp7KPVnPkPak.pgp
Description: PGP signature

Re: RFC: OpenLDAP and TLS/SSL

2002-08-21 Thread Tore Anderson

Torsten Landschoff <[EMAIL PROTECTED]> writes:

> Today I was convinced by Stephen Frost that I can just enable SSL support
> in the OpenLDAP packages I maintain. No problem so far, but:
> 
> - libldap2 is Priority: important
> - this change will make it depend on libssl0.9.6
> - libssl0.9.6 is Priority: standard
> 
> So - what should I do to handle this? Can the priority of libssl0.9.6 be
> easily changed? Or should I rather provide libldap2{,-ssl}? Technically
> it would not be a big deal since the interface of libldap2 does not
> change if you enable ssl. Also I wonder if a slapd package without 
> ssl would be in order. After all there are still people using Debian
> who are not allowed to import all that crypto stuff from the US.

As far as I know, exim is the only package with priority: important that
depend on libldap2. Howevery, the basic configuration generated by exim's
postinst doesn't use the LDAP functionality (AFAIK). So, I think exim
should be fixed so that it doesn't depend on libldap2 anymore.

Then lildap2 wouldn't need to be important anymore - your problem
would be solved, and base would shrink. :)

We could instead have an exim-bloated package with full
LDAP/MySQL/PostgreSQL/SSL functionality as priority extra.

-- 
Tore Anderson

Re: RFC: OpenLDAP and TLS/SSL

2002-08-21 Thread Oliver Kurth

On Wed, Aug 21, 2002 at 03:18:38PM +0200, Torsten Landschoff wrote:
> Hi *, 

Hi Torsten :-)

> 
> Today I was convinced by Stephen Frost that I can just enable SSL support
> in the OpenLDAP packages I maintain. No problem so far, but:
> 
> - libldap2 is Priority: important
> - this change will make it depend on libssl0.9.6
> - libssl0.9.6 is Priority: standard
> 
> So - what should I do to handle this? Can the priority of libssl0.9.6 be
> easily changed? Or should I rather provide libldap2{,-ssl}? Technically
> it would not be a big deal since the interface of libldap2 does not
> change if you enable ssl. Also I wonder if a slapd package without 
> ssl would be in order. After all there are still people using Debian
> who are not allowed to import all that crypto stuff from the US.

I would suggest that you make an extra -ssl package, along the lines of
eg. fetchmai{,-ssl}l. It reduces dependencies and solves your problem. Maybe
people want ldap, but not ssl.

Greetings,
Oliver
-- 
debian/rules   http://zork.net/~nick/srom/


pgpwnehOIJqbw.pgp
Description: PGP signature

RFC: OpenLDAP and TLS/SSL

2002-08-21 Thread Torsten Landschoff

Hi *, 

Today I was convinced by Stephen Frost that I can just enable SSL support
in the OpenLDAP packages I maintain. No problem so far, but:

- libldap2 is Priority: important
- this change will make it depend on libssl0.9.6
- libssl0.9.6 is Priority: standard

So - what should I do to handle this? Can the priority of libssl0.9.6 be
easily changed? Or should I rather provide libldap2{,-ssl}? Technically
it would not be a big deal since the interface of libldap2 does not
change if you enable ssl. Also I wonder if a slapd package without 
ssl would be in order. After all there are still people using Debian
who are not allowed to import all that crypto stuff from the US.

Any suggestions welcome

Torsten


pgpOXeElrL3N9.pgp
Description: PGP signature

Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System

2002-08-21 Thread Aaron Lehmann

On Wed, Aug 21, 2002 at 03:10:05PM +0200, Marc Leeman wrote:
> > Are you aware that ffmpeg need lame ?
> yes and no:
> 
> yes I am aware of that 
>   and
> no not "need"
> 
> --enable-mp3lame) mp3lame="yes"
> (the default is "no")
> 
> but since nvrec requires mp3lame I am trouble anyway ;)

Well lame isn't included in the distribution because of patent problems

And the same patents (and other ones) cover ffmpeg, which can encode
(among other things) AC3, MPEG1 video, MPEG4, and MPEG 1 layer 2 audio.

So it looks like either way you're in trouble.

Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System

2002-08-21 Thread Christian Marillat

Marc Leeman <[EMAIL PROTECTED]> writes:

> Are you aware that ffmpeg need lame ?
> yes and no:

> yes I am aware of that 
>   and
> no not "need"

> --enable-mp3lame) mp3lame="yes"
> (the default is "no")

But you will lose a lot of fonctionnalities. This is the main reason
I've never did an ITP for ffmpeg.

> but since nvrec requires mp3lame I am trouble anyway ;)

BTW the video codecs (MPEG4, MSMPEG4) are DFSG compliant ?

Christian

[buildd] brltty

2002-08-21 Thread Mario Lang

Hello.

I noticed that buildd doesn't build brltty since 2.98-2.

Well, I know I originally just had i386 in the architecture field, but 
I am currently working with the upstream maintainer to
fix alot of different architectures, and it would be nice
if buildd could build brltty again on all archs listed in
the architecture field.

Could anyone tell me what to do to achieve this again,
or whom to write about it?

-- 
CYa,
  Mario

Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System

> Are you aware that ffmpeg need lame ?
yes and no:

yes I am aware of that 
and
no not "need"

--enable-mp3lame) mp3lame="yes"
(the default is "no")

but since nvrec requires mp3lame I am trouble anyway ;)

-- 
greetz, marc
 
We need a licensed electrician to replace the light bulbs in the computer room.
 Key fingerprint = 890C E47F 1589 F240 9CC8  C60C 510A 63D3 D356 2DE1
Linux mykene 2.4.19-pre4 #1 Tue Apr 2 22:47:06 CEST 2002 i686 unknown


pgpEvAmNZgWLD.pgp
Description: PGP signature

Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System

> A lot of the code in ffmpeg is within the 'libavcodec' subdirectory,
> and this code has been incorporated by several other projects (xine
> and mplayer are all I can think of right now). I know that the libxine
> source, at least on the debian servers, contains a copy of libavcodec.
> Perhaps a dynamic libavcodec library should be built from the ffmpeg
> sources and packages like xine could link against it.

Well, I decided that I could not use the version of Christian because it
was to old, but used his configuration to recompile with a latest
snapshot.

libavcodec and libavformat are now dinamically linked in nvrec (instead
of included in the project). I'll see if there are no recording
problems and if not, report the changes to upstream.

libavformat was not compiled as a shlib in the original sources.

Since Christian is basically maintaining the package, I'll confer with
him about the best approach, I won't "branch" the package.

-- 
   greetz, marc
 
BOFH excuse #73:

Daemons did it
pgp Key ID: 0xD3562DE1
 Key fingerprint = 890C E47F 1589 F240 9CC8  C60C 510A 63D3 D356 2DE1
Linux scorpius 2.4.19-rc3 #2 Thu Aug 1 05:23:31 CEST 2002 GNU/Linux


pgpSqrcgMNXUz.pgp
Description: PGP signature

Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System

2002-08-21 Thread Christian Marillat

"Marc Leeman" <[EMAIL PROTECTED]> writes:

> Package: wnpp
> Version: N/A; reported 2002-08-21
> Severity: wishlist

> * Package name: ffmpeg
>   Version : 0.46
>   Upstream Author : Fabrice Bellard <[EMAIL PROTECTED]>
> * URL : http://ffmpeg.sourceforge.net/
> * License : LGPL
>   Description : FFmpeg Streaming Multimedia System

Are you aware that ffmpeg need lame ?

Christian

 $ dlocate -s libffmpeg0
Package: libffmpeg0
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 552
Maintainer: Christian Marillat <[EMAIL PROTECTED]>
Source: ffmpeg
Version: 0.4.6cvs20020521-0.0
Depends: libc6 (>= 2.2.4-4), liblame0 (>= 3.91-0.1)

Re: orphaning most (of my) packages

2002-08-21 Thread Robert van der Meulen


Quoting Ivo Timmermans ([EMAIL PROTECTED]):
> I would like to take over your ITP for cryptoapi.  If noone else wants
> it, I can take kernel-patch-int too.

As discussed yesterday night; they're yours.

Greets,
Robert

-- 
( o>  Linux Generation

Re: orphaning most (of my) packages

2002-08-21 Thread Robert van der Meulen


Quoting Peter Palfrader ([EMAIL PROTECTED]):
> Please retitle them to RFP (request for package) rather than closing
> them if you still think they'ld make a worthwhile addition to Debian.

Thanks, good point :)

Greets,
Robert
-- 
( o>  Linux Generation  

pgp4T6dYieG6z.pgp
Description: PGP signature

Bug#157729: ITP: gatos-drm-source -- DRM modules source from the GATOS project, with support for recent ATI chips

2002-08-21 Thread Yann Dirson

Package: wnpp
Version: N/A; reported 2002-08-19
Severity: wishlist

* Package name: gatos-drm-source
  Version : 1.2.0-14
  Upstream Author : Vladimir Dergachev
* URL : http://sourceforge.net/projects/gatos
* License : GPL and additional rights
  Description : DRM modules source from the GATOS project, with support for 
recent ATI chips

-- 
Yann Dirson <[EMAIL PROTECTED]> http://www.alcove.com/
Technical support managerResponsable de l'assistance technique
Senior Free-Software Consultant  Consultant senior en Logiciels Libres
Debian developer ([EMAIL PROTECTED])Développeur Debian

Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System

> FYI, Christian Marillat has already some ffmpeg packages at
> http://marillat.free.fr/

Hm,

Christian's package is the same (at least the binary contents) as my
quick solution.

I'll see if we can use his packages (libffmpeg0 and ffmpeg), tnx.

-- 
   greetz, marc
 
BOFH excuse #73:

Daemons did it
pgp Key ID: 0xD3562DE1
 Key fingerprint = 890C E47F 1589 F240 9CC8  C60C 510A 63D3 D356 2DE1
Linux scorpius 2.4.19-rc3 #2 Thu Aug 1 05:23:31 CEST 2002 GNU/Linux


pgp6zVwDkll8m.pgp
Description: PGP signature

Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System

> FYI, Christian Marillat has already some ffmpeg packages at
> http://marillat.free.fr/

I'll check it out, since this package is not my main interest. If I can
use the existing ones, the better.

-- 
   greetz, marc
 
BOFH excuse #73:

Daemons did it
pgp Key ID: 0xD3562DE1
 Key fingerprint = 890C E47F 1589 F240 9CC8  C60C 510A 63D3 D356 2DE1
Linux scorpius 2.4.19-rc3 #2 Thu Aug 1 05:23:31 CEST 2002 GNU/Linux


pgpJrnXTrrBrh.pgp
Description: PGP signature

Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System

2002-08-21 Thread Aaron Lehmann

On Wed, Aug 21, 2002 at 09:39:56AM +0200, Marc Leeman wrote:
> * Package name: ffmpeg
>   Version : 0.46
>   Upstream Author : Fabrice Bellard <[EMAIL PROTECTED]>
> * URL : http://ffmpeg.sourceforge.net/
> * License : LGPL
>   Description : FFmpeg Streaming Multimedia System

A lot of the code in ffmpeg is within the 'libavcodec' subdirectory,
and this code has been incorporated by several other projects (xine
and mplayer are all I can think of right now). I know that the libxine
source, at least on the debian servers, contains a copy of libavcodec.
Perhaps a dynamic libavcodec library should be built from the ffmpeg
sources and packages like xine could link against it.

Also, libavcodec contains some assembly routines that greatly enhance
performance. I would make sure that these are enabled on your packages
on all relevant architectures. They should not pose any problems
because IIRC at least on i386 usage of nonstandard features like MMX,
SSE, and 3DNow is decided at runtime based on the processor's features
(CPUID).

Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System

2002-08-21 Thread Josselin Mouette

Le mer 21/08/2002 à 09:39, Marc Leeman a écrit :

> * Package name: ffmpeg
>   Version : 0.46
>   Upstream Author : Fabrice Bellard <[EMAIL PROTECTED]>
> * URL : http://ffmpeg.sourceforge.net/
> * License : LGPL
>   Description : FFmpeg Streaming Multimedia System

FYI, Christian Marillat has already some ffmpeg packages at
http://marillat.free.fr/

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: PGP signature

Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System