Re: gconf transition
* Josselin Mouette | /usr/lib/libgconf2-4/gconf-sanity-check-2: error while loading shared | libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such | file or dir | | Ladies and gentlemen, this is a perfect example of why linking indirect | dependencies is a very bad thing. Let me explain. No, it's not. At least not in the way GTK friends work. | Of all binaries shipped with GConf, gconf-sanity-check is the only one | using GTK+. The only application using gconf-sanity-check is | gnome-session. On first sight, it looks safe to exclude | gconf-sanity-check for the computation of gconf dependencies, Uhm, this is where you go wrong. You can't just exclude binaries nilly-willy like this. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
On Sat, Jan 07, 2006 at 03:09:34PM +0100, Josselin Mouette wrote: Le vendredi 06 janvier 2006 à 14:28 -0600, Alejandro Bonilla a écrit : /usr/lib/libgconf2-4/gconf-sanity-check-2: error while loading shared libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such file or dir Ladies and gentlemen, this is a perfect example of why linking indirect dependencies is a very bad thing. Let me explain. Linking indirect dependency isn't a good thing, but not linking to them isn't magicly going to fix bugs like this. Of all binaries shipped with GConf, gconf-sanity-check is the only one using GTK+. The only application using gconf-sanity-check is gnome-session. On first sight, it looks safe to exclude gconf-sanity-check for the computation of gconf dependencies, as gnome-session will always require libgtk2.0-0, and gconf-sanity-check isn't susceptible to use any symbols that could be added to GTK+. You should _never_ exclude anything for the calculation of the dependencies, because it will result in such errors. Even if you think some other dependency will (now) take care of this for you doesn't mean you shouldn't have a depends on it. There are cases where excluding something can make sense, but this isn't one of them. Now, let's have a look at gconf-sanity-check: NEEDED libgtk-x11-2.0.so.0 [...] NEEDED libpangocairo-1.0.so.0 [...] So gconf-sanity-check-2 (from the libgconf2-4 package) NEEDS libpangocairo-1.0.so.0 from the libpango1.0-0 package. So libgconf2-4 should depend on libpango1.0-0. And it doesn't. This is an RC bug in the libgconf2-4 package. It's also missing all those other depends, specially the one on libgtk2.0-0. The only libraries from which it actually uses symbols are libgconf2, libgtk-x11, libglib and libc. It seems to be: libgtk-x11-2, libgconf-2, libpopt, libgobject-2, libpthread, libglib-2 and libc. So make it only link to those libraries instead. This shouldn't be that hard. And I think that using --as-needed as you did is the wrong way to go. This should be a last resort option in case you really can't fix it some other way. So in short you should: - Remove the -Xgconf-sanity-check from DEB_DH_SHLIBDEPS_ARGS This is something you should do in _any_ case since it's just wrong. - Remove the LDFLAGS=-Wl,--as-needed from DEB_CONFIGURE_SCRIPT_ENV - Use Debian's libtool - Only link (gconf-sanity-check-2) to the libraries it needs. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
Le lundi 09 janvier 2006 à 14:41 +0100, Tollef Fog Heen a écrit : | Ladies and gentlemen, this is a perfect example of why linking indirect | dependencies is a very bad thing. Let me explain. No, it's not. At least not in the way GTK friends work. Why so? | Of all binaries shipped with GConf, gconf-sanity-check is the only one | using GTK+. The only application using gconf-sanity-check is | gnome-session. On first sight, it looks safe to exclude | gconf-sanity-check for the computation of gconf dependencies, Uhm, this is where you go wrong. You can't just exclude binaries nilly-willy like this. Of course I can. The gconf-sanity-check binary is absolutely not necessary for the rest of the gconf functionality. This is an optional add-on, which isn't even in /usr/bin. It is perfectly safe to put its dependencies in Recommends:. A more elegant solution would be to make a separate package for gconf-sanity-check, but it is only 11K. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: gconf transition
Le lundi 09 janvier 2006 à 15:45 +0100, Kurt Roeckx a écrit : Linking indirect dependency isn't a good thing, but not linking to them isn't magicly going to fix bugs like this. How so? Please show me a case where the bug will still be here. You should _never_ exclude anything for the calculation of the dependencies, because it will result in such errors. Even if you think some other dependency will (now) take care of this for you doesn't mean you shouldn't have a depends on it. The gconf-sanity-check functionality is optional. As such, its dependencies can go in the Recommends: field. The bug was that these dependencies were missing indirect libraries the binary actually requires. So gconf-sanity-check-2 (from the libgconf2-4 package) NEEDS libpangocairo-1.0.so.0 from the libpango1.0-0 package. So libgconf2-4 should depend on libpango1.0-0. And it doesn't. This is an RC bug in the libgconf2-4 package. It's also missing all those other depends, specially the one on libgtk2.0-0. Nothing linking with libgconf2-4 will stop working when these dependencies aren't installed. Some optional functionality will, but it is not part of the functionality almost all packages using gconf2 actually need. It seems to be: libgtk-x11-2, libgconf-2, libpopt, libgobject-2, libpthread, libglib-2 and libc. So make it only link to those libraries instead. This shouldn't be that hard. You haven't investigated how to do it, have you? And I think that using --as-needed as you did is the wrong way to go. This should be a last resort option in case you really can't fix it some other way. I don't believe --as-needed should be a last resort option. Is dh_fixperms a last resort option when you cannot fix the build system to install files with proper permissions? Even with a fixed build system, you still use dh_fixperms, just to be sure. The same goes for --as-needed. As for relibtoolizing, it is currently not possible to relibtoolize all GNOME packages, because of a lack of manpower. If you want to see them relibtoolized, you'd better get libtool upstream to accept the Debian patches. Even with relibtoolized packages, the problem remains, because of pkg-config. As GNOME headers have a spurious tendency to include headers from most of their dependencies, it isn't possible to move them to private dependencies. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: gconf transition
* Josselin Mouette | Le lundi 09 janvier 2006 à 14:41 +0100, Tollef Fog Heen a écrit : | | Ladies and gentlemen, this is a perfect example of why linking indirect | | dependencies is a very bad thing. Let me explain. | | No, it's not. At least not in the way GTK friends work. | | Why so? Because GTK exports and depends on the definitions of GLib (and pango, in this case) types, so if any of those definitions change, you must get the right ones. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: gconf transition
Le lundi 09 janvier 2006 à 16:42 +0100, Tollef Fog Heen a écrit : Because GTK exports and depends on the definitions of GLib (and pango, in this case) types, so if any of those definitions change, you must get the right ones. That's why GTK itself depends on GLib and pango. I don't get your point. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: gconf transition
On Mon, 2006-01-09 at 16:10 +0100, Josselin Mouette wrote: Le lundi 09 janvier 2006 à 15:45 +0100, Kurt Roeckx a écrit : Linking indirect dependency isn't a good thing, but not linking to them isn't magicly going to fix bugs like this. How so? Please show me a case where the bug will still be here. You should _never_ exclude anything for the calculation of the dependencies, because it will result in such errors. Even if you think some other dependency will (now) take care of this for you doesn't mean you shouldn't have a depends on it. The gconf-sanity-check functionality is optional. As such, its Why is gconf-sanity-check optional? It seems pretty vital to me. -- - Ron Johnson, Jr. Jefferson, LA USA Thinking men cannot be ruled. Ayn Rand
Re: gconf transition
On Monday, 9 January 2006 19:26, Ron Johnson wrote: The gconf-sanity-check functionality is optional. As such, its Why is gconf-sanity-check optional? It seems pretty vital to me. AFAIK only gdm (or gnome-settings-daemon) uses gconf-sanity-check and both depend on libgtk2.0-0. Best regards -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: [EMAIL PROTECTED] | Debian: [EMAIL PROTECTED] pgpuVW97Rn9Wo.pgp Description: PGP signature
Re: gconf transition
[Re-sending, my previous reply didn't made it.] Le lundi 09 janvier 2006 à 15:45 +0100, Kurt Roeckx a écrit : Linking indirect dependency isn't a good thing, but not linking to them isn't magicly going to fix bugs like this. How so? Please show me a case where the bug will still be here. You should _never_ exclude anything for the calculation of the dependencies, because it will result in such errors. Even if you think some other dependency will (now) take care of this for you doesn't mean you shouldn't have a depends on it. The gconf-sanity-check functionality is optional. As such, its dependencies can go in the Recommends: field. The bug was that these dependencies were missing indirect libraries the binary actually requires. So gconf-sanity-check-2 (from the libgconf2-4 package) NEEDS libpangocairo-1.0.so.0 from the libpango1.0-0 package. So libgconf2-4 should depend on libpango1.0-0. And it doesn't. This is an RC bug in the libgconf2-4 package. It's also missing all those other depends, specially the one on libgtk2.0-0. Nothing linking with libgconf2-4 will stop working when these dependencies aren't installed. Some optional functionality will, but it is not part of the functionality packages using libgconf2-4 actually need. It seems to be: libgtk-x11-2, libgconf-2, libpopt, libgobject-2, libpthread, libglib-2 and libc. So make it only link to those libraries instead. This shouldn't be that hard. You haven't investigated how to do it, have you? And I think that using --as-needed as you did is the wrong way to go. This should be a last resort option in case you really can't fix it some other way. I don't believe --as-needed should be a last resort option. Is dh_fixperms a last resort option when you cannot fix the build system to install files with proper permissions? Even with a fixed build system, you still use dh_fixperms, just to be sure. The same goes for --as-needed. As for relibtoolizing, it is currently not possible to relibtoolize all GNOME packages, because of a lack of manpower. If you want to see them relibtoolized, you'd better get libtool upstream to accept the Debian patches. Even with relibtoolized packages, the problem remains, because of pkg-config. As GNOME headers have a spurious tendency to include headers from most of their dependencies, it isn't possible to move them to private dependencies. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: gconf transition
On Mon, 2006-01-09 at 19:50 +0100, Isaac Clerencia wrote: On Monday, 9 January 2006 19:26, Ron Johnson wrote: The gconf-sanity-check functionality is optional. As such, its Why is gconf-sanity-check optional? It seems pretty vital to me. AFAIK only gdm (or gnome-settings-daemon) uses gconf-sanity-check and both depend on libgtk2.0-0. So gconf-sanity-check should be in gconf, and gnome-settings-daemon should depend on gconf? ISTM that since gconf is so vital to GNOME, a sanity checker is vital to be able to fix corruptions. -- - Ron Johnson, Jr. Jefferson, LA USA When you see a rattlesnake poised to strike, you do not wait until he has struck before you crush him. Franklin D. Roosevelt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
On Mon, Jan 09, 2006 at 04:42:05PM +0100, Tollef Fog Heen wrote: * Josselin Mouette | Le lundi 09 janvier 2006 à 14:41 +0100, Tollef Fog Heen a écrit : | | Ladies and gentlemen, this is a perfect example of why linking indirect | | dependencies is a very bad thing. Let me explain. | | No, it's not. At least not in the way GTK friends work. | Why so? Because GTK exports and depends on the definitions of GLib (and pango, in this case) types, so if any of those definitions change, you must get the right ones. How can those definitions change without changing the ABI of GTK itself? If the ABI of GTK changes, so must the soname. I don't see a problem here. -- 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/ signature.asc Description: Digital signature
Re: gconf transition
Alejandro Bonilla wrote: I just upgraded Sid and rebooted, after that, logging into Gnome told me if I wanted to migrate to a Single file that will give me better performance, so of course I said yes. It logged me off and everytime that I need to log back in, it kicks me out. I don't have any special scripts, I just use some PAM for the FingerPrint reader. Still, ignoring the fingerprint authentication, it fails. [errors] Which package gets the bug report? Well, it does say it will break some things (did not break anything for me though), so I am sure developers are well aware. If you are not terribly concerned about loosing some of your settings, I suggest you delete your .gconf and let it be regenerated. By the way, you are much more likely to receive answers to such questions if you post in debian-user. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
Hi, On Fri, Jan 06, 2006, Alejandro Bonilla wrote: /usr/lib/libgconf2-4/gconf-sanity-check-2: error while loading shared libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such file or dir gconf-sanity-check-2 did not pass, logging back out I've filed a serious bug on gconf for now, but this might not be a _gconf_ bug. Thanks for your report, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
Le vendredi 06 janvier 2006 à 14:28 -0600, Alejandro Bonilla a écrit : Hi, I just upgraded Sid and rebooted, after that, logging into Gnome told me if I wanted to migrate to a Single file that will give me better performance, so of course I said yes. It logged me off and everytime that I need to log back in, it kicks me out. In fact it has nothing to do with the schema migration. /usr/lib/libgconf2-4/gconf-sanity-check-2: error while loading shared libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such file or dir Ladies and gentlemen, this is a perfect example of why linking indirect dependencies is a very bad thing. Let me explain. Of all binaries shipped with GConf, gconf-sanity-check is the only one using GTK+. The only application using gconf-sanity-check is gnome-session. On first sight, it looks safe to exclude gconf-sanity-check for the computation of gconf dependencies, as gnome-session will always require libgtk2.0-0, and gconf-sanity-check isn't susceptible to use any symbols that could be added to GTK+. Now, let's have a look at gconf-sanity-check: NEEDED libgtk-x11-2.0.so.0 NEEDED libgdk-x11-2.0.so.0 NEEDED libXrandr.so.2 NEEDED libXi.so.6 NEEDED libXinerama.so.1 NEEDED libXext.so.6 NEEDED libatk-1.0.so.0 NEEDED libgdk_pixbuf-2.0.so.0 NEEDED libpangocairo-1.0.so.0 NEEDED libpangoft2-1.0.so.0 NEEDED libXcursor.so.1 NEEDED libpango-1.0.so.0 NEEDED libcairo.so.2 NEEDED libpng12.so.0 NEEDED libfontconfig.so.1 NEEDED libfreetype.so.6 NEEDED libXrender.so.1 NEEDED libX11.so.6 NEEDED libxml2.so.2 NEEDED libz.so.1 NEEDED libgconf-2.so.4 NEEDED libORBit-2.so.0 NEEDED libpopt.so.0 NEEDED libgobject-2.0.so.0 NEEDED libm.so.6 NEEDED libgmodule-2.0.so.0 NEEDED libdl.so.2 NEEDED libgthread-2.0.so.0 NEEDED libpthread.so.0 NEEDED libglib-2.0.so.0 NEEDED libc.so.6 The only libraries from which it actually uses symbols are libgconf2, libgtk-x11, libglib and libc. Now, as the dependencies of libgtk2.0-0 change, when the GTK+ backend changes, they're still required while not being really needed, but the program will nevertheless crash upon startup when not finding them. You can now thank pkg-config and libtool. I'm going to fix this right away, thanks for the report. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: gconf transition
Alejandro Bonilla [EMAIL PROTECTED] writes: /usr/lib/libgconf2-4/gconf-sanity-check-2: error while loading shared libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such file or dir gconf-sanity-check-2 did not pass, logging back out Fun! :-/ Which package gets the bug report? Looks like libgconf2-4, for lacking proper dependencies (on libpango1.0-0, at the very least). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
