On Mon, 2016-12-12 at 04:26:20 +0100, Marco d'Itri wrote:
> On Nov 21, Guillem Jover wrote:
> > First I have to go over a list of queued pending items and then I'll
> > get to this during this week. I have not yet reviewed the patches (in
> > part because I didn't do much Debian stuff last week du
On Nov 21, Guillem Jover wrote:
> First I have to go over a list of queued pending items and then I'll
> get to this during this week. I have not yet reviewed the patches (in
> part because I didn't do much Debian stuff last week due to lack of
> motivation after an unpleasant interaction precise
[ Please follow up on d-d and d-cross (M-F-T set). ]
Hi!
There are several cleanups and order changes in the pipe for the default
dpkg-shlibdeps shared library directory search list in dpkg 1.18.x.
It was previously, in decreasing order of preference:
0. «dpkg-shlibdeps -l» (or via
ah yes of course. Thank you.
On Sun, Sep 15, 2013 at 12:17 AM, Steve Langasek wrote:
> On Sun, Sep 15, 2013 at 12:07:17AM -0500, Pedro DeKeratry wrote:
> > I received the following warnings when building with dpkg-buildpackage
>
> > dpkg-shlibdeps: warning: symbol pthre
On Sun, Sep 15, 2013 at 12:07:17AM -0500, Pedro DeKeratry wrote:
> I received the following warnings when building with dpkg-buildpackage
> dpkg-shlibdeps: warning: symbol pthread_sigmask used by
> debian/libyrp/usr/lib/libyrp.so.2.0.0 found in none of the libraries
> dpkg-shlibd
I received the following warnings when building with dpkg-buildpackage
dpkg-shlibdeps: warning: symbol pthread_sigmask used by
debian/libyrp/usr/lib/libyrp.so.2.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol pthread_join used by
debian/libyrp/usr/lib/libyrp.so.2.0.0 found in
On Mon, 04 Apr 2011 17:05:01 +0200
Sim IJskes wrote:
> what is missing in the package configuration when dpkg-shlibdeps does
> not visit debian/tmp/usr/lib to find the libraries?
Try debian-ment...@lists.debian.org in future for these questions.
Often it can be looking in debian/foo/u
what is missing in the package configuration when dpkg-shlibdeps does
not visit debian/tmp/usr/lib to find the libraries?
Are these considered the private libraries in:
To help dpkg-shlibdeps find private libraries, you might need to set
LD_LIBRARY_PATH.
Gr. Sim
--
To UNSUBSCRIBE, email
clone 533642 -1
reassign -1 libgcc1 1:4.4.0-7
retitle -1 Ensure __aeabi_* symbols are listed in libgcc1.symbols for armel
severity -1 important
thanks
On Sat, 20 Jun 2009, Raphael Hertzog wrote:
> I think that to properly resolve my issue I have to allow you to export
> those blacklisted symbols i
On Sat, 20 Jun 2009, Matthias Klose wrote:
> > Under normal curcumstances, I'd expect every shared library and application
> > to
> > require __aeabi_* from libgcc. Under normal circumstances these will come
> > from
> > libgcc_s.so, but if you link with --static-libgcc then you'll get your ow
Paul Brook schrieb:
>> Now it seems that the irrlicht library depends on those symbols
>> provided by libgcc_s.so.1 (and does not define them locally contrary to
>> what was seen by Aurélien in libvorbis in #462318) and of course
>> dpkg-shlibdeps complains because th
On Fri, 19 Jun 2009, Paul Brook wrote:
> >Now it seems that the irrlicht library depends on those symbols
> >provided by libgcc_s.so.1 (and does not define them locally contrary to
> >what was seen by Aurélien in libvorbis in #462318) and of course
> >dpkg-shlibdeps complai
>Now it seems that the irrlicht library depends on those symbols
>provided by libgcc_s.so.1 (and does not define them locally contrary to
>what was seen by Aurélien in libvorbis in #462318) and of course
>dpkg-shlibdeps complains because they can't be found in the symbols file.
&
On Fri, 19 Jun 2009, Christoph Egger wrote:
> Building the NEW package I'm working on (irrlicht [3]) on my
> ARM(el)[4] box (up-to-date sid pbuilder) causes dpkg-shlibdeps to
> complain about missing symbols [0]. These symbols seem to be some gcc
> internals that sho
d, which doesn't happen automatically.
I just wanted to know if it would be OK for dpkg-shlibdeps to use only
one package for a library (eg. in case of diversions, use dpkg-divert to
find the right one) and fail in case of ambiguity.
What is the right one, the non-diverted one ?
I&#x
't provide
dependencies that are compatible (even if not exactly the same).
> I just wanted to know if it would be OK for dpkg-shlibdeps to use only
> one package for a library (eg. in case of diversions, use dpkg-divert to
> find the right one) and fail in case of ambiguity.
What i
to have both packages in sync.
I just wanted to know if it would be OK for dpkg-shlibdeps to use only one
package for a library (eg. in case of diversions, use dpkg-divert to find
the right one) and fail in case of ambiguity.
Regards
Jiri Palecek
--
To UNSUBSCRIBE, email to debia
On Thu, 30 Apr 2009, Jiří Paleček wrote:
> Yes, but even then, libGL.so.1 (the one used for building a package) is
> only mentioned in one symbol file, namely the one from nvidia-glx, isn't
> it (let's put aside the package doesn't feature a symbol file)? Why
> should the libgl1-mesa-glx symbo
On Wed, 29 Apr 2009 19:40:12 +0200, Josselin Mouette
wrote:
Le mercredi 29 avril 2009 à 18:51 +0200, Jiří Paleček a écrit :
I've hacked a little into dpkg-shlibdeps and while doing this, I've
found
that the code makes allowance for a single library being mentioned in
two
Le mercredi 29 avril 2009 à 18:51 +0200, Jiří Paleček a écrit :
> I've hacked a little into dpkg-shlibdeps and while doing this, I've found
> that the code makes allowance for a single library being mentioned in two
> different symbol files. I'd like to ask if (and
Hello,
I've hacked a little into dpkg-shlibdeps and while doing this, I've found
that the code makes allowance for a single library being mentioned in two
different symbol files. I'd like to ask if (and when) can such situation
actually arise.
Regards
Jiri Palecek
-
Hello,
Neil answered me off-list. I'm putting this info on-list just FYI
-- Forwarded message --
From: Neil Williams <[EMAIL PROTECTED]>
Date: 27/11/2007 20:01
Subject: Re: Fwd: About dpkg-shlibdeps checks
To: Hector Oron <[EMAIL PROTECTED]>
Cc: Wookey
Hi,
On Tue, 27 Nov 2007, Hector Oron wrote:
> > Until dpkg-shlibdeps has been modified to support natively cross-build,
> > you'll have to indicate him where to find libraries for other
> > architectures with LD_LIBRARY_PATH=/usr/arm-linux-gnu/lib/ or similar.
>
> Th
Hello,
> Until dpkg-shlibdeps has been modified to support natively cross-build,
> you'll have to indicate him where to find libraries for other
> architectures with LD_LIBRARY_PATH=/usr/arm-linux-gnu/lib/ or similar.
Thanks, it look like it somehow worked, but then i'm miss
tions did work though.
--dpkg-shlibdeps-params=--ignore-missing-info
/Sune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, 26 Nov 2007, Hector Oron wrote:
> I tried with option: -uignore-missing-info
>
> ARCH=arm MAKEFLAGS="CC=something" dh_shlibdeps -plibgcc1-arm-cross
> -uignore-missing-info
> dpkg-shlibdeps: failure: couldn't find library libc.so.6 (note: only
> packages wi
I tried with option: -uignore-missing-info
ARCH=arm MAKEFLAGS="CC=something" dh_shlibdeps -plibgcc1-arm-cross
-uignore-missing-info
dpkg-shlibdeps: failure: couldn't find library libc.so.6 (note: only
packages with 'shlibs' files are looked into).
dh_shlibdeps: comman
DEBIAN/shlibs.fixed
debian/libgcc1-arm-cross/DEBIAN/shlibs
cat debian/libgcc1-arm-cross/DEBIAN/shlibs >> debian/shlibs.local
ARCH=arm MAKEFLAGS="CC=something" dh_shlibdeps -plibgcc1-arm-cross
dpkg-shlibdeps: failure: couldn't find library libc.so.6 (note: only
packages with '
On Sat, 2007-11-24 at 10:07 +0100, Raphael Hertzog wrote:
> On Sat, 24 Nov 2007, Soeren Sonnenburg wrote:
> > But what is the intended way of fixing things with the newer
> > dpkg-shlibdeps ? Adding --rpath ?
>
> Helping dpkg-shlibdeps with LD_LIBRARY_PATH is the right thi
On Sat, 24 Nov 2007, David Moreno Garza wrote:
> After my last attempts to rebuild the archive (using rebuildd) on
> powerpc, I've faced that given this, lots of packages now FTBFS.
I know, and I expect most of them to not happen any more with dpkg
1.14.11.
In any case, I've asked Lucas to do a f
On Sat, Nov 24, 2007 at 07:26:41PM +, David Moreno Garza wrote:
> On Fri, 2007-11-23 at 10:39 +0100, Raphael Hertzog wrote:
> > Hello,
> >
> > as announced in
> > http://lists.debian.org/debian-devel-announce/2007/09/msg00004.html the
> > new dpkg-shlibdeps i
On Fri, 2007-11-23 at 10:39 +0100, Raphael Hertzog wrote:
> Hello,
>
> as announced in
> http://lists.debian.org/debian-devel-announce/2007/09/msg4.html the
> new dpkg-shlibdeps is stricter in what it accepts and will fail when it
> can't find dependency information for
On Sat, 24 Nov 2007, Soeren Sonnenburg wrote:
> But what is the intended way of fixing things with the newer
> dpkg-shlibdeps ? Adding --rpath ?
Helping dpkg-shlibdeps with LD_LIBRARY_PATH is the right thing as you did
below... (option -l for dh_shlibdeps)
> $ LD_LIBRARY_PATH=/usr/l
On Fri, 2007-11-23 at 10:39 +0100, Raphael Hertzog wrote:
> Hello,
Hello,
> as announced in
> http://lists.debian.org/debian-devel-announce/2007/09/msg4.html the
> new dpkg-shlibdeps is stricter in what it accepts and will fail when it
> can't find dependency informatio
On Fri, 23 Nov 2007, Luk Claes wrote:
> Nowadays there are better alternatives to uploading to unstable for
> archive wide testing IMHO. Uploading to experimental is a good thing to
> have some initial testing on many architectures, though I would go for a
> rebuild of the whole archive for testing
. So we had a
> >>> clue on how many packages are affected. The list has probably evolved
> >>> since september but not by much.
> >> Except covering kde now. KDE didn't change that much since september.
> >
> > Apparently not any more with the dpkg-sh
bably evolved
>>> since september but not by much.
>> Except covering kde now. KDE didn't change that much since september.
>
> Apparently not any more with the dpkg-shlibdeps that implements the exceptions
> that I listed in my first mail... (you know it since you tested
On Fri, Nov 23, 2007 at 01:40:39PM +, Raphael Hertzog wrote:
> I'd rather be more strict and relax the rules as we identify cases where I
> have been too strict, than let people upload broken .debs during weeks and
> later discover that we have to scan the full archive to rebuild
> a bunch of
'd expect you to make lower the dpkg-shlibdeps
> expectations for a while, so that we can take our time to catalog every
> issues that it raise.
If only things were as simple as that.
Go read #452339 and understand that the new dpkg-shlibdeps fully respects
any local ld.so.conf configur
On ven, nov 23, 2007 at 11:31:57 +, Raphael Hertzog wrote:
> But I'm just not willing to fully revert a decision
Damn I wanted to answer to that, and forgot: I don't think anyone
wants a revert. I'd expect you to make lower the dpkg-shlibdeps
expectations for a while, s
On 2007-11-23, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> they have some fixing to do (in particular when it looks like they don't
> really understand the issues at hand).
If this was targetted at me, then please explain me what I don't really
understand.
/Sune
--
To UNSUBSCRIBE, email to [E
On ven, nov 23, 2007 at 11:31:57 +, Raphael Hertzog wrote:
> (in particular when it looks like they don't really understand the
> issues at hand).
Please, this ad hominem isn't deserved, because the KDE team could
exactly answer the same to you. Mind you, but the huge workload you just
infli
sures.
The disruption it caused to the KDE guys (and I fear for OOo or
moizilla) isn't _that_ surprising to me, and it's completely unfair to
prevent them from doing anything. Because that's what dpkg-shlibdeps
does: the KDE team think it's a 3days effort to support the new
ut not by much.
>
> Except covering kde now. KDE didn't change that much since september.
Apparently not any more with the dpkg-shlibdeps that implements the exceptions
that I listed in my first mail... (you know it since you tested it for me)
I'm willing to take some blame,
Pierre Habouzit wrote:
> But forcing every maintainer that probably had an agenda for their
> package already, to comply to yours without even knowing what's coming
> is at the very least tactless and disruptive.
the new dpkg was in experimental for a long enough time, and this was
announced of
On ven, nov 23, 2007 at 10:14:51 +, Raphael Hertzog wrote:
> On Fri, 23 Nov 2007, Pierre Habouzit wrote:
> > does your plan include having a version of the dpkg-shlibdeps that
> > works in "warning-mode" only so that we can have a more extensive idea
> > of
On 2007-11-23, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> Well, the d-d-a mail included a list of affected packages. So we had a
> clue on how many packages are affected. The list has probably evolved
> since september but not by much.
Except covering kde now. KDE didn't change that much since s
On Fri, 23 Nov 2007, Pierre Habouzit wrote:
> does your plan include having a version of the dpkg-shlibdeps that
> works in "warning-mode" only so that we can have a more extensive idea
> of how the things are going to be, before it stops the development of
> the bigge
On Fri, Nov 23, 2007 at 09:39:58AM +, Raphael Hertzog wrote:
> Hello,
>
> as announced in
> http://lists.debian.org/debian-devel-announce/2007/09/msg4.html the
> new dpkg-shlibdeps is stricter in what it accepts and will fail when it
> can't find dependency informa
Hello,
as announced in
http://lists.debian.org/debian-devel-announce/2007/09/msg4.html the
new dpkg-shlibdeps is stricter in what it accepts and will fail when it
can't find dependency information for a library that is used by an
executable or a public library (a public library is defin
On Tue, Nov 13, 2007 at 08:59:32PM +0100, Josselin Mouette wrote:
> Le mardi 13 novembre 2007 à 11:01 -0800, Steve Langasek a écrit :
> > > The current packages install the dynamic libraries simply to /usr/lib
> > > which I want to fix now. They should go to
> > > ${ARB_HOME}/lib
> > FWIW,
On Sat, Nov 17, 2007 at 04:24:18PM +, Ian Jackson wrote:
> Steve Langasek writes ("Re: dpkg-shlibdeps and private libraries"):
> > On Tue, Nov 06, 2007 at 08:51:05AM +0100, Andreas Tille wrote:
> > FWIW, I don't agree that this is a fix. In one sense it makes /u
Steve Langasek writes ("Re: dpkg-shlibdeps and private libraries"):
> On Tue, Nov 06, 2007 at 08:51:05AM +0100, Andreas Tille wrote:
> FWIW, I don't agree that this is a fix. In one sense it makes /usr/lib
> "cleaner" by moving private libs into a private dire
On Tue, 13 Nov 2007, Steve Langasek wrote:
FWIW, I don't agree that this is a fix. In one sense it makes /usr/lib
"cleaner" by moving private libs into a private directory; however:
Well, I'm perfectly willing to adopt your suggestions, but I have to admit
that the authors of this software do
Hi,
Le mardi 13 novembre 2007 à 11:01 -0800, Steve Langasek a écrit :
> > The current packages install the dynamic libraries simply to /usr/lib
> > which I want to fix now. They should go to
>
> > ${ARB_HOME}/lib
>
> FWIW, I don't agree that this is a fix. In one sense it makes /usr/lib
>
On Tue, Nov 06, 2007 at 08:51:05AM +0100, Andreas Tille wrote:
> At installation time the filles will be installed to a directory
> ARB_HOME=/usr/lib/arb
> were the binaries go to
> ${ARB_HOME}/bin
> The current packages install the dynamic libraries simply to /usr/lib
> which I want
On Tue, Nov 06, 2007 at 10:18:43AM +, Ben Hutchings wrote:
> You should use "-Wl,-rpath -Wl,/usr/lib/arb/lib" instead of
> "-Lrpath /usr/lib/arb/lib".
Better use the shorter form "-Wl,-rpath,/usr/lib/arb/lib".
Bastian
--
The best diplomat I know is a fully activated phaser bank.
On Tue, 2007-11-06 at 08:51 +0100, Andreas Tille wrote:
> Could anybody enlighten me what compiler options I have to give to
> enable compile time and runtime correctly working. I tried
>
> g++ ... -Lrpath /usr/lib/arb/lib ... -L/lib
>
> which just caused
>
> /usr/bin/ld: /usr/lib/a
Hi,
I would like to seek for some clarification of the thread from September
this year because I also have to use the rpath feature, but it became
not really clear to me, how this has to be used. I need it for the
package arb. At compile time the libraries are
/lib/lib*.so
the binaries t
> libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment
> variable apparently defined by the openoffice startup script/program
No.
$ORIGIN is dynamic linker feature, it is expanded to the directory where
executable resides.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
On Wed, Sep 26, 2007 at 10:36:18AM +, Reinhard Tartler wrote:
> Raphael Hertzog <[EMAIL PROTECTED]> writes:
>
> > libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment
> > variable apparently defined by the openoffice startup script/program.
> > This variable is not set a bu
On Wed, Sep 26, 2007 at 11:30:27AM +0200, Raphael Hertzog <[EMAIL PROTECTED]>
wrote:
> Hello,
>
> _rene_ reported me a failure with openoffice and the new dpkg-shlibdeps.
>
>
> Scanning
> debian/openoffice.org-writer/usr/lib/openoffice/program/libswui680lp.so
&
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment
> variable apparently defined by the openoffice startup script/program.
> This variable is not set a build time (and the code wasn't expecting
> variables at that place anyway).
> I would suggest that, there are a few programs out there which use
> many internal use shlibs without a soname and a more complex
> tree of dirs to pick up their stuff than a single directory.
Also all Java JNI libraries dont use SONAMEs. I guess these can be
problematic for new dpkg-shl
On Wed, Sep 26, 2007 at 11:30:27AM +0200, Raphael Hertzog wrote:
> On the other hand, maybe I should just be less picky for shared objects
> without SONAME... I'm not sure about it.
>
I would suggest that, there are a few programs out there which use
many internal use shlibs without a soname and
Hello,
_rene_ reported me a failure with openoffice and the new dpkg-shlibdeps.
Scanning debian/openoffice.org-writer/usr/lib/openoffice/program/libswui680lp.so
(for Depends field)
dpkg-shlibdeps: failure: couldn't find library libsw680lp.so (note: only
packages with 'shlibs&
Hi Raphael,
On Thu, Jun 21, 2007 at 09:59:53AM +0100, Raphael Hertzog wrote:
> ace-of-penguins_1.2-8_sid32.buildlog:dpkg-shlibdeps: warning: Symbol [EMAIL
> PROTECTED] used by debian/ace-of-penguins/usr/lib/libcards.so.1.0.0 found in
> none of the libraries.
> -> here's y
[Raphael Hertzog]
> > Also, please omit @Base from the log messages, it adds visual clutter
> > without adding information.
>
> Well, it can be worthwhile to know which version the symbol is attached
> to. If I remove it, I only remove @Base and not @GLIBC_2.4 or any other
> versions.
Yeah, I me
On Thu, 21 Jun 2007, Peter Samuelson wrote:
>
> [Raphael Hertzog]
> > If you encounter any strangeness, please report it so that we can
> > check. Those warnings could be the base of some mass-bug filings
> > althought we might want to start with the second one (those are real
> > bugs, while the
On Thu, Jun 21, 2007 at 09:59:53AM +0100, Raphael Hertzog wrote:
> Hello,
>
> Lucas just rebuilt the archive with my new dpkg-shlibdeps and the symbols
> file that I provided him
> (http://people.debian.org/~hertzog/symbols.tar.bz2) and that I
> auto-generated.
>
> The re
[Raphael Hertzog]
> If you encounter any strangeness, please report it so that we can
> check. Those warnings could be the base of some mass-bug filings
> althought we might want to start with the second one (those are real
> bugs, while the other are not creating any technical problem (except
>
Hello,
Lucas just rebuilt the archive with my new dpkg-shlibdeps and the symbols
file that I provided him
(http://people.debian.org/~hertzog/symbols.tar.bz2) and that I
auto-generated.
The resulting Packages file is here:
http://people.debian.org/~hertzog/Packages.gz (it contains only
binary
tool chain in unstable:
>> dpkg-shlibdeps: warning: could not find path for libkafs4.so.0
>> dpkg-shlibdeps: warning: could not find path for libkrb.so.1
>> dpkg-shlibdeps: warning: could not find path for libroken.so.16
>> dpkg-shlibdeps: warning: could not find path for
On Tue, Aug 16, 2005 at 01:34:56PM -0700, Russ Allbery wrote:
> For the past week, I've started getting errors like the following when
> building any packages in pbuilder that include shared libraries with the
> current tool chain in unstable:
>
> dpkg-shlibdeps: warning: cou
For the past week, I've started getting errors like the following when
building any packages in pbuilder that include shared libraries with the
current tool chain in unstable:
dpkg-shlibdeps: warning: could not find path for libkafs4.so.0
dpkg-shlibdeps: warning: could not find path for libk
should I write my
> dependencies manually, not using dh_shlibdeps?
You can use debian/shlibs. You will find documentation about this
in the man page for dpkg-shlibdeps.
> If you answer, PLEASE CC to me, as I don't read debian-devel
> regularly.
Greetings,
Oliver
--
.'&
On Tue, Dec 09, 2003 at 07:44:48PM +0100, Adam Byrtek / alpha wrote:
> I maintain a program which needs to depend on certain version of some
> library (the earlier ones are incompatibile, despite soname wasn't
> changed), but I would also like to use shlib:Depends for other
> libraries.
Shared li
Hi,
I maintain a program which needs to depend on certain version of some
library (the earlier ones are incompatibile, despite soname wasn't
changed), but I would also like to use shlib:Depends for other
libraries.
Now I use:
Depends: libtlen1 (>= 20021117), ${shlibs:Depends}
But it generates d
hi folks,
i am playing around with one of the orphaned packages (check) and i want
to build a new package of it. so far everything went fine, but there are
two things that i don't understand:
- dpkg-shlibdeps and therefore dh_shlibdeps fail because dpkg-shlibdeps
doesn't recognize th
it is).
>
> > Ok. Of course, you are right ;) I've added (>= 2.0.7u) to
> > /var/lib/dpkg/info/fakeroot.shlibs and now it works, but I think
> > dpkg-shlibdeps should know that "libc6, libc6 (>= 2.0.7u)" should
> > be "libc6 (>= 2.0.7u)"
Adam P. Harris wrote:
> > Ok. Of course, you are right ;) I've added (>= 2.0.7u) to
> > /var/lib/dpkg/info/fakeroot.shlibs and now it works, but I think
> > dpkg-shlibdeps should know that "libc6, libc6 (>= 2.0.7u)" should
> > be "libc6 (>=
gt;= 2.0.7u) to
> /var/lib/dpkg/info/fakeroot.shlibs and now it works, but I think
> dpkg-shlibdeps should know that "libc6, libc6 (>= 2.0.7u)" should
> be "libc6 (>= 2.0.7u)". Anyway, I don't know much about how shlibs
> stuff works...
Um, what is the ri
On Friday, October 9 1998, at 21:19:38, James Troup wrote:
: Roberto Lumbreras <[EMAIL PROTECTED]> writes:
:
: > Package: dpkg-dev
: > Version: 1.4.0.30
: >
: > $ dpkg-shlibdeps src/fortify; cat debian/substvars
: > shlibs:Depends=libc6 (>= 2.0.7u)
: >
: > $ faker
Roberto Lumbreras <[EMAIL PROTECTED]> writes:
> Package: dpkg-dev
> Version: 1.4.0.30
>
> $ dpkg-shlibdeps src/fortify; cat debian/substvars
> shlibs:Depends=libc6 (>= 2.0.7u)
>
> $ fakeroot dpkg-shlibdeps src/fortify; cat debian/substvars
> shlib
Package: dpkg-dev
Version: 1.4.0.30
$ dpkg-shlibdeps src/fortify; cat debian/substvars
shlibs:Depends=libc6 (>= 2.0.7u)
$ fakeroot dpkg-shlibdeps src/fortify; cat debian/substvars
shlibs:Depends=libc6, libc6 (>= 2.0.7u)
^ ^
:-?
Ideas??
PS: libtrick'
libgimp 1 libgimp1
libgimpui 1 libgimp1
libgck 0 libgimp1
yet dpkg-shlibdeps on binaries linked with these libraries doesn't
make debian/substvars contain libgimp1.
What am I doing wrong?
--
Brought to you by the letters U and Y and the number 15.
"Egad! A base tone denotes a b
In article <[EMAIL PROTECTED]> you write:
>Are we supposed to use dpkg-shlibdeps for all dependecies upon shared libs?
I believe so, yes.
>Or is it just for the three (or so) installed in /etc/dpkg/shlibs.default?
Ian will correct me if I'm wrong, but I think (under the New
Are we supposed to use dpkg-shlibdeps for all dependecies upon shared libs?
Or is it just for the three (or so) installed in /etc/dpkg/shlibs.default?
So what do I do with xpm for instance?
Michael
--
Michael Meskes |_ __
[EMAIL PROTECTED
88 matches
Mail list logo
