how about calling potato "legacy"

[Paul Baker]

Just an idea. Now that woody is stable. I see references to potato being 
called "oldstable". For instance in the changelogs for potato security 
updates, the dist is oldstable-security. Looks kind of ugly to me. 
Perhaps a better name might be "legacy". Anyone agree? I'm not aware of 
how big a change this would be for the ftpmasters. Flame on!

--
Paul Baker
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety."
 -- Benjamin Franklin, 1759

GPG Key: http://homepage.mac.com/pauljbaker/public.asc

(fwd) uucp_1.06.1+1.07beta1-patch2-2_powerpc.changes REJECTED

[Peter Palfrader]

Could whoever is responsible for that upload please set their name as
uploader/builder next time. They also might want to actually sign the
package as well as upload to auric rather than pandora.

TIA.

- Forwarded message from Debian Installer <[EMAIL PROTECTED]> -

From: Debian Installer <[EMAIL PROTECTED]>
To: Peter Palfrader <[EMAIL PROTECTED]>
Date: Fri, 16 Aug 2002 03:47:07 +0200
Message-Id: <[EMAIL PROTECTED]>


Rejected: no signature found in uucp_1.06.1+1.07beta1-patch2-2_powerpc.changes.
Rejected: no valid distribution.
Rejected: no source found for uucp 1.06.1+1.07beta1-patch2-2 
(cu_1.06.1+1.07beta1-patch2-2_powerpc.deb).
Rejected: no source found for uucp 1.06.1+1.07beta1-patch2-2 
(uucp_1.06.1+1.07beta1-patch2-2_powerpc.deb).

[..]

- End forwarded message -

yours,
peter

-- 
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
messages preferred.| : :' :  The  universal
   | `. `'  Operating System
 http://www.palfrader.org/ |   `-http://www.debian.org/


pgpPVLc37dy4H.pgp
Description: PGP signature

Re: Next Debconf

[Andreas Tille]

On 15 Aug 2002, Tollef Fog Heen wrote:

> I am planning Debconf 3 to be held in Oslo, from Friday July 18th to
> Sunday July 20th.
Great!
I guess this would not conflict with LSM (Bordeaux) or LinuxTag (Karlsruhe)
because this is traditionally earlier (even if there are no dates fixed).

> Joeyh hess mentioned a good idea in the DebConf2 post-mortem thread:
>
> : What I wouldn't mind seeing is 2 or 3 days either before or after
> : the next one that lack talks and are just there for ad-hoc
> : discussion and face time and hacking. It was nice to have the talks
> : but I really went for the other 3 items. Call it 'debcamp' or
> : something. Extra organizational overhead should be near-zero; the
> : people who stay on for debcamp just use the same facilities as does
> : the conference.
Very good idea.

> Since this will be the weekend after cofsino (Conference on Free
> Software in Norway), I'll try to get a debcamp thingy before DebConf.
> Hopefully it can be a full week, but I guess people can show up in the
> middle of the week if they'd like to.
Very good plan to realize the idea ;-).

> Please don't ask for a lot of details yet -- things are still
> forming.
:) But what about the details? ;-)

> I'll post stuff on d-d-a when they are ripe.
>
> If you want to hold a presentation, don't hesitate to contact me.
I would like to geive a presentation about Debian Internal Projects
(which hopefully will be quite advanced than currently...).

Kind regards and thanks for your effort

   Andreas.

Re: reinstall of kernel-image fails

[Kalle Valo]

Daniel Wagner <[EMAIL PROTECTED]> writes:

> waring about the modules, but then postrm failed and the package
> remained in half-installed state, no chance to change that. How can i
> fix up this mess?

It's a small typo in postrm, which can be fixed manually. See bugs
#156579 and #156853.

PS. I hope that water levels start to be getting down in your country.
I have seen the floods on TV and they were immense.

-- 
Kalle Valo

Re: Move to python 2.2 as default release?

[Laura Creighton]

> On Aug 14, Laura Creighton wrote: 
> > The new Python Business Forum (www.python-in-business.com) is 
> 
> what is this? The link is dead. Is this the former PSA?

No.  My brain was tired -- it was python-in-business.org.  Apologies.
We are new.  We are a Business Non-Profit Society 'to organise and
further the interests of companies that base their business on Python'.
Membership is extremely reasonable (20 Euros) and we had our first
general Assembly at Europython.  For more info, see the correct
address.

Sorry about that again,
Laura Creighton

unsubscribe

[Gnanasekaran Thoppae]

unsubscribe

Re: reinstall of kernel-image fails

