openSUSE Packaging September 2011

packaging@lists.opensuse.org

57 participants
44 discussions

[opensuse-packaging] Desktop-related macros for scriptlets

by Vincent Untz

Hi, Something I probably failed to document properly in 11.4 is the new macros that got introduced for desktop-related things (some of them being, arguably, GTK+-only). They were introduced to fix various issues, and move away from the SuSEconfig scripts. With rpm 4.9, we might be able to use another solution. In that case, the macros listed below will just expand to an empty string and do nothing. So it won't harm to use them either. Desktop-related macros ====================== a) Package installs a .desktop file in /usr/share/applications Macros: %desktop_database_post/%desktop_database_postun What it does: calls update-desktop-database to update a cache mapping MIME types to apps handling them. This is needed to make the desktops aware that an app can handle a MIME type. b) Package installs a MIME definition (in /usr/share/mime): Macros: %mime_database_post/%mime_database_postun What it does: calls update-mime-database to update the database containing information about all MIME definitions. c) Package installs an icon in hicolor (/usr/share/icons/hicolor): Macros: %icon_theme_cache_post/%icon_theme_cache_postun What it does: calls gtk-update-icon-cache (if existing) to update the GTK+ icon cache for hicolor, as specified by the spec. This is needed to make the icon visible to GTK+ apps. d) Package installs an icon in another icon theme (let's say "geeko" theme, /usr/share/icons/geeko) Macros: %icon_theme_cache_post geeko / %icon_theme_cache_postun geeko What it does: calls gtk-update-icon-cache (if existing) to update the GTK+ icon cache for geeko. This is needed to make the icon visible to GTK+ apps. e) Package installs a GSettings schema (in /usr/share/glib-2.0/schemas): Macros: %glib2_gsettings_schema_post/%glib2_gsettings_schema_postun %glib2_gsettings_schema_requires (similar to %py_requires) What it does: calls glib-compile-schemas to build the blob containing the data for all schemas. This is needed to have your app not crash :-) f) Package installs a gio module (in /usr/lib/gio/modules): Macros: %glib2_gio_module_post/%glib2_gio_module_postun %glib2_gio_module_requires (similar to %py_requires) What it does: calls gio-querymodules to update a cache listing all gio modules and the extension points they are using. This is needed to make the gio module known to gio. g) Package installs a gdk-pixbuf loader (in /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders): Macros: %gdk_pixbuf_loader_post/%gdk_pixbuf_loader_postun %gdk_pixbuf_loader_requires (similar to %py_requires) What it does: calls gdk-pixbuf-query-loaders to update a cache listing all gdk-pixbuf loaders and their abilities. This is needed to make the gdk-pixbuf loader known to gdk-pixbuf. h) Package installs a GTK+ (2 or 3) IM module (in /usr/lib/gtk-2.0/2.10.0/immodules or /usr/lib/gtk-3.0/3.0.0/immodules): Macros: %gtk2_immodule_post/%gtk2_immodule_postun %gtk2_immodule_requires %gtk3_immodule_post/%gtk3_immodule_postun %gtk3_immodule_requires What it does: calls gtk-query-immodules-2.0/gtk-query-immodules-3.0 to build a cache listing all IM modules and the locale/language they apply to. You obviously need to only call the gtk2/gtk3 version, depending on which version of GTK+ you target. This is needed to make the IM module known to GTK+. i) Package installs a pango module (in /usr/lib/pango/1.6.0/modules): Macros: %pango_module_post/%pango_module_postun %pango_module_requires (similar to %py_requires) What it does: calls pango-querymodules to update a cache listing all pango modules and information about what they handle. This is needed to make the module known to pango. Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 5 months

[opensuse-packaging] review split glibc-devel-static

by Rüdiger Meier

Hi, Even I've tripped over the separated static libc into the new package glibc-devel-static. reference http://old.nabble.com/glibc-devel-static-coming-to-Factory-tt31860569.html#… I think the split itself is a good idea but is the package name well choosen? Fedora/CentOS/RedHat have made the split into glibc-static Mandriva calls it glibc-static-devel Now suse invents glibc-devel-static IMO this is a pain for people trying to make portable spec files depending on static libc. So if possible I would suggest to follow Fedora (because they did that already years ago) and rename it to glibc-static too. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 6 months

