subject:"Bug#406455\: libpango1.0\-0\: 32bit libpango must use \/usr\/lib32\/pango\/1.5.0\/module\-files.d"

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 revisiting this
 patch.

 Hmm, I think everybody (including me) forgot about kfreebsd-i386/amd64
 too.

-- 
Loïc Minier [EMAIL PROTECTED]

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

2007-01-14 Thread Steve Langasek

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?
  If there are, it might make sense to spare the time of revisiting this
  patch.

No, there are not.  There's one guy doing a fringe ppc64 port, but it will
never be accepted in Debian because it's not actually beneficial to run all
your software in 64-bit mode on ppc64.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

2007-01-14 Thread Aurelien Jarno

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 already part of the system
   lib path in etch and is much better future-proofed than the alternatives?
 
   I'm willing to use whatever is blessed by bi-arch as I think it would
   make sense to support bi-arch in the lenny lifecycle; I think the
   adaptation that libpango needs are relatively close in both cases (but
   biarch will need a second build of course).
 
 Biarch is broken on amd64 in ways that are not reconcilable with the FHS.
 
 And /emul as a file path is totally blecherous, and an obstacle to ever
 reusing binary packages for multiarch.
 
 Multiarch is the only way forward from the current mess.  I want to be able
 to completely rid ourselves of biarch hacks for lenny.
 
   (FYI, pango can be built with multi-arch support but
   /usr/lib/i486-linux-gnu, is then used as libdir, not just for module
   files and modules.)
 
 Right, you wouldn't want to be moving the libs into /usr/lib/i486-linux-gnu
 at this point.
 
   It seems to me 64-bits libs for i386 use /usr/lib64 in bi-arch (I
   checked lib64z1 and lib64asound2).  It's less clear to me what to use
   for 326bits libs on 64-bits arches: lib32z1 and lib32asound2 use
   /emul/ia32-linux/usr/lib; is this correct?  Does it make sense that use
   this path?
 
 It is unfortunately the only install path supported by biarch because of the
 symlinking solution that was adopted for /usr/lib32, yes.
 
 On Sat, Jan 13, 2007 at 10:28:22AM +0100, Goswin von Brederlow wrote:
   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 dir on i486.
 
   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?
 
  Because binutils does not support /usr/lib/i486-linux-gnu and amd64
  already uses lib32 (and binutils supports it there).
 
 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.
 

Note that in that when multiarch will arrive, you will have to add a 
conflict between libpango [i386] and ia32-libs-gtk [amd64], because both
of them will ship the same files. This case has not been planned in
the current dpkg patches.

It's the argument which make us revert the use of
/usr/lib/i486-linux-gnu for libc6-dev-i386 one year ago.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

2007-01-14 Thread Aurelien Jarno

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?
  If there are, it might make sense to spare the time of revisiting this
  patch.
 
  Hmm, I think everybody (including me) forgot about kfreebsd-i386/amd64
  too.
 

We don't really have the problem on GNU/kFreeBSD, as non-free stuff like
flash or java plugin are only available for linux i386, not for
freebsd...

The solution for us is a linux chroot, or multiarch...

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 that using /usr/lib/i486-linux-gnu/pango might mean
 a conflict with ia32-libs-gtk when we move to multiarch; if instead I
 use /usr/lib32, respectively /usr/lib64, I wont have to add the
 conflict in the multiarch era.

 If the two paths are coupled in an inconvenient fashion in the pango build
 rules such that the maintainers prefer to keep them all in one directory,
 then yes, /emul/blah/barf is the best option for now.

 (Yes, you fully understand the problem, I'm okay to add module pathes,
 but I don't want to lie to the internal get lib dir function of pango
 or patch it to not return the real libdir (since the lib isn't in
 there), especially because this function is part of the ABI and is used
 for different things.  It's even worse in Gtk.)

 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 sane overview of what's supportable and
 what's not, what's going to become supported, and what will not.  E.g.,
 I've heard that bi-arch was something working well and not too complex
 to implement, yet X libs don't support it and I've heard they don't
 want to support biarch; some people also tell me that biarch is complex
 and a kludge as well.
   On multiarch, some people tell me I should keep /usr/triplet/lib
 because it necessarily works due to cross-compilers, other tell me
 /usr/lib/triplet is the true multiarch path.
   I've heard a lot of times that ia32-libs is very ugly (and I concur),
 but I've also noticed it's widely used and popular.

 This is absolutely not a rant about you or anyone else in the bug, I
 think all participants have a good technical picture, but very
 different opinions.

 I wish we would have a technical leader on these subjects who would
 have the authority to go forward on the subjects and who would follow a
 spec writing process to reach consensus and produce:
 - specs for implementing multiarch in packages (looks like this is
   going to happen long term): where we currently are, how to implement
   it fully, special cases, how to permit building it conditionally
   right now (e.g. I used DEB_BUILD_OPTIONS=multiarch), etc.
 - specs for implementing biarch in packages (looks like this started
   happening, but finally has too many *opponents* which will prevent it
   from happening): where we currently are, how to implement it fully,
   special cases, when it makes sense, on which arches, etc.
 - specs for implementing packages usable in ia32-libs in the sanest way
   for the future (e.g. when multiarch will be there) -- looks like some
   packages will continue to happen short term and this will be
   obsoleted with multiarch


 Thanks for all the participants in the discussion, I think I am
 inclined to:
 - keep the switch of the multiarch path to the standard multiarch
   path
 - do not aim at reusing this for biarch or at implementing biarch, as
   my current feeling is that it won't ever be supported in X (which is
   a pre-requisite) and will be reverted and dropped
 - implement ia32-libs support:
   * by using /usr/lib32 and /usr/lib64 in the code instead of
 /usr/lib/triplet to avoid the necessity of a conflict in the future
   * on i386, ia64, and amd64 (and not anything else as no demand or use
 case exist and this will be obsoleted with multiarch)
   * by checking a different module path (and not by redefining libdir)
 for consistency in the build process and internally to pango and
 for clients of the pango ABI


 Now would be a good time to shout if I didn't understand something,
 if you think one of the above choices is not the best, or if some
 arguments are missing from the discussion!  :)

