Packaging-related changes in GNOME
by Matthias Clasen
This cycle, some things land in GNOME land that will require minor
adjustments of scriptlets:
1) GIO modules. GIO now uses a caching approach to its modules. If a
package installs a loadable module in %{_libdir}/gio/modules, you need
to run gio-querymodules to update
%{_libdir}/gio/modules/giomodule.cache. There's the usual multilib pain;
glib2 installs the binary as gio-querymodules-32/64. I propose to
recommend the following scriptlets for this:
%posttrans
gio-querymodules-%{__isa_bits} || :
%postun
gio-querymodules-%{__isa_bits} || :
2) GSettings. GConf is on the way out, we will start seeing applications
that are ported to GSettings (which is part of libgio in the glib2
package). GSettings uses schemas as well, and has a cache of those that
needs updating if schemas are added/removed. The tool for this is
glib-compile-schemas (schemas and their cache are arch-neutral, so no
multilib pain here). Proposed scriptlets:
%posttrans
glib-compile-schemas %{_datadir}/glib-2.0/schemas || :
%postun
glib-compile-schemas %{_datadir}/glib-2.0/schemas || :
3) GTK3. gtk3 will be parallel installable with gtk2, which means it
keeps its loadable modules separate. I took the occasion to rework
things a bit to reduce the multilib pain. gdk-pixbuf loaders, theme
engines and im modules get installed to
%{_libdir}/gtk-3.0/3.0.0/{loaders,engines,immodules}, and the cache
files for loaders and immodules have been relocated to
%{_libdir}/gtk-3.0/3.0.0/{loaders,immodules}.cache. Suitable scriptlets
to update these caches look as follows:
%posttrans
gdk-pixbuf-query-loaders-3.0-%{__isa_bits} --update-cache || :
gtk-query-immodules-3.0-%{__isa_bits} --update-cache || :
%postun
gdk-pixbuf-query-loaders-3.0-%{__isa_bits} --update-cache || :
gtk-query-immodules-3.0-%{__isa_bits} --update-cache || :
I guess all the %postun scriptlets could be optimized with a if $1 -eq 0
Comments ?
Matthias
13 years, 6 months
Inaccurate information about LiVES package
by salsaman
Hi all,
I am the main developer/maintainer of LiVES (http://lives.sourceforge.net).
I recently noticed the information about LiVES on this page:
http://fedoraproject.org/wiki/PackageMaintainers/WishList#L-M
The information give about LiVES is inaccurate/incorrect. First of all,
LiVES is not dependant on ffmpeg. As in, you can perfectly well build and
run the application without ffmpeg being present on either the build system
or the end user system.
However, the ffmpeg libraries are recommended for end users, since LiVES
will make indirect use of them (via mplayer) for decoding some video
formats, and via mencoder for encoding some video formats.
I fail to see the reason for this to be sufficient cause for crossing out
LiVES. A long time ago, ffmpeg contained some allegedly patented code (AAC
audio IIRC), however this code was removed from the core of ffmpeg at least
5 years ago. However it seems that the FUD (and that is indeed what it is)
persists. Microsoft must be laughing hard at this one.
If you don't believe me, then how is it that both ffmpeg and LiVES are in
debian testing and unstable ? Please check for yourselves, and contact the
debian legal team if you are still in doubt.
It is particularly timely that I noticed this, as I would like to introduce
the new packager for LiVES in Fedora, Harry Rickards (harry(a)linux.com).
Harry is also the point of contact between LiVES and the debian multimedia
team who are responsible for packaging LiVES for debian.
I hope that you will correct the information on the wishlist page, stop
spreading (unintentional ?) FUD about ffmpeg, and most importantly give
Harry every assistance with the Fedora LiVES packages.
Regards,
Salsaman,
main developer, LiVES.
http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman
14 years
Config Files in Home Dir
by Jameson
I maintain a package that when run for the first time creates a file,
~/.projectM/config.inp. The package previously needed symlinks to
fonts because the location of the fonts was hard-coded. I have since
removed the symlinks, and patched the package so that config.inp will
be created pointing to the real font files. However, when one
upgrades from the previous version to a new one, the config.inp file
still points to they symlinks. What is the appropriate way to deal
with this?
Thanks,
=-Jameson
14 years
shared-mime-info inconsistencies
by Michel Alexandre Salim
According to http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#mimeinfo
packages should not depend on shared-mime-info, but instead only
update its database if it happens to be installed. I would expect
shared-mime-info to be pulled in by either specifying it in comps.xml
or as a dependency to gvfs (on GNOME) or its KDE equivalent, but
instead it is required by gnome-vfs2 (which should not pull it in
anymore, now that we have gvfs) as well as PackageKit, several
NetworkManager subpackages, and several other applications.
Should we consider these packaging bugs? I'd file the bugs and fix
them, but first we probably need to decide on what is the right way to
pull in shared-mime-info on a normal installation, and ensuring that a
fix does not break upgrades.
Thanks,
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: 78884778
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
14 years
error running fedora-packager-setup
by Léon Keijser
Hi,
After reinstalling F12 (fresh install, no upgrade) i tried to run
'fedora-packager-setup' and got this error:
$ fedora-packager-setup
Setting up Fedora packager environment
Traceback (most recent call last):
File "/usr/bin/fedora-packager-setup", line 140, in <module>
main()
File "/usr/bin/fedora-packager-setup", line 114, in main
if certificate_expired():
NameError: global name 'certificate_expired' is not defined
I'm not sure why it's throwing this error.
Léon
14 years
How to build SRPMs for Rawhide from Fedora 12
by Edmon Begoli
Hi,
I am working on a Fedora 12 machine, but I would like to build Java
packages for rawhide
without necessarily enabling rawhide repository for all the system (it
messes with the stable updates).
How can I create an RPM build environment for rpmbuild that accesses
all the dependencies available
in rawhide without affecting the host?
Thank you in advance.
EB
14 years
Update on packages violating the Static Library guidelines
by Michael Schwendt
* Only three packages fixed since April 1st.
* 20 packages left to be fixed.
* No new violations since February.
* Bugzilla status for packages violating the Static Library guidelines:
http://mschwendt.fedorapeople.org/staticbugstat.html
acl 556036 -> CLOSED
atlas 556037 -> CLOSED
attr 556038 -> CLOSED
audit 556039 -> CLOSED
binutils 556040 -> CLOSED
brltty 556041
Canna 556034 -> CLOSED
cdparanoia 547682 -> CLOSED
comedilib 556043
dnssec-tools 556044
e2fsprogs 545144 -> CLOSED
expat 556046 -> CLOSED
fftw2 556047
file 556048 -> CLOSED
gcc 556049
gdbm 556050 -> CLOSED
ghostscript 556051 -> CLOSED
gnutls 556052 -> CLOSED
gpsim 556053 -> CLOSED
gtk+extra 556054 -> CLOSED
hpic 556055 -> CLOSED
isdn4k-utils 556056 -> CLOSED
js 556057 -> CLOSED
ldns 556058 -> CLOSED
libaio 556059 -> CLOSED
libannodex 556060 -> CLOSED
libbtctl 556061 -> CLOSED
libcaca 556062 -> CLOSED
libcddb 556063 -> CLOSED
libcdio 556064 -> CLOSED
libcmml 556065
libdnet 556066 -> CLOSED
libevent 556067
libftdi 556068 -> CLOSED
libnl 556069
liboggz 556070 -> CLOSED
libotr 556071
librx 556072 -> CLOSED
libsemanage 556073 -> CLOSED
libsndfile 556074 -> CLOSED
libstatgrab 556075 -> CLOSED
libtranslate 556076 -> CLOSED
libtwin 556077
libuninameslist 556078 -> CLOSED
libxslt 556079
link-grammar 556080
linux-atm 556081
linuxwacom 556082 -> CLOSED
lockdev 556083 -> CLOSED
meanwhile 556084 -> CLOSED
mpich2 545149 -> CLOSED
munipack 556086
nfs-utils-lib 556087
numactl 556088 -> CLOSED
opencdk 556089 -> CLOSED
openldap 556090 -> CLOSED
proj 556091 -> CLOSED
python 556092 -> CLOSED
QuantLib 556035 -> CLOSED
rubberband 556093
shapelib 556094 -> CLOSED
syck 556095 -> CLOSED
sysfsutils 556096 -> CLOSED
texlive 556097 -> CLOSED
torque 556098
util-vserver 556099
xbsql 556100 -> CLOSED
xen 556101
xfsprogs 556102 -> CLOSED
xmlsec1 556103
xqilla 562566 -> CLOSED
14 years
Adding a section on GSettingsSchema
by Richard Hughes
As more applications convert from GConf to GSettings, Fedora packages
are going to need to deal with schema files.
At the moment in gnome-color-manager I use this:
%post
glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :
%postun
glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :
Although doing it for every single package seems like a waste of time.
Maybe posttrans would be better in this case? Anyway, I think we need
to sort out a policy and stick it on
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets before
people start packaging applications that use GSettings schema files.
Let the discussion commence.
Thanks,
Richard.
14 years
