Bug#406453: 32bit libgtk2.0 must use /etc/gtk-2.0/gdk-pixbuf.loaders.32

2007-01-17 Thread Goswin von Brederlow 
reassign 406453 libgtk2.0-0
thanks

Steve Langasek [EMAIL PROTECTED] writes:

 reassign 406453 ia32-libs-gtk
 thanks

 On Thu, Jan 11, 2007 at 10:36:23AM +0100, Goswin von Brederlow wrote:
 PS: I set this to grave as it makes ia32-libs-gtk unusable which
 contains libgtk-2.0.

 Then the problem is ia32-libs-gtk's, not libgtk2.0-0's.  There's no way it's
 an RC bug in gtk that you've repackaged it in a way that doesn't work.

ia32-libs-gtk does contain the libgtk2.0-0.deb, the precompiled binary
from i386. The source (included for GPL compliance only) is not and
can not be compiled so it can't be patched.

We could ship a patched precompiled libgtk2.0-0.deb but I think that
would be a very bad idea.

So back to libgtk2.0-0 with this bug. Patch below.


To get ia32-libs-gtk working properly chunks 1+2 of the patch need to
be applied. Chunks 3+4 just round things up by allowing the admin and
user to have different gtkrc files if they so choose.

MfG
Goswin

--[ debian/patches/030_compat_sysconfdir.patch ]---

diff -Nurd gtk+-2.8.20.orig/gdk-pixbuf/gdk-pixbuf-io.c 
gtk+-2.8.20/gdk-pixbuf/gdk-pixbuf-io.c
--- gtk+-2.8.20.orig/gdk-pixbuf/gdk-pixbuf-io.c 2005-10-03 15:11:49.0 
+
+++ gtk+-2.8.20/gdk-pixbuf/gdk-pixbuf-io.c  2007-01-17 16:38:15.0 
+
@@ -276,8 +276,20 @@
   gchar *result = g_strdup (g_getenv (GDK_PIXBUF_MODULE_FILE));
 
   if (!result)
- result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, 
gdk-pixbuf.loaders, NULL);
-
+{
+#if defined(__linux__)  ( defined(__i386__) || defined (__x86_64__) || 
defined(__ia64__) )
+# if defined (__i386__)
+  result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, 32, 
gdk-pixbuf.loaders, NULL);
+# else
+  result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, 64, 
gdk-pixbuf.loaders, NULL);
+#endif
+  /* Prefer compat gtk.immodules file if it's usable. */
+  if (! g_access(result, R_OK))
+return result;
+  g_free (result);
+#endif
+  result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, 
gdk-pixbuf.loaders, NULL);
+}
   return result;
 }
 
diff -Nurd gtk+-2.8.20.orig/gtk/gtkrc.c gtk+-2.8.20/gtk/gtkrc.c
--- gtk+-2.8.20.orig/gtk/gtkrc.c2005-11-23 14:24:51.0 +
+++ gtk+-2.8.20/gtk/gtkrc.c 2007-01-17 16:43:32.0 +
@@ -364,7 +364,20 @@
   if (im_module_file)
result = g_strdup (im_module_file);
   else
-   result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, gtk.immodules, 
NULL);
+{
+#if defined(__linux__)  ( defined(__i386__) || defined (__x86_64__) || 
defined(__ia64__) )
+# if defined (__i386__)
+ result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, 32, 
gtk.immodules, NULL);
+# else
+ result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, 64, 
gtk.immodules, NULL);
+# endif
+  /* Prefer compat gtk.immodules file if it's usable. */
+  if (!g_access(result, R_OK))
+return result;
+  g_free (result);
+#endif
+  result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, 
gtk.immodules, NULL);
+}
 }
 
   return result;
