请 debian-devel 注意！

[吴 文婷]

第一批用户的文件已经发出，请注意查收。
请未收到文件的朋友重新向新信箱发EMAIL索取。

香港，台湾，大陆明星走光照片73张。

索取方法：
1 登陆http://zzwcashloo.yeah.net 免费注册成为用户。
2 进入注册信箱接收通知信并激活帐号。
3 [EMAIL PROTECTED]

我确认之后即将您需要的文件发往您的EMAIL。
文件大小为为3.17MB，请确定您的信箱有足够大的空间。

Re: ARM toolchains (was: Familiar packages)

[Matthias Klose]

Matt Zimmerman writes:
> On Wed, Apr 09, 2003 at 01:40:38PM +0100, Wookey wrote:
> 
> > This will effectively update and move the emdebian packages to be available
> > was part of Debian proper where they are a lot more useful. I'll be posting
> > the patch and compile option sets to debian-embedded and debian-arm for
> > discussion. Anyone else who wants to be cc:ed speak up now. (CC: me I'm not
> > on this list)
> 
> Please send a note to debian-handheld@lists.debian.org as well.

you may want to look at the gcc-3.3 package, from which you can build
cross compiler packages as well. The support was updated by Bastian
Blank, but has not been tested yet.

Matthias

Bom dia debian-devel

[Alexandre Venturini]

Title: Veja só a promoção que preparei para você:








Veja só a promoção que preparei para você:

 

Fragrâncias Famosas, tais como

 

Angel

Gabriela Sabatini

Dolce & Gabbana

Azzaro

Polo

Armani, entre outros

 

Fator5 - Contratipos Importados

 

Apenas R$31,00 (trinta e
um reias) FRETE
GRÁTIS

 

Visite: http://igspot.ig.com.br/fator5contratipos

ICQ
178481806

 

PEDIDOS: [EMAIL PROTECTED]

 

 

ATENÇÃO:

 Seu e-mail foi extraído de mensagens
encaminhadas á minha caixa postal, por internautas cuja o relacionamento temos em comum, e não de listas
cadastrais comercializadas. No entanto, se o recebimento deste lhe causa
transtorno, e deseja não receber mais mensagens, favor responder este email com o título REMOVER.

 

 

 

 

Re: /run and read-only /etc

[Thomas Hood]

On Wed, 2003-04-09 at 20:22, Jeremy Jackson wrote:
> Clearly what is needed here is an API for resolver updates
> [...]

What you describe is roughly what I wrote up in my last TODO
message.

> In Debian, there should possibly be a policy decided upon.
> (what the dir is, what API is, etc)

I don't immediately see why the resolver management scheme
has to be written up in policy.  It concerns only a small
set of packages.  The APM subsystem uses a similar scheme
(/etc/apm/apmd_proxy, /etc/apm/event.d, etc.) but is nowhere
mentioned in policy.

Eventually, however, there will have to be policy that
forbids routinely writing to files in /etc/.

And there will have to be a FHS change to allow for /run/.

-- 
Thomas Hood <[EMAIL PROTECTED]>

Re: >2000 packages still waiting to enter testing, > 1500 over age

[Nick Phillips]

On Wed, Apr 09, 2003 at 03:10:46PM +0200, Petter Reinholdtsen wrote:
> [Michael Banck]
> > I object. Not entering testing could very well happen if the
> > package's dependencies are broken/buggy/uninstallable.
> 
> Yes, there are many reasons for a package to get stuck in unstable.
> 
> But I believe it is the maintainers responsibility to make sure his
> packages do enter testing, and if he fail to do so for _300_ days, the
> package is not well maintained and can probably be removed.

BS. There are plenty of packages which *should never* get into testing (as
they will never, by our definition, be stable).

That, of course, raises another question...


Cheers,


Nick

-- 
Nick Phillips -- [EMAIL PROTECTED]
It's all in the mind, ya know.

Question of casts, lvalues, and & operator

[Marc Singer]

I've found that G++ 3.2 has a problem optimizing this code.

#include 

int func_b (void** ppv)
{
  *ppv = (void*) 2;
  return 0;
}


char* test (void)
{
  char* pa = NULL;
  func_b (&(void*)pa);
  return pa;
}


int main (int, char**)
{
  char* p = NULL;
  p = test ();
  printf ("%p\n", p);

  return 0;
}


When compiling with -O0, everything is OK.  -Os, on the other hand,
will optimize the return and always yield NULL.

I sent a preprocessed version of the errant file to gcc-bugs and was
told that my syntax is faulty and that the compiler will issue
warnings.