-- 
Loïc Minier [EMAIL PROTECTED]

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

 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	2007-01-14 17:39:25.0 +0100
@@ -24,6 +24,7 @@
 #include string.h
 #include limits.h
 #include errno.h
+#include unistd.h
 
 #include gmodule.h
 #include glib/gstdio.h
@@ -490,6 +491,18 @@
 	   MODULE_VERSION,
 	   module-files.d,
 	   NULL);
+
+#if defined(__linux__)  defined (__i386__)
+  char *compat_module_files_d_str = g_build_filename (/usr/lib32,
+	   MODULE_VERSION,
+	   module-files.d,
+	   NULL);
+#elif defined(__linux__)  ( defined (__x86_64__) || defined(__ia64__) )
+  char *compat_module_files_d_str = g_build_filename (/usr/lib64,
+	   MODULE_VERSION,
+	   module-files.d,
+	   NULL);
+#endif
   char *list_str;
   char **files;
   int n;
@@ -501,6 +514,17 @@
  pango.modules,
  NULL);
 
+#if defined(__linux__)  ( defined(__i386__) || defined (__x86_64__) || defined(__ia64__) )
+  /* prefer compat_module_files_d_str over module_files_d_str on the above
+   * arches if it's usable */
+  if (g_access(compat_module_files_d_str, R_OK|X_OK))
+  list_str = g_strjoin (G_SEARCHPATH_SEPARATOR_S,
+			file_str,
+			compat_module_files_d_str,
+			NULL);
+  else /* continued below */
+#endif
+
   list_str = g_strjoin (G_SEARCHPATH_SEPARATOR_S,
 			file_str,
 			module_files_d_str,
@@ -550,6 +574,9 @@
   g_strfreev (files);
   g_free (list_str);
   g_free (module_files_d_str);
+#if defined(__linux__)  ( defined(__i386__) || defined (__x86_64__) || defined(__ia64__) )
+  g_free (compat_module_files_d_str);
+#endif
   g_free (file_str);
 
   dlloaded_engines = g_slist_reverse (dlloaded_engines);

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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]

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

2007-01-14 Thread Goswin von Brederlow

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 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 is blessed by bi-arch as I think it would
   make sense to support bi-arch in the lenny lifecycle; I think the
   adaptation that libpango needs are relatively close in both cases (but
   biarch will need a second build of course).
 
 Biarch is broken on amd64 in ways that are not reconcilable with the FHS.
 
 And /emul as a file path is totally blecherous, and an obstacle to ever
 reusing binary packages for multiarch.
 
 Multiarch is the only way forward from the current mess.  I want to be able
 to completely rid ourselves of biarch hacks for lenny.
 
   (FYI, pango can be built with multi-arch support but
   /usr/lib/i486-linux-gnu, is then used as libdir, not just for module
   files and modules.)
 
 Right, you wouldn't want to be moving the libs into /usr/lib/i486-linux-gnu
 at this point.
 
   It seems to me 64-bits libs for i386 use /usr/lib64 in bi-arch (I
   checked lib64z1 and lib64asound2).  It's less clear to me what to use
   for 326bits libs on 64-bits arches: lib32z1 and lib32asound2 use
   /emul/ia32-linux/usr/lib; is this correct?  Does it make sense that use
   this path?
 
 It is unfortunately the only install path supported by biarch because of the
 symlinking solution that was adopted for /usr/lib32, yes.
 
 On Sat, Jan 13, 2007 at 10:28:22AM +0100, Goswin von Brederlow wrote:
   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 dir on i486.
 
   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?
 
  Because binutils does not support /usr/lib/i486-linux-gnu and amd64
  already uses lib32 (and binutils supports it there).
 
 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.
 

 Note that in that when multiarch will arrive, you will have to add a 
 conflict between libpango [i386] and ia32-libs-gtk [amd64], because both
 of them will ship the same files. This case has not been planned in
 the current dpkg patches.

 It's the argument which make us revert the use of
 /usr/lib/i486-linux-gnu for libc6-dev-i386 one year ago.

Thanks for reminding us. I knew there was some reason not to use
multiarch dirs yet. :)

