Re: perlapi-5.6.1

[Adam Heath]

On Sat, 28 Jun 2003, Mark Hedges wrote:

>
> I apologize for filing multiple bug reports about this
> before seeking consensus on the list.
>
> Is someone going to put perlapi-5.6.1 back into sarge?
> Lots of packages indirectly depend on this and cannot
> be installed now.  Should there be a dummy package
> for compatibility with perl 5.8.0?

No.  The packages that require perl 5.6.1 need to be updated.  They have had
plenty of time to do so.  Because they hadn't, they had been holding up perl
5.8 from entering testing, which was keeping lots of other packages in the dep
tree from progressing.

Re: How to Avoid GPL Issue

[Bernd Eckenfels]

On Sun, Jun 29, 2003 at 06:44:06PM +0200, Josselin Mouette wrote:
> > Is there any approach that we can avoid publicizing the third party code 
> > while porting to Linux? Do we need to write some shim layer code in Linux 
> > kernel to interface the third party code? How can we do that? Is there any 
> > document or samples?
> 
> It is impossible. To say more, it is *meant* to be impossible.

it is no problem to offer binary only modules. As long as the porting can be
done as a loadable module, and does not use the GPL symbols this will work.

However this is strongly undesireable, will neighter get you commercial
success not is it a good (supportable) technical solution.

> Or they can also do like Nvidia and ignore the GPL restrictions, but it
> is just tolerated in this single case by Linus Torvalds, and may not be
> in other cases.

drivers and modules are allowed to be binary only.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Upstream requires forked Date::Manip

[Kenneth Pronovici]

The upstream maintainer of XMLTV, which I package for Debian, has
temporarily forked the Perl Date::Manip module.  He says:

   Over the past six months or so I've accumulated various bug fixes to
   the Date::Manip module, most of them because of xmltv bug reports
   sent by users.  Rather than wait any longer for the upstream
   Date::Manip to incorporate the fixes I have made my own release
   (intended as a temporary measure, not a permanent fork)... I've
   updated xmltv to require this version of the module (since it does
   fix several fairly important problems).

I'm not entirely sure what to do with this.

One option would be to roll these forked bug fixes into the offical
Debian libdate-manip-perl package.  There are no interface changes, so
this really shouldn't cause problems for anyone (in theory, anyway).  I
have written the Debian libdate-manip-perl maintainer a few times in the
last few weeks about this, but I haven't heard anything back from him.

Another option would be for me to create a temporary
libdate-manip-perl-fork package (or something) to temporarily provide
the forked code, which wouldn't affect users who don't install the XMLTV
packages.  This would be OK, but I don't like the idea of adding
temporary packages to the archive.

As a final option, I could just take out Makefile.PL's checks on version
and build the Debian XMLTV packages against the version of Date::Manip
currently in Debian.  This bothers me because it would leave us open to
Debian-only bugs for which there's an obvious fix that Debian doesn't
support.

Does anyone have any opinions on the best way to deal with this?  

Thanks...

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


pgp8OcQw4Jhdt.pgp
Description: PGP signature

Attn: Mass bug filing: libtool requires updating

[Scott James Remnant]

Version 3.39-1 of the file utility changed the format of the output line
for MIPS shared libraries again.

Older versions of libtool.m4 use the file utility and a regular
expression to determine if something is a shared library or not.  This
regular expression does not match the new file output format.

Newer versions of libtool instead use a much better checking method,
however the following source packages have not updated (list obtained by
grepping mips and mipsel build logs for the warning).

a2ps
ace-of-penguins
bombermaze
console-tools
cronosii
cyrus-sasl-nonus
eeyes
exult
gacc
gasql
gimp-python
gnome-admin
gnome-objc
gphoto
greg
gstalker
gtk-engines
gtk-engines-begtk
gtranscript
hermes1
infinity
insight
libgtrans-ifase
libgtrans-mysql-3-23
libibtk
libical
libjpeg6b
libopenobex
libunicode
lprng
ltt
mad
mnogosearch
mpqc
mysql++
ngrep
ntop
nurbs++
open-amulet
recode
roxen
rumba-manifold
snac
tdb
tetex-bin
tetradraw
tex-guy
tuxtime
usbutils
vdkbuilder
vflib3
xalf
xmlrpc-c
xmms-cdread
xmms-nas

This means that on the mips and mipsel architectures the following
warning is produced during configure.

*** Warning: the command libtool uses to detect shared libraries,
*** /usr/bin/file, produces output that libtool cannot recognize.
*** The result is that libtool may fail to recognize shared libraries
*** as such.  This will affect the creation of libtool libraries that
*** depend on shared libraries, but programs linked with such libtool
*** libraries will work regardless of this problem.  Nevertheless, you
*** may want to report the problem to your system manager and/or to
*** [EMAIL PROTECTED]

An updated libtool will produce the following message during configure
output on mips (a good method of checking whether you've updated or
not).

checking how to recognise dependent libraries... pass_all
 

In order to update your packages to the latest version of libtool,
ensure that libtool_1.4.3-10 is installed on your system and run the
following commands from the source directory.

$ libtoolize -cf
$ aclocal
$ autoconf

You should also remove any "libtool" or "ltconfig" file left lying
around from a previous version of libtool.

Failure to run *all three* means you'll end up with a funted version of
libtool.

Also make sure that you run them in any sub-directory which ALSO runs
libtool ( find . -type f | grep -e ltconfig -e ltmain )
 
Scott
-- 
Who is nervous about his first ever mass-bug


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

Re: Bug#198158: architecture i386 isn't i386 anymore

[Nathan Hawkins]

On Thu, Jun 26, 2003 at 04:24:23PM -0400, Matt Zimmerman wrote:
> On Thu, Jun 26, 2003 at 09:44:30AM +0200, Christoph Hellwig wrote:
> 
> > On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote:
> > > ports - NetBSD gives us the potential to bring Debian to _many_ new
> > > platforms. 
> > 
> > It's not that many actually.  The only CPU that NetBSD claims to support
> > but Linux doesn't is the pc532.  Also the (umerged) Linux VAX and arm26
> > aren't really useable unlike their NetBSD counterparts.
> 
> However, NetBSD doesn't run on IA64 or S/390 as far as I know, while Debian
> does.

Of course, FreeBSD (5.0) does run on IA64, so I suspect it won't be that
long before NetBSD has a port to it. I also recall seeing that people
are in the process of porting both FreeBSD and NetBSD to S/390.

---Nathan

Re: How to Avoid GPL Issue

[Josselin Mouette]

Le ven 27/06/2003 à 04:27, G. C. a écrit :
> Dear Sir or Madam,
> 
> Currently we are trying to port some third party code to Linux kernel. Some 
> modules of third party code need to be ported into Linux kernel and some 
> drivers need to be ported from Vxworks to Linux drivers. The problem we have 
> is that this third party does not allow us to publicize its code as Linux 
> GPL requires.
> 
> Is there any approach that we can avoid publicizing the third party code 
> while porting to Linux? Do we need to write some shim layer code in Linux 
> kernel to interface the third party code? How can we do that? Is there any 
> document or samples?

It is impossible. To say more, it is *meant* to be impossible.

But this third party should also be aware that putting her code under
the GPL is not giving it completely away : it guarantees them the code
won't be used in another proprietary product, and it will bring them
back the community enhancements and bugfixes.

They can also release the information needed for writing these drivers.
Some developers will generally accept to write the driver themselves.

Or they can also do like Nvidia and ignore the GPL restrictions, but it
is just tolerated in this single case by Linus Torvalds, and may not be
in other cases.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

test

[Duck]

Bug#62878: Screen display problems with terminals.

[Ross Boylan]

On Thu, Apr 03, 2003 at 04:43:31PM +0200, Bill Allombert wrote:
> Hello,
> 
> It seems sthat changing the font have solved the problem
> so we can close this bug report ?
> 
> Cheers,
I am very belatedly catching up with this question.  It doesn't seem
to me the bug should be closed.

It appears that things work for some combinations of terminal
programs, font selections, and TERM variable settings, but not others.

It seems to me it should work for all, or it should be better
documented why it doesn't.

I can't fully check this behavior because I am having other, more
serious font problems.  If I select Lucida-Typewriter font in my KDE
Konsole now, nothing at all shows up.  However, if I set the font to
medium in the Konsole settings, things work OK with TERM=xterm (the
default) but not TERM=linux.  Same for an xterm.

It *might* be appropriate to close this if the defaults for all
relevant packages put in sensible values and alternatives, so the
problem does not arise.  I'm not sure what all "relevant" packages
are, since some of this stuff might go in general start up files.

perlapi-5.6.1

[Mark Hedges]

I apologize for filing multiple bug reports about this
before seeking consensus on the list.

Is someone going to put perlapi-5.6.1 back into sarge?
Lots of packages indirectly depend on this and cannot
be installed now.  Should there be a dummy package
for compatibility with perl 5.8.0?

