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
Hi,
As some of you are certainly already aware, I am creating a series of
blog posts around rpmlint errors and brp-check errors that can arise in
packages.
So on the weekend, Thanks to the input of Malcolm Lewis, a new post went
online, which addresses this error:
I: Statement might be overflowing a buffer in strncat.
The b log post with explanation why it happens and how to solve it can
be found at
http://dominique.leuenberger.net/blog/?p=189
Hope it helps you all out.
Dominique
PS: The offer still stands of course: whichever brp/lint you struggle
with, just send me a message and I will try to come up with a post about
it.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Can packages in 11.4 standard or update repositories build against packages provided in the tumbleweed update repository.? I've filed
bnc#696826 about 11.4's lv2core-devel's lv2config being unable to function due to a lack of package python-redland. The LV2 plugin system
cannot be used at all if the package can't build against lv2core and slv2, I submitted new packages lv2core, slv2 and an updated redland
package that included the python bindings before 11.4's release, lv2core is in the 11.4 distribution but slv2 is still in review, here is
it's history :
62079 State:declined By:autobuild When:2011-02-18T16:30:51
submit: multimedia:libs/slv2 -> openSUSE:Factory note: obsoleted by submitreq 62078
From: plater(new)
Descr: Removed conflict for libslv2-8
62078 State:review By:coolo When:2011-03-28T16:14:46
submit: multimedia:libs/slv2 -> openSUSE:Factory
From: plater(new) -> saschpe(review)
Descr: Removed conflict for libslv2-8
60049 State:declined By:autobuild When:2011-02-18T16:30:43
submit: multimedia:libs/slv2 -> openSUSE:Factory
From: plater(new)
Descr: Add slv2-0.6.6-licencefix.patch to remove file with conflicting
GPLv2 statement in the header.
See bnc#669117 and slv upstream drobillad #630
59638 State:declined By:autobuild When:2011-02-04T17:25:01
submit: multimedia:libs/slv2 -> openSUSE:Factory
From: plater(new)
Descr: New package slv2 is a library to make the use of LV2 plugins as
simple as possible for applications.slv2 is free software (GPL v2
or later) written in C99 using the Redland RDF toolkit, and is
known to work on GNU/Linux and Mac OS X. This package is the
other part of the slv2 lv2core needed for openSUSE packages to
use the LV2 plugin system and compliments submit request sr#59624
the home url for this package is
http://drobilla.net/software/slv2/ apart from the url and licence
all of the other relevant information is contained in submit
request id 59624
and this is sr#62078 the last request which is still open :
Request #62078:
submit: multimedia:libs/slv2(r5) -> openSUSE:Factory/slv2
Message:
Removed conflict for libslv2-8
State: review 2011-03-28T16:14:46 coolo
Comment: run checker
Review: new darix None None None Please decide
accepted None factory-auto 2011-03-29T16:16:48 coolo Builds for all Factory repos found
Output of check script (non-fatal):
History: review 2011-03-18T10:39:07 saschpe
new 2011-02-18T16:18:50 plater
This last request effectively blocks slv from even going into factory. There was a comment made in a reply during one of my many emails
pleading for slv2 to be accepted that it was a duplicate of a Packman package and I replied that it's purpose was to enable multimedia
applications to build with support for LV2 plugins and openSUSE packages cannot build against Packman packages.
I'm busy updating qtractor from 0.7.8 to 0.7.9 the earlier version would have been in 11.4 had slv2 been present and now it seems that
version 0.7.9 is also going to be blocked.
Reference threads :
http://lists.opensuse.org/opensuse-factory/2011-02/msg00678.htmlhttp://lists.opensuse.org/opensuse-factory/2011-02/msg00004.htmlhttp://lists.opensuse.org/opensuse-factory/2011-01/msg00377.html
I originally created the lv2core and slv2 packages when a user requested LV2 plugin support for ardour which isn't in the main distribution
but he was happy with the result and this verifies that there isn't anything wrong with the package. Maybe I violated an openSUSE rule
inadvertently but if nobody explains what it was I may do it again. I'm passionate about openSUSE multimedia and I feel that it presents an
important face of openSUSE.
Regards
Dave Plater
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
I just updated python-cups to a new version, and it is now shipping
files to automatically add Provides tag to packages that are shipping
cups drivers (thanks to the new rpm 4.9).
It's matching those files:
%__psdriver_path ^(/usr/lib/cups/driver/.*|%{_datadir}/cups/drv/.*\.drv)$
%__psdriver_magic ^PPD file.*$
It'd be cool to have all our packages that are shipping drivers for cups
use this. It's just a matter of adding a python-cups BuildRequires.
For instance, for gutenprint, this would add Provides like this:
postscriptdriver(hp;photosmart_100;)
This will enable configuration tools to know which package to install,
if one is needed, when configuring a printer.
I've submitted the change to gutenprint, so you can take a look at it to
if you need to change another package in a similar way (but it's really
easy): https://build.opensuse.org/request/show/71723
There are likely other packages than gutenprint that should be changed,
and I don't know which ones, so I'd appreciate if others could do this
or at least tell me which packages to change.
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
Hi all,
first of all big thanks to mls for rpm 4.9.
I've a question about the dependency generators introduced in rpm 4.9 -
I want to reuse the Fedora maven.attr and maven.prov they added into
jpackage-utils. It will add the maven styled provides into maven
packages, so on the end all maven packages can have cross-distro
compatible names.
There's a problem I see with their approach. The maven.prov is written
in Python, that means you have to handle this as dependency somehow. I
thought about few ways, but noone seems to me like a good way
1.) add a Requires: python into jpackage-utils, so you have to have
python with every java package, because j-u is needed for every JVM
we have
2.) move those files into maven package and let it Require python -
this is not much far from the 1.)
3.) add BuildRequires: python into every package have BuildRequires:
maven - this seems as the best one, even it is confusing for
packagers
What's your opinion?
Regards
Michal Vyskocil
Hi guys,
recently we already had some discussion about how to fix our Python (and Ruby)
packages. One rule was to (re)name all packages so that they match their
upstream counterparts as closely as possible. For Python this would be
python-$UPSTREAM_PYPI_NAME and for Ruby it is currently
rubygem-$UPSTREAM_GEM_NAME.
Sometimes this leads to ugly ducklings like 'python-python-daemon', but that
already is the perfect example why we have to name it like that [1]. Darix
discovered a similar offender for Ruby [2][3]. Therefore we suggest to enforce
this rule for new Factory packages. Furthermore we would have to gradually fix
offending packages in devel:languages:ruby:extensions and
devel:languages:python (aledr is already quite active fixing the latter).
Sometimes we have to break this for characters that can't be part of RPM names
(like the dot for older distros). In this case, we may want to replace them
with "_".
Along these lines, it would be great to also provide the upstream name like
Perl packages do nowadays:
Provides: python($UPSTREAM_GEM_NAME)
Ideally, this should be part of our Python macros.
Footnotes:
[1] http://lists.opensuse.org/opensuse-packaging/2009-09/msg00148.html
[2] http://rubygems.org/gems/libarchive
[3] http://rubygems.org/gems/libarchive-ruby
--
Mit freundlichen Grüßen,
Sascha Peilicke
http://saschpe.wordpress.com
Hi,
Trying to get OpenNebula into a more usable state. The startup script of
the daemon puts pid files into /var/run/one/one.pid and log files into
/var/log/one/one.log. This is of course perfetly reasonable, with the
exception that the startup fails if /var/run/one and var/log/one do not
exists.
Question now is should the startup script create the directories if they
do not exists or is this a job of the package in %post?
Thanks,
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rschweikert(a)novell.com
rschweikert(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
Hallo,
i've downloaded and install openSuse 11.4.
Cause of i want to help develop openSuse, i need a lot of hints.
The documentation of development don't help me, cause i'm at the moment
a non experience user.
I've read, that there was a package for suse development, but the
current version i've didn't find.
i would like to improve applications or wan't write new stuff.
can you give me a easy reading tutorial or a step to step howto.
Must i download the development version of suse ... ????
Please help me.
Thanks and best regards.
Frank
>Hallo Freunde,
>
> ich hab mir jetzt openSuse 11.4 heruntergeladen und installiert.
>
> Da ich mich an der Entwicklung von openSuse gerne einbringen würde,
> bräuchte ich dringend ein paar Tipps.
>
> Die Dokumentation für Entwickler hilft mir leider nicht weiter.
>
> Es gab da wohl mal ein Paket für die openSuse Entwicklung, was es
wohl
> nicht mehr aktuell ist.
>
> Ich würde gerne Anwendungen erweitern/verbessern und habe auch Ideen
> für neue Programme.
>
> Bitte helft mir, sonst geb ichs auf.
>
>
> Viele Grüße
>
> Frank
>
>
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi all,
Gabriel recently asked me if I could maintain the Banshee Project
repositories, which I accepted. Now this brings me a few issues...
Banshee repository inherits some packages from Mono which seem to be
based on what I would call 'fedora' specs and could use some love.
Well, I'm available to improve a bit this packages (the ones used for
Banshee) and resubmit them to Mono project, and then branch them over
to Banshee. The reason why they are all there is because currently
(and in the future) Banshee will be served to all supported platforms
through those reps, so those mono packages provide the requirements
for it.
Now, there's two things I've noticed:
1. Mono packages are 'noarch' and install always on /usr/lib (which
suggests %libexecdir can be used);
2. Mono packages are placing the .pc file on /usr/share/pkgconfig;
3. Mono packages have sometimes a devel package which only provides
the .pc file and no real development files.
My questions are quite simple:
1. Can we use a '%define _libdir %{libexecdir}? This would make the
packages always install on /usr/lib (or as an alternative, '%define
_libdir %{prefix}/lib');
2. Why would we want to drop the .pc file on /usr/share? If we would
use the macro above, shouldn't it also be sane to dump the .pc file on
/usr/lib/pkgconfig ?
3. In the cases where we have a devel package only for the .pc file,
could we merge it and have a 'Provides: %{name}-devel' ?
I really would love to make the best possible for Banshee
repositories, and sorting out this mono things would be something
really cool. Any help/comments will be appreciated.
NM
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello Mates,
actually i'm wondering whay such packages in devel:languages:perl are
not building.
The Logs are in http://bit.ly/kEGuXF and http://bit.ly/jbpf4b.
It builds for all released Versions but not for Factory.
Maybe anyone knows more?
cu Sascha
--
Sincerely Yours
Sascha Manns
open-slx Community & Support Agent
openSUSE Membership Comitee
openSUSE Marketing Team
Web: http://saigkill.homelinux.net
German Community Portal: http://community.open-slx.de
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org