@@ -433,7 +446,17 @@
   else
 {
   const gchar *home;
-  str = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, gtkrc, NULL);
+#if defined(__linux__)  ( defined(__i386__) || defined (__x86_64__) || 
defined(__ia64__) )
+# if defined (__i386__)
+  str = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, 32, gtkrc, NULL);
+# else
+  str = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, 64, gtkrc, NULL);
+# endif
+  /* Prefer compat gtkrc if it's usable. */
+  if (g_access(str, R_OK))
+g_free (str), /* continue in next line */
+#endif
+str = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, gtkrc, NULL);
 
   gtk_rc_add_default_file (str);
   g_free (str);
@@ -441,7 +464,17 @@
   home = g_get_home_dir ();
   if (home)
{
- str = g_build_filename (home, .gtkrc-2.0, NULL);
+#if defined(__linux__)  ( defined(__i386__) || defined (__x86_64__) || 
defined(__ia64__) )
+# if defined (__i386__)
+  str = g_build_filename (home, .gtkrc-2.0-32, NULL);
+# else
+  str = g_build_filename (home, .gtkrc-2.0-64, NULL);
+# endif
+  /* Prefer compat .gtkrc-2.0 if it's usable. */
+  if (g_access(str, R_OK))
+g_free (str), /* continue in next line */
+#endif
+   str = g_build_filename (home, .gtkrc-2.0, NULL);
  gtk_rc_add_default_file (str);
  g_free (str);
}


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

Bug#406453: 32bit libgtk2.0 must use /etc/gtk-2.0/gdk-pixbuf.loaders.32

2007-01-17 Thread Steve Langasek 
clone 406453 -1
severity 406453 grave
reassign 406453 ia32-gtk-libs
thanks

On Wed, Jan 17, 2007 at 07:52:04PM +0100, Goswin von Brederlow wrote:
 reassign 406453 libgtk2.0-0
 thanks

 Steve Langasek [EMAIL PROTECTED] writes:

  On Thu, Jan 11, 2007 at 10:36:23AM +0100, Goswin von Brederlow wrote:
  PS: I set this to grave as it makes ia32-libs-gtk unusable which
  contains libgtk-2.0.

  Then the problem is ia32-libs-gtk's, not libgtk2.0-0's.  There's no way it's
  an RC bug in gtk that you've repackaged it in a way that doesn't work.

 ia32-libs-gtk does contain the libgtk2.0-0.deb, the precompiled binary
 from i386. The source (included for GPL compliance only) is not and
 can not be compiled so it can't be patched.

ia32-libs-gtk is unusable -- that's an RC bug in ia32-libs-gtk.  It's
unusable because gtk+2.0 doesn't support it -- that's a wishlist bug in
gtk+2.0.

You don't get to add new packages to the archive that depend on
unimplemented functionality in other packages, and then automatically
declare this brokenness an RC bug in the underlying package.

-- 
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#406453: 32bit libgtk2.0 must use /etc/gtk-2.0/gdk-pixbuf.loaders.32

2007-01-17 Thread Loïc Minier 
On Wed, Jan 17, 2007, Goswin von Brederlow wrote:
 To get ia32-libs-gtk working properly chunks 1+2 of the patch need to
 be applied. Chunks 3+4 just round things up by allowing the admin and
 user to have different gtkrc files if they so choose.

 I've started looking into the problem last week, and it's relatively
 complex.  Actually, for module pathes, Gtk will try plenty of pathes
 (as you might have seen in straces), so either we support a diversion
 of all of these (such as /etc/gtk-2.0/$host = /etc/gtk-2.0/$host.32),
 or we simply advice people to move away of these pathes (by default, a
 path including the triplet is checked).

 I've given some thought on how to handle this, and I don't want to spam
 all users with a fat NEWS.Debian, so I thought simply supporting
 diversions for what Debian ever shipped is enough
 (in /etc/gtk: gdk.loaders and gtk.immodules), and we shouldn't bother
 with supporting anything else at the code level, but this should be
 documented in README.Debian.
   I think this is particularly true for ~/.gtk-2.0 modules as I can
 imagine users compiling an IM method if they need one.
   I doubt changing the lookups in /usr/lib is useful, however I did not
 have time to look at all getenv calls to see whether or not some
 modules can be forcibly loaded without a full path via env vars.

 I'm not sure about handling of gtkrc, what made you customize this one?
 The possibility of loading modules from gtkrc?

 +# if defined (__i386__)
 +  result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, 32, 
 gdk-pixbuf.loaders, NULL);
 +# else
 +  if (! g_access(result, R_OK))

 I've collected patches from all other distros last week, and while they
 all use different names, I would prefer we use one of the existing
 names.

 Ubuntu:
GTK_SYSCONFDIR, gtk-2.0, gdk-pixbuf.loaders.32,
 OpenSuse:
GTK_SYSCONFDIR, gtk-2.0, gdk-pixbuf64.loaders
 Fedora:
GTK_SYSCONFDIR, gtk-2.0, HOST, gdk-pixbuf.loaders
(-DHOST=\$(host_triplet)\)

 (BTW, Fedora uses a slightly nicer test:)
g_file_test (result, G_FILE_TEST_EXISTS)

 The patches are attached.  My personal preference goes for the Ubuntu
 option, but the Fedora one might be the best as it re-uses a path which
 is already handled by Gtk, the only difference is that the path is
 preferred when present and no further path is used; this might be
 problematic with the default location of the loaders which we
 currently use, and it's too late to change it for this cycle.

-- 
Loïc Minier [EMAIL PROTECTED]
--- gtk+-2.8.13/gdk-pixbuf/gdk-pixbuf-io.c~	2005-10-03 17:11:49.0 +0200
+++ gtk+-2.8.13/gdk-pixbuf/gdk-pixbuf-io.c	2006-03-01 20:33:36.524552192 +0100
@@ -32,6 +32,7 @@
 #ifdef HAVE_UNISTD_H
 #include unistd.h
 #endif
+#include sys/utsname.h
 
 #include gdk-pixbuf-private.h
 #include gdk-pixbuf-io.h
@@ -276,8 +277,21 @@
   gchar *result = g_strdup (g_getenv (GDK_PIXBUF_MODULE_FILE));
 
   if (!result)
-	  result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, gdk-pixbuf.loaders, NULL);
+#if defined(__linux__)  defined (__i386__)
+	{
+	  struct utsname uts;
 
+	  uname(uts);
+	  result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, gdk-pixbuf.loaders.32, NULL);
+	  if (strcmp(x86_64, uts.machine) || access(result, R_OK))
+	{
+	  g_free(result);
+	  result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, gdk-pixbuf.loaders, NULL);
+	}
+	}
+#else
+	  result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, gdk-pixbuf.loaders, NULL);
+#endif
   return result;
 }
 
--- gtk+-2.8.13/gtk/gtkprivate.h~	2005-03-22 03:14:55.0 +0100
+++ gtk+-2.8.13/gtk/gtkprivate.h	2006-03-01 19:51:42.510740384 +0100
@@ -96,6 +96,13 @@
 
 #endif /* G_OS_WIN32 */
 
+#if defined(__linux__)  defined (__i386__)
+const gchar *_gtk_get_libdir ();
+
+#undef GTK_LIBDIR
+#define GTK_LIBDIR _gtk_get_libdir ()
+#endif
+
 gboolean _gtk_fnmatch (const char *pattern,
 		   const char *string,
 		   gbooleanno_leading_period);
--- gtk+-2.8.13/gtk/gtkmain.c~	2005-12-06 17:14:30.0 +0100
+++ gtk+-2.8.13/gtk/gtkmain.c	2006-03-01 20:36:05.175953744 +0100
@@ -42,6 +42,7 @@
 #include unistd.h
 #endif
 #include sys/types.h		/* For uid_t, gid_t */
+#include sys/utsname.h
 
 #ifdef G_OS_WIN32
 #define STRICT
@@ -336,6 +337,28 @@
 
 #endif /* G_OS_WIN32 */
 