Thank you for investigating.

--mark--

Re: [Stefano =)] Bug#198619: Could not perform configuration on libpam0g

[Adam Heath]

On Sat, 28 Jun 2003, Sylvain LE GALL wrote:

> On Thu, Jun 26, 2003 at 11:15:37PM +0100, Esteban Manchado Vel?zquez wrote:
> > On Wed, Jun 25, 2003 at 05:39:36PM -0400, Sam Hartman wrote:
> > >
> > > [Please cc me; I'm very behind on -devel]
> > >
> > >
> > > I'm very confused by this bug and am sufficiently busy this week that
> > > I'm not going to be able to diagnose it right now.
> > >
> > > Could anyone who has a chance to do so please look at exactly what is
> > > failing from a dependency standpoint?
> > > I get the feeling I'm missing
> > > something about the interactions between pre-dependencies and
> > > dependencies and apt.
> >
> >I ran into the very same error some days ago. I have no idea about the
> > cause, but doing random tests, we (at work) found that upgrading to testing
> > and then to unstable "fixed" the problem. You only have to upgrade libpam or
> > libpam0g (I'm not sure which of them; the former doesn't exist in unstable,
> > IIRC), and then you can upgrade normally to unstable. That is, add testing 
> > to
> > your sources.list, do apt-get install libpam/testing, and then upgrade
> > normally.
> >
> >DEBCONF_DEBUG=developer showed nothing, BTW.
> >
> >HTH,
> >
> Hello,
>
> In fact, i have also this bug. It comes from a circular versionned
> dependency betwee lipam0g and libpam-modules :
>
> libpam0g depend on libpam-modules > 0.7.X and
> libpam-modules depends on libpam0g > 0.7.X...
>
> So if you try to upgrade from a version below 0.7.X you cannot get it to
> work... Or you have to ignore the dependcy...

this is a bug in apt.  dpkg correctly handles this case(it breaks the dep loop
randomly, which means postinsts of the affected packages need to be aware of
the issue.

The apt developer has refused to fix apt to work around this non-problem in
the past, I suggest you take it up with him.

Re: Package Lists and Size

[Bruno Rodrigues]

Corrin Lakeland <[EMAIL PROTECTED]> wrote:
> 
>> So, i think if there .diff's exist, maybe apt-get can patch the
>> Changes into the files on the client, or a small wrapper arround
>> apt-get can do this..
> 
> Goodness, you are the second person to ask for this in a month.  Diff is not 
> suitable since there are many versions the file could be diffed against.  You 
> need rsync, anoncvs, or similar.
> 
> Some of the servers run rsync, which works well for the Packages file, but 
> does not work for the packages themselves.  Other mirrors do not run rsync 
> since it puts extra CPU load on their server. Perhaps you could find/use a 
> mirror with public rsync access.  To do this, just replace http with rsync in 
> your sources.list

With which apt version ?
I don't find any usr/lib/apt/methods/rsync :(

Re: Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption

[Millis Miller]

OK, let me see if I can address all the comments I've received so far.

1. Description too long.
OK, I will change it to a shorter one, once I work out how to do that
with an ITP.

2. Various questions along the line of "What does email do that a
certain shell sequence doesn't".

This from Upstream:
A) Email users SMTP or Sendmail.  (Main purpose!)
B) Email handles the GPG interaction.  Meaning you can use email from a
cron job and as long as you have your pass in the email.conf file, you
won't have to type it in when gpg asks for it.  You'd have to come up
with a pretty wicked shell script otherwise.
C) Email handles signature files 
D) Email handles an address book.
E) Email does binary attachments and uses MIME (mime types, base64
encoding) to "attach" and send them with the message.  You can't do this
by doing what is described above.  You can UUEncode it, but A LOT of
mail clients don't support UUEncoding anymore.  Plus, you can attach
multiple binary files with email, not just one UUEncoded file.  For
instance:
uuencode file.bin | gpg --clearsign | mail 

First of all, it's only one file.  Second of all, it's using a
--clearsign and not the way email does it.  I believe it was you who
suggested email sign/encrypt messages such as Ximian and Outlook does. 
This is the way the majority of modern mail reader clients view such
data.  So in short:

The command line way you are suggesting violates modern RFC compliant
mail reader clients.  However, email follows RFC's 821, 2015 (PGP
Encryption), 2045, and soon 2554.


3. Change the name from email to something else. 
Upstream does not want to do this, as the name has been in use since
2001, with an established user base. Apparently (for what it is worth)
it has been used in Slackware with this name.
Also, I myself first came accross it precisly by doing a search on
google using the word email (I forget exatly how, something like
"command line email" I think).
Finally, as Upstream reasons, it does actually describe what it does.
Remembering the meaning of the verb, "to email", email does precisely
that: send email.

BR,
Millis



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

Re: [Stefano =)] Bug#198619: Could not perform configuration on libpam0g

[Sylvain LE GALL]

On Thu, Jun 26, 2003 at 11:15:37PM +0100, Esteban Manchado Vel?zquez wrote:
> On Wed, Jun 25, 2003 at 05:39:36PM -0400, Sam Hartman wrote:
> > 
> > [Please cc me; I'm very behind on -devel]
> > 
> > 
> > I'm very confused by this bug and am sufficiently busy this week that
> > I'm not going to be able to diagnose it right now.
> > 
> > Could anyone who has a chance to do so please look at exactly what is
> > failing from a dependency standpoint?  
> > I get the feeling I'm missing
> > something about the interactions between pre-dependencies and
> > dependencies and apt.
> 
>I ran into the very same error some days ago. I have no idea about the
> cause, but doing random tests, we (at work) found that upgrading to testing
> and then to unstable "fixed" the problem. You only have to upgrade libpam or
> libpam0g (I'm not sure which of them; the former doesn't exist in unstable,
> IIRC), and then you can upgrade normally to unstable. That is, add testing to
> your sources.list, do apt-get install libpam/testing, and then upgrade
> normally.
> 
>DEBCONF_DEBUG=developer showed nothing, BTW.
> 
>HTH,
> 
Hello,

In fact, i have also this bug. It comes from a circular versionned
dependency betwee lipam0g and libpam-modules :

libpam0g depend on libpam-modules > 0.7.X and 
libpam-modules depends on libpam0g > 0.7.X...

So if you try to upgrade from a version below 0.7.X you cannot get it to
work... Or you have to ignore the dependcy...

Regard
Sylvain LE GALL

Re: Counter-Proposal: Architecture Versions and Architecture Features

[Andreas Barth]

* Julian Mehnle ([EMAIL PROTECTED]) [030627 21:05]:
> I understand that the your proposed extensions to the Debian package system
> are based on the concepts of "sub-archs" and "meta-sub-archs" (I'd call
> these "pseudo-sub-archs" or "alias-sub-archs", though).  I have already
> proposed a more genereal extension based on "arch versions" (essentially
> equivalent to sub-archs, except that an order is implicitly defined), and
> "features".  I'll explain it in more detail, because I think that a more
> general approach would also be more flexible for potential future
> requirements in the Debian package system.

Thanks for your proposal. IMHO it is important that we are going to
adopt one or the other proposal rather soon, so that it could be used
in sarge.

I think both proposals have their specific advantages, and we must try to 
combine these.

Now to comments:


> Every base arch (alpha, i386, mips, ...) can, but isn't required to, have
> one or more explicit versions (as I said, these are equivalent to
> sub-archs).  An arch version gets appended to the base arch name as
> ".", the default version being 0.  Thus, "i386" would be
> equivalent to "i386.0", and subsequent versions could be "i386.1",
> "i386.1foo", "i386.2", and so on.


>  Arch versions are ordered
> alphabetically, with higher versions including the functionality of all
> lower versions, i.e. higher arch versions must be downwards compatible. 
> Example: "i386" = "i386.0" < "i386.1" < "i386.1foo" < "i386.2".

The problem with this is: It works only if all relevant processor
makes can be seen as a chain by inclusion, i.e. there is only one heir
to each processor version. However, with AMDs Opteron on one side and
the certainly next Intel processor on the other side there will be two
"childs" with different features, so this fails. You can of course
make it with 

> Independently, every arch can, but isn't required to, have one or more
> special features beyond what the base arch version supports.  A feature
> gets appended to the arch name/version as "+".  For "i386", there
> could be features like "fpu", "mmx", "sse", "sse2", etc.  A single arch
> specifier can name any number of features, e.g. "i386+3dnow", or
> "i386.6+mmx+sse".

... but this has the disadvantage of being unexact. What to do if a
processor has three features, but in the special case the packages
allows only two of them at a time? Or to make it worse say processor A
supports maximum subarch 7, and feature A, but feature A can only be
used really fast in subarch 6; packages in subarch 7 must also be
built because they are faster on processors without feature A?

In your proposal one is bound to suboptimal matches in special cases,
and even a very good package maintainer can't get around. The argument
that special cases are seldom won't match here because: The whole
subarch-system is only needed in special cases. I don't believe that
vi will get substantial speed improvements because of subarch specific
versions (otherwise show me figures). ;-)


