Should I recommend "less" if I use it in some scripts?

[Number Six]

Some of the scripts I include with my package use "less" (as well as 
"sed", "tr", and "grep").  I know for a fact "less" is not installed by 
default.  (Not sure about this others).

Should every little "ordinary" thing like less be included in my 
Recommends?  It's surely not germane to the package, but if it's not 
there, these little scripts will break.

Re: Should I recommend "less" if I use it in some scripts?

[Michael Koch]

Am Montag, 22. März 2004 10:25 schrieb Number Six:
> Some of the scripts I include with my package use "less" (as well as
> "sed", "tr", and "grep").  I know for a fact "less" is not installed
> by default.  (Not sure about this others).
>
> Should every little "ordinary" thing like less be included in my
> Recommends?  It's surely not germane to the package, but if it's not
> there, these little scripts will break.

You need to depend on "less", a recommends seems not to be enough in 
your case. "coreutils" and "sedutils" are marked "essential" and can be 
exspected on the system.


Michael

Re: Should I recommend "less" if I use it in some scripts?

[Kalle Kivimaa]

Number Six <[EMAIL PROTECTED]> writes:
> Should every little "ordinary" thing like less be included in my 
> Recommends?  It's surely not germane to the package, but if it's not 
> there, these little scripts will break.

If your package needs something that is not Essential you must declare
a Depends to it. See policy 3.5.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *

Re: Should I recommend "less" if I use it in some scripts?

[David Weinehall]

On Mon, Mar 22, 2004 at 01:25:47AM -0800, Number Six wrote:
> Some of the scripts I include with my package use "less" (as well as 
> "sed", "tr", and "grep").  I know for a fact "less" is not installed by 
> default.  (Not sure about this others).
> 
> Should every little "ordinary" thing like less be included in my 
> Recommends?  It's surely not germane to the package, but if it's not 
> there, these little scripts will break.

Why do you need less, wouldn't any pager work?

Refer to 11.4. Editors and pagers


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

Re: Should I recommend "less" if I use it in some scripts?

[Andreas Metzler]

On 2004-03-22 Number Six <[EMAIL PROTECTED]> wrote:
> Some of the scripts I include with my package use "less" (as well as 
> "sed", "tr", and "grep").  I know for a fact "less" is not installed by 
> default.  (Not sure about this others).

> Should every little "ordinary" thing like less be included in my 
> Recommends?  It's surely not germane to the package, but if it's not 
> there, these little scripts will break.

Adapt your scripts to confirm to policy "11.4 Editors and pagers".
   cu andreas

Re: Should I recommend "less" if I use it in some scripts?

[Cosimo Alfarano]

On Mon, Mar 22, 2004 at 01:25:47AM -0800, Number Six wrote:
> Should every little "ordinary" thing like less be included in my 
> Recommends?  It's surely not germane to the package, but if it's not 

Why not use sensible-pager, in debianutils (Essential: yes)?

cheers,
c.

Howto use misc:Depends? [was Re: Should I recommend "less" if I use it in some scripts?]

[Number Six]

On Mon, Mar 22, 2004 at 11:03:58AM +0100, Michael Koch wrote:
> Am Montag, 22. März 2004 10:25 schrieb Number Six:
> > Some of the scripts I include with my package use "less" (as well as
> > "sed", "tr", and "grep").  I know for a fact "less" is not installed
> > by default.  (Not sure about this others).
> >
> > Should every little "ordinary" thing like less be included in my
> > Recommends?  It's surely not germane to the package, but if it's not
> > there, these little scripts will break.
> 
> You need to depend on "less", a recommends seems not to be enough in 
> your case. "coreutils" and "sedutils" are marked "essential" and can be 
> exspected on the system.
> 

Okay.  The dh-make generated control file has:
Depends: ${shlibs:Depends}, ${misc:Depends}

shlibs:Depends is being populated properly, misc:Depends is currently
not being used:

dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}

I would prefer to have "less" be picked up by misc:Depends, I guess,
rather than explicitly adding it to the Depends line.

How can I do that?  Or should I just remove misc:Depends and explicitly
add it?

Should I always clean in debian/rules before making binary?

[Number Six]

I have an automake project that I've also run dh_make on.

If I just run: ./configure, the default {prefix} is "/usr/local",
which is the way I want it.

If I then run "fakeroot debian/rules binary", the binary debian package 
will install itself to /usr/local.

If I "make clean; fakeroot debian/rules binary", the package will 
install itself to /usr, which is right for debian.

Should I do something in debian/rules to make sure the binary always 
goes to /usr, or this flexiblity desirable?  It sure seems like 
"unexpected behavior" to me.

Re: Development packages.

[Adrian 'Dagurashibanipal' von Bidder]

On Sunday 21 March 2004 20.49, Stephen Frost wrote:

> .la files shouldn't be included in anything, they're just plain broken.

940 .la files on my system. Report bugs?

/usr/lib/rep/...
/usr/lib/libkabc_ldapkio.la
/usr/lib/libesd.la
/usr/lib/libkwireless.la
usr/lib/gimp/1.3/modules/...
/usr/lib/kde3/...

So either you don't mean that absolutely, or three's a few buggy packages out 
there.

-- vbi



-- 
It's not a bug; it's an undocumented feature.


pgpC8VE8p8uGf.pgp
Description: signature

Re: Development packages.

[Stephen Frost]

* Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote:
> On Sunday 21 March 2004 20.49, Stephen Frost wrote:
> 
> > .la files shouldn't be included in anything, they're just plain broken.
> 
> 940 .la files on my system. Report bugs?
[...]
> So either you don't mean that absolutely, or three's a few buggy packages out 
> there.

It's the glorious brokenness that is libtool.  Basically, libtool needs
to be fixed to not use the stupid things on systems that don't need them
(like, oh, all of Debian).  I don't know that filing bug reports would
be useful until libtool is fixed because I imagine most maintainers who
havn't actually run into the problems caused by .la files will just
whine "libtool did it".

Stephen


signature.asc
Description: Digital signature

Re: Should I always clean in debian/rules before making binary?

[Frank Küster]

Number Six <[EMAIL PROTECTED]> schrieb:

> I have an automake project that I've also run dh_make on.
>
> If I just run: ./configure, the default {prefix} is "/usr/local",
> which is the way I want it.
>
> If I then run "fakeroot debian/rules binary", the binary debian package 
> will install itself to /usr/local.
>
> If I "make clean; fakeroot debian/rules binary", the package will 
> install itself to /usr, which is right for debian.
>
> Should I do something in debian/rules to make sure the binary always 
> goes to /usr, or this flexiblity desirable?  It sure seems like 
> "unexpected behavior" to me.

- I think you should call ./configure --prefix=/usr/ in debian/rules -
  in some target that binary depends on (e.g. a configure or build
  target). 

- In the install target, you would call something like

  $(MAKE) install prefix=debian/tmp/usr

- From a policy point of view, it doesn't hurt to call clean before
  debian/rules binary, but if you do that, I'd do it in debian/rules,
  not by hand. However, I recommend not to do it. It makes it much
  easier to test changes in your installation procedure, postinst
  etc. You can simply wipe out the package tree under debian/ and call
  fakeroot debian/rules binary, and then it won't need to configure and
  compile everything, but just start installing.

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: Howto use misc:Depends? [was Re: Should I recommend "less" if I use it in some scripts?]

[Colin Watson]

On Mon, Mar 22, 2004 at 02:37:48AM -0800, Number Six wrote:
> I would prefer to have "less" be picked up by misc:Depends, I guess,
> rather than explicitly adding it to the Depends line.

No, you should add it explicitly; misc:Depends belongs to debhelper.
However, I agree that you should refer to policy and use the
sensible-pager system instead.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Should I always clean in debian/rules before making binary?

[Colin Watson]

On Mon, Mar 22, 2004 at 03:19:55PM +0100, Frank Küster wrote:
> - In the install target, you would call something like
> 
>   $(MAKE) install prefix=debian/tmp/usr

It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is
available; that way you get less confused by /etc.

> - From a policy point of view, it doesn't hurt to call clean before
>   debian/rules binary, but if you do that, I'd do it in debian/rules,
>   not by hand. However, I recommend not to do it.

I'd call it a bug to do that. I believe the buildds, and certainly
dpkg-buildpackage, do something morally equivalent to 'debian/rules
build && fakeroot debian/rules binary'.

Use dpkg-buildpackage (or debuild, a wrapper around it which sorts out
fakeroot and the like) rather than 'debian/rules binary'.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Development packages.

[Frank Küster]

Stephen Frost <[EMAIL PROTECTED]> schrieb:

> * Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote:
>> On Sunday 21 March 2004 20.49, Stephen Frost wrote:
>> 
>> > .la files shouldn't be included in anything, they're just plain broken.
>> 
>> 940 .la files on my system. Report bugs?
> [...]
>> So either you don't mean that absolutely, or three's a few buggy packages 
>> out 
>> there.
>
> It's the glorious brokenness that is libtool.  Basically, libtool needs
> to be fixed to not use the stupid things on systems that don't need them
> (like, oh, all of Debian).  I don't know that filing bug reports would
> be useful until libtool is fixed because I imagine most maintainers who
> havn't actually run into the problems caused by .la files will just
> whine "libtool did it".

Yes, it did :-|. Could you point me to a documentation where I could
read about these problems, and under what weird circumstances it will be
a bug nevertheless if I don't install the *la files? 

I'm asking because - hm, well - in the NM process I promised not to
package a library soon, and now a month later I have write access to
tetex-bin's cvs. And libkpathsea is going to switch from its own hacked
libtool to the standard one, including all standard errors...

TIA, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

updating gdal library

[Silke Reimer]

Hallo!

I am the maintainer of gdal and since a new upstream version is
available I want to build a new pacakge. Now I have the following
problems:

First I don't know how to fill the Depends for libgdal1-dev
correctly.
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#AEN75
explains the following:

"""
The -dev package should depend on all -dev packages for libraries
that the library package depends upon, with the specific (so)version
that the library package is linked against. This includes libc-dev.
"""

The problem for my package is that it depends on different
library-versions depending on the architecture it is built on. So I
would like to create those dev-dependencies automatically.
I tried d-devlibdeps (which is part of the  package d-shlibs) but
this didn't find a few of the necessary dev-packages:


mimirs gdal-1.2.0 522: d-devlibdeps debian/libgdal1-dev.substvar
debian/libgdal1/usr/lib/libgdal.so.1.2.0
 --> libc6-dev package exists.
devlibs error: There is no package matching [libcfitsio2-dev] and
noone provides it, please report bug to d-shlibs maintainer
devlibs error: There is no package matching [libdf4-dev] and noone
provides it, please report bug to d-shlibs maintainer
 --> libjpeg62-dev package exists.
devlibs error: There is no package matching [libmfhdf4-dev] and
noone provides it, please report bug to d-shlibs maintainer
devlibs error: There is no package matching [libodbc1-dev] and noone
provides it, please report bug to d-shlibs maintainer
 --> libpng12-0-dev is provided by a package.
devlibs error: There is no package matching [libpq3-dev] and noone
provides it, please report bug to d-shlibs maintainer
 --> libstdc++5-dev package exists.
 --> libungif4-dev package exists.
devlibs error: There is no package matching [libxerces-c21-dev] and
noone provides it, please report bug to d-shlibs maintainer
 --> zlib1g-dev package exists.
-

Do you have any ideas?


The second questions is concerning the fields 'replaces',
'conflicts' etc. of libgdal1-dev. Currently they contain:

 Depends: libgdal1 (= 1.2.0-1)
 Suggests: libgdal-doc
 Conflicts: libgdal-dev, libgdal1 (<< 1.2.0-1)
 Replaces: libgdal1 (<< 1.2.0-1)
 Provides: libgdal-dev

Thus the  old libgdal1 will be removed and the current libgdal1
installed when libgdal1-dev is updated. Otherwise there are other
package that depend on special versions of libgdal1 i.e. gdal-bin.
Thus libgdal1 will not be removed by an update of libgdal1-dev. Do
have any suggestions how I can solve this conflict?

Many thanks,

Silke

-- 
Silke Reimer

Intevation GmbH  http://intevation.de/
FreeGIShttp://freegis.org/



pgpkhrJ40atXB.pgp
Description: PGP signature

Re: updating gdal library

[Andreas Metzler]

On Mon, Mar 22, 2004 at 04:39:19PM +0100, Silke Reimer wrote:
> First I don't know how to fill the Depends for libgdal1-dev
> correctly.
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#AEN75
> explains the following:
> 
>   """
>   The -dev package should depend on all -dev packages for libraries
>   that the library package depends upon, with the specific (so)version
>   that the library package is linked against. This includes libc-dev.
>   """
[...]

This is bogus. The Depends should list the -dev packages that are
needed for linking against your library (basically if libgal's header
files include header files from other packages you should depend on
this packages)
   cu andreas