[Daniel Wagner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kalle Valo <[EMAIL PROTECTED]> writes:

> Daniel Wagner <[EMAIL PROTECTED]> writes:
> 
> > waring about the modules, but then postrm failed and the package
> > remained in half-installed state, no chance to change that. How can i
> > fix up this mess?
> 
> It's a small typo in postrm, which can be fixed manually. See bugs
> #156579 and #156853.
> 

Yes, thx. I've already figured out how to handle it. Everything works
fine now.

> 
> PS. I hope that water levels start to be getting down in your
> country.  I have seen the floods on TV and they were immense.
> 

Thx, luckily my house didn't get flooded but some of my friends really
have troubles.

- -- 
God is real - unless declared integer.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 

iD8DBQE9XKrLw4dB3BTf+woRAh1tAKDkUKMaN5O/KeSq0KHfS1dNNG2DHACg5WWZ
+MxEeMgDHap8aCrEpfPoOPc=
=AP5v
-END PGP SIGNATURE-

Urlaubsgrüsse aus Mallorca

[Birgit Langhorst]

sorry,
hatte dir die falsche adresse 
geschoickt
 
die richtige ist: http://biggimaus.5xx.net
Birgit
email: [EMAIL PROTECTED]
 
ps: hast du schon die neuen bilder auf meiner 
homepage gesehen?

KDE for Debian

[Björn]

Hi!

I want to know where I can get KDE packages for my Debian system.
I'm currently running Debian2.2r5. This is quite important since
I really lack a good mail client, I miss Kmail! :(


Kind regards  Björn Johansson

Re: list of valid distributions in Debian changelog file.

[Wichert Akkerman]

Previously Peter S Galbraith wrote:
> Hi,  What are the currently valid distribution to which we can make
> uploads to?

I think the list currently is:

unstable experimental stable-proposed-updates stable-security
testing-proposed-updates testing-security test

Some combinations of those are possible although not recommended I
think. I can't think of any reasonably combination at least :)

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.wiggy.net/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: KDE for Debian

[Josip Rodin]

On Fri, Aug 16, 2002 at 12:44:13PM +0100, Björn Johansson wrote:
> I want to know where I can get KDE packages for my Debian system.
> I'm currently running Debian2.2r5. This is quite important since
> I really lack a good mail client, I miss Kmail! :(

If you upgraded your Debian system to 3.0, you would be able to install KDE.
For upgrading instructions, check
http://www.debian.org/releases/stable/releasenotes

In fact, kmail would be just one apt-get install kmail install :)

Note also that this mailing list, debian-devel, is meant for development
questions and not questions about using Debian. Next time please use
debian-user.

-- 
 2. That which causes joy or happiness.

ZINF pkgs crashing dpkg - please test

[Andreas Rottmann]

Hi!

I finished a first version of my ZINF packages (ZINF is not FreeA*p).

They seem to reproducibly cause a dpkg degfault on my machine when
doing the following:

~# apt-get install freeamp freeamp-extras libfreeamp-esound
~# dpkg -i --auto-deconfigure zinf_2.2.0-1_i386.deb 
zinf-extras_2.2.0-1_i386.deb zinf-plugin-esound_2.2.0-1_i386.deb

On my machine this dpkg crashes like this:

Selecting previously deselected package zinf.
dpkg: considering removing freeamp in favour of zinf ...
dpkg: yes, will remove freeamp in favour of zinf.
(Reading database ... 101551 files and directories currently installed.)
Unpacking zinf (from zinf_2.2.0-1_i386.deb) ...
De-configuring freeamp-extras, so that we can remove freeamp ...
De-configuring libfreeamp-esound, so that we can remove freeamp ...
Segmentation fault

Could (esp. FreeAmp users) please try to install my packages
(available from http://student.cosy.sbg.ac.at/~arott/dpkg-crash/) like
this? If dpkg crashes, you can recover like this:

~# dpkg --configure -a
~# apt-get -f install

If i get no crash reports 'till Monday, I will upload my ZINF
packages, assuming this is a local problem.

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: Bug#156852: ITP: ttf-dustismo -- general purpose gpl'ed truetype sans serif font

[christophe barbé]

On Thu, Aug 15, 2002 at 03:34:32PM -0700, Michael Cardenas wrote:
>   You will need xfs-xtt to view this font properly.

This is plain wrong. Since XFree86 4.0 we don't need xfs-xtt to use a
True-Type font.

Please don't put this sentence in your description.

Christophe 

-- 
Christophe Barbé <[EMAIL PROTECTED]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

There's no sense in being precise when you don't even know what you're
talking about. -- John von Neumann


pgplO8gDu18MF.pgp
Description: PGP signature

Re: ZINF pkgs crashing dpkg - please test

[Martin Michlmayr]

* Andreas Rottmann <[EMAIL PROTECTED]> [2002-08-16 13:44]:
> If i get no crash reports 'till Monday, I will upload my ZINF
> packages, assuming this is a local problem.

How did you test the packages when you cannot even install them?
-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: ZINF pkgs crashing dpkg - please test

[Simon Law]

On Fri, Aug 16, 2002 at 01:44:30PM +0200, Andreas Rottmann wrote:
> If i get no crash reports 'till Monday, I will upload my ZINF
> packages, assuming this is a local problem.

You most certainly want to test this in a chroot environment.
May I suggest using debootstrap or pbuilder to do this.  Please do not
upload your packages until you are sure that they work properly.

Thanks for doing proper QA!

Simon

Re: ZINF pkgs crashing dpkg - please test

[Andreas Rottmann]

> "Martin" == Martin Michlmayr <[EMAIL PROTECTED]> writes:

Martin> * Andreas Rottmann <[EMAIL PROTECTED]> [2002-08-16 13:44]:
>> If i get no crash reports 'till Monday, I will upload my ZINF
>> packages, assuming this is a local problem.

Martin> How did you test the packages when you cannot even install
Martin> them?  -- Martin Michlmayr [EMAIL PROTECTED]

I can in fact install them, if i re-run dpkg -i --auto-deconfigure,
after dpkg has crashed.

Gtx, Andi
-- 
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: ZINF pkgs crashing dpkg - please test

[Andreas Rottmann]

> "Simon" == Simon Law <[EMAIL PROTECTED]> writes:

Simon> On Fri, Aug 16, 2002 at 01:44:30PM +0200, Andreas Rottmann
Simon> wrote:
>> If i get no crash reports 'till Monday, I will upload my ZINF
>> packages, assuming this is a local problem.

Simon>  You most certainly want to test this in a chroot
Simon> environment.  May I suggest using debootstrap or pbuilder
Simon> to do this.  Please do not upload your packages until you
Simon> are sure that they work properly.

Good idea, thx I already built a version using pbuilder and checked that
on my machine, but still the same crash happens.

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

GCC 3.2 transition

[Matthew Wilcox]

I got sick of listening to people discuss the gcc 3.2 transition in an
uninformed manner.  So I've whipped up a transition plan which will
hopefully get us from A to B without causing too much pain.  Haha.
I'm entirely fallible and I don't pretend to understand all the issues
involved with doing the transition.  But by writing down a plan at
least it can be updated and fixed before we have to start _doing_
the transition.

Comments and corrections welcomed.  The most up to date version of
this document is at http://people.debian.org/~willy/c++transition.html
The following is the output from lynx -dump.

-
  The Debian GCC 3.2 Transition Plan

This is a proposal. You will be notified when this is a real plan

   Note! m68k and arm have not yet uploaded gcc-3.2. Until they do, we
   cannot start this transition! 

   Note! We need to check glibc and binutils work properly with gcc-3.2
   on all architectures! Until this is done, we cannot start this
   transition! 

   Why do we need one?

   Because GCC 3.2 changed the C++ ABI. You can't mix a C++ library
   compiled with GCC 3.2 and a C++ application compiled with an earlier
   version, or vice versa.

   Transitions are painful. This will be no exception. The rules here are
   designed to make it as smooth as possible, but it's still going to be
   unpleasant. We have to do it, we can't stay with g++ 2.95 for ever.

This is a proposal. You will be notified when this is a real plan

   So what're we going to do?

 * If your package contains no C++, do nothing. One fine day,
   gcc-defaults will be changed to gcc-3.2 and you'll start using GCC
   3.2 with no work by yourself.
 * If you maintain a library written in C++, add a `c' to the end of
   the name of your .deb, eg libdb4.0++.deb -> libdb4.0++c.deb. This
   is similar in spirit to the glibc transition adding `g' to the end
   of libraries.
 * You should not add a `c' to your -dev package.
 * The exact placement of the `c' can be tricky. It's not terribly
   important; the important thing is that the new package conflicts
   with the old and has a different name. Stylistically, we prefer to
   keep the `c' adjacent to the soname number, eg libqt3c-mt-odbc,
   but if your package ends in a ++, put the `c' after that.
 * Add a Conflict with the non-`c' version of the package.
 * Ensure that you're using g++-3.2 to build your library (setting
   CXX in the environment will normally do the trick).
 * Add a build-dependency on g++-3.2 in your control file (this can
   be removed after gcc-defaults is changed).
 * Wait until all your dependencies have been uploaded in `c'
   versions.
 * Upload and rejoice!

   At some point in the future, we will change gcc-defaults to make
   gcc-3.2 the default on all architectures. At that time, you should
   remove the setting of CXX and the explicit dependency on g++-3.2. You
   should not rename your package to remove the `c' suffix until upstream
   change their soname.

This is a proposal. You will be notified when this is a real plan

   Why don't we just change the sonames?

   Because upstream chooses the soname to match their API. If we change
   the soname then we render ourselves binary-incompatible with other
   distros and vendor-supplied binaries. This is important because the
   LSB intend to standardise the GCC 3.2 ABI; for Debian to become
   binary-incompatible at this point would be the height of perversity.

   Of course, when your upstream does bump the soname, you can drop the
   `c' from the package name, just like very few libs still have a `g' on
   the end.

   How about versioned symbols?

   Versioned symbols don't even pretend to solve ABI transition problems.
   Not to mention there's the other-distro compatibility issue --
   binaries compiled on Debian would not run on other distros.

   Why don't we put the libs in a different directory?

   Basically, it's too complex. For the glibc transition, we could do
   this because they used different dynamic linkers.

   What about other architectures?

   The rules I've outlined above should make the autobuilders build your
   packages with GCC 3.2.

   Help! My package doesn't build with GCC 3.2

   Typically this is because your package isn't actually written in C++
   but some "extended subset" of it. You may want to talk to upstream
   about getting it converted. Fortunately, due to hppa using GCC 3.0 for
   woody, you've probably had a bug filed against your package for at
   least six months, so this is no surprise to you.

   If you really can't get your package fixed, you should change to
   build-depend on g++-2.95. If you depend on a library other than
   libstdc++ (or libg++), you're not likely to release with sarge. We
   recommend you statically link to any C++ libraries (other than libg++)
   which you use.

This is a proposal. You will be notified when this is a real p

Bug#156935: ITP: nttcp - New test TCP program

[Taku YASUI]

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

* Package name: nttcp
  Version : 1.47
  Upstream Author : Elmar Bartel <[EMAIL PROTECTED]>
* URL : http://www.leo.org/~elmar/nttcp/
* License : Original (non-free)
  Description : New test TCP program

 This program is a much more convenient version of the ttcp program.
 It uses inetd (or simulates its behaviour) to start off the remote
 side program which will send/receive data. Both sides measure the time
 and number of bytes transfered. The local side will print the measures.
 The format of the output can be specified on the commandline.

 It does not allow for commercial use.  So it will be non-free.

Re: GCC 3.2 transition

[Oohara Yuuma]

[for debian-gcc people: please Cc: to me because I am not subscribed]

On Fri, 16 Aug 2002 14:51:34 +0100,
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
>  * If your package contains no C++, do nothing. One fine day,
>gcc-defaults will be changed to gcc-3.2 and you'll start using GCC
>3.2 with no work by yourself.
1. Does a C (not C++) library compiled with gcc 2.95 work with
   a C++ program compiled with gcc 3.2?
2. Does this mean I must not use gcc 3.2 before it becomes gcc-defaults?
   There may be a case where gcc 3.2 offers better optimization.

>  * If you maintain a library written in C++, add a `c' to the end of
>the name of your .deb, eg libdb4.0++.deb -> libdb4.0++c.deb. This
>is similar in spirit to the glibc transition adding `g' to the end
>of libraries.
What does this "c" mean?

-- 
Oohara Yuuma <[EMAIL PROTECTED]>
Debian developer
PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt
Key fingerprint = 6142 8D07 9C5B 159B C170  1F4A 40D6 F42E F464 A695

Better just encrypt it all in your head :-).
--- Derrick 'dman' Hudson, about encryption without any physical medium

Re: GCC 3.2 transition

[Richard Kettlewell]

Matthew Wilcox <[EMAIL PROTECTED]> writes:
>  * Add a Conflict with the non-`c' version of the package.

So it will be impossible to have both the old and new library packages
on the system simultaneously.  That's broken.

>Why don't we just change the sonames?
>
>Because upstream chooses the soname to match their API. If we change

Sonames define ABIs not APIs.

>the soname then we render ourselves binary-incompatible with other
>distros and vendor-supplied binaries. This is important because the
>LSB intend to standardise the GCC 3.2 ABI; for Debian to become
>binary-incompatible at this point would be the height of
>perversity.

You have to change the soname for this kind of transition to work
properly and (obviously) this must be coordinated with upstream.

-- 
http://www.greenend.org.uk/rjk/

Re: GCC 3.2 transition

[Steve Langasek]

On Fri, Aug 16, 2002 at 02:51:34PM +0100, Matthew Wilcox wrote:

> This is a proposal. You will be notified when this is a real plan

>Why don't we just change the sonames?

>Because upstream chooses the soname to match their API. If we change
>the soname then we render ourselves binary-incompatible with other
>distros and vendor-supplied binaries. This is important because the
>LSB intend to standardise the GCC 3.2 ABI; for Debian to become
>binary-incompatible at this point would be the height of perversity.

No, not at all.  The soname is an assurance that the library's *ABI* is
constant.  An ABI can change with no changes to the API, and when it
does, the soname must be changed.  This is why we have at least 5
versions of libstdc++ in the archive right now (4 in woody alone).

I sincerely hope that g++ 3.2 applications will be allowed to coexist on
the system with g++ 2.95.x applications.  And really, there is no reason
to not allow this: because of the nature of the ABI breakage, you will
never be able to accidentally mix-and-match g++ 3.2 binaries with g++
2.95.x binaries, because they will not be able to resolve each other's
symbols at the linker level.  It is precisely because the symbol name
mangling has changed with each revision of gcc that we need to worry
about this transition in the first place.

If other distributions are planning to move from 2.95.x to 3.2 without
changing sonames, then we need to start talking to them /now/, and make
sure we aren't all stuck with this terrible mistake.

Steve Langasek
postmodern programmer


pgpzw1d4LEFlt.pgp
Description: PGP signature

Re: GCC 3.2 transition

[Wichert Akkerman]

Previously Oohara Yuuma wrote:
> 1. Does a C (not C++) library compiled with gcc 2.95 work with
>a C++ program compiled with gcc 3.2?

Yes

> 2. Does this mean I must not use gcc 3.2 before it becomes gcc-defaults?
>There may be a case where gcc 3.2 offers better optimization.

Yes.

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.wiggy.net/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: GCC 3.2 transition

[Daniel Jacobowitz]

On Fri, Aug 16, 2002 at 11:47:07PM +0900, Oohara Yuuma wrote:
> [for debian-gcc people: please Cc: to me because I am not subscribed]
> 
> On Fri, 16 Aug 2002 14:51:34 +0100,
> Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> >  * If your package contains no C++, do nothing. One fine day,
> >gcc-defaults will be changed to gcc-3.2 and you'll start using GCC
> >3.2 with no work by yourself.
> 1. Does a C (not C++) library compiled with gcc 2.95 work with
>a C++ program compiled with gcc 3.2?

If the library does not use exceptions in any way then yes, almost
certainly.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Re: GCC 3.2 transition

[Adam Heath]

On Fri, 16 Aug 2002, Oohara Yuuma wrote:

> >  * If you maintain a library written in C++, add a `c' to the end of
> >the name of your .deb, eg libdb4.0++.deb -> libdb4.0++c.deb. This
> >is similar in spirit to the glibc transition adding `g' to the end
> >of libraries.
> What does this "c" mean?

c++ -> ++c

Re: tenative ITP linux-wlan-ng; soliciting advice

[Paul Hedderly]

On Fri, Jul 26, 2002 at 03:17:21AM -0400, Joey Hess wrote:
> Peter Hicks wrote:
> > well, I would hate to dissuade you from packaging the linux-wlan
> > drivers, but I have no trouble using prism2, orinoco, or cisco aironet
> > cards with the stock debian 2.4.18 kernel. Both my lucent card and my
> > smc 2632 use the hermes/orinoco_cs drivers. I tested a cisco card last
> > monday and it worked fine, but I don't have it around to check which
> > drivers it used.
> 
> As far as I know wlan-ng is the only game in town for pci prism2 cards.
> And I've done the necessary work to integrate it with
> /etc/network/interfaces already:

No. the hostap dirver is excellent. Written by Jean Tour... something.
He works for SSH Corp. google for "linux prism2 driver". It does pcmcia
and pci brilliantly but doesnt support usb yet. works with prism2/2.5/3
cards - and most orinoco cards too. supports kysmet.

--
Paul (Started packaging modules for it a month ago then went away for a
month... must finish that)

> 
> iface wlan0 inet static
> address 192.168.1.5
> gateway 192.168.1.1
> netmask 255.255.255.0
> # Should be either ad-hoc or managed. Used managed if you have an AP.
> wireless_mode ad_hoc
> # Leave this unset to associate with any access point. Set to pick an
> # access point, or in ad-hoc mode.
> wireless_essid wortroot
> # A name for your machine. Required.
> wireless_nick dragon
> # For ad-hoc mode, you must specify a channel.
> wireless_channel 1
> #
> #
> # To enable WEP, uncomment the next line.
> #   wireless_enc on
> # To set a WEP key, either use a string, which will be converted to a key:
> #   wlan_ng_priv_genstr foo
> # (Using the specified key length.)
> #   wlan_ng_priv_key128 false
> # Or set keys explicitly.
> #   wlan_ng_key0 xx:xx:xx:xx:xx
> #   wlan_ng_key1 xx:xx:xx:xx:xx
> #   wlan_ng_key2 xx:xx:xx:xx:xx
> #   wlan_ng_key3 xx:xx:xx:xx:xx
> # If you set a key, remember to make the file mode 600!
> #
> # In managed mode, set to "sharedkey" if a shared key is required.
> #   wlan_ng_authtype opensystem
> # If you are serving as an AP, uncommnent this to require WEP for all STAs.
> #   wlan_ng_exclude_unencrypted true
> #
> # Some extra ah-hoc mode settings:
> # Beacon interval (in Kus)
> #   wlan_ng_bcint 100
> # Rates for mgmt&ctl frames (in 500Kb/s)
> #   wlan_ng_basicrates 2 4
> # Supported rates in BSS (in 500Kb/s)
> #   wlan_ng_oprates 2 4 11 22
> #
> # You can set arbitrary MIB items with this directive, separated by
> # whitespace. Each will then be set.
> #   wlan_ng_user_mibs p2CnfRoamingMode=1
> 
> (It also does a really impressive job of getting ad-hoc link quality
> stats right automatically. Despite the huge complexity, I think I like
> it..)
> 
> -- 
> see shy jo
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

Re: GCC 3.2 transition

[Steve Langasek]

On Fri, Aug 16, 2002 at 04:06:56PM +0100, Richard Kettlewell wrote:
> Matthew Wilcox <[EMAIL PROTECTED]> writes:
> >  * Add a Conflict with the non-`c' version of the package.

> So it will be impossible to have both the old and new library packages
> on the system simultaneously.  That's broken.

> >Why don't we just change the sonames?

> >Because upstream chooses the soname to match their API. If we change

> Sonames define ABIs not APIs.

> >the soname then we render ourselves binary-incompatible with other
> >distros and vendor-supplied binaries. This is important because the
> >LSB intend to standardise the GCC 3.2 ABI; for Debian to become
> >binary-incompatible at this point would be the height of
> >perversity.

> You have to change the soname for this kind of transition to work
> properly and (obviously) this must be coordinated with upstream.

From the heated discussion I've just had on IRC, I've gathered the
following:

* It is assumed that for the vast majority of C++ libs we ship, upstream
  has already transitioned to using the GCC 3.2 ABI, therefore our
  current packages are already binary-incompatible with the rest of the
  world. (ok)
* In these cases, having a package whose soname is compatible with the
  rest of the world is considered more important than providing
  compatibility for binaries locally compiled by our users against the
  old, broken ABI. (ok)
* For any remaining libraries, there are many in Debian who don't give
  a damn about getting it right, to the point that they don't want
  maintainers to get any grandiose ideas about discussing this issue with
  upstream and possibly hammering out a sane, cross-platform
  transitioning plan for the library in question that actually manages to
  NOT break anything. (not ok)

But, I seem to be strongly outvoted on the last point. 

Steve Langasek
postmodern programmer


pgpEVGsRcAkyi.pgp
Description: PGP signature

Re: ZINF pkgs crashing dpkg - please test

[Adam Heath]

On 16 Aug 2002, Andreas Rottmann wrote:

> Hi!
>
> I finished a first version of my ZINF packages (ZINF is not FreeA*p).
>
> They seem to reproducibly cause a dpkg degfault on my machine when
> doing the following:
>
> ~# apt-get install freeamp freeamp-extras libfreeamp-esound
> ~# dpkg -i --auto-deconfigure zinf_2.2.0-1_i386.deb 
> zinf-extras_2.2.0-1_i386.deb zinf-plugin-esound_2.2.0-1_i386.deb
>
> On my machine this dpkg crashes like this:
>
> Selecting previously deselected package zinf.
> dpkg: considering removing freeamp in favour of zinf ...
> dpkg: yes, will remove freeamp in favour of zinf.
> (Reading database ... 101551 files and directories currently installed.)
> Unpacking zinf (from zinf_2.2.0-1_i386.deb) ...
> De-configuring freeamp-extras, so that we can remove freeamp ...
> De-configuring libfreeamp-esound, so that we can remove freeamp ...
> Segmentation fault

What version of dpkg?

 .__.
_|  |_  <-- dpkg hat
  doogie

Re: GCC 3.2 transition

[Jack Howarth]

Steve,
There shouldn't be huge issues in the gcc 2.95.4 to gcc 3.2 transition.
Currently the only two major ones I know if are...

1) Rebuilding glibc with gcc 3.2 *may* require an arch to add a libgcc-compat
   section to provide libgcc symbols, now .hidden in gcc 3.2's libgcc_s.so,
   with local copies that are resolvable at runtime. Currently ia64 and ppc
   has such code available. This is to prevent breaking old binaries when
   a gcc 3.2 built glibc is installed.
2) Using something like a gcc 2.95.4 built jdk javaplugin (written in c++)
   with a gcc 3.2 built mozilla won't currently work although workarounds
   are said to exist. Since Blackdown JDK 1.4 development is underway
   a gcc 3.2 build JDK won't be far off.

  Jack