Because of this in my proposal exact matches are possible. There is
only one case where unexact must be used, and this is when a new
subarch comes to existence.


The subarch information that could be stored in your modell can be
also be stored in my modell, but also more complex information. (You
break up the subarch-info from my modell to several pieces. In my
modell there would be a subarch _i586 and _i586-mmx, and with an
unexact match packages for _i586 are also used for _i586-mmx, unless
there is a better, i.e. exact match.)


There is one obvious advantage of your proposal: The archive selection
code needs to know less of subarchs. But, as new subarchs aren't
created every day (unlike new version of ordinary packages) it's IMHO
ok to save magic code in the selection programms. It won't get real
large.

The other advantage is that it consumes less space in the Packages
file. But, as subarchs are needed on relativly few packages this is
IMHO ok because of the more mightier abilities.


>   Available packages in the fictitious pool:
>   (A) pool/contrib/q/quake2/quake2_0.2.1-4_i386.deb
>   (B) pool/contrib/q/quake2/quake2_0.2.1-4_i386.5+mmx.deb
>   (C) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+3dnow.deb

Do I see it right that the package names are nowhere noted but created
by s/// on the fly? I specified the different files
on purpose in the Packages-File, as it might be useful in special
cases to use different filenames - or to use one file for different
subarchs.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Please don't misuse the debian/changelog to close bugs!

[Mark Brown]

On Thu, Jun 26, 2003 at 07:56:37AM +1000, Herbert Xu wrote:
> Brian Nelson <[EMAIL PROTECTED]> wrote:

> > http://bugs.debian.org/188740

> That's a documentation issue.  debian/changelog is not the place for
> documenting random features.

Messages that close bugs are, however, the place for documenting why
bugs are being closed and when those messages come from changelogs that
means that the changelogs ought to be more explicit too.

In this case things would've been fine if the feature integrated
upstream had done the same thing as the patch I originally submitted but
in fact it didn't quite do so, breaking my setup.  Had the changelog
been more explicit about why the bug was being closed there would've
been rather less confusion.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


pgpyaA5EI8S1T.pgp
Description: PGP signature

Re: Bug#198158: architecture i386 isn't i386 anymore

[Christoph Hellwig]

On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote:
> No it doesn't. I've yet to even hear of an architecture that NetBSD runs
> on but which Linux doesn't.

pc532

> They just have a different definition of
> "architecture" than us. (ie: our "hppa" may be three or four arches to
> the NetBSD kernel folk.)

Yupp.  But under this different arch concepts there's also hidden
lots of hardware supported by only either NetBSD or Linux even if
the CPU is supported by both..

Re: Garbled messages received from lists.d.o.

[Mike Dresser]

On 27 Jun 2003, Philippe Troin wrote:

> I have been receiving bugs.d.o emails which are unrelated to my
> package for the last two-three days.
>
> And their headers seem quite garbled: they include part of other
> messages...
>
> Included five of them.
>
> Is there anything fishy going on? Or is the spam filter going crazy?
>
> Phil.
>

Getting them here, so it's not your system along.. Seeing parts of bug
reports here.

Re: ximiam connector

[Jim Mintha]

On Mon, Jun 23, 2003 at 04:27:36PM -0600, Thomas E. Vaughan wrote:
> 
> Is there anyone else out there trying to run Connector on
> Debian (sid)?
> 
> Although Ximian strongly discourages a direct download of
> Connector (because Ximian urges the use of Red Carpet), the
> binaries are available at
> .
> 
...
> I've tried alien on a couple of the packages, but so far, no
> good.

I have it working, but at the moment it is a bit difficult.  The idea
is that you can add 
deb http://red-carpet.ximian.com/debian woody main
to your sources.list and then you can install red-carpet.  red-carpet
looks at the /etc/issue file to figure out which distro you have.  I
changed my issue to be:

Debian GNU/\s 3.0 \n \l

so it thought I was still running stable.  With red-carpet you can
then download all the rest (evolution, connector, etc.)

However at the moment red-carpet doesn't seem to work.  Also the
sources line above doesn't seem to work either.  The line:
deb http://trumpetti.atm.tut.fi/ximian/debian woody main
but that doesn't get you the connector.  