Re: Should I always clean in debian/rules before making binary?

[Frank Küster]

Colin Watson <[EMAIL PROTECTED]> schrieb:

> On Mon, Mar 22, 2004 at 03:19:55PM +0100, Frank Küster wrote:
>> - In the install target, you would call something like
>> 
>>   $(MAKE) install prefix=debian/tmp/usr
>
> It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is
> available; that way you get less confused by /etc.

Ah, you're right. The last package I prepared from scratch doesn't
install anything into /etc anyway, and my only alone-maintained package
uses it. 

Hm, how do I know (other by trial and error) whether a package supports
this? autoconf'iscated ones do not use it generally, do they?

>> - From a policy point of view, it doesn't hurt to call clean before
>>   debian/rules binary, but if you do that, I'd do it in debian/rules,
>>   not by hand. However, I recommend not to do it.
>
> I'd call it a bug to do that. I believe the buildds, and certainly
> dpkg-buildpackage, do something morally equivalent to 'debian/rules
> build && fakeroot debian/rules binary'.

Didn't think about buildds. Only about human ones, also called
maintainer_in_debugging_building_cycle. 
>
> Use dpkg-buildpackage (or debuild, a wrapper around it which sorts out
> fakeroot and the like) rather than 'debian/rules binary'.

The last is a remark to the OP's question, not to me, right? Because
that's what I meant: Don't make binary depend on clean, because it
enables you to delete exactly what you want and then run the binary
target, and dpkg-buildpackage will run clean, anyway.

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Spam mail warning notification! (Subject check wicked screen saver your account)

[spamcontrol]

 eManager Notification *

The following mail was blocked since it contains sensitive content.

Source mailbox: 
Destination mailbox(es): [EMAIL PROTECTED]
Policy: Subject check  wicked screen saver  your account
Action: Quarantine

Subject is similar to one caused by virus.  Please change and try again.

*** End of message *
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1B5RfJ-0003EE-00
for ietf@ietf.org; Mon, 22 Mar 2004 10:48:37 -0500
Received: from venera.isi.edu ([128.9.176.32])
by ietf-mx with esmtp (Exim 4.12)
id 1B5ReO-00036X-00
for ietf@ietf.org; Mon, 22 Mar 2004 10:47:40 -0500
Received: from venera.isi.edu (dijon-1-62-147-69-195.dial.proxad.net 
[62.147.69.195])
by venera.isi.edu (8.9.3/8.9.3) with ESMTP id HAA24489
for <[EMAIL PROTECTED]>; Mon, 22 Mar 2004 07:44:56 -0800 (PST)
From: debian-mentors@lists.debian.org
Message-Id: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: approved
Date: Mon, 22 Mar 2004 16:47:14 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_NextPart_000_0016=_NextPart_000_0016"
X-Priority: 3
X-MSMail-Priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
ietf-mx.ietf.org
X-Spam-Status: No, hits=2.4 required=5.0 tests=MIME_BOUND_NEXTPART,
MISSING_MIMEOLE,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no 
version=2.60

Re: Should I always clean in debian/rules before making binary?

[Bob Proulx]

Frank Küster wrote:
> Colin Watson <[EMAIL PROTECTED]> schrieb:
> > It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is
> > available; that way you get less confused by /etc.
> [..]
> Hm, how do I know (other by trial and error) whether a package supports
> this? autoconf'iscated ones do not use it generally, do they?

Older automake generated Makefiles do not support DESTDIR.  But newer
automake generated Makefiles do support it.  I don't know at what
version that support was enabled.  But if the tool uses a new automake
to generate the files or if you happen to regenerate them then you
should have DESTDIR support.

There appear to be three cases.

1. The developer wrote the Makefiles by hand and did not supply any
   support for DESTDIR natively.

2. The developer used automake and therefore supports DESTDIR by
   default.

3. The developer used automake but also supplied additional Makefile
   sections by hand and those additional sections do not support
   DESTDIR.  So it is partially there but not fully functional now.

That last one happens every so often.  I found and reported one in
gettext just recently (which was promptly fixed by upstream).  But
those are the hardest to detect without actually trying.

Trial and error is probably the easiest method.

Bob


pgpOFWFs3v7EH.pgp
Description: PGP signature

Re: Should I always clean in debian/rules before making binary?

[elijah wright]

frank, can i beg you to doublecheck the way your last name is encoded in
your email client?  it corrupts the screen state in pine EVERY time i get
one of your email messages...  mutt doesn't get corrupted, but it shows me
a big fat questionmark instead of the letter between "K" and "s" in your
last name... i see that your mails are coming across as latin-1 encoded -
is whatever the second letter of your name is really in that charset?

alternatively, can someone suggest a solution to the screen corruption?  i
think what might be happening is that the letter in question is taking two
cells on the screen instead of the ONE that it should take up...


 thanks,

elijah



On Mon, 22 Mar 2004, Frank Küster wrote:

> Date: Mon, 22 Mar 2004 17:03:44 +0100
> From: Frank Küster <[EMAIL PROTECTED]>
> To: debian-mentors@lists.debian.org
> Subject: Re: Should I always clean in debian/rules before making binary?
> Resent-Date: Mon, 22 Mar 2004 10:08:24 -0600 (CST)
> Resent-From: debian-mentors@lists.debian.org
>
> Colin Watson <[EMAIL PROTECTED]> schrieb:
>
> > On Mon, Mar 22, 2004 at 03:19:55PM +0100, Frank Küster wrote:
> >> - In the install target, you would call something like
> >>
> >>   $(MAKE) install prefix=debian/tmp/usr
> >
> > It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is
> > available; that way you get less confused by /etc.
>
> Ah, you're right. The last package I prepared from scratch doesn't
> install anything into /etc anyway, and my only alone-maintained package
> uses it.
>
> Hm, how do I know (other by trial and error) whether a package supports
> this? autoconf'iscated ones do not use it generally, do they?
>
> >> - From a policy point of view, it doesn't hurt to call clean before
> >>   debian/rules binary, but if you do that, I'd do it in debian/rules,
> >>   not by hand. However, I recommend not to do it.
> >
> > I'd call it a bug to do that. I believe the buildds, and certainly
> > dpkg-buildpackage, do something morally equivalent to 'debian/rules
> > build && fakeroot debian/rules binary'.
>
> Didn't think about buildds. Only about human ones, also called
> maintainer_in_debugging_building_cycle.
> >
> > Use dpkg-buildpackage (or debuild, a wrapper around it which sorts out
> > fakeroot and the like) rather than 'debian/rules binary'.
>
> The last is a remark to the OP's question, not to me, right? Because
> that's what I meant: Don't make binary depend on clean, because it
> enables you to delete exactly what you want and then run the binary
> target, and dpkg-buildpackage will run clean, anyway.
>
> Regards, Frank
>

Re: Development packages.

[Andreas Metzler]

On Mon, Mar 22, 2004 at 04:26:49PM +0100, Frank Küster wrote:
> Stephen Frost <[EMAIL PROTECTED]> schrieb:
> > * Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote:
> >> On Sunday 21 March 2004 20.49, Stephen Frost wrote:
> >> 
> >> > .la files shouldn't be included in anything, they're just plain broken.
> >> 
> >> 940 .la files on my system. Report bugs?
> > [...]
> >> So either you don't mean that absolutely, or three's a few buggy
> >> packages out there.

> > It's the glorious brokenness that is libtool.  Basically, libtool needs
> > to be fixed to not use the stupid things on systems that don't need them
> > (like, oh, all of Debian).  I don't know that filing bug reports would
> > be useful until libtool is fixed because I imagine most maintainers who
> > havn't actually run into the problems caused by .la files will just
> > whine "libtool did it".
 
> Yes, it did :-|. Could you point me to a documentation where I could
> read about these problems, and under what weird circumstances it will be
> a bug nevertheless if I don't install the *la files? 
[...]

Hello,
Basically the essence of the mess is #191425. If libfoo links against
libbar and application blah makes use of libfoo (but does not use
libbar) libtool will link the application against both libraries.

This is not necessary for dynamic linking on reasonably unbroken
platforms like GNU/Linux and complicates matters a lot:

Dependencies are immensly bloated. For example check the
dependencies of ghex (a simple Hex-Editor). It links directly
against libtasn1-0 although it sure as hell does not parse ASN
certificates. This can make make migration to testing a lot more
painful.

Now, if libfoo is replaced by libfoo2 and libbar is rebuilt against it
the application blah sudenly links against both libfoo2 and libfoo. If
these libraries do not use versioned symbols you'll get symbol clashes
and segmentation faults.

Now libtool gets this information (libfoo links against libbar) from
the .la file, if you do not ship it, libtool cannot be that stupid and
link against all these dependcies. - The price you pay for that is
that _static_ linking does require following these dependency chains.

Personally I think the payoff is ok, due to dlopen in glibc (NSS,
iconv) static linking is unreliable anyway.

If you want to see a nice example for the results of this bug, check
e.g.  apt-cache showpkg  libtasn1-0 and ask yourself how many of these
packages really should link against it.
cu andreas
PS: Be aware that I do not maintain a library myself, I have just 
done one or two NMUs and have followed discussions on the issue.
PPS: I gather that pkgconfig is also broken.

Re: updating gdal library

[Silke Reimer]

On Mon, Mar 22, 2004 at 04:49:51PM +0100, Andreas Metzler wrote:
> On Mon, Mar 22, 2004 at 04:39:19PM +0100, Silke Reimer wrote:
> > First I don't know how to fill the Depends for libgdal1-dev
> > correctly.
> > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#AEN75
> > explains the following:
> > 
> > """
> > The -dev package should depend on all -dev packages for libraries
> > that the library package depends upon, with the specific (so)version
> > that the library package is linked against. This includes libc-dev.
> > """
> [...]
> 
> This is bogus. The Depends should list the -dev packages that are
> needed for linking against your library (basically if libgal's header
> files include header files from other packages you should depend on
> this packages)

Thanks. This is more sensible and now it is not that difficult to
provide the *-dev's on the Depends: field. 


Silke

-- 
Silke Reimer

Intevation GmbH  http://intevation.de/
FreeGIShttp://freegis.org/



pgpmK0UzGLWcN.pgp
Description: PGP signature

Re: Should I always clean in debian/rules before making binary?

[Kalle Kivimaa]

elijah wright <[EMAIL PROTECTED]> writes:
> frank, can i beg you to doublecheck the way your last name is encoded in
> your email client?  it corrupts the screen state in pine EVERY time i get
> one of your email messages...  mutt doesn't get corrupted, but it shows me
> a big fat questionmark instead of the letter between "K" and "s" in your
> last name... i see that your mails are coming across as latin-1 encoded -
> is whatever the second letter of your name is really in that charset?

Current SMTP standards do not allow anything else except 7-bit ASCII
in the headers. Thus the MUA should convert any 8-bit characters to
the special header MIME encoding when sending and of course manage to
convert the MIME information back. This mail _should_ demonstrate
that, unless my Gnus surprises me.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *

Re: Development packages.

[Frank Küster]

Andreas Metzler <[EMAIL PROTECTED]> wrote:

> Basically the essence of the mess is #191425. If libfoo links against
> libbar and application blah makes use of libfoo (but does not use
> libbar) libtool will link the application against both libraries.

[...]
O.k., understood.

> Now libtool gets this information (libfoo links against libbar) from
> the .la file, if you do not ship it, libtool cannot be that stupid and
> link against all these dependcies. - The price you pay for that is
> that _static_ linking does require following these dependency chains.

Also o.k.

> Personally I think the payoff is ok, due to dlopen in glibc (NSS,
> iconv) static linking is unreliable anyway.

This I don't understand. What is the relation between dlopen calls and
static linking? For sure a statically linked binary won't use dlopen,
and if it's a different one, what's the problem?

TIA, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: Should I always clean in debian/rules before making binary?

[Frank Küster]

elijah wright <[EMAIL PROTECTED]> schrieb:

> frank, can i beg you to doublecheck the way your last name is encoded in
> your email client? 

As I see it, it is

From: =?iso-8859-1?q?Frank_K=FCster?= <[EMAIL PROTECTED]>

Although I'd prefer

From: Frank =?iso-8859-1?q?K=FCster?= <[EMAIL PROTECTED]>

(that was handmade, may be incorrect), I don't see what else I could do
about this (except writing Kuester, but that is _not_ my name).

> alternatively, can someone suggest a solution to the screen corruption?  i
> think what might be happening is that the letter in question is taking two
> cells on the screen instead of the ONE that it should take up...

Or do you meant the message _body_? I would be surprised if pine and
mutt couldn't cope with 

Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

> On Mon, 22 Mar 2004, Frank Küster wrote:

Could it be that this isn't a problem of pine or mutt, but because of
missing fonts in your installation? Because my name looks quite well in
your citation.

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Character encoding (was: Should I always clean...)