RE: GCC 3.2 transition

[Sean 'Shaleh' Perry]

>  * Add a Conflict with the non-`c' version of the package.

why can't we have both installed, just like the libfoo6 and libfoo6g situation??

Re: GCC 3.2 transition

[Matthew Wilcox]

On Fri, Aug 16, 2002 at 09:59:28AM -0700, Sean 'Shaleh' Perry wrote:
> >  * Add a Conflict with the non-`c' version of the package.
> 
> why can't we have both installed, just like the libfoo6 and libfoo6g
> situation??

i explained this elsewhere...

Why don't we put the libs in a different directory?

Basically, it's too complex.  For the glibc transition, we could do this
because they used different dynamic linkers.

Or can you think of a good way of having them both install without
having conflicting files?

-- 
Revolutions do not require corporate support.

Re: ZINF pkgs crashing dpkg - please test

[Adam Heath]

On Fri, 16 Aug 2002, Adam Heath wrote:

> > Selecting previously deselected package zinf.
> > dpkg: considering removing freeamp in favour of zinf ...
> > dpkg: yes, will remove freeamp in favour of zinf.
> > (Reading database ... 101551 files and directories currently installed.)
> > Unpacking zinf (from zinf_2.2.0-1_i386.deb) ...
> > De-configuring freeamp-extras, so that we can remove freeamp ...
> > De-configuring libfreeamp-esound, so that we can remove freeamp ...
> > Segmentation fault
>
> What version of dpkg?