+#if defined(__linux__)  defined (__i386__)
+const gchar *
+_gtk_get_libdir (void)
+{
+  static char *gtk_libdir = NULL;
+  if (gtk_libdir == NULL)
+{
+#if defined(__linux__)  defined (__i386__)
+  struct utsname uts;
+
+  uname(uts);
+  if (!strcmp(x86_64, uts.machine)
+	   !access(/usr/lib32/gtk-2.0, R_OK|X_OK))
+	gtk_libdir = /usr/lib32;
+  else
+#endif
+  gtk_libdir = /usr/lib;
+}
+  return gtk_libdir;
+}
+#endif
+
 static gboolean do_setlocale = TRUE;
 
 /**
--- gtk+-2.8.13/gtk/gtkrc.c~	2005-11-23 15:24:51.0 +0100
+++ gtk+-2.8.13/gtk/gtkrc.c	2006-03-01 20:33:25.952159440 +0100
@@ -38,6 +38,10 @@
 #include string.h
 #include stdio.h
 #include stdlib.h

Bug#406453: 32bit libgtk2.0 must use /etc/gtk-2.0/gdk-pixbuf.loaders.32

2007-01-17 Thread Goswin von Brederlow 
Steve Langasek [EMAIL PROTECTED] writes:

 clone 406453 -1
 severity 406453 grave
 reassign 406453 ia32-gtk-libs
 thanks

 On Wed, Jan 17, 2007 at 07:52:04PM +0100, Goswin von Brederlow wrote:
 reassign 406453 libgtk2.0-0
 thanks

 Steve Langasek [EMAIL PROTECTED] writes:

  On Thu, Jan 11, 2007 at 10:36:23AM +0100, Goswin von Brederlow wrote:
  PS: I set this to grave as it makes ia32-libs-gtk unusable which
  contains libgtk-2.0.

  Then the problem is ia32-libs-gtk's, not libgtk2.0-0's.  There's no way 
  it's
  an RC bug in gtk that you've repackaged it in a way that doesn't work.

 ia32-libs-gtk does contain the libgtk2.0-0.deb, the precompiled binary
 from i386. The source (included for GPL compliance only) is not and
 can not be compiled so it can't be patched.

 ia32-libs-gtk is unusable -- that's an RC bug in ia32-libs-gtk.  It's
 unusable because gtk+2.0 doesn't support it -- that's a wishlist bug in
 gtk+2.0.

 You don't get to add new packages to the archive that depend on
 unimplemented functionality in other packages, and then automatically
 declare this brokenness an RC bug in the underlying package.

Got me there. You are of cause right about the respective severities.

MfG
Goswin


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

Bug#406453: 32bit libgtk2.0 must use /etc/gtk-2.0/gdk-pixbuf.loaders.32

2007-01-17 Thread Goswin von Brederlow 
Loïc Minier [EMAIL PROTECTED] wrote:

On Wed, Jan 17, 2007, Goswin von Brederlow wrote:
 To get ia32-libs-gtk working properly chunks 1+2 of the patch need to
 be applied. Chunks 3+4 just round things up by allowing the admin and
 user to have different gtkrc files if they so choose.

 I've started looking into the problem last week, and it's relatively
 complex.  Actually, for module pathes, Gtk will try plenty of pathes
 (as you might have seen in straces), so either we support a diversion
 of all of these (such as /etc/gtk-2.0/$host = /etc/gtk-2.0/$host.32),
 or we simply advice people to move away of these pathes (by default, a
 path including the triplet is checked).

I don't see that in the logs. I only see:

32bit acroread:

access(/home/mrvn/.themes/Raleigh/gtk-2.0/gtkrc, F_OK) = -1 ENOENT (No such 
file or directory)
access(/usr/share/themes/Raleigh/gtk-2.0/gtkrc, F_OK) = 0
open(/etc/gtk-2.0/gdk-pixbuf.loaders, O_RDONLY|O_LARGEFILE) = 4
open(/etc/gtk-2.0/gtk.immodules, O_RDONLY|O_LARGEFILE) = 4

Seems like strace isn't showing lstats for 32bit code like below.


64bit gkrellm:

lstat(/etc/gtk-2.0/gtkrc, 0x7fffc5cd8a10) = -1 ENOENT (No such file or 
directory)
lstat(/home/mrvn/.gtkrc-2.0, 0x7fffc5cd8a10) = -1 ENOENT (No such file or 
directory)
access(/home/mrvn/.themes/Raleigh/gtk-2.0/gtkrc, F_OK) = -1 ENOENT (No such 
file or directory)
access(/usr/share/themes/Raleigh/gtk-2.0/gtkrc, F_OK) = 0
lstat(/usr/share/themes/Raleigh/gtk-2.0/gtkrc, {st_mode=S_IFREG|0644, 
st_size=69, ...}) = 0
open(/usr/share/themes/Raleigh/gtk-2.0/gtkrc, O_RDONLY) = 6
open(/etc/gtk-2.0/gdk-pixbuf.loaders, O_RDONLY) = 6

I see one global rc file, one in home, the themes rc file(s) and then
the loaders/modules.

I see nothing host specific and nothing with the triplet. If gtk would
load its conffiles from a dir with triplet we wouldn't have the
problem.

I've given some thought on how to handle this, and I don't want to spam
 all users with a fat NEWS.Debian, so I thought simply supporting
 diversions for what Debian ever shipped is enough
 (in /etc/gtk: gdk.loaders and gtk.immodules), and we shouldn't bother
 with supporting anything else at the code level, but this should be
 documented in README.Debian.
   I think this is particularly true for ~/.gtk-2.0 modules as I can
 imagine users compiling an IM method if they need one.
   I doubt changing the lookups in /usr/lib is useful, however I did not
 have time to look at all getenv calls to see whether or not some
 modules can be forcibly loaded without a full path via env vars.

I tried to be non-invasive with the patch and modeled it after the
pango change. Everything keeps working as is and only ia32-libs-gtk
uses the new dir to overload the normal path with the 32bit one.

 I'm not sure about handling of gtkrc, what made you customize this one?
 The possibility of loading modules from gtkrc?

You can have module paths in the gtkrc file. Unfortunately only for
modules, not for the loaders.

 +# if defined (__i386__)
 +  result = g_build_filename (GTK_SYSCONFDIR, gtk-2.0, 32, 
 gdk-pixbuf.loaders, NULL);
 +# else
 +  if (! g_access(result, R_OK))

 I've collected patches from all other distros last week, and while they
 all use different names, I would prefer we use one of the existing
 names.

 Ubuntu:
GTK_SYSCONFDIR, gtk-2.0, gdk-pixbuf.loaders.32,

As shown for pango uname() is inconclusive to the point of
harmfullness.

Changing the GTK_LIBDIR seems completly unneccessary. The modules and
loader files contain the full path to the *.so files so this has no
affect at all. Could this work with relative paths? Because if it does
we could have it search through all libdirs till it finds a loadable
module. No more different configs per arch.

On other notes I find it a bit inconsistent to use _gtk_get_libdir()
to change the libdir but then not use _gtk_get_sysconfdir() as well
for the sysconf part. Probably because they used a .32 suffix instead
of a subdir.

 OpenSuse:
GTK_SYSCONFDIR, gtk-2.0, gdk-pixbuf64.loaders

Intrusive to the build system and hardcodes everything to 64. This
would have to be conditionalized on the arch first.

 Fedora:
GTK_SYSCONFDIR, gtk-2.0, HOST, gdk-pixbuf.loaders
(-DHOST=\$(host_triplet)\)

For the final product this is the nicest but if we were to use this
now then multiarch packages would need to conflict with our hackish
ia32-libs-gtk. We stayed clear of that everywhere else.

 (BTW, Fedora uses a slightly nicer test:)
g_file_test (result, G_FILE_TEST_EXISTS)

If that is nicer I'm all for it. That is a simple change.

 The patches are attached.  My personal preference goes for the Ubuntu
 option, but the Fedora one might be the best as it re-uses a path which
 is already handled by Gtk, the only difference is that the path is
 preferred when present and no further path is used; this might be
 problematic with the default location of the loaders which we
 currently use, and it's too late to change it for this

Bug#406453: 32bit libgtk2.0 must use /etc/gtk-2.0/gdk-pixbuf.loaders.32

2007-01-12 Thread Steve Langasek 
reassign 406453 ia32-libs-gtk
thanks

On Thu, Jan 11, 2007 at 10:36:23AM +0100, Goswin von Brederlow wrote:
 PS: I set this to grave as it makes ia32-libs-gtk unusable which
 contains libgtk-2.0.

Then the problem is ia32-libs-gtk's, not libgtk2.0-0's.  There's no way it's
an RC bug in gtk that you've repackaged it in a way that doesn't work.

-- 
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#406453: 32bit libgtk2.0 must use /etc/gtk-2.0/gdk-pixbuf.loaders.32

2007-01-11 Thread Goswin von Brederlow 
Package: libgtk2.0-0
Version: 2.8.20-3
Severity: grave

When starting a 32bit gtk program on amd64 the libgtk uses the wrong conffile:

open(/etc/gtk-2.0/gdk-pixbuf.loaders, O_RDONLY|O_LARGEFILE) = 4

Subsequently the frong modules are attempted:

(acroread:1689): GdkPixbuf-WARNING **: Error loading XPM image loader: Unable 
to load image-loading module: 
/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so: 
/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so: cannot open shared 
object file: No such file or directory) = 277

Replacing /etc/gtk-2.0/gdk-pixbuf.loaders with
/etc/gtk-2.0/gdk-pixbuf.loaders.32 [and fixing the version from 2.10.0
to 2.4.0] fixes the problem for 32bit but obviously breaks 64bit.

The proper fix, and what afaik is supposed to happen, is for the 32bit
libgtk to use /etc/gtk-2.0/gdk-pixbuf.loaders.32 if it exists and the
64bit libgtk to use /etc/gtk-2.0/gdk-pixbuf.loaders.64 if it exists.

MfG
Goswin

PS: I set this to grave as it makes ia32-libs-gtk unusable which
contains libgtk-2.0.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-amd64
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages libgtk2.0-0 depends on:
ii  libatk1.0-0   1.12.3-1   The ATK accessibility toolkit
ii  libc6 2.3.6.ds1-9GNU C Library: Shared libraries
ii  libcairo2 1.2.4-4The Cairo 2D vector graphics libra
ii  libfontconfig12.4.2-1generic font configuration library
ii  libglib2.0-0  2.12.4-2   The GLib library of C routines
ii  libgtk2.0-common  2.8.20-3   Common files for the GTK+ graphica
ii  libjpeg62 6b-13  The Independent JPEG Group's JPEG 
ii  libpango1.0-0 1.14.8-4   Layout and rendering of internatio
ii  libpng12-01.2.15~beta5-1 PNG library - runtime
ii  libtiff4  3.8.2-6Tag Image File Format (TIFF) libra
ii  libx11-6  2:1.0.3-4  X11 client-side library
ii  libxcursor1   1.1.7-4X cursor management library
ii  libxext6  1:1.0.1-2  X11 miscellaneous extension librar
ii  libxfixes31:4.0.1-5  X11 miscellaneous 'fixes' extensio
ii  libxi61:1.0.1-4  X11 Input extension library
ii  libxinerama1  1:1.0.1-4.1X11 Xinerama extension library
ii  libxrandr22:1.1.0.2-5X11 RandR extension library
ii  libxrender1   1:0.9.1-3  X Rendering Extension client libra

Versions of packages libgtk2.0-0 recommends:
ii  hicolor-icon-theme0.8-4  default fallback theme for FreeDes
pn  libgtk2.0-bin none (no description available)

-- no debconf information


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