[Matt Brubeck]

elijah wright <[EMAIL PROTECTED]> schrieb:

> alternatively, can someone suggest a solution to the screen
> corruption?  i think what might be happening is that the letter in
> question is taking two cells on the screen instead of the ONE that
> it should take up...

It sounds like Pine is sending characters in UTF-8 and your terminal
emulation program is interpreting them in a single-byte character set,
or vice-versa.

Re: Should I always clean in debian/rules before making binary?

[Rene Engelhard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[ read http://learn.to.quote ]

Hi,

elijah wright wrote:
> frank, can i beg you to doublecheck the way your last name is encoded in
> your email client?  it corrupts the screen state in pine EVERY time i get
> one of your email messages...  mutt doesn't get corrupted, but it shows me
> a big fat questionmark instead of the letter between "K" and "s" in your
> last name... i see that your mails are coming across as latin-1 encoded -
> is whatever the second letter of your name is really in that charset?

Yes, the ü is as every german umlaut in latin-1.

> alternatively, can someone suggest a solution to the screen corruption?  i
> think what might be happening is that the letter in question is taking two
> cells on the screen instead of the ONE that it should take up...

don't use pine? :)
i
Grüße/Regards,

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

iD8DBQFAXyXK+FmQsCSK63MRApDrAJ9izysSXYWWH9r8v20eBhdBvdFqPwCfdFyb
CwKbmX6hXZYyXQtFP7KuUbo=
=uVfK
-END PGP SIGNATURE-

Re: Development packages.

[Andreas Metzler]

On Mon, Mar 22, 2004 at 06:28:43PM +0100, Frank Küster wrote:
> Andreas Metzler <[EMAIL PROTECTED]> wrote:
[...] 
> > Personally I think the payoff is ok, due to dlopen in glibc (NSS,
> > iconv) static linking is unreliable anyway.

> This I don't understand. What is the relation between dlopen calls and
> static linking? For sure a statically linked binary won't use dlopen,

It does.

> and if it's a different one, what's the problem?

The problem is that dlopen()ed stuffed is not linked and therefore not
pulled in by static linking. - If you link static against glibc 2.2
and execute the program on a system using glibc 2.3 the NSS/iconv
modules from the new version are used which might be incompatible.

See http://bugs.debian.org/193310

The comment at the top of the mail is too broad, static linking
against chosen libraries whih don't use dlopen works.
cu andreas

Re: Development packages.

[Roger Leigh]

Stephen Frost <[EMAIL PROTECTED]> writes:

> We shouldn't be recommending providing staticlly linked libs for people
> to use, even in the 'fast moving' case- if it's that fast then it
> probably shouldn't be in Debian and that's just life.
>
> .la files shouldn't be included in anything, they're just plain broken.

Even with static libraries?  The .la does contain dependency
information.  I know that using pkg-config .pc files can eliminate
this case, but not everything using libtool is using pkg-config yet.


-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Re: Development packages.

[Stephen Frost]

* Roger Leigh ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > We shouldn't be recommending providing staticlly linked libs for people
> > to use, even in the 'fast moving' case- if it's that fast then it
> > probably shouldn't be in Debian and that's just life.
> >
> > .la files shouldn't be included in anything, they're just plain broken.
> 
> Even with static libraries?  The .la does contain dependency
> information.  I know that using pkg-config .pc files can eliminate
> this case, but not everything using libtool is using pkg-config yet.

We shouldn't be shipping or using static libraries.

Stephen


signature.asc
Description: Digital signature

Re: Development packages.

[Matt Brubeck]

Stephen Frost wrote:

> We shouldn't be shipping or using static libraries.

Why not?  I know we shouldn't be linking to static libraries in our
packaged software, but having the static libraries available is
important for some end-users and local administrators.

Debian Policy section 8.3 says,

  The static library (libraryname.a) is usually provided in addition
  to the shared version. It is placed into the development package
  (see below).

Re: Development packages.

[Stephen Frost]

* Matt Brubeck ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > We shouldn't be shipping or using static libraries.
> 
> Why not?  I know we shouldn't be linking to static libraries in our
> packaged software, but having the static libraries available is
> important for some end-users and local administrators.

Pffft.  Honestly, I think that claim of end-users and local
administrators using static libraries is rather dated and rarely the
case these days.  Regardless, we shouldn't be using them and the end
users and local admins who actually need to link against things
statically can figure out the dependencies.

Stephen


signature.asc
Description: Digital signature

Re: Development packages.

[Bernhard R. Link]

* Stephen Frost <[EMAIL PROTECTED]> [040322 21:14]:
> Pffft.  Honestly, I think that claim of end-users and local
> administrators using static libraries is rather dated and rarely the
> case these days.  

I do not know, if they are used to make any programs intended for 
production use any more, though I often found them very helpfull 
when debugging things.
Having to recompile whole libraries just to locate some of those
ugly pointer-address relatated bugs makes those assembler near
languages like C and friends much more a pain than it has to be.

Hochachtungsvoll,
  Bernhard R. Link

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

Re: Should I always clean in debian/rules before making binary?

[Kalle Kivimaa]

Frank Küster <[EMAIL PROTECTED]> writes:
> As I see it, it is
> From: =?iso-8859-1?q?Frank_K=FCster?= <[EMAIL PROTECTED]>

Yes, that's how I see it as well. My previous reply was based on the
fact that my Gnus surprised me by showing the From-field correctly, if
it is encoded, but NOT showing To, CC or Subject-lines...

So it seems that Frank is doing everything correctly, so there is
either an installation problem at the other end or a bug in Pine.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *

Re: Development packages.

[Steve Langasek]

On Sun, Mar 21, 2004 at 08:18:35PM +, Roger Leigh wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:

> > We shouldn't be recommending providing staticlly linked libs for people
> > to use, even in the 'fast moving' case- if it's that fast then it
> > probably shouldn't be in Debian and that's just life.

> > .la files shouldn't be included in anything, they're just plain broken.

> Even with static libraries?  The .la does contain dependency
> information.  I know that using pkg-config .pc files can eliminate
> this case, but not everything using libtool is using pkg-config yet.

pkg-config is a *far* worse offender than libtool.  With libtool, we
have some hope of getting these things right in the near future;
pkg-config, OTOH, doesn't even know there *is* a difference between
static and shared libs, so can't be taught to handle them differently
without a lot of growing pains.  Please don't add pkg-config to packages
that don't already have the misfortune of using it!

In general, while policy does require us to ship static libraries, it
does not require shipping .la files to go with them.  If there's a
choice to be made between having a brittle shared library dependency
tree in Debian and having static library users complaining that they
have to link by hand, I know which way I'm gonna vote.  However, with
the pending libtool cleanups (our libtool maintainer is actively
involved with addressing precisely these issues upstream), it should
soon no longer be necessary to make such a choice.

But shipping .la files in non-dev packages should still be a hanging
offense.

Cheers,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Development packages.

[Scott James Remnant]

On Sun, 2004-03-21 at 19:49, Stephen Frost wrote:

> We shouldn't be recommending providing staticlly linked libs for people
> to use, even in the 'fast moving' case- if it's that fast then it
> probably shouldn't be in Debian and that's just life.
> 
> .la files shouldn't be included in anything, they're just plain broken.
> 
Please note that Stephen is talking complete bollocks here and clearly
has little to no understanding of libraries.

If you are creating a library package, you should ship the shared
library (and SONAME symlink) in the libxxxN package and the static
library, name-only symlink *AND* .la file (if relevant) in the
libxxx[N]-dev package.


The "broken"ness he's referring to is that Libtool will link all the
dependency libraries of a library to a program:

libAlibB
   \/
libC

If you link "app" to "libC" with Libtool, app will be linked to libA,
libB and libC.

This is a requirement for most platforms, Linux is fairly unique in that
its dynamic link loader is able to process dependency trees itself and
load the dependencies of a linked library.

In user terms, this has zero effect; the dependency libraries need to
loaded *anyway* so loading them earlier actually *slightly* speeds up
load times of complex apps (esp. Mozilla and friends).


In Debian terms, it's slightly annoying; our "shlibs" tools don't
realise what's going on and suggest more dependencies than are strictly
necessary.  It can also cause annoyances during SONAME changes of
libraries deep in the dependency stack.

There's already a fix for Libtool to ignore dependency_libs when linking
shared libraries on Linux and the next major release should have it.


The .la files then simply convey the required dependencies when linking
a static library, which even on Linux requires you to link in all the
dependencies manually.

This user links statically a hell of a lot when debugging code; I assume
I'm not the only one either.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



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

Re: Development packages.

[Scott James Remnant]

On Mon, 2004-03-22 at 21:29, Steve Langasek wrote:

> On Sun, Mar 21, 2004 at 08:18:35PM +, Roger Leigh wrote:
> > Stephen Frost <[EMAIL PROTECTED]> writes:
> 
> > > We shouldn't be recommending providing staticlly linked libs for people
> > > to use, even in the 'fast moving' case- if it's that fast then it
> > > probably shouldn't be in Debian and that's just life.
> 
> > > .la files shouldn't be included in anything, they're just plain broken.
> 
> > Even with static libraries?  The .la does contain dependency
> > information.  I know that using pkg-config .pc files can eliminate
> > this case, but not everything using libtool is using pkg-config yet.
> 
> pkg-config is a *far* worse offender than libtool.  With libtool, we
> have some hope of getting these things right in the near future;
> pkg-config, OTOH, doesn't even know there *is* a difference between
> static and shared libs, so can't be taught to handle them differently
> without a lot of growing pains.  Please don't add pkg-config to packages
> that don't already have the misfortune of using it!
> 
I've got half a mind, if pkg-config upstream haven't shown any signs of
activity once I've finished fighting my current battles to start
developing it further myself.

Giving it some idea of what's a dependency library and what's a 2nd (or
even 3rd) level dependency would be nice, along with some "I'm linking
statically" and "I'm cross-compiling" logic.

Maybe even make it play nice with Libtool.

> But shipping .la files in non-dev packages should still be a hanging
> offense.
> 
Plugins using libltdl probably need them ... though not until some of
the more exotic ports come to fruition.

"Debian Solaris" anyone? :o)

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



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

Re: Development packages.

[Roger Leigh]

Stephen Frost <[EMAIL PROTECTED]> writes:

> * Matt Brubeck ([EMAIL PROTECTED]) wrote:
>> Stephen Frost wrote:
>> > We shouldn't be shipping or using static libraries.
>> 
>> Why not?  I know we shouldn't be linking to static libraries in our
>> packaged software, but having the static libraries available is
>> important for some end-users and local administrators.
>
> Pffft.  Honestly, I think that claim of end-users and local
> administrators using static libraries is rather dated and rarely the
> case these days.

I used a statically-linked binary just a few days ago.  I needed to
resize an NTFS partition on a newly-delivered system which came with
Windows XP.  In the event, I was able to get a statically linked
binary, copy it onto a floppy and run this after booting from a rescue
disk.

So, it's very useful for rescue situations, where you can't rely on a
whole suite of shared libs, or any installation at all.

It's also useful when you want to provide something that "just work"
with no extra dependencies.  While proprietary/commercial software was
the biggest user of this, it's also useful for free software.  What if
Joe Average would like to run my program which makes use of libstdc++,
GTK+ 2.2 and GNOME 2.4?  It's the least hassle way to achieve this.

> Regardless, we shouldn't be using them and the end
> users and local admins who actually need to link against things
> statically can figure out the dependencies.

Since nearly all -dev packages come with static libs and this is not
forbidded (it's mentioned in Policy) I won't stop using them.  I'll by
happy to stop as soon as Policy forbids/discourages it.


On a related note, I'd also be very happy if it was a requirement to
build libraries with a miniumum of "-g -ggdb -gdwarf-2", and not strip
them.  We could provide some mechanism to automatically strip
binaries, surely?


-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Re: Development packages.

[Roger Leigh]

Andreas Metzler <[EMAIL PROTECTED]> writes:

> On Mon, Mar 22, 2004 at 04:26:49PM +0100, Frank Küster wrote:

[libtool brokenness]
>> Yes, it did :-|. Could you point me to a documentation where I could
>> read about these problems, and under what weird circumstances it will be
>> a bug nevertheless if I don't install the *la files? 
> [...]
>
> Hello,
> Basically the essence of the mess is #191425. If libfoo links against
> libbar and application blah makes use of libfoo (but does not use
> libbar) libtool will link the application against both libraries.

How is this different to pkg-config:

$ pkg-config --libs libglademm-2.0
-Wl,--export-dynamic -lglademm-2.0 -lgtkmm-2.0 -lglade-2.0 -lgdkmm-2.0
 -latkmm-1.0 -lpangomm-1.0 -lglibmm-2.0 -lsigc-1.2 -lgtk-x11-2.0
 -lxml2 -lpthread -lz -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0
 -ldl -lglib-2.0

Whew!  Yet in reality, -lglademm-2.0 would have sufficed...


-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Re: Development packages.

[Steve Langasek]

On Mon, Mar 22, 2004 at 09:59:34PM +, Scott James Remnant wrote:
> > pkg-config is a *far* worse offender than libtool.  With libtool, we
> > have some hope of getting these things right in the near future;
> > pkg-config, OTOH, doesn't even know there *is* a difference between
> > static and shared libs, so can't be taught to handle them differently
> > without a lot of growing pains.  Please don't add pkg-config to packages
> > that don't already have the misfortune of using it!

> I've got half a mind, if pkg-config upstream haven't shown any signs of
> activity once I've finished fighting my current battles to start
> developing it further myself.

> Giving it some idea of what's a dependency library and what's a 2nd (or
> even 3rd) level dependency would be nice, along with some "I'm linking
> statically" and "I'm cross-compiling" logic.

From what I can tell, the .pc files already contain enough information
to distinguish between direct and indirect dependencies.

> > But shipping .la files in non-dev packages should still be a hanging
> > offense.

> Plugins using libltdl probably need them ... though not until some of
> the more exotic ports come to fruition.

> "Debian Solaris" anyone? :o)

How about if we just not allow ports of Debian based on such
bass-ackwards linkers?  Just because upstreams feel obligated to support
every stone age library implementation available doesn't mean Debian
should.  Tolerating such known-buggy designs would erode one of Debian's
greatest strengths as a platform.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Development packages.

[Scott James Remnant]

On Mon, 2004-03-22 at 22:15, Steve Langasek wrote:
> On Mon, Mar 22, 2004 at 09:59:34PM +, Scott James Remnant wrote:
> > > But shipping .la files in non-dev packages should still be a hanging
> > > offense.
> 
> > Plugins using libltdl probably need them ... though not until some of
> > the more exotic ports come to fruition.
> 
> > "Debian Solaris" anyone? :o)
> 
> How about if we just not allow ports of Debian based on such
> bass-ackwards linkers?
> 
Are you listening Robert Millan? :-)

