Hello,
Hum, in theory /usr/lib32 is checked first. What's the output of
the failing dpkg-shlibdeps call if you add the -v option ?
The relevant lines are:
Library libidn.so.11 found in /emul/ia32-linux/usr/lib/libidn.so.11
No associated package found for /emul/ia32-linux/usr/lib/libidn.so.11
Processing commands for cont...@bugs.debian.org:
tags 581544 + patch
Bug #581544 [dpkg] /usr/bin/dpkg-divert: useless errors on not writable
destination if source does not exist
Added tag(s) patch.
thanks
Stopping processing here.
Please contact me if you need assistance.
--
581544:
Do you have LD_LIBRARY_PATH set during the build process?
I did not explicitly set LD_LIBRARY_PATH, I just appended a directory to
it by using the -l parameter of dh_shlibdeps.
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
tags 581544 + patch
thanks
Version: 1.15.7.2
I attach a patch that stops dpkg-divert --rename doing useless checking
(and emitting useless errors) if the source file of the rename does not
exist.
I successfully tested this in a few piuparts runs (on the
nvidia-graphics-drivers* packages) where
Package: dpkg
Version: 1.15.7.2
Severity: normal
Hi,
the fsync()/sync() changes done recently cause significant performance
loss of dpkg when used in chroot environments living on tmpfs.
For short-lived chroots that cause a lot of e.g. dpkg activity (e.g.
pbuilder environments while building,
On Wed, 07 Jul 2010, Christoph Pleger wrote:
Do you have LD_LIBRARY_PATH set during the build process?
I did not explicitly set LD_LIBRARY_PATH, I just appended a directory to
it by using the -l parameter of dh_shlibdeps.
That's the same... what's this directory and why did you do that?
Hi,
On Wed, 07 Jul 2010, Andreas Beckmann wrote:
Version: 1.15.7.2
I attach a patch that stops dpkg-divert --rename doing useless checking
(and emitting useless errors) if the source file of the rename does not
exist.
dpkg-divert has been rewritten in C in the master branch of the git
Hi kernel team,
Andreas Beckmann wrote:
Unfortunately since the last dpkg changes concerning sync()/fsync() this
no longer works out well - the continuous sync() from a virtual chroot
on tmpfs hits the physical system really hard, causing speed loss
factors between 3-5, probably more if
8 matches
Mail list logo
