Re: Time to package simpleinit?

[Matthias Urlichs]

Hi,

On Mon, 28 Apr 2003 18:23:34 +, Theodore Ts'o wrote:
> Ignoring a dependency is probably bettter than a deadlock which makes
> the system unusable, to be sure

There's a third option. Make "need" exit with nonzero status if it's
called recursively.

Then the script just says

set -e
need foo

and everything works. (I assume 'need' is capable of printing
sensible error messages here.)

I like the "need" idea. It's neat.   ;-)

-- 
Matthias

Re: i386 compatibility & libstdc++

[Martin v. Löwis]

Arnd Bergmann <[EMAIL PROTECTED]> writes:

> No, look at my patch again. If you build without i486 optimization,
> the compiler will see only the extern declaration for 
> __exchange_and_add().

I see. What sonames do you suggest to give to the two copies of
libstdc++? You once said you'd call them libstdc++-i386.so.5,
but that you would also provide them under the name libstdc++.so.5.
This solution seems to have the following properties:

1. It becomes possible to mix native Debian and foreign binaries
   on i486 (provided the dynamic linker can really find the right
   library all the time)
2. Running Debian binaries on foreign systems won't be easy.
   In particular, they all link to libstdc++-i386.so.5, so
   such a library needs to be provided for other systems.
   Mixing that library with that native libstdc++.so.5 might
   cause problems, so anybody running a Debian binary on
   a foreign system would need the binary and all shared libraries
   it links with, even though those libraries have the same 
   sonames as the libraries available on the foreign system.
3. Debian i486 binaries take a significant performance hit.
   The attached program demonstrates that the cost of
   __atomic_add is roughly twice as much if done out-of-line,
   compared to the inline version. On my system, I get
inline: 2.4061
out-of-line: 4.60658

Regards,
Martin

#include 
#include 

typedef int _Atomic_word;
const int nrepeats = 1;

static inline void
atomic_add (volatile _Atomic_word* __mem, int __val)
{
  __asm__ __volatile__ ("lock; addl %0,%1"
: : "ir" (__val), "m" (*__mem) : "memory");
}

static void
atomic_add2 (volatile _Atomic_word* __mem, int __val);

int main()
{
struct timeval start, stop;
double total;
int i;
_Atomic_word w = 0;
// inline
gettimeofday(&start, 0);
for (i = 0; i < nrepeats; i++)
atomic_add(&w, 1);
gettimeofday(&stop, 0);
total = stop.tv_sec + 1e-6*stop.tv_usec - 
(start.tv_sec + 1e-6*start.tv_usec);
printf("inline: %g\n", total);

// out-of-line
gettimeofday(&start, 0);
for (i = 0; i < nrepeats; i++)
atomic_add2(&w, 1);
gettimeofday(&stop, 0);
total = stop.tv_sec + 1e-6*stop.tv_usec - 
(start.tv_sec + 1e-6*start.tv_usec);
printf("out-of-line: %g\n", total);
}

static void
atomic_add2 (volatile _Atomic_word* __mem, int __val)
{
  __asm__ __volatile__ ("lock; addl %0,%1"
: : "ir" (__val), "m" (*__mem) : "memory");
}

Re: pilot-link in Sid and Sarge: Much bigger question

[Björn Stenberg]

Stephen Ryan wrote:
> there is no substitute for testing in the *exact* environment that you
> plan to release in.  Period.

My point exactly. We should test packages in the environment we plan to
release: sarge. We should not let new uploads hold other packages
hostage. Because then we are only testing in sid, not in sarge.

-- 
Björn

Re: FVWM 2.5.x debs

[Harald Dunkel]

Hi Alex,
Alexander Kotelnikov wrote:
Hello.
Recently I was reported [1] by Marco d'Itri that FVWM from stable
branch (2.4.x) does not work with GNOME2, so he requested 2.5.x
packages from me.
Olivier Chapuis clarified the situation in his reply [2] to my
question in fvwm-workers mailing list.
FVWM packages are ready and apt'able now for stable and unstable on
386 architecture. Sources are provided in unstable branch only (since
stable package is just a rebuild).
Would it be possible to add these packages to the official pool
for Sid? fvwm 2.5.6 is surely stable enough for daily use, but
I can speak just for i386 here.
Regards
Harri

Re: Bug in apt-get ? [replace essential package / Yes, do as I say]

[Miquel van Smoorenburg]

According to [EMAIL PROTECTED]:
> On Sat, Apr 26, 2003 at 11:12:00AM +, Miquel van Smoorenburg wrote:
> 
> > It seems that currently apt is not able to replace an essential
> > package. Well in fact the package I am trying to replace isn't
> > even really essential...
> 
> It is able to, as you demonstrated, it just make it harder than normal.
> 
> There are a lot of wonky things that can happen during most of the essential
> package remove scenarios that can completely screw your system so it doesn't
> boot or can't run programs, install scripts or something er other.
> 
> Your case may or may not have these properties, it's impossible to tell.

Well yes, it probably is. Sysv-rc and file-rc *are not* essential.
Sysvinit is, and it depends on sysv-rc | file-rc, and that's why
apt 'upgrades' the status of those packages to Essential. Even if
I put Essential: no in the control file, apt still ignores that.

I'd say in this case apt is going slightly overboard. It's against
current policy, and dpkg itself does get it right.

Unix is all about having enough rope to hang yourself and being
able to shoot yourself in the foot etc, right, so why is apt
preventing me from doing something that actually makes a lot
of sense.

When replacing a (virtually) essential package, apt should simply
not remove the old package first and install the replacing
package after that. It should let dpkg take care of that. Apt
is able to order things the right way, so it should be able to
configure the replacing package as soon as it is unpacked.

Now I have to find a sane way to describe that, and file a
bug report against apt, I guess. Apt being written in C++ I'm
not going to try to fix it myself.

Mike.

Re: Announcing Debian Package Tags

[Erich Schubert]

> > - policy should require that tags are added
> 
> This is going to be problematic.  I think it would be better to have an
> override system where missing tags can be added by a central authority,
> rather than trying to force all maintainers to add tags or be NMUed.

Of course. they can be overriden the same way the section "gnome" was
overridden for these packages. So no uploads would be required, but the
packages can just be updated with their next uploads. Maybe some will
stay in the override file for a long time even.

I should also look at the localized-apt announced yesterday. This might
be nice to integrate. After all not everybody uses tag information, so
maybe we could keep those separate (i guess it's ~150kb gzipped)

> Speaking of adding tags, I've categorized a bunch of packages through the
> CGI interface, and while I appreciate its simplicity, it isn't very
> efficient for categorizing large numbers of packages.  I would be willing to
> put together some simple command line tools to accelerate the process, if
> you have not done this already.

Well, i have the basic tools there, i can do mass changes even matching
on package description or long description.
Basically anything i can SELECT from the DB and process in perl ;)

I planned to add a "upload" facility, where you can upload a
package: +tag, -tag
style diff file (or what ever diff format enricos tools have)
but i havn't had time to do so yet.
However when you send me such things i will hurry to do these changes.

The interface is lacking another big point: it doesn't yet automatically
add "implicit" tags - the tags "below" one tag in the tree structure -
so right now you have to add "devel" as well as "devel::lang::perl"
if you want to have the system work properly.

Yesterday i introduced another improvement: the interface doesn't form
subcategories that contain more than 80% of the matching packages.
That is, when you select "devel::lang::perl" but not "devel" it won't
provide you with the selection "devel" only, but provide a reasonable
list of useful choices. ;)

Still the system is way to slow and i fear slashdot...

Greetings,
Erich

Re: Yet Another Debianisation Aid - new features

[Denis Barbier]

On Mon, Apr 28, 2003 at 11:36:27PM +0200, Piotr Roszatycki wrote:
> Hi,
> 
> A few days ago I've uploaded new experimental version of yada. This is
> alternative way of building packages which doesn't use debhelper and
> doesn't require editing of Makefile.
> 
> The last release introduces macro preprocessor and 'build-indep'
> make target.

How are debconf translated templates files supposed to be managed?

Denis

Re: Bug#191167: ITP: oooqs-kde -- OpenOffice.org QuickStarter applet for KDE

[Michael Banck]

On Tue, Apr 29, 2003 at 02:25:27AM +0200, Rene Engelhard wrote:
> [1] the package will be called 1:0.99+1.0_rc3-1 to ensure upgradability
> to 1.0 and from the woody backport which was versioned
> 1.0_rc3-0woody1 :(

nothing against upgradability to 1.0, but introducing epochs right from
the start just to support unofficial woody-backports seems like a bad
idea to me.

Can't you introduce the epoch just prior to release, if the package is
still at 1.0? I don't think we absolutely *must* support people using
backports for woody wanting to upgrade to unstable.

Your call of course.

Michael

Re: FVWM 2.5.x debs

[Alexander Kotelnikov]

> On Tue, 29 Apr 2003 09:11:58 +0200
> "HD" == Harald Dunkel <[EMAIL PROTECTED]> wrote:
HD> 
HD> Hi Alex,
HD> Alexander Kotelnikov wrote:
>> Hello.
>> Recently I was reported [1] by Marco d'Itri that FVWM from stable
>> branch (2.4.x) does not work with GNOME2, so he requested 2.5.x
>> packages from me.
>> Olivier Chapuis clarified the situation in his reply [2] to my
>> question in fvwm-workers mailing list.
>> FVWM packages are ready and apt'able now for stable and unstable on
>> 386 architecture. Sources are provided in unstable branch only (since
>> stable package is just a rebuild).
>> 
HD> 
HD> Would it be possible to add these packages to the official pool
HD> for Sid? fvwm 2.5.6 is surely stable enough for daily use, but
HD> I can speak just for i386 here.

I really do not like this idea.

-- 
Alexander Kotelnikov
Saint-Petersburg, Russia

Re: OpenEXR packages

[Jesus Climent]

On Fri, Apr 25, 2003 at 06:08:50PM -0700, Drew Hess wrote:
> 
> Hi,
> 
> I'm the upstream maintainer of OpenEXR.  Is there anything I can do to
> help expedite getting OpenEXR into Debian?  Not much has happened since
> the original ITP as far as I can tell.  If something's broken on our side,
> let me know and I'll fix it.

Andrew will provide the packages, due to lack of time (need to finish my
Graduation Work and I moved to a new house).

mooch

-- 
Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69
--
 Registered Linux user #66350 proudly using Debian Sid & Linux 2.4.20

I've decided what to do with my life. I wanna be a cleaner.
--Mathilda (Leon, the Cleaner)

Re: Announcing Debian Package Tags

[Enrico Zini]

On Mon, Apr 28, 2003 at 03:23:24PM +0200, Javier Fernández-Sanguino Peña wrote:

> [1] One of the difficult things in the future might be to generate new tags
> or associate new packages to tags already available. Automatising (sp?) 
> this would be useful and TFIDF (and similar IA-related techniques) help
> with this quite a lot.

I've never tried the tools you are suggesting me, but I definitely will.
I have some immediate additions to make to tagcoll and debtags based on
the many suggestions I have received.

You're showing me a whole new world to explore, and I'll be sure do it
asap.


Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


pgp7s37uZRjBT.pgp
Description: PGP signature

Re: aag - wrapper for apt-get with support for recommend and suggests field

[Graham Williams]

Received Tue 29 Apr 2003  2:35pm +1000 from Alexander Wirt:
> Hi folks, 
> 
> i have written a small wrapper for apt-get that makes it possible to
> install all recommended and/or suggested Packages for a Package too. 
> ...

I've also got the same functionality in my apt-get wrapper, wajig, as
in:

  wajig installr 
  wajig installs 
  wajig installrs 

Wajig is installed with:

  apt-get install wajig

Regards,
Graham

Re: Announcing Debian Package Tags

[Javier Fernández-Sanguino Peña]

On Tue, Apr 29, 2003 at 12:38:18PM +0200, Enrico Zini wrote:
> On Mon, Apr 28, 2003 at 03:23:24PM +0200, Javier Fernández-Sanguino Peña 
> wrote:
> 
> > [1] One of the difficult things in the future might be to generate new tags
> > or associate new packages to tags already available. Automatising (sp?) 
> > this would be useful and TFIDF (and similar IA-related techniques) help
> > with this quite a lot.
> 
> I've never tried the tools you are suggesting me, but I definitely will.
> I have some immediate additions to make to tagcoll and debtags based on
> the many suggestions I have received.
> 

Notice that rainbow (libbow) is not being actively updated upstream 
anymore. The library works, the tool works, but some documentation is still 
lacking.


> You're showing me a whole new world to explore, and I'll be sure do it
> asap.

Glad to help.

Just FYI TFIDF is a very simple "technology" (as a matter of fact it's just
an equation) used to determine the 'weight' of words given a liberal text. 
It's useful for document clustering (because you can determine documents
belong to the same 'group' if they have the same word weights).