I can repeat this with 1.10.4.  I'll look into it.

Re: GCC 3.2 transition

[Anthony Towns]

On Fri, Aug 16, 2002 at 09:59:28AM -0700, Sean 'Shaleh' Perry wrote:
> >  * Add a Conflict with the non-`c' version of the package.
> why can't we have both installed, just like the libfoo6 and libfoo6g 
> situation??

Because doing so would require changing the soname. Which is possible,
but would mean inventing a new soname that's not used anywhere else. If
upstream then reuse the soname we make up for something different we
end up with continuing problems. As far as non-Debian apps go, it seems
likely, especially with the LSB looking to standardise C++ on gcc 3.2
"soon" (in theory in the next couple of months, in practice maybe longer)
that people will expect the "current" sonames to use the gcc 3.2 C++ ABI.

Other options are:

* encourage upstream to bump their soname themselves, and wait for
  them to do that. so libfoo.so.2 is the old C++ ABI, and
  libfoo.so.3 is the new one, eg.

* encourage upstream to encode the C++ ABI in the soname, as
  apt does, ending up with something like
  libapt-pkg-libc6.2-3-2.so.3.2. (I have no idea how this is worked
  out)

If upstream aren't inclined to change their Linux soname for the new gcc,
though, not changing our soname but doing the upgrade anyway seems the
best option.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''


pgpZKJKTaOyWo.pgp
Description: PGP signature

Re: GCC 3.2 transition

[Michael Alan Dorman]

"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
> >  * Add a Conflict with the non-`c' version of the package.
> why can't we have both installed, just like the libfoo6 and libfoo6g
> situation??

Err, weren't we able to do that because we moved all the libc5 libs to
another directory?

Mike.

Re: GCC 3.2 transition

[Matthias Klose]

Steve Langasek writes:
> * It is assumed that for the vast majority of C++ libs we ship, upstream
>   has already transitioned to using the GCC 3.2 ABI, therefore our
>   current packages are already binary-incompatible with the rest of the
>   world. (ok)

right. One reason for the 3.2 release was a common base for Linux
distributions.

> * In these cases, having a package whose soname is compatible with the
>   rest of the world is considered more important than providing
>   compatibility for binaries locally compiled by our users against the
>   old, broken ABI. (ok)

Jeff Bailey planned to put these libraries in /usr/lib/gcc-2.95 (like
in the libc5/6 transition) and rename the packages containing the 2.95
libraries.

> * For any remaining libraries, there are many in Debian who don't give
>   a damn about getting it right, to the point that they don't want
>   maintainers to get any grandiose ideas about discussing this issue with
>   upstream and possibly hammering out a sane, cross-platform
>   transitioning plan for the library in question that actually manages to
>   NOT break anything. (not ok)

cross platform == cross architecture: yes. Jeff is working on a plan
to NMU libstdc++ dependent packages.

> But, I seem to be strongly outvoted on the last point. 