[opensuse-packaging] Obsoletes < vs Obsoletes <=

by Jan Engelhardt

Hi, in discussions etc. people say one should use < in the obsoletes/provides relation: Obsoletes: foo < %version Provides: foo = %version However this does not reliably "work" when %version did not change across the change (e.g. changing EV from foo-1.0 towards libfoo-1.0), the old foo-1.0 will stick around because it is not obsoleted by libfoo-1.0. So "foo < %version" is actually bogus and should be either <=, or actually foo < %version-%release. <= makes technology unhappy ("package obsoletes itself"), so that leaves us with the %version-%release approach. Does baselibs.conf support obsoletes "foo < <version>-<release>" actually? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 7 months

[opensuse-packaging] libray whitelist - packages not found help

by Robert Schweikert

Hi, After some more digging and lots of clicking ;) I end up with the following entries in the whitelist that do not appear to match anything. "libartskde1" : "no package found", "libevolutionglue" : "no package found", "libgladesharpglue-2" : "no package found", "libglibsharpglue-2" : "no package found", "libgnomesharpglue-2" : "no package found", "libgsfglue" : "no package found", "libICE6" : "no package found", "libind_helper0" : "no package found", "libmdbodbc0" : "no package found", "libQtSql4" : "no package found", "libSM6" : "no package found", "libz1" : "no package found", If anyone recognizes one of these names and can confirm that it really no longer exists I would appreciate it. On the contrary, if you do recognize a name and the package still exists in the project please point me to the project and spec that produces the library in question. I'll rip these out within the next couple of days if I do not hear anything back. Help is appreciated, Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 7 months

[opensuse-packaging] The source service validator is creating havoc in my home project

by Dave Plater

The above mentioned monstrosity is creating havoc with packages I maintain especially the ones with links eg. ladspa has linked package ladspa-devel and ladspa won't build until it's devel one has. I work with the main package locally it's normally not necessary to download the liked package at double the bandwidth. I'm amusing myself cleaning up ladspa and fixing hydrogen, failing in factory for a few months which uses ladspa-devel and version 0.9.6 builds happily except that my ladspa-devel which hydrogen has difficulty in finding keeps on getting screwed up by the source service validator. Can someone please commit it to staging and fix it before unleashing it on the world. I might add that I'm amusing myself with this work while waiting for an extremely sluggish factory to allow guile1 and guile and lilypond to complete builds. Dave -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 7 months

[opensuse-packaging] library policy whitelist

by Robert Schweikert

Hi, As agreed at osc11 I am working to add version numbers to the library whitelist such that we can gradually eliminate the list and enforce the library policy on all appropriate packages. While processing the list I have found a number of packages listed that no longer exist, such as libEMF1 or libglibsharpglue-2. IMHO we should just remove these from the list. There should be no harm, unless there are false positives, i.e. packages I was not able to find but they exist. One such example may be libXrender. libXrender is listed in the whitelist as libXrender1 and it cannot be found using "osc bse". However, using the web search interface one can find xorg-x11-libXrender. This leads me to my next question. How is the whitelist used? Exact matches or loose matches, i.e. the libXrender1 listing matches xorg-x11-libXrender and thus exempts it from the policy or, libXrender1 does not match xorg-x11-libXrender and therefore there is no exemption. Next are the entries in the list that list packages in home: projects. IMHO these should also be removed from the list. Of course we can discuss whether or not packaging policies should be enforced in home projects, but I'd rather not go down that rat hole. Finally some statistics: Current total entries in the whitelist: 119 Packages only in home: projects: 14 Packages not found: 63 Thus the list would only have 42 entries if we decide to remove everything that cannot be found based on the listed name and things that are in home: projects. Thought/Comments? Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 7 months

[opensuse-packaging] help with naming please - shared library policy naming problem

by Robert Schweikert

