On Mon, Jan 07, 2008 at 10:02:17PM -0600, Raphael Geissert wrote:
Filippo Giunchedi [EMAIL PROTECTED]
bluez-cups (U)
bluez-utils (U)
fixed in unstable
libbtctl4 (U)
python-libbtctl (U)
Filippo Giunchedi [EMAIL PROTECTED]
gnome-bluetooth (U)
libgnomebt0 (U)
will fix
On Tue, Jan 08, 2008 at 06:20:20AM +0100, Cyril Brulebois wrote:
On 08/01/2008, Michal Čihař wrote:
Adding --disable-rpath to configure might be easier solution for this
problem.
Another workaround is chrpath.
which is my preferred dirty trick when I'm not enable to manage the
upstream
On Jan 8, 2008 1:32 PM, Raphael Geissert [EMAIL PROTECTED] wrote:
Some time ago I noticed some packages were defining a RPATH on non i386
architectures, notably amd64.
Is either of these planned?
* Make lintian.d.o process debs from architectures other than i386/all
* A way to put all these
Cyril Brulebois wrote:
On 08/01/2008, Michal Čihař wrote:
Adding --disable-rpath to configure might be easier solution for this
problem.
Another workaround is chrpath.
According to some people (I remember reading something about it in -mentors)
chrpath doesn't always remove the rpath,
Russ Allbery wrote:
That's what we do now. It takes about a half-hour, usually, or less.
However, when I upgrade lintian.d.o to a new version of lintian, I have to
regenerate the entire results for the whole archive to have consistent
results, and I don't want that to take a week.
I
Raphael Geissert [EMAIL PROTECTED] writes:
Russ Allbery wrote:
It already takes over a day for Lintian to process the entire archive,
so I don't have any immediate plans to run it on more architectures
unless we can find some dramatic way to speed it up or find other
places to run it besides
Raphael Geissert [EMAIL PROTECTED] writes:
Russ Allbery wrote:
I suppose we could do something fancy where the archive is rebuilt in
the background, but gluck doesn't have a lot of spare cycles as it is,
and I'm not sure it's worth the effort at the moment to get coverage of
the remaining
On Jan 9, 2008 5:15 AM, Russ Allbery [EMAIL PROTECTED] wrote:
* Make lintian.d.o process debs from architectures other than i386/all
It already takes over a day for Lintian to process the entire archive, so
I don't have any immediate plans to run it on more architectures unless we
can find
Paul Wise [EMAIL PROTECTED] writes:
Perhaps lucas could use his access to Grid'5000 to do these lintian runs
when you upgrade lintian? I imagine that would take very little time to
do on the grid. There would need to be some way of merging the results
back to lintian.d.o and ensuring the same
On Tue, 2008-01-08 at 17:01:27 -0800, Russ Allbery wrote:
Oh, the other challenge with running lintian across multiple architectures
is that, at least in previous days, some things didn't work right unless
the binutils installed corresponded to the package architecture. I wonder
if that's
Guillem Jover [EMAIL PROTECTED] writes:
On Tue, 2008-01-08 at 17:01:27 -0800, Russ Allbery wrote:
Oh, the other challenge with running lintian across multiple
architectures is that, at least in previous days, some things didn't
work right unless the binutils installed corresponded to the
Russ Allbery wrote:
Oh, the other challenge with running lintian across multiple architectures
is that, at least in previous days, some things didn't work right unless
the binutils installed corresponded to the package architecture. I wonder
if that's still true.
What kind of problems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all,
Some time ago I noticed some packages were defining a RPATH on non i386
architectures, notably amd64. This seems to be caused by an old auto* file,
but there might be other reasons as well.
I've run an archive wide lintian check on all
Hi
On Mon, 07 Jan 2008 22:02:17 -0600
Raphael Geissert [EMAIL PROTECTED] wrote:
Michal Čihař [EMAIL PROTECTED]
enca
Fixed in svn.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
signature.asc
Description: PGP signature
Raphael Geissert [EMAIL PROTECTED] writes:
Some time ago I noticed some packages were defining a RPATH on non i386
architectures, notably amd64. This seems to be caused by an old auto*
file, but there might be other reasons as well.
The problem is with the following code in libtool.m4:
#
Russ Allbery [EMAIL PROTECTED] writes:
Therefore, rerunning libtoolize before compilation will fix this problem
for most packages.
Hm, actually, since it's in the .m4 file and not in ltmain.sh, you may
have to do more than that. I'd have to experiment. I'm not completely
sure what libtoolize
Hi
On Mon, 07 Jan 2008 20:24:35 -0800
Russ Allbery [EMAIL PROTECTED] wrote:
Russ Allbery [EMAIL PROTECTED] writes:
Therefore, rerunning libtoolize before compilation will fix this problem
for most packages.
Hm, actually, since it's in the .m4 file and not in ltmain.sh, you may
have to
Michal Čihař [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] wrote:
Hm, actually, since it's in the .m4 file and not in ltmain.sh, you may
have to do more than that. I'd have to experiment. I'm not completely
sure what libtoolize will do and whether it will mangae to upgrade the
Hi,
Michal Čihař wrote:
Adding --disable-rpath to configure might be easier solution for this
problem.
I've found packages that even when the --disable-rpath flag is set the
binaries have a defined rpath.
This is actually how I noticed the whole rpath problem on non i386 archs the
first
On 08/01/2008, Michal Čihař wrote:
Adding --disable-rpath to configure might be easier solution for this
problem.
Another workaround is chrpath.
--
Cyril Brulebois
pgp0znAJnoiDS.pgp
Description: PGP signature
20 matches
Mail list logo
