On Sun, Jan 14, 2007 at 04:25:43PM +0100, Loïc Minier wrote:
It's still bletcherous special-casing IMO. Maintainer's choice whether to
adopt this solution in the short term, but it's just going to mean changing
again as we move to a solid multiarch solution.
It's hard for me to get a
On Sat, Jan 13, 2007, Steve Langasek wrote:
So i386/ia64 and i386/amd64 are the only biarch cases where having gtk for
the non-default ABI makes much sense.
Aren't there sparc64 and powerpc64 ports out of Debian or in the plans?
If there are, it might make sense to spare the time of
On Sun, Jan 14, 2007 at 09:50:34AM +0100, Loïc Minier wrote:
On Sat, Jan 13, 2007, Steve Langasek wrote:
So i386/ia64 and i386/amd64 are the only biarch cases where having gtk for
the non-default ABI makes much sense.
Aren't there sparc64 and powerpc64 ports out of Debian or in the plans?
On Sat, Jan 13, 2007 at 04:37:11PM -0800, Steve Langasek wrote:
On Sat, Jan 13, 2007 at 10:19:52AM +0100, Loïc Minier wrote:
On Fri, Jan 12, 2007, Steve Langasek wrote:
If you're going to use non-standard paths at all, why would you not move
this to /usr/lib/i486-linux-gnu, which is also
On Sun, Jan 14, 2007 at 09:50:34AM +0100, Loïc Minier wrote:
On Sat, Jan 13, 2007, Steve Langasek wrote:
So i386/ia64 and i386/amd64 are the only biarch cases where having gtk for
the non-default ABI makes much sense.
Aren't there sparc64 and powerpc64 ports out of Debian or in the plans?
On Sat, Jan 13, 2007, Steve Langasek wrote:
That shouldn't prevent using /usr/lib/i486-linux-gnu/pango as a modules
subdir, because binutils doesn't need to know about /that/ path. It does
prevent moving libpango.so to /usr/lib/i486-linux-gnu until binutils
supports it.
Aurélien commented
Resulting patch is attached for comments; binary packages available at:
http://people.dooz.org/~lool/debian/pango1.0/1.14.8-5/sid-pbuilder/
--
Loïc Minier [EMAIL PROTECTED]
--- pango1.0-1.14.8.orig/pango/modules.c 2007-01-14 17:38:08.0 +0100
+++ pango1.0-1.14.8/pango/modules.c
On Sun, Jan 14, 2007, Loïc Minier wrote:
+ if (g_access(compat_module_files_d_str, R_OK|X_OK))
That was inverted; I've re-uploaded fixed binaries.
--
Loïc Minier [EMAIL PROTECTED]
Aurelien Jarno [EMAIL PROTECTED] writes:
On Sat, Jan 13, 2007 at 04:37:11PM -0800, Steve Langasek wrote:
On Sat, Jan 13, 2007 at 10:19:52AM +0100, Loïc Minier wrote:
On Fri, Jan 12, 2007, Steve Langasek wrote:
If you're going to use non-standard paths at all, why would you not move
this
On Sat, Jan 13, 2007, Goswin von Brederlow wrote:
The patch had a minor bug for /etc/pango32. It tested for /etc/pango32
but then overwrote the reult with /etc/pango anyway. Which is ok as
there seems to be no architecture specific file left in /etc/pango,
only the font aliases.
It's not
On Fri, Jan 12, 2007, Steve Langasek wrote:
If you're going to use non-standard paths at all, why would you not move
this to /usr/lib/i486-linux-gnu, which is also already part of the system
lib path in etch and is much better future-proofed than the alternatives?
I'm willing to use whatever
Steve Langasek [EMAIL PROTECTED] writes:
On Fri, Jan 12, 2007 at 08:19:18PM +0100, Goswin von Brederlow wrote:
As for using /usr/lib32 on i386 that is totaly up to you. On i386
/usr/lib32 does not yet exist but I don't see a reason not to create
it. Note that you can't have system libraries
Loïc Minier [EMAIL PROTECTED] writes:
On Sat, Jan 13, 2007, Goswin von Brederlow wrote:
The patch had a minor bug for /etc/pango32. It tested for /etc/pango32
but then overwrote the reult with /etc/pango anyway. Which is ok as
there seems to be no architecture specific file left in
Loïc Minier [EMAIL PROTECTED] writes:
On Fri, Jan 12, 2007, Steve Langasek wrote:
If you're going to use non-standard paths at all, why would you not move
this to /usr/lib/i486-linux-gnu, which is also already part of the system
lib path in etch and is much better future-proofed than the
On Sat, Jan 13, 2007, Goswin von Brederlow wrote:
Which means the kernel has to load /usr into cache and check if lib32
exists. That shouldn't even cause a disk access, just cache. I don't
see that as a problem.
Yeah, same here, it's my preferred solution as well from the two; I
wonder why
On Sat, Jan 13, 2007, Goswin von Brederlow wrote:
Nearly right:
ifneq (,$(findstring multiarch,$(DEB_BUILD_OPTIONS)))
LIBDIR := usr/$(DEB_HOST_GNU_TYPE)/lib
Pango uses the cross-compiler dirs which binutils supports and I more
and more think is the right choice [so don't change that, it is
Loïc Minier [EMAIL PROTECTED] writes:
On Sat, Jan 13, 2007, Goswin von Brederlow wrote:
Could you complement the above list of arches / unames / personalities
combination for powerpc / powerpc64 and sparc / sparc64 if it makes
sense? Does it make sense to support m68k, arm etc. for a
Loïc Minier [EMAIL PROTECTED] writes:
On Sat, Jan 13, 2007, Goswin von Brederlow wrote:
Nearly right:
ifneq (,$(findstring multiarch,$(DEB_BUILD_OPTIONS)))
LIBDIR := usr/$(DEB_HOST_GNU_TYPE)/lib
Pango uses the cross-compiler dirs which binutils supports and I more
and more think is the
On Sat, Jan 13, 2007 at 04:34:33PM +0100, Loïc Minier wrote:
Could you complement the above list of arches / unames / personalities
combination for powerpc / powerpc64 and sparc / sparc64 if it makes
sense? Does it make sense to support m68k, arm etc. for a 64-bits
personality?
I don't
On Sat, Jan 13, 2007 at 10:19:52AM +0100, Loïc Minier wrote:
On Fri, Jan 12, 2007, Steve Langasek wrote:
If you're going to use non-standard paths at all, why would you not move
this to /usr/lib/i486-linux-gnu, which is also already part of the system
lib path in etch and is much better
On Sat, Jan 13, 2007 at 11:48:52AM +0100, Goswin von Brederlow wrote:
Nearly right:
ifneq (,$(findstring multiarch,$(DEB_BUILD_OPTIONS)))
LIBDIR := usr/$(DEB_HOST_GNU_TYPE)/lib
Pango uses the cross-compiler dirs which binutils supports and I more
and more think is the right choice [so don't
Check the ia32-libs-gtk pacakge, it has a hack which you might need to
adapt to workaround this in local/pangohack.c.
Since ia32-libs-gtk is forking the pango source, this is not the
problem of the pango maintainer really.
--
Loïc Minier [EMAIL PROTECTED]
On Thu, Jan 11, 2007, Goswin von Brederlow wrote:
Replacing the /usr/lib/pango/1.5.0/module-files.d/* with
/usr/lib32/pango/1.5.0/module-files.d/* fixes this problem for 32bit
but obviously breaks 64 bit.
Can we use /usr/lib32 in all cases or should we use /usr/lib32 only for
the pango
On Thu, Jan 11, 2007, Goswin von Brederlow wrote:
Package: libpango1.0-0
Version: 1.14.8-4
Severity: grave
Justification: renders package unusable
PS: I set this to grave because it makes ia32-libs-gtk unusable which
contains the pango debs. Please reassign to ia32-libs-gtk when you
fixed
Loïc Minier [EMAIL PROTECTED] writes:
On Thu, Jan 11, 2007, Goswin von Brederlow wrote:
Replacing the /usr/lib/pango/1.5.0/module-files.d/* with
/usr/lib32/pango/1.5.0/module-files.d/* fixes this problem for 32bit
but obviously breaks 64 bit.
Can we use /usr/lib32 in all cases or should we
Loïc Minier [EMAIL PROTECTED] writes:
On Thu, Jan 11, 2007, Goswin von Brederlow wrote:
Package: libpango1.0-0
Version: 1.14.8-4
Severity: grave
Justification: renders package unusable
PS: I set this to grave because it makes ia32-libs-gtk unusable which
contains the pango debs. Please
Loïc Minier [EMAIL PROTECTED] writes:
Check the ia32-libs-gtk pacakge, it has a hack which you might need to
adapt to workaround this in local/pangohack.c.
Since ia32-libs-gtk is forking the pango source, this is not the
problem of the pango maintainer really.
--
Loïc Minier [EMAIL
On Fri, Jan 12, 2007, Goswin von Brederlow wrote:
Is it more useful to turn on the support for /usr/lib32 at runtime
only, or is it ok to unconditionally setup this support at build time?
How would you turn it on at runtime? Policy forbidds to set an
environment variable in a package. You
On Fri, Jan 12, 2007, Goswin von Brederlow wrote:
The patch below should fix the issue. The first change is optional. We
can move the objects and adjust the conffile in ia32-libs-gtk if you
don't like it.
Err, how will your patch affect where pango is actually looking for
modules?
--
Loïc
Loïc Minier [EMAIL PROTECTED] writes:
On Fri, Jan 12, 2007, Goswin von Brederlow wrote:
The patch below should fix the issue. The first change is optional. We
can move the objects and adjust the conffile in ia32-libs-gtk if you
don't like it.
Err, how will your patch affect where pango is
Loïc Minier [EMAIL PROTECTED] writes:
On Fri, Jan 12, 2007, Goswin von Brederlow wrote:
Is it more useful to turn on the support for /usr/lib32 at runtime
only, or is it ok to unconditionally setup this support at build time?
How would you turn it on at runtime? Policy forbidds to set an
On Fri, Jan 12, 2007, Goswin von Brederlow wrote:
After some discussion on irc here is another possibility to fix
this. Instead of setting /etc/ld.so.preload we mangle the
libpango-1.0.so directly during build.
!!!DANGER, EVIL HACK COMING!!!
ar x /32-bit-chroot/usr/lib/libpango-1.0.a
On Fri, Jan 12, 2007, Goswin von Brederlow wrote:
Ah yes, that was in the old bugreport. I thought you actually had it
(or something equivalent) included in pango already but it wasn't
working.
I will do a test build with it and the latest pango source but from
reading the patch it looks
Loïc Minier [EMAIL PROTECTED] writes:
On Fri, Jan 12, 2007, Goswin von Brederlow wrote:
Ah yes, that was in the old bugreport. I thought you actually had it
(or something equivalent) included in pango already but it wasn't
working.
I will do a test build with it and the latest pango source
On Fri, Jan 12, 2007 at 08:19:18PM +0100, Goswin von Brederlow wrote:
As for using /usr/lib32 on i386 that is totaly up to you. On i386
/usr/lib32 does not yet exist but I don't see a reason not to create
it. Note that you can't have system libraries in /usr/lib32 since it
is not a default lib
Package: libpango1.0-0
Version: 1.14.8-4
Severity: grave
Justification: renders package unusable
Hi,
when running 32bit applications on amd64 the wrong module files are
opened by libpango:
open(/etc/pango/pangorc, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
36 matches
Mail list logo