maybe we break some things in unstable for some days, but how do we
call this distro?

Matthias

Re: GCC 3.2 transition

[Colin Watson]

On Fri, Aug 16, 2002 at 02:51:34PM +0100, Matthew Wilcox wrote:
>  * If you maintain a library written in C++, add a `c' to the end of
>the name of your .deb, eg libdb4.0++.deb -> libdb4.0++c.deb. This
>is similar in spirit to the glibc transition adding `g' to the end
>of libraries.
>  * You should not add a `c' to your -dev package.
>  * The exact placement of the `c' can be tricky. It's not terribly
>important; the important thing is that the new package conflicts
>with the old and has a different name. Stylistically, we prefer to
>keep the `c' adjacent to the soname number, eg libqt3c-mt-odbc,
>but if your package ends in a ++, put the `c' after that.
>  * Add a Conflict with the non-`c' version of the package.
>  * Ensure that you're using g++-3.2 to build your library (setting
>CXX in the environment will normally do the trick).
>  * Add a build-dependency on g++-3.2 in your control file (this can
>be removed after gcc-defaults is changed).
>  * Wait until all your dependencies have been uploaded in `c'
>versions.

What should maintainers of ordinary non-library packages written in C++
do? Presumably it will be possible to upload with a build-dep on g++-3.2
pretty much as soon as a transition plan is finalized, provided there
are no library dependencies beyond libstdc++.

(Yes, there's a certain amount of pride here in trying to save work for
whoever ends up mass-NMUing ...)

-- 
Colin Watson  [EMAIL PROTECTED]

Re: GCC 3.2 transition

[Steve Langasek]

On Fri, Aug 16, 2002 at 08:03:48PM +0200, Matthias Klose wrote:
> Steve Langasek writes:
> > * In these cases, having a package whose soname is compatible with the
> >   rest of the world is considered more important than providing
> >   compatibility for binaries locally compiled by our users against the
> >   old, broken ABI. (ok)

> Jeff Bailey planned to put these libraries in /usr/lib/gcc-2.95 (like
> in the libc5/6 transition) and rename the packages containing the 2.95
> libraries.

How would this work?  Would those using gcc-2.95 software have to set an
rpath or $LD_LIBRARY_PATH to take advantage of the compat libs?  If so,
it hardly seems worth the effort; manual intervention is still required
to make legacy binaries work.

> > * For any remaining libraries, there are many in Debian who don't give
> >   a damn about getting it right, to the point that they don't want
> >   maintainers to get any grandiose ideas about discussing this issue with
> >   upstream and possibly hammering out a sane, cross-platform
> >   transitioning plan for the library in question that actually manages to
> >   NOT break anything. (not ok)

> cross platform == cross architecture: yes. Jeff is working on a plan
> to NMU libstdc++ dependent packages.

> > But, I seem to be strongly outvoted on the last point. 

> maybe we break some things in unstable for some days, but how do we
> call this distro?

My concern is that locally compiled apps built against C++ libraries
other than libstdc++ will silently stop working on upgrade.  This is
certainly not the most important issue facing us in the transition, but
so far it seems to me that people are regarding it as so *un*important
that it's not worth discussing at all.

Steve Langasek
postmodern programmer


pgpb2XvWyMZSM.pgp
Description: PGP signature

Re: GCC 3.2 transition

[Martin v. Loewis]

Matthew Wilcox <[EMAIL PROTECTED]> writes:

> This is a proposal. You will be notified when this is a real plan

I think Jeff Bailey's plan is entirely different, and I like his plan
more. Here are the differences.

>  * If you maintain a library written in C++, add a `c' to the end of
>the name of your .deb, eg libdb4.0++.deb -> libdb4.0++c.deb. This
>is similar in spirit to the glibc transition adding `g' to the end
>of libraries.

In Jeff's plan: do nothing.

