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,
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
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
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
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
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
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
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
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
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