(I'm actually not convinced the BSD linker can do full-depth dependency
trees.)

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



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

Re: Development packages.

[Stephen Frost]

* Roger Leigh ([EMAIL PROTECTED]) wrote:
> I used a statically-linked binary just a few days ago.  I needed to
> resize an NTFS partition on a newly-delivered system which came with
> Windows XP.  In the event, I was able to get a statically linked
> binary, copy it onto a floppy and run this after booting from a rescue
> disk.
>
> So, it's very useful for rescue situations, where you can't rely on a
> whole suite of shared libs, or any installation at all.

Boot Knoppix or similar from a CD.  PCs today are more often installed
with CDs than floppies anyway.  That's really a pretty poor reason.

> It's also useful when you want to provide something that "just work"
> with no extra dependencies.  While proprietary/commercial software was
> the biggest user of this, it's also useful for free software.  What if
> Joe Average would like to run my program which makes use of libstdc++,
> GTK+ 2.2 and GNOME 2.4?  It's the least hassle way to achieve this.

Joe Average installs Debian which *handles* all of the dependencies.
Come on, this isn't even a reason to keep them.

> > Regardless, we shouldn't be using them and the end
> > users and local admins who actually need to link against things
> > statically can figure out the dependencies.
> 
> Since nearly all -dev packages come with static libs and this is not
> forbidded (it's mentioned in Policy) I won't stop using them.  I'll by
> happy to stop as soon as Policy forbids/discourages it.

Policy follows current action more than it forces changes.  Regardless,
it doesn't actually hurt anything to include static libs except disk
space on the mirrors (something I don't tend to worry myself over too
much) so while we *shouldn't*, as long as it doesn't *hurt* things, I
don't care.  Using them as an excuse to include .la files isn't valid
because .la files break other things.

> On a related note, I'd also be very happy if it was a requirement to
> build libraries with a miniumum of "-g -ggdb -gdwarf-2", and not strip
> them.  We could provide some mechanism to automatically strip
> binaries, surely?

This doesn't make a whole lot of sense.  I certainly hope you're not
trying to say we should ship not-stripped *anything* by default.
Libraries make up a large part of the archive and having them not be
stripped would cause users to have to download *alot* of crap they're
very likely to not be interested in.  A much better solution, which is
already being worked on and I think may be working in part at least, is
-dbg packages.  These increase the size the mirror uses, which I realize
some people are concerned about, but doesn't increase the amount of crap
a user has to download unless they ask for it specifically.

Stpehen


signature.asc
Description: Digital signature

Re: Development packages.

[Stephen Frost]

* Scott James Remnant ([EMAIL PROTECTED]) wrote:
> > But shipping .la files in non-dev packages should still be a hanging
> > offense.
>
> Plugins using libltdl probably need them ... though not until some of
> the more exotic ports come to fruition.
> 
> "Debian Solaris" anyone? :o)

I'm not 100% sure but I actually thought that's what OpenLDAP used
(libltdl) and it works just fine w/o the stupid .la files.

Stephen


signature.asc
Description: Digital signature

Re: Development packages.

[Alexander Winston]

On Mon, 2004-03-22 at 20:54 +, Roger Leigh wrote:

> On a related note, I'd also be very happy if it was a requirement to
> build libraries with a miniumum of "-g -ggdb -gdwarf-2", and not strip
> them.  We could provide some mechanism to automatically strip
> binaries, surely?

I believe that this was discussed before and never really got off of the
ground because of the bandwidth issues involved.

By the way, doesn't "-ggdb3" provide more verbose debugging information?


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

Re: Development packages.

[Roger Leigh]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Mon, Mar 22, 2004 at 09:59:34PM +, Scott James Remnant wrote:
>> > pkg-config is a *far* worse offender than libtool.  With libtool, we
>> > have some hope of getting these things right in the near future;
>> > pkg-config, OTOH, doesn't even know there *is* a difference between
>> > static and shared libs, so can't be taught to handle them differently
>> > without a lot of growing pains.  Please don't add pkg-config to packages
>> > that don't already have the misfortune of using it!
>
>> I've got half a mind, if pkg-config upstream haven't shown any signs of
>> activity once I've finished fighting my current battles to start
>> developing it further myself.
>
>> Giving it some idea of what's a dependency library and what's a 2nd (or
>> even 3rd) level dependency would be nice, along with some "I'm linking
>> statically" and "I'm cross-compiling" logic.
>
> From what I can tell, the .pc files already contain enough information
> to distinguish between direct and indirect dependencies.

If you were to take libs specified in the .pc, and those directly
Required by it, that should be the minimum.

Better still, you could just take "pkg-config --libs", and then
manually construct the dependency tree.  You can then just include the
root(s) of however many unique dependency trees you find.

Since pkg-config is already an ELF executable, there's no reason why
it can't do it directly when you use --libs.  The only issue I see is
distinguishing between normal (dynamic) linking and static linking
(where the old behaviour is still required).

Scott, if you do find the time to look at this, I would be ecstatic!
If you don't have the time, I'll try to fit it in myself, since this
is my main peeve with pkg-config.


Regards,
Roger

-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Re: Development packages.

[Stephen Frost]

* Scott James Remnant ([EMAIL PROTECTED]) wrote:
> If you are creating a library package, you should ship the shared
> library (and SONAME symlink) in the libxxxN package and the static
> library, name-only symlink *AND* .la file (if relevant) in the
> libxxx[N]-dev package.

Right, on Debian shipping the .la file isn't relevant.

> This is a requirement for most platforms, Linux is fairly unique in that
> its dynamic link loader is able to process dependency trees itself and
> load the dependencies of a linked library.

Right, not necessary on Linux, therefore crap on Linux shouldn't be
doing it.

> In user terms, this has zero effect; the dependency libraries need to
> loaded *anyway* so loading them earlier actually *slightly* speeds up
> load times of complex apps (esp. Mozilla and friends).

Pffft, with complex apps you're so unlikely to notice the speed
difference as to even consider it is funny.

> In Debian terms, it's slightly annoying; our "shlibs" tools don't
> realise what's going on and suggest more dependencies than are strictly
> necessary.  It can also cause annoyances during SONAME changes of
> libraries deep in the dependency stack.

Which I'm sure wouldn't affect users at all .. (sarcasm)

> There's already a fix for Libtool to ignore dependency_libs when linking
> shared libraries on Linux and the next major release should have it.

Then we'll just have to get people to move to that version, and get them
to turn on symbol versioning.

> The .la files then simply convey the required dependencies when linking
> a static library, which even on Linux requires you to link in all the
> dependencies manually.
> 
> This user links statically a hell of a lot when debugging code; I assume
> I'm not the only one either.

I hardly ever statically link things, even when doing debugging.

Stephen


signature.asc
Description: Digital signature

Re: RFS: mimms - MMS (mms://) streaming media download utility

[Wesley J Landaker]

On Sunday 07 March 2004 9:59 pm, Wesley J Landaker wrote:
> Hi folks,
>
> I'm looking for a sponsor for the mimms package. This upload would
> close ITP bug #221806.

I've gettextized mimms, so now have a new version available that has 
i18n support for all of it's messages.

> Source and binary packages can be downloaded from:
> 

The original package and this new revision are both available here. =)

-- 
Wesley J. Landaker <[EMAIL PROTECTED]>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2



pgpAGbzmkJxyn.pgp
Description: signature

Re: Development packages.

[Andreas Metzler]

On 2004-03-22 Roger Leigh <[EMAIL PROTECTED]> wrote:
> Andreas Metzler <[EMAIL PROTECTED]> writes:
> > On Mon, Mar 22, 2004 at 04:26:49PM +0100, Frank Küster wrote:

> [libtool brokenness]
> >> Yes, it did :-|. Could you point me to a documentation where I could
> >> read about these problems, and under what weird circumstances it will be
> >> a bug nevertheless if I don't install the *la files? 
> > [...]

> > Basically the essence of the mess is #191425. If libfoo links against
> > libbar and application blah makes use of libfoo (but does not use
> > libbar) libtool will link the application against both libraries.

> How is this different to pkg-config:
[...]

See Steve's and Scott's answers.
 cu andreas

Re: Development packages.

[Roger Leigh]

Alexander Winston <[EMAIL PROTECTED]> writes:

> On Mon, 2004-03-22 at 20:54 +, Roger Leigh wrote:
>
>> On a related note, I'd also be very happy if it was a requirement to
>> build libraries with a miniumum of "-g -ggdb -gdwarf-2", and not strip
>> them.  We could provide some mechanism to automatically strip
>> binaries, surely?
>
> I believe that this was discussed before and never really got off of the
> ground because of the bandwidth issues involved.
>
> By the way, doesn't "-ggdb3" provide more verbose debugging information?

Yes, or '-g3' which is equivalent.  I find this essential when
debugging inline C++ code, such as templates.  I think

-g3 -gdwarf-2

should be the shortest way to write it.


Regards,
Roger

-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Re: Development packages.

[Roger Leigh]

Stephen Frost <[EMAIL PROTECTED]> writes:

> * Roger Leigh ([EMAIL PROTECTED]) wrote:
>> I used a statically-linked binary just a few days ago.  I needed to
>> resize an NTFS partition on a newly-delivered system which came with
>> Windows XP.  In the event, I was able to get a statically linked
>> binary, copy it onto a floppy and run this after booting from a rescue
>> disk.
>>
>> So, it's very useful for rescue situations, where you can't rely on a
>> whole suite of shared libs, or any installation at all.
>
> Boot Knoppix or similar from a CD.  PCs today are more often installed
> with CDs than floppies anyway.  That's really a pretty poor reason.

Consider this situation:

New PC arrives.  I only had an old Knoppix CD (freebie from UKUUG two
years ago), which didn't have ntfsutils.  I didn't have the means to
download and burn a new ISO, or the time to mess about doing it.  So
the CD was out.

I used the rescue initrd from a Fedora Core 1 CD, after downloading a
statically linked ntfsresize (from the maintainers' site) and copying
it to a floppy using Windows XP.  Boot the rescue image, and run the
statically linked binary directly from the floppy.  It worked like a
charm.

After resizing, I set up the paritions and LVM2 prior to cloning a new
install directly from the Debian unstable install of my laptop.

>> It's also useful when you want to provide something that "just work"
>> with no extra dependencies.  While proprietary/commercial software was
>> the biggest user of this, it's also useful for free software.  What if
>> Joe Average would like to run my program which makes use of libstdc++,
>> GTK+ 2.2 and GNOME 2.4?  It's the least hassle way to achieve this.
>
> Joe Average installs Debian which *handles* all of the dependencies.
> Come on, this isn't even a reason to keep them.

What about users who don't run Debian, or who don't run unstable.
These are very common situations, and you can't expect everyone to
install unstable just to run my program.  I also don't expect every
user to build over 30 libraries themselves.  Not everyone lives on the
bleeding edge.

> Using [static libs] as an excuse to include .la files isn't valid
> because .la files break other things.

Examples, please?

>> On a related note, I'd also be very happy if it was a requirement to
>> build libraries with a miniumum of "-g -ggdb -gdwarf-2", and not strip
>> them.  We could provide some mechanism to automatically strip
>> binaries, surely?
>
> This doesn't make a whole lot of sense.  I certainly hope you're not
> trying to say we should ship not-stripped *anything* by default.

Yup.  I'd like all my libs with debugging symbols by default.  Since I
spend all day (and night!) writing and debugging software, this would
make a lot of sense (for me).  Whether others would appreciate this is
another matter ;-).