>At some point in the future, we will change gcc-defaults to make
>gcc-3.2 the default on all architectures. At that time, you should
>remove the setting of CXX and the explicit dependency on g++-3.2. You
>should not rename your package to remove the `c' suffix until upstream
>change their soname.

In Jeff's plan: All C++ packages will be uploaded via NMUs. The
package maintainer can upload their packages afterwards if they have
to make other corrections.

>Why don't we just change the sonames?

Because it is easiest to have just two binary-incompatible
libraries. They can't coexist, and they don't need to, most of the
time. When they do, the old versions can be put in a separate
directory.

>Why don't we put the libs in a different directory?
> 
>Basically, it's too complex. For the glibc transition, we could do
>this because they used different dynamic linkers.

For C++, we can do this because we have the source of nearly all
packages, and can recompile them. There won't be much C++ libraries
that are needed by packages for which we don't have the source to.

Regards,
Martin

Re: GCC 3.2 transition

[Martin v. Loewis]

Steve Langasek <[EMAIL PROTECTED]> writes:

> I sincerely hope that g++ 3.2 applications will be allowed to coexist on
> the system with g++ 2.95.x applications.  

I don't think this will happen, atleast not for shared libraries. Any
scheme that tries to solve this problem will be horribly complex,
require manual interaction with the build process, and produce
binaries that are incompatible with anybody else's binaries.

> And really, there is no reason to not allow this: because of the
> nature of the ABI breakage, you will never be able to accidentally
> mix-and-match g++ 3.2 binaries with g++ 2.95.x binaries, because
> they will not be able to resolve each other's symbols at the linker
> level.

Indeed. So there is no accidental linkage of the wrong library. If
something breaks, it will be visible right when it starts, and the
solution is clear: recompile the package that uses the old ABI.

> It is precisely because the symbol name mangling has changed with
> each revision of gcc that we need to worry about this transition in
> the first place.

The ABI deals with way more aspects than name mangling, but - yes.

> If other distributions are planning to move from 2.95.x to 3.2 without
> changing sonames, then we need to start talking to them /now/, and make
> sure we aren't all stuck with this terrible mistake.

It is not a terrible mistake, it is the only solution that can work at
all. *If* sonames are changed, we will get a terrible mess. If we use
the sonames defined by the upstream maintainers, everything will work
out nicely, as everybody uses the same sonames for the same libraries.

Other distributions *will* build the packages from source as-is, and
thus *will not* change the sonames of the library: they can rebuild
the entire distribution from source, so there simply is no need to
keep the old shared libraries.

Regards,
Martin

Bug#156956: ITP: iftop -- iftop provides real-time bandwidth usage information on a specified interface, listed by host pairs.

[Norbert Tretkowski]

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

* Package name: iftop
  Version : 0.4
  Upstream Author : Paul Warren <[EMAIL PROTECTED]>, Chris Lightfoot <[EMAIL 
PROTECTED]>
* URL : http://www.ex-parrot.com/~pdw/iftop/
* License : GPL
  Description : iftop provides real-time bandwidth usage information on a 
specified interface, listed by host pairs.

iftop does for network usage what top(1) does for CPU usage. It listens to 
network traffic on a named interface and displays a table
of current bandwidth usage by pairs of hosts. Handy for answering the question 
"why is our ADSL link so slow?".

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux rollcage 2.4.19 #1 Sat Aug 3 21:53:42 CEST 2002 i686
Locale: LANG=POSIX, LC_CTYPE=de_DE

Re: GCC 3.2 transition

[Martin v. Loewis]

Matthew Wilcox <[EMAIL PROTECTED]> writes:

> All of them?  I sw someone do a count and there were around 1000 packages
> currently in the archive.  10%.  Per architecture.  Is Jeff really going
> to bNMU all of these packages on the same day for all architectures?

I think this is the plan. You'll have to ask him for specifics; I
think the plan incorporates doing one architecture at a time.

> What will that do to auric's disc space and our network traffic?
> This doesn't sound like a plan, it sounds like the absence of a
> plan.

It is a strategy that requires a minimum of manual intervention, so I
think it is a good strategy - much better than requiring every single
maintainer of each of the 1000 packages to act in a coordinated way,
and ending up with an infrastructure that is incompatible to anybody
else's gcc 3.2 applications.

If temporary breakage of some applications is acceptable, you can
spread this over a couple of days, by tsorting the 1000 packages.

Regards,
Martin

Re: GCC 3.2 transition

[Steve Langasek]

On Fri, Aug 16, 2002 at 09:47:25PM +0200, Martin v. Loewis wrote:

> Not necessarily: you can write wrapper scripts around the executable
> which automatically set LD_LIBRARY_PATH, then invoke the original
> binary. That has worked very well in the past.

> If you mean that the manual intervention is need by package
> maintainers: indeed they'd need to act. So this would be restricted to
> packages for which no source code is available.

> The majority of such packages links to libstdc++ only, so there may be
> no need for action at all.

Do we have non-free C++ packages that we have to worry about?  My
comments were more directed at unpackaged software that users may be
running on their Debian systems.  In those cases, providing a way to get
their binaries working again /after/ we break them is only a little bit
better than forcing them to recompile.

> > My concern is that locally compiled apps built against C++ libraries
> > other than libstdc++ will silently stop working on upgrade.  This is
> > certainly not the most important issue facing us in the transition,
> > but so far it seems to me that people are regarding it as so
> > *un*important that it's not worth discussing at all.

> The breakage will not be silent: On startup of the application, they
> will give an error message indicating the problem. I think that
> problem is best solved by educating the users that such problems might
> happen.

It is silent in the sense that the package management system will give no
indication that the new libfoo++.so.n is not compatible with the old
libfoo++.so.n; only locally compiled, /packaged/ apps will be tipped off
to the problem.

Steve Langasek
postmodern programmer


pgpwIB15ehwxQ.pgp
Description: PGP signature

Re: Bug#156956: ITP: iftop -- iftop provides real-time bandwidth usage information on a specified interface, listed by host pairs.

[Norbert Tretkowski]

close 156956
thanks

* Guillem Jover <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 16, 2002 at 08:37:41PM +0200, Norbert Tretkowski wrote:
> > Package: wnpp
> > Version: N/A; reported 2002-08-16
> > Severity: wishlist
> > [...]
> Package: iftop
> Status: install ok installed

ARGH, my fault... I only looked into stable.

Re: GCC 3.2 transition

[Sean 'Shaleh' Perry]

> 
> If upstream aren't inclined to change their Linux soname for the new gcc,
> though, not changing our soname but doing the upgrade anyway seems the
> best option.
> 

even if some are willing not all will be.  Then we have to worry about dead
upstreams too.  It seems like changing the sonames to solve this simply won't
work.

I had forgotten we solved the libc5 issue by moving the libs to a new directory
and making ld.so look there.  Been a while (-:

Re: GCC 3.2 transition

[Martin v. Loewis]

Steve Langasek <[EMAIL PROTECTED]> writes:

> > Jeff Bailey planned to put these libraries in /usr/lib/gcc-2.95 (like
> > in the libc5/6 transition) and rename the packages containing the 2.95
> > libraries.
> 
> How would this work?  Would those using gcc-2.95 software have to set an
> rpath or $LD_LIBRARY_PATH to take advantage of the compat libs?  If so,
> it hardly seems worth the effort; manual intervention is still required
> to make legacy binaries work.

Not necessarily: you can write wrapper scripts around the executable
which automatically set LD_LIBRARY_PATH, then invoke the original
binary. That has worked very well in the past.

If you mean that the manual intervention is need by package
maintainers: indeed they'd need to act. So this would be restricted to
packages for which no source code is available.

The majority of such packages links to libstdc++ only, so there may be
no need for action at all.

> My concern is that locally compiled apps built against C++ libraries
> other than libstdc++ will silently stop working on upgrade.  This is
> certainly not the most important issue facing us in the transition,
> but so far it seems to me that people are regarding it as so
> *un*important that it's not worth discussing at all.

The breakage will not be silent: On startup of the application, they
will give an error message indicating the problem. I think that
problem is best solved by educating the users that such problems might
happen.

With a little effort, it would be possible to produce a list of shared
libraries that will break; perhaps while constructing the NMUs, and
maintaining that list as a package.

It would then be possible to even write a skript that checks one or
many binaries (apps and libs) whether they are linked against one of
these libraries, and warn users that those programs will stop working
after the update.

The time to maintain this database would IMO be better spent than the
time needed to really solve the problem (which is an effort with
uncertain outcome, too).

Regards,
Martin

Re: GCC 3.2 transition

[David Schleef]

On Fri, Aug 16, 2002 at 01:27:37PM -0500, Steve Langasek wrote:
> On Fri, Aug 16, 2002 at 08:03:48PM +0200, Matthias Klose wrote:
> > Steve Langasek writes:
> > > * In these cases, having a package whose soname is compatible with the
> > >   rest of the world is considered more important than providing
> > >   compatibility for binaries locally compiled by our users against the
> > >   old, broken ABI. (ok)
> 
> > Jeff Bailey planned to put these libraries in /usr/lib/gcc-2.95 (like
> > in the libc5/6 transition) and rename the packages containing the 2.95
> > libraries.
> 
> How would this work?  Would those using gcc-2.95 software have to set an
> rpath or $LD_LIBRARY_PATH to take advantage of the compat libs?  If so,
> it hardly seems worth the effort; manual intervention is still required
> to make legacy binaries work.
> 
> My concern is that locally compiled apps built against C++ libraries
> other than libstdc++ will silently stop working on upgrade.  This is
> certainly not the most important issue facing us in the transition, but
> so far it seems to me that people are regarding it as so *un*important
> that it's not worth discussing at all.


One possible way of allowing both 2.95 libs and 3.2 libs to coincide
is to hack ld.so to look in additional search paths if a binary is
linked with specific library.

For example, in this case, if ld.so sees that local-qt-based-app is
linked with libstdc++-libc6.2-2.so.3, it adds
/usr/lib/libstdc++-libc6.2-2.so.3 to the library search path, and
then preferentially load /usr/lib/libstdc++-libc6.2-2.so.3/libqt.so.2
to satisfy the libqt.so.2 dependency.

Naturally, we'd need a transition plan to get those libs out of
/usr/lib and into /usr/lib/libstdc++-libc6.2-2.so.3.  But we could
do that at the same time as putting new, gcc-3.2-compiled libraries
in /usr/lib/libstdc++-libc6.2-2.so.5/.  When /usr/lib is empty of
so.3-dependent libs, we can start moving so.5-dependent libs into
/usr/lib.

This only covers a clean unstable transition.  I'm not familiar with
release-to-release transitions.

Given that same-soname library transitioning occurs too much (i.e.,
more than never), it might be time to have a fix, even if the fix is
detestable.



dave...

Re: Bug#156956: ITP: iftop -- iftop provides real-time bandwidth usage information on a specified interface, listed by host pairs.

[Guillem Jover]

On Fri, Aug 16, 2002 at 08:37:41PM +0200, Norbert Tretkowski wrote:
> Package: wnpp
> Version: N/A; reported 2002-08-16
> Severity: wishlist
> 
> * Package name: iftop
>   Version : 0.4
>   Upstream Author : Paul Warren <[EMAIL PROTECTED]>, Chris Lightfoot <[EMAIL 
> PROTECTED]>
> * URL : http://www.ex-parrot.com/~pdw/iftop/
> * License : GPL
>   Description : iftop provides real-time bandwidth usage information on a 
> specified interface, listed by host pairs.
> 
> iftop does for network usage what top(1) does for CPU usage. It listens to 
> network traffic on a named interface and displays a table
> of current bandwidth usage by pairs of hosts. Handy for answering the 
> question "why is our ADSL link so slow?".

Package: iftop
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 76
Maintainer: christophe barbe <[EMAIL PROTECTED]>
Version: 0.4-2
Depends: libc6 (>= 2.2.4-4), libncurses5 (>= 5.2.20020112a-1), libpcap0.7
Description: Display bandwidth usage on an interface
 iftop does for network usage what top(1) does for CPU usage. It
 listens to network traffic on a named interface and displays a table
 of current bandwidth usage by pairs of hosts. Handy for answering the
 question "why is our ADSL link so slow?".


regards,
guillem

Re: GCC 3.2 transition

[Gerhard Tonn]

On Friday 16 August 2002 15:51, Matthew Wilcox wrote:
> I got sick of listening to people discuss the gcc 3.2 transition in an
> uninformed manner.  So I've whipped up a transition plan which will
> hopefully get us from A to B without causing too much pain.  Haha.
> I'm entirely fallible and I don't pretend to understand all the issues
> involved with doing the transition.  But by writing down a plan at
> least it can be updated and fixed before we have to start _doing_
> the transition.
>
> Comments and corrections welcomed.  
>

I think, the question is, whether the transition should be done by the 
package maintainers or by the platform porters. 

If it is done by the platform porters a special build server has to be setup 
for each platform recompiling all packages depending on c++. A wanna build 
feature creating packages for NMUs can be used. The packages that have been 
built successfully can then be uploaded to a local archive or to auric which 
will probably break some other packages. The packages that haven't been built 
successfully have to be rebuilt. This is basically the approach used to build 
packages for a new architecture. The advantage is that the transition takes 
probably only one week on most architectures. The disadvantage is that we 
must know all C++ packages in advance.

Gerhard

Re: GCC 3.2 transition

[Matthew Wilcox]

On Fri, Aug 16, 2002 at 08:38:53PM +0200, Martin v. Loewis wrote:
> In Jeff's plan: All C++ packages will be uploaded via NMUs. The
> package maintainer can upload their packages afterwards if they have
> to make other corrections.

All of them?  I sw someone do a count and there were around 1000 packages
currently in the archive.  10%.  Per architecture.  Is Jeff really going
to bNMU all of these packages on the same day for all architectures?
What will that do to auric's disc space and our network traffic?  This
doesn't sound like a plan, it sounds like the absence of a plan.

-- 
Revolutions do not require corporate support.

Re: GCC 3.2 transition

[Simon Law]

On Fri, Aug 16, 2002 at 08:38:53PM +0200, Martin v. Loewis wrote:
> Matthew Wilcox <[EMAIL PROTECTED]> writes:
> >At some point in the future, we will change gcc-defaults to make
> >gcc-3.2 the default on all architectures. At that time, you should
> >remove the setting of CXX and the explicit dependency on g++-3.2. You
> >should not rename your package to remove the `c' suffix until upstream
> >change their soname.
> 
> In Jeff's plan: All C++ packages will be uploaded via NMUs. The
> package maintainer can upload their packages afterwards if they have
> to make other corrections.