Yes, very ironic.... I am fiddling around with swfdec in home:rjschwei:openshot/libswfdec and am running into a problem with the naming. The build process, by default, produces 2 libraries, one just the decoder (libswfdec) and another bound to GTK+ (libswfdec-gtk). I'd like to keep these separate but am running into trouble. The spec file starts out with: Name: libswfdec-0_8-0 this will meet the shared library policy for "libswfdec" :) . I also have a section in the spec file for the gtk library; this looks as follows: %package gtk ..... This of course produces a package name of "libswfdec-0_8-0-gtk" when I really want "libswfdec-gtk-0_8-0". How do I beat this naming issue into submission. I can disable the build of the gtk library, which avoids the problem of course, but I'd rather not. Help is appreciated. Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 7 months

[opensuse-packaging] Rationale behind X-SuSE-Unimportant in .desktop files?

by Vincent Untz

Hi, We have an extension for .desktop files that enables us to say when an application is unimportant; the result is that the application does not appear in the menus by default. To do this, we just add X-SuSE-Unimportant=True to the .desktop file. On my machine, this is used in those files: $ grep -rl X-SuSE-Unimportant /usr/share/applications /usr/share/applications/xload.desktop /usr/share/applications/xclipboard.desktop /usr/share/applications/Xrefresh.desktop /usr/share/applications/Xkill.desktop /usr/share/applications/xcalc.desktop /usr/share/applications/math.desktop /usr/share/applications/xmag.desktop They come from xorg-x11, and libreoffice (math.desktop). This non-standard key is a bit of an issue, as it means that all implementations of the menu specification have to be patched to support this flag. And therefore, I'm wondering: is there any use for this? If we want to hide an application by default, then let's just do it with NoDisplay=true or Hidden=true, and the user can then chooses to display this application with a menu editor. Is there anybody opposed to killing this? Or am I missing something? FWIW, killing this might be as easy as updating update-desktop-files so that passing -u will add NoDisplay=true or Hidden=true, instead of adding X-SuSE-Unimportant=True. Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 7 months

[opensuse-packaging] Dropping google-gadgets

by Vincent Untz

Hi, Unless someone steps in, I'll drop google-gadgets from Factory in a few days. I know of nobody using the package, it was already kind of dead upstream, and with Google killing the non-Linux version, I don't think there's any hope to see this code get really alive again. If you want to maintain it, then you're most welcome :-) I can help you start, if needed. Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 7 months

Re: [opensuse-packaging] Request for perl help

by Joop Boonen

On Mon, September 26, 2011 11:49 pm, Greg Freemyer wrote: > On Mon, Sep 26, 2011 at 4:29 PM, Joop Boonen <joop.boonen(a)boonen.org> wrote: >> Hi Greg, >> >> As you can see this perl module (2.0.15) is quite old because of this probably doesn't support per 5.12 any more. >> http://search.cpan.org/~pmqs/IO-Compress-Bzip2-2.015/ >> I think it's better to use a more resent version. >> http://search.cpan.org/~pmqs/IO-Compress-2.037/ >> Contains IO:Compress:Bzip2 >> http://search.cpan.org/~pmqs/IO-Compress-2.037/lib/IO/Compress/Bzip2.pm >> >> I see that this package already exists: perl-IO-Compress in >> devel:languages:perl >> >> Regards, >> >> Joop. >> > > Joop, > > Thanks but this looking a little more complex. > > perl-IO-Compress won't install because it requires perl-Compress-Raw-Zlib > > perl-Compress-Raw-Zlib won't install because it is obsoleted by > perl-5.12.3-11.16.1.x86_64 > > Assuming that means what it says I'm testing this specfile change to perl-IO-Compress > I would use (if it works, I didn't test it). The reason is because perl 5.12 wouldn't work for example openSuSE 11.3.: %if perl < 5.12 in stead of %if 0%{suse_version} < 1140 > ============ > # Compress::Raw::Zlib is now a core perl function > %if 0%{suse_version} < 1140 > BuildRequires: perl(Compress::Raw::Zlib) >= %{version} > Requires: perl(Compress::Raw::Zlib) >= %{version} > %endif > ============ > > Can you (or anyone else) confirm that the above is accurate. > > Thanks > Greg > -- Regards, Joop. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 7 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging September 2011