Re: [RFH] Compiling a Gnome app / GTHREAD or XDamage error
Joe Wreschnig wrote: On Thu, 2006-03-23 at 18:20 +0100, Bastian Venthur wrote: checking for GTHREAD... configure: error: Byzanz requires GThread-2.0 = and XDamage = 1.0 to compile. make: *** [config.status] Error 1 Currently my package build-depends on: debhelper (= 4.0.0), autotools-dev, libexpat1-dev, libxdamage-dev, libpanelappletmm-2.6-dev, intltool, libgtk2.0-dev I guess the problem has something to do with GTHREAD, but I have no Idea which package provides it or if it's already in my build-depends, why config does not recognize it. No, the error message sucks, it doesn't distinguish between two different (completely unrelated) failures. I reported this earlier as http://bugs.debian.org/358253 when I was trying to get Byzanz compiled. Ah, thanks for the hint! Do you know a workaround for this problem, so I can compile the package? Regards, Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Solved] Compiling a Gnome app / GTHREAD or XDamage error
Bastian Venthur wrote: Joe Wreschnig wrote: On Thu, 2006-03-23 at 18:20 +0100, Bastian Venthur wrote: checking for GTHREAD... configure: error: Byzanz requires GThread-2.0 = and XDamage = 1.0 to compile. make: *** [config.status] Error 1 Currently my package build-depends on: debhelper (= 4.0.0), autotools-dev, libexpat1-dev, libxdamage-dev, libpanelappletmm-2.6-dev, intltool, libgtk2.0-dev I guess the problem has something to do with GTHREAD, but I have no Idea which package provides it or if it's already in my build-depends, why config does not recognize it. No, the error message sucks, it doesn't distinguish between two different (completely unrelated) failures. I reported this earlier as http://bugs.debian.org/358253 when I was trying to get Byzanz compiled. Ah, thanks for the hint! Do you know a workaround for this problem, so I can compile the package? I found the solution myself, just put PKG_CONFIG_PATH=/usr/X11R6/lib/pkgconfig:$(PKG_CONFIG_PATH) before your config-part in debian/rules. Works for me :) Thanks again Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Conflicting library names
I'm packaging libggtl (ITP #358659), which uses libsl (ITP #358657). The latter is rather unfortunately named. The namespace of two letter acronyms is rather crowded and there is already a /usr/lib/libsl0 in libsl0-heimdal. What would be a sane way to handle this situation? I'm thinking of just copying libsl into the package and linking statically to it and to not package libsl at all. IMHO there are already quite a lot of libraries in Debian that provide utilities such as linked lists for C programmers. Most of the uses of libsl are internal in libggtl, but some parts of its API return libsl derived data structures. There would be some need to have libsl at hand for users... Otherwise I would just take the easy road and not bother packaging libsl at all. signature.asc Description: Digital signature
Including .so symlinks in non-dev package: policy violation?
Hi! Is it forbidden by policy (or otherwise) to include .so symlinks without the version number (for example, libraryname.so - libraryname.so.0.0.0) in a non-dev package? I guess the general answer is that it shouldn't be done, but how about this particular case: synfig, a 2D vector animation package, uses a (libtool) dlopen()-style way of loading plugins at runtime. The plugins are shipped as .so's. The plugin loader is not sophisticated enough to ask the ltdl routines for a versioned library [0]. If we don't ship the unversioned .so symlinks together with the actual .so's, the program will not work unless the -dev package is installed with the unversioned symlinks (some plugins implement essential functionality). The plugin .so's are not designed to be accessed directly. The purpose is to access them through libsynfig, which is properly versioned. In a sense, they differ from shared libraries (libraries that are to be shared between applications). Is it ok to include the unversioned symlinks for the plugin .so's in the non-dev package (libsynfig0)? [0] This is a planned future enhancement, but until someone steps up to implement it, the simple loader is all we have. -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Including .so symlinks in non-dev package: policy violation?
On Fri, 2006-03-24 at 16:34 +0200, Fabian Fagerholm wrote: The plugin .so's are not designed to be accessed directly. The purpose is to access them through libsynfig, which is properly versioned. In a sense, they differ from shared libraries (libraries that are to be shared between applications). Is it ok to include the unversioned symlinks for the plugin .so's in the non-dev package (libsynfig0)? I forgot to mention that the plugins are shipped in /usr/lib/synfig/modules -- so the whole thing looks very much like the run-time support programs in policy 8.2, except in this case, the artifacts are shared objects, not executables. -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Including .so symlinks in non-dev package: policy violation?
On Fri, 2006-03-24 at 17:00 +0200, Fabian Fagerholm wrote: On Fri, 2006-03-24 at 16:34 +0200, Fabian Fagerholm wrote: The plugin .so's are not designed to be accessed directly. The purpose is to access them through libsynfig, which is properly versioned. In a sense, they differ from shared libraries (libraries that are to be shared between applications). Is it ok to include the unversioned symlinks for the plugin .so's in the non-dev package (libsynfig0)? I forgot to mention that the plugins are shipped in /usr/lib/synfig/modules -- so the whole thing looks very much like the run-time support programs in policy 8.2, except in this case, the artifacts are shared objects, not executables. In this case, the libraries don't need to be versioned at all, assuming they're entirely private to synfig. Similar cases (e.g. XMMS plugins, Python extensions) also do not have versioned names. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Including .so symlinks in non-dev package: policy violation?
Hi Fabian,
Fabian Fagerholm wrote:
Is it forbidden by policy (or otherwise) to include .so symlinks without
the version number (for example, libraryname.so -
libraryname.so.0.0.0) in a non-dev package?
In general, yes. Let's say your library package is libfoo0 and it
includes the files
libfoo.so.0.0.0
libfoo.so.0 - libfoo.so.0.0.0
libfoo.so - libfoo.so.0.0.0
Later the soname is changed, so you ship a new package libfoo1 containing
libfoo.so.1.0.0
libfoo.so.1 - libfoo.so.1.0.0
libfoo.so - libfoo.so.1.0.0
The libfoo.so symlink that exists in both packages will prevent you from
having libfoo0 and libfoo1 installed simultaneously, and this is a
Policy violation (runtime libs must be co-installable for ease of upgrades).
I guess the general answer is that it shouldn't be done, but how about
this particular case:
synfig, a 2D vector animation package, uses a (libtool) dlopen()-style
way of loading plugins at runtime. The plugins are shipped as .so's. The
plugin loader is not sophisticated enough to ask the ltdl routines for a
versioned library [0]. If we don't ship the unversioned .so symlinks
together with the actual .so's, the program will not work unless the
-dev package is installed with the unversioned symlinks (some plugins
implement essential functionality).
The plugin .so's are not designed to be accessed directly. The purpose
is to access them through libsynfig, which is properly versioned. In a
sense, they differ from shared libraries (libraries that are to be
shared between applications).
As long as they aren't in /usr/lib or some other place where the linker
can find them -- that is, they are private files of synfig -- you
actually don't need to follow Policy for shared libraries. I'm not
really even clear on why you need library versioning. If synfig and its
plugins are in the same binary Debian package, there is no problem at
all. If they are in different binary packages, say synfig and
synfig-plugins, but generated by the same source package, then you can
always have synfig Depend on synfig-plugins (= ${Source-Version}) so
they are guaranteed to be in sync.
Is it ok to include the unversioned symlinks for the plugin .so's in the
non-dev package (libsynfig0)?
If the only things in libsynfig0 are plugins, then I would rename it to
synfig-plugins, put the plugins into /usr/lib/synfig/modules, and
proceed as above.
If there is also an honest-to-goodness shared library that goes in
/usr/lib and itself uses the plugins, things get a bit more complicated.
The important thing is to make sure that libsynfig0 and the eventual
libsynfig1 are co-installable. One solution is to use versioned
directories. In the case of synfig, maybe you could have something like
this in the libsynfig0 package:
/usr/lib/synfig/0/modules/libplugin.so.0.0.0
/usr/lib/synfig/0/modules/libplugin.so - libplugin.so.0.0.0
/usr/lib/libsynfig.so.0.0.0
/usr/lib/libsynfig.so.0 - libsynfig.so.0.0.0
and in libsynfig-dev:
/usr/lib/libsynfig.so - libsynfig.so.0.0.0
/usr/lib/libsynfig.a
/usr/include/whatever.h
This supposes that libsynfig can be configured to look for its plugins
only in the directory /usr/lib/synfig/0/modules. When you bump the
soname, the lib becomes libsynfig.so.1.0.0 and the plugins go into
/usr/lib/synfig/1/modules, where the new lib is configured to look.
(For simplicity I'm assuming the main library and the plugins have
soversions that stay in sync. If this is the case, again I see no
reason for the plugins to need soversions.)
Hope this helps,
--
Kevin B. McCarty [EMAIL PROTECTED] Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
signature.asc
Description: OpenPGP digital signature
Re: Including .so symlinks in non-dev package: policy violation?
On Fri, Mar 24, 2006 at 05:00:19PM +0200, Fabian Fagerholm wrote: On Fri, 2006-03-24 at 16:34 +0200, Fabian Fagerholm wrote: The plugin .so's are not designed to be accessed directly. The purpose is to access them through libsynfig, which is properly versioned. In a sense, they differ from shared libraries (libraries that are to be shared between applications). Is it ok to include the unversioned symlinks for the plugin .so's in the non-dev package (libsynfig0)? I forgot to mention that the plugins are shipped in /usr/lib/synfig/modules -- so the whole thing looks very much like the run-time support programs in policy 8.2, except in this case, the artifacts are shared objects, not executables. Do you actually have to ship them as separate objects, or could you conceivably link statically to them? This is what Steve suggested here: http://lists.debian.org/debian-mentors/2005/01/msg00465.html Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: checkinstall - installation tracker
Justin Pryzby wrote: Your first Closes entry isn't terminated with a closing/right parenthesis; not that it really matters. Fixed You need to include the years of copyright (if available). Put copyright 2002-2006 Your rules file is set up as if you produced both -arch and -indep packages, but that isn't the case. In particular, you don't need DH_OPTIONS at all. That must be because originally I was producing 2 packages. Deleted the extra stuff. useless use of cat in the install target; you should probably just rely on the debhelper tools to do everything like: creating links compressing files creating directories installing files Fixed manpage installation. However, I can't use dh_installdocs, because using it on installwatch's documentation would overwrite the checkinstall files. I would have to rename the files in the source (the same reason dh_install doesn't help). You have sed commands, which aren't necessarily bad, but you could probably just include the changes in the .diff.gz. Some are actually needed (installwatch has a hack to detect if it has been installed). I used sed scripts because I didn't want to modify the original source files (specially on the configuration file). Deleted them, and modified the source. binary depends on build and install, but install already depends on build. I don't know why the template is like this; I'm filing a bug now.. Done. Your modified makefile might use install -s to install the library, rather than cp. Done. BTW, did you ever figure out why dpkg wasn't allowing you to directly install the new package? No. However, I've been playing a bit, and dpkg -B causes the package to install. Reuploaded the package. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicting library names
On Fri, Mar 24, 2006 at 12:54:01PM +0200, Kari Pahula wrote: I'm packaging libggtl (ITP #358659), which uses libsl (ITP #358657). The latter is rather unfortunately named. The namespace of two letter acronyms is rather crowded and there is already a /usr/lib/libsl0 in libsl0-heimdal. To be precise, it is a file collision, not a directory: libsl0-heimdal: usr/lib/libsl.so.0 libsl0-heimdal: usr/lib/libsl.so.0.1.2 What would be a sane way to handle this situation? I'm thinking of just copying libsl into the package and linking statically to it and to not package libsl at all. The obvious disadvantage to this is that the source package will be nonpristine (well, unless you use an embedded-style source package, which is like borderline-pristine or something). Most of the uses of libsl are internal in libggtl, but some parts of its API return libsl derived data structures. There would be some need to have libsl at hand for users... Otherwise I would just take the easy road and not bother packaging libsl at all. Perhaps you could install include files, including any from libsl, to /usr/include/ggtl/ (rather than cause more 2 letter collisions), and rename the library file to libggtl-sl? (And update the soname too of course). This means that some binaries won't run on different distributions, but there's no way around that anyway, right? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Linda warning: Shared object is linked with version 12 and 11 of libgnutls.
Hi, I am building package for fast-user-switch-applet[1] based on Ubuntu package. I get a linda warning: W: fast-user-switch-applet; Shared object /usr/lib/fast-user-switch-applet/fast-user-switch-applet is linked with version 12 and 11 of libgnutls. The binary object shown above links against 2 versions of the same shared library. This means your package may require conflicting packages to be installed at the same time, and is therefore uninstallable, or the binary may not work. This may also be ignored if versioned symbols are being used in both libraries. I installed the package and everything works fine, thus it seems I'm in the last situation. Is there anything I can do to avoid this, or should I simply override this warning? Thanks for your comments! Cheers, Julien [1] http://ignore-your.tv/fusa/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: fast-user-switch-applet: applet for the GNOME panel providing a menu to switch between users
Hi, I am looking for a sponsor for fast-user-switch-applet, an applet for the GNOME panel providing a menu to switch between users. Homepage: http://ignore-your.tv/fusa/ Licence: GNU GPL Copyright: James M. Cape [EMAIL PROTECTED] This package is now part of GNOME 2.14, and should thus be sponsored by a member of the GNOME team. My package is largely based on Ubuntu package for the previous release. It is linda and lintian error/warning free. You can find both signed sources and i386 binary package at: http://packages.kirya.net/debian/pool/main/f/fast-user-switch-applet/ Feel free to comment, especially on the description if not appropriate. Thanks a lot! Cheers, Julien signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFS: fast-user-switch-applet: applet for the GNOME panel providing a menu to switch between users
Le samedi 25 mars 2006 à 00:35 +0100, Julien Valroff a écrit : Hi, I am looking for a sponsor for fast-user-switch-applet, an applet for the GNOME panel providing a menu to switch between users. Homepage: http://ignore-your.tv/fusa/ Licence: GNU GPL Copyright: James M. Cape [EMAIL PROTECTED] Forgot to mention ITP #304763 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304763) Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: nautilus-open-terminal - nautilus plugin for opening terminals in arbitrary local paths through nautilus
Hi, I am looking for a sponsor for nautilus-open-terminal, a nautilus plugin for opening terminals in arbitrary local paths through nautilus. Homepage: http://manny.cluecoder.org/packages/nautilus-open-terminal/ Copyright: Christian Neumair [EMAIL PROTECTED] Licence: GNU GPL ITP #310258 [ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310258 ] This is a very simple package which is quite with newer GNOME releases as 'open in terminal' shortcut on a click on the desktop was removed. Signed sources and i386 inary package can be found at: http://packages.kirya.net/debian/pool/main/n/nautilus-open-terminal/ I would appreciate your comments on this package, and would be grateful if someone accepts to upload it. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: fast-user-switch-applet: applet for the GNOME panel providing a menu to switch between users
On Sat, 2006-03-25 at 00:35 +0100, Julien Valroff wrote: I am looking for a sponsor for fast-user-switch-applet, an applet for the GNOME panel providing a menu to switch between users. This package is now part of GNOME 2.14, and should thus be sponsored by a member of the GNOME team. Shouldn't you contact them directly? They probably even have a package already prepared in SVN. Their list is here: http://lists.debian.org/debian-gtk-gnome/ Some comments: * debian/changelog: since this is the first debian release, probably best to strip it back to one changelog entry that closes the ITP. * debian/control: add the homepage in the manner described by the developers reference section 6.2.4 * debian/compat: using version 4 would help people who may want to backport gnome 2.14 to sarge (and upload to backports.org) * AUTHORS: redundant, no need to install it - debian/copyright contains that info * README: please strip bits that are irrelevant for people using binary packages. Might want to ask upstream to split it into separate files * might also want to install HACKING * debian/copyright: You seem to ignore some of the copyright notices in the .po files and even the source code?!! ./src/applet.c especially. Please do a proper debian/copyright file by using mc and grep to find all copyright info. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