Regards,
Roger

-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Re: Development packages.

[Roger Leigh]

Stephen Frost <[EMAIL PROTECTED]> writes:

> * Scott James Remnant ([EMAIL PROTECTED]) wrote:
>> > But shipping .la files in non-dev packages should still be a hanging
>> > offense.
>>
>> Plugins using libltdl probably need them ... though not until some of
>> the more exotic ports come to fruition.
>> 
>> "Debian Solaris" anyone? :o)
>
> I'm not 100% sure but I actually thought that's what OpenLDAP used
> (libltdl) and it works just fine w/o the stupid .la files.

Have you actually *used* libltdl yourself?  For several reasons, it's
often best (when dynamically loading modules) to load the .la file
directly, and have libltdl do the magic of translating it to
whatever.so for you.

If you're writing your program to work on multiple platforms, this
hides the issues you'll find:

- You don't need to special case DSO extensions for every platform.
  Thus the package will work "out of the box" on every
  libltdl-supported platform.
- This makes debugging and maintenance simpler and more reliable.
- library conventions vary depending on the platform.  Example:
  on Cygwin, DLLs are named cygfoo.dll, and live in /bin.  The .la
  file would take care of this for me (I'd load /usr/lib/libfoo.la).

You can do without the .la file, but IMHO it's too much hassle and
causes more problems than it solves.

If you want to use .so's directly, then just use libdl directly on
Linux.  For example, for Gimp-Print 5.0 (not yet released) I wrote a
module loader that works in 3 modes:
- libltdl  [used when libdl is unavailable]
- libdl[the default]
- static   [useful for debugging and static libs]
Add a little configure magic to detect the best option, and you're all set.


Regards,
Roger

-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Re: Development packages.

[Anibal Monsalve Salazar]

On Mon, Mar 22, 2004 at 05:26:39PM -0500, Stephen Frost wrote:
>* Roger Leigh ([EMAIL PROTECTED]) wrote:
>>I used a statically-linked binary just a few days ago.  I needed to
>>resize an NTFS partition on a newly-delivered system which came with
>>Windows XP.  In the event, I was able to get a statically linked
>>binary, copy it onto a floppy and run this after booting from a rescue
>>disk.
>>
>>So, it's very useful for rescue situations, where you can't rely on a
>>whole suite of shared libs, or any installation at all.
>
>Boot Knoppix or similar from a CD.  PCs today are more often installed
>with CDs than floppies anyway.  That's really a pretty poor reason.

I cannot use a Knoppix CD to rescue my 75 MHz Pentium machine with 16 MB
of RAM running debian stable to connect my home network to the internet.
I have to use a rescue floppy. Roger's case is a good reason, IMHO.

Other operating systems (e.g. Solaris) also provide stand alone programs
compiled with static libraries for exceptional cases where you don't
have access to the file systems where the shared libraries are located.

Anibal Monsalve Salazar
--
 .''`.  Debian GNU/Linux  | Building 28C
: :' :  Free Operating System | Monash University VIC 3800
`. `'   http://debian.org/| Australia
  `-  |



pgpmrqE2Rcr7h.pgp
Description: PGP signature

Re: Development packages.

[Stephen Frost]

* Roger Leigh ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > I'm not 100% sure but I actually thought that's what OpenLDAP used
> > (libltdl) and it works just fine w/o the stupid .la files.
> 
> Have you actually *used* libltdl yourself?  For several reasons, it's
> often best (when dynamically loading modules) to load the .la file
> directly, and have libltdl do the magic of translating it to
> whatever.so for you.

Yes, actually, I have.  A little anyway- modified OpenLDAP to use it
somewhat more intelligently (and got upstream to include my changes, as
I recall) and to *not* need the .la files.

> If you're writing your program to work on multiple platforms, this
> hides the issues you'll find:

My issues here are with problems on Debian and not on other systems.
.la files, libltdl, etc may be useful for other systems but if they
don't work correctly on Debian then I've got issues with them.

> You can do without the .la file, but IMHO it's too much hassle and
> causes more problems than it solves.

If you're having to worry about platforms that aren't Debian that may be
the case.  However, that's not what I'm referring to, and in fact
consider it uninteresting.

Stephen


signature.asc
Description: Digital signature

Re: Development packages.

[Stephen Frost]

* Bernhard R. Link ([EMAIL PROTECTED]) wrote:
> * Stephen Frost <[EMAIL PROTECTED]> [040322 21:14]:
> > Pffft.  Honestly, I think that claim of end-users and local
> > administrators using static libraries is rather dated and rarely the
> > case these days.  
> 
> I do not know, if they are used to make any programs intended for 
> production use any more, though I often found them very helpfull 
> when debugging things.
> Having to recompile whole libraries just to locate some of those
> ugly pointer-address relatated bugs makes those assembler near
> languages like C and friends much more a pain than it has to be.

Would -dbg packages fix this issue for you?

Stephen


signature.asc
Description: Digital signature

Re: Development packages.

[Stephen Frost]

* Anibal Monsalve Salazar ([EMAIL PROTECTED]) wrote:
> On Mon, Mar 22, 2004 at 05:26:39PM -0500, Stephen Frost wrote:
> >Boot Knoppix or similar from a CD.  PCs today are more often installed
> >with CDs than floppies anyway.  That's really a pretty poor reason.
> 
> I cannot use a Knoppix CD to rescue my 75 MHz Pentium machine with 16 MB
> of RAM running debian stable to connect my home network to the internet.
> I have to use a rescue floppy. Roger's case is a good reason, IMHO.

You may actually find this difficult to do w/ 2.6 anyway...

> Other operating systems (e.g. Solaris) also provide stand alone programs
> compiled with static libraries for exceptional cases where you don't
> have access to the file systems where the shared libraries are located.

I can understand that in some small cases for basic applications.

Stephen


signature.asc
Description: Digital signature

Re: Development packages.

[Stephen Frost]

* Roger Leigh ([EMAIL PROTECTED]) wrote:
> Consider this situation:

Situations can be derived for anything. :)

> > Joe Average installs Debian which *handles* all of the dependencies.
> > Come on, this isn't even a reason to keep them.
> 
> What about users who don't run Debian, or who don't run unstable.
> These are very common situations, and you can't expect everyone to
> install unstable just to run my program.  I also don't expect every
> user to build over 30 libraries themselves.  Not everyone lives on the
> bleeding edge.

Honestly, if you can run the same binary anyway I think you should be
running a distribution which can handle dependencies.

> > Using [static libs] as an excuse to include .la files isn't valid
> > because .la files break other things.
> 
> Examples, please?

Until libtool is fixed it breaks complex programs which are linking
against libraries which link against other libraries which use versioned
symbols (and therefore can have multiple .so's linked in at once).
It adds unnecessary dependencies to the dependency chain, which is 
very annoying.

> > This doesn't make a whole lot of sense.  I certainly hope you're not
> > trying to say we should ship not-stripped *anything* by default.
> 
> Yup.  I'd like all my libs with debugging symbols by default.  Since I
> spend all day (and night!) writing and debugging software, this would
> make a lot of sense (for me).  Whether others would appreciate this is
> another matter ;-).

Keep dreaming..  -dbg packages I think are a good idea though, where
necessary.

Stephen


signature.asc
Description: Digital signature

Re: Need a sponsor to upload #234303

[Everton da Silva Marques]

Hi Mentors,

I have added minimum support for both
PHP and Perl into ruli-0.19. The new
Debian packages are uploaded to
mentors.debian.net and are also
available in the usual place:

http://savannah.nongnu.org/download/ruli/

I have a signature of [EMAIL PROTECTED] on
my gpg key. I suppose that is sufficient
for confirming my identity?

I keep looking for a sponsor to check
the packaging and possibly upload it
to Debian.

Thanks,
Everton





__

Yahoo! Mail - O melhor e-mail do Brasil! Abra sua conta agora:
http://br.yahoo.com/info/mail.html

Re: Development packages.

[Matt Zimmerman]

On Mon, Mar 22, 2004 at 08:54:17PM +, Roger Leigh wrote:

> I used a statically-linked binary just a few days ago.  I needed to
> resize an NTFS partition on a newly-delivered system which came with
> Windows XP.  In the event, I was able to get a statically linked
> binary, copy it onto a floppy and run this after booting from a rescue
> disk.

It should be much simpler and faster to copy the existing binary and its
shared library dependencies from a running system than to recompile the
program from source.  It would probably be larger, so you might need to
compress it to fit onto a floppy, but it still seems easier.

If you need more than a "quick fix", a rescue CD is the way to go, as others
have mentioned.

> It's also useful when you want to provide something that "just work" with
> no extra dependencies.  While proprietary/commercial software was the
> biggest user of this, it's also useful for free software.  What if Joe
> Average would like to run my program which makes use of libstdc++, GTK+
> 2.2 and GNOME 2.4?  It's the least hassle way to achieve this.

The Debian packaging system is another way to accomplish the same goal
(among other things), and I find it preferable to static linking. :-)

> On a related note, I'd also be very happy if it was a requirement to
> build libraries with a miniumum of "-g -ggdb -gdwarf-2", and not strip
> them.  We could provide some mechanism to automatically strip
> binaries, surely?

We can do better than that.  See dh_strip --dbg-package=.

-- 
 - mdz

Advice on adopting a package: relay-ctrl

[Brian T Glenn]

