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
Help with rpath issue
by Jirka Hladky
Hello everybody!
I have run into rpath issue when creating rpm for hwloc (you might want to
check package review ticket at
https://bugzilla.redhat.com/show_bug.cgi?id=606498)
rpath is added by libtool. Libraries are getting installed into /usr/lib64 but
libtool does not recognize this as default library location on 64-bit system.
One solution was to add "/usr/lib64" directory into /etc/ld.so.conf.
Practical solution to get rpm was to add
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
into the %configure stage in rpm specs.
I would like to get rid of these sed lines.
For me it seems either that libtool is buggy or "/usr/lib64" directory is
missing in /etc/ld.so.conf.
I (together with upstream) would highly appreciate any feedback on it.
Thanks
Jirka
13 years, 1 month
How to install vim syntax files?
by Martin Gieseking
Hi,
it seems, there's currently no common way how to add vim add-ons (e.g.
syntax files) provided by several packages. Some packages place them in
the versioned folder /usr/share/vim/vimXY, some in
/usr/share/vim/vimfiles. The latter seems to be the better alternative
to me.
However, what's about directory ownership? Should we always add a
dependency to vim-common (and use subpackages containing some small vim
files), or should the package own the affected folders (multiple
ownership like /etc/bash-completion.d)? I found several packages that either
a) add Requires: vim-common, or
b) add %dir %{datadir}/vim/vimfiles/syntax, or
c) just put the syntax files somewhere below %{datadir}/vim without
considering directory ownership, or
d) add the vim files with %doc for manual installation in ~/.vim/syntax
So what's the recommended way to add these kind of add-ons?
Martin
13 years, 3 months
Re: [Fedora-packaging] Discussion of RPM packaging standards and practices for Fedora
by Denis Arnaud
2010/8/28 <packaging-request(a)lists.fedoraproject.org>
> > Are there any specific Version Control systems which are designed to work
> > with the RPM format out of the box like svn, cvs, git, sccs?
> >
> > I would potentially like something that will automagically populate the
> > ?Version? and ?Changelog? fields in my spec files for some home grown
> > packages I maintain.
>
Some Boost developers have started and maintain ryppl (as reported in
http://lists.boost.org/boost-cmake/2010/08/0924.php), which may correspond
(partly) to what you are looking for:
http://ryppl.org/
http://ryppl.github.com/
http://github.com/boost-lib/
Then, of course, there are the tools used by Fedora. To name a few, Mock,
Koji <https://fedorahosted.org/koji/>, Bodhi<https://fedorahosted.org/bodhi/>,
Mash <http://people.redhat.com/notting/mash/>,
TurboGears<http://turbogears.org/>,
Git, Trac, FedPkg. And, for the virtual machines, Xen is apparently used.
Denis
13 years, 3 months
FW: EXTERNAL: RPM and Version Control Systems
by Boyce, Kevin P (AS)
Anyone have any suggestions . . .
Hi All,
Hopefully I'm at the right place to ask this question.
Does anyone know a good way to keep rpm packages under revision control?
How does the fedora team manage all those packages?
Are there any specific Version Control systems which are designed to
work with the RPM format out of the box like svn, cvs, git, sccs?
I would potentially like something that will automagically populate the
"Version" and "Changelog" fields in my spec files for some home grown
packages I maintain.
Regards,
Kevin
--
packaging mailing list
packaging(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
13 years, 3 months
Next FPC Meeting
by Tom Callaway
The next Fedora Packaging Committee meeting is scheduled for Wednesday,
August 25, 2010 at 1600 UTC.
Thanks,
~spot
13 years, 3 months
RPM and Version Control Systems
by Boyce, Kevin P (AS)
Hi All,
Hopefully I'm at the right place to ask this question.
Does anyone know a good way to keep rpm packages under revision control?
How does the fedora team manage all those packages?
Are there any specific Version Control systems which are designed to
work with the RPM format out of the box like svn, cvs, git, sccs?
I would potentially like something that will automagically populate the
"Version" and "Changelog" fields in my spec files for some home grown
packages I maintain.
Regards,
Kevin
13 years, 3 months
F-14 build tree
by Gregory Hosler
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
in my cvs development tree, I am not seeing a F-14 branch, yet.
At the risk of sounding like I missed an announcement :-(, should I be ?
I even did a "cvs co" on my project, hoping that would get ma a F-14 directory,
but it did not.
I'm ok if the F-14 is not yet, but I thought with F-14 approaching it might be
available already.
Comments, pointers to urls (that I might have missed) appreciated.
- -Greg
- --
+---------------------------------------------------------------------+
Please also check the log file at "/dev/null" for additional information.
(from /var/log/Xorg.setup.log)
| Greg Hosler ghosler(a)redhat.com |
+---------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxnzXcACgkQ404fl/0CV/SSEQCfTJp0VhW0TZhJNbwR9+lqsAp9
xdEAn1JSr5yWmJuCDPl3WQSwVAkKqMD0
=g8bj
-----END PGP SIGNATURE-----
13 years, 4 months