Indeed, this is the entire reason apt-rdepends exists.  I looked
really hard to see if anything else does what apt-rdepends did.  Alas,
no.  I am looking to integrate this functionality into apt-cache, ASAP.

Simon

Re: GCC 3.2 transition

[Sean 'Shaleh' Perry]

> 
> If temporary breakage of some applications is acceptable, you can
> spread this over a couple of days, by tsorting the 1000 packages.
> 

or do a staging in experimental or somewhere else.  Upload everything there,
let people look at it for a day or two then move it over.

This staging could also take away the need to finish in one day.  All C++
package maintainers could upload to the staging area.  Anyone who has not
uploaded in a certain time (a week or less sounds right) will hae an NMU done
for them.

business oportunity

[tell3peace]

Have You got your own computer and internet connection ?
Why don't You use this for earn the money ?
You must not buy, sell or click in some links! This way is so simply!

Please, leave your name and mail in link :
http://www.notterhrbiz.i8.com
……and we will contact You and meet You with this really good business 
opportunity.
Believe me, You will not to be disappointed.
Membership is apsolutely free and without risk.

Best Regards,
Velimir Notter
You get offer for this job only once time,and I will not contact You,
only if You insist.

Lowering the severity doesn't fix libvorbis0

[Adrian Bunk]

severity 156227 grave
thanks

Hi Christopher,

please explain why you think that it's not RC that packages depending
libvorbis0 no longer run when upgrading libvorbis0 (the problem is similar
to the recent libc6 <-> db breakage that will be fixed by a dependency of
libc6 on libdb1-compat)?