I have submitted an ITA (Bug#238972), but the original RFA is 
Bug#238972. I have new packages created for relay-ctrl at the current
version per the RFA. I attempted to contact the current maintainer,
but i have received no response after a few days.

What else should I be doing in order to execute the ITA?

The packages are available from the following apt source:

deb http://cvs.delink.net/debian/ delink main contrib
deb-src http://cvs.delink.net/debian/ delink main contrib

-- 
Brian T Glenn
delink.net Internet Services


pgpuC0UIy0taI.pgp
Description: PGP signature

Re: Should I always clean in debian/rules before making binary?

[Peter Samuelson]

[Bob Proulx]
> There appear to be three cases.
> 
> 1. The developer wrote the Makefiles by hand and did not supply any
>support for DESTDIR natively.

Actually there is also:

  1a. The developer wrote Makefiles by hand, but also happens to have a
  clue, so at some point added DESTDIR support.

You can spot this case, generally, with 'grep DESTDIR Makefile'.  Of
course there is the possibility that the developer only had half a
clue, so this is broken, but then it's just a bug to be patched and
handed upstream.

Peter


signature.asc
Description: Digital signature

uploaded my pim project to mentors.debian.net

[Tom Ballard]

Forum:
http://mentors.debian.net/phpbb/viewtopic.php?t=35&sid=d33a77afe7960fb079f69e21927abb6f

Also:
http://freshmet.net/projects/pim-tb
http://freshmeat.net/screenshots/45596/
http://sourceforge.net/projects/pim-tb

I'm working on the 1.5 version.  The package name is "pim" which is somewhat
generic so I can call it "pim-tb" or something else you suggest.  But I like
"pim" if you don't care.  While it would be nice to get a sponsor to put 
it in the Sid archive, it's not an urgent priority for me.  So far 400 
people have d/l'd it with 4 subscribers at Freshmeat.  My main goal is 
to get some eyeballs on it and let it cook a while longer.  So far I 
have no external feedback.  It is highly useful to me.  See GOALS, 
below.

Info:
Hierarchical personal data manager. Schemas and data are stored in XML.
Uses GTK2. Designed for single users, small, personal databases.

///

Right now, it's a somewhat pedestrian but useful little list manager 
that implements table lookups / referential integrity, stores 
data/schemas in XML, and doesn't require a server. I use it to keep 
track of my TODO lists, Books I want, espcially useful are my Account #s 
for various companies and the address/phone on file they have for me, my 
credit card receipts, my .flag collection, and my calorie intake.

When combined with xsltproc to process the data it is very powerful.

Here are the GOALS I have for it:

GOAL: Factor view component out of main.c.
GOAL: Add SVG/HTML/Text-based reports.
GOAL: Add image/media integration (Document Management) -- also
requires versioning.
GOAL: Add Struts-style MVC; turn into an ERP client.

Re: Should I recommend "less" if I use it in some scripts?

[Michael Koch]

Am Montag, 22. März 2004 10:25 schrieb Number Six:
> Some of the scripts I include with my package use "less" (as well as
> "sed", "tr", and "grep").  I know for a fact "less" is not installed
> by default.  (Not sure about this others).
>
> Should every little "ordinary" thing like less be included in my
> Recommends?  It's surely not germane to the package, but if it's not
> there, these little scripts will break.

You need to depend on "less", a recommends seems not to be enough in 
your case. "coreutils" and "sedutils" are marked "essential" and can be 
exspected on the system.


Michael


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

Re: Should I recommend "less" if I use it in some scripts?

[Kalle Kivimaa]

Number Six <[EMAIL PROTECTED]> writes:
> Should every little "ordinary" thing like less be included in my 
> Recommends?  It's surely not germane to the package, but if it's not 
> there, these little scripts will break.

If your package needs something that is not Essential you must declare
a Depends to it. See policy 3.5.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


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

Re: Should I recommend "less" if I use it in some scripts?

[David Weinehall]

On Mon, Mar 22, 2004 at 01:25:47AM -0800, Number Six wrote:
> Some of the scripts I include with my package use "less" (as well as 
> "sed", "tr", and "grep").  I know for a fact "less" is not installed by 
> default.  (Not sure about this others).
> 
> Should every little "ordinary" thing like less be included in my 
> Recommends?  It's surely not germane to the package, but if it's not 
> there, these little scripts will break.

Why do you need less, wouldn't any pager work?

Refer to 11.4. Editors and pagers


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


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

Should I recommend "less" if I use it in some scripts?

[Number Six]

Some of the scripts I include with my package use "less" (as well as 
"sed", "tr", and "grep").  I know for a fact "less" is not installed by 
default.  (Not sure about this others).

Should every little "ordinary" thing like less be included in my 
Recommends?  It's surely not germane to the package, but if it's not 
there, these little scripts will break.


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

Re: Should I recommend "less" if I use it in some scripts?

[Andreas Metzler]

On 2004-03-22 Number Six <[EMAIL PROTECTED]> wrote:
> Some of the scripts I include with my package use "less" (as well as 
> "sed", "tr", and "grep").  I know for a fact "less" is not installed by 
> default.  (Not sure about this others).

> Should every little "ordinary" thing like less be included in my 
> Recommends?  It's surely not germane to the package, but if it's not 
> there, these little scripts will break.

Adapt your scripts to confirm to policy "11.4 Editors and pagers".
   cu andreas


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

Re: Should I recommend "less" if I use it in some scripts?

[Cosimo Alfarano]

On Mon, Mar 22, 2004 at 01:25:47AM -0800, Number Six wrote:
> Should every little "ordinary" thing like less be included in my 
> Recommends?  It's surely not germane to the package, but if it's not 

Why not use sensible-pager, in debianutils (Essential: yes)?

cheers,
c.


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

Howto use misc:Depends? [was Re: Should I recommend "less" if I use it in some scripts?]

[Number Six]

On Mon, Mar 22, 2004 at 11:03:58AM +0100, Michael Koch wrote:
> Am Montag, 22. März 2004 10:25 schrieb Number Six:
> > Some of the scripts I include with my package use "less" (as well as
> > "sed", "tr", and "grep").  I know for a fact "less" is not installed
> > by default.  (Not sure about this others).
> >
> > Should every little "ordinary" thing like less be included in my
> > Recommends?  It's surely not germane to the package, but if it's not
> > there, these little scripts will break.
> 
> You need to depend on "less", a recommends seems not to be enough in 
> your case. "coreutils" and "sedutils" are marked "essential" and can be 
> exspected on the system.
> 

Okay.  The dh-make generated control file has:
Depends: ${shlibs:Depends}, ${misc:Depends}

shlibs:Depends is being populated properly, misc:Depends is currently
not being used:

dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}

I would prefer to have "less" be picked up by misc:Depends, I guess,
rather than explicitly adding it to the Depends line.

How can I do that?  Or should I just remove misc:Depends and explicitly
add it?


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

Should I always clean in debian/rules before making binary?

[Number Six]

I have an automake project that I've also run dh_make on.

If I just run: ./configure, the default {prefix} is "/usr/local",
which is the way I want it.

If I then run "fakeroot debian/rules binary", the binary debian package 
will install itself to /usr/local.

If I "make clean; fakeroot debian/rules binary", the package will 
install itself to /usr, which is right for debian.

Should I do something in debian/rules to make sure the binary always 
goes to /usr, or this flexiblity desirable?  It sure seems like 
"unexpected behavior" to me.


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

Re: Development packages.

[Adrian 'Dagurashibanipal' von Bidder]

On Sunday 21 March 2004 20.49, Stephen Frost wrote:

> .la files shouldn't be included in anything, they're just plain broken.

940 .la files on my system. Report bugs?

/usr/lib/rep/...
/usr/lib/libkabc_ldapkio.la
/usr/lib/libesd.la
/usr/lib/libkwireless.la
usr/lib/gimp/1.3/modules/...
/usr/lib/kde3/...

So either you don't mean that absolutely, or three's a few buggy packages out 
there.

-- vbi



-- 
It's not a bug; it's an undocumented feature.


pgp0.pgp
Description: signature

Re: Development packages.

[Stephen Frost]

* Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote:
> On Sunday 21 March 2004 20.49, Stephen Frost wrote:
> 
> > .la files shouldn't be included in anything, they're just plain broken.
> 
> 940 .la files on my system. Report bugs?
[...]
> So either you don't mean that absolutely, or three's a few buggy packages out 
> there.

It's the glorious brokenness that is libtool.  Basically, libtool needs
to be fixed to not use the stupid things on systems that don't need them
(like, oh, all of Debian).  I don't know that filing bug reports would
be useful until libtool is fixed because I imagine most maintainers who
havn't actually run into the problems caused by .la files will just
whine "libtool did it".

Stephen


signature.asc
Description: Digital signature

Re: Should I always clean in debian/rules before making binary?

[Frank Küster]

Number Six <[EMAIL PROTECTED]> schrieb:

> I have an automake project that I've also run dh_make on.
>
> If I just run: ./configure, the default {prefix} is "/usr/local",
> which is the way I want it.
>
> If I then run "fakeroot debian/rules binary", the binary debian package 
> will install itself to /usr/local.
>
> If I "make clean; fakeroot debian/rules binary", the package will 
> install itself to /usr, which is right for debian.
>
> Should I do something in debian/rules to make sure the binary always 
> goes to /usr, or this flexiblity desirable?  It sure seems like 
> "unexpected behavior" to me.

- I think you should call ./configure --prefix=/usr/ in debian/rules -
  in some target that binary depends on (e.g. a configure or build
  target). 

- In the install target, you would call something like

  $(MAKE) install prefix=debian/tmp/usr

- From a policy point of view, it doesn't hurt to call clean before
  debian/rules binary, but if you do that, I'd do it in debian/rules,
  not by hand. However, I recommend not to do it. It makes it much
  easier to test changes in your installation procedure, postinst
  etc. You can simply wipe out the package tree under debian/ and call
  fakeroot debian/rules binary, and then it won't need to configure and
  compile everything, but just start installing.

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: Howto use misc:Depends? [was Re: Should I recommend "less" if I use it in some scripts?]

[Colin Watson]

On Mon, Mar 22, 2004 at 02:37:48AM -0800, Number Six wrote:
> I would prefer to have "less" be picked up by misc:Depends, I guess,
> rather than explicitly adding it to the Depends line.

No, you should add it explicitly; misc:Depends belongs to debhelper.
However, I agree that you should refer to policy and use the
sensible-pager system instead.

-- 
Colin Watson  [EMAIL PROTECTED]


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

Re: Should I always clean in debian/rules before making binary?

[Colin Watson]

On Mon, Mar 22, 2004 at 03:19:55PM +0100, Frank Küster wrote:
> - In the install target, you would call something like
> 
>   $(MAKE) install prefix=debian/tmp/usr

It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is
available; that way you get less confused by /etc.

> - From a policy point of view, it doesn't hurt to call clean before
>   debian/rules binary, but if you do that, I'd do it in debian/rules,
>   not by hand. However, I recommend not to do it.

I'd call it a bug to do that. I believe the buildds, and certainly
dpkg-buildpackage, do something morally equivalent to 'debian/rules
build && fakeroot debian/rules binary'.

Use dpkg-buildpackage (or debuild, a wrapper around it which sorts out
fakeroot and the like) rather than 'debian/rules binary'.

-- 
Colin Watson  [EMAIL PROTECTED]


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

Re: Development packages.

[Frank Küster]

Stephen Frost <[EMAIL PROTECTED]> schrieb:

> * Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote:
>> On Sunday 21 March 2004 20.49, Stephen Frost wrote:
>> 
>> > .la files shouldn't be included in anything, they're just plain broken.
>> 
>> 940 .la files on my system. Report bugs?
> [...]
>> So either you don't mean that absolutely, or three's a few buggy packages out 
>> there.
>
> It's the glorious brokenness that is libtool.  Basically, libtool needs
> to be fixed to not use the stupid things on systems that don't need them
> (like, oh, all of Debian).  I don't know that filing bug reports would
> be useful until libtool is fixed because I imagine most maintainers who
> havn't actually run into the problems caused by .la files will just
> whine "libtool did it".

Yes, it did :-|. Could you point me to a documentation where I could
read about these problems, and under what weird circumstances it will be
a bug nevertheless if I don't install the *la files? 

I'm asking because - hm, well - in the NM process I promised not to
package a library soon, and now a month later I have write access to
tetex-bin's cvs. And libkpathsea is going to switch from its own hacked
libtool to the standard one, including all standard errors...

TIA, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

updating gdal library

[Silke Reimer]

Hallo!

I am the maintainer of gdal and since a new upstream version is
available I want to build a new pacakge. Now I have the following
problems:

First I don't know how to fill the Depends for libgdal1-dev
correctly.
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#AEN75
explains the following:

"""
The -dev package should depend on all -dev packages for libraries
that the library package depends upon, with the specific (so)version
that the library package is linked against. This includes libc-dev.
"""

The problem for my package is that it depends on different
library-versions depending on the architecture it is built on. So I
would like to create those dev-dependencies automatically.
I tried d-devlibdeps (which is part of the  package d-shlibs) but
this didn't find a few of the necessary dev-packages:


mimirs gdal-1.2.0 522: d-devlibdeps debian/libgdal1-dev.substvar
debian/libgdal1/usr/lib/libgdal.so.1.2.0
 --> libc6-dev package exists.
devlibs error: There is no package matching [libcfitsio2-dev] and
noone provides it, please report bug to d-shlibs maintainer
devlibs error: There is no package matching [libdf4-dev] and noone
provides it, please report bug to d-shlibs maintainer
 --> libjpeg62-dev package exists.
devlibs error: There is no package matching [libmfhdf4-dev] and
noone provides it, please report bug to d-shlibs maintainer
devlibs error: There is no package matching [libodbc1-dev] and noone
provides it, please report bug to d-shlibs maintainer
 --> libpng12-0-dev is provided by a package.
devlibs error: There is no package matching [libpq3-dev] and noone
provides it, please report bug to d-shlibs maintainer
 --> libstdc++5-dev package exists.
 --> libungif4-dev package exists.
devlibs error: There is no package matching [libxerces-c21-dev] and
noone provides it, please report bug to d-shlibs maintainer
 --> zlib1g-dev package exists.
-

Do you have any ideas?


The second questions is concerning the fields 'replaces',
'conflicts' etc. of libgdal1-dev. Currently they contain:

 Depends: libgdal1 (= 1.2.0-1)
 Suggests: libgdal-doc
 Conflicts: libgdal-dev, libgdal1 (<< 1.2.0-1)
 Replaces: libgdal1 (<< 1.2.0-1)
 Provides: libgdal-dev

Thus the  old libgdal1 will be removed and the current libgdal1
installed when libgdal1-dev is updated. Otherwise there are other
package that depend on special versions of libgdal1 i.e. gdal-bin.
Thus libgdal1 will not be removed by an update of libgdal1-dev. Do
have any suggestions how I can solve this conflict?

Many thanks,

Silke

-- 
Silke Reimer

Intevation GmbH  http://intevation.de/
FreeGIShttp://freegis.org/



pgp0.pgp
Description: PGP signature

Re: updating gdal library

[Andreas Metzler]

On Mon, Mar 22, 2004 at 04:39:19PM +0100, Silke Reimer wrote:
> First I don't know how to fill the Depends for libgdal1-dev
> correctly.
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#AEN75
> explains the following:
> 
>   """
>   The -dev package should depend on all -dev packages for libraries
>   that the library package depends upon, with the specific (so)version
>   that the library package is linked against. This includes libc-dev.
>   """
[...]

This is bogus. The Depends should list the -dev packages that are
needed for linking against your library (basically if libgal's header
files include header files from other packages you should depend on
this packages)
   cu andreas


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