Fortunately red-carpet has an on-disk cache so I still have the debian
packages. (or I'd be in trouble).  

Jim

-- 
Jim Mintha   Email: [EMAIL PROTECTED]
System Administrator  Work: +31 20 525-4919
Informatiseringscentrum   Home: +31 20 662-3892
University of Amsterdam   Debian GNU/Linux: [EMAIL PROTECTED]
_There are always Possibilities_  http://www.mintha.com

Re: Application files in $HOME

[Daniel Ruoso]

Em Sex, 2003-06-27 às 02:14, Adam Majer escreveu:
> Then they should't delete anything with .*  After all, shoudn't most
> "user friendly" applications hide those directories in the first place?
> Even ls does it unless you use -a

But the question is: These files and directories uses a lot of disk
space... And today we have to clean another user's home, because there
is no way to a newbie to clean it, because that demands a certain
knowledge of the operating system and the packages that are installed.

P.S.: think of an office with diskless stations running debian with the
home over nfs and the authentication over nis, in this way we have to
set a low quota, because we don't have much space in the hd.

> Furthermore, this is what a system admin is for. If something is broken,
> they can fix it remotely.

I don't expect that a system admin even touch my home directory.

> > And anyway, this doesn't need to be made in one day, think about
> > debconf, there are packages that still doesn't use it and nobody died.
> 
> I think that the two things are very different. debconf is not used by the
> end user.

I was not talking about this. I was talking about the risk of this
proposal.

> On the other hand, if someone is using Debian as a desktop and doesn't know
> how to upgrade it (and probably doesn't want to upgrade it too often)
> they will never run into the problem of run-away dot-files/dirs.

Unless the user needs to keep its disk space below the quota.

Re: Application files in $HOME

[Daniel Ruoso]

Well, it may be included in the wishlist for cruft, the program I called
userconfpurge may be a part of it. But before this would be necessary a
change in the debian packages, to include which files are created in the
user's home.

Em Qui, 2003-06-26 às 14:31, Drew Scott Daniels escreveu:
> Is connecting files to packages like this part of cruft? A potential
> wishlist item for cruft?
> 
>  Drew Daniels
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

Counter-Proposal: Architecture Versions and Architecture Features

[Julian Mehnle]

Hi all,

(I'm sending this message again, since the copy I sent yesterday seems not
to have made it onto the list.  If you receive it twice, please excuse.)

Andreas Barth wrote:
> DRAFT - Subarchitectures for debian [0.1]

First, thanks for creating a prototype proposal.

I understand that the your proposed extensions to the Debian package system
are based on the concepts of "sub-archs" and "meta-sub-archs" (I'd call
these "pseudo-sub-archs" or "alias-sub-archs", though).  I have already
proposed a more genereal extension based on "arch versions" (essentially
equivalent to sub-archs, except that an order is implicitly defined), and
"features".  I'll explain it in more detail, because I think that a more
general approach would also be more flexible for potential future
requirements in the Debian package system.


Architecture Specifiers
---

An arch specifier may specify the exact base arch, arch version, and arch
features that are supported by a given system, or that are required for a
given binary package to work (with or without an emulating kernel).

Every base arch (alpha, i386, mips, ...) can, but isn't required to, have
one or more explicit versions (as I said, these are equivalent to
sub-archs).  An arch version gets appended to the base arch name as
".", the default version being 0.  Thus, "i386" would be
equivalent to "i386.0", and subsequent versions could be "i386.1",
"i386.1foo", "i386.2", and so on.  Arch versions are ordered
alphabetically, with higher versions including the functionality of all
lower versions, i.e. higher arch versions must be downwards compatible. 
Example: "i386" = "i386.0" < "i386.1" < "i386.1foo" < "i386.2".

Independently, every arch can, but isn't required to, have one or more
special features beyond what the base arch version supports.  A feature
gets appended to the arch name/version as "+".  For "i386", there
could be features like "fpu", "mmx", "sse", "sse2", etc.  A single arch
specifier can name any number of features, e.g. "i386+3dnow", or
"i386.6+mmx+sse".


Binary Package Files


Binary package files shall have the full arch specifier in their file names
(see below for examples).  Current packages with simple (traditional) arch
specifiers such as "i386" don't require special features beyond what the
base arch version supports, thus the extension is backward compatible.


"control" and "Packages" Files
--

In "control" files, the "Architecture:" field, as before, lists the
architectures supported by the base arch binary packages.  Additionally,
more specific arch specifiers can be listed here.  Binary packages will be
built for every listed arch specifier.  Example:

  Architecture: alpha i386 i386.6+mmx+sse mips

The special "any" arch specifier in the "control/Architecture:" field would
only build binary packages for the base archs.

The "Packages" file of a given base arch would, for every binary package
based on (but of course not neccessarily supporting) that base arch, list
the packages' exact arch specifiers in the "Architecture:" field.  I.e.
although a binary package compiled for "i386.6+mmx+sse" probably will not
run on a real 80386 or Pentium 1 machine (disregarding any emulating
kernels), it will be part of the "i386" base arch nonetheless.


apt and dpkg


There might be several methods for apt and dpkg how to choose which
packages to download and to install.  Generally, binary packages for the
plain base arch will be downloaded and installed unless specified
otherwise.

The 'APT::Architecture' configuration option would specify the *minimum*
arch version and features that must be required by any package to be
installed.  The *maximum* arch version and features supported by the local
system could be configured either as some 'APT::Architecture-Maximum'
configuration or '--arch' command-line option, or as some generic
'/etc/hwarch' config file, or it might even be possible to query the kernel
for this information.

Apt would then choose the binary package compiled for the highest
compatible arch version and the most matching arch features that fulfills
both the minimum and maximum requirements.

Examples:

  Available packages in the fictitious pool:
  (A) pool/contrib/q/quake2/quake2_0.2.1-4_i386.deb
  (B) pool/contrib/q/quake2/quake2_0.2.1-4_i386.5+mmx.deb
  (C) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+3dnow.deb
  (D) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+mmx.deb
  (E) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+sse.deb
  (F) pool/contrib/q/quake2/quake2_0.2.1-4_i386.7+mmx+sse.deb
  (G) pool/contrib/q/quake2/quake2_0.2.1-4_i386.7+mmx+sse2.deb

  # uname -a
  Linux gray 2.4.20 #1 Fri Apr 4 14:43:45 CEST 2003 i686 GNU/Linux
  # cat /etc/apt/apt.conf
  APT::Architecture "i386";# minimum arch specifier
  APT::Architecture-Maximum "i386.6+mmx+sse";  # maximum arch specifier

  # apt-get install quake2
  (chooses package D, acceptable fallbacks 

Re: Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption

[Adrian 'Dagurashibanipal' von Bidder]

On Friday 27 June 2003 01:32, Millis Miller wrote:

>   Description : Send email from command line, either via MTA or SMTP,
> with optional encryption

> Also, if gpg is installed, it can digitally sign and encrypt outgoing
> emails.

Just out of curiosity: inline PGP, or PGP/MIME

cheers
-- vbi

-- 
random link of the day: http://fortytwo.ch/sienapei/shoezaim


pgpO5ztwWzmS5.pgp
Description: signature

Re: Bug#160074: acknowledged by developer (Re: Bug#160074: acknowledged by developer (Re: Bug#160074: Ok, can't be that important then))

[Scott James Remnant]

On Fri, 2003-06-27 at 01:50, Ryan Murray wrote:

> On Thu, Jun 26, 2003 at 06:48:06PM -0500, Debian Bug Tracking System wrote:
> > Don't reopen bugs just because you think it's not fixed, I've spent
> > three or four hours testing libtool on mips this evening and I've not
> 
> I'm not convinced it's fixed.  It's really easy to fix this.  Would
> you like me to NMU it?
> 
THEN PROVE THAT IT IS NOT FIXED.

Give me a test that I can fun on a mips box to replicate this.

And don't you fucking dare NMU my package over my head.

> > 1) I've tested it quite thoroughly
> > 2) libtool no longer uses file to check mips shared libraries
> 
> Yet some builds still end up using the file_magic check (and give a message
> to file it as a libtool bug) even though they are using pass_all.
> 
WHICH BUILDS?

Point at one!  SHOW ME ONE!

If libtool is somehow using file_magic when deplibs_check_method is
pass_all, that's a far more serious problem than fixing a "commented
out" bit of code.

> > there's only a handful left and it's easy to see and understand which
> > platforms still need this.
> 
> If you're going to leave the code in the libtool.m4 file, let's leave code
> that works.
> 
I didn't leave that code there, upstream did -- and there's no reason to
remove it because it's *DEAD CODE*, there's no possible way, save for a
very bad bug in the shell, that it can be used.

> > Filing bugs against the Debian libtool package when there is a problem
> > with the Debian libtool package is fine.
> 
> There is a problem with the package.  It has an incorrect file_magic check,
> and that is sometimes being used in freshly relibtoolized packages.
> 
When?  GIVE ME AN EXAMPLE.

> > Let's use lprng as our guinea-pig, shall we?  That's certainly exhibited
> > this problem on mips...
> 
> I said to *SEARCH* build logs, not randomly pick one that has had the problem
> due to being out of date.  We both know that if it's out of date, a change
> to the libtool package won't make a bit of difference.
> 
I did.  I compiled 10 different packages on a mips box last night, all
of which had this warning in their most recent build logs.  After
libtoolizing again with 1.4.3-10, THE WARNING WENT AWAY.

I've proved to myself that it is fixed.  You've not even bothered doing
any testing, and can't replicate the problem.

Give me a package that uses the Debian 1.4.3-10 libtool and produces
this warning.

I can't find one!

If you can, I'll happily investigate why libtool is using file_magic
WHEN IT SHOULDN'T.

Changing a "comment" to match the current file output WILL NOT fix any
problem you think you might have.

Scott
-- 
Who is seriously getting tired of this.


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

Re: Bug#198158: architecture i386 isn't i386 anymore

[Matthew Garrett]

Christoph Hellwig wrote:
>On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote:
>> ports - NetBSD gives us the potential to bring Debian to _many_ new
>> platforms. 
>
>It's not that many actually.  The only CPU that NetBSD claims to support
>but Linux doesn't is the pc532.  Also the (umerged) Linux VAX and arm26
>aren't really useable unlike their NetBSD counterparts.

It depends a bit on your definition of platform - NetBSD supports the
Turbochannel Alphas while Linux doesn't, for instance. There's various
chunks of architectures that are better supported by one than the other.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Bug#198158: architecture i386 isn't i386 anymore

[Frank Gevaerts]

On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote:
> On Wed, 25 Jun 2003 14:04:54 -0500
> Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> > And not only 80386 needs this - There is the Sparc64 port which would
> > also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we
> > had support for subarchtectures, not only would the ix86 mess be able to
> > be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever
> > you fancy). And I am sure this can somehow help maintain the non-Linux
> > ports - NetBSD gives us the potential to bring Debian to _many_ new
> > platforms. 
> 
> No it doesn't. I've yet to even hear of an architecture that NetBSD runs
> on but which Linux doesn't. They just have a different definition of
> "architecture" than us. (ie: our "hppa" may be three or four arches to
> the NetBSD kernel folk.)

They support the vax, and openbsd (nearly) supports the m88k. The others
look (to me, I didn't look very hard) like their CPUs are supported

Frank

Re: Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption

[Craig Sanders]

On Sat, Jun 28, 2003 at 03:33:16PM -0500, Steve Langasek wrote:
> On Sat, Jun 28, 2003 at 04:08:05PM +0100, Millis Miller wrote:
> > E) Email does binary attachments and uses MIME (mime types, base64
> > encoding) to "attach" and send them with the message.  You can't do this
> > by doing what is described above.  You can UUEncode it, but A LOT of
> > mail clients don't support UUEncoding anymore.  Plus, you can attach
> > multiple binary files with email, not just one UUEncoded file.  For
> > instance:
> > uuencode file.bin | gpg --clearsign | mail 
> 
> OTOH, the above features seem useful.

mime-construct does multiple mime attachments.  it does an excellent job, a
very useful and versatile tool.

it doesn't do uuencode, but a) uuencode is deprecated and should be avoided,
and b) that's easy enough to do anyway:

   (for i in file1.bin file2.bin file3.bin ; uuencode $i ; echo ; done) | \
   gpg --clearsign | mail ...



FWIW, i don't think that mere duplication of existing functionality is a reason
for a package not to be included in debian(*), but "email" is a really bad name
for this program and this package.  it's far too generic.


(*) the only criteria for inclusion in debian are:

1. is it free?
2. is someone willing to package and maintain it?

craig

Re: Please don't misuse the debian/changelog to close bugs!

[Richard Braakman]

On Fri, Jun 27, 2003 at 08:19:14PM +1000, Herbert Xu wrote:
> Are you proposing that we list important upstream changes regardless of
> whether they fix bugs or not?
> 
> If so then this may be worth considering.

Hmm, I've always tried to do that, actually.  And I appreciate it when
other developers do it.  If the upstream changelog is verbose and
detailed (like the GNU ones tend to be) then it's nice to have the
major changes as a short list.

Richard Braakman

Re: Application files in $HOME

[Brian Nelson]

Richard Braakman <[EMAIL PROTECTED]> writes:

> On Wed, Jun 25, 2003 at 02:02:04PM -0300, Daniel Ruoso wrote:
>> What if the packages tells to dpkg which files or directories it will
>> create on the user's home directory and when a package is purged the
>> user could run a program to purge the files of packages that no longer
>> exists.
>
> I have a better idea :)  What if packages don't leave droppings in my
> home directory in the first place?  I have all sorts of dotfiles (and
> even dot-directories) that I never asked for.  It's reasonable for a
> program to install a dotfile when I configure it differently from the
> default, but there's no reason to create a dotfile that's identical
> to the default.

Amen, brother!

$ ls -Ad ~/.* | wc -l
241

-- 
Poems... always a sign of pretentious inner turmoil.


pgpoTAP7pod8x.pgp
Description: PGP signature

Re: but I want the GNU versions of packages

[Sam Hocevar]

On Sat, Jun 28, 2003, Dan Jacobson wrote:

> Do I look in Packages.gz for Conflicts:, and then look in Description:
> for "this is the GNU version of..."?

   No need for such a fastidious search. Use this instead:

 apt-get install `apt-cache search gnu | sed 's/ .*//'`

Cheers,
-- 
Sam.

Re: Mass bug filing: Build-Depends on libgdbmg1-dev and/or imlib-dev

[Adam Heath]

On Sat, 28 Jun 2003, Daniel Schepler wrote:

> I don't know why my previous message on this topic didn't get
> through, so let me try again...

murphy has been having load issues, amoung other things.

> I'm planning to file bugs against source packages which currently
> don't build in unstable because of build dependencies on libgdbmg1-dev
> or imlib-dev.  Currently, the packages involved would be:

Why?

Re: Bug#198158: architecture i386 isn't i386 anymore

[Joel Baker]

On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote:
> On Wed, 25 Jun 2003 14:04:54 -0500
> Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> > And not only 80386 needs this - There is the Sparc64 port which would
> > also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we
> > had support for subarchtectures, not only would the ix86 mess be able to
> > be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever
> > you fancy). And I am sure this can somehow help maintain the non-Linux
> > ports - NetBSD gives us the potential to bring Debian to _many_ new
> > platforms. 
> 
> No it doesn't. I've yet to even hear of an architecture that NetBSD runs
> on but which Linux doesn't. They just have a different definition of
> "architecture" than us. (ie: our "hppa" may be three or four arches to
> the NetBSD kernel folk.)

There are a couple. I don't think most people care about any of them,
right now (and quite possibly never will, in the case of old VAXen,
for example).

In discussing it the other day, I actually found a concise way to
express one of the major reasons I choose to work on the port and find
it worthwhile:

NetBSD's motto is "Yes, it runs NetBSD".

NetBSD other motto is "correctness above all" (by comparison, OpenBSD is
"security above all", FreeBSD is "features above most", and Linux would
probably be "bleeding edge above most").

Sort of like Debian's release schedule is "when it's ready", and for the
same reasons.

Their -current is more or less like our unstable ("It may break, but people
always scream at us when it does so for any significant length of time").
They don't release fast (other than security patches), but they do have a
good history of their releases being rock-stable.
-- 
Joel Baker <[EMAIL PROTECTED]>


pgpVPPhefbfAy.pgp
Description: PGP signature

Mass bug filing: Build-Depends on libgdbmg1-dev and/or imlib-dev

[Daniel Schepler]

I don't know why my previous message on this topic didn't get
through, so let me try again...

I'm planning to file bugs against source packages which currently
don't build in unstable because of build dependencies on libgdbmg1-dev
or imlib-dev.  Currently, the packages involved would be:

For libgdbmg1-dev (excluding packages with Build-Depends on
"libgdbm-dev | libgdbmg1-dev"): acm, am-utils, apache-perl, gauche,
hypermail, inn, ipac-ng, jenova, jwhois, libapache-mod-perl, libgda,
maildrop, mozart, nis, pdns, python1.5, python2.1, qpopper, ruby-beta,
saml, sced, siag, skk, slpim, smail, tdb, xfmail, xkbsel, zmailer,
zmailer-ssl

with maintainers:
Akira TAGOH <[EMAIL PROTECTED]>
Daniel Jacobowitz <[EMAIL PROTECTED]>
Debian QA Group <[EMAIL PROTECTED]>
Enrique Zanardi <[EMAIL PROTECTED]>
Florian Hinzmann <[EMAIL PROTECTED]>
Gregor Hoffleit <[EMAIL PROTECTED]>
Hatta Shuzo <[EMAIL PROTECTED]>
Hector Garcia <[EMAIL PROTECTED]>
Josip Rodin <[EMAIL PROTECTED]>
Marco Kuhlmann <[EMAIL PROTECTED]>
Marco d'Itri <[EMAIL PROTECTED]>
Marek Habersack <[EMAIL PROTECTED]>
Miquel van Smoorenburg <[EMAIL PROTECTED]>
Noel Koethe <[EMAIL PROTECTED]>
Peter Karlsson <[EMAIL PROTECTED]>
Phil Brooke <[EMAIL PROTECTED]>
Philippe Troin <[EMAIL PROTECTED]>
Scott James Remnant <[EMAIL PROTECTED]>
Takao KAWAMURA <[EMAIL PROTECTED]>
Vikram Aggarwal <[EMAIL PROTECTED]>
Wichert Akkerman <[EMAIL PROTECTED]>
Yu Guanghui <[EMAIL PROTECTED]>
akira yamada <[EMAIL PROTECTED]>

For imlib-dev: chameleon, enlightenment, epplets, kdegraphics,
motioneye, mozart-gtk, pixelize, qvwm, vertex, w3m, xteddy

with maintainers:
Andreas Tille <[EMAIL PROTECTED]>
Arto Jantunen <[EMAIL PROTECTED]>
Christophe Le Bars <[EMAIL PROTECTED]>
Christopher L Cheney <[EMAIL PROTECTED]>
Eduardo Marcel Macan <[EMAIL PROTECTED]>
Fumitoshi UKAI <[EMAIL PROTECTED]>
Laurence J. Lane <[EMAIL PROTECTED]>
Marco Kuhlmann <[EMAIL PROTECTED]>
Shuichi OONO <[EMAIL PROTECTED]>
Stephen Frost <[EMAIL PROTECTED]>
Uwe Hermann <[EMAIL PROTECTED]>
-- 
Daniel Schepler  "Please don't disillusion me.  I
[EMAIL PROTECTED]haven't had breakfast yet."
 -- Orson Scott Card

Re: Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption

[Steve Langasek]

On Sat, Jun 28, 2003 at 04:08:05PM +0100, Millis Miller wrote:

> This from Upstream:
> A) Email users SMTP or Sendmail.  (Main purpose!)

Which would make it the only piece of mail-aware software on the system
that doesn't depend on a working /usr/sbin/sendmail; so this is great as
long as you never install any other software.  (c.f. 'apt-cache showpkg
mail-transport-agent'.)

> B) Email handles the GPG interaction.  Meaning you can use email from a
> cron job and as long as you have your pass in the email.conf file, you
> won't have to type it in when gpg asks for it.  You'd have to come up
> with a pretty wicked shell script otherwise.

This is as good of a reason as any to NOT include this software in
Debian.  If you want passwordless access to a gpg key, create your gpg
key without a passphrase -- don't encourage users to acquire a false 
sense of security by putting a passphrase on their key, and then storing
the passphrase on disk next to the key!

> C) Email handles signature files 
> D) Email handles an address book.
> E) Email does binary attachments and uses MIME (mime types, base64
> encoding) to "attach" and send them with the message.  You can't do this
> by doing what is described above.  You can UUEncode it, but A LOT of
> mail clients don't support UUEncoding anymore.  Plus, you can attach
> multiple binary files with email, not just one UUEncoded file.  For
> instance:
> uuencode file.bin | gpg --clearsign | mail 

OTOH, the above features seem useful.

> First of all, it's only one file.  Second of all, it's using a
> --clearsign and not the way email does it.  I believe it was you who
> suggested email sign/encrypt messages such as Ximian and Outlook does. 
> This is the way the majority of modern mail reader clients view such
> data.  So in short:

> The command line way you are suggesting violates modern RFC compliant
> mail reader clients.  However, email follows RFC's 821, 2015 (PGP
> Encryption), 2045, and soon 2554.

Outlook is not a modern mail reader.  It *certainly* doesn't know what
to do with PGP/MIME messages.  In light of this, I think providing tools
that allow users to more easily generate PGP/MIME messages is a good
thing.

> 3. Change the name from email to something else. 
> Upstream does not want to do this, as the name has been in use since
> 2001, with an established user base. Apparently (for what it is worth)
> it has been used in Slackware with this name.

I've been using email since 1994, and have never heard of this software.
I'm sure many here have other examples of prior art.

-- 
Steve Langasek
postmodern programmer


pgpxhXgo4Mx7k.pgp
Description: PGP signature

Re: Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption

[Falk Hueffner]

"Benj. Mako Hill" <[EMAIL PROTECTED]> writes:

