openSUSE Packaging June 2011

packaging@lists.opensuse.org

54 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

9 years, 10 months

[opensuse-packaging] Packaging policy for systemd .unit file

by Frederic Crozat

Hi all, as part of systemd integration in openSUSE, Michal suggested we might want to create our own openSUSE policy for packaging systemd .unit file, similar to Fedora policy http://fedoraproject.org/wiki/Packaging:Systemd , moreover the scriptlets part : http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd However, I'm not sure we should directly add those direct call to systemctl in %post but instead, use some macros, similar to the one we have for sysvinit and / or update those macros to be systemd compliant : %stop_on_removal / %insserv_force_if_yast / %{fillup_only} / % restart_on_update / etc.. Opinions ? -- Frederic Crozat <fcrozat(a)suse.com> SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years

[opensuse-packaging] HAL and related

by Ilya Chernykh

First of all I want to ask whether hal will be available under 12.1 or it is to be decided? My second question is as follows. As you know, hal is depreciated and people who prepare 12.1 want to remove dependency on hal from different packages. For instance they want to remove it from kdebase3-runtime which will be included in 12.1. But hal is necessary for normal function of KDE3 so we, who use KDE3 as a desktop want hal functions to be enabled. That's why my question. Is it possible to build a package with hal if hal is available in the repository and without hal otherwise? How to properly organize the check on whether the package exists in the repo at the buildtime? Or may be another solution based on an option constant defined in the project's properties is better? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 2 months

[opensuse-packaging] python > 2.7.1 for 11.4?

by Mathias Homann

hi there, I'm still trying to package calibre >= 0.8 for opensuse. Problems are: 1. calibre by now requires python 2.7.1 or higher but NOT python 3 2. the original author is about as cooperative and helpful as the german tax authorities on a bad day. His general approach to any kind of support question is "If you're not running the binaries from my website, go eff yourself." ...problem with that is, calibre is pretty much the only decent ebook reader management software that is platform independent. any ideas? bye, MH -- Die unaufgeforderte Zusendung einer Werbemail an Privatleute verstößt gegen §1 UWG und §823 I BGB (Beschluß des LG Berlin vom 2.8.1998 Az: 16 O 201/98). Jede kommerzielle Nutzung der übermittelten persönlichen Daten sowie deren Weitergabe an Dritte ist ausdrücklich untersagt! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 2 months

Re: [opensuse-packaging] python > 2.7.1 for 11.4?

by Ismail Doenmez

On 06/30/2011 10:25 AM, Mathias Homann wrote: > nope, my package works fine, I just don't know if the requirement "python>= 2.7.1" on > calibre's website is just a quirk or actually justified... I think the author actually meant "Don't use Python3". So please submit updated calibre to Factory and we can move on :) -- Ismail Dönmez - openSUSE Booster SUSE LINUX Products GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 2 months

[opensuse-packaging] Debuginfo is not included on 11.1

by Michal Vyskocil

Hi all, I have a problem with icedtea-web build on (Evergreen) 11.1. Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/icedtea-web-1.1-build error: Installed (but unpackaged) file(s) found: /usr/lib/debug/.build-id/3e/c823cdc0980d1f9ddc5ee234b19bc0565e8804 /usr/lib/debug/.build-id/3e/c823cdc0980d1f9ddc5ee234b19bc0565e8804.debug so it seems like debuginfo and debugsource packages are not included into spec file. The debug is enabled for that project (build with --debug did not change anything) and I see %suse_insert_debug_package after rpmbuild, so don't don't where is the problem. The same spec works well for 11.2+. https://build.opensuse.org/package/live_build_log?arch=i586&package=icedtea… Anyone have a hint what should be wrong? Regards Michal Vyskocil

10 years, 2 months

[opensuse-packaging] pyparsing naming advice/notice

by aledr

Good day! We currently have python-parsing and python-pyparsing, and both points to pyparsing[1]. As the naming convention says and discussed before[2], seems that the name python-pyparsing is the most suited here. If there is no objections i would like to provide the needed changes (removing python-parsing, updating python-pyparsing, cleaning the spec file and setting needed Provides/Obsoletes tags). Thanks. [1]: http://pypi.python.org/pypi/pyparsing [2]: http://lists.opensuse.org/opensuse-packaging/2011-05/msg00186.html -- [ ]'s Aledr - Alexandre "OpenSource Solutions for SmallBusiness Problems" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 2 months

[opensuse-packaging] Package categorization

by Ilya Chernykh

Hi! I first discussed this issue with coolo in private but possible a wider range of ideas may be beneficial. All of us know that is is sometimes confusing to find a package which belongs to your desktop environment, whether Gnome or KDE. Sometimes you have to look into package's dependencies to find out whether it is written in GTK or Qt. As the number of desktops increases, the problem only becomes worser. Currently the packages are classifies using the RPM groups. But for the most packages this groupping only reflects the package's purpose, i.e. network, game or office. This groupping is organized as a tree, and there is no possibility to add another categorization. An obvious solution is to add a desktop environment name to the package's name such as prefixing all KDE apps with "kde-" or simple "k". But this is also confusing and may require much of work as renaming is not an easy task. So are there any ideas on how to organize this better? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 2 months

[opensuse-packaging] Strange issue...

by Nelson Marques

Hi all, I'm having a small problem with a package which giving me a huge headache to build the latest version of Banshee. This dependency was introduced in this development version (dbus-sharp-glib). The spec file[1] seems to be ok... but: 1. The log shows that either dbus-sharp-glib and dbus-sharp-glib-devel have been installed (but it's false, osc chroot and a simple query to the rpm database shows this package hasn't been installed). This makes the build fail (of course it does)... Anyone has a clear idea on how to debug this further on ? NM [1] - http://tinyurl.com/64nb9cw -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 2 months

[opensuse-packaging] Failed source download service in obs, but locally it works (server:php:applications horde4)

by Ralf Lang

Can anybody give me clues why the download source service in OBS server:php:applications horde4 says it cannot download (making the package broken) but locally it runs just fine against a checkout of this repo? -- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 2 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging June 2011