MfG
Goswin

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 only that, we don't use pango.modules under Debian anymore,
 but /usr/lib/pango/1.5.0/module-files.d/*.modules.  This is why the
 Ubuntu patch wont work as is.

 I fixed that and also made the patch less conditional. The test for
 uname is not needed and actualy breaks stuff. You might want to have
 an uname of i686 for your www-browser so some flash or java plugin
 works. But you still want to be able to read pdf links too. 'linux32
 www-browser' would result in acroread being started with uname 'i686'
 and then pango fails.

 On the other hand, doesn't that save a stat() when the kernel is
 detected to not be 64 bits?  This is in the startup of all libpango
 using apps.

 I also added a g_getenv(PANGO32_SYSCONFDIR); for symetry.
 Are you sure the SYSCONFDIR part is still needed? The modules conffile
 used to be there iirc but no more. I can't think of a reason why 32bit
 and 64bit would need different fonts:

 No, it's not; the sysconfdir parts of pangohack and of the patch are
 irrelevant for the current layout of the *pango* package.  The Gtk
 package is not at this level in unstable though.

 +#if defined(__linux__)  defined (__i386__)
 +  if (!access(/usr/lib32/pango, R_OK|X_OK))
 +return /usr/lib32/pango;
 +#endif
return LIBDIR /pango;
  #endif
  }

 I don't think this is the place to patch.  IMO, we should not touch
 libdir, only prepend
 /usr/lib32/pango/1.5.0/module-files.d
 to the search path on i386.

 The biggest question I have is whether we should check the kernel at
 runtime or not and include this path conditionally; pros for using
 uname(): might save a stat(); cons: not clear what values the kernel
 may return.

 Goswin, as ia32-libs-gtk is supposed to work on ia64, could you tell me
 whether defined (__ia64__) the correct test for this platform?

 Are there other 64-bits platforms to be supported?

 Do you intend to conflict with other packages providing pango module
 files?


 In the initial bug report, you requested support for /usr/lib64 in the
 64-bits pango; first, I don't see an ia32-libs-gtk for 32-bits arches,
 and second, could you give me a list or arches and defined() tests
 for these arches?

-- 
Loïc Minier [EMAIL PROTECTED]

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 is blessed by bi-arch as I think it would
 make sense to support bi-arch in the lenny lifecycle; I think the
 adaptation that libpango needs are relatively close in both cases (but
 biarch will need a second build of course).

 (FYI, pango can be built with multi-arch support but
 /usr/lib/i486-linux-gnu, is then used as libdir, not just for module
 files and modules.)

 It seems to me 64-bits libs for i386 use /usr/lib64 in bi-arch (I
 checked lib64z1 and lib64asound2).  It's less clear to me what to use
 for 326bits libs on 64-bits arches: lib32z1 and lib32asound2 use
 /emul/ia32-linux/usr/lib; is this correct?  Does it make sense that use
 this path?

-- 
Loïc Minier [EMAIL PROTECTED]

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 in /usr/lib32 since it
 is not a default lib dir on i486.

 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?

Because binutils does not support /usr/lib/i486-linux-gnu and amd64
already uses lib32 (and binutils supports it there). lib32 is
standardized in the FHS:

| /libqual : Alternate format essential shared libraries (optional)
| Purpose
|
| There may be one or more variants of the /lib directory on systems
| which support more than one binary format requiring separate
| libraries. [14]
|
| [14] This is commonly used for 64-bit or 32-bit support on systems
| which support multiple binary formats, but require libraries of the
| same name. In this case, /lib32 and /lib64 might be the library
| directories, and /lib a symlink to one of them.
|
| /usr/libqual : Alternate format libraries (optional)
| Purpose
|
| /usr/libqual performs the same role as /usr/lib for an alternate
| binary format, except that the symbolic links /usr/libqual/sendmail
| and /usr/libqual/X11 are not required. [26]


Anyway, the conditional use of /usr/lib32 as with the revised
ia32-hack patch posted yesterday doesn't require i386 to use
/usr/lib32 but allows amd64 to do so. That would be the savest bet.

MfG
Goswin


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

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 /etc/pango,
 only the font aliases.

  It's not only that, we don't use pango.modules under Debian anymore,
  but /usr/lib/pango/1.5.0/module-files.d/*.modules.  This is why the
  Ubuntu patch wont work as is.


 I fixed that and also made the patch less conditional. The test for
 uname is not needed and actualy breaks stuff. You might want to have
 an uname of i686 for your www-browser so some flash or java plugin
 works. But you still want to be able to read pdf links too. 'linux32
 www-browser' would result in acroread being started with uname 'i686'
 and then pango fails.

  On the other hand, doesn't that save a stat() when the kernel is
  detected to not be 64 bits?  This is in the startup of all libpango
  using apps.

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.

 I also added a g_getenv(PANGO32_SYSCONFDIR); for symetry.
 Are you sure the SYSCONFDIR part is still needed? The modules conffile
 used to be there iirc but no more. I can't think of a reason why 32bit
 and 64bit would need different fonts:

  No, it's not; the sysconfdir parts of pangohack and of the patch are
  irrelevant for the current layout of the *pango* package.  The Gtk
  package is not at this level in unstable though.

Ok, so we agree that the SYSCONFDIR part is now obsolete. That
certainly simplifies things.

 +#if defined(__linux__)  defined (__i386__)
 +  if (!access(/usr/lib32/pango, R_OK|X_OK))
 +return /usr/lib32/pango;
 +#endif
return LIBDIR /pango;
  #endif
  }

  I don't think this is the place to patch.  IMO, we should not touch
  libdir, only prepend
  /usr/lib32/pango/1.5.0/module-files.d
  to the search path on i386.

We have to replace the /usr/lib/pango/1.5.0/module-files.d with
/usr/lib32/pango/1.5.0/module-files.d on amd64 32bit otherwise every
single 64bit module generates a few lines error message.

Maybe there are better ways to solve this but this is simple and works
and the patch already exists.

  The biggest question I have is whether we should check the kernel at
  runtime or not and include this path conditionally; pros for using
  uname(): might save a stat(); cons: not clear what values the kernel
  may return.

DebianPersonality   uname   needed dir
i386  32bit i[3456]86   /usr/lib
i386  64bit x86_64  /usr/lib
amd64 32bit i686/usr/lib32
amd64 64bit x86_64  /usr/lib32
ia64  32bit i686 (or i[345]86?) /usr/lib32
ia64  64bit ia64 (?)/usr/lib32

Uname isn't helpfull here and access() is way simpler than asking dpkg
for the architecture, which would be the only way to be sure at runtime.

  Goswin, as ia32-libs-gtk is supposed to work on ia64, could you tell me
  whether defined (__ia64__) the correct test for this platform?

Should be. But why would you care? The ia64 libpango does not need the
test, only the i386 one.

  Are there other 64-bits platforms to be supported?

Only amd64 and ia64 support running i386 binaries. There is also the
possibility to use qemu on other archs but nothing is packaged for
that. Without the uname check it would work in qemu too no matter what
uname returns there, and I have no idea what it does return.

  Do you intend to conflict with other packages providing pango module
  files?

Why would I? With the stat test for /usr/lib32/pango there is no
change for any package except for ia32-libs-gtk. Only ia32-libs-gtk
would have /usr/lib32/pango and ia32-libs-gtk is the only package with
32bit pango modules for amd64. Nothing to conflict against.

  In the initial bug report, you requested support for /usr/lib64 in the
  64-bits pango; first, I don't see an ia32-libs-gtk for 32-bits arches,
  and second, could you give me a list or arches and defined() tests
  for these arches?

There isn't an amd64-libs-gtk package (yet?) but it is kind of a
chickenegg problem. Without support for /usr/lib64 there can't be
one.

The number of requests for 32bit gtk support for amd64 made us (and
ubuntu way before that) create the ia32-libs-gtk package. I haven't
seen requests for 64bit gtk support on i386 yet so we can ignore that
for Etch. And for Lenny we can hopefully just use multiarch finaly.

MfG
Goswin

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 alternatives?

  I'm willing to use whatever is blessed by bi-arch as I think it would
  make sense to support bi-arch in the lenny lifecycle; I think the
  adaptation that libpango needs are relatively close in both cases (but
  biarch will need a second build of course).

  (FYI, pango can be built with multi-arch support but
  /usr/lib/i486-linux-gnu, is then used as libdir, not just for module
  files and modules.)

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 fine].
The libc6 in etch on the other hand uses the proposed
usr/lib/$(DEB_HOST_GNU_TYPE) in /etc/ld.so.conf.d/*. That proposal was
initialy made without knowing that cross compiling had already
established usr/$(DEB_HOST_GNU_TYPE)/lib so well.

For what is worth, if libc6 changes the /etc/ld.so.conf.d/* files then
multiarch becomes usable. Native gcc and binutils both work with the
cross-compile dirs too.

  It seems to me 64-bits libs for i386 use /usr/lib64 in bi-arch (I
  checked lib64z1 and lib64asound2).  It's less clear to me what to use
  for 326bits libs on 64-bits arches: lib32z1 and lib32asound2 use
  /emul/ia32-linux/usr/lib; is this correct?  Does it make sense that use
  this path?

/usr/lib32 is a link to /emul/ia32-linux/usr/lib. Due to dpkgs link
handling you must ship files in /emul/ia32-linux/usr/lib and not in
/usr/lib32. In the code you can use /usr/lib32 or
/emul/ia32-linux/usr/lib as you wish and most, if not all, packages
use /usr/lib32.

The /emul/ia32-linux/ comes from ia64 where it denotes that 32bit
stuff needs emulation and isn't purely native code.

 -- 
 Loïc Minier [EMAIL PROTECTED]

MfG
Goswin

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 Ubuntu folks picked uname().

 Ok, so we agree that the SYSCONFDIR part is now obsolete. That
 certainly simplifies things.

 (Not for Gtk, but this is far more complex and I prefer getting things
 done cleanly on Pango first which is simpler and then doing the same on
 Gtk plus the needed extra hacks.)

 We have to replace the /usr/lib/pango/1.5.0/module-files.d with
 /usr/lib32/pango/1.5.0/module-files.d on amd64 32bit otherwise every
 single 64bit module generates a few lines error message.

 Yes, but I don't consider it wise to change the internal definition of
 libdir for pango; I prefer changing the specific path to
 /usr/lib/pango/1.5.0/module-files.d to not use libdir but lib32dir for
 example or something similar.  Of course, one could check how pango
 uses its libdir in the whole pango source code, but
 pango_get_lib_subdirectory() is part of the ABI and this could change
 in future releases, I prefer not taking the risk, if the code relative
 to modules changes, at least the patch wont apply.

 DebianPersonality   uname   needed dir
 i386  32bit i[3456]86   /usr/lib
 i386  64bit x86_64  /usr/lib
 amd64 32bit i686/usr/lib32
 amd64 64bit x86_64  /usr/lib32
 ia64  32bit i686 (or i[345]86?) /usr/lib32
 ia64  64bit ia64 (?)/usr/lib32

 Nice.

 Uname isn't helpfull here and access() is way simpler than asking dpkg
 for the architecture, which would be the only way to be sure at runtime.

 Ok, that settles it then.

   Goswin, as ia32-libs-gtk is supposed to work on ia64, could you tell me
   whether defined (__ia64__) the correct test for this platform?
 Should be. But why would you care? The ia64 libpango does not need the
 test, only the i386 one.

 I cared for the 32-bits support under ia64, but since we'll use the
 i386 *.debs, it's not needed indeed.  However, I do need it for the
 lib64 check in the amd64 version; is it defined(__x86_64__)?

 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?  Or should this be revisited for bi-arch?

 Why not test for 32-bits/64-bits instead of defined(__i386__) or
 defined(__x86_64__)?

   Do you intend to conflict with other packages providing pango module
   files?
 Why would I? With the stat test for /usr/lib32/pango there is no
 change for any package except for ia32-libs-gtk. Only ia32-libs-gtk
 would have /usr/lib32/pango and ia32-libs-gtk is the only package with
 32bit pango modules for amd64. Nothing to conflict against.

 Hmm, it was simpler for me to unconditionnally prepend the /usr/lib32
 path before /usr/lib; but it's cleaner to disable /usr/lib when
 /usr/lib32 is found.

   In the initial bug report, you requested support for /usr/lib64 in the
   64-bits pango; first, I don't see an ia32-libs-gtk for 32-bits arches,
   and second, could you give me a list or arches and defined() tests
   for these arches?
 There isn't an amd64-libs-gtk package (yet?) but it is kind of a
 chickenegg problem. Without support for /usr/lib64 there can't be
 one.

 Ok, but we can implement it nevertheless, it's the same amount of work.
 Could you hand me the relevant arches/defined() tests couples?  Of
 perhaps we can switch to a 32-bits/64-bits test.

 The number of requests for 32bit gtk support for amd64 made us (and
 ubuntu way before that) create the ia32-libs-gtk package. I haven't
 seen requests for 64bit gtk support on i386 yet so we can ignore that
 for Etch. And for Lenny we can hopefully just use multiarch finaly.

 Yeah, I am aware of the high demand and use of this setup; it's a
 terrible pity that your package went into etch one month ago, and that
 you file RCs for this support at this point of the release cycle...

 For lenny, it might also make sense to work on biarch; there are some
 functional package in the archives, and its support is close to the
 requests in this report.

-- 
Loïc Minier [EMAIL PROTECTED]

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 fine].

Yes, we already discussed this in the multiarch bug report and this is
changed in SVN since a couple of days (it was on the TODO list since
back then,

http://svn.debian.org/wsvn/pkg-gnome/desktop/unstable/pango1.0/debian/rules?op=filerev=0sc=0).

You told me both should work and I heard from other folks that the
correct dir for multiarch was the usr/lib/$(DEB_HOST_GNU_TYPE) case.

Who's the authority to decide on such things? Should I contact the
binutils maintainer to get the final word? There shouldn't be room for
doubt here. :-/

I prefer using the blessed official / canonical dir for multiarch as
the goal is to achieve multiarch, not a cross-compiling pango.

The libc6 in etch on the other hand uses the proposed
usr/lib/$(DEB_HOST_GNU_TYPE) in /etc/ld.so.conf.d/*. That proposal was
initialy made without knowing that cross compiling had already
established usr/$(DEB_HOST_GNU_TYPE)/lib so well.

So, both work currently; why not keep the scheme of the libc if it's
supported and blessed as multiarch? Was it decided to revert this?

It seems to me 64-bits libs for i386 use /usr/lib64 in bi-arch (I
checked lib64z1 and lib64asound2). It's less clear to me what to use
for 326bits libs on 64-bits arches: lib32z1 and lib32asound2 use
/emul/ia32-linux/usr/lib; is this correct? Does it make sense that use
this path?
/usr/lib32 is a link to /emul/ia32-linux/usr/lib. Due to dpkgs link
handling you must ship files in /emul/ia32-linux/usr/lib and not in
/usr/lib32. In the code you can use /usr/lib32 or
/emul/ia32-linux/usr/lib as you wish and most, if not all, packages
use /usr/lib32.

Hmm. Ok; so I'll use /usr/lib32, and you'll ship files in /emul.

--
Loïc Minier [EMAIL PROTECTED]

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 64-bits
  personality?  Or should this be revisited for bi-arch?

I'm not quite sure but I think powerpc can be both __ppc__ and
__powerpc__ and don't even start about mips with its 12+ abis.

  Why not test for 32-bits/64-bits instead of defined(__i386__) or
  defined(__x86_64__)?

Yeah, testing sizeof(long) or sizeof(void*) soulds like a general
solution that circumvents testing for all the archs seperately.

So in pango_get_lib_subdirectory() you would have something like

#if sizeof(long) = 4
result = /usr/lib32/pango;
#else
result = /usr/lib64/pango;
#endif
if (access(result 

and else fallback to /usr/lib/pango.

   Do you intend to conflict with other packages providing pango module
   files?
 Why would I? With the stat test for /usr/lib32/pango there is no
 change for any package except for ia32-libs-gtk. Only ia32-libs-gtk
 would have /usr/lib32/pango and ia32-libs-gtk is the only package with
 32bit pango modules for amd64. Nothing to conflict against.

  Hmm, it was simpler for me to unconditionnally prepend the /usr/lib32
  path before /usr/lib; but it's cleaner to disable /usr/lib when
  /usr/lib32 is found.

Having it spew out errors for every 64bit and 32bit module on both
64bit and 32bit pango apps respectively would be quite anoying.

   In the initial bug report, you requested support for /usr/lib64 in the
   64-bits pango; first, I don't see an ia32-libs-gtk for 32-bits arches,
   and second, could you give me a list or arches and defined() tests
   for these arches?
 There isn't an amd64-libs-gtk package (yet?) but it is kind of a
 chickenegg problem. Without support for /usr/lib64 there can't be
 one.

  Ok, but we can implement it nevertheless, it's the same amount of work.
  Could you hand me the relevant arches/defined() tests couples?  Of
  perhaps we can switch to a 32-bits/64-bits test.

Go with a 32/64 bits test.

 The number of requests for 32bit gtk support for amd64 made us (and
 ubuntu way before that) create the ia32-libs-gtk package. I haven't
 seen requests for 64bit gtk support on i386 yet so we can ignore that
 for Etch. And for Lenny we can hopefully just use multiarch finaly.

  Yeah, I am aware of the high demand and use of this setup; it's a
  terrible pity that your package went into etch one month ago, and that
  you file RCs for this support at this point of the release cycle...

Sorry.

  For lenny, it might also make sense to work on biarch; there are some
  functional package in the archives, and its support is close to the
  requests in this report.

 -- 
 Loïc Minier [EMAIL PROTECTED]

MfG
Goswin

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

Loïc Minier [EMAIL PROTECTED] writes:

Yes, we already discussed this in the multiarch bug report and this is
changed in SVN since a couple of days (it was on the TODO list since
back then,

http://svn.debian.org/wsvn/pkg-gnome/desktop/unstable/pango1.0/debian/rules?op=filerev=0sc=0).

You told me both should work and I heard from other folks that the
correct dir for multiarch was the usr/lib/$(DEB_HOST_GNU_TYPE) case.

Who's the authority to decide on such things? Should I contact the
binutils maintainer to get the final word? There shouldn't be room for
doubt here. :-/

I prefer using the blessed official / canonical dir for multiarch as
the goal is to achieve multiarch, not a cross-compiling pango.

I guess the binutils, gcc and glibc folks have to get together and
decide. But cross compiling has been around for a while so any new
thing (like multiarch) should follow the beaten path. I just wish I
had realized a year ago that standard binutils already searches in the
cross compile dirs.

So, both work currently; why not keep the scheme of the libc if it's
supported and blessed as multiarch? Was it decided to revert this?

No, binutils does not support /usr/lib/$(DEB_HOST_GNU_TYPE). If you
put libraries there stuff fails to link. And that needs a source
change in binutils. On the other hand the change in libc6 is just the
special conffile debian creates.

Hmm. Ok; so I'll use /usr/lib32, and you'll ship files in /emul.

Perfect.

So lets solve this problem now and leave the multiarch issues for Lenny.

MfG
Goswin

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

2007-01-13 Thread Steve Langasek

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 think that 64-bit variants of pango/gtk make sense except on
architectures that have native 64-bit ports; whoever said I'd like it if my
GUI would use more memory for storing pointers?  The high-end computing
apps that need 64-bit address space tend to not to be GUIs, and the
architectures where 64-bit mode isn't a performance penalty for
general-purpose computing have 64-bit ports.

So i386/ia64 and i386/amd64 are the only biarch cases where having gtk for
the non-default ABI makes much sense.

Only when you get into multiarch do you start getting other scenarios where
gtk might be beneficial for alternative ABIs (though mostly for
development/testing reasons, not because running a gtk app under qemu is
particularly beneficial :).

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

2007-01-13 Thread Steve Langasek

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 future-proofed than the alternatives?

  I'm willing to use whatever is blessed by bi-arch as I think it would
  make sense to support bi-arch in the lenny lifecycle; I think the
  adaptation that libpango needs are relatively close in both cases (but
  biarch will need a second build of course).

Biarch is broken on amd64 in ways that are not reconcilable with the FHS.

And /emul as a file path is totally blecherous, and an obstacle to ever
reusing binary packages for multiarch.

Multiarch is the only way forward from the current mess.  I want to be able
to completely rid ourselves of biarch hacks for lenny.

  (FYI, pango can be built with multi-arch support but
  /usr/lib/i486-linux-gnu, is then used as libdir, not just for module
  files and modules.)

Right, you wouldn't want to be moving the libs into /usr/lib/i486-linux-gnu
at this point.

  It seems to me 64-bits libs for i386 use /usr/lib64 in bi-arch (I
  checked lib64z1 and lib64asound2).  It's less clear to me what to use
  for 326bits libs on 64-bits arches: lib32z1 and lib32asound2 use
  /emul/ia32-linux/usr/lib; is this correct?  Does it make sense that use
  this path?

It is unfortunately the only install path supported by biarch because of the
symlinking solution that was adopted for /usr/lib32, yes.

On Sat, Jan 13, 2007 at 10:28:22AM +0100, Goswin von Brederlow wrote:
  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 dir on i486.

  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?

 Because binutils does not support /usr/lib/i486-linux-gnu and amd64
 already uses lib32 (and binutils supports it there).

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.

If the two paths are coupled in an inconvenient fashion in the pango build
rules such that the maintainers prefer to keep them all in one directory,
then yes, /emul/blah/barf is the best option for now.

 lib32 is standardized in the FHS:

 | /libqual : Alternate format essential shared libraries (optional)
 | Purpose

 | There may be one or more variants of the /lib directory on systems
 | which support more than one binary format requiring separate
 | libraries. [14]

And on amd64, the FHS specifies that /usr/lib is supposed to be *32*-bit,
and /usr/lib*64* is the one to use for 64-bit biarch files, the exact
opposite of all other biarch platforms.

The FHS provides no useful guidance here.  We have to break the FHS anyway,
we might as well be doing it in a least-awful fashion by looking towards
multiarch to the greatest extent currently possible.

 Anyway, the conditional use of /usr/lib32 as with the revised
 ia32-hack patch posted yesterday doesn't require i386 to use
 /usr/lib32 but allows amd64 to do so. That would be the savest bet.

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.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

2007-01-13 Thread Steve Langasek

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 change that, it is fine].
 The libc6 in etch on the other hand uses the proposed
 usr/lib/$(DEB_HOST_GNU_TYPE) in /etc/ld.so.conf.d/*. That proposal was
 initialy made without knowing that cross compiling had already
 established usr/$(DEB_HOST_GNU_TYPE)/lib so well.

Says who?  I was certainly well familiar with the use of /usr/$(system)/lib
for cross-compilers, and it is neither equivalent to multiarch in use nor a
good FHS-like solution for what multiarch aims to achieve.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

 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]

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 embedded in ia32-libs?  IOW, can I change the pango/i386
 package to ship /usr/lib32/pango/1.5.0/module-files.d and the the
 pango/amd64 package to use /usr/lib64/pango/1.5.0/module-files.d -- and
 hence have no /usr/lib/pango/1.5.0/module-files.d except on other
 arches (m68k, arm, ...)?


 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?

-- 
Loïc Minier [EMAIL PROTECTED]

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 it instead of closing.

 Why does this show up only now?  How did ia32-libs-gtk work until now?

-- 
Loïc Minier [EMAIL PROTECTED]

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 use /usr/lib32 only for
  the pango embedded in ia32-libs?  IOW, can I change the pango/i386
  package to ship /usr/lib32/pango/1.5.0/module-files.d and the the
  pango/amd64 package to use /usr/lib64/pango/1.5.0/module-files.d -- and
  hence have no /usr/lib/pango/1.5.0/module-files.d except on other
  arches (m68k, arm, ...)?

On amd64 /usr/lib64 is a link to /usr/lib maintained by libc6 and if
you put any files in there then dpkg will complain on the next libc6
update about a file conflict for /usr/lib64. So you must ship the file
in /usr/lib even if you use /usr/lib64 to open them.

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 dir on i486.

  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 could have an /etc/pango/config
that tells libpango i386 to use lib32 and we ship it in ia32-libs-gtk
only. But isn't than more work than always using lib32?

Alternatively you could include the gnu tripple in the path to the
modules file like gcc uses:

/usr/lib/pango/x86_64-linux-gnu/1.5.0/module-files.d/
/usr/lib/pango/i486-linux-gnu/1.5.0/module-files.d/

or like cross-compilers:

/usr/x86_64-linux-gnu/lib/pango/1.5.0/module-files.d/ 
/usr/i486-linux-gnu/lib/pango/1.5.0/module-files.d/ 

 -- 
 Loïc Minier [EMAIL PROTECTED]

MfG
Goswin

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 reassign to ia32-libs-gtk when you
 fixed it instead of closing.

  Why does this show up only now?  How did ia32-libs-gtk work until now?

Ia32-libs-gtk in debian is relatively new and it never worked.

See '#372508: Preparing multiarch' for details if you can't remeber
the issues you fixed. Unfortunately we can't just default to seting
multiarch yet.

 -- 
 Loïc Minier [EMAIL PROTECTED]

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.

MfG
Goswin

--- debian/rules~   2007-01-12 20:37:19.0 +0100
+++ debian/rules2007-01-12 20:52:07.0 +0100
@@ -49,10 +49,10 @@
 endif
 
 # relative Pango Modules Path (separated by :)
-MODULES_PATH := $(LIBDIR)/pango/$(MODVER)/modules
+MODULES_PATH := usr/$(DEB_HOST_GNU_TYPE)/lib/pango/$(MODVER)/modules
 
 # relative directory to store the generated Pango Module File
-MODULE_FILES_D := $(LIBDIR)/pango/$(MODVER)/module-files.d
+MODULE_FILES_D := usr/$(DEB_HOST_GNU_TYPE)/lib/pango/$(MODVER)/module-files.d
 
 # Pango Module API version virtual Provide
 ifneq (,$(findstring multiarch,$(DEB_BUILD_OPTIONS)))

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 PROTECTED]

The ia32-libs-gtk package has a local/pangohack.c file. But that does
not fork the pango source. Instead it is a library that can be
preloaded with LD_PRELOAD=libpangohack.so.0.0.

The ia32-libs-gtk package in debian does not build the library but if
we must I guess we could. We would then have to add
libpangohack.so.0.0 to /etc/ld.so.preload to make this
work in a package. Something I would rather not do.

MfG
Goswin

PS: sorry to reply to every mail in turn instead all at once.

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 could have an /etc/pango/config
 that tells libpango i386 to use lib32 and we ship it in ia32-libs-gtk
 only. But isn't than more work than always using lib32?

 Check the patch in the Ubuntu package, I thought I already sent it to
 you during the multiarch discussion.  It uses uname().  Attached.

 Alternatively you could include the gnu tripple in the path to the
 modules file like gcc uses:
 /usr/lib/pango/x86_64-linux-gnu/1.5.0/module-files.d/
 /usr/lib/pango/i486-linux-gnu/1.5.0/module-files.d/
 or like cross-compilers:
 /usr/x86_64-linux-gnu/lib/pango/1.5.0/module-files.d/ 
 /usr/i486-linux-gnu/lib/pango/1.5.0/module-files.d/ 

 This would require updating of the pangohack in ia32-libs-gtk I
 suppose.

-- 
Loïc Minier [EMAIL PROTECTED]
diff -Nur pango-1.15.2.orig/pango/pango-utils.c pango-1.15.2/pango/pango-utils.c
--- pango-1.15.2.orig/pango/pango-utils.c	2006-12-07 03:16:13.0 +0100
+++ pango-1.15.2/pango/pango-utils.c	2006-12-21 17:23:55.0 +0100
@@ -24,6 +24,8 @@
 #include string.h
 #include stdlib.h
 #include math.h
+#include unistd.h
+#include sys/utsname.h
 #include locale.h
 
 #include pango-font.h
@@ -688,7 +690,23 @@
 
   return result;
 #else
-  return SYSCONFDIR /pango;
+  static gchar *result = NULL;
+  struct utsname uts;
+
+  if (result == NULL)
+{
+  result = g_getenv(PANGO_SYSCONFDIR);
+  if (!access(result, R_OK|X_OK))
+	return result;
+#if defined(__linux__)  defined (__i386__)
+  uname(uts);
+  if (!strcmp(x86_64, uts.machine)
+	   !access(SYSCONFDIR /pango32, R_OK|X_OK))
+	result = SYSCONFDIR /pango32;
+#endif
+  result = SYSCONFDIR /pango;
+}
+  return result;
 #endif
 }
 
@@ -716,6 +734,14 @@
 
   return result;
 #else
+#if defined(__linux__)  defined (__i386__)
+  struct utsname uts;
+
+  uname(uts);
+  if (!strcmp(x86_64, uts.machine)
+   !access(/usr/lib32/pango, R_OK|X_OK))
+return /usr/lib32/pango;
+#endif
   return LIBDIR /pango;
 #endif
 }

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 Minier [EMAIL PROTECTED]

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 actually looking for
  modules?

Aeh, isn't that debian/rules variable passed along to the source
during compile? Well, if not that would have to be done.

 -- 
 Loïc Minier [EMAIL PROTECTED]

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
objcopy -W pango_get_sysconf_subdirectory -N pango_get_lib_subdirectory 
pango-utils.o pango-utils2.o
rm pango-utils.o
gcc -m32 -O2 -W -Wall -c pangohack.c
gcc -m32 -g -Wall -W -nostartfiles -shared -fPIC -Wl,-soname,libpango-1.0.so.0 
-o libpango-1.0.so.0.0.1234 *.o

This is pretty crazy but if it breaks at least it only affects 32bit
pango using programms and not the whole system like
/etc/ld.so.preload would.

MfG
Goswin

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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
 environment variable in a package. You could have an /etc/pango/config
 that tells libpango i386 to use lib32 and we ship it in ia32-libs-gtk
 only. But isn't than more work than always using lib32?

  Check the patch in the Ubuntu package, I thought I already sent it to
  you during the multiarch discussion.  It uses uname().  Attached.

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 fine.

MfG
Goswin

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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
 objcopy -W pango_get_sysconf_subdirectory -N pango_get_lib_subdirectory 
 pango-utils.o pango-utils2.o
 rm pango-utils.o
 gcc -m32 -O2 -W -Wall -c pangohack.c
 gcc -m32 -g -Wall -W -nostartfiles -shared -fPIC 
 -Wl,-soname,libpango-1.0.so.0 -o libpango-1.0.so.0.0.1234 *.o
 
 This is pretty crazy but if it breaks at least it only affects 32bit
 pango using programms and not the whole system like
 /etc/ld.so.preload would.

 I prefer this solution as IIUC it doesn't require any change to pango.
 Could you confirm this basically works?

 I suggest you drop the pango.modules from ia32-libs-gtk completely and
 sed the pango-module-file.d/pango instead (this is required anyway, not
 just for this solution).

-- 
Loïc Minier [EMAIL PROTECTED]

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d

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 fine.

 It certainly wont work as is, no.

-- 
Loïc Minier [EMAIL PROTECTED]

Bug#406455: libpango1.0-0: 32bit libpango must use /usr/lib32/pango/1.5.0/module-files.d