> On Fri, Jun 27, 2003 at 12:32:59AM +0100, Millis Miller wrote:
> > Package: wnpp
> > Version: N/A; reported 2003-06-27
> > Severity: wishlist
> > 
> > * Package name: email
> 
> I understand that email is the name of the upstream client but I'd
> like to urge you to reconsider keeping this name while the program is
> in Debian.

Fortunately, this is no problem, since the license
(http://email.cleancode.org/download/COPYING) doesn't allow
redistribution anyway and so it cannot even go to non-free.

-- 
Falk

Re: How to Avoid GPL Issue

[Christoph Haas]

On Thu, Jun 26, 2003 at 10:27:40PM -0400, G. C. wrote:
> Currently we are trying to port some third party code to Linux kernel. Some 
> modules of third party code need to be ported into Linux kernel and some 
> drivers need to be ported from Vxworks to Linux drivers. The problem we 
> have is that this third party does not allow us to publicize its code as 
> Linux GPL requires.
> 
> Is there any approach that we can avoid publicizing the third party code 
> while porting to Linux? Do we need to write some shim layer code in Linux 
> kernel to interface the third party code? How can we do that? Is there any 
> document or samples?

You could provide a binary kernel module for every architecture and
kernel version. Some graphic card manufacturers do this with their
drivers. You need to know how kernel building works. As an example you
could take the NVidia graphic card drivers for Linux.

> Your assistance is deeply appreciated,

So is your real name.

 Christoph

-- 
~
~
".signature" [Modified] 3 lines --100%--3,41 All

Re: debootstrapping and sysvinit

[Andreas Metzler]

Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> I've received several reports that debootstrap of sid has not been
> possible recently due to sysvinit.

> I guess the problem is that sysvinit related postinst 
> scripts are calling 'init' inside chroot, which fails,
> failing the whole installation process.
[...]

The latest[1] version of sysvinit, an NMU, fixed this, apt-get upgrade
inside the chroot worked again yesterday. IMHO this is the right way
to fix this, because it broke not only debootstrap but our regular
sid-chroots.
   cu andreas

Re: Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption

[Benj. Mako Hill]

On Fri, Jun 27, 2003 at 12:32:59AM +0100, Millis Miller wrote:
> Package: wnpp
> Version: N/A; reported 2003-06-27
> Severity: wishlist
> 
> * Package name: email
>   Version : 1.9.0
>   Upstream Author : Dean Jones <[EMAIL PROTECTED]>
> * URL : http://www.cleancode.org/email
> * License : Custom
>   Description : Send email from command line, either via MTA or
>   SMTP, with optional encryption
> 
> email is a simple command-line program to send emails. It can be
> configured to use either your sendmail installation or directly via
> smtp.   .   Also, if gpg is installed, it can digitally sign and
> encrypt outgoing emails.

I understand that email is the name of the upstream client but I'd
like to urge you to reconsider keeping this name while the program is
in Debian. In fact, I'd like to urge to consider contacting the
upstream author to have them change the name upstream as well. In
addition to being totally unoriginal, the name is hopelessly generic
and, as a result, quite confusing. It's unclear whether we are talking
about email, the client, or email, the larger concept.

This isn't the first time this has come up. You should review previous
discussions on the subject[1] in the archives.

On a related note, it makes reading the upstream homepage mind
numbing.  The page is peppered with link text like "Download Email",
and "Home of Email" that are confusing at best.

Does "Email Man Page" email the man page or is it the man page for
email -- and it's about how to use email the client, not email in
general right? If you want to email the authors, you click on one of
the two links *without* the word "email" in the title. 

Regards,
Mako


[1] http://lists.debian.org/debian-devel/2001/debian-devel-200107/msg01845.html

-- 
Benj. Mako Hill
[EMAIL PROTECTED]
http://mako.yukidoke.org/



pgpqD6iBPWggg.pgp
Description: PGP signature

Re: debootstrapping and sysvinit

[Michael Koch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Samstag, 28. Juni 2003 04:09 schrieb Junichi Uekawa:
> Hi,
>
> I've received several reports that debootstrap of sid has not been
> possible recently due to sysvinit.
>
> I guess the problem is that sysvinit related postinst
> scripts are calling 'init' inside chroot, which fails,
> failing the whole installation process.
>
>
> The possible alternatives seem to be:
>
> 1. hack debootstrap to work around it
> 2. hack sysvinit to work around it
> 3. hack debootstrap/sysvinit so that sysvinit will know that
> postinst is running inside chroot and not try to run 'init'
> directly.
>
>
> But I'm not quite confident which way to go.
>
> The goal is to make Debian installable. Comments?

I had the same problem in my chroots. This was fixed with the latest 
upload of sysvinit. Now it does the following:

init u || true

With this postinst doesnt fail.


Michael
- -- 
Homepage: http://www.worldforge.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+/XReWSOgCCdjSDsRAu33AJ9yJnYkdG5PnYy3lGBg5WOoOW9RcwCgjYlo
CeiPJ13p/ORyvmjuLvtzT5E=
=j34I
-END PGP SIGNATURE-

Re: inews path question

[Bernd Eckenfels]

On Sat, Jun 28, 2003 at 10:26:08AM +0200, Andreas Metzler wrote:
> Afaik the basic mode of operation and options are compatibel,
> inews even diverts the inews from cnews. Using alternatives sounds
> nice.

and of course it must be installed in /usr/sbin/ in that case, just like
/usr/sbin/sendmail.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: Garbled messages received from lists.d.o.

[Josip Rodin]

On Fri, Jun 27, 2003 at 08:54:30AM -0700, Philippe Troin wrote:
> I have been receiving bugs.d.o emails which are unrelated to my
> package for the last two-three days.

That would be because you're subscribed to
debian-bugs-{dist,closed,forwarded}...

> And their headers seem quite garbled: they include part of other
> messages...

That's one of the bugs that surfaced recently due to the resource problems
on the list server. The problem has now been tracked down but not fully
fixed -- working on it. I'll post something to -devel-announce when all is
well again.

-- 
 2. That which causes joy or happiness.

Re: How to Avoid GPL Issue

[Mathieu Roy]

"G. C." <[EMAIL PROTECTED]> a tapoté :

> Dear Sir or Madam,
> 
> Currently we are trying to port some third party code to Linux
> kernel. Some modules of third party code need to be ported into Linux
> kernel and some drivers need to be ported from Vxworks to Linux
> drivers. The problem we have is that this third party does not allow
> us to publicize its code as Linux GPL requires.
> 
> Is there any approach that we can avoid publicizing the third party
> code while porting to Linux? Do we need to write some shim layer code
> in Linux kernel to interface the third party code? How can we do that?
> Is there any document or samples?
> 
> Your assistance is deeply appreciated,


Hi,

As far I know, this list is related to Debian GNU/Linux development,
not to the linux software. So your message is off-topic.

Anyway, the better approach, IMHO, is to convince this third party to 
publicize its code. As a "Linux lover", I'm sure you understand that a
reason of the success of this kernel is the way the code is
publicized. 



-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: Application files in $HOME

[Mathieu Roy]

Richard Braakman <[EMAIL PROTECTED]> a tapoté :

> I have a better idea :)  What if packages don't leave droppings in my
> home directory in the first place?  I have all sorts of dotfiles (and
> even dot-directories) that I never asked for.  It's reasonable for a
> program to install a dotfile when I configure it differently from the
> default, but there's no reason to create a dotfile that's identical
> to the default.

Example?

Gimp and many others software creates dotfiles. Because from the start
you configure it (cache size, temp dir).

> In addition to being annoying in themselves,

How?
For their size? Apart from web browser cache, what can be so big?


> such useless dotfiles get in the way when a newer version has
> different defaults or incompatible configuration fields.

Well designed software that change their configuration file should be
able to handle an older configuration file.


> When I do configure a program (if it doesn't have an interactive
> configuration interface), I want to do it by creating a small,
> human-editable file that contains the _differences_ from the
> defaults.  So even then I have no use for a copy of the default
> configuration.  (If I want an example, I can look in
> /usr/doc/$foo/examples, which is a better place for it than $HOME.)

You want to make your copy from a file in /usr/doc/$foo/examples. 
I'm not sure that what most users want to do. 

I'm pretty sure that people using kmail are happy to have a GUI to
configure their mail account, for instance. 





-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: inews path question

[Andreas Metzler]

Joey Hess <[EMAIL PROTECTED]> wrote:
> I maintain slrn, which can run inews to post news. We apparently have
> three inews programs in debian; inewsinn puts it in /usr/bin/inews,
> while inews and cnews put it in /usr/lib/news/inews.

Actually inewsinn puts it in /usr/lib/news/bin/, /usr/bin/inews is
just a symlink, but that does not help you.

> My question is how is a program like slrn supposed to find an inews
> program to run? If it searches PATH it will only find inewsinn's
> inews. Of course the user can configure it (via inews_program in the
> rc file) to use any inews program, but this is an extra step to get
> working news posting. Would an alternative make sense for inews?

Afaik the basic mode of operation and options are compatibel,
inews even diverts the inews from cnews. Using alternatives sounds
nice.
   cu andreas

Re: Proposal: removing libc5, altgcc and all their old-days dependencies

[Sven Luther]

On Thu, Jun 26, 2003 at 10:44:11PM +0200, Mathieu Roy wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> a tapoté :
> 
> > On Thu, Jun 26, 2003 at 12:21:22AM +1000, Hamish Moffatt wrote:
> > > On Sun, Jun 22, 2003 at 10:49:54AM +0200, Bernd Eckenfels wrote:
> > > > On Sun, Jun 22, 2003 at 10:23:01AM +0200, Sven Luther wrote:
> > > > > Tell me, you seriously think that there is a libc5 program still 
> > > > > around
> > > > > that uses DRI ? Hell, libc5 was abandoned well before DRI even 
> > > > > existed.
> > > > 
> > > > the only libc5 program I do use is netscape 4.77 because it is 
> > > > compatible to
> > > > some pages where mozilla/opera/konquerror fails. I would hate to 
> > > > reboot, to
> > > > just open that page.
> > > 
> > > Tried mozilla recently? It's a thousand times better than Netscape 4.7x
> > > was... Although I've still had it vanish a couple of times recently. It
> > > doesn't hang like NS though.
> > 
> > There are some sites that still require Netscape 4.77. A good example is
> > an online banking site here in Belgium, which 'supports' Linux, but you
> > need to use Netscape to be able to use that site.
> 
> 
> With the current mozilla version, everything that works with a
> netscape 4.x works with mozilla.
> 
> If not, write them to work on w3c standards compliances.

And they will respond, but nobody uses mozilla anyway, see  only 0.67 % of the accesses are with mozilla, so we are
going to support what people use.

They don't even mention that if the web site doesn't work with mozilla,
nobody is going to access it with it, and thus the statistic are
meaningless.

Friendly,

Sven Luther

but I want the GNU versions of packages

[Dan Jacobson]

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?

Last year I discovered mawk sitting there until I banished it away with
apt-get install gawk.

Yesterday I realized I had been using mailx all this time while GNU's
mailutils were sitting unused.

Do I look in Packages.gz for Conflicts:, and then look in Description:
for "this is the GNU version of..."?

What other other leading brands programs are sitting on my computer
when I could have been using a genuine GNU program?

What genuine GNU programs should I defer, lest e.g. messages get trunc

Content rejected.

[spambody]

Content rejected.

Based on an automated review of the content in a message you sent,
the message appears to be unsolicited commercial e-mail or to contain
content that we deem inappropriate for our business environment. The
message has been blocked from delivery.  If you feel you received
this message in error, please forward this message, the address that
you are trying to send to, and any questions to [EMAIL PROTECTED]


Received: from SMTP32-FWD by imail.duda.com
  (SMTP32) id A0BD8; Sat, 28 Jun 2003 00:15:16 -0400
Received: from ov7.duda.com [10.1.1.11] by imail.duda.com
  (SMTPD32-7.15) id A6459F250136; Sat, 28 Jun 2003 00:15:01 -0400
Received: from psmtp.com ([12.158.35.153])
 by ov7.duda.com (SAVSMTP 3.1.0.29) with SMTP id M2003062800144626199
 for <[EMAIL PROTECTED]>; Sat, 28 Jun 2003 00:15:00 -0400
Received: from source ([146.82.138.6]) by exprod6mx13.postini.com 
([12.158.35.251]) with SMTP;
Sat, 28 Jun 2003 00:14:46 EDT
Received: from localhost (localhost [127.0.0.1])
by murphy.debian.org (Postfix) with QMQP
id B420A1F49D; Fri, 27 Jun 2003 07:20:15 -0500 (CDT)
Old-Return-Path: <[EMAIL PROTECTED]>
Received: from master.debian.org (master.debian.org [146.82.138.7])
by murphy.debian.org (Postfix) with ESMTP id 4F5891F434
for ; Fri, 27 Jun 2003 06:30:03 
-0500 (CDT)
Received: from debbugs by master.debian.org with local (Exim 3.35 1 (Debian))
id 19VrQZ-00088u-00; Fri, 27 Jun 2003 06:30:03 -0500
Date: Fri, 27 Jun 2003 06:30:03 -0500
From: BugScan reporter <[EMAIL PROTECTED]>
To: debian-devel-announce@lists.debian.org
Subject: Release-critical Bugreport for June 27, 2003
Message-ID: <[EMAIL PROTECTED]>
Reply-To: debian-devel@lists.debian.org, [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.28i
Sender: Debian BTS <[EMAIL PROTECTED]>
X-Debian-Message: RC bugreport check passed
Mail-Followup-To: debian-devel@lists.debian.org
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-From: debian-devel-announce@lists.debian.org
X-Mailing-List:  
X-Loop: debian-devel-announce@lists.debian.org
List-Id: 
List-Post: 
List-Help: 
List-Subscribe: 
List-Unsubscribe: 
List-Archive: 
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
Resent-Date: Fri, 27 Jun 2003 07:20:15 -0500 (CDT)
X-Declude-Sender: [EMAIL PROTECTED] [12.158.35.153]
X-Declude-Spoolname: D16459f2501361e1d.SMD
X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam.
X-Spam-Tests-Failed: Whitelisted [0]

Re: Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption

[Adam Heath]

On Fri, 27 Jun 2003, Millis Miller wrote:

> Package: wnpp
> Version: N/A; reported 2003-06-27
> Severity: wishlist
>
> * Package name: email
>   Version : 1.9.0
>   Upstream Author : Dean Jones <[EMAIL PROTECTED]>
> * URL : http://www.cleancode.org/email
> * License : Custom
>   Description : Send email from command line, either via MTA or SMTP, 
> with optional encryption
>
> email is a simple command-line program to send emails. It can be
> configured to use either your sendmail installation or directly via
> smtp.
>  .
>  Also, if gpg is installed, it can digitally sign and encrypt outgoing
> emails.

Do I even need to say it?

unsubscribe

[Leo Cadle]

Re: Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption

[Rene Engelhard]

Hi,

Millis Miller wrote:
> Package: wnpp
> Version: N/A; reported 2003-06-27
> Severity: wishlist
> 
> * Package name: email
>   Version : 1.9.0
>   Upstream Author : Dean Jones <[EMAIL PROTECTED]>
> * URL : http://www.cleancode.org/email
> * License : Custom
>   Description : Send email from command line, either via MTA or SMTP, 
> with optional encryption

Hmm.. A little bit long, no?

> email is a simple command-line program to send emails. It can be 
> configured to use either your sendmail installation or directly via
> smtp.
>  .
>  Also, if gpg is installed, it can digitally sign and encrypt outgoing 
> emails.

How is that (except that mail uses the local sendmail) different from:

echo "foo" | gpg --clearsign | mail -s "subject" [EMAIL PROTECTED] or
cat mailtxt | gpg --clearsign | mail -s ... or
cat mailtxt.signed | mail -s 

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73
  


pgpyRNbUULUlG.pgp
Description: PGP signature

Re: EPSON appreciates your feedback by June 30, '03 - Debian

[Farideh Sherbaf]

Hi Torsten,
 
Thank you for your feedback.  I 
have sent your email to Olaf Meeuwissen, the Lead Developer 
for Image Scan! for Linux at EPSON Kowa. 
 
Please feel free to contact him if you 
have any related questions specific to iScan.  Otherwise, I am always here 
to help.
 
Best regards,
 

Ms. Farideh Sherbaf Sr. Product 
EngineerEPSON Worldwide Developer Relations150 River Oaks Parkway, Suite 
#200San Jose, CA 95134Tel:  408-576-4135Fax: 
408-474-0511E-mail:  [EMAIL PROTECTED]~~~
 

  - Original Message - 
  From: 
  Torsten 
  Landschoff 
  To: Farideh Sherbaf 
  Cc: debian-devel@lists.debian.org 
  ; Ray 
  Hsu ; Farideh Sherbaf 
  Sent: Tuesday, June 24, 2003 10:14 
  AM
  Subject: Re: EPSON appreciates your 
  feedback by June 30, '03 - Debian
  Hi Farideh, On Mon, Jun 23, 2003 at 04:15:25PM -0700, 
  Farideh Sherbaf wrote:> Please allow me to introduce myself.  My 
  name is Farideh Sherbaf and I> am your contact for EPSON Worldwide 
  Developer Relations for scanners> and All-In-One (Multifunction) 
  products.   The EPSON Developer> Relations Group would like 
  to obtain your feedback on your support of> scanners in the Linux 
  environment.   Let me add to Juliens opinion a note from a 
  user of those scanner tools:I own an Epson 1640SU scanner with 
  automatic document feeder. And it is really great to have it supported by 
  Linux. With the scanimage toolwe wrote a script to scan our lecture notes 
  and generate PDF files in notime - something we failed to implement with 
  *cough* Windows.It really helps to have them archived in binary form 
  instead of paper soa big thank you for making it possible by at least 
  providing developmentinformation for your 
  hardware.GreetingsTorsten

Re: How to Avoid GPL Issue

["Martin v. Löwis"]

G. C. wrote:
Is there any approach that we can avoid publicizing the third party code 
while porting to Linux? Do we need to write some shim layer code in 
Linux kernel to interface the third party code? How can we do that? Is 
there any document or samples?
In general, this is not possible. It is also intentional: One primary
goal of the GPL is to require derived work to be published, so it would
be quite unfortunate if you could work around this with dirty tricks.
The only way to avoid publishing the source is to avoid distributing
the binary. You only have to offer the source whoever you provide the
binaries.
Regards,
Martin

Re: Application

[Joanne Kane]

Please confirm your identity, otherwise I will not open this file.
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

Re: Application

[Joanne Kane]

Please confirm your identity, otherwise I will not open this file.
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

Re: Please don't misuse the debian/changelog to close bugs!

[Herbert Xu]

Brian Nelson <[EMAIL PROTECTED]> wrote:
> 
> Huh?  The bug report was a feature request with a patch.  The bug was
> closed with the description of "New Upstream Release".  No indication
> was given whether the patch was integrated upstream, or implemented
> differently (with a different interface).  I don't consider this
> information "documentation of random features".

The bug report is ultimately about the adding of a feature.  The bug
closure indicates that this feature has been added.  The fact that how
that feature is implemented is a documentation issue.
 
> Uhh, I didn't.  In fact, *you* are the one trying to dictate what goes
> in upstream changelogs, which is utterly pointless.  Every upstream is
> different, and Debian has absolutely no control what upstream decides to
> put in their changelogs.  That's why we must standardize[1] our changelog
> entries, so that the pertinent information will be available regardless
> of what upstream does.

Are you proposing that we list important upstream changes regardless of
whether they fix bugs or not?

If so then this may be worth considering.

But it is a major departure from what you have been arguing in the past.

However, if you're listing upstream changes in debian/changelog on the
basis that they close Debian bugs, then I disagree completely since this
is in no way representative as to how the package has changed.  It's
merely supplying information for the BTS which is not needed.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Bug#198158: architecture i386 isn't i386 anymore

[Emile van Bergen]

Hi,

On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote:

> On Wed, 25 Jun 2003 14:04:54 -0500
> Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> > And not only 80386 needs this - There is the Sparc64 port which would
> > also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we
> > had support for subarchtectures, not only would the ix86 mess be able to
> > be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever
> > you fancy). And I am sure this can somehow help maintain the non-Linux
> > ports - NetBSD gives us the potential to bring Debian to _many_ new
> > platforms. 
> 
> No it doesn't. I've yet to even hear of an architecture that NetBSD runs
> on but which Linux doesn't. They just have a different definition of
> "architecture" than us. (ie: our "hppa" may be three or four arches to
> the NetBSD kernel folk.)

Turbochannel machines? VAXen?

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen   [EMAIL PROTECTED]  
tel. +31 (0)70 3906153   http://www.e-advies.nl

Re: Bug#189329: ITP: gnome-swallow - meta-applet to embed any application in the GNOME panel

[Stefano Zacchiroli]

On Thu, Jun 26, 2003 at 05:53:27PM +0200, Josselin Mouette wrote:
> The swallow applet can "eat" any X11 window into the GNOME 2 panel. The
> application then displays inside the panel instead of being in a window.
> 
> Its primary goal is to allow use of dockapps with the GNOME desktop.

Just for the matter of curiosity: what happens if a big window is eaten?
Does the gnome panel become as big as the original window?

Cheers.

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney


pgpj3qNMcOqbv.pgp
Description: PGP signature

Norton AntiVirus detected and quarantined a virus in a message you sent.

[NAV for Microsoft Exchange-IVAEXMS]

Recipient of the infected attachment:  Byers, Matthew E\Inbox
Subject of the message:  Re: Application
One or more attachments were quarantined.
  Attachment your_details.zip was Quarantined for the following reasons:
Virus UNAUTHORIZED FILE was found.
<>

Re: [proposal] subarchitectures (was: Bug#198158: architecture i386 isn't i386 anymore)

[Michael Banck]

On Thu, Jun 26, 2003 at 08:29:41PM -0500, Adam Heath wrote:
> On Thu, 26 Jun 2003, Michael Banck wrote:
> 
> > Also, please note that at least half of the dpkg-maintainers don't read
> > -devel, you probably want to post this to -dpkg. Incidently, there is a
> > proposal and patch by Gerhard Tonn for handling lib64 under
> > discussion[2].
> 
> Well, considering there are most likely only 2 dpkg maintainers(of which I am
> one), and I read your mail, does that mean the other isn't on this list?

:)

Wiggy told me multiple times that the only debian list he was on was
-dpkg (and probably -devel-announce) these days. Perhaps he changed his
mind recently, dunno.


Michael

Problem with advocating new prospective delevolper.

[Janusz A. Urbanowicz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm trying to advocate a developer, although my recomendation bounces from
nm.debian.org, with following message:

This message was created automatically by mail delivery software (Exim).

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pipe to |/org/nm.debian.org/bin/advocate_check
generated by recommend<@>nm.debian.org
pipe delivery process timed out

Alex
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE++/Asi2676t/eTc4RAsFYAKCNVv0b98/p9mxwDUUFeSKVSK9MYgCfbyyj
ptGYb5jXgtCsRoopf0Ivz6Q=
=LqH4
-END PGP SIGNATURE-

Re: Bug#198479: general: perlapi-5.6.1 missing in sarge since perl 5.8.0 rollout

[Adam Heath]

On Sat, 28 Jun 2003, Mark Hedges wrote:

> Package: general
> Version: unavailable; reported 2003-06-28
> Followup-For: Bug #198479
>
> There needs to be a backwards-compatible perlapi-5.6.1 module
> which apt-file and other depend on to install.  Since rolling
> out perl 5.8.0, many packages that depend on perl 5.6.1 components
> have broken or will not install.

Please file bugs on packages that still require 5.6.1.

Bug#198158: architecture i386 isn't i386 anymore

[David Weinehall]

On Fri, Jun 27, 2003 at 02:08:46PM -0400, Nathanael Nerode wrote:
> >* what opcodes need to be emulated?
> 
> >* all 386->486 opcodes (there's just a few of them, right?)
> This is the correct answer. :-)  Then all programs can be compiled with
> gcc --arch=i486 --tune=i686 (which should probably be mandated as the 
> standard, in fact).
> 
> >* do you need SMP on 80386?  Is there even such thing as 80386 SMP
> >  machines?  Not requiring SMP support would make the ABI change 
> >  trivial...
> I think there is no such thing as SMP for 80386.

There is afaik. Not in widespread use though, and the Linux kernel
hasn't been ported to that hardware.  I think we can safely ignore
this hardware without stepping on anyone's toes...


/David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/

Bug#199266: ITP: ffmpeg -- multimedia streaming system

[Sam Hocevar]

Package: wnpp
Version: unavailable; reported 2003-06-29
Severity: wishlist

   Since the ffmpeg ITP (#157719) was closed almost one year ago, I
assume no one is interested anymore, thus this ITP. I use ffmpeg daily
and I am not satisfied with the reasons given for closing the ITP. If
anyone disagrees I'll gladly elaborate.

* Package name: ffmpeg
  Version : upcoming 0.4.7, probably latest CVS snapshot
  Upstream Author : Fabrice Bellard et al.
* URL : http://ffmpeg.sf.net/
* License : GPL (but see notes below)
  Description : multimedia streaming system

Package: ffmpeg
Description: converter for audio and video formats
 FFmpeg is a very fast video and audio converter. It can work on files but
 also grab from a live audio/video source.
 .
 FFmpeg can convert from any sample rate to any other, and resize video on
 the fly with a high quality polyphase filter.

Package: ffserver
Description: multimedia streaming server
 FFserver is a streaming server for both audio and video. It supports
 several live feeds, streaming from files and time shifting on live
 feeds (you can seek to positions in the past on each live feed).

Package: libavcodec-dev
Description: FFmpeg's audio/video codec library
 FFmpeg is a complete solution to record, convert and stream audio and
 video. This package includes libavcodec, the leading audio/video codec
 library.


Notes:

   There will be no ffserver package at first because it is slightly
broken at the moment.

   Also, libavcodec optionally links with GPL libraries. I will build
with support for those libraries that are already in Debian (hence the
License: GPL), but will also provide _lgpl variants (à la libart-dev).
And since the API is not stable, PIC libs will be static (_pic.a) instead
of shared.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686
Locale: LANG=C, LC_CTYPE=fr_FR