Your lowering of the severity to get your broken package into testing
(it's now in testing...) is _not_ a solution.

cu
Adrian

-- 

You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
Alan Cox

Re: GCC 3.2 transition

[Joseph Carter]

On Fri, Aug 16, 2002 at 02:53:22PM -0500, Steve Langasek wrote:
> > The majority of such packages links to libstdc++ only, so there may be
> > no need for action at all.
> 
> Do we have non-free C++ packages that we have to worry about?  My
> comments were more directed at unpackaged software that users may be
> running on their Debian systems.  In those cases, providing a way to get
> their binaries working again /after/ we break them is only a little bit
> better than forcing them to recompile.

Well there's the proprietary JDK, but it already uses a -compat package
library.

*shrug*

-- 
Joseph Carter <[EMAIL PROTECTED]>Don't feed the sigs
 
 xhost +localhost should only be done by people who would
paint their hostname and root password on an interstate
overpass.



pgpVkJEjPhr4Q.pgp
Description: PGP signature

联系

[ee498]

debian-devel:您好!

老板理财：是一款特别为中小企业设计的理财软件，它的功能范围包括货品管理、资金管理、债权债务管
理，并配备有功能完整、全面的经营报告系统，它的功能覆盖了中小型企业财务管理的方方面面，是一款非常
实用的软件。
 
Office2000财务系统：采用微软Office2000内置开发语言开发，包括帐务报表等部分，可以自动生成现金
流量表。

 请到 http://www.iboss2000.com 免费下载！


致
礼!
  　　


   2002-08-18
   


致
礼!
  　　 
  　　 [EMAIL PROTECTED]
  　　 2002-08-18

Re: Shared library defines a RPATH

[Bdale Garbee]

[EMAIL PROTECTED] (Colin Watson) writes:

> Generally speaking, Debian packages aren't relocatable anyway. Many of
> them (unavoidably) end up with paths compiled into binaries.

We may have to deal with this for things like allowing ia32 binaries to run
on ia64 systems... though so far, all of the ia32 libs I've repacked to drop
into the /emul/ia32-linux tree have been fine.

Bdale

Re: chroot administration

[Thomas Bushnell, BSG]

John Hasler <[EMAIL PROTECTED]> writes:

> The US government definitely is allowed to own copyrights.  The restriction
> is on _enforcing_ their copyrights on works of which they are author.

There are two ways to be the owner of a copyright.  First, you can buy
it from someone else (or otherwise get it by transfer).  The US
government can own copyrights this way.

The second way is by writing something.  The US government cannot own
copyrights this way.  But this is not a restriction merely on
enforcement, rather, no copyright at all exists.

As evidence, I cite the following, 17 USC 105:

"Copyright protection under this title is not available for any work
of the United States Government, but the United States Government is
not precluded from receiving and holding copyrights transferred to it
by assignment, bequest, or otherwise."

Re: GCC 3.2 transition

[Stephen Zander]

> "Joseph" == Joseph Carter <[EMAIL PROTECTED]> writes:
Joseph> Well there's the proprietary JDK, but it already uses a
Joseph> -compat package library.

Eh?  Are you refering to java plugins for mozilla et al, or any actual
JDK?

-- 
Stephen

To Republicans, limited government means not assisting people they
would sooner see shoveled into mass graves. -- Kenneth R. Kahn

Re: chroot administration

[Ben Pfaff]

[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:

> John Hasler <[EMAIL PROTECTED]> writes:
> 
> > The US government definitely is allowed to own copyrights.  The restriction
> > is on _enforcing_ their copyrights on works of which they are author.
> 
> There are two ways to be the owner of a copyright.  First, you can buy
> it from someone else (or otherwise get it by transfer).  The US
> government can own copyrights this way.
> 
> The second way is by writing something.  The US government cannot own
> copyrights this way.  But this is not a restriction merely on
> enforcement, rather, no copyright at all exists.
> 
> As evidence, I cite the following, 17 USC 105:
> 
> "Copyright protection under this title is not available for any work
> of the United States Government, but the United States Government is
> not precluded from receiving and holding copyrights transferred to it
> by assignment, bequest, or otherwise."

The specific powers of the U.S. government listed there are
"receiving" and "holding".  It does not mention "enforcing" or
"protecting", etc.  Are those powers implied elsewhere?

Re: GCC 3.2 transition

[Joseph Carter]

On Fri, Aug 16, 2002 at 02:54:03PM -0700, Stephen Zander wrote:
> > "Joseph" == Joseph Carter <[EMAIL PROTECTED]> writes:
> Joseph> Well there's the proprietary JDK, but it already uses a
> Joseph> -compat package library.
> 
> Eh?  Are you refering to java plugins for mozilla et al, or any actual
> JDK?

Sun's JDK.

-- 
Joseph Carter <[EMAIL PROTECTED]> You expected a coherent reply?
 
  the increase in tension worldwide (as evidenced by crime
and whatnot) over that time period looks a lot like Linux
growth since 1993
 ``Linux linked to worldwide crime epidemic!!''



pgp0JuuUuDprS.pgp
Description: PGP signature

Re: no md5sums for essential packages?

[Kai Henningsen]

kleptog@svana.org (Martijn van Oosterhout)  wrote on 01.08.02 in <[EMAIL 
PROTECTED]>:

> No reason, however in the docs there is an example line to put in apt.conf

Which docs?
What line?

> to automatically generate md5sum files for every package that doesn't
> contain them.
>
> So after you do an upgrade you get a pile of lines like:
>
> Generating missing md5sums for package xxx...
>
> It's very convenient for finding broken files when your laptop battery dies
> just after you've done a dist-upgrade :)

Sounds convenient, yes ... now if I knew where it's hidden!


MfG Kai

Re: GCC 3.2 transition

[Kai Henningsen]

[EMAIL PROTECTED] (Steve Langasek)  wrote on 16.08.02 in <[EMAIL PROTECTED]>:

> From the heated discussion I've just had on IRC, I've gathered the
> following:
>
> * It is assumed that for the vast majority of C++ libs we ship, upstream
>   has already transitioned to using the GCC 3.2 ABI, therefore our
>   current packages are already binary-incompatible with the rest of the
>   world. (ok)

Is this maybe "will already have ... when we release"?

Because otherwise, this is obvious nonsense. 3.2 was released *yesterday*.  
I am pretty certain 99% of all upstreams haven't even realized yet that  
3.2 exists. *No* distribution currently ships with 3.2.[1]

Our current packages may or may not be incompatible, but not for this  
reason.

[1] From the gcc list, IIRC several distributions were planning on  
shipping with 3.2 end of August or September. That was one of the  
arguments for creating 3.2.

MfG Kai

Re: [hertzog@debian.org: Re: Woody retrospective and Sarge introspecti

[Kai Henningsen]

[EMAIL PROTECTED] (Joey Hess)  wrote on 30.07.02 in <[EMAIL PROTECTED]>:

> I don't think it offers much if anything over special-purpose staging
> areas as is being used for perl 5.8 right now.

It seems to me staging areas could solve a lot of these difficulties, yes.

I'm not clear on the current state of the art (never having needed to use  
them), but I envision a productive state approximately like this:

* Have some (semi-?)automatic way of creating a new staging area
* Allow upload to a "staging/xyz" distribution via the usual upload queues  
(and probably using the usual pool, and having the staging stuff under  
dists/staging/xyz with Packages files and everything - easier on mirrors  
_and_ developers/testers that way)
* Have a (semi-?)automatic way of "pulling the plug" on a staging area, so  
that all of it packages get injected into unstable and the staging area  
closed in one go

Creating a new staging area, and pulling the plug, should involve more  
than making a changelog entry - otherwise errors are too easy to make -  
but if we can get away without bothering ftp masters or release  
coordinators, that's a plus.

You might envision staging areas as short-time extra-unstables.

MfG Kai

Re: GCC 3.2 transition

[Clint Adams]

> My concern is that locally compiled apps built against C++ libraries
> other than libstdc++ will silently stop working on upgrade.  This is
> certainly not the most important issue facing us in the transition, but
> so far it seems to me that people are regarding it as so *un*important
> that it's not worth discussing at all.

Having been surprised by 64-bit stuff ceasing to work on sparc after the
libc6 security upgrade, and then the additional amusement of no longer
being able to compile anything 64-bit, I imagine the C++ breakage would
be a whole lot less painless.

Re: chroot administration

[Thomas Bushnell, BSG]

Ben Pfaff <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> 
> > John Hasler <[EMAIL PROTECTED]> writes:
> > 
> > > The US government definitely is allowed to own copyrights.  The 
> > > restriction
> > > is on _enforcing_ their copyrights on works of which they are author.
> > 
> > There are two ways to be the owner of a copyright.  First, you can buy
> > it from someone else (or otherwise get it by transfer).  The US
> > government can own copyrights this way.
> > 
> > The second way is by writing something.  The US government cannot own
> > copyrights this way.  But this is not a restriction merely on
> > enforcement, rather, no copyright at all exists.
> > 
> > As evidence, I cite the following, 17 USC 105:
> > 
> > "Copyright protection under this title is not available for any work
> > of the United States Government, but the United States Government is
> > not precluded from receiving and holding copyrights transferred to it
> > by assignment, bequest, or otherwise."
> 
> The specific powers of the U.S. government listed there are
> "receiving" and "holding".  It does not mention "enforcing" or
> "protecting", etc.  Are those powers implied elsewhere?

There is no such thing as the ownership of a copyright absent the
right to enforce it.  Such enforcement *is* what the ownership is.

Re: GCC 3.2 transition

[Steve Langasek]

On Fri, Aug 16, 2002 at 11:34:00PM +0200, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Steve Langasek)  wrote on 16.08.02 in <[EMAIL PROTECTED]>:

> > From the heated discussion I've just had on IRC, I've gathered the
> > following:

> > * It is assumed that for the vast majority of C++ libs we ship, upstream
> >   has already transitioned to using the GCC 3.2 ABI, therefore our
> >   current packages are already binary-incompatible with the rest of the
> >   world. (ok)

> Is this maybe "will already have ... when we release"?

> Because otherwise, this is obvious nonsense. 3.2 was released *yesterday*.  
> I am pretty certain 99% of all upstreams haven't even realized yet that  
> 3.2 exists. *No* distribution currently ships with 3.2.[1]

> Our current packages may or may not be incompatible, but not for this  
> reason.

The claim was, that it's already too late to prevent binary
incompatibility for some libraries.  Whether this is because some distros
have already shipped with a post-2.95.x ABI, or whether this is because
it's too late to stop certain distros from shipping with the 3.2 ABI, I
don't know.

Steve Langasek
postmodern programmer


pgpvWnr0Yf6Gj.pgp
Description: PGP signature

Re: list of valid distributions in Debian changelog file.

[Peter S Galbraith]

Wichert Akkerman <[EMAIL PROTECTED]> wrote:

> Previously Peter S Galbraith wrote:
> > Hi,  What are the currently valid distribution to which we can make
> > uploads to?
> 
> I think the list currently is:
> 
> unstable experimental stable-proposed-updates stable-security
> testing-proposed-updates testing-security test
> 
> Some combinations of those are possible although not recommended I
> think. I can't think of any reasonably combination at least :)

Thanks Wichert.  I decided to remove debian-changelog-mode.el's feature
of facilitating the insertion of combinations.  Usually the version
number needs to be tweaked anyway.

Peter

Bug#157009: ITP: cl-asdf -- Another System Definition Facility (Lisp)

[Kevin M. Rosenberg]

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

* Package name: cl-asdf
  Version : unversioned, cvs distribution
  Upstream Author : Dan Barlow & Contributors <[EMAIL PROTECTED]>
* URL : http://www.sourceforge.net/projects/cclan
* License : BSD-like
  Description : A Simple Defsystem - "Make" system for Common Lisp Packages

asdf provides a "make" type functions for Common Lisp packages. It
provides compilation and loading features for complex Lisp systems
with multiple modules and files. It is similar in concept, but quite
different in features, from "defsystem" which is included in the
common-lisp-controller package.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux tiger 2.4.19 #1 SMP Sat Aug 3 10:05:27 MDT 2002 i686
Locale: LANG=C, LC_CTYPE=C