Re: Should I always clean in debian/rules before making binary?

[Frank Küster]

Colin Watson <[EMAIL PROTECTED]> schrieb:

> On Mon, Mar 22, 2004 at 03:19:55PM +0100, Frank Küster wrote:
>> - In the install target, you would call something like
>> 
>>   $(MAKE) install prefix=debian/tmp/usr
>
> It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is
> available; that way you get less confused by /etc.

Ah, you're right. The last package I prepared from scratch doesn't
install anything into /etc anyway, and my only alone-maintained package
uses it. 

Hm, how do I know (other by trial and error) whether a package supports
this? autoconf'iscated ones do not use it generally, do they?

>> - From a policy point of view, it doesn't hurt to call clean before
>>   debian/rules binary, but if you do that, I'd do it in debian/rules,
>>   not by hand. However, I recommend not to do it.
>
> I'd call it a bug to do that. I believe the buildds, and certainly
> dpkg-buildpackage, do something morally equivalent to 'debian/rules
> build && fakeroot debian/rules binary'.

Didn't think about buildds. Only about human ones, also called
maintainer_in_debugging_building_cycle. 
>
> Use dpkg-buildpackage (or debuild, a wrapper around it which sorts out
> fakeroot and the like) rather than 'debian/rules binary'.

The last is a remark to the OP's question, not to me, right? Because
that's what I meant: Don't make binary depend on clean, because it
enables you to delete exactly what you want and then run the binary
target, and dpkg-buildpackage will run clean, anyway.

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Spam mail warning notification! (Subject check wicked screen saver your account)

[spamcontrol]

 eManager Notification *

The following mail was blocked since it contains sensitive content.

Source mailbox: <[EMAIL PROTECTED]>
Destination mailbox(es): [EMAIL PROTECTED]
Policy: Subject check  wicked screen saver  your account
Action: Quarantine

Subject is similar to one caused by virus.  Please change and try again.

*** End of message *
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1B5RfJ-0003EE-00
for [EMAIL PROTECTED]; Mon, 22 Mar 2004 10:48:37 -0500
Received: from venera.isi.edu ([128.9.176.32])
by ietf-mx with esmtp (Exim 4.12)
id 1B5ReO-00036X-00
for [EMAIL PROTECTED]; Mon, 22 Mar 2004 10:47:40 -0500
Received: from venera.isi.edu (dijon-1-62-147-69-195.dial.proxad.net [62.147.69.195])
by venera.isi.edu (8.9.3/8.9.3) with ESMTP id HAA24489
for <[EMAIL PROTECTED]>; Mon, 22 Mar 2004 07:44:56 -0800 (PST)
From: [EMAIL PROTECTED]
Message-Id: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: approved
Date: Mon, 22 Mar 2004 16:47:14 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_NextPart_000_0016=_NextPart_000_0016"
X-Priority: 3
X-MSMail-Priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
ietf-mx.ietf.org
X-Spam-Status: No, hits=2.4 required=5.0 tests=MIME_BOUND_NEXTPART,
MISSING_MIMEOLE,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no 
version=2.60

Re: Should I always clean in debian/rules before making binary?

[Bob Proulx]

Frank Küster wrote:
> Colin Watson <[EMAIL PROTECTED]> schrieb:
> > It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is
> > available; that way you get less confused by /etc.
> [..]
> Hm, how do I know (other by trial and error) whether a package supports
> this? autoconf'iscated ones do not use it generally, do they?

Older automake generated Makefiles do not support DESTDIR.  But newer
automake generated Makefiles do support it.  I don't know at what
version that support was enabled.  But if the tool uses a new automake
to generate the files or if you happen to regenerate them then you
should have DESTDIR support.

There appear to be three cases.

1. The developer wrote the Makefiles by hand and did not supply any
   support for DESTDIR natively.

2. The developer used automake and therefore supports DESTDIR by
   default.

3. The developer used automake but also supplied additional Makefile
   sections by hand and those additional sections do not support
   DESTDIR.  So it is partially there but not fully functional now.

That last one happens every so often.  I found and reported one in
gettext just recently (which was promptly fixed by upstream).  But
those are the hardest to detect without actually trying.

Trial and error is probably the easiest method.

Bob


pgp0.pgp
Description: PGP signature

Re: Should I always clean in debian/rules before making binary?

[elijah wright]

frank, can i beg you to doublecheck the way your last name is encoded in
your email client?  it corrupts the screen state in pine EVERY time i get
one of your email messages...  mutt doesn't get corrupted, but it shows me
a big fat questionmark instead of the letter between "K" and "s" in your
last name... i see that your mails are coming across as latin-1 encoded -
is whatever the second letter of your name is really in that charset?

alternatively, can someone suggest a solution to the screen corruption?  i
think what might be happening is that the letter in question is taking two
cells on the screen instead of the ONE that it should take up...


 thanks,

elijah



On Mon, 22 Mar 2004, Frank Küster wrote:

> Date: Mon, 22 Mar 2004 17:03:44 +0100
> From: Frank Küster <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Should I always clean in debian/rules before making binary?
> Resent-Date: Mon, 22 Mar 2004 10:08:24 -0600 (CST)
> Resent-From: [EMAIL PROTECTED]
>
> Colin Watson <[EMAIL PROTECTED]> schrieb:
>
> > On Mon, Mar 22, 2004 at 03:19:55PM +0100, Frank Küster wrote:
> >> - In the install target, you would call something like
> >>
> >>   $(MAKE) install prefix=debian/tmp/usr
> >
> > It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is
> > available; that way you get less confused by /etc.
>
> Ah, you're right. The last package I prepared from scratch doesn't
> install anything into /etc anyway, and my only alone-maintained package
> uses it.
>
> Hm, how do I know (other by trial and error) whether a package supports
> this? autoconf'iscated ones do not use it generally, do they?
>
> >> - From a policy point of view, it doesn't hurt to call clean before
> >>   debian/rules binary, but if you do that, I'd do it in debian/rules,
> >>   not by hand. However, I recommend not to do it.
> >
> > I'd call it a bug to do that. I believe the buildds, and certainly
> > dpkg-buildpackage, do something morally equivalent to 'debian/rules
> > build && fakeroot debian/rules binary'.
>
> Didn't think about buildds. Only about human ones, also called
> maintainer_in_debugging_building_cycle.
> >
> > Use dpkg-buildpackage (or debuild, a wrapper around it which sorts out
> > fakeroot and the like) rather than 'debian/rules binary'.
>
> The last is a remark to the OP's question, not to me, right? Because
> that's what I meant: Don't make binary depend on clean, because it
> enables you to delete exactly what you want and then run the binary
> target, and dpkg-buildpackage will run clean, anyway.
>
> Regards, Frank
>


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

Re: Development packages.

[Andreas Metzler]

On Mon, Mar 22, 2004 at 04:26:49PM +0100, Frank Küster wrote:
> Stephen Frost <[EMAIL PROTECTED]> schrieb:
> > * Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote:
> >> On Sunday 21 March 2004 20.49, Stephen Frost wrote:
> >> 
> >> > .la files shouldn't be included in anything, they're just plain broken.
> >> 
> >> 940 .la files on my system. Report bugs?
> > [...]
> >> So either you don't mean that absolutely, or three's a few buggy
> >> packages out there.

> > It's the glorious brokenness that is libtool.  Basically, libtool needs
> > to be fixed to not use the stupid things on systems that don't need them
> > (like, oh, all of Debian).  I don't know that filing bug reports would
> > be useful until libtool is fixed because I imagine most maintainers who
> > havn't actually run into the problems caused by .la files will just
> > whine "libtool did it".
 
> Yes, it did :-|. Could you point me to a documentation where I could
> read about these problems, and under what weird circumstances it will be
> a bug nevertheless if I don't install the *la files? 
[...]

Hello,
Basically the essence of the mess is #191425. If libfoo links against
libbar and application blah makes use of libfoo (but does not use
libbar) libtool will link the application against both libraries.

This is not necessary for dynamic linking on reasonably unbroken
platforms like GNU/Linux and complicates matters a lot:

Dependencies are immensly bloated. For example check the
dependencies of ghex (a simple Hex-Editor). It links directly
against libtasn1-0 although it sure as hell does not parse ASN
certificates. This can make make migration to testing a lot more
painful.

Now, if libfoo is replaced by libfoo2 and libbar is rebuilt against it
the application blah sudenly links against both libfoo2 and libfoo. If
these libraries do not use versioned symbols you'll get symbol clashes
and segmentation faults.

Now libtool gets this information (libfoo links against libbar) from
the .la file, if you do not ship it, libtool cannot be that stupid and
link against all these dependcies. - The price you pay for that is
that _static_ linking does require following these dependency chains.

Personally I think the payoff is ok, due to dlopen in glibc (NSS,
iconv) static linking is unreliable anyway.

If you want to see a nice example for the results of this bug, check
e.g.  apt-cache showpkg  libtasn1-0 and ask yourself how many of these
packages really should link against it.
cu andreas
PS: Be aware that I do not maintain a library myself, I have just 
done one or two NMUs and have followed discussions on the issue.
PPS: I gather that pkgconfig is also broken.


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

Re: updating gdal library

[Silke Reimer]

On Mon, Mar 22, 2004 at 04:49:51PM +0100, Andreas Metzler wrote:
> On Mon, Mar 22, 2004 at 04:39:19PM +0100, Silke Reimer wrote:
> > First I don't know how to fill the Depends for libgdal1-dev
> > correctly.
> > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#AEN75
> > explains the following:
> > 
> > """
> > The -dev package should depend on all -dev packages for libraries
> > that the library package depends upon, with the specific (so)version
> > that the library package is linked against. This includes libc-dev.
> > """
> [...]
> 
> This is bogus. The Depends should list the -dev packages that are
> needed for linking against your library (basically if libgal's header
> files include header files from other packages you should depend on
> this packages)

Thanks. This is more sensible and now it is not that difficult to
provide the *-dev's on the Depends: field. 


Silke

-- 
Silke Reimer

Intevation GmbH  http://intevation.de/
FreeGIShttp://freegis.org/



pgp0.pgp
Description: PGP signature

Re: Should I always clean in debian/rules before making binary?

[Kalle Kivimaa]

elijah wright <[EMAIL PROTECTED]> writes:
> frank, can i beg you to doublecheck the way your last name is encoded in
> your email client?  it corrupts the screen state in pine EVERY time i get
> one of your email messages...  mutt doesn't get corrupted, but it shows me
> a big fat questionmark instead of the letter between "K" and "s" in your
> last name... i see that your mails are coming across as latin-1 encoded -
> is whatever the second letter of your name is really in that charset?

Current SMTP standards do not allow anything else except 7-bit ASCII
in the headers. Thus the MUA should convert any 8-bit characters to
the special header MIME encoding when sending and of course manage to
convert the MIME information back. This mail _should_ demonstrate
that, unless my Gnus surprises me.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


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

Re: Development packages.

[Frank Küster]

Andreas Metzler <[EMAIL PROTECTED]> wrote:

> Basically the essence of the mess is #191425. If libfoo links against
> libbar and application blah makes use of libfoo (but does not use
> libbar) libtool will link the application against both libraries.

[...]
O.k., understood.

> Now libtool gets this information (libfoo links against libbar) from
> the .la file, if you do not ship it, libtool cannot be that stupid and
> link against all these dependcies. - The price you pay for that is
> that _static_ linking does require following these dependency chains.

Also o.k.

> Personally I think the payoff is ok, due to dlopen in glibc (NSS,
> iconv) static linking is unreliable anyway.

This I don't understand. What is the relation between dlopen calls and
static linking? For sure a statically linked binary won't use dlopen,
and if it's a different one, what's the problem?

TIA, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: Should I always clean in debian/rules before making binary?

[Frank Küster]

elijah wright <[EMAIL PROTECTED]> schrieb:

> frank, can i beg you to doublecheck the way your last name is encoded in
> your email client? 

As I see it, it is

From: =?iso-8859-1?q?Frank_K=FCster?= <[EMAIL PROTECTED]>

Although I'd prefer

From: Frank =?iso-8859-1?q?K=FCster?= <[EMAIL PROTECTED]>

(that was handmade, may be incorrect), I don't see what else I could do
about this (except writing Kuester, but that is _not_ my name).

> alternatively, can someone suggest a solution to the screen corruption?  i
> think what might be happening is that the letter in question is taking two
> cells on the screen instead of the ONE that it should take up...

Or do you meant the message _body_? I would be surprised if pine and
mutt couldn't cope with 

Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

> On Mon, 22 Mar 2004, Frank Küster wrote:

Could it be that this isn't a problem of pine or mutt, but because of
missing fonts in your installation? Because my name looks quite well in
your citation.

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Character encoding (was: Should I always clean...)

[Matt Brubeck]

elijah wright <[EMAIL PROTECTED]> schrieb:

> alternatively, can someone suggest a solution to the screen
> corruption?  i think what might be happening is that the letter in
> question is taking two cells on the screen instead of the ONE that
> it should take up...

It sounds like Pine is sending characters in UTF-8 and your terminal
emulation program is interpreting them in a single-byte character set,
or vice-versa.


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

Re: Should I always clean in debian/rules before making binary?

[Rene Engelhard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[ read http://learn.to.quote ]

Hi,

elijah wright wrote:
> frank, can i beg you to doublecheck the way your last name is encoded in
> your email client?  it corrupts the screen state in pine EVERY time i get
> one of your email messages...  mutt doesn't get corrupted, but it shows me
> a big fat questionmark instead of the letter between "K" and "s" in your
> last name... i see that your mails are coming across as latin-1 encoded -
> is whatever the second letter of your name is really in that charset?

Yes, the ü is as every german umlaut in latin-1.

> alternatively, can someone suggest a solution to the screen corruption?  i
> think what might be happening is that the letter in question is taking two
> cells on the screen instead of the ONE that it should take up...

don't use pine? :)
i
Grüße/Regards,

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

iD8DBQFAXyXK+FmQsCSK63MRApDrAJ9izysSXYWWH9r8v20eBhdBvdFqPwCfdFyb
CwKbmX6hXZYyXQtFP7KuUbo=
=uVfK
-END PGP SIGNATURE-


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

Re: Development packages.

[Andreas Metzler]

On Mon, Mar 22, 2004 at 06:28:43PM +0100, Frank Küster wrote:
> Andreas Metzler <[EMAIL PROTECTED]> wrote:
[...] 
> > Personally I think the payoff is ok, due to dlopen in glibc (NSS,
> > iconv) static linking is unreliable anyway.

> This I don't understand. What is the relation between dlopen calls and
> static linking? For sure a statically linked binary won't use dlopen,

It does.

> and if it's a different one, what's the problem?

The problem is that dlopen()ed stuffed is not linked and therefore not
pulled in by static linking. - If you link static against glibc 2.2
and execute the program on a system using glibc 2.3 the NSS/iconv
modules from the new version are used which might be incompatible.

See http://bugs.debian.org/193310

The comment at the top of the mail is too broad, static linking
against chosen libraries whih don't use dlopen works.
cu andreas


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

Re: Development packages.

[Roger Leigh]

Stephen Frost <[EMAIL PROTECTED]> writes:

> We shouldn't be recommending providing staticlly linked libs for people
> to use, even in the 'fast moving' case- if it's that fast then it
> probably shouldn't be in Debian and that's just life.
>
> .la files shouldn't be included in anything, they're just plain broken.

Even with static libraries?  The .la does contain dependency
information.  I know that using pkg-config .pc files can eliminate
this case, but not everything using libtool is using pkg-config yet.


-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


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

Re: Development packages.

[Stephen Frost]

* Roger Leigh ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > We shouldn't be recommending providing staticlly linked libs for people
> > to use, even in the 'fast moving' case- if it's that fast then it
> > probably shouldn't be in Debian and that's just life.
> >
> > .la files shouldn't be included in anything, they're just plain broken.
> 
> Even with static libraries?  The .la does contain dependency
> information.  I know that using pkg-config .pc files can eliminate
> this case, but not everything using libtool is using pkg-config yet.

We shouldn't be shipping or using static libraries.

Stephen


signature.asc
Description: Digital signature

Re: Development packages.

[Matt Brubeck]

Stephen Frost wrote:

> We shouldn't be shipping or using static libraries.

Why not?  I know we shouldn't be linking to static libraries in our
packaged software, but having the static libraries available is
important for some end-users and local administrators.

Debian Policy section 8.3 says,

  The static library (libraryname.a) is usually provided in addition
  to the shared version. It is placed into the development package
  (see below).


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

Re: Development packages.

[Stephen Frost]

* Matt Brubeck ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > We shouldn't be shipping or using static libraries.
> 
> Why not?  I know we shouldn't be linking to static libraries in our
> packaged software, but having the static libraries available is
> important for some end-users and local administrators.

Pffft.  Honestly, I think that claim of end-users and local
administrators using static libraries is rather dated and rarely the
case these days.  Regardless, we shouldn't be using them and the end
users and local admins who actually need to link against things
statically can figure out the dependencies.

Stephen


signature.asc
Description: Digital signature

Re: Development packages.

[Bernhard R. Link]

* Stephen Frost <[EMAIL PROTECTED]> [040322 21:14]:
> Pffft.  Honestly, I think that claim of end-users and local
> administrators using static libraries is rather dated and rarely the
> case these days.  

I do not know, if they are used to make any programs intended for 
production use any more, though I often found them very helpfull 
when debugging things.
Having to recompile whole libraries just to locate some of those
ugly pointer-address relatated bugs makes those assembler near
languages like C and friends much more a pain than it has to be.

Hochachtungsvoll,
  Bernhard R. Link

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


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

Re: Should I always clean in debian/rules before making binary?

[Kalle Kivimaa]

Frank Küster <[EMAIL PROTECTED]> writes:
> As I see it, it is
> From: =?iso-8859-1?q?Frank_K=FCster?= <[EMAIL PROTECTED]>

Yes, that's how I see it as well. My previous reply was based on the
fact that my Gnus surprised me by showing the From-field correctly, if
it is encoded, but NOT showing To, CC or Subject-lines...

So it seems that Frank is doing everything correctly, so there is
either an installation problem at the other end or a bug in Pine.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


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

Re: Development packages.

[Steve Langasek]

On Sun, Mar 21, 2004 at 08:18:35PM +, Roger Leigh wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:

> > We shouldn't be recommending providing staticlly linked libs for people
> > to use, even in the 'fast moving' case- if it's that fast then it
> > probably shouldn't be in Debian and that's just life.

> > .la files shouldn't be included in anything, they're just plain broken.

> Even with static libraries?  The .la does contain dependency
> information.  I know that using pkg-config .pc files can eliminate
> this case, but not everything using libtool is using pkg-config yet.

pkg-config is a *far* worse offender than libtool.  With libtool, we
have some hope of getting these things right in the near future;
pkg-config, OTOH, doesn't even know there *is* a difference between
static and shared libs, so can't be taught to handle them differently
without a lot of growing pains.  Please don't add pkg-config to packages
that don't already have the misfortune of using it!

In general, while policy does require us to ship static libraries, it
does not require shipping .la files to go with them.  If there's a
choice to be made between having a brittle shared library dependency
tree in Debian and having static library users complaining that they
have to link by hand, I know which way I'm gonna vote.  However, with
the pending libtool cleanups (our libtool maintainer is actively
involved with addressing precisely these issues upstream), it should
soon no longer be necessary to make such a choice.

But shipping .la files in non-dev packages should still be a hanging
offense.

Cheers,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Development packages.

[Scott James Remnant]

On Sun, 2004-03-21 at 19:49, Stephen Frost wrote:

> We shouldn't be recommending providing staticlly linked libs for people
> to use, even in the 'fast moving' case- if it's that fast then it
> probably shouldn't be in Debian and that's just life.
> 
> .la files shouldn't be included in anything, they're just plain broken.
> 
Please note that Stephen is talking complete bollocks here and clearly
has little to no understanding of libraries.

If you are creating a library package, you should ship the shared
library (and SONAME symlink) in the libxxxN package and the static
library, name-only symlink *AND* .la file (if relevant) in the
libxxx[N]-dev package.


The "broken"ness he's referring to is that Libtool will link all the
dependency libraries of a library to a program:

libAlibB
   \/
libC

If you link "app" to "libC" with Libtool, app will be linked to libA,
libB and libC.

This is a requirement for most platforms, Linux is fairly unique in that
its dynamic link loader is able to process dependency trees itself and
load the dependencies of a linked library.

In user terms, this has zero effect; the dependency libraries need to
loaded *anyway* so loading them earlier actually *slightly* speeds up
load times of complex apps (esp. Mozilla and friends).


In Debian terms, it's slightly annoying; our "shlibs" tools don't
realise what's going on and suggest more dependencies than are strictly
necessary.  It can also cause annoyances during SONAME changes of
libraries deep in the dependency stack.

There's already a fix for Libtool to ignore dependency_libs when linking
shared libraries on Linux and the next major release should have it.


The .la files then simply convey the required dependencies when linking
a static library, which even on Linux requires you to link in all the
dependencies manually.

This user links statically a hell of a lot when debugging code; I assume
I'm not the only one either.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



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

Re: Development packages.

[Scott James Remnant]

On Mon, 2004-03-22 at 21:29, Steve Langasek wrote:

> On Sun, Mar 21, 2004 at 08:18:35PM +, Roger Leigh wrote:
> > Stephen Frost <[EMAIL PROTECTED]> writes:
> 
> > > We shouldn't be recommending providing staticlly linked libs for people
> > > to use, even in the 'fast moving' case- if it's that fast then it
> > > probably shouldn't be in Debian and that's just life.
> 
> > > .la files shouldn't be included in anything, they're just plain broken.
> 
> > Even with static libraries?  The .la does contain dependency
> > information.  I know that using pkg-config .pc files can eliminate
> > this case, but not everything using libtool is using pkg-config yet.
> 
> pkg-config is a *far* worse offender than libtool.  With libtool, we
> have some hope of getting these things right in the near future;
> pkg-config, OTOH, doesn't even know there *is* a difference between
> static and shared libs, so can't be taught to handle them differently
> without a lot of growing pains.  Please don't add pkg-config to packages
> that don't already have the misfortune of using it!
> 
I've got half a mind, if pkg-config upstream haven't shown any signs of
activity once I've finished fighting my current battles to start
developing it further myself.

Giving it some idea of what's a dependency library and what's a 2nd (or
even 3rd) level dependency would be nice, along with some "I'm linking
statically" and "I'm cross-compiling" logic.

Maybe even make it play nice with Libtool.

> But shipping .la files in non-dev packages should still be a hanging
> offense.
> 
Plugins using libltdl probably need them ... though not until some of
the more exotic ports come to fruition.

"Debian Solaris" anyone? :o)

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



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

Re: Development packages.

[Roger Leigh]

Stephen Frost <[EMAIL PROTECTED]> writes:

> * Matt Brubeck ([EMAIL PROTECTED]) wrote:
>> Stephen Frost wrote:
>> > We shouldn't be shipping or using static libraries.
>> 
>> Why not?  I know we shouldn't be linking to static libraries in our
>> packaged software, but having the static libraries available is
>> important for some end-users and local administrators.
>
> Pffft.  Honestly, I think that claim of end-users and local
> administrators using static libraries is rather dated and rarely the
> case these days.

I used a statically-linked binary just a few days ago.  I needed to
resize an NTFS partition on a newly-delivered system which came with
Windows XP.  In the event, I was able to get a statically linked
binary, copy it onto a floppy and run this after booting from a rescue
disk.

So, it's very useful for rescue situations, where you can't rely on a
whole suite of shared libs, or any installation at all.

It's also useful when you want to provide something that "just work"
with no extra dependencies.  While proprietary/commercial software was
the biggest user of this, it's also useful for free software.  What if
Joe Average would like to run my program which makes use of libstdc++,
GTK+ 2.2 and GNOME 2.4?  It's the least hassle way to achieve this.

> Regardless, we shouldn't be using them and the end
> users and local admins who actually need to link against things
> statically can figure out the dependencies.

Since nearly all -dev packages come with static libs and this is not
forbidded (it's mentioned in Policy) I won't stop using them.  I'll by
happy to stop as soon as Policy forbids/discourages it.


On a related note, I'd also be very happy if it was a requirement to
build libraries with a miniumum of "-g -ggdb -gdwarf-2", and not strip
them.  We could provide some mechanism to automatically strip
binaries, surely?


-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


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

Re: Development packages.

[Roger Leigh]

Andreas Metzler <[EMAIL PROTECTED]> writes:

> On Mon, Mar 22, 2004 at 04:26:49PM +0100, Frank KÃster wrote:

[libtool brokenness]
>> Yes, it did :-|. Could you point me to a documentation where I could
>> read about these problems, and under what weird circumstances it will be
>> a bug nevertheless if I don't install the *la files? 
> [...]
>
> Hello,
> Basically the essence of the mess is #191425. If libfoo links against
> libbar and application blah makes use of libfoo (but does not use
> libbar) libtool will link the application against both libraries.

How is this different to pkg-config:

$ pkg-config --libs libglademm-2.0
-Wl,--export-dynamic -lglademm-2.0 -lgtkmm-2.0 -lglade-2.0 -lgdkmm-2.0
 -latkmm-1.0 -lpangomm-1.0 -lglibmm-2.0 -lsigc-1.2 -lgtk-x11-2.0
 -lxml2 -lpthread -lz -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0
 -ldl -lglib-2.0

Whew!  Yet in reality, -lglademm-2.0 would have sufficed...


-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.