Here's his comment:

 (Your code should get a warning, or perhaps even a hard error -
  you're applying the & operator to a cast to non-reference type, which
  is not an lvalue, so it's invalid.)

Yet, -Wall does not make the compiler complain.  

He says that the line ought to be

  f ((void**)&p);

which does generate correct code.  Still, it seems to me that either
the compiler ought to warn or error, *or* the original code ought to
work.  

So, is this simply an example of the compiler failing to warn?

Re: Question of casts, lvalues, and & operator

[Anthony Towns]

On Wed, Apr 09, 2003 at 11:57:37PM -0700, Marc Singer wrote:
>   func_b (&(void*)pa);

> So, is this simply an example of the compiler failing to warn?

Yes. When you cast something, the compiler can do many things: covert the
value and put it in a register (in which case you can't take the address
of it), convert the value and put it somewhere more convenient in memory
(in which case you can, but if you write to it, it'll be lost), or just
use the existing location if no conversion is strictly required.

You should be getting an error like:

  test.c:13: invalid lvalue in unary `&'

(which is what I get when I build with gcc-3.2, not g++-3.2). Unless of
course this is another little divergence of C++.

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!''

fakeroot with chroot.

[Piotr Roszatycki]

http://people.debian.org/~dexter/fakeroot/

This is very dirty hack, but it works. I mean you can use debootstrap on
your user account without root privileges.

An example session from my system:

[EMAIL PROTECTED]:~$ fakeroot
[EMAIL PROTECTED]:~# export 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin
[EMAIL PROTECTED]:~# /usr/sbin/chroot /tmp/fakeroot /bin/bash
[EMAIL PROTECTED]:/tmp/fakeroot# cd /
[EMAIL PROTECTED]:/# id
uid=0(root) gid=0(root) groups=1001(dexter)
[EMAIL PROTECTED]:/# apt-get install libfreetype6-dev
Reading Package Lists...
Building Dependency Tree...
The following extra packages will be installed:
  libfreetype6
2 packages upgraded, 0 newly installed, 0 to remove and 3  not upgraded.
Need to get 943kB of archives. After unpacking 28.7kB will be used.
Do you want to continue? [Y/n]
(Reading database ... 20462 files and directories currently installed.)
Preparing to replace libfreetype6-dev 2.1.3+2.1.4rc2-5 (using 
.../libfreetype6-dev_2.1.4-1_i386.deb) ...
Unpacking replacement libfreetype6-dev ...
Preparing to replace libfreetype6 2.1.3+2.1.4rc2-5 (using 
.../libfreetype6_2.1.4-1_i386.deb) ...
Unpacking replacement libfreetype6 ...
Setting up libfreetype6 (2.1.4-1) ...

Warning: Fake ldconfig called, doing nothing

Setting up libfreetype6-dev (2.1.4-1) ...
[EMAIL PROTECTED]:/# exit
[EMAIL PROTECTED]:~# exit
[EMAIL PROTECTED]:~$


Have a good fun!

-- 
Piotr Roszatycki, Netia Telekom S.A..''`.
mailto:[EMAIL PROTECTED]   : :' :
mailto:[EMAIL PROTECTED]   `. `'
 `-

Re: >2000 packages still waiting to enter testing, > 1500 over age

[Sven Luther]

On Wed, Apr 09, 2003 at 09:10:30PM +0100, Colin Watson wrote:
> On Wed, Apr 09, 2003 at 08:30:42PM +0200, Sven Luther wrote:
> > Ideally the testing script should be modified to output more verbose
> > data, but i don't speak perl. 
> 
> That's no excuse, since it's (nowadays) written in Python. :)

Well, i don't speak python either, just didn't remember the exact
language that was used, sorry if i have wronged someone.

Friendly,

Sven Luther

Re: >2000 packages still waiting to enter testing, > 1500 over age

[Sven Luther]

On Wed, Apr 09, 2003 at 11:05:52PM +0200, Michael Banck wrote:
> On Wed, Apr 09, 2003 at 08:30:42PM +0200, Sven Luther wrote:
> > On Wed, Apr 09, 2003 at 05:59:26PM +0200, Michael Banck wrote:
> > > On Wed, Apr 09, 2003 at 04:40:31PM +0200, Sven Luther wrote:
> > > > depth, i cannot help all that much about it, and libvorbis is a valid
> > > > candidate, but his installation would break 107 or so packages in
> > > > testing, and i have not really the intention to check by hand all those
> > > > 107 packages. I believe it is just some packages that need to be rebuilt
> > > > due to the libvorbis0a thingy, not sure though. I already checked the
> > > > primary dependencies of all our packages (around 40) by hand, which
> > > 
> > > apt-cache showpkg libvorbis0 prints out just a couple of packages. Is
> > 
> > You have to look at the update_output.txt file, it shows :
>  
> > * alpha: adonthell, alsaplayer, alsaplayer-alsa, alsaplayer-common,
> [...]
> 
> But these are also packages wich depend implicitely on libvorbis0,
> right?

I suppose so, not sure though, as i have not checked in detail.

> For example:
> blackbird:~/tum/tum/ac1/report$ apt-cache show race | grep Depends
> Depends: race-data (>= 0.7.0-5), clanlib2 (>= 0.6.2-1), clanlib2-gl (>=
> 0.6.2-1), clanlib2-gui (>= 0.6.2-1), clanlib2-jpeg (>= 0.6.2-1),
> clanlib2-png (>= 0.6.2-1), clanlib2-sound (>= 0.6.2-1), clanlib2-vorbis
> (>= 0.6.2-1), libc6 (>= 2.2.5-13), libpng3, libstdc++2.10-glibc2.2 (>=
> 1:2.95.4-0.010810), xlibmesa3 | libgl1, zlib1g (>= 1:1.1.4)
> 
> clanlib2-vorbis probably depends on libvorbis0.

Yes, and clanlib2-vorbis doesn't exist in sid anymore, but only
libclan2-vorbis.

> I guess wo only have to rebuild first-level dependencies, or am I
> mistaken?

You would have to rebuild all first-level dependencies, yes, and hope
that those rebuilds don't introduce other bumped dependencies that have
problems with testing.

Friendly,

Sven Luther

Re: installing package twice only differing in debian version

[Andreas Metzler]

Jeremy Jackson <[EMAIL PROTECTED]> wrote:
> Is this supported?  Suppose the files between revs are named not to
> conflict.  It would be nice to be able to install a new version of a
> critical package, leaving the old one around while testing so you can
> fall back to it, then later remove the old one.  The kernel and
> postgresql come to mind.

No, dpkg does not supported this (and imho shouldn't, because
the added complexity is not worth the minimal gain. - How many
packages with differ only in the version number contain no commom
files?)
 cu andreas

Bug#188426: ITP: request-tracker3 -- Extensible Trouble Ticket System

[Andrew Stribblehill]

Package: wnpp
Version: unavailable; reported 2003-04-09
Severity: wishlist

* Package name: request-tracker3
  Version : 3.0.0
  Upstream Author : Jesse Vincent <[EMAIL PROTECTED]>
* URL : http://www.bestpractical.com/
* License : GPL v2
  Description : Extensible trouble-ticket tracking system

Request Tracker helps you handle and track problem reports. It features
web interfaces for queue administration and report submitting and sends
email with replies and comments to those reports.


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux wompom 2.4.19-686 #1 Mon Nov 18 23:59:03 EST 2002 i686
Locale: LANG=C, LC_CTYPE=C


-- 
Andrew Stribblehill <[EMAIL PROTECTED]>
Systems programmer, IT Service, University of Durham, England

Re: installing package twice only differing in debian version

[Colin Watson]

On Thu, Apr 10, 2003 at 10:13:58AM +0200, Andreas Metzler wrote:
> Jeremy Jackson <[EMAIL PROTECTED]> wrote:
> > Is this supported?  Suppose the files between revs are named not to
> > conflict.  It would be nice to be able to install a new version of a
> > critical package, leaving the old one around while testing so you can
> > fall back to it, then later remove the old one.  The kernel and
> > postgresql come to mind.
> 
> No, dpkg does not supported this (and imho shouldn't, because
> the added complexity is not worth the minimal gain. - How many
> packages with differ only in the version number contain no commom
> files?)

None, due to /usr/share/doc//copyright and changelog.Debian.gz.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Debian for x86-64 (AMD Opteron)

[Michael Banck]

[just replying to bring this to the attention of the dpkg-maintainers.
At least Wichert does not read -devel. I hope that's alright.]

On Thu, Apr 10, 2003 at 10:12:25AM +0900, GOTO Masanori wrote:
> At Wed, 9 Apr 2003 23:08:31 +0200,
> Michael Banck wrote:
> > > Note that the x86_64 is special: It would be relatively easy to bootstrap
> > > a port on the actual hardware, but doing it right requires changing _all_
> > > library packages as well as many other packages. The problem is that
> > > we want binaries to be compatible with i386 as well as with other x86_64
> > > distributions and that requires the installation of both 32 and 64 bit
> > > libraries at the same time.
> > 
> > FWIW, we can probably discuss how to do an x86-64 port in the right
> > way[tm] *NOW*, we don't need access the hardware for this.
> 
> I fully agree.
> 
> Moreover, this discussion is needed for architectures which can handle
> both 32bit and 64bit binaries for a long time.  Currently glibc has
> already sparc64 and s390x port, but we will have x86_64, in addition
> probably ppc64 and mips64 (I have been interested in this area
> especially for maintaining glibc package).
> 
> Currently only glibc and gcc has special handling for sparc64 and
> s390x.  Almost all libraries are not concerned, so most applications
> on sparc64 and s390x are worked under 32bit.  32 bit is sufficient for
> almost personal users, but it's not for commercial use and probably
> future personal use (for handling large DVD/blueray movie data or so).
> 
> I think generic 64bit libraries should put on {/lib64, /usr/lib64/,
> /usr/local/lib64, /usr/X11R6/lib64, ...}. Debian 64bit architecture
> packages should have only 64 bit libraries because it saves storage,
> and once we prepare 64bit port, we have no need to use 32bit
> binaries/libraries.  To use 32 bit old libraries, dpkg and apt may
> be needed to modify handling both 32 bit and 64 bit packages like:
> 
>   apt-get install libgtk2.0-0(32) libgtk2.0-0
>   dpkg -i libgtk2.0-0_ver_i386.deb libgtk2.0-0_ver_x8664.deb
> 
> Well the version number "ver" should be same in 32/64 bit version.
> The above issue is only for generic libraries, and I have not
> considered how to handle glibc/gcc package yet.
> 
> BTW, my concern about x86_64 issue is intel's 64bit extension (not
> ia64).  If they plan to release 64 bit version i386, and it's
> different architecture from x86_64 (so XEAX is not existed, for
> example), we should not think that x86_64 is only 64 bit version of
> i386 (and i386 packages are shared between x86_64 and intel's i386
> 64bit).

Re: SASL/LDAP/DB dependency hell.

[Andreas Metzler]

Daniel Schepler <[EMAIL PROTECTED]> wrote:
> Andreas Metzler <[EMAIL PROTECTED]> writes:
[...]
>> Actually it is much simpler, many packages are simply not compileable
>> anymore:
>> 
>> libldap2-dev depends on libsasl-dev [1]
>> libsasl-dev depends on libdb2-dev (>= 2.7.7.0-7) [2]
>> libdb3-dev conflicts with libdb2-dev
[...]
>> This hits almost anything linking against libldap2, including postfix
>> (db3), apache2 (db4.1), xemacs21(db3), sendmail (db3), KDE (db4.0),

> I'm going to prepare a new NMU in which libsasl-dev has that
> dependency changed to "libdb2-dev | libdb-dev", which should satisfy
> the libtool issue while still allowing libdb4.0-dev, etc.

Thanks for giving this a shot.

> Hopefully because of the versioned symbols in libdb2 this won't
> result in breakage.

Afaik it shouldn't, it had worked so far, there are many
packages using libdb!=2 together with sasl or ldap.

[...]
> Actually, though, it seems libdb4.0 and libdb4.1 don't have versioned
> symbols -- so if a program links against -lsasl and -ldb4.0 there's
> still a possibility of problems afaict.

Iirc versioned-symbols in db2 and db3 were introduced by the
respective debian maintainers, and db4 shipped them with upstream but
my memory might be wrong.
cu andreas

Re: Debian for x86-64 (AMD Opteron)

[Arnd Bergmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thursday 10 April 2003 03:24, Falk Hueffner wrote:

> On x86-64, things might be a bit different, though, because the 64 bit
> variant has more registers and therefore gcc might produce better code
> and binaries might run faster. If that is the case, 64 bit libraries
> and programs would generally be preferable. I don't know whether it is
> actually the case, though.

It would be preferrable to have full 64 bit userspace for the other
ports as well. I know that on s390x, many users want to have more than
2GB virtual addressing space and 64 bit only userspace is usually faster
than mixed 32/64 bit space because you don't have to map all libraries
twice. We are definitely working towards a native s390x port, 
probably other 64 bit ports aside from x86_64 and s390x are as well.

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

iD8DBQE+lTb55t5GS2LDRf4RAgTTAJ0c4KmX0R/qfPHcfKhTyO0Efc2T6gCgoS/3
8jW6qgGJbj+wuLqMhgMdNFY=
=YOU3
-END PGP SIGNATURE-

Re: >2000 packages still waiting to enter testing, > 1500 over age

[Josip Rodin]

On Wed, Apr 09, 2003 at 12:54:34PM +0200, Petter Reinholdtsen wrote:
> I suggest we remove packages which haven't entered testing after more
> more then 300 days.

Packages can be stuck out of testing due to their dependencies, so 300 days
of lag only indicates a serious problem with a package, it does not
automatically imply it. I suggest you spend time fixing stuff on a case by
case basis, rather than make sweeping generalizations :)

-- 
 2. That which causes joy or happiness.

Re: Debian for x86-64 (AMD Opteron)

[Arnd Bergmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thursday 10 April 2003 03:46, Philippe Troin wrote:
> > IMO, the right way is just like ia64 is doing. 64bit userspace with an
> > ia32 subarch installable. Best part about this is that you can use
> > almost everything ia64 is doing already. In fact, if dpkg could support
> > ia32 packages as a subarch for ia64 and x86_64, the packages could be
> > installable on both as-is.
>
> I definitely prefer everything 64-bit with optionally 32-bit rather
> than the other way around. Otherwise what's the point?

There is a difference between the two questions of where to install
libraries and whether to do a full native port. AFAIK, debian/ia64 
only has a very limited support for i386 packages because it requires
i386 libraries to be installed below /emul/ia32-linux/.

The existing x86_64 (and newer s390x, for that matter) distributions
take a different approach. Native 64 bit libraries are installed
in /lib64 and /usr/lib64 instead of /lib and /usr/lib. This makes it
possible to install all libraries in both variants at the same time.
Applications can obviously be installed only once, but that is what
is desired anyway. The scheme is consistant with LSB and is the only
one that provides full binary compatibility with Debian/i386 _and_
RPM packages from other distros.

We should definitely do a port of all packages to native 64 bit, but
in the process of doing so, we can use any i386 packages that are
not yet ported.

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

iD8DBQE+lTvJ5t5GS2LDRf4RAouzAKCMde7VX1HW/obqnxwOMInwNI8EJgCbB8E3
OlSqaArlFYX0q5GPQO2fo6g=
=iqhN
-END PGP SIGNATURE-

Re: Debian for x86-64 (AMD Opteron)

[Hamish Marson]

Philippe Troin wrote:
Ben Collins <[EMAIL PROTECTED]> writes:
 

On Wed, Apr 09, 2003 at 09:58:04PM +0200, Arnd Bergmann wrote:
   

Note that the x86_64 is special: It would be relatively easy to bootstrap
a port on the actual hardware, but doing it right requires changing _all_
library packages as well as many other packages. The problem is that
we want binaries to be compatible with i386 as well as with other x86_64
distributions and that requires the installation of both 32 and 64 bit
libraries at the same time.
 

IMO, the right way is just like ia64 is doing. 64bit userspace with an
ia32 subarch installable. Best part about this is that you can use
almost everything ia64 is doing already. In fact, if dpkg could support
ia32 packages as a subarch for ia64 and x86_64, the packages could be
installable on both as-is.
   

I definitely prefer everything 64-bit with optionally 32-bit rather
than the other way around. Otherwise what's the point?
Plus, as another poster wrote, 64-bit executable might end-up being
faster because of the extra 64-bit-only registers.
Phil.
 

Then again, it's more likely to end up SLOWER as loading 64 bit values 
from memory into registers is going to go at half the speed of loading 
32 bit values, just based on bus bandwidth alone. If the system you're 
supporting does BOTH 32 & 64 bit at the same time, then unless you need 
> 2GB access, 32bit is probably going to be the way to go.

I'm not sure how your logic works out that a 64 bit reg is going to be 
faster than a 32bit one. Or do you mean simply you're expecting a speedu 
because there are MORE 64 bit registers tahn 32 bit registers?

H
--
I don't suffer from Insanity... | Linux User #16396
I enjoy every minute of it...   |
|
http://www.travellingkiwi.com/  |

Bug#188434: ITP: fm -- FM is a Gtk+ file manager

[Rodrigo Tadeu Claro]

Package: wnpp
Version: 0.2.2; reported 2003-04-10
Severity: wishlist

* Package name: fm
  Version : 0.2.2
  Upstream Author : Geert Bevin <[EMAIL PROTECTED]>
* URL : http://thunderstorms.org/fm/downloads.html
* License : (GPL)
  Description : FM is a Gtk+ file manager. It aims to offer the best
  posssible ratio between, simplicity and resource usage.
  Currently all the effort have gone to the development of the browser.
  Much thought has been put into the creation of an efficient and
  easy-to-use interface. Several existing file managers on a variety of
  plataforms have benn used as an inspiration and lots of new and
  original features have been added.


-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux debian-rlinux 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i586
Locale: LANG=pt_BR, LC_CTYPE=pt_BR

Re: Debian for x86-64 (AMD Opteron)

[Ulrich Eckhardt]

On Thursday 10 April 2003 03:12, GOTO Masanori wrote:
> I think generic 64bit libraries should put on {/lib64, /usr/lib64/,
> /usr/local/lib64, /usr/X11R6/lib64, ...}. Debian 64bit architecture
> packages should have only 64 bit libraries because it saves storage,
> and once we prepare 64bit port, we have no need to use 32bit
> binaries/libraries.  To use 32 bit old libraries, dpkg and apt may
> be needed to modify handling both 32 bit and 64 bit packages like:
>
>   apt-get install libgtk2.0-0(32) libgtk2.0-0
>   dpkg -i libgtk2.0-0_ver_i386.deb libgtk2.0-0_ver_x8664.deb

Other alternative: only install and run 32bit apps in a chroot-style thingy, 
64bit stuff being the native type. Is that useful/possible ?


Uli

Re: Question of casts, lvalues, and & operator

[Ulrich Eckhardt]

On Thursday 10 April 2003 08:57, Marc Singer wrote:
> int func_b (void** ppv)
> {
>   *ppv = (void*) 2;
>   return 0;
> }
>
>
> char* test (void)
> {
>   char* pa = NULL;
>   func_b (&(void*)pa);

creates a pointer-to-void, copies the value of pa into it and then takes the 
address of that new object ...
Try '& reinterpret_cast(pa)' instead.

uli

Bug#188435: ITP: zodb3 -- A persistent system for Python objects

[Luca - De Whiskey's - De Vitis]

Package: wnpp
Version: unavailable; reported 2003-04-10
Severity: wishlist

* Package name: zodb3
  Version : 3.1
  Upstream Author : Zope Corporation
* URL : http://sourceforge.net/projects/zodb/
* License : http://www.zope.org/Resources/ZPL
  Description : A persistent system for Python objects

Actually this is an intent to split the ZODB from Zope package.
I'll probably provide more than a package, and perheps use the same
upstream for ZEO[1] (I'm still not sure)

[1] http://bugs.debian.org/186567

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux darkness 2.4.20 #1 Wed Mar 26 08:45:16 CET 2003 i686
Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set)


-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][-A-Za-z]*[iy]'?s$   | as fine or rude sentences have
Infinite loop: see `Loop, infinite'.| something in common: they
Loop, infinite: see `Infinite loop'.| don't depend on the language.

Re: SASL/LDAP/DB dependency hell.

[Daniel Schepler]

Andreas Metzler <[EMAIL PROTECTED]> writes:

> > Actually, though, it seems libdb4.0 and libdb4.1 don't have versioned
> > symbols -- so if a program links against -lsasl and -ldb4.0 there's
> > still a possibility of problems afaict.
> 
> Iirc versioned-symbols in db2 and db3 were introduced by the
> respective debian maintainers, and db4 shipped them with upstream but
> my memory might be wrong.

This was based on running objdump -p on the libdb libraries.  For db2
and db3 the output included entries like

Version definitions:
1 0x01 0x05477ab2 libdb2.so.2
2 0x00 0x4852 DB2

For db4.0 and db4.1 there was no such output.
-- 
Daniel Schepler  "Please don't disillusion me.  I
[EMAIL PROTECTED]haven't had breakfast yet."
 -- Orson Scott Card

Re: fakeroot with chroot.

[Matthias Urlichs]

Hi,
> http://people.debian.org/~dexter/fakeroot/
> 
> Have a good fun!
> 
Nice. Very nice. Will you put that into the official fakeroot?

Why do you comment out the mount calls in debootstrap?
Much nicer to just wrap the mount(2) syscall...

-- 
Matthias

Re: Debian for x86-64 (AMD Opteron)

[Cyrille Chepelov]

Le Thu, Apr 10, 2003, à 10:40:47AM +0100, Hamish Marson a écrit:

> I'm not sure how your logic works out that a 64 bit reg is going to be 
> faster than a 32bit one. Or do you mean simply you're expecting a speedu 
> because there are MORE 64 bit registers tahn 32 bit registers?

Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64 (IIRC,
long is 64 bit and of course any T* ). So yes, anything which plays with
pointers will be larger on x86-64, but it's not an automatic doubling in
size of everything. And mapping libraries twice also eats a good deal of
memory. OTOH, 16 general-purpose 8,16,32 or 64-bit registers (not even
counting a large SSE2 register file as well) should help gcc feel more at
home (especially with less code dedicated to handling register<->memory
swap-outs)

I don't have numbers to back either choice, but it looks to me that a mixed
userland with everything duplicated should be a last resort. And I'm sure
some people have numbers out these.

Assuming a pure x86-64 (no 32 bit support) can be bootstrapped with relative
ease, I guess it would be very interesting to see a couple benchmark (speed
and memory) numbers against running the exact same package selection but
from the i386 archive.  It looks to me that the /lib-vs-/lib64 scheme
should have enough room to let people make the right tradeoff between
running full 32-bit (but allegedly smaller in data sizes), full 64-bit (but
allegedly faster in code in some situations, and probably slightly larger in
data size) or a mixture (obviously mapping common libraries twice), using
their own workloads.

-- Cyrille

-- 

Bug#188437: ITP: zope-xmlmethods -- Set of methods to perform XML processing on Zope objects

[Luca - De Whiskey's - De Vitis]

Package: wnpp
Version: unavailable; reported 2003-04-10
Severity: wishlist

* Package name: zope-xmlmethods
  Version : 1.0.0
  Upstream Author : Ariel Partners LLC
* URL : http://zopexmlmethods.sourceforge.net
* License : BSD
  Description : Set of methods to perform XML processing on Zope objects

ZopeXMLMethods consists of a set of methods that can be applied to Zope
objects to perform various types of XML processing. In general each type
of method is applied to a Zope object in the same manner that a standard
DTML Method or Python Script might be applied. The only requirement for
the source Zope object is that it must somehow produce XML. Currently,
this XML must be in ASCII or UNICODE form, but in the future additional
formats such as DOM or SAX events will be supported. ZopeXMLMethods
includes a Cache Manager that is specialized to notice changes to the
XML source files and to store cached contents in files in the
filesystem, rather than the Zope object database.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux darkness 2.4.20 #1 Wed Mar 26 08:45:16 CET 2003 i686
Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set)


-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][-A-Za-z]*[iy]'?s$   | as fine or rude sentences have
Infinite loop: see `Loop, infinite'.| something in common: they
Loop, infinite: see `Infinite loop'.| don't depend on the language.

Re: Debian for x86-64 (AMD Opteron)

[Josselin Mouette]

Le jeu 10/04/2003 à 11:40, Hamish Marson a écrit :

> Then again, it's more likely to end up SLOWER as loading 64 bit values 
> from memory into registers is going to go at half the speed of loading 
> 32 bit values, just based on bus bandwidth alone. If the system you're 
> supporting does BOTH 32 & 64 bit at the same time, then unless you need 
>  > 2GB access, 32bit is probably going to be the way to go.

AIUI, this is true for e.g. sparc64, but not for x86_64. The opteron is
not just an i386 with 64 bit registers, but has new registers and new
optimizations which make it run faster with 64 bit executables than with
32 bit ones.

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


signature.asc
Description: PGP signature

Re: Bug#188434: ITP: fm -- FM is a Gtk+ file manager

[Andreas Metzler]

Rodrigo Tadeu Claro <[EMAIL PROTECTED]> wrote:
> Package: wnpp
> Version: 0.2.2; reported 2003-04-10
> Severity: wishlist

> * Package name: fm
>  Version : 0.2.2
>  Upstream Author : Geert Bevin <[EMAIL PROTECTED]>
> * URL : http://thunderstorms.org/fm/downloads.html
> * License : (GPL)
>  Description : FM is a Gtk+ file manager. It aims to offer the best
[...]

The package name shouldn't repeated in the short description.

I haven't got better suggestions but imho fm is a bad name for the
project (freshmeat-what?) and especially a bad name for the debian
package, it's too short (gtk-fm?).
   cu andreas

Computer Problem or Requirement ? Call us

[[EMAIL PROTECTED]]

Maximise your existing systems potential. Effective IT sys
 tems 
produce higher profits.  The IT Division are a specialist team of highly experienced IT professionals offering a fast efficient and cost effective service.  
 The wide range of specialist services we offer includes :-   CONSULTANCY The IT Division offers a full range of consultancy services to evaluate, plan and implement your I.T. strategies.    SUPPORTTroubleshooting and support services are vital in keeping your business "up and running".  The IT Division has over ten years' experience in resolving complex issues quickly and effectively for clients, from small businesses to multi-nation
 al 
corporates.   HARDWAREWe supply the best quality hardware from top manufacturers at the most competitive prices.PC's, laptops & servers (major brands & custom builds).Peripherals - printers, scanners, modems etc. – all upgrades & components supplied.    SOFTWARE We can offer you "out of the box" solutions at discount prices from top software houses.Installation & configuration services available.Our developers can also design bespoke applications to meet your specific needs and provide support and 
training. NETWORKS    Troubleshooting, design and installation services available for all your networking requirements.   INTERNET    Connectivity 
Web Hosting - Packages start from as little as £70 p.a. Web Page & Graphic DesignE-MarketingDomain Name Sales    SECURITY   Are you sure that your security is up to scratch ?  The IT Division can analyse your systems and networks for vulnerabilities, and work with you to minimise the risks.  The methods we use to protect your system include th
 e 
installation of firewalls and anti-virus software.    DATABASE Our development team specialise in database and bespoke software design and support. We can take a development project from beginning to end or just supply staff on an ad-hoc basis to get the job done.   CAD   Software and hardware sales and rentals.  We offer all Autodesk products at a discounted rate, contact us to discuss your requirements and obtain a quote.  We can also usually beat quotes from our competitors !     Our clients include from single PC sites to medium size businesses such as accountants, builders, engineering companies, estate agents, I.T. companies, medical practices, money market traders, recruitment agencies ..   and large corporates such as :-  Barclays InternationalComputacenterEDSJ.P. Morgan BankLiverpool VictoriaSiemensNational Mutual  Life Association of Australasia  For further information please contact us at –[EMAIL PROTECTED] You can find out more about us from our website at – www.itdivision.co.uk  REMOVE INSTRUCTIONS:  There is no need ro reply as this is a one off mailing which complies with The Electronic Commerce (EC Directive) Regulations 2002.  Your email address was advertised on the internet and if you have received this email in error we apologise for any inconvenience.

Re: Debian for x86-64 (AMD Opteron)

[Gerd Knorr]

Hamish Marson <[EMAIL PROTECTED]> writes:

> I'm not sure how your logic works out that a 64 bit reg is going to be
> faster than a 32bit one. Or do you mean simply you're expecting a
> speedu because there are MORE 64 bit registers tahn 32 bit registers?

IIRC x86-64 has 8 additional registers, which helps *alot* given the
very few registers ia32 has.

  Gerd

-- 
Gerd Knorr <[EMAIL PROTECTED]>

Re: Debian for x86-64 (AMD Opteron)

[Arnd Bergmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thursday 10 April 2003 12:16, Ulrich Eckhardt wrote:
> Other alternative: only install and run 32bit apps in a chroot-style
> thingy, 64bit stuff being the native type. Is that useful/possible ?

Possible -- sure, but not useful except as an option for the initial
bootstrap that might not fully work with /lib64.
I've followed both SuSE and Red Hat making that mistake with their early
s390x distributions. They both now have the problem that they changed
to /lib64 installations, which makes it really hard to create 64 bit
packages that work in the old _and_ new distributions. 

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

iD8DBQE+lVan5t5GS2LDRf4RAoqhAJsE5Xc2Vjsad4yNx5tZKgLnzTt0BwCfTWru
X2fM5E1MB0Oh8Zhh9LHJj9c=
=HKhC
-END PGP SIGNATURE-

Bug#188439: ITP: kernel-patch-bootsplash -- Kernel patch to display a graphical boot splash-screen

[Mike Hommey]

Package: wnpp
Version: unavailable; reported 2003-04-10
Severity: wishlist


* Package name: kernel-patch-bootsplash
  Version : 3.0.7
  Upstream Author : Stefan Reinauer <[EMAIL PROTECTED]>
* URL : http://www.bootsplash.org/
* License : GPL
  Description : Kernel patch to display a graphical boot splash-screen

 This patch adds a themeable boot splash screen to the Linux kernel.

 Two modes are available :
 - a silent mode, showing, for example a logo and a progress bar
 - a verbose mode, showing a picture on the background of the console 
 messages

 It needs 16-bits truecolor (i.e. without palette) support on 
 framebuffer. Themes need to be converted and attached to an initrd.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux vaio 2.4.20-pre7-mh1 #1 Sun Sep 22 18:57:57 CEST 2002 i686
Locale: LANG=en_US, LC_CTYPE=en_US

Bug#188440: ITP: splashutils -- Set of utilities to manage boot splash-screen

[Mike Hommey]

Package: wnpp
Version: unavailable; reported 2003-04-10
Severity: wishlist


* Package name: splashutils
  Version : no upstream versioning
  Upstream Author : Stefan Reinauer <[EMAIL PROTECTED]>
* URL : http://www.bootsplash.org/
* License : GPL
  Description : Set of utilities to manage boot splash-screen

 This set provides useful tools to manage the boot splash-screen.
 Needs a kernel patched with kernel-patch-bootsplash.

 splash is used to convert a theme to a format suitable to be attached 
 to an initrd for the kernel to load the theme, or to change the picture 
 displayed on the console while the system is running.

 fbresolution shows the current used resolution on framebuffer console.

 progress is used to draw a progress box on the framebuffer console.

I will also add scripts and READMEs to have a nice result on a Debian 
system.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux vaio 2.4.20-pre7-mh1 #1 Sun Sep 22 18:57:57 CEST 2002 i686
Locale: LANG=en_US, LC_CTYPE=en_US

Re: Debian for x86-64 (AMD Opteron)

[Colin Watson]

On Thu, Apr 10, 2003 at 12:39:25PM +0200, Cyrille Chepelov wrote:
> Le Thu, Apr 10, 2003, ? 10:40:47AM +0100, Hamish Marson a ?crit:
> > I'm not sure how your logic works out that a 64 bit reg is going to
> > be faster than a 32bit one. Or do you mean simply you're expecting a
> > speedu because there are MORE 64 bit registers tahn 32 bit
> > registers?
> 
> Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64
> (IIRC, long is 64 bit and of course any T* ). So yes, anything which
> plays with pointers will be larger on x86-64, but it's not an
> automatic doubling in size of everything. And mapping libraries twice
> also eats a good deal of memory. OTOH, 16 general-purpose 8,16,32 or
> 64-bit registers (not even counting a large SSE2 register file as
> well) should help gcc feel more at home (especially with less code
> dedicated to handling register<->memory swap-outs)
> 
> I don't have numbers to back either choice, but it looks to me that a
> mixed userland with everything duplicated should be a last resort. And
> I'm sure some people have numbers out these.

Based on the numbers I've seen, the factors mentioned seem to balance
each other out fairly well. I'm not (yet) allowed to talk about the
details though ...

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Debian for x86-64 (AMD Opteron)

[Colin Watson]

On Thu, Apr 10, 2003 at 12:43:38PM +0100, Colin Watson wrote:
> On Thu, Apr 10, 2003 at 12:39:25PM +0200, Cyrille Chepelov wrote:
> > Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64
> > (IIRC, long is 64 bit and of course any T* ). So yes, anything which
> > plays with pointers will be larger on x86-64, but it's not an
> > automatic doubling in size of everything. And mapping libraries twice
> > also eats a good deal of memory. OTOH, 16 general-purpose 8,16,32 or
> > 64-bit registers (not even counting a large SSE2 register file as
> > well) should help gcc feel more at home (especially with less code
> > dedicated to handling register<->memory swap-outs)
> > 
> > I don't have numbers to back either choice, but it looks to me that a
> > mixed userland with everything duplicated should be a last resort. And
> > I'm sure some people have numbers out these.
> 
> Based on the numbers I've seen, the factors mentioned seem to balance
> each other out fairly well. I'm not (yet) allowed to talk about the
> details though ...

(And what I mean by this is that the x86-64 seems to have bloody good
32-bit performance, not poor 64-bit performance. :))

-- 
Colin Watson  [EMAIL PROTECTED]

Re: fakeroot with chroot.

[Piotr Roszatycki]

On Thu, 10 Apr 2003, Matthias Urlichs wrote:
> > http://people.debian.org/~dexter/fakeroot/
> >
> > Have a good fun!
> >
> Nice. Very nice. Will you put that into the official fakeroot?

I really don't know. The fakeroot is not my project and I'm afraid my
patches are too experimental for such stable tool. Also there is too much
work with cleaning up the code. Should I start new project or join to the
original fakeroot?

> Why do you comment out the mount calls in debootstrap?
> Much nicer to just wrap the mount(2) syscall...

Should I just ignore mount/umount calls? I'm afraid this syscall is too
complicated to override in faked envrionmend.

I'd like to make "/proc" directory transparent for chroot-ed environment.
It would be possible to use pstools. Another idea?

-- 
Piotr Roszatycki, Netia Telekom S.A..''`.
mailto:[EMAIL PROTECTED]   : :' :
mailto:[EMAIL PROTECTED]   `. `'
 `-

Fakeroot to obsolete DESTDIR

[Wesley W. Terpstra]

After running into yet two more problems with staged installs ala DESTDIR,
I was reminded of an idea I originally had for fink packages.

... but, let's begin from the beginning.
Why is DESTDIR a problem?

---

1: libtool cannot relink inter-dependent libraries during a staged install.
2: some upstream packages don't provide any means for relocated installation
... probably others, but these are the two I ran into again today.

On the topic of 1, cvs libtool can do this with an undocumented command-line
flag. However, it still prefers the installed location over the staged
location. So, if you link to -L/.../debian/tmp/usr/lib -lfoo, a libfoo.so in
/usr/lib is prefered, which can cause subtle problems. 

Furthermore, libtool has been custom hacked in so many source packages, that
it is not feasible to simply replace ltmain.sh as we do for config.* in
autoconf. Thus, we are stuck with the old libtool + spinoffs for some time.

These problems in libtool can be solved by hacking the ltmain.sh or .la
files by hand, which afaik is what everyone does. This compounds the problem
above.

In regards to 2, if everyone used automake, this would not be a problem.
However, many projects do not use automake, and some of them are even
correct in this decision. So, sometimes we have no DESTDIR.

Often, people end up having to search through all the Makefiles injecting
DESTDIR in various locations, hopefully catching them all. This makes large
.diff files which are problematic to maintain.

Other times, the build system doesn't use Makefiles at all, but bash
scripts, jam, ant, perl or others. In each of these cases, a special
solution must be hand-crafted by the packager in a potentially error-prone
manner.

Now, I admit the above problems are not fatal given the amount of man-power
at debian's disposal. In fact, our current solution---hand hacking---does
work fairly well.

What I would like to propose is simply a way to reduce the effort by
allowing plain 'make install' to work without changing the build scripts.

---

As we all know, fakeroot intercepts stat/chown/chmod/etc. We do this so that
users can install files into a staged location and preserve the correct
permissions.

What I propose to do is to slightly extend fakeroot to also intercept
open/diropen. If the open call would create a file, redirect it to
/.../debian/tmp or some such location. If the call would open a file, first
check /.../debian/tmp and then /.

To illustrate this, lets take an example: (here libbar depends on libfoo)

make install
libtool install libfoo.la /usr/lib/libfoo.la
libtool install libbar.la /usr/lib/libbar.la

The first install relinks libfoo.la against /lib/libc.so.6.

So, fakeroot intercepts ld's open, checks for /.../debian/tmp/lib/libc.so.6
and doesn't find it. Then it tries /lib/libc.so.6 and finds it, so provides
this file handle.

Then fakeroot intercepts ld's output open for /usr/lib/libfoo.la, it
redirects this to /.../debian/tmp/usr/lib/libfoo.la. Hence, the library is
installed in the staging location transparently.

Next, libbar.la is installed.

fakeroot correctly prefers /.../debian/tmp/usr/lib/libfoo.la to
/usr/lib/libfoo.la in the case it was already installed. The output is also
staged.

So, here we have libtool working seamlessly because fakeroot redirected it.

... the beauty of this solution is that it is simple and common. This would
allow us to always install with the package's default install rule and have
magic look after all that nasty stuff.

The interface I propose is to add two new fakeroot options
--outputdir /.../debian/tmp
--searchdir /sw:/

If --outputdir is specified, then it is always prepended to the searchdir
option. When a new file is created, outputdir is the location really used.
When a file is opened, outputdir:searchdir is consulted.

On of the fringe benefits of this is that fink packages don't have to modify
the debian packages much; simply add /sw before / in the search path.

---

What I am looking for is comments about whether people think this is useful,
suggestions on how to make it as simple/easy-to-use as possible, and a list
of which libc functions needs to be trapped.

Presently, I think libfakeroot.so just needs to trap open/diropen and maybe
a few others, faked needs to keep track of the search/outputdir parameters,
and fakeroot has to pass the above options to faked. diropen requires some
extra work to merge the directory listings, but I think this is doable.

---
Wes

BJ系列全自动剪剥机、打端机

[wq]

Õã½­Ê¡ÁÙº£ÊÐÁúÌÚ»úе³§ÊÇÒ»¾Å¾Å°ËÄê³ÉÁ¢µÄÒ»¼ÒרҵÉú²úÈ«×Ô¶¯²ÃÏß°þƤ´ò¶Ë»ú¡¢È«×Ô¶¯²ÃÏß°þƤ»úµÄ³§¼Ò¡£²úÆ·Ö÷ÒªÓ¦Óõç×Ó¡¢µç
Æ÷ÐÐÒµ£¬Êǵç×Ó¡¢µçÆ÷ÐÐÒµÀíÏëµÄ°þÏßÉ豸¡£¸ù¾ÝÓû§µÄʹÓúͷ´Ó¦£¬ÎÒÃÇÔÚ¹¤ÒպͲúÆ·ÖÊÁ¿Éϲ»¶Ï¸Ä½ø£¬È¡µÃÁ˽ÏΪÂúÒâµÄÊг¡Ð§¹û
¡£ÓëÆäËûͬÀà²úÆ·±È½Ï£¬±¾³§Éú²úµÄ²úÆ·¾ßÓÐÕûÌåÉè¼ÆºÏÀí¡¢¹¦Ð§¸ß¡¢×Ô¶¯»¯³Ì¶È¸ß£¬²Ù×÷°²È«¡¢Î¬»¤ÈÝÒ×µÈÌص㡣½ÏÖ®ÒÔÆäËûͬÀà²ú
Æ·£¬ÎÒÃǵIJúÆ·¾ß±¸½Ï¸ßµÄÐÔÄܼ۸ñ±È¡£ÔÚ´ËÁìÓò£¬¾ß±¸Ò»¶¨µÄÏȽøÐÔ£¬Óû§Êг¡·´Ó³Á¼ºÃ¡£ÁíÍ⣬±¾³§³Ð½Ó¸÷Àà½ø¿Ú¡¢¹ú²úÈ«×Ô¶¯²Ã
Ïß°þƤ´ò¶Ë»ú¡¢È«×Ô¶¯²ÃÏß°þƤ»úµÄάÐÞ¡£±¾³§³ÉÁ¢ÖÁ½ñ£¬²úÆ·ÏúÊÛÈ«¹ú¸÷µØ£¬ÒÔÖÊÁ¿È¡ÐÅ¿Í»§¡¢ÒÔ¼Û¸ñ»Ø±¨¿Í»§£¬²¢ÒÔÖܵ½¿ì½ÝµÄ·þ
ÎñºÍÊÛÇ°ÊÛºóÈ«·½Î»µÄ¼¼ÊõÖ§³Ö£¡ÈÃÄúÂòµÃ˳ÐÄ£¬ÓõóÆÐÄ¡£Ï£Íû¸÷λÐÂÀÏ¿Í»§À´µçÀ´º¯Ç¢Ì¸ÒµÎñ¡£

 

 

 

²úÆ·½éÉÜ£º

 

²ú Æ· Ãû ³Æ: È«×Ô¶¯²ÃÏß°þƤ´ò¶Ë»ú

ÐÍ   ºÅ: BJϵÁÐ

ÍÑÏßÍ·³¤¶È: 1.0£­6.0 mm

ѹ Öø ËÙ ¶È: 40£­80¸ù/·ÖÖÓ

×î ´ó ËÍ ¾à: 120£­450 mm

ÊÊ Óà µç Ïß: 0.3-5.0 ƽ·½ºÁÃ×

×Ü  ÖØ   Á¿: 450KG

¼Û  ¸ñ(/̨): Ãæ̸(ÏÖ»õ)

 

 

 

²ú Æ· Ãû ³Æ: È«×Ô¶¯²ÃÏß°þƤ»ú

ÐÍ   ºÅ: BJϵÁÐ

×î´óÇи¶È:

BJ-45AÐÍ£º40£­450  mm

BJ-45BÐÍ£º40£­5800 mm

°þÍ·³ß´ç: 2-25mm

×î ´ó Ïß ¾¶: 0.8£­5.0 mm

ÖØ   Á¿: 350kg

¼Û  ¸ñ(/̨): Ãæ̸(ÏÖ»õ)

 

¹«Ë¾Ãû³Æ:Õã½­Ê¡ÁÙº£ÁúÌÚ»úе³§ 

Áª ϵ ÈË:ÍõÈçÁú  ³§³¤

µØÖ·:Õã½­Ê¡ÁÙº£ÊÐË®ÔÆÄÏ·

ÓÊÕþ±àÂë:317000 

µç»°(´«Õæ):0576-5281989

 

ZHEJIANG LINHAI LONG TENG MACHINERY FACTORY, founded on 1998, is specialized in 
making self-motion cord cutter & 
insulation barker & terminal fastening machine and self-motion cord insulation 
cutter & barker. The product is widely 
used in electrical and electronic industrial and is the most ideal cord 
insulation barker. Good market effect has been 
formed after our long term¡¯s energy on improving technics and quality of 
product according to user¡¯s requirement and 
feedback. Comparing to other same kind product, product of our factory has the 
better features in integrated 
designing, efficacy, self-motion, safe operation, easy maintenance and etc but 
lower price. In addition, we also 
engage in service of machines manufactured whether home or abroad. Products are 
now well sold nation-widely since we 
are founded. We always try our best to provide the best quality but most 
feasible price to users. Thoughtful and speed 
service and strong technical support are accompanied at any time. All old or 
new friends are welcomed to discuss 
business whether on technical service or machine.

 

PRODUCT INTRODUCTION:

 

PRODUCT: SELF-MOTION CORD CUTTER & INSULATION BARKER & TERMINAL FASTENING 
MACHINE

MODEL: BJ SERIES

LENGTH OF PEELED CORD END: 1.0£­6.0 mm

FASTENING SPEED: 40£­80PCS/MINUTE

MAXIMUM DELIVERING DISTANCE: 120£­450 mm

APPLICABLE SUPPLY CORD: 0.3-5.0 mm2

WEIGHT: 450KG

UNIT PRICE: INTERVIEW (MERCHANDISE ON HAND)

 

PRODUCT: SELF-MOTION CORD INSULATION CUTTER & BARKER

MODEL: BJ SERIES

MAXINUM CUTTING LENGTH:

MODEL BJ-45A: 40£­450  mm

MODEL BJ-45B: 40£­5800  mm

SIZE OF BARKER HEAD: 2-25mm

MAXIMUM DIAMETER OF CORD: 0.8-5.0mm

WEIGHT: 350KG

UNIT PRICE: INTERVIEW (MERCHANDISE ON HAND)

 

Company Name: ZHEJIANG LINHAI LONG TENG MACHINERY FACTORY

CONTACT: WANG LU LONG (FACTORY DIRECTOR)

ADDRESS: SOUTH SHUI YUN ROAD, LINHAI CITY, ZHEJIANG PROVINCE

POSTCODE: 317000

TEL(FAX): 0576-5281989

Re: Aptitude, ARs

[Enrico Zini]

[I'm Cc-ing deb-usability-list so that people interested in usability
can know what's been discussed in -devel about it.  I invite others to
do the same]

On Fri, Mar 28, 2003 at 12:06:45AM -0800, Osamu Aoki wrote:

> > I'm interested in helping in the menu issue, too; I've offered help some
> > months ago, but I didn't get many answers.  There are some different
> > problems there though, like coping with the existing Gnome and KDE menus.
> 
> As for your question on the later thread, I was thinking to "extract"
> data from gnome menu to assign some short key words to each packages.

Extracting tag data from Gnome and KDE menus is a good idea (and it's
the same algorithm I use to merge XBEL bookmark files with tagbk).

However, this would mean providing another, different menu tree.

One problem about these menu trees is that the support people wants them
to be standard, that is to be able to tell how to find an application to
those who seek help.

This means that if we go with a different menu system, we should take
care to make sure that both the paths already available in the Gnome and
KDE menus can be followed to reach an application, so that support
people (which is not limited to just Sun or IBM hotlines) can keep
giving the right directions also in Debian systems.

Even better could be to work with Gnome and KDE people: working at the
same thing, at minimum we want to know what the others are doing, and
hopefully we want to work together and share the most.

I just wrote to the Gnome usability list asking about what's going on in
that field; I have no contacts with the KDE guys, but I hope to have
some soon.


> > How do you plan to tune the thresholds, since this weighting is likely
> > to be strongly subjective?
> Popocon type data gathering is one way I can think of.  This time if any
> of us initiate similar efforts, we need to gather short report on each
> installed package in a standardized format.

Problem is, popcon results are biased: they are limited to machines with
an internet connection and an SMTP server available.  It's unlikely to
be installed in computer labs, kiosks or other systems focused to
providing service to people.  It's also unlikely to be installed on
production servers, were you don't want anything you don't really need.

It also treats all boxes as equal, regardless of the services they
should provide and of the kind of public that uses them.

I don't mean that it shouldn't be taken into account, only that extra
care should be used with the data it provides, and that it shouldn't be
the only source of data used to rate packages if a rating system is to
be put in place.


Bye,

Enrico

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


pgpUFV6jJnLhs.pgp
Description: PGP signature

Re: SASL/LDAP/DB dependency hell.

[Junichi Uekawa]

> > Iirc versioned-symbols in db2 and db3 were introduced by the
> > respective debian maintainers, and db4 shipped them with upstream but
> > my memory might be wrong.
> 
> This was based on running objdump -p on the libdb libraries.  For db2
> and db3 the output included entries like
> 
> Version definitions:
> 1 0x01 0x05477ab2 libdb2.so.2
> 2 0x00 0x4852 DB2
> 
> For db4.0 and db4.1 there was no such output.

You are looking at the wrong part.
They have really versioned their symbols, without
using the GNU ld feature which doesn't work on some platforms:

objdump -T gives me:

.
.
00018b94 gDF .text  005d  Base__db_db_h_nelem_4001
000679e0 gDF .text  01c9  Base__ham_chgpg_log_4001
00038438 gDF .text  010d  Base__db_master_open_4001
000187c0 gDF .text  005d  Base__db_db_bt_maxkey_4001
00067dc0 gDF .text  0135  Base__ham_init_print_4001
00055c3c gDF .text  0013  Base__db_ndbm_clearerr_4001
0001c784 gDF .text  0022  Base__dbcl_set_timeout_4001
0003c0ec gDF .text  0264  Base__db_big_getpgnos_4001
00045554 gDF .text  0050  Base__db_ccountchk_4001
0006a3b8 gDF .text  000b  Base__ham_test_4001
.
.

ITO: searching new maintainer for gworkspace package

[Paul Seelig]

Hi everybody,

here's your Debian package maintainer (still) for the gworkspace package
writing. I want to get rid of the gworkspace package and wanted to first
ask here before i move on to simply orphan the package via bug report.

I once wanted to see GNUstep supported by and within Debian via inclusion
of a user oriented application like GWorkspace and that's why i packaged it
for Debian in the first place. But, unfortunately, i don't rank myself
among the envisioned user population for such an application and that's why
i've actually never really used gworkspace or any GNUstep components other
than WMaker and WTerm. Actually, since ever i do prefer a terminal emulator
with the IMHO wonderful Midnight commander or simply a shell prompt. So i'm
quite a bad package and application tester for GWorkspace anyway. ;-)

Since two weeks or so, upstream has released GWorkspace 0.5 and an upload
of this package would be a great means for switching Debian maintainers.
Some aquaintance with GNUstep in general would be needed though. So now
here's the chance for interested parties to step forward and assume
maintainership.
 Thanks, P. *8^)

Re: Debian for x86-64 (AMD Opteron)

[Wichert Akkerman]

Previously Michael Banck wrote:
> [just replying to bring this to the attention of the dpkg-maintainers.
> At least Wichert does not read -devel. I hope that's alright.]

Sure.

On Thu, Apr 10, 2003 at 10:12:25AM +0900, GOTO Masanori wrote:
> I think generic 64bit libraries should put on {/lib64, /usr/lib64/,
> /usr/local/lib64, /usr/X11R6/lib64, ...}. Debian 64bit architecture
> packages should have only 64 bit libraries because it saves storage,
> and once we prepare 64bit port, we have no need to use 32bit
> binaries/libraries.  To use 32 bit old libraries, dpkg and apt may
> be needed to modify handling both 32 bit and 64 bit packages like:
> 
>   apt-get install libgtk2.0-0(32) libgtk2.0-0
>   dpkg -i libgtk2.0-0_ver_i386.deb libgtk2.0-0_ver_x8664.deb

I don't think that would work: you suddenly have two packages with
the exact same name and version, only with a different architecture.
This would mean that suddenly everywhere there would be an implicit
extra key in identifying a package: besides its name and version
the architecture would be important.

This would mean major changes to how things work:

* dpkg, apt and others would need to store the architecture for each
  package after installation
* all code that deals with package relations needs to be updated to
  check architectures
* dpkg would have to allow two different versions of the same package 
  to be installed

Since dependencies do not specify an architecture we could also run into
all sorts of problem when trying to resolve them.

So basically, I don't think this is a very good idea. However I think we
can solve it differently in a much simpler way:

* modify dpkg (already planned) to allow it to install packages from
  different architectures on a system where it makes sense
* change the naming of the libraries, for example by adding '64' to the
  64bit version of a library

That way you could do something like:

# echo x86-64 >> /etc/dpkg/legal-archs
# dpkg -i libgtk2-2.0-1_i386.deb
# dpkg -i lib64gtk2-2.0-1_x8664.deb

Wichert.

-- 
Wichert Akkerman <[EMAIL PROTECTED]>   http://www.wiggy.net/
A random hacker

Re: SASL/LDAP/DB dependency hell.

[Stephen Frost]

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> You are looking at the wrong part.

No, he isn't.

> They have really versioned their symbols, without

No, they havn't, they've done a nasty hack apparently, which is really
unfortunate.

> using the GNU ld feature which doesn't work on some platforms:

They're not a 'GNU ld feature', quit spreading misinformation.  They
originally appeared under Solaris and are supported by at least glibc
and Solaris and it sounds like they're either supported or going to be
under FreeBSD.

Stephen


pgpCriilP8xbg.pgp
Description: PGP signature

Re: SASL/LDAP/DB dependency hell.

[Junichi Uekawa]

Hi,

Pretty interesting mail to receive; an excercise in using negative
response, I assume.

> > You are looking at the wrong part.
> 
> No, he isn't.
> 
> > They have really versioned their symbols, without
> 
> No, they havn't, they've done a nasty hack apparently, which is really
> unfortunate.

I wouldn't consider them nasty hacks.
 
> > using the GNU ld feature which doesn't work on some platforms:
> 
> They're not a 'GNU ld feature', quit spreading misinformation.  They
> originally appeared under Solaris and are supported by at least glibc
> and Solaris and it sounds like they're either supported or going to be
> under FreeBSD.

Well, then, they are ld feature, not universally available.

I could not convince libpng maintainers to use versioned symbols because
they were apparently not available on AIX and Windows.


regards,
junichi

Re: SASL/LDAP/DB dependency hell. (was: Accepted cyrus-sasl 1.5.27-3.4 (i386 source))

[Stephen Frost]

* Andreas Metzler ([EMAIL PROTECTED]) wrote:
> Actually it is much simpler, many packages are simply not compileable
> anymore:
> 
> libldap2-dev depends on libsasl-dev [1]
> libsasl-dev depends on libdb2-dev (>= 2.7.7.0-7) [2]
> libdb3-dev conflicts with libdb2-dev
> 
> [1] introduced in response to #164791
> [2] introduced in response to #168993
> 
> libtool strikes again, quoting from the report
> | /usr/lib/libsasl.la contains -lpam as a dependency, so -lsasl can't be
> | linked using libtool without libpam0g-dev being installed.

Going back to this I realize I didn't look into this carefully enough.
libsasl-dev should not be depending on libdb2-dev, if it is then
something's fucked up, and it sounds like it's libtool.  I've heard
there is work being done to fix this obvious and blatent fuckage so
trying to come up with a way to support this is not necessary.

Stephen


pgpNwpsiW6ceS.pgp
Description: PGP signature

Re: SASL/LDAP/DB dependency hell.

[Stephen Frost]

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> I wouldn't consider them nasty hacks.

You'd be wrong.

> Well, then, they are ld feature, not universally available.

That's correct, amazingly enough.

> I could not convince libpng maintainers to use versioned symbols because
> they were apparently not available on AIX and Windows.

Then they're being fools.  As with a great deal of other things (which
is why we have things like automake/autoconf and company) versioned
symbols should be used on the platforms that support them and ugly hacks
where they're not supported.  The ugly hacks shouldn't be forced on
current systems due to the poor design of ancient and archaic systems.

Stephen


pgp2ZwNf30DPD.pgp
Description: PGP signature

Bug#188463: ITP: libxcb -- lightweight, low-latency replacement for Xlib

[Eric Dorland]

Package: wnpp
Version: unavailable; reported 2003-04-09
Severity: wishlist

* Package name: libxcb
  Version : CVS
  Upstream Authors: Bart Massey <[EMAIL PROTECTED]>, 
Jamey Sharp <[EMAIL PROTECTED]> 
* URL : http://xcb.cs.pdx.edu/
* License : MIT/X
  Description : lightweight, low-latency replacement for Xlib

An X C Binding. A lightweight binding that speaks the X protocol
directly, meant as a replacement for Xlib. It is meant to address some
issues with Xlib, by being smaller, providing lower latency and being
better able to handle multithreaded programs.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux apocalypse 2.4.20 #1 Fri Dec 20 18:08:05 EST 2002 i686
Locale: LANG=en_US, LC_CTYPE=en_US

Re: Debian for x86-64 (AMD Opteron)

[Emile van Bergen]

Hi,

On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote:

[SNIP]
> So basically, I don't think this is a very good idea. However I think we
> can solve it differently in a much simpler way:
> 
> * modify dpkg (already planned) to allow it to install packages from
>   different architectures on a system where it makes sense
> * change the naming of the libraries, for example by adding '64' to the
>   64bit version of a library
> 
> That way you could do something like:
> 
> # echo x86-64 >> /etc/dpkg/legal-archs
> # dpkg -i libgtk2-2.0-1_i386.deb
> # dpkg -i lib64gtk2-2.0-1_x8664.deb

To my untrained eye, this seems an excellent and very general solution.

As a slight but positive side effect, it also seems to open the way to
per-CPU optimized library versions; if you have a 686, you add 686 (or
686-cmov) to /etc/dpkg/legal-archs, and can install either

libssl0.9.6-0.9.6c-2_i386.deb or 
libssl0.9.6-0.9.6c-2_i686.deb; 

on a x86-64 you'd have the choice between those same two plus 

libssl0.9.6-0.9.6c-2_x8664.deb

Of course, that's only the dpkg side of things; in any case, you'd still
need a way to present the extra choices caused by legal-archs in
dselect. How would that be done?

Cheers,


Emile.

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


pgprxcutj0URl.pgp
Description: PGP signature

Re: Fakeroot to obsolete DESTDIR

[Andrew Suffield]

On Thu, Apr 10, 2003 at 02:26:38PM +0200, Wesley W. Terpstra wrote:
> What I propose to do is to slightly extend fakeroot to also intercept
> open/diropen. If the open call would create a file, redirect it to
> /.../debian/tmp or some such location. If the call would open a file, first
> check /.../debian/tmp and then /.

Read the fakeroot manpage for an explanation of why fakeroot does not
wrap open().

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgpQvf5z2l92W.pgp
Description: PGP signature

Re: SASL/LDAP/DB dependency hell.

[Henrique de Moraes Holschuh]

On Thu, 10 Apr 2003, Junichi Uekawa wrote:
> I could not convince libpng maintainers to use versioned symbols because
> they were apparently not available on AIX and Windows.

AIX is an ancient PoS. And Windows, well... :)

Symbol versioning is something that can be turned on and off where it is
available.  Not using it because "foo" doesn't support it makes no sense. AS
FAR AS you write the detection code...

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

Re: Debian for x86-64 (AMD Opteron)

[Andy MacKay]

On Thu, Apr 10, 2003 at 12:43:38PM +0100, Colin Watson wrote:
> On Thu, Apr 10, 2003 at 12:39:25PM +0200, Cyrille Chepelov wrote:
> > Le Thu, Apr 10, 2003, ? 10:40:47AM +0100, Hamish Marson a ?crit:
> > > I'm not sure how your logic works out that a 64 bit reg is going to
> > > be faster than a 32bit one. Or do you mean simply you're expecting a
> > > speedu because there are MORE 64 bit registers tahn 32 bit
> > > registers?
> > 
> > Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64
> > (IIRC, long is 64 bit and of course any T* ). So yes, anything which
> > plays with pointers will be larger on x86-64, but it's not an
> > automatic doubling in size of everything. And mapping libraries twice
> > also eats a good deal of memory. OTOH, 16 general-purpose 8,16,32 or
> > 64-bit registers (not even counting a large SSE2 register file as
> > well) should help gcc feel more at home (especially with less code
> > dedicated to handling register<->memory swap-outs)
> > 
> > I don't have numbers to back either choice, but it looks to me that a
> > mixed userland with everything duplicated should be a last resort. And
> > I'm sure some people have numbers out these.
> 
> Based on the numbers I've seen, the factors mentioned seem to balance
> each other out fairly well. I'm not (yet) allowed to talk about the
> details though ...

No need to be secretive. :) In Fred Weber's MPF presentation last year
he put up some specific numbers about how code generation was affected
by going to 64-bit mode.  As I recall he said that the average
instruction length increased slightly and static data size increased
(larger pointers), but both the static and dynamic instruction counts
went down because of the decrease in register spilling, and that
generally offset the bloating effect of having larger pointers. 

I think the general consensus on the has been that on x86-64, compiling
for 64-bit mode is seldom a performance loss and often a performance
win.  This is contrary to other mixed 32/64-bit architectures, usually
because in those cases the 32-bit arch that the 64-bit arch was based on
wasn't as archtecturally hamstrung in the first place as x86 is.

Does what I've said jive with what you're seeing, in a very high-level
sense?  I don't want to get you in trouble with the NDA police or
anything. :)

-- 
Anderson MacKay <[EMAIL PROTECTED]>
Green Hills Software -- Hardware Target Connections

Re: Debian for x86-64 (AMD Opteron)

[Wichert Akkerman]

Previously Emile van Bergen wrote:
> As a slight but positive side effect, it also seems to open the way to
> per-CPU optimized library versions;

That's why we were already planning to do it. To make that really useful
one could extend apt and add a priority to each supported architecture
so it can pick the one that is preferred for your system.

Wichert.

-- 
Wichert Akkerman <[EMAIL PROTECTED]>   http://www.wiggy.net/
A random hacker

Re: Debian for x86-64 (AMD Opteron)

[Michael Banck]

On Thu, Apr 10, 2003 at 04:43:57PM +0200, Emile van Bergen wrote:
> On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote:
> 
> [SNIP]
> > So basically, I don't think this is a very good idea. However I think we
> > can solve it differently in a much simpler way:
> > 
> > * modify dpkg (already planned) to allow it to install packages from
> >   different architectures on a system where it makes sense
> > * change the naming of the libraries, for example by adding '64' to the
> >   64bit version of a library
> > 
> > That way you could do something like:
> > 
> > # echo x86-64 >> /etc/dpkg/legal-archs
> > # dpkg -i libgtk2-2.0-1_i386.deb
> > # dpkg -i lib64gtk2-2.0-1_x8664.deb
> 
> To my untrained eye, this seems an excellent and very general solution.
> 
> As a slight but positive side effect, it also seems to open the way to
> per-CPU optimized library versions; if you have a 686, you add 686 (or
> 686-cmov) to /etc/dpkg/legal-archs, and can install either
> 
> libssl0.9.6-0.9.6c-2_i386.deb or 
> libssl0.9.6-0.9.6c-2_i686.deb; 
> 
> on a x86-64 you'd have the choice between those same two plus 
> 
> libssl0.9.6-0.9.6c-2_x8664.deb

Please note the
wiggy> * change the naming of the libraries, for example by adding '64' to
wiggy> the 64bit version of a library

Your above examples all have the same package name, just for a different
architecture. AFAICT, this is exactly what Wichert wanted to avoid.

Michael

Re: Fakeroot to obsolete DESTDIR

[Steve Langasek]

On Thu, Apr 10, 2003 at 02:26:38PM +0200, Wesley W. Terpstra wrote:
> After running into yet two more problems with staged installs ala DESTDIR,
> I was reminded of an idea I originally had for fink packages.

> ... but, let's begin from the beginning.
> Why is DESTDIR a problem?

> ---
> 1: libtool cannot relink inter-dependent libraries during a staged install.

Please refile this under the header 'Why is libtool a problem?'.

-- 
Steve Langasek
postmodern programmer


pgpnMEVhTttIv.pgp
Description: PGP signature

Re: Debian for x86-64 (AMD Opteron)

[Emile van Bergen]

Hi,

On Thu, Apr 10, 2003 at 05:23:12PM +0200, Cyrille Chepelov wrote:

> Le Thu, Apr 10, 2003, à 04:43:57PM +0200, Emile van Bergen a écrit:
> 
> > > That way you could do something like:
> > > 
> > > # echo x86-64 >> /etc/dpkg/legal-archs
> > > # dpkg -i libgtk2-2.0-1_i386.deb
> > > # dpkg -i lib64gtk2-2.0-1_x8664.deb
> > 
> > To my untrained eye, this seems an excellent and very general solution.
> > 
> > As a slight but positive side effect, it also seems to open the way to
> > per-CPU optimized library versions; if you have a 686, you add 686 (or
> > 686-cmov) to /etc/dpkg/legal-archs, and can install either
> > 
> > libssl0.9.6-0.9.6c-2_i386.deb or 
> > libssl0.9.6-0.9.6c-2_i686.deb; 
> 
> That would be 
>   lib686ssl0.9.6-0.9.6c-2_i686.deb; 
> or 
>   lib686-cmovssl0.9.6-0.9.6c-2_i686-cmov.deb; 
> 
> according to Wichert's proposal (which I think will lead us to a support
> nightmare, not to mention the ugliness of the naming scheme)

No, for dependency-less optimizations you leave them out on purpose;
that's the whole idea. You want 32-bit applications that depend on
libssl0.9.6, to use either 
libssl0.9.6-0.9.6c-2_i386.deb or
libssl0.9.6-0.9.6c-2_i686.deb; completely transparent to the depending
application. I.e. every package becomes slightly virtual in the sense
that multiple architectures are allowed.

Only 64-bit applications would depend on lib64ssl0.9.6 (from
lib64ssl0.9.6-0.9.6c-2_x8664.deb, sorry, missed the 64 in my last mail)
instead of depending on libssl0.9.6, which is an entirely different
package. 

I'll stop rambling about this now though as optimization an entirely
different subject. I just wanted to second Wichert's idea.

Cheers,


Emile.

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


pgpTkcQvWK8uO.pgp
Description: PGP signature

Re: Debian for x86-64 (AMD Opteron)

[Hamish Marson]

Andy MacKay wrote:
On Thu, Apr 10, 2003 at 12:43:38PM +0100, Colin Watson wrote:
 

On Thu, Apr 10, 2003 at 12:39:25PM +0200, Cyrille Chepelov wrote:
   

Le Thu, Apr 10, 2003, ? 10:40:47AM +0100, Hamish Marson a ?crit:
 

I'm not sure how your logic works out that a 64 bit reg is going to
be faster than a 32bit one. Or do you mean simply you're expecting a
speedu because there are MORE 64 bit registers tahn 32 bit
registers?
   

Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64
(IIRC, long is 64 bit and of course any T* ). So yes, anything which
plays with pointers will be larger on x86-64, but it's not an
automatic doubling in size of everything. And mapping libraries twice
also eats a good deal of memory. OTOH, 16 general-purpose 8,16,32 or
64-bit registers (not even counting a large SSE2 register file as
well) should help gcc feel more at home (especially with less code
dedicated to handling register<->memory swap-outs)
I don't have numbers to back either choice, but it looks to me that a
mixed userland with everything duplicated should be a last resort. And
I'm sure some people have numbers out these.
 

Based on the numbers I've seen, the factors mentioned seem to balance
each other out fairly well. I'm not (yet) allowed to talk about the
details though ...
   

No need to be secretive. :) In Fred Weber's MPF presentation last year
he put up some specific numbers about how code generation was affected
by going to 64-bit mode.  As I recall he said that the average
instruction length increased slightly and static data size increased
(larger pointers), but both the static and dynamic instruction counts
went down because of the decrease in register spilling, and that
generally offset the bloating effect of having larger pointers. 

I think the general consensus on the has been that on x86-64, compiling
for 64-bit mode is seldom a performance loss and often a performance
win.  This is contrary to other mixed 32/64-bit architectures, usually
because in those cases the 32-bit arch that the 64-bit arch was based on
wasn't as archtecturally hamstrung in the first place as x86 is.
Does what I've said jive with what you're seeing, in a very high-level
sense?  I don't want to get you in trouble with the NDA police or
anything. :)
 

Ah right. Light dawneth. Yes, you make excellent sense. Basically ia32 
is so hacked about & wacky (In order to be backwardly compatible) as to 
be very slow, yet ia64 is a new instruction set with none of the baggage 
that it had to carry around. Thus you can optimise ia64 architecture 
better than ia32.

Compared to something like PowerPC (Sparc maybe? Although I don't think 
Sparc was concieved as a 64 bit instruction set was it? I could be wrong 
there though) where you start with a 64-bit definition and then cut it 
back to 32-bit & so gain some optimisations which make 32-bit PowerPC 
faster than 64-bit PowerPC (Except where you genuinely need 64bit of 
course).


--
I don't suffer from Insanity... | Linux User #16396
I enjoy every minute of it...   |
|
http://www.travellingkiwi.com/  |

Re: Debian for x86-64 (AMD Opteron)

[Cyrille Chepelov]

Le Thu, Apr 10, 2003, à 03:33:39PM +0200, Wichert Akkerman a écrit:

> That way you could do something like:
> 
> # echo x86-64 >> /etc/dpkg/legal-archs
> # dpkg -i libgtk2-2.0-1_i386.deb
> # dpkg -i lib64gtk2-2.0-1_x8664.deb

Will we have to also have lib64gtk2.0-dev? Wouldn't that have pretty bad
inconvenient consequences on the build dependencies?

-- Cyrille

-- 

Re: Debian for x86-64 (AMD Opteron)

[Emile van Bergen]

Hi,

On Thu, Apr 10, 2003 at 05:27:40PM +0200, Michael Banck wrote:

> On Thu, Apr 10, 2003 at 04:43:57PM +0200, Emile van Bergen wrote:
> > On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote:
> > 
> > [SNIP]
> > > So basically, I don't think this is a very good idea. However I think we
> > > can solve it differently in a much simpler way:
> > > 
> > > * modify dpkg (already planned) to allow it to install packages from
> > >   different architectures on a system where it makes sense
> > > * change the naming of the libraries, for example by adding '64' to the
> > >   64bit version of a library
> > > 
> > > That way you could do something like:
> > > 
> > > # echo x86-64 >> /etc/dpkg/legal-archs
> > > # dpkg -i libgtk2-2.0-1_i386.deb
> > > # dpkg -i lib64gtk2-2.0-1_x8664.deb
> > 
> > To my untrained eye, this seems an excellent and very general solution.
> > 
> > As a slight but positive side effect, it also seems to open the way to
> > per-CPU optimized library versions; if you have a 686, you add 686 (or
> > 686-cmov) to /etc/dpkg/legal-archs, and can install either
> > 
> > libssl0.9.6-0.9.6c-2_i386.deb or 
> > libssl0.9.6-0.9.6c-2_i686.deb; 
> > 
> > on a x86-64 you'd have the choice between those same two plus 
> > 
> > libssl0.9.6-0.9.6c-2_x8664.deb
> 
> Please note the
> wiggy> * change the naming of the libraries, for example by adding '64' to
> wiggy> the 64bit version of a library
> 
> Your above examples all have the same package name, just for a different
> architecture. AFAICT, this is exactly what Wichert wanted to avoid.

Yes, sorry, the last .deb name should have been
lib64ssl0.9.6-0.9.6c-2_x8664.deb; it's a different package altogether,
and applications need an explicit dependency on it. The other two were
correct; the package name is the same, they conflict inherently, and
applications cannot specify any particular dependency.  The positive
side of that is that the rollout of CPU optimized versions of library
can happen without having to change depending applications in any way.

Cheers,


Emile.

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


pgpiNsZ31ItHK.pgp
Description: PGP signature

Re: Debian for x86-64 (AMD Opteron)

[Andy MacKay]

On Thu, Apr 10, 2003 at 04:50:59PM +0100, Hamish Marson wrote:
> Ah right. Light dawneth. Yes, you make excellent sense. Basically ia32 
> is so hacked about & wacky (In order to be backwardly compatible) as to 
> be very slow, yet ia64 is a new instruction set with none of the baggage 
> that it had to carry around. Thus you can optimise ia64 architecture 
> better than ia32.

Yep, that's pretty much it.  But ia64 != x86-64 ... ia64 is the Intel
Itanium's instruction set, while x86-64 is the AMD Opteron/Athlon 64,
and they're very very different beasts.  The x86-64 architecture really
is just another extension of the x86 architecture (and so retains all
the scary stuff that's been in there from the dawn of time for backwards
compatibility) ... but it does add in a few nice features that make life
easier for the compiler.  IA64 would take some time to explain in full,
but in short it's completely incompatible with x86 (of any sort), and is
based on an idea called VLIW where multiple instruction "bundles" are
issued together and more responsibility is placed on the compiler's
instruction scheduler to extract parallelism from the instruction
stream.  

> Compared to something like PowerPC (Sparc maybe? Although I don't think 
> Sparc was concieved as a 64 bit instruction set was it? I could be wrong 
> there though) where you start with a 64-bit definition and then cut it 
> back to 32-bit & so gain some optimisations which make 32-bit PowerPC 
> faster than 64-bit PowerPC (Except where you genuinely need 64bit of 
> course).

Really it's that when you're in 64-bit mode you use 64-bit operands for
many operations (particularly pointers and pointer arithmetic), and it
takes more time to do 64-bit math than 32-bit math (c.f. on Opteron a
32-bit multiply has a 3-cycle latency, but a 64-bit mul has a 5-cycle
latency).  Furthermore, in 64-bit mode you put more stress on the memory
subsystem because you're loading and storing some non-zero number of
64-bit data chunks that would have been smaller (probably 32 bits in
size) in 32-bit mode.

All that to say that if you can do something in 32-bit mode and all
other things are equal, 32-bit operations are more efficient than 64-bit
operations for many cases ... there's less bits to work on.  In the case
of x64-64, all things are *not* equal :), and the extra registers and
such tends to offset the extra overhead of dealing with 64-bit operands.
Or so AMD has said.

Also, in 64-bit mode AMD left sizeof(int)==4 so that the overhead of
64-bit integer operations isn't incurred for many code paths that don't
need it.  They also made some noise about changing the C calling
convention around and supposedly it's more efficient now, but I don't
know much in the way of details on that.

-- 
Anderson MacKay <[EMAIL PROTECTED]>
Green Hills Software -- Hardware Target Connections

[desktop] Draft proposal for a new debian menu system

[Enrico Zini]

Hello.

With all the new anvances in Linux Desktop tecnologies, it seems like
the current menu system needs some redesign to keep up and integrate
with the other existing systems.

Since the desktop menu problem is shared with at least the Gnome and KDE
people, I've asked in the gnome-usability list what is their current
status with it.

The answer came quickly, and was quite encouraging: they are working
together on it at www.freedesktop.org, and they are converging into the
open Desktop Menu Specification found here:

  http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html

Some background:

 what is the freedesktop.org project (from the About section of the site):

   freedesktop.org is affiliated with the Free Standards Group, which
   organizes a number of standards for open source software, in
   particular the Linux Standard Base. freedesktop.org itself does not
   "legislate" or approve standards, this web site and our CVS server
   and mailing list are purely intended as a place for developers to
   meet and work together.

 what is the Desktop Menu Specification (from the Specification Intro):

   This DRAFT document defines how to construct a user-visible hierarchy
   of applications, typically displayed as a menu. It allows third-party
   software to add menu items that work for all desktops, and allows
   system administrators to edit menus in a way that affects all
   desktops.
   [...]
   Things are complicated somewhat by the need to support legacy desktop
   entry hierarchies, and the need to allow third parties to extend the
   menu layout. Both of these issues are addressed by the idea of
   merging two menu layouts. 


What we have there is a nice menu standard which is now becoming *the*
menu standard, and which has some desirable feature like multiple
categories and menu merging.

The former seems to be one the way to to overcome the limitations of the
existing systems, where Mozilla is a web browser, an HTML editor and a
mail reader, but can only be found under one arbitrary entry of those
three.

The latter would allow to merge our menu informations with the ones
provided by the other desktop projects, thus preserving consistency
among distributions (from the efforts of those desktop projects) and
completeness (from the Debian high quality standards).


At my first read of both standards, the DMS .menu files appear to be as
expressive as the current /usr/lib/menu/ files, so they
are suitable as a replacement.

update-menu can probably also be used to generate the new style .desktop
files from the existing data, opening the possibility of automated
conversion.


I would like to propose that we switch to the freedesktop.org .menu
format for desktop entries, and we keep providing menu informations for
applications that do not provide one on their own.

The advantages would be to adhere to an existing, open standard (and
push it), to provide a better system (with multiple cathegories and menu
translations) and to better integrate with the desktop environments we
package.  The latter is going to be very important in the future as
Linux spreads in the desktop world.

I would also like to propose a link to http://www.freedesktop.org among
the "Important Links" section of http://www.debian.org/devel/debian-desktop/



The menu policy states this:

> If you have other proposals for changing the menu hierarchy, or making
> other changes to menu policy, please bring it up on debian-policy.

Before making a policy proposal, I feel the need for a feasibility
study, to see if there are resons not to do this move and, if not, to
design a strategy for the move.

I'm not experienced enough to perform the study myself.  This is the
reason I'm posting this for discussion in debian-devel.

This is a small but important step to take, please don't let this mail
go unanswered like the one about user analysis.  There's no need for
much historical Debian experience for user analysis, and I can try and
start it alone.  I cannot do this for the Debian menu system: please
respond.


Yours truly,

Enrico


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


pgpbAXj2Cmqf0.pgp
Description: PGP signature

Bug#187988: ITP: planets -- A gravitation simulation program of planetary bodies

[Martin Pitt]

Package: wnpp
Version: N/A; reported 2003-04-10
Followup-For: Bug #187988

I compiled, installed and tested the program and it worked without
problems. I have contacted the upstream author (Yaron Minsky): he would
be pleased to have a Debian package and offered his cooperation.

Currently I am not a Debian developer, I would like to upload the
package with the help of a sponsor. There is a chance that a DD I know
helps me, otherwise I'll ask on d-mentors.

Martin Pitt

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux tomate 2.4.19 #3 Wed Oct 16 16:08:27 CEST 2002 i586
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: Debian for x86-64 (AMD Opteron)

[Arnd Bergmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thursday 10 April 2003 16:43, Emile van Bergen wrote:

> On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote:

> >
> > # echo x86-64 >> /etc/dpkg/legal-archs
> > # dpkg -i libgtk2-2.0-1_i386.deb
> > # dpkg -i lib64gtk2-2.0-1_x8664.deb
>
> libssl0.9.6-0.9.6c-2_i386.deb or
> libssl0.9.6-0.9.6c-2_i686.deb;
>
> on a x86-64 you'd have the choice between those same two plus
>
> libssl0.9.6-0.9.6c-2_x8664.deb

These two proposals have a significant difference. The first one
needs more changes to the individual library packages because it
changes not only the file names but also the package names. I'm
not sure how to best handle dependencies on this.

The second proposal would mean that dpkg will have to be changed
so it can install the same package for both x8664 and {i386,i686}
at the same time, which could prove difficult. The dependencies
here can basically stay the same (e.g. ssh will continue to
depend on libssl0.9.6 even on 64 bit), but dpkg and apt will have
to know about an additional dimension concerning dependencies, e.g.:

ssh (64 bit) depends on libssl0.9.6 (64 bit)
ssh (32 bit) depends on libssl0.9.6 (32 bit)
ssh (64 bit) depends on debconf (32 _or_ 64 bit)
libssl096-dev depends on libssl0.9.6 (32 _and_ 64 bit??)

> Of course, that's only the dpkg side of things; in any case, you'd still
> need a way to present the extra choices caused by legal-archs in
> dselect. How would that be done?

One way is to copy the system that rpm is using: every installation
sets the default architecture and the package manager has a static
translation tree with entries like this:

ia64   -> i686
x8664  -> athlon
athlon -> amdk6
athlon -> i686
amdk6  -> i586
i686   -> i586
i586   -> i486
i486   -> i386

When apt looks for a binary it starts at the configured architecture
and moves down the tree and installs the first available package it
can find.

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

iD8DBQE+lZpx5t5GS2LDRf4RAliQAJ4qyazmyTV/L49uTQUnO26JPecFwACgiLZQ
zEVvf06loHkSWnN4smRD9aY=
=UGTw
-END PGP SIGNATURE-

BIG&TALL news (Big Sizes Menswear in Athens)

[BIGANDTALL.GR]

BIG&TALL news

Åðéóêåöèåßôå ôï çëåêôñïíéêü ìáò êáôÜóôçìá êáé èá âñåßôå áðü óÞìåñá ôá åîÞò íÝá ðñïúüíôá:

1. ÍÝåò êïíôïìÜíéêåò ðïõêáìßóåò
2. ÍÝá õöáóìÜôéíá ìðïîåñÜêéá

-- TEXT IN ENGLISH FOLLOWS ---

BIG&TALL news

Visit our OnLine store and find from today:

1. New short sleeved "button-down" shirts
2. New Boxer Shorts


BIG&TALL news
		To unsubscribe: http://www.ymlp.com/[EMAIL PROTECTED]This mailinglist is hosted by YourMailingListProvider.com

Get 3 Free Panties Now from Frederick's of Hollywood

[Lingerie Exclusive]

Click here or see below to unsubscribe.





You are currently subscribed to DealPatrol.com as: debian-devel@LISTS.DEBIAN.ORG
To unsubscribe Click Here
(http://ofrsvr.com/[EMAIL PROTECTED]&l=DLP) or send an email to
[EMAIL PROTECTED].
Any correspondence about the products/services should be directed to
the company in the ad.
[EMAIL PROTECTED]/EM%
  

Re: Debian for x86-64 (AMD Opteron)

[Daniel Jacobowitz]

On Thu, Apr 10, 2003 at 06:05:38PM +0200, Cyrille Chepelov wrote:
> Le Thu, Apr 10, 2003, à 03:33:39PM +0200, Wichert Akkerman a écrit:
> 
> > That way you could do something like:
> > 
> > # echo x86-64 >> /etc/dpkg/legal-archs
> > # dpkg -i libgtk2-2.0-1_i386.deb
> > # dpkg -i lib64gtk2-2.0-1_x8664.deb
> 
> Will we have to also have lib64gtk2.0-dev? Wouldn't that have pretty bad
> inconvenient consequences on the build dependencies?

I'm not sure this is really a good approach.  Some concerns:
 - the names of all library packages would change on a 64-bit
   architecture; this is a hassle for library packagers
 - Would you have libgtk2-dev_2.0-1_x8664.deb or
   lib64gtk2_2.0-1_x8664.deb?

Hmm... thinking about it some more, basically every package you wanted
to treat this way would have to support building a package with
multiple names.  We could make this easier in dpkg probably.  And then
you would only install i386 packages if there wasn't an x86-64 package
with the same package name...

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Re: [desktop] Draft proposal for a new debian menu system

[Fabio Massimo Di Nitto]

Ciao Enrico,

On Thu, 10 Apr 2003, Enrico Zini wrote:

> The advantages would be to adhere to an existing, open standard (and
> push it), to provide a better system (with multiple cathegories and menu
> translations) and to better integrate with the desktop environments we
> package.  The latter is going to be very important in the future as
> Linux spreads in the desktop world.

As you might know Im not too much into technical details of the menu
system but I have to fully agree with your idea. Keeping up with standards
is good specially if they are spread over different distros.

> please don't let this mail go unanswered like the one about user
> analysis.

Don't be disappointed by that. Sometimes there is no real need for an
answer. When we announced the stats for IPv6 in Debian noone commented via
email. Our biggest satisfaction was to see apache logs exploding within
few minutes.

Regards
Fabio

-- 
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues

http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html

Re: [desktop] Draft proposal for a new debian menu system

[Michał Politowski]

One minor point:

On Thu, 10 Apr 2003 18:16:25 +0200, Enrico Zini wrote:
[...]
> The former seems to be one the way to to overcome the limitations of the
> existing systems, where Mozilla is a web browser, an HTML editor and a
> mail reader, but can only be found under one arbitrary entry of those
> three.

Not strictly true in the current menu system, though you have to duplicate 
complete
entries.

Currently eg. mozilla-browser package includes menu entries under:
Apps/Net(mozilla)
Apps/Net/Mozilla Components (mozilla and mozilla -edit)

-- 
Michał Politowski -- [EMAIL PROTECTED]
Warning: this is a memetically modified message

Re: [desktop] Draft proposal for a new debian menu system

[Colin Walters]

On Thu, 2003-04-10 at 12:16, Enrico Zini wrote:

> I would like to propose that we switch to the freedesktop.org .menu
> format for desktop entries, and we keep providing menu informations for
> applications that do not provide one on their own.

Wasn't Chris Lawrence working on this?  Or maybe he was working on the
older menu format.  Hopefully he can elaborate.

> I would also like to propose a link to http://www.freedesktop.org among
> the "Important Links" section of http://www.debian.org/devel/debian-desktop/

Done.

Anyways, I completely agree with your proposal.

Re: [desktop] Draft proposal for a new debian menu system

[Bernhard R. Link]

* Enrico Zini <[EMAIL PROTECTED]> [030410 18:51]:
> With all the new anvances in Linux Desktop tecnologies, it seems like
> the current menu system needs some redesign to keep up and integrate
> with the other existing systems.

Please explain this phrase. Ecspecially the "other existing systems".
Debian menu-system has many disadvantages, though I've not heared of
any other system at all.

(One of the problems is KDE's inability to use it. Thoug KDE is well
 known to no integrate well. Is it able to parse /etc/printcap nowaday?)

> The answer came quickly, and was quite encouraging: they are working
> together on it at www.freedesktop.org, and they are converging into the
> open Desktop Menu Specification found here:
> 
>   http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html

Seems to be both for the "desktop" and the "menus". I do not see what
they have in common.
It seems to miss some things, most important in my eyes a possibility to
switch window managers. (I doubt it is usable for anything than KDE or
Gnome)


Hochachtungsvoll,
  Bernhard R. Link

-- 
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.

Re: Categorization of packages (was Re: Aptitude, ARs)

[Enrico Zini]

[Cc-ing to deb-usability-list]

On Fri, Mar 28, 2003 at 12:05:25AM -0800, Osamu Aoki wrote:

> > Before the wish list, I propose to do a step back and do some task
> > analysis.
> Also after this we need to prioritize them considering efforts needed to
> achieve them.

You mean efforts for doing the task analysis or efforts to implement the
outcoming proposals?





I'm maintaining an updated HTML version of this ongoing brainstorming in
the Debian Usability Research web pages at:

http://deb-usability.alioth.debian.org/pkgman-brainstorm.html



> I think these "User" thing can be summarized in 3 coordinates
> User::Skill::Developer/Experienced/Intermediate/Newbie
[...]
> At this moment, I think this can be one "User".  Debian User :-)

Yes.  My intent was not to produce an exact taxonomy used to put a label
on our users, but instead to build a list so that we do not forget about
someone.  Kinda like the goal of the User Analysis proposal I've made
recently.


> Instead of addressing "User" factors,  we may be able to assign
> "Relevance" attribute of each package for the typical uses.

Maybe this is best addressed by subprojects/metadistros/flavours
altogether?  I see much potential in that direction.


> >  * Purpose of the application
> I guess you mean purpose of package management application.
> It is:
> 1. to reduce task by the System administrator of any skill level and
>orientation, and
> 2. to provide information to the administrator and normal user for the
>availability and usefulness of the package.

I like this description!


> > - See what kind of problems or tasks have some package in Debian
> >   that address them (what can I do with all these packages?)
> I think "Topics" used by sourceforge is very good starting point for the
> choice of "Topic".  Also "Task" used by Debian is another.
> See http://people.debian.org/~osamu/pub/osamu-cat.txt for example of
> these Topics.

Yes, that's a great candidate for a starting task list.

The experience will probably show other tasks not covered in that list
(Web CMS and Wireless LAN already come to my mind), and they'll
probably come is as bug reports or other feedback.  We need to keep a
door open for the possibility to fit new tasks in.


> > - Examine the different alternative implementations for a given
> >   feature (what choice of word processors do I have?)
> This is basically way to present equivalent packages as an alternatives
> under the menu entry for virtual package.

Yes.  Is the current virtual package system enough for such a feature?
I explain: afaik it's designed to cover the need of application
dependencies, not of user tasks.

For example, rcalc does not "Provides: calculator", since there is no
package that has a dependancy on a calculator application.  However, I
can imagine that some user would like to browse the different
alternatives of calculator applications.




> > At the LCA2003 BOF, in the limited time we had, we came out with these ideas
> > for improving package metadata:
> >  - More than one section (tag/category) per package
> Yes and no.

What do you mean?


> > I think, however, that the time has definitely come to start to
> > seriously address this kind of user-centered technical problems.
> In order to address these issues, I think most important parts is
> creating infrastructures and guide lines to generate compact data to
> address user needs.

What kind of data are you thinking about?  And in what sense "compact
data"?
 

> After thinking more on this issue,I realized the issue in "volunteer"
> project like Debian is to create and maintain good database to address
> above concerns.  I think "popcon" like voting system which not only
> collects installed package and their objective usage records but
> collects more feedbacks from user how the user rate each program
> installed and how relevant each programs are, may be needed to produce
> these information. 
> 1.  People sign up from web and receive key with e-mail
> 2.  People run simple voting program and assign some key words and
> rating for each package which they installed on their system.
> (Sourceforge like Topics entry)
> 3.  E-mail it to server with key. (Some signing involve here)
> 4.  Tally them to create a list which can be used by menu system.

Yes, that kind of infrastructure is definitely something we need.

However, the polls must be carefully designed in order not to restrict
the user base (in your case, to the ones that are able and want to sign
into a web page, then receive a key via mail and feed it to a voting
program), or we should at least be aware of those restrictions and
consider the data accordingly.

Do you already have some polling ideas?


Bye,

Enrico

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


pgph4a9uAWH18.pgp
Description: PGP signature

Re: Debian for x86-64 (AMD Opteron)

[Gerd Knorr]

Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

> multiple names.  We could make this easier in dpkg probably.  And then
> you would only install i386 packages if there wasn't an x86-64 package
> with the same package name...

For application that approach (use x86-64 if available, i386
otherwise) would likely work.  But for library packages it must be
possible to install 32bit and 64bit versions in parallel, so it must
be possible to separate glibc 32bit + glibc 64bit somehow.

Using different names for 32bit and 64bit shared library packages is
IMHO not a bad idea to deal with the issue.  Sure, you have to touch
every f*cking library package to implement that, but you have to do
that anyway to move the 64bit versions of the shared libraries to
/lib64 (and this in turn is needed to be compatible with the rest of
the world).

  Gerd

-- 
Gerd Knorr <[EMAIL PROTECTED]>

Re: Debian for x86-64 (AMD Opteron)

[Drew Scott Daniels]

I don't quite understand all the concepts being discussed but the
following web pages may be worth reading.
http://master.debian.org/~brinkmd/arch-handling.txt
http://lists.debian.org/debian-win32/2003/debian-win32-200302/msg00018.html
http://lists.debian.org/debian-bsd/2002/debian-bsd-200202/msg00131.html

 Drew Daniels

Re: Fakeroot to obsolete DESTDIR

[Joey Hess]

Andrew Suffield wrote:
> Read the fakeroot manpage for an explanation of why fakeroot does not
> wrap open().

   The real way around
  this  is  to  wrap  open()  and create(), but that creates other
  problems, as demonstrated by the libtricks package. This package
  wrapped  many  more  functions,  and tried to do a lot more than
  fakeroot .  It turned out that a minor upgrade of libc (from one
  where the stat() function didn't use open() to one with a stat()
  function that did (in some cases) use open()), would cause unex-
  plainable  segfaults  (that  is,  the  libc6  stat()  called the
  wrapped open(), which would then call the  libc6  stat(),  etc).
  Fixing  them wasn't all that easy, but once fixed, it was just a
  matter of time before another function started  to  use  open(),
  never  mind  trying  to port it to a different operating system.
  Thus I decided to keep the number of functions wrapped by  fake-
  root  as  small  as possible, to limit the likelihood of 'colli-
  sions'.

It's certianly possible to work around this kind of thing, if not always
pretty. I've sucesfully kept open() wrapping working in libmooproxy for over
a year. Anyway, it probably wasn't worth it if fakeroot was only wrapping
open to get the information used to resolve the touch problem described
earlier in the man page, but it might be worth the pain to add open path
support. Up to Clint of course..

Of course, it would sort of suck if we became dependent on this, and then
glibc broke it in some way that was impossible to work around without 
hacking glibc. That would put us in a messy position. At least if fakeroot
breaks irreparably now, we have an easy work around.

-- 
see shy jo


pgpmZnMp44SO2.pgp
Description: PGP signature

Re: Fakeroot to obsolete DESTDIR

[Joey Hess]

Wesley W. Terpstra wrote:
> 1: libtool cannot relink inter-dependent libraries during a staged install.

> On the topic of 1, cvs libtool can do this with an undocumented command-line
> flag. However, it still prefers the installed location over the staged
> location. So, if you link to -L/.../debian/tmp/usr/lib -lfoo, a libfoo.so in
> /usr/lib is prefered, which can cause subtle problems. 

Could you elaborate on what the subtle problems are, exactly? Leaving
as much of libtool out of it as possible, as I'm sure this is not
specific to libtool, is it.

-- 
see shy jo


pgpykVuR76Ocj.pgp
Description: PGP signature

尊敬的: Happy4会员 您好！

[service]

===
Happy4娱乐网：http://happy4.7u7.net
[EMAIL PROTECTED]

200部国内大片电影;500部激情电影免费观看;2000多首DJ舞曲免费试听及下载 ！
===


尊敬的: Happy4会员 您好！


您在Happy4[ Happy4.7u7.Net ]的帐号是: pangaidi ; 密码是: 7ckufem


请妥善保管您的帐号及密码，我们将会在第一时间内为您提供最好的增值服务。
我们的发展离不开您的支持！


===

Re: Debian for x86-64 (AMD Opteron)

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Arnd Bergmann  <[EMAIL PROTECTED]> wrote:
>Possible -- sure, but not useful except as an option for the initial
>bootstrap that might not fully work with /lib64.
>I've followed both SuSE and Red Hat making that mistake with their early
>s390x distributions. They both now have the problem that they changed
>to /lib64 installations, which makes it really hard to create 64 bit
>packages that work in the old _and_ new distributions. 

/lib64 ?! We're arguing for a month if adding a new top-level
directory called /run is a good idea and they just add a very
very ugly /lib64 ?

What's wrong with /lib/ for 64 bits libs and /lib/32/ for the 32 bit
legacy stuff (note the slash).

Ofcourse, they'll get the rpath thing wrong and commercial applications
are going to insist on /lib64, shiver.

Mike.

Re: Debian for x86-64 (AMD Opteron)

[Daniel Jacobowitz]

On Thu, Apr 10, 2003 at 07:59:51PM +, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Arnd Bergmann  <[EMAIL PROTECTED]> wrote:
> >Possible -- sure, but not useful except as an option for the initial
> >bootstrap that might not fully work with /lib64.
> >I've followed both SuSE and Red Hat making that mistake with their early
> >s390x distributions. They both now have the problem that they changed
> >to /lib64 installations, which makes it really hard to create 64 bit
> >packages that work in the old _and_ new distributions. 
> 
> /lib64 ?! We're arguing for a month if adding a new top-level
> directory called /run is a good idea and they just add a very
> very ugly /lib64 ?
> 
> What's wrong with /lib/ for 64 bits libs and /lib/32/ for the 32 bit
> legacy stuff (note the slash).
> 
> Ofcourse, they'll get the rpath thing wrong and commercial applications
> are going to insist on /lib64, shiver.

Well, it's written into the ABI documentation for at least a few
platforms now, so it's a bit late to do anything about it :(

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Re: [desktop] Draft proposal for a new debian menu system

[Michael Banck]

On Thu, Apr 10, 2003 at 01:58:12PM -0400, Colin Walters wrote:
> On Thu, 2003-04-10 at 12:16, Enrico Zini wrote:
> 
> > I would like to propose that we switch to the freedesktop.org .menu
> > format for desktop entries, and we keep providing menu informations for
> > applications that do not provide one on their own.
> 
> Wasn't Chris Lawrence working on this?  Or maybe he was working on the
> older menu format.  Hopefully he can elaborate.

Unfortunately, he seems to be MIA WRT Debian. I tried to dig up his menu
code somewhere on the web, but to no avail.

Michael

Signs from God

[The last Judgement]

Title: Sign from God








Signs from God. The Messiah comes. We
have the end of the World

Signs from God. The Messiah comes.
We have the end of the World and already 3th World war. The
Mankind faces the Doom and as well the biggest ever experienced
Holocaust. Each second Humanbeing ends up in the Pond of Fire. If
the Messiah is not coming now (Jesus Christ, Son of God, King of
the Jews), God will come as Devil-and Germany brought the entire
Mankind into Hell. Owing to the Brandenburger Nazigate in Berlin
every Human will be punished as hard as Adolf Hitler. That means
Hell forever:Final Solution (Endloesung)

Everyone who doesn't call Mankind
into Paradise has got at least the same much Guilt and Dirt at
putting like Adolf Hitler an will be punished just as hard. The
USA was sworn in to the Bible and is liable with the Final
Solution (Endloesung) Death on the Cross forever-

The one who supports Wholesole
murderers and Traitors- like especially the USA and other
Countries did towards Germany-will be executed as Wholesale
murderers and Traitors and sent to the Pond of Fire. Laughing
Third Persons are even hardest punished by God.



Since the USA bombed the Cradle of
Mankind (The Gulf-War USA and Irak),is the entire Mankind
condemned to Hell.When God`s Children are getting bombed,pays the
Mankind with the Eternal Penalty. That includes also the USA. The
Iraq is the Cradle of Mankind, Tigris Euphrat the
Beginning of the Bible. Adam and Eve. The one who`s the
Worldpower Number 1- as it happens to the USA-has got the Main
Responsibility for the whole Mankind and is liable now even with
the Final Solution. Death at the Cross- Hell forever.

If the USA belief that they could
make War on their own account- then they have to count with the
eternal Punishment. The USA bombed once before the Cradle of
Mankind (1991 Irak) and is already condemned to Hell. But for to
make a War needs the USA the Permission of God himself. Which
will never be granted.

The Brandenburger Nazigate in
Berlin is the Hellgate of Mankind and must be pulled down
immediately



Germany turned with the
Brandenburger Nazigate Got to Devil-Germany is therefore Nation
of Kain and High Treason and brought the entire Mankind into Doom.

Germany has got the Worldpower to
bring the entire Mankind into Hell if the Brandenburger Nazigate
in Berlin is not pulled down immediately and if there will hot be
atoned for the second Worldwar. The USA must be careful that they
don't come into Hell completely in because the reunion of Nazi-Germany.
Who Protects Wholesale murderers and High Traitors like the USA
did for Decades, will be executed as Wholesale murderer and as
one guilty of High Treason and ends up in the Pond of Fire. The
USA raised Nazi-Germany and is liable now for the reunited Nazi-Germany.
Germany made an Oath to God and the Leader of the Nazis. That
means everything what Germany does falls back to God-Germany
caused with that its own Sentence. Which is Death on the Cross
and Hell forever. That is now reputed even for entire Mankind. If
it would be up to Germany the Mankind would be in Hell already
and lost forever. Hence The Mankind must be called now into
Paradise. Before a War even takes Place. Anything else means
Wholesale murder and High Treason. The condemnation for that is
Hell forever.

The USA have got now the Main
responsibility for the entire Mankind, and with it also for
Germany. The one with the biggest Power must also account for it
to God. So the USA is liable for the Final Solution Death on the
Cross Hell forever.Jesus Christ is a Diamond,is our Redeemer-can
release us from the Guilt and save entire Mankind from Downfall.

Sign from God is no
Advertising,but a Message and is reputed for entire Mankind.

http://www.zevo.de



 

 

ocaml compiled binaries and rpath

[Martin Pitt]

Hi!

I'm just packaging planets (#187988) which is written in ML and
compiled with ocaml. The problem is that the ocaml linker uses the
rpath feature (i. e. hardcoded libary paths).

It seems to be against Debian policy to use rpath; on the other hand,
the ocaml linker does not seem to allow disabling it (at least the
documentation says nothing about this issue).

lintian says:

W: planets: binary-or-shlib-defines-rpath ./usr/bin/planets
/usr/lib:/usr/X11R6/lib
N:
N:   The binary or shared library defines the `RPATH'. Usually this is a
N:   bad thing. Most likely you will find a Makefile with a line like:
N:   gcc test.o -o test -Wl,--rpath
N:   or
N:   gcc test.o -o test -R/usr/local/lib
N:   Please contact debian-devel@lists.debian.org if you have questions
N:   about this.

Does anybody know whether it's possible to avoid that? If not, it is
just a warning, so how bad it would be just to ignore it?

Thanks a lot and have a nice day!

Martin
-- 
Martin Pitt
home:  www.piware.de
eMail: [EMAIL PROTECTED]

Verteidigen Sie Ihre Freiheit und Ihre Rechte! Stoppt TCPA!
Defend your freedom and your rights! Stop TCPA!
http://www.notcpa.org


pgpky5ki85gpJ.pgp
Description: PGP signature

Re: /run and read-only /etc

[Jeremy Jackson]

Can someone point me the message(s) discussing /run (and why not
/etc/run) - I would like to think that adding another directory off /
should be avoided.  /etc/run sounds nice, unless you want to support
booting before /etc is mounted...

Cheers,

Jeremy

On Wed, 2003-04-09 at 14:17, Thomas Hood wrote:
> Here are:
> * an updated list of wishes,
> * an updated TODO suggestion for resolv.conf based on Emile's idea,
> * a brief rationale for adding /run/,
> * and a discussion of some FHS passages that present problems.
> 
> We need to find more of the programs that routinely write to /etc.
> Russell might be of some help here.  :)
> 
> The read-only root effort
> =
> 
> Wish reports filed or updated
>   * sysvinit
>   #150355: Please move motd to /var/lib/
> NEW:  #188087: Move ioctl.save out of /etc/
>   * util-linux
>   #156489: Please move adjtime out of /etc/
>   * ppp
>   #187756: Patch to allow /etc/ to be read-only
>   * pppconfig
>   #187810: Please support read-only /etc/
> /etc/ppp/ip-up.d/0dns-up and /etc/ppp/ip-down.d/0dns-down
> shouldn't create temporary files in /etc/
>   #187651: Please document how to keep resolv.conf static
>   * linuxlogo
>   #187953: Please do not store files in /etc/.  Use /var/lib/.
>   * cupsys
>   #187954: Move /etc/printcap.cups under /var/
> 
> Wishes to be filed (by Jamie Wilkinson) after more testing
>   * base-files
>   Add /run/ directory
>   * pam, shadow
>   Allow either /etc/nologin or /run/nologin to prevent nonroot login
>   * sysvinit:
>   Touch /run/nologin (not /etc/nologin) when there is a delay
>   before a shutdown.
>   * util-linux
>   Use /run/mtab for mount's statefile
> 
> TODO for /etc/resolv.conf
>   Overview:
>   * /etc/resolv.conf -> /run/resolv.conf
>   * Networking daemon pidfiles go in /run/
>   * Resolv.conf-like files go in /run/resolver/interfaces/
>   * DNS cache configuration file fragments go in /run//
>   * "/etc/init.d/resolver reload" regenerates /run/resolv.conf
> and calls DNS cache update scripts in /etc/resolver/update.d/
>   * libc6
> * Create /etc/init.d/resolver script to:
>   * Do "run-parts /etc/resolver/update.d"
>   * Write /run/resolv.conf which:
> * lists 127.0.0.1 first if some local nameserver is running
> * then lists other nameservers from /run/resolver/interfaces/*
> * As B. Link and others have noted, this will have to be done
>   with some care.
> * Change postinst to install symlink in rcS.d
>   * bind
> * Create script /etc/resolver/update.d/bind to:
>   * Write a "forwarders { ... }" statement to
> /run/bind/named.conf.options.forwarders containing
> the nameserver adresses from /run/resolver/interfaces/*
>   * Then do "/etc/init.d/bind reload"
> * Change the /etc/bind/named.conf.options file to include
>   /run/bind/named.conf.options.forwarders within the
>   "options { ... }" statement.
>   * dnscache
> * Something similar
>   * ppp
> * Change /usr/sbin/pppd to:
>   * Store PID in /run/, not in /var/run/
> * Create script /etc/ppp/ip-up.d/resolver to:
>   * Write the lines:
>   nameserver $DNS1
>   nameserver $DNS2
> to /run/resolver/interfaces/$PPP_IFACE
>   * Then call update-resolver
> * Create script /etc/ppp/ip-down.d/resolver to:
>   * Delete /run/resolver/interfaces/$PPP_IFACE
>   * Then call update-resolver
>   * pump
> * Add /etc/pump directory
> * Change /sbin/pump to:
>   * Store PID in /run, not in /var/run
>   * By default, don't write /etc/resolv.conf
>   * Run /etc/pump/up after configuring interface, furnishing
> $IFACE and nameserver addresses $DNS1 and $DNS2
> * Add script /etc/pump/up to:
>   * Write the lines:
>   nameserver $DNS1
>   nameserver $DNS2
> to /run/resolver/interfaces/$IFACE
>   * Then call update-resolver
> * Add script /etc/pump/down to:
>   * Delete /run/resolver/interfaces/$IFACE
>   * Then call update-resolver
> * Move pump.conf under /etc/pump
>   * dhcp3-client
> * Change /sbin/dhclient to:
>   * By default, store PID in /run, not in /var/run
> * Change /etc/dhcp3/dhclient-script to:
>   * Write resolv.conf information to
> /run/resolver/interfaces/$interface not to /etc/resolv.conf
>   * Then call update-resolver
> 
> TODO later
>   * ifupdown
> * Wish that ifstate be moved under /run/network/
>   * sysvinit
> * Add support for mounting / read-only.
> * Add support for mounting /run/ as a separate filesystem.
> * The patches in #30446 and #186892 should be reviewed
>   in implementing this.
> 
> Rationale for adding /run directory
> ===
> 
> The /var/ hierarchy is for "variable" files -- i.e., files that vary
> during normal sy

尊敬的: Happy4会员 您好！

[service]

===
Happy4娱乐网：http://happy4.7u7.net
[EMAIL PROTECTED]

200部国内大片电影;500部激情电影免费观看;2000多首DJ舞曲免费试听及下载 ！
===


尊敬的: Happy4会员 您好！


您在Happy4[ Happy4.7u7.Net ]的帐号是: pangaidi ; 密码是: 7ckufem


请妥善保管您的帐号及密码，我们将会在第一时间内为您提供最好的增值服务。
我们的发展离不开您的支持！


===

Re: ocaml compiled binaries and rpath

[Remi Vanicat]

Martin Pitt <[EMAIL PROTECTED]> writes:

> Hi!
>
> I'm just packaging planets (#187988) which is written in ML and
> compiled with ocaml. The problem is that the ocaml linker uses the
> rpath feature (i. e. hardcoded libary paths).

I don't know the answer, but you should ask on
debian-ocaml-maint@lists.debian.org, where you will find several
debian maintainer that have packaged ocaml program

[...]

-- 
Rémi Vanicat
[EMAIL PROTECTED]
http://dept-info.labri.u-bordeaux.fr/~vanicat

Re: /run and read-only /etc

[Jeremy Jackson]

Overall I think it is wonderful to see support for read-only root being
worked on.

On Wed, 2003-04-09 at 15:41, Matthew Garrett wrote:
> Jeremy Jackson wrote:
> 
> (doing this with bind mounts)
> 
> >2.2 kernels are out though.
> 
> As are BSDs. I have no idea whether the Hurd supports bind mounting.
> 
Can it be assumed that all systems that may use this support ramdisks?  
What other schemes would allow a read-only root?  Mounting a small fs on
/run (although I hope it's not in the root directory)?

> In most cases, just moving the files somewhere more sensible like
> /var/run is sensible. The only argument should be over files that need
> to be written before /var has been mounted, of which there should be a
> very small number. It should be possible to deal with this in a simple
> fashion.

The technique involving bind mounts can be done with a regular mount, it
would just take a few more steps:

Mount ramdisk or whatever other rw fs on /etc/run very early in boot. 
Whatever needs to scribble in it does so, and everything works. If later
the root FS is mounted rw, copy contents of /run to temp dir, unmount
/etc/run, clear it out, then copy it all back.

I think it's the least invasive technique, although I agree that some
things that are messing about in /etc and can do it in /var should be
fixed.

-- 
Jeremy Jackson <[EMAIL PROTECTED]>

Bug#188516: ITP: mrtg-ping-probe -- Ping module for Multi Router Traffic Grapher (MRTG)

[Jonathan Oxer]

Package: wnpp
Version: unavailable; reported 2003-04-11
Severity: wishlist

* Package name: mrtg-ping-probe
  Version : 2.1.0
  Upstream Author : Peter W. Osel <[EMAIL PROTECTED]>
* URL : http://pwo.de/projects/mrtg/
* License : GPL version 2
  Description : Ping module for Multi Router Traffic Grapher

mrtg-ping-probe is a ping probe for MRTG 2.x.  It is used to monitor
the round trip time and packet loss to networked devices.  MRTG uses
its output to generate graphs visualizing minimum and maximum round
trip times or packet loss.
  
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux jon.ivt.com.au 2.4.18 #8 SMP Fri Oct 11 10:41:39 EST 2002 i686
Locale: LANG=C, LC_CTYPE=C

Re: bad postinst in kernel-images

[Keith Owens]

When using a recent binutils, you need modutils >= 2.4.17.  The
binutils team changed the output of the 'nm' command which changed the
contents of System.map.

Re: SASL/LDAP/DB dependency hell. (was: Accepted cyrus-sasl 1.5.27-3.4 (i386 source))

[Steve Langasek]

On Wed, Apr 09, 2003 at 09:26:12PM -0700, Daniel Schepler wrote:

> > On Tue, Apr 08, 2003 at 07:07:33PM -0400, Richard A Nelson wrote:
> > > Why was this rebuilt with libdb2-dev ?  Shouldn't we be trying to
> > > get things to db4.1 at this point ?  I'd think db3 at a minimum.

> > > This isn't just idle curiosity either, SASL impacts MANY packages -
> > > most MTAs and anything using OpenLDAP.

> > > If we don't agree on a minimum, or at least a preferred lib... we're
> > > going to have packages linked against 3 different levels - not fun

> > Hello,
> > Actually it is much simpler, many packages are simply not compileable
> > anymore:

> > libldap2-dev depends on libsasl-dev [1]
> > libsasl-dev depends on libdb2-dev (>= 2.7.7.0-7) [2]
> > libdb3-dev conflicts with libdb2-dev

> > [1] introduced in response to #164791
> > [2] introduced in response to #168993

> > libtool strikes again, quoting from the report
> > | /usr/lib/libsasl.la contains -lpam as a dependency, so -lsasl can't be
> > | linked using libtool without libpam0g-dev being installed.

> > This hits almost anything linking against libldap2, including postfix
> > (db3), apache2 (db4.1), xemacs21(db3), sendmail (db3), KDE (db4.0),

> I'm going to prepare a new NMU in which libsasl-dev has that
> dependency changed to "libdb2-dev | libdb-dev", which should satisfy
> the libtool issue while still allowing libdb4.0-dev, etc.  Hopefully
> because of the versioned symbols in libdb2 this won't result in
> breakage.

Whether or not it results in breakage, it still compounds the
libtool-induced problem of linking against libraries that aren't needed.
If you allow this dependency to be satisfied by any version of
libdb-dev, we may end up with binaries for applications that don't
directly use libdb *at all* being linked against an extraneous version
that happens to be on the system at the time.

A much saner solution would be to simply stop shipping the .la file in
libsasl-dev.  Its only reasonable application on Linux systems is for
static linking, and even there it's a convenience, not a necessity.
Since Debian doesn't ship statically linked binaries (with few
exceptions), and few users are likely to be statically linking libsasl
anyway, I think this is the best choice.  Note that OpenLDAP 2.1
currently uses the .la file (via ltdl_open()) for dynamic loading of
libraries, but I think work is being done to correct this unnecessary
dependency as well.

-- 
Steve Langasek
postmodern programmer


pgpILNayhjeK4.pgp
Description: PGP signature

Suggestions accepted

[Rodrigo Tadeu Claro]

Hello!

I'm going to do it with name gtk-fm.

Thanks.


  .''`.  Rodrigo Tadeu Claro (rlinux)
 : :'  : Debian-SP - irc.freenode.net - #debian-sp
 `. `'`  email - [EMAIL PROTECTED]
   `-www.rodrigoclaro.cjb.net ->> UIN168799234
 --
 Linux User Registered #301748  Debian-BR User #504
 GPGkey ID D33084F2  -->>  http://www.keyserver.net
 Duvidas sobre Debian? Visite o Rau-tu do CIPSGA:
http://rautu.cipsga.org.br

pgpumaai5Fhz6.pgp
Description: PGP signature

100款软件均为注册版，一亿邮址本月结集

[hhggrrrryry]

如果您需要推广自己的产品或信息，敬请耐心阅读。否则，对您说声抱歉！

营销宝典☆☆营销宝典☆☆营销宝典☆☆营销宝典☆☆营销宝典☆☆营销宝典 

  ☆☆ 100元能让你联系亿万家 ☆☆

●●●100元能购买到下列6项：（内含100款软件均为注册版，一亿邮址本月结集）
1.网上搜索软件??据自己的需要搜索"目标客户"的网址和邮址。每小时搜索上万个，比如：搜索深圳的电子公司，只需输入"深圳+电子"，点击"开始"即可。
2.信息发布软件--将产品信息群发至全球几千家中英文交易场所，形成免费的广告效益。3.群发软件??每小时能发送6～8万个E-mail
4.邮址大全??5000万个国内128个行业的分类邮址和5000万个按省和地区分类的邮址。
5.国内33万家各类企业的数据库--显示：公司名称－联系人－联系方式。 
6.每两个月免费索取一次"升级包"。  

以下各项另行计费
●●●2个亿国外邮址（分别按地区和行业分类），5张CD共计180元（赠送上列软件）

●●●企业黄页--《广东省企业黄页》  《深圳企业黄页》  《东莞企业黄页》  
《中山企业黄页》  《佛山企业黄页》  《中国电子厂商名录》   
《深圳地区电子厂商名录》  《东莞地区电子厂商名录》。
企业黄页综合了当地各类企业，企业介绍极为详尽，主营，电话，网页，邮箱等等。可谓看得见的企业。信封打印，网上即时查询，点击发邮，详尽方便。全部8项4张CD共计180元。单购前5项（黄页）130元。

●●●《5～10万个中文网址＋1～2万英文网址＋200款电脑常用软件》分128小类，工作休闲都有用。网址库终生免费升级，永远最新。共一张CD
 40元

★★需要快递加快递费：广东地区10元，以外地区20元，需要票据请注明。

※※以上CD价位，已低至极！议价免问，不诚勿扰，谢谢！※※

★★ 汇款方式：1。请直接将现金存入 :
 开户行：深圳市工商银行泥岗办
 帐 号：4 273011 02966 270
 收款人：李文奇  （一定注意不要填错收款人姓名）
 
2。将汇款单据，购买内容，汇款人地址、姓名、电话，邮编、排列清楚，传真至0755-82489125
  
（请不要通过邮局汇款，款到后我方才能发货，取款手续太麻烦。直接去工行异地存款，当即能查询，当天发货）
 
  ★★ 
以上属本公司兼营的产品，所有内容绝对真实，正规注册公司，票据齐全，承诺有假愿服法律责任。本公司主营各类集成电路（ＩＣ）及科技开发，若有此类需要请来电咨询。
 
  ★ 公司名称：深圳市神硅科技有限公司 
  ★ 公司地址：深圳市泥岗西路1046号鸿颖大厦15楼A
  ★ 咨询电话：0755-82489020 26256569 李生  韩小姐
  ★ 传真：0755-82489125
  [EMAIL PROTECTED]

★ ★只要8元钱，无限期收看看全球电影电视

[没 商量]

★ ★只要8元钱，无限期收看看全球电影电视
　　
　　随着网络的发展，使得网上看电视成为一种可能。相对于普通的电视，网络电视有
其不可以替代的优点：可以欣赏到全球各地区的电视节目。
　　本软件是一款适合宽带网用户在线收看网络电视节目的绿色软件，能够让您在网上
自由的享受看电视的乐趣！
●软件内置全球数百个电视台，任您尽情点播；
●众多外语广播电台，让你领略异国他乡纯正风味，塑造良好的外语学习环境；
●伊拉克战事变幻末测，为您提供第一现场直击；
●商场如战场，股市风云突变，您可随机应变；
●足球赛事精彩，哥们岂容错过；
●数十套音乐节目，让您贴近时尚，紧跟时代潮流。
　　
　　软件统一售价：8元/套。绝对正宗，款到发货，软件安装后自动根据您的计算机配
置形成唯一产品序列号。由本人提供注册码，一次注册，无限期收看。
　　　
[EMAIL PROTECTED]
   QQ:25668868
   产品所在地：上海
   

_
享用世界上最大的电子邮件系统― MSN Hotmail。  http://www.hotmail.com  

Re: Fakeroot to obsolete DESTDIR

[Andrew Suffield]

On Thu, Apr 10, 2003 at 03:38:10PM -0400, Joey Hess wrote:
> Wesley W. Terpstra wrote:
> > 1: libtool cannot relink inter-dependent libraries during a staged install.
> 
> > On the topic of 1, cvs libtool can do this with an undocumented command-line
> > flag. However, it still prefers the installed location over the staged
> > location. So, if you link to -L/.../debian/tmp/usr/lib -lfoo, a libfoo.so in
> > /usr/lib is prefered, which can cause subtle problems. 
> 
> Could you elaborate on what the subtle problems are, exactly?

If you've broken the ABI and haven't changed the soname, things go
wrong. But then, you're fucked anyway. Note that this includes doing
various stupid things with versioned symbols.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgp0MUOhZw1WH.pgp
Description: PGP signature