The application I found, in Debian, worth testing (which prompted me to 
develop the hack that 'dpkg-iasearch' is) is to use document clustering and 
TFIDF to find packages.

If you have a set of packages descriptions (let's say 4000) you can parse 
all the words in the descriptions, compare all the words in all the 
descriptions and determine which words are 'appropiate' to describe a given 
package. 

As a matter of fact, naturally, this same words are keywords that can 
describe a set of related packages and thus, this approach could be useful 
to automaticly tags new packages when they get into Debian.

Just my 2c.

Regards

Javi



pgpp75dqPcXpw.pgp
Description: PGP signature

Re: aag - wrapper for apt-get with support for recommend and suggests field

[David Nusinow]

On Tue, Apr 29, 2003 at 06:13:38AM +0200, Alexander Wirt wrote:
> Hi folks, 
> 
> i have written a small wrapper for apt-get that makes it possible to
> install all recommended and/or suggested Packages for a Package too. 
> A simple Call of: aag -rs  would install all recommended and
> suggested Packages for . The Code isn't very nice, but it works
> fine for me. I other people are interested in using this wrapper I would
> clean the code up and insert some features. Just take a look at:
> http://www.formorer.de/code/aag/aag
> Its just a small Perlscript with getopts and pod2usage as dependencys. 
> 
> I would be pleased to hear some comments from you. 

Why not just use aptitude?[1]

 - David

[1] Yes, I know it's still uninstallable, but that's hopefully not
going to be for much longer.

Re: /run/, resolvconf and read-only root

[Jamie Wilkinson]

This one time, at band camp, Jamie Wilkinson wrote:
>This one time, at band camp, Theodore Ts'o wrote:
>>... and those who have tried to explain why it's a bad idea or have
>>concerns have been brushed off.  So I've given up for now trying to
>>explain to you folks why I'm not convinced, since I don't have time to
>>go pig mud-wrestling, but please don't assume that silence means
>>assent.
>
>I don't recall you giving a strong argument why /run was a bad idea.  I do
>recall you voicing your concern and then having your concerns addressed.  If
>that is not the case, please reiterate them.

And just to make sure, I had a look back up the thread to see what your
complaints were, and the only thing you said in this thread was on the
21st of March, msgid <[EMAIL PROTECTED]> when you
said:

>Doing this would violate the FHS

It was replied to by Anthony Towns, who said:

>Nonsense; changes to the FHS have to first be trialled in distros,
>so adding new directories and moving things around is explicitly a
>supported part of the FHS process these days.

It seemed to me that opinion was more swayed towards giving this a try, and
seeing what happened.

I don't know what it will take to convince you, but I would like you to
answer these questions:

Do you think having programs write to /etc is a bad thing?

Where would you put /etc/mtab, to keep /etc sacrosanct?

-- 
[EMAIL PROTECTED]   http://people.debian.org/~jaq

Re: binary-or-shlib-defines-rpath from autotools

[Junichi Uekawa]

> W: gnunet-gtk: binary-or-shlib-defines-rpath ./usr/bin/gnunet-gtk
> /home/bug1/0.5.3/gnunet-0.5.3/debian/tmp/usr/lib
> 
> ./configure and the Makefile.in's mention -rpath, but rpath isnt set
> directly by configure.ac or Makefile.am, i dont know how to
> stop autotools from setting it.

My wild guess is that the build script is setting prefix rather
than DESTDIR ?


regards,
junichi

RE: Form0.iv

[Riggs, Mary]

Title: RE: Form0.iv





Cannot read this.


-Original Message-
From:   debian-devel [SMTP:[EMAIL PROTECTED]
Sent:   Monday, April 28, 2003 10:31 PM
To: [EMAIL PROTECTED]
Subject:    Form0.iv


 << File: now_app_gaining_cmd[1].htm >> 

libstdc++... Help please

[Nick Burkett]

Hi,
  I've just upgraded my sid system (i386) without
realising that libstdc++-pre6 is completely broken...
I've got an essay due in 24 hours which (was) being
written in lyx (which now doesn't work). Does anyone know
where I can get a pre5 version of libstdc++ from (my local
cache doesn't have it). Please CC me as I'm not on the mailing
list.
Thanks,
Nick


_
Hotmail now available on Australian mobile phones. Go to  
http://ninemsn.com.au/mobilecentral/hotmail_mobile.asp

Re: Root can't run X programs

[David Krider]

Cameron Hutchison wrote:
The next bit of juju is to set the environment variable XAUTHORITY to
~/.Xauthority, where  is the user that started the xserver.
This is great. What about taking it to the next level? What I mean is 
that I had been thinking about actually extracting the cookie from the 
server's auth file and sticking it in root's .Xauthority file for good 
(this is what Red Hat does), but I wasn't sure if the auth file changed 
on Debian. Unforunately, after checking, it seems like the auth file 
does change on every start of the X server. I see that 
/etc/kde2/kdm/Xservers has a line to start the X server, but in a `ps 
-ef' listing, I see an additional "-auth" option. How does this get to 
be a part of the command?

dk

Re: libstdc++... Help please

[Domenico Andreoli]

http://snapshot.debian.net/archive/2003/04/28/debian/pool/main/g/gcc-3.3/libstdc++5_3.3-0pre5_i386.deb

On Tue, Apr 29, 2003 at 12:02:38PM +, Nick Burkett wrote:
> 
> Hi,
>   I've just upgraded my sid system (i386) without
> realising that libstdc++-pre6 is completely broken...
> I've got an essay due in 24 hours which (was) being
> written in lyx (which now doesn't work). Does anyone know
> where I can get a pre5 version of libstdc++ from (my local
> cache doesn't have it). Please CC me as I'm not on the mailing
> list.
> 
> Thanks,
> Nick
> 

-[ Domenico Andreoli, aka cavok
 --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: libstdc++... Help please

[Otavio Salvador]

"Nick Burkett" <[EMAIL PROTECTED]> writes:

> Hi,

Hello Nick,

>I've just upgraded my sid system (i386) without
> realising that libstdc++-pre6 is completely broken...
> I've got an essay due in 24 hours which (was) being
> written in lyx (which now doesn't work). Does anyone know
> where I can get a pre5 version of libstdc++ from (my local
> cache doesn't have it). Please CC me as I'm not on the mailing
> list.

Got this in ftp at: http://ftp.debian.org/debian/pool/main/g/gcc-3.3/

Probably you need these files:

- 
http://ftp.debian.org/debian/pool/main/g/gcc-3.3/libstdc++5-3.3-dev_3.3-0pre5_i386.deb
- http://ftp.debian.org/debian/pool/main/g/gcc-3.3/libstdc++5_3.3-0pre5_i386.deb

[]s

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-

Re: libstdc++... Help please

[Nick Burkett]

Thanks for the help everyone... now on to the essay.

From: Otavio Salvador <[EMAIL PROTECTED]>
To: "Nick Burkett" <[EMAIL PROTECTED]>
CC: debian-devel@lists.debian.org
Subject: Re: libstdc++... Help please
Date: Tue, 29 Apr 2003 09:39:55 -0300
"Nick Burkett" <[EMAIL PROTECTED]> writes:
> Hi,
Hello Nick,
>I've just upgraded my sid system (i386) without
> realising that libstdc++-pre6 is completely broken...
> I've got an essay due in 24 hours which (was) being
> written in lyx (which now doesn't work). Does anyone know
> where I can get a pre5 version of libstdc++ from (my local
> cache doesn't have it). Please CC me as I'm not on the mailing
> list.
Got this in ftp at: http://ftp.debian.org/debian/pool/main/g/gcc-3.3/
Probably you need these files:
- 
http://ftp.debian.org/debian/pool/main/g/gcc-3.3/libstdc++5-3.3-dev_3.3-0pre5_i386.deb
- 
http://ftp.debian.org/debian/pool/main/g/gcc-3.3/libstdc++5_3.3-0pre5_i386.deb

[]s
--
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-

_
Hotmail now available on Australian mobile phones. Go to  
http://ninemsn.com.au/mobilecentral/hotmail_mobile.asp

Backporting a package from unstable to stable

[Andrew Pollock]

Hi,

To use an example, I'd like to take the source package for Snort (2.0.0-2) 
in unstable and rebuild it against stable so that I can update my 
otherwise stable installation with a newer version of Snort, without 
dragging in all the other dependencies from unstable that just installing 
the Snort 2.0.0-2 binary package from unstable would do.

Is it as simple as using something like pbuilder and tweaking the 
Build-Depends to match the versions of the packages that are in stable?

Andrew

Re: Root can't run X programs

[Vincent Zweije]

On Tue, Apr 29, 2003 at 07:10:06AM -0500, David Krider wrote:
||  Cameron Hutchison wrote:
||
||  >The next bit of juju is to set the environment variable XAUTHORITY to
||  >~/.Xauthority, where  is the user that started the xserver.

This shouldn't be necessary, since X clients default to $HOME/.Xauthority
for locating xauth cookies when XAUTHORITY is undefined.

Ahh, wait, I missed the context. You're setting XAUTHORITY as root
to ~mortaluser/.Xauthority. That's a good option.

||  This is great. What about taking it to the next level? What I mean is
||  that I had been thinking about actually extracting the cookie from the
||  server's auth file and sticking it in root's .Xauthority file for good
||  (this is what Red Hat does), but I wasn't sure if the auth file changed
||  on Debian.

Xdm generates a fresh cookie for every session and transmits it to
the X server through the XDMCP protocol.

Startx generates a fresh cookie for the session being started. Or
it least, it should.

|| Unforunately, after checking, it seems like the auth file
||  does change on every start of the X server.

You can modify the startx script to copy the cookie to ~root/.Xauthority.

Picking up the cookie that xdm uses can be done in the Xsession
script which is run at the beginning of every session. Or actually,
Xsession *is* the session under xdm, IIRC. I think the cookie is
stored somewhere in /var/run/xdm/auth/something. Check your xdm
config files for details.

However, I don't think this should be done by default, because it
would come too close to violating the privacy of the users, especially
for remote X session.

||  I see that
||  /etc/kde2/kdm/Xservers has a line to start the X server, but in a `ps
||  -ef' listing, I see an additional "-auth" option. How does this get to
||  be a part of the command?

Not sure about kdm. Can't remember if xdm does this too, but I don't
think so.

Ciao.Vincent.

Re: i386 compatibility & libstdc++

[Arnd Bergmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tuesday 29 April 2003 07:50, you wrote:
> Arnd Bergmann <[EMAIL PROTECTED]> writes:
> > No, look at my patch again. If you build without i486 optimization,
> > the compiler will see only the extern declaration for
> > __exchange_and_add().
>
> I see. What sonames do you suggest to give to the two copies of
> libstdc++? You once said you'd call them libstdc++-i386.so.5,
Yes, either have libstdc++-i386 for i386 optimized binaries plus
libstdc++ for others or have libstdc++ everywhere. Both should
work in principle. Using libstdc++-i386 will break Debian binaries
on other platforms explicitly, which may or may not be considered
a good idea.

> 2. Running Debian binaries on foreign systems won't be easy.
>In particular, they all link to libstdc++-i386.so.5, so
>such a library needs to be provided for other systems.
>Mixing that library with that native libstdc++.so.5 might
>cause problems, so anybody running a Debian binary on
>a foreign system would need the binary and all shared libraries
>it links with, even though those libraries have the same
>sonames as the libraries available on the foreign system.
There are two ways out of this:
 a) The patch gets merged upstream. It won't hurt anyone who is
building i486+ optimized binaries and fixes a real bug.
This would mean we should not have libstdc++-i386.so.5.
 b) We provide a libstdc++-i386.so.$(version) file that contains
only the __exchange_and_add function and is linked to 
libstdc++.so.

> 3. Debian i486 binaries take a significant performance hit.
>The attached program demonstrates that the cost of
>__atomic_add is roughly twice as much if done out-of-line,
>compared to the inline version. On my system, I get
> inline: 2.4061
> out-of-line: 4.60658

We can shave a bit off by making the function __attribute__((regparm(2)))
and perhaps by using a trivial non-locking variant when compiling
without threads, as the i386 version uses the mutex only in those
cases and AFAICS it is compatible with the i486 version otherwise.
The numbers I get on my P3 now are (in average cpu cycles):

non-locked   locked
i486 inline:   6.524.2
i486 out-of-line:  7.335.8
i386 inline:   4.5   189.9
i386 out-of-line:  9.9   196.4

If we know at compile time that locking (neither 'lock;' prefix nor
the mutex call) is never needed, we can even get much faster than the
current i486 code.

Also, if an application or library cares about this sort of 
micro-optimization, it probably should be provided in an optimized
version anyway.

Arnd <><
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+rnlj5t5GS2LDRf4RAm1SAJ0WwDALgWCpJ6/8l+xfk5oSWeftuwCeOoKz
jsbSsLCw1g4NlK6axPBQwXk=
=iwhP
-END PGP SIGNATURE-

Re: libstdc++... Help please

[Andreas Metzler]

Nick Burkett <[EMAIL PROTECTED]> wrote:
>   I've just upgraded my sid system (i386) without
> realising that libstdc++-pre6 is completely broken...
> I've got an essay due in 24 hours which (was) being
> written in lyx (which now doesn't work).

sid=unstable - you know that, don't you?

> Does anyone know where I can get a pre5 version of libstdc++ from
> (my local cache doesn't have it).

snapshot.debian.net?
  cu andreas
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: Backporting a package from unstable to stable

[Junichi Uekawa]

> To use an example, I'd like to take the source package for Snort (2.0.0-2) 
> in unstable and rebuild it against stable so that I can update my 
> otherwise stable installation with a newer version of Snort, without 
> dragging in all the other dependencies from unstable that just installing 
> the Snort 2.0.0-2 binary package from unstable would do.
> 
> Is it as simple as using something like pbuilder and tweaking the 
> Build-Depends to match the versions of the packages that are in stable?

To answer the question, the answer is 'no, not always'.

You need some try-and-error, and usually backporting one package
requires backporting of another. However, many people do it due to 
their needs.

The biggest stumbling block is probably debhelper; if you could ignore
that, things would be pretty straightforward (in most cases).



regards,
junichi

ITA: nail -- BSD mail(1) supporting MIME, SMTP, POP3/SSL and UTF-8

[Hilko Bengen]

Hi,

as the subject says, I intend to adopt nail. A new version, 10.5-1,
will be uploaded shortly.

-Hilko

Re: libstdc++... Help please

[Chris Cheney]

On Tue, Apr 29, 2003 at 02:26:23PM +0200, Andreas Metzler wrote:
> Nick Burkett <[EMAIL PROTECTED]> wrote:
> >   I've just upgraded my sid system (i386) without
> > realising that libstdc++-pre6 is completely broken...
> > I've got an essay due in 24 hours which (was) being
> > written in lyx (which now doesn't work).
> 
> sid=unstable - you know that, don't you?

debian stable = eternally ancient - you know that, don't you? 8)

Although currently stable is only ~ 1.5 yrs old software-wise, so it
wasn't as bad as before woody was released, when it was ~ 2.5 years old.

Chris

Re: aag - wrapper for apt-get with support for recommend and suggests field

[Alexander Wirt]

Am Die, 2003-04-29 um 13.08 schrieb David Nusinow:
> On Tue, Apr 29, 2003 at 06:13:38AM +0200, Alexander Wirt wrote:
> > Hi folks, 
> > 
> > i have written a small wrapper for apt-get that makes it possible to
> > install all recommended and/or suggested Packages for a Package too. 
> > A simple Call of: aag -rs  would install all recommended and
> > suggested Packages for . The Code isn't very nice, but it works
> > fine for me. I other people are interested in using this wrapper I would
> > clean the code up and insert some features. Just take a look at:
> > http://www.formorer.de/code/aag/aag
> > Its just a small Perlscript with getopts and pod2usage as dependencys. 
> > 
> > I would be pleased to hear some comments from you. 
> 
> Why not just use aptitude?[1]
Its interactive, I don't want to launch a GUI if I want so simple add a
package. Additionally it seams that aptitude is currently broken in Sid.
So this are two good reasons for me.

formorer
-- 
Alexander "formorer" Wirt   KeyID: BC7D020A
EMail: [EMAIL PROTECTED] ICQ: 28651245
WWW: http://www.formorer.de
Encrypted and Signed Email preferred.

Re: binary-or-shlib-defines-rpath from autotools

[Glenn McGrath]

On Tue, 29 Apr 2003 11:28:51 +0900
Junichi Uekawa <[EMAIL PROTECTED]> wrote:

> My wild guess is that the build script is setting prefix rather
> than DESTDIR ?

You are correct, i should know better than to make such basic mistakes.


Thanks

Glenn 

Re: Dropping/splitting (proper) i386 support

[Hamish Moffatt]

On Sun, Apr 27, 2003 at 04:32:37PM -0400, Nathanael Nerode wrote:
> This is an attempt to summarize some points.
>
> 1. Why do we have a problem, other than performance issues?
>
> * To maintain binary compatibility with other distributions for C++
> packages, Debian needs to use the i486+ version of atomicity.h supplied
> by GCC.
> * This version is significantly faster than the i386 version.
> * GCC 3.2 doesn't even supply a working i386 version (GCC 3.3 does).
> * This is exposed ABI (currently) and therefore cannot be solved by
> multilibbing.
 
I notice that we already have /usr/lib/i486/libstdc++.so.5 etc. Does this
mean we can have different versions of the library for i386, i486 etc?

Can we use the 486+ atomicity.h on everything other than i386, and use
the 386 version on i386? Then we'd have binary compatibility everywhere
except on i386, which would be better than dropping it completely.

> 2. What performance benefits do we get as side effects of dropping 386?
> 
> * i486 guarantees a 32-bit external data bus (386SX has a 16-bit bus.).
> http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02043.html
> Not sure if there's anyone programming to the data bus. :-)

This is simply an advantage of the 386DX or 486+; it shouldn't affect
compiled code.

> * i486 has a cache, and accordingly an 'invalidate cache' instruction. 
> * i486 has an 'invalidate TLB entry' instruction (INVLPG).  386 requires
> the flushing of the entire page table.

Does this affect compiled user-space code? Or only the kernel? Or
neither?

> * i486 has the BSWAP, XADD, and CMPXCHG instructions (and possibly 
> others -- I haven't found a complete list).

OK.

> * OpenSSL is *much* faster on i486+ than on i386.  The improvements for 
> going to i586, i686, etc. are not that great.
>  http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02031.html

OpenSSL already has 486, 586 and 686 versions; we don't need to
sacrifice i386 to get those benefits. (Is that correct?)

> * The kernel is markedly faster compiled for i486+ than on i386.  

But we already have seperate kernel packages for 386, 586tsc, 686, k6,
k7... We don't have to drop i386 support to improve performance on the
others.

Can you make a list of performance benefits that we only get by dropping
i386 support?



Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: libstdc++... Help please

[David Starner]

> sid=unstable - you know that, don't you?

We need someone to test unstable, don't we? We can not realistically
test our distribution if the only people running it are those with many
computers who put it on one they aren't really using. Please don't give
our testers crap for actually testing the system in real life
situations.

-- 
David Starner - [EMAIL PROTECTED]
Ic sæt me on anum leahtrice, ða com heo and bát me!

Re: libstdc++... Help please

[Michael Banck]

On Tue, Apr 29, 2003 at 02:26:23PM +0200, Andreas Metzler wrote:
> Nick Burkett <[EMAIL PROTECTED]> wrote:
> >   I've just upgraded my sid system (i386) without
> > realising that libstdc++-pre6 is completely broken...
> > I've got an essay due in 24 hours which (was) being
> > written in lyx (which now doesn't work).
> 
> sid=unstable - you know that, don't you?

The version of lyx in stable is only contrib, as it builds upon a
non-free library. This might matter to some people. You are right in
general though, of course.

Michael

Re: aag - wrapper for apt-get with support for recommend and suggests field

[Rene Engelhard]

Hi,

Alexander Wirt wrote:
> Its interactive, I don't want to launch a GUI if I want so simple add a

eh?

aptitude install
aptitude remove
aptitude purge

from command line.

> package. Additionally it seams that aptitude is currently broken in Sid.
> So this are two good reasons for me.

apt 0.5.5 shows Suggested and Recommended packages during
installation..
apitude can be fixed when the new apt will be in sid...

Regards,

Rene
-- 
 .''`.  Rene 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


pgpqbTncJRuSr.pgp
Description: PGP signature

Re: aag - wrapper for apt-get with support for recommend and suggests field

[Kai Weber]

On Tue, Apr 29, 2003 at 03:58:34PM +0200, Alexander Wirt wrote:

> > Why not just use aptitude?[1]
> Its interactive, I don't want to launch a GUI if I want so simple add a
> package. Additionally it seams that aptitude is currently broken in Sid.
> So this are two good reasons for me.

aptitude can be used interactive, too.

aptitude install foo

Kai

Re: libstdc++... Help please

[Anthony Towns]

On Tue, Apr 29, 2003 at 09:04:06AM -0500, Chris Cheney wrote:
> On Tue, Apr 29, 2003 at 02:26:23PM +0200, Andreas Metzler wrote:
> > Nick Burkett <[EMAIL PROTECTED]> wrote:
> > >   I've just upgraded my sid system (i386) without
> > > realising that libstdc++-pre6 is completely broken...
> > > I've got an essay due in 24 hours which (was) being
> > > written in lyx (which now doesn't work).
> > sid=unstable - you know that, don't you?
> debian stable = eternally ancient - you know that, don't you? 8)
> Although currently stable is only ~ 1.5 yrs old software-wise, so it

I'm not sure where you get that from; woody was released July 20th last year,
which is a little over 3/4th of a year ago, and uploads were being accepted
into testing without special consideration up until pretty much a year ago
today. The libreadline-java from stable, for example, was uploaded on 19th
April 2002, eg.

You can make claims about things like X being overly old (X 4.2 was
released January last year, we're shipping X 4.1 in woody), but that's
not really very meaningful when we're not shipping X 4.3 (released two
months ago) even in unstable.

> wasn't as bad as before woody was released, when it was ~ 2.5 years old.

If you're implying this isn't a good thing, and that we should be providing
current software that's bug free and reliable, you might like to consider
fixing all of:

Package: kdeadmin (debian/main).
Maintainer: Christopher L Cheney <[EMAIL PROTECTED]>
  185622 kdeadmin_4:3.1.1-2(m68k/unstable/thing2): fails to build from source

Package: kdebase (debian/main).   
Maintainer: Christopher L Cheney <[EMAIL PROTECTED]>
  184678 kdebase_4:3.1.1-1(hppa/unstable): FTBFS: non-PIC in shared lib
  186419 kdebase: upgrade from woody to sid breaks kde

Package: kdelibs (debian/main).
Maintainer: Christopher L Cheney <[EMAIL PROTECTED]>
  185697 kdelibs: KDE linked to obsolete libssl0.9.6 instead of 0.9.7

Package: kdemultimedia (debian/main).
Maintainer: Christopher L Cheney <[EMAIL PROTECTED]>
  181624 FTBFS: dga extension problem
  188221 kdemultimedia_4:3.1.1-1(m68k/unstable/poseidon): FTBFS, missing [...]

Package: kdeprint (debian/main).
Maintainer: Christopher L Cheney <[EMAIL PROTECTED]>
  142489 kdeprint: needs recommends on efax/hylafax/mgetty-fax
  185843 kdeprint: library load error

Package: kdm (debian/main).
Maintainer: Christopher L Cheney <[EMAIL PROTECTED]>
  181082 AltGr does not work under XFree-v3

Package: kmail (debian/main).
Maintainer: Christopher L Cheney <[EMAIL PROTECTED]>
  185773 kmail 4:2.2.2-14.23 gives  relocation error: kmail: undefined [...]

Package: konqueror (debian/main).
Maintainer: Christopher L Cheney <[EMAIL PROTECTED]>
  190945 konqueror: Konqueror 2 hatte noch keinen "feed the mozilla" button

Package: korganizer (debian/main).
Maintainer: Christopher L Cheney <[EMAIL PROTECTED]>
  185823 korganizer: clicking To-Do checkbox eats all memory

Package: kpackage (debian/main).
Maintainer: Christopher L Cheney <[EMAIL PROTECTED]>
  188575 kpackage: unable to install packages

Package: ktalkd (debian/main).
Maintainer: Christopher L Cheney <[EMAIL PROTECTED]>
  147762 ktalkd: change run as user to nobody

Package: libao (debian/main).
Maintainer: Christopher L Cheney <[EMAIL PROTECTED]>
  189160 libao: FTBFS: Build-Depends on libarts-dev

Unless I'm miscounting, 11 of these were filed over a month ago.

Cheers,
aj

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

  ``Dear Anthony Towns: [...] Congratulations -- 
you are now certified as a Red Hat Certified Engineer!''


pgpg2ShTxZJ1t.pgp
Description: PGP signature

Re: Announcing Debian Package Tags

[Matt Zimmerman]

On Tue, Apr 29, 2003 at 09:58:16AM +0200, Erich Schubert wrote:

> Of course. they can be overriden the same way the section "gnome" was
> overridden for these packages. So no uploads would be required, but the
> packages can just be updated with their next uploads. Maybe some will stay
> in the override file for a long time even.

Indeed.  I see no reason to try to use policy to strongarm maintainers into
adding tags, or to create a lot of work to add tags to orphaned packages.

> Well, i have the basic tools there, i can do mass changes even matching
> on package description or long description.
> Basically anything i can SELECT from the DB and process in perl ;)

Yes, but unless you want to do all of the tagging yourself, this is not
ideal. :-)

> I planned to add a "upload" facility, where you can upload a
> package: +tag, -tag
> style diff file (or what ever diff format enricos tools have)
> but i havn't had time to do so yet.
> However when you send me such things i will hurry to do these changes.

Ah, I will have to look at enrico's tools.

> The interface is lacking another big point: it doesn't yet automatically
> add "implicit" tags - the tags "below" one tag in the tree structure -
> so right now you have to add "devel" as well as "devel::lang::perl"
> if you want to have the system work properly.

I have not been doing that (nor removing the not-yet-tagged tags) with the
presumption that this can be automated en masse at a later time.

-- 
 - mdz

Re: aag - wrapper for apt-get with support for recommend andsuggests field

[Michael Banck]

On Tue, Apr 29, 2003 at 03:58:34PM +0200, Alexander Wirt wrote:
> Am Die, 2003-04-29 um 13.08 schrieb David Nusinow:
> > On Tue, Apr 29, 2003 at 06:13:38AM +0200, Alexander Wirt wrote:
> > Why not just use aptitude?[1]
> Its interactive, I don't want to launch a GUI if I want so simple add a
> package. Additionally it seams that aptitude is currently broken in Sid.
> So this are two good reasons for me.

aptitude [install,(dist-)upgrade] on the command line looks exactly like
apt-get, except that it works like aptitude.

Michael

Re: aag - wrapper for apt-get with support for recommend and suggests field

[Alexander Wirt]

Am Die, 2003-04-29 um 17.01 schrieb Rene Engelhard:
> Hi,
> 
> Alexander Wirt wrote:
> > Its interactive, I don't want to launch a GUI if I want so simple add a
> 
> eh?
> 
> aptitude install
> aptitude remove
> aptitude purge
I'm really sorry, but this sound very new to me. But its very nice to know. 
I have to give aptitide another chance if its back in the pool.

> from command line.
> 
> > package. Additionally it seams that aptitude is currently broken in Sid.
> > So this are two good reasons for me.
> 
> apt 0.5.5 shows Suggested and Recommended packages during
> installation..
> apitude can be fixed when the new apt will be in sid...
*wait*

Best regarss 

formorer
-- 
Alexander "formorer" Wirt   KeyID: BC7D020A
EMail: [EMAIL PROTECTED] ICQ: 28651245
WWW: http://www.formorer.de
Encrypted and Signed Email preferred.

国内外软件解密服务

[123]

如果本邮件不是你所需要的，我们表示抱歉，请随手删除或按回复删除!!!
---
专业提供加密、解密国内外的加密狗、注册机
1、硬件加密狗破解；
2、软件完全破解；
3、软件注册机提取；
4、去除软件时间限制（如把网络版的10用户改成100用户，打印功能等）；
5、国外大型数据库破解；

联系人:毛先生
电话：013175112922
E-mail:[EMAIL PROTECTED]

声明：本服务只供学习、相互交流。用于合法用途，建议您支持正版软件。

Re: Dropping/splitting (proper) i386 support

[Adrian 'Dagurashibanipal' von Bidder]

On Tuesday 29 April 2003 16:40, Hamish Moffatt wrote:
> On Sun, Apr 27, 2003 at 04:32:37PM -0400, Nathanael Nerode wrote:

> > * i486 guarantees a 32-bit external data bus (386SX has a 16-bit bus.).
> > http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02043.ht
> >ml Not sure if there's anyone programming to the data bus. :-)
>
> This is simply an advantage of the 386DX or 486+; it shouldn't affect
> compiled code.

Just a guess: some error could occur between the first and second halfword on 
386SX, where a 32 bit access on all other machines is atomic - this might 
matter for some operations

-- vbi

-- 
OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481


pgpU8egeLppPV.pgp
Description: signature

Re: Announcing Debian Package Tags

[David Roundy]

On Mon, Apr 28, 2003 at 09:46:47PM -0500, Manoj Srivastava wrote:
> On Mon, 28 Apr 2003 17:06:14 -0400, David Roundy
> <[EMAIL PROTECTED]> said:  
> > probably wouldn't hid mp3blaster.  Maybe novices should only be
> > shown gui programs after all.  They probably don't want to be using
> > a shell anyways...
> 
> I would object to such a major disservice to people just
> because they happen to be new to Linux.  This is blatant
> discrimination. 

I wasn't saying that novices shouldn't be using a shell.  Just that I do
think it would be helpful to allow novices, if they wish, to browse only
those packages which don't require the use of a shell, which hardly seems
discriminatory to me.
-- 
David Roundy
http://civet.berkeley.edu/droundy/

debian-devel@lists.debian.org

[Michael Meskes]

Package: wnpp
Version: unavailable; reported 2003-04-29
Followup-For: Bug #148421

Since this ITP is almost a year old and there is a package available
under http://kopete.creativa.cl/debian/sid/ and the packages applies for
NM and I am willing to sponsor him, I hope no one opposes us to go ahead
and upload kopete 0.6.1a or a newer version (if available once we
finished the package).

There are some packaging thing left to be done, but the binary provided
at this URL already works. Just enter

deb http://kopete.creativa.cl/debian/sid/ ./

to sources.list to test.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux feivel 2.4.20-1-k7 #3 Sam Mär 29 21:35:23 CET 2003 i686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8

Re: Bug in apt-get ? [replace essential package / Yes, do as I say]

[Jason Gunthorpe]

On Tue, 29 Apr 2003, Miquel van Smoorenburg wrote:

> > There are a lot of wonky things that can happen during most of the essential
> > package remove scenarios that can completely screw your system so it doesn't
> > boot or can't run programs, install scripts or something er other.
> > 
> > Your case may or may not have these properties, it's impossible to tell.
 
> Well yes, it probably is. Sysv-rc and file-rc *are not* essential.
> Sysvinit is, and it depends on sysv-rc | file-rc, and that's why
> apt 'upgrades' the status of those packages to Essential. Even if
> I put Essential: no in the control file, apt still ignores that.

Well, for the purposes of this check they are essential. It is
specifically designed to prevent against 
 
> I'd say in this case apt is going slightly overboard. It's against
> current policy, and dpkg itself does get it right.

It isn't against policy.

> Unix is all about having enough rope to hang yourself and being
> able to shoot yourself in the foot etc, right, so why is apt
> preventing me from doing something that actually makes a lot
> of sense.

Yeah, well, a few years ago people were busilly shooting themselves in the
foot and rendering their systems completely inoperable by removing
these 'virtually eseential' packages. They complained loudly that it
should not be the way it was and I agreed. So this check is here to
stay.

You have to find another way to do what you want that isn't so risky.

> When replacing a (virtually) essential package, apt should simply
> not remove the old package first and install the replacing
> package after that. It should let dpkg take care of that. Apt
> is able to order things the right way, so it should be able to
> configure the replacing package as soon as it is unpacked.

This isn't relevent. Dpkg does the same operations internally, it just
does them a little faster. You still get the same potential bad effects.

> Now I have to find a sane way to describe that, and file a
> bug report against apt, I guess. Apt being written in C++ I'm
> not going to try to fix it myself.

It's not a bug, so please don't file more pointless bugs against it.

I seriously recommend against using virtual packages, or |'s with packages
that are marked essential. There is alot of very poor behavior you will
run into.

Jason

Re: Bug#191037: /run/, resolvconf and read-only root

[Manoj Srivastava]

On Tue, 29 Apr 2003 00:32:46 +0200, Emile van Bergen
<[EMAIL PROTECTED]> said:  

> On Mon, Apr 28, 2003 at 05:54:37PM -0400, Sam Hartman wrote:

>> I'd certainly feel better if there were a broader consensus than
>> just Debian before moving in this direction.

> I think if Debian comes up with a good idea that's applicable to any
> Unix, be it Free/Open/NetBSD or the commercial *nixes, it would be a
> waste to wait with the implementing it till the others adopt it
> before us.

> Also, others may not adopt till they have seen a succesful
> implementation. Incidentally, this also applies to the FHS.

>> So, for now I'll sit back and see what other people do about /run.

> If you mean other GNU/Linux distributions or the *BSDs, don't hold
> your breath. If you mean Debian developers, it seems that a lot of
> good progress is being made.

I am concerned about the impact these changes will have on
 interoperability with other machines in a heterogeneous
 environments.  Are we facting in the negatives of doing things
 differently from everyone else into this decision? 

I had a number of questions about this, that I posted in the
 -policy mailing list; and there have been some answers. 

: Issues of concern: Do we have a consensus on a solution? is
: this doable? How much impact would it have on compatibility? What is
: the initial reaction to the proposal on the FHS lists?

If we are going to go through with this transition, we'll have
 to defend our choice at several points, to several parties. I suggest
 the proponents of this change put together a central location
 (preferably a web site) with the arguments for this.

I would suggest some starting points:
 a) The use case that motivate this proposal:
The debian-devel mailing list, 
From: Thomas Hood <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
Subject: Re: /run/, resolvconf and read-only root
I would also suggest expanding on these, and presenting a
Rationale for each case. 

 b) List of changes proposed, made, and to do:
From: Thomas Hood <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
Subject: /run/, resolvconf and read-only root

 c) List of changes in behaviour

 d) Impact on interoperability: how would administering a Debian box be
different from administering any other Linux box? (based on c)

 e) List of negatives for the proposal, and a rebuttal. I suggest you
ask the opponents for collaboration on this section.

Manoj
-- 
The FALAFEL SANDWICH lands on my HEAD and I become a VEGETARIAN ...
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: libstdc++... Help please

[Gunnar Wolf]

> > sid=unstable - you know that, don't you?
> 
> We need someone to test unstable, don't we? We can not realistically
> test our distribution if the only people running it are those with many
> computers who put it on one they aren't really using. Please don't give
> our testers crap for actually testing the system in real life
> situations.

Nope. We need ourselves to play with unstable - but unstable is not up
for testing. That's what *testing* is for! :-)

Ideally, Sid should stay as a developer testbed. In fact, when I started
using it, I got disappointed because it is not unstable at all. I have
only had a major (for me) problem once or twice.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

hi

[sweet-jenny]

Schade das du schon aus dem chat bist,ich wollte dir doch noch ein paar bilder 
von mir zeigen.na ja schau sie dir halt jetzt an und sage mir dann wie du sie 
findest :-))

http://www.jenny17.de.ms/

bis dann sagt jenny

Re: Bug#191036: create /run for programs that run before /var is mounted

[Thomas Hood]

I agree with Manoj when he says:
> I think it is premature to [r]atify into policy an action
> that has not been fully decided upon, and has not yet had
> all the kinks ironed out [...]

However, there does need to be some discussion of what
properties /run/ will have.  Early in the debian-devel 
discussion it was suggested that /run/ be required to be
RAM-based, that it be initialised with a skeleton, etc.

As the discussion went on there seemed to be agreement 
that /run/'s properties should be determined by the 
problem it is solving, namely, the problem of there being
nowhere to store runtime state prior to the availability of
/var/run/ on a system that mounts /var/ from the network.
To solve this problem, /run/ needs to be available locally
so that it can be mounted early, probably by
/etc/rcS.d/S35mountall.sh .

I would argue that for the present /run/ should be so defined,
and otherwise should be implemented as simply as possible.

Proposed list of properties of /run/:
* Available and empty after /etc/rcS.d/S35mountall.sh runs
* No skeleton
* Files stored in /run/ are not "reaped"
* A program should *only* use /run/ if it *must* do so because
  it has to store something before /var/run/ becomes available
  on systems that mount /var/ over NFS.
-- 
Thomas Hood <[EMAIL PROTECTED]>

Announcing second release of Debian Package Tags

[Enrico Zini]

Hello.

I'm announcing it again in debian-devel because it contains new
infrastructure to support proposals that are being discussed here, and
to ask a small testing run: if I see no big showstoppers, this is the
version that tomorrow I will upload to unstable.

I have made a bunch of neat additions:

Major updates to tagcoll (the computing engine enabling every sort of
operations on the tag databases):

 - Added a "reverse" command to tagcoll.  Now, if we want to see all
   packages that have a given tag, we can just do this:

   tagcoll reverse collection-file | grep ^tag:

   (of course it might have other applications)
 
 - Added the --derived-tags-from option to tagcoll.  This allows the
   introduction of tags that are added to an item if an expression
   matches the item tag set.  For example, we can define this (from a
   proposal by David Roundy):

   userlevel::novice: !specialized && (interface::gui || interface::curses)

   Tagcoll is now able to expand such things.


Major updates to debtags (the tool that manages the tag database for
Debian):

 - Include a tag database with debtags (to be used for networkless
   systems, and, in the future, as the well-tested database for stable
   system)
 - Add the possibility of installing local vocabulary additions in
   /etc/tagvoc.d
 - Merge the master vocabulary and all the additions at update time.
   This means that the public location of the vocabulary has been
   changed to /var/lib/debtags/vocabulary
 - Extract implications and derived tags from the merged vocabulary at
   import time and keep them in
   /var/lib/debtags/{implications,derived-tags}
   They can now be used directly for tagcoll manipulations of the
   database
 - Expand implications and derived tags at update time, so that
   applications using the package database will find them.  The package
   database can then be re-compressed at any time with tagcoll.


We can now have custom vocabulary bits installed by {sub,meta}distro
maintainers with records like this:
---
Tag: userlevel::novice
Derived: !specialized && (interface::gui || interface::curses)

Tag: specialized
Derived: (!toy && !educational) && (devel || chemistry || electronics)
---

And yes, expressions can reference other expressions and tags resulting
from implication expansion, too.


I hope this can give the required technical support for the many good
proposals I've seen in the list.


Ciao! Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


pgp1pwhTVbPtp.pgp
Description: PGP signature

Re: Announcing Debian Package Tags

[Manoj Srivastava]

On Tue, 29 Apr 2003 12:24:19 -0400, David Roundy <[EMAIL PROTECTED]> said: 

> On Mon, Apr 28, 2003 at 09:46:47PM -0500, Manoj Srivastava wrote:
>> On Mon, 28 Apr 2003 17:06:14 -0400, David Roundy
>> <[EMAIL PROTECTED]> said:
>> > probably wouldn't hid mp3blaster.  Maybe novices should only be
>> > shown gui programs after all.  They probably don't want to be
>> > using a shell anyways...
>>
>> I would object to such a major disservice to people just because
>> they happen to be new to Linux.  This is blatant discrimination.

> I wasn't saying that novices shouldn't be using a shell.  Just that
> I do think it would be helpful to allow novices, if they wish, to
> browse only those packages which don't require the use of a shell,
> which hardly seems discriminatory to me.  

To be precise, you said "Maybe novices should only be shown
 gui programs after all". Not that novices should be allowed to decide
 to only view gui programs IF THEY WISH, as you said later. The first
 message impled that some one other than novices decides what to show
 them, then you toned it down to being a choice of the end user, which
 is acceptable.

manoj
-- 
It will be generally found that those who sneer habitually at human
nature and affect to despise it, are among its worst and least
pleasant examples. Charles Dickens
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: libstdc++... Help please

[Chris Cheney]

On Wed, Apr 30, 2003 at 01:42:20AM +1000, Anthony Towns wrote:
> I'm not sure where you get that from; woody was released July 20th last year,
> which is a little over 3/4th of a year ago, and uploads were being accepted
> into testing without special consideration up until pretty much a year ago
> today. The libreadline-java from stable, for example, was uploaded on 19th
> April 2002, eg.
> 
> You can make claims about things like X being overly old (X 4.2 was
> released January last year, we're shipping X 4.1 in woody), but that's
> not really very meaningful when we're not shipping X 4.3 (released two
> months ago) even in unstable.

Woody was effectively frozen around Jan 2002, no major changes to
packages were permitted, etc. The fact that other distributions make
releases 2 - 3 times a year and debian still does multi year releases
ensures the users we have left, that aren't using it solely for servers
where stability is paramount, will be using unstable.

On a side note tracking bugs in testing would be interesting, because it
is generally thought testing is more stable than unstable, but I doubt
this is really the case. Right now we generally close a bug once it goes
into unstable but that bug that was just fixed probably still exists in
testing.

> > wasn't as bad as before woody was released, when it was ~ 2.5 years old.
> 
> If you're implying this isn't a good thing, and that we should be providing
> current software that's bug free and reliable, you might like to consider
> fixing all of:

- snip my numerous RC bugs -

I plan to work on them as soon as I graduate (which is in two weeks)...
I closed quite a few bugs (RC and regular) when I had some free time
earlier this month, I still have around 600 open bugs though.

In general I don't think its a good idea for a package to having only
one maintainer. It may work for smaller packages, but even then many
times maintainers vanish or forget to update their packages. I think
having a rcs system that contained all the packaging information
required to build the entire distribution in one place that all DD's
had access to (and actually used) would be a good thing. That along
with a method of automatically determining which packages are out of
date with upstream (possibly using a mandated watch file) could help
to keep debian up to date. Having a centralized repo could also help
with other things such as updating i18n templates, etc. (imho of
course, ymmv)

Chris

Re: libstdc++... Help please

[Chris Cheney]

On Tue, Apr 29, 2003 at 12:45:32PM -0500, Gunnar Wolf wrote:
> > > sid=unstable - you know that, don't you?
> > 
> > We need someone to test unstable, don't we? We can not realistically
> > test our distribution if the only people running it are those with many
> > computers who put it on one they aren't really using. Please don't give
> > our testers crap for actually testing the system in real life
> > situations.
> 
> Nope. We need ourselves to play with unstable - but unstable is not up
> for testing. That's what *testing* is for! :-)

Testing in almost all cases is worse than unstable. Two major reasons,
it doesn't get security updates at all, and two you don't even know what
bugs are in it since they get closed when the bug is fixed in unstable.
The fact that things rarely migrate from unstable into testing due to
the fact that forward and reverse dependencies must be met only
compounds the problem.

Chris

Re: Bug#191036: create /run for programs that run before /var is mounted

[Steve Langasek]

On Tue, Apr 29, 2003 at 08:26:07PM +0200, Thomas Hood wrote:

> * Files stored in /run/ are not "reaped"

I would supplement this by saying that programs which use /run/ may not
depend on state being preserved across reboots.  This permits the use of
a ramfs for those who desire it.

Otherwise, I think you've captured the requirements well.

-- 
Steve Langasek
postmodern programmer


pgpo5FdfAs9rR.pgp
Description: PGP signature

Re: FVWM 2.5.x debs

[Marco d'Itri]

On Apr 29, Alexander Kotelnikov <[EMAIL PROTECTED]> wrote:

 >Actually, I would like to close #189664 without uploading any fvwm2.5
 >packages to unstable, if no one  objects.
I object, as the problem (fvwm not working with gnome2) still exists.
The open bug will help other users to find the solution.

-- 
ciao, |
Marco | [698 alfBogIjEKdmM]

Re: Bug#191036: /run/, resolvconf and read-only root

[Marco d'Itri]

On Apr 29, Jamie Wilkinson <[EMAIL PROTECTED]> wrote:

 >Do you think having programs write to /etc is a bad thing?
Yes.

 >Where would you put /etc/mtab, to keep /etc sacrosanct?
I would teach mount to follow the /etc/mtab. Actually, I remember that
somebody already did this as he wrote about it on #debian-devel.

-- 
ciao, |
Marco | [701 taaMb9.vY4Hms]

Re: i386 compatibility & libstdc++

[Martin v. Löwis]

Arnd Bergmann <[EMAIL PROTECTED]> writes:

>  a) The patch gets merged upstream. It won't hurt anyone who is
> building i486+ optimized binaries and fixes a real bug.

Upstream won't accept the patch, because of the performance penalty.

Even if upstream accepts the patch, that won't be before gcc
3.4. However, the gcc 3.2/3.3 ABI will stay with us for a long time
(most likely until after the next Debian release).

>  b) We provide a libstdc++-i386.so.$(version) file that contains
> only the __exchange_and_add function and is linked to 
> libstdc++.so.

That would work, yes.

> We can shave a bit off by making the function __attribute__((regparm(2)))

Even with that change, and -fomit-frame-pointer, I get

inline: 2.39809
out-of-line: 4.0224

i.e. this is still a 60% slowdown (in a test case where the processor
does branch prediction correctly all the time, and everything is in
the cache). The assembler code is

_Z11atomic_add2PVii:
lock; addl %edx,(%eax)
ret

so it can't get any better. The performance hit is still unacceptable.

> and perhaps by using a trivial non-locking variant when compiling
> without threads, as the i386 version uses the mutex only in those
> cases and AFAICS it is compatible with the i486 version otherwise.

That won't help anything. "Compiling without threads" isn't really
supported on Linux: if threads are not used, this is always a
link-time/runtime issue, not a compile time issue.

> If we know at compile time that locking (neither 'lock;' prefix nor
> the mutex call) is never needed, we can even get much faster than the
> current i486 code.

We never know that.

> Also, if an application or library cares about this sort of 
> micro-optimization, it probably should be provided in an optimized
> version anyway.

I think the performance loss for applications like KDE will be
significant. I doubt that providing two versions of KDE (i386
and i486+) would be feasible.

Regards,
Martin

Re: libstdc++... Help please

[Jérôme Marant]

Chris Cheney <[EMAIL PROTECTED]> writes:


> In general I don't think its a good idea for a package to having only
> one maintainer. It may work for smaller packages, but even then many
> times maintainers vanish or forget to update their packages. I think
> having a rcs system that contained all the packaging information
> required to build the entire distribution in one place that all DD's
> had access to (and actually used) would be a good thing. That along

We have the alioth service nowdays, which is made for easying the
work in team on packaging.

Cheers,

-- 
Jérôme Marant

http://marant.org

Re: i386 compatibility & libstdc++

[Morgon Kanter]

This one time, at band camp, [EMAIL PROTECTED] (Martin v. L) wrote:
> I think the performance loss for applications like KDE will be
> significant. I doubt that providing two versions of KDE (i386
> and i486+) would be feasible.

Not starting a flamewar here, but in all honesty, who is going to try 
to use KDE on a 386 anyway? Actually, while we are on that, who is even 
going to try to use X at all on a 386?

--
You said homosexuals form a small percentage of the population.  So
do Jews.  Is that a reason to deny someone equality?
 - Richard Marceau

Re: libstdc++... Help please

[Andreas Metzler]

David Starner <[EMAIL PROTECTED]> wrote:
>> sid=unstable - you know that, don't you?

> We need someone to test unstable, don't we? We can not realistically
> test our distribution if the only people running it are those with many
> computers who put it on one they aren't really using. Please don't give
> our testers crap for actually testing the system in real life
> situations.

If somebody _needs_ his computer working 100% ("I've got an essay due
in 24 hours...") and runs unstable on it imho some reminder that this
might be a bad choice is *required*.
 cu andreas
PS: And please don't forget the fact that I did provide a solution for
the original problem.

libstdc++-pre6 vs build machines

[Jack Howarth]

   I was wondering if any effort was being made
to hold the build machines from installing the
broken libstdc++-5_3.3-0pre6 packages. If there 
are missing symbols in those new libstdc++ libs
I am wondering what the impact will be for
any c++ code built against pre6 when the symbols
return in the next fixed libstdc++ build.
Jack

Re: i386 compatibility & libstdc++

["Martin v. Löwis"]

Morgon Kanter wrote:
Not starting a flamewar here, but in all honesty, who is going to try 
to use KDE on a 386 anyway? Actually, while we are on that, who is even 
going to try to use X at all on a 386?
Probably nobody will. IMO, it is the worse that the KDE binaries have
to be built for i386 compatibility (as the Debian package will have
i386 in its name)
Regards,
Martin

Re: Bug#148421: kopete 0.6.1a

[Chris Cheney]

*** Please type your report below this line ***
Message-ID: <[EMAIL PROTECTED]>
Mail-Followup-To: [EMAIL PROTECTED],
debian-devel@lists.debian.org
References: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.5.4i

On Tue, Apr 29, 2003 at 06:59:52PM +0200, Michael Meskes wrote:
> Package: wnpp
> Version: unavailable; reported 2003-04-29
> Followup-For: Bug #148421
> 
> Since this ITP is almost a year old and there is a package available
> under http://kopete.creativa.cl/debian/sid/ and the packages applies for
> NM and I am willing to sponsor him, I hope no one opposes us to go ahead
> and upload kopete 0.6.1a or a newer version (if available once we
> finished the package).

Sounds fine to me. Kopete inclusion in kdenetwork got pushed back to the
KDE 3.2 release which currently doesn't have an estimated release date.

Chris

Re: libstdc++... Help please

[Keegan Quinn]

On Tuesday 29 April 2003 11:05 am, Andreas Metzler wrote:
> David Starner <[EMAIL PROTECTED]> wrote:
> >> sid=unstable - you know that, don't you?
> >
> > We need someone to test unstable, don't we? We can not realistically
> > test our distribution if the only people running it are those with many
> > computers who put it on one they aren't really using. Please don't give
> > our testers crap for actually testing the system in real life
> > situations.
>
> If somebody _needs_ his computer working 100% ("I've got an essay due
> in 24 hours...") and runs unstable on it imho some reminder that this
> might be a bad choice is *required*.

Running unstable in general is no big deal - in fact I would go so far as to 
say that on many days, an unstable snapshot is better than a commercial Linux 
stable release - but people should be exercising some significant care when 
upgrading, especially under deadlines like this.  Lots of people (like me) 
have no problem running unstable, encountering and dealing with bugs, but 
people in this position need to take responsibility for introducing new code 
into their own systems.

In other words, if you have serious (non-Debian) work to do on an unstable 
machine that is functioning properly, don't upgrade - doing this is like 
asking, "are there any new bugs I can work on?"  If you don't really want to 
work on those bugs right then, wait!

 - Keegan

Re: aag - wrapper for apt-get with support for recommend and suggests field

[Daniel Burrows]

On Tue, Apr 29, 2003 at 03:58:34PM +0200, Alexander Wirt <[EMAIL PROTECTED]> 
was heard to say:
> Its interactive, I don't want to launch a GUI if I want so simple add a
> package. Additionally it seams that aptitude is currently broken in Sid.
> So this are two good reasons for me.

  apt is broken in sid now too.  Isn't unstable fun? :)

Working on my epic play "Waiting for doogie" [0],
  Daniel

  [0] or this week, "Waiting for the ftpmasters"

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|   "Next, consider a circle passing through infinity; that   |
|is, a straight line.."   |
\ News without the $$ -- National Public Radio -- http://www.npr.org /

Re: i386 compatibility & libstdc++

[Andreas Metzler]

Morgon Kanter <[EMAIL PROTECTED]> wrote:
> This one time, at band camp, [EMAIL PROTECTED] (Martin v. L) wrote:
>> I think the performance loss for applications like KDE will be
>> significant. I doubt that providing two versions of KDE (i386
>> and i486+) would be feasible.

> Not starting a flamewar here, but in all honesty, who is going to try 
> to use KDE on a 386 anyway? Actually, while we are on that, who is even 
> going to try to use X at all on a 386?

Afaict the performance hit Martin is talking about does not hit i386
but i486+
<[EMAIL PROTECTED]>
cu andreas

Re: libstdc++... Help please

[Daniel Burrows]

On Tue, Apr 29, 2003 at 08:05:48PM +0200, Andreas Metzler <[EMAIL PROTECTED]> 
was heard to say:
> David Starner <[EMAIL PROTECTED]> wrote:
> >> sid=unstable - you know that, don't you?
> 
> > We need someone to test unstable, don't we? We can not realistically
> > test our distribution if the only people running it are those with many
> > computers who put it on one they aren't really using. Please don't give
> > our testers crap for actually testing the system in real life
> > situations.
> 
> If somebody _needs_ his computer working 100% ("I've got an essay due
> in 24 hours...") and runs unstable on it imho some reminder that this
> might be a bad choice is *required*.

  I think it would be more useful to say that if you have an essay
due in 24 hours, doing an upgrade may not be a good idea :)

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|"You keep on using that word.  I do not think|
| it means what you think it means."  |
|  -- "The Princess Bride"|
\-- A duck! -- http://www.python.org -/

Re: FVWM 2.5.x debs

[Alexander Kotelnikov]

> On Tue, 29 Apr 2003 20:57:54 +0200
> "Md" == Marco d'Itri <[EMAIL PROTECTED]> wrote:
Md> 
Md> On Apr 29, Alexander Kotelnikov <[EMAIL PROTECTED]> wrote:
>> Actually, I would like to close #189664 without uploading any fvwm2.5
>> packages to unstable, if no one  objects.
Md> I object, as the problem (fvwm not working with gnome2) still exists.
Md> The open bug will help other users to find the solution.

The first trouble we will face on this way is blockage of new 2.4
packages to be accepted to testing without any good reason. Possible
solution is to lower severity from grave to wishlist :).

-- 
Alexander Kotelnikov
Saint-Petersburg, Russia

Re: libstdc++... Help please

[Jose Carlos Garcia Sogo]

On Tue, Apr 29, 2003 at 08:05:48PM +0200, Andreas Metzler wrote:
> David Starner <[EMAIL PROTECTED]> wrote:
> >> sid=unstable - you know that, don't you?
> 
> > We need someone to test unstable, don't we? We can not realistically
> > test our distribution if the only people running it are those with many
> > computers who put it on one they aren't really using. Please don't give
> > our testers crap for actually testing the system in real life
> > situations.
> 
> If somebody _needs_ his computer working 100% ("I've got an essay due
> in 24 hours...") and runs unstable on it imho some reminder that this
> might be a bad choice is *required*.
>  cu andreas
> PS: And please don't forget the fact that I did provide a solution for
> the original problem.

  Not only using unstable, but upgrading it so short time before.

  But this also shows that unstable works quite well. If unstable were
  brokening or broken everyday, people won't upgrade it so often and
  carelessly.

-- 
  Jose Carlos Garcia Sogo
 [EMAIL PROTECTED]


pgpian2kHQoS8.pgp
Description: PGP signature

Re: i386 compatibility & libstdc++

[Arnd Bergmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tuesday 29 April 2003 21:22, Martin v. Löwis wrote:

> That won't help anything. "Compiling without threads" isn't really
> supported on Linux: if threads are not used, this is always a
> link-time/runtime issue, not a compile time issue.

Right, forget what I said about that.

> > Also, if an application or library cares about this sort of
> > micro-optimization, it probably should be provided in an optimized
> > version anyway.
>
> I think the performance loss for applications like KDE will be
> significant. I doubt that providing two versions of KDE (i386
> and i486+) would be feasible.

It would surely be nice to see performance numbers from actual
applications. After all, the applications are normally doing
some things besides low level atomic operations.

When the i386 and the i486 libraries are compatible, we can
decide what to do with each package case-by-case with
these options:

1. not performance critical but important (e.g. apt)
2. won't work on i386 anyway and therefore can be built 
   for i486 (e.g. mozilla or kde)
3. might be used on i386 but is performance critical and
   should be provided for i386 as well as i[56]86 (e.g. libqt3)

Since category 3. will be very small (I could not come up with 
any example besides libqt3 and even that is debatable), 
this should solve the problem.

Nevertheless, I think it would be best to also start a full 
Debian/i686 port which will be 100% compatible with Debian on i386 
except that it only runs on PentiumPro compatible machines,
i.e. Pentium 2/3/4/M, Xeon, Celeron, Athlon, Duron and Opteron 
but not Pentium, K5, K6 and most VIA/cyrix chips.

Arnd <><
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+rvna5t5GS2LDRf4RAirIAJ9ei78r+TXOzdQlQfL4dk5MoWmoTACfZ+Yh
a1SZdcTVT273JvuzYi7LQS8=
=TIk2
-END PGP SIGNATURE-

Re: aag - wrapper for apt-get with support for recommend and suggests field

[Adam Heath]

On Tue, 29 Apr 2003, Daniel Burrows wrote:

> On Tue, Apr 29, 2003 at 03:58:34PM +0200, Alexander Wirt <[EMAIL PROTECTED]> 
> was heard to say:
> > Its interactive, I don't want to launch a GUI if I want so simple add a
> > package. Additionally it seams that aptitude is currently broken in Sid.
> > So this are two good reasons for me.
>
>   apt is broken in sid now too.  Isn't unstable fun? :)

Broken how?  0.5.5 is sitting in NEW still.

Re: aag - wrapper for apt-get with support for recommend and suggests field

[Michael Banck]

On Tue, Apr 29, 2003 at 05:23:52PM -0400, Daniel Burrows wrote:
> On Tue, Apr 29, 2003 at 03:58:34PM +0200, Alexander Wirt <[EMAIL PROTECTED]> 
> was heard to say:
> > Its interactive, I don't want to launch a GUI if I want so simple add a
> > package. Additionally it seams that aptitude is currently broken in Sid.
> > So this are two good reasons for me.
> 
>   apt is broken in sid now too.  Isn't unstable fun? :)

How that?

> Working on my epic play "Waiting for doogie" [0],
>   Daniel
> 
>   [0] or this week, "Waiting for the ftpmasters"

ftpmasters don't let apt into unstable because of the libstdc++
breakage. A wise move IMHO.

Michael

Re: Backporting a package from unstable to stable

[Andrew Pollock]

On Tue, Apr 29, 2003 at 10:41:13PM +0900, Junichi Uekawa wrote:
> 
> To answer the question, the answer is 'no, not always'.
> 
> You need some try-and-error, and usually backporting one package
> requires backporting of another. However, many people do it due to 
> their needs.
> 
> The biggest stumbling block is probably debhelper; if you could ignore
> that, things would be pretty straightforward (in most cases).

This is what I've discovered. I took the Snort (2.0.0-2)  source package,
modified the build dependencies to match the appropriate package versions
that were in stable, and build a new source package and then ran pbuilder
over it.

It built fine, but when I installed it, all the debconf dialog boxes came 
up without any messages.

Andrew

Re: aag - wrapper for apt-get with support for recommend and suggests field

[EspeonEefi]

Daniel Burrows wrote:
 apt is broken in sid now too.  Isn't unstable fun? :)
 

Did you get this from the line in the topic of #debian @ 
irc.freenode.net? I jumped as well at first, but the apt that's MIA is 
the bot in that channel, not the program in sid, I think.

Re: Announcing Debian Package Tags

[Colin Walters]

On Tue, 2003-04-29 at 14:32, Manoj Srivastava wrote:
> On Tue, 29 Apr 2003 12:24:19 -0400, David Roundy <[EMAIL PROTECTED]> said: 

>   To be precise, you said "Maybe novices should only be shown
>  gui programs after all". Not that novices should be allowed to decide
>  to only view gui programs IF THEY WISH, as you said later. The first
>  message impled that some one other than novices decides what to show
>  them, then you toned it down to being a choice of the end user, which
>  is acceptable.

Manoj, the topic here is tuning Debian for different audiences.  Believe
it or not there are a huge number of people in the world for whom if you
said "terminal application" or "gui" they just stare at you blankly.  In
fact they comprise the vast majority of people in the world.  For most
of these people, most console applications are just not usable.

So having a version of Debian (or more precisely a Debian-based OS)
which doesn't list console applications by default is entirely
reasonable.  Maybe you wouldn't use it.  That's great.  That's your
choice.  But there are people who would.

I'm not advocating Debian proper itself do this, so if that's what your
concerned about, rest assured, it will not happen.

Re: Request for Clue: i18n of fortune-esque things

[Alexander Schmehl]

* Andreas Tille <[EMAIL PROTECTED]> [030423 23:38]:

> I just had the idea of translating these hints myself and thus I talked
> with Grisu about using the DDTP server for this purpose.  He promised
> to think about this ...

Well, did I missed something, hasn't anybody translated them, yet? I
was a little bit curious, so after I translated the Hints to german
(just 14 Hints), I created my very first own Package!
You can see it at:

deb http://www.schmehl.info/linux/debian/ ./
deb-src http://www.schmehl.info/linux/debian/ ./

I called it fortunes-debian-hints-de.

cu
Alex

PS: So, and now I think it is time to read docu, how to get my package
into debian...


pgpkxB6TMRYFm.pgp
Description: PGP signature

Re: Backporting a package from unstable to stable

[James D Strandboge]

On Tue, 2003-04-29 at 19:09, Andrew Pollock wrote:
> On Tue, Apr 29, 2003 at 10:41:13PM +0900, Junichi Uekawa wrote:
> > 
> > To answer the question, the answer is 'no, not always'.
> > 
> > You need some try-and-error, and usually backporting one package
> > requires backporting of another. However, many people do it due to 
> > their needs.
> > 
> > The biggest stumbling block is probably debhelper; if you could ignore
> > that, things would be pretty straightforward (in most cases).
> 
> This is what I've discovered. I took the Snort (2.0.0-2)  source package,
> modified the build dependencies to match the appropriate package versions
> that were in stable, and build a new source package and then ran pbuilder
> over it.
> 
> It built fine, but when I installed it, all the debconf dialog boxes came 
> up without any messages.

If you are going to backport packages from sid, you will most likely
need to backport debhelper, debconf, automake*, et al so that the
package will build properly (though it may *compile* correctly).

If it seems scary to use your production system to backport packages, I
found chroot a very valuable tool:

http://www.debian.org/doc/manuals/reference/ch-tips.en.html#s-chroot

Jamie Strandboge (gnome 2.2 woody backport maintainer)

-- 
Email:[EMAIL PROTECTED]
GPG/PGP ID:   26384A3A
Fingerprint:  D9FF DF4A 2D46 A353 A289  E8F5 AA75 DCBE 2638 4A3A

Re: Bug#148421: kopete =?utf-8?q?0=2E6=2E1a

[Sean 'Shaleh' Perry]

On Tuesday 29 April 2003 09:59, Michael Meskes wrote:
> Package: wnpp
> Version: unavailable; reported 2003-04-29
> Followup-For: Bug #148421
>
> Since this ITP is almost a year old and there is a package available
> under http://kopete.creativa.cl/debian/sid/ and the packages applies for
> NM and I am willing to sponsor him, I hope no one opposes us to go ahead
> and upload kopete 0.6.1a or a newer version (if available once we
> finished the package).
>
> There are some packaging thing left to be done, but the binary provided
> at this URL already works. Just enter
>
> deb http://kopete.creativa.cl/debian/sid/ ./
>
> to sources.list to test.
>

I have also talked to the person behind these packages.  I had promised to 
sponsor an upload and was waiting on the new KDE.  However my time has now 
become quite limited.  He is responsive and capable judging from my dealings.

Re: debian.org machine with pbuilder/debootstrap?

[Neil Roeth]

On Apr 28, Martin Schulze ([EMAIL PROTECTED]) wrote:
 > Hamish Moffatt wrote:
 > > Many have chroots but don't tend to have the relevant build-deps
 > > installed.
 > You can always send a mail into the direction of
 > [EMAIL PROTECTED] and ask for the packages which are missing.
 > You don't have to, but it's a common way to get things installed.
   ^
What's the alternative?

-- 
Neil Roeth

Re: Announcing Debian Package Tags

[Neil Roeth]

How about "obsolete" and "deprecated" tags?  This information is not currently
captured for packages anywhere, so it is hard to tell if packages are
obsolete, or if there is a transition going on from an older one to a newer
one.

-- 
Neil Roeth

Dropping/splitting (proper) i386 support

[Neil Roeth]

Nice summary.  Comments below.

On Apr 27, Nathanael Nerode ([EMAIL PROTECTED]) wrote:
 > This is an attempt to summarize some points.
[snip]
 > 3. How much impact will this have on users?
 > * Two people have reported live 386 systems (not clear if they're using 
 > Debian):
 > 4. Conclusion.
 > The i386 support is marginal, there are very few users of it, and it's 
 > significantly impeding the rest of the distribution.
 > 
 > There are several ways to deal with this.
[snip]
 > * Drop i386 support entirely; 'i386' architecture becomes 'i486'.
 > The most dramatic option. 

Is it really that dramatic?  Suppose we drop the 386 in sarge; people can run
woody on their 386s forever.  Just because Debian releases a new version
doesn't mean there are only two options: (1) ensuring Debian supports the 386,
or (2) forcing every 386 owner to run out and replace hardware so they can run
the new version.

I realize there are some people using a 386 who would need security updates,
so their choice in this case would be to backport the fixes themselves, or buy
a brand spanking new 486.  Oh, well, no surprise that administering a secure
machine is not free, as in beer.

 > * Drop i386 support mostly.  'i386' architecture becomes 'i486'.
 > Start a 'Debian-real-i386' subproject, with a 'real-i386' architecture,
 > but don't require that any packages build on it in order to go into 
 > testing or to release Debian; it would be a bonus architecture, with
 > a limited number of packages avaiable.
 > 
 > This seems to be the most immediately feasible option.  Several people 
 > have already indicated their approval of this idea.  I wouldn't wait for 
 > sarge to release, but do it ASAP. (Since C++ is already semi-broken on 
 > 386s, this would likely make things better for i386 in fact; at least 
 > it would have a specific functioning project.)
 > 
 > This is assuming someone with a real i386 is willing to lead a
 > 'Debian-real-i386' project (which wouldn't be a huge amount of work,
 > really; upstream support is usually pretty good, you don't have to actually
 > compile packages on your slow 386, just test them there, and you don't have
 > to worry about ABI compatibility with anyone much).  If nobody is willing
 > then I'd say there just isn't enough support and 386 should be dropped
 > outright.

I am in favor of dropping the 386 altogether, but this is acceptable as an
alternative.  If people would rather work on keeping 386 software up to date
than just run woody forever, more power to them.  It doesn't seem like it
would cost much on anyone else's part to enable this.

-- 
Neil Roeth

专业主机+24小时服务，“五一”空间促销！

[盈通网络]

尊敬的新老用户：

您好，首先感谢您对我们的关注，同时也对冒昧打扰表示歉意！

　　为了更好的服务于广大新老客户，我司特对所推出的虚拟主机类型进行调整!
欢迎点击：http://www.88dns.com  了解我司最新动态！

 1、200M（纯HTML空间）+ 送一国际域名，仅售150元/年
 2、50M空间+50M企业邮局 + 支持ASP，CGI + 送一国际域名，仅售248元/年
 3、200MP空间+200M企业邮局 + 支持ASP，CGI，ACCESS + 送一国际域名，仅售330元/年 
 4、400MP空间+200M企业邮局 + 支持ASP，CGI，ACCESS + 送一国际域名，仅售600元/年
   
更多空间组合，更多选择--请点击我司网站 　http://www.88dns.com/　了解详情;.

“高速、稳定、安全、24小时专业售后服务”是全体盈通人的服务宗旨，我们郑重承诺：
 1、盈通主机全部采用最新原装Dell PowerApp互联网应用服务器；
 2、光纤直接接入，主机独享 100M 带宽，同时托管于网通与电信；
 2、盈通主机全部安装正版Turbolinux或Microsoft操作系统；
 3、采用世界标准的SNMP进行24x7x365 系统监测；
 4、盈通主机客户一个月内可无条件全额退款；其它按实际余额退款。

联系E-mail:[EMAIL PROTECTED] 　QQ：40327558　

电话：0592-5557492　/ 8667174  传真： 0592--5580200  郑先生联系

*此邮件为商业信函，如果给你造成不便请原谅，如果你不希望再收到此信函请到:[EMAIL
 PROTECTED] 
退订，我们将会把您的邮箱地址过滤出列表。谢谢！ 
   This mail is a business letter .If you are uninterested in this ,please 
delete it ;If you do 
not hope to receive this mail again ,please go to [EMAIL PROTECTED] ,fill ni 
your mail 
address ,and we will filter it out of our mail list! 
   Thank your!  
**

Re: aag - wrapper for apt-get with support for recommend and suggests field

[Daniel Burrows]

On Wed, Apr 30, 2003 at 12:59:17AM +0200, Michael Banck <[EMAIL PROTECTED]> was 
heard to say:
> On Tue, Apr 29, 2003 at 05:23:52PM -0400, Daniel Burrows wrote:
> > On Tue, Apr 29, 2003 at 03:58:34PM +0200, Alexander Wirt <[EMAIL 
> > PROTECTED]> was heard to say:
> > > Its interactive, I don't want to launch a GUI if I want so simple add a
> > > package. Additionally it seams that aptitude is currently broken in Sid.
> > > So this are two good reasons for me.
> > 
> >   apt is broken in sid now too.  Isn't unstable fun? :)
> 
> How that?

On Tue, Apr 29, 2003 at 06:14:47PM -0500, Adam Heath <[EMAIL PROTECTED]> was 
heard to say:
> Broken how?  0.5.5 is sitting in NEW still.

On Tue, Apr 29, 2003 at 06:35:28PM -0500, EspeonEefi <[EMAIL PROTECTED]> was 
heard to say:
> Did you get this from the line in the topic of #debian @ 
> irc.freenode.net? I jumped as well at first, but the apt that's MIA is 
> the bot in that channel, not the program in sid, I think.

  Try running apt in an up-to-date unstable.  (this isn't apt's fault,
of course)

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|   "Anyway, running out of stack is similar to running out   |
|of tape on a turing machine.  Maybe we should signal |
|SIGCANNOLONGERPRETENDTOBEUNIVERSALTURINGMACHINE."|
| -- Matthew Danish   |
\- The Turtle Moves! -- http://www.lspace.org /