packaging October 2010

packaging@lists.fedoraproject.org

22 participants
20 discussions

Macro %{optflags}
by Sergio Belkin 23 Jan '11

23 Jan '11

Hi, Does Makefile flags from the tarball overrides %{optflags} ? Thanks in advance! -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com Sergio Belkin -

5 10

Packaging-related changes in GNOME
by Matthias Clasen 19 Nov '10

19 Nov '10

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

4 6

Help with rpath issue
by Jirka Hladky 06 Nov '10

06 Nov '10

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

6 8

Noarch package depending on an arch-specific package, how to handle it?
by Ville-Pekka Vainio 02 Nov '10

02 Nov '10

Hi, I'm packaging pymtp, which the new gPodder versions need as a dependency. The review request is at <https://bugzilla.redhat.com/show_bug.cgi?id=643199>. It's a python binding to libmtp done with ctypes. The package in itself is noarch, but I noticed it won't work, if the 32-bit version of libmtp is installed on a 64-bit system. Should I make the pymtp package arch dependent and require the libmtp package, which matches the arch? Or should I require "libmtp" and trust yum to install the 64-bit package on x86_64? That wouldn't solve the case where the system already has the 32-bit libmtp installed, though. -- Ville-Pekka Vainio

3 3

#15 relaxing guidelines wrt. bundling
by Jeroen van Meeuwen 01 Nov '10

01 Nov '10

Toshio Kuratomi wrote: > If you're on packaging(a)lists.fp.o, we should probably take discussion > there. > > Here's the fpc ticket with the question of whether we should relax the > guidelines: > https://fedorahosted.org/fpc/ticket/15 > > Note that your description of the rubygem-passenger system could still fail > to pass the test under revised guidelines depending on what they turn out > to be. For instance, the guidelines might allow bundling of the latest > upstream version or of the version provided by Fedora, or they might > require that the package maintainer be able to code fixes should they be > necessary. It's probably a good idea to join packaging(a)lists.fp.o and > give reasons that requirements like that aren't needed. > As per the thread on advisory-board; http://lists.fedoraproject.org/pipermail/advisory-board/2010- October/009577.html I urge you to consider to allow exceptions like these for the greater benefit of your users -and thus upstream, through Fedora. Kind regards, Jeroen van Meeuwen -kanarip

6 11

Alternative plan for packages with bundled libraries
by Stephen Gallagher 29 Oct '10

29 Oct '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I submitted this to the Advisory Board, but I'm including it here since there's a lot of discussion ongoing about the nature of bundled libraries in Fedora. In the cases where removing libraries wouldn't be possible without extensive upstream work, we should rewrite the rules around the use of http://fedoraproject.org/wiki/Fedorapeople_Repos repositories to allow such packages in an unofficial capacity. Right now, they require an agreement that all packages being hosted meets with Fedora Packaging Guidelines in full, but I suspect that the Board could consider reducing this restriction to "In compliance with Fedora Legal guidelines" instead. So we could at least have a central semi-official repository where these packages could be made available to those who need them (separate from Fedora and unsigned so those using them *know* they're not official or fully-supported) while efforts are made to bring the project into full compliance, at which time it should become an official package. The benefits of this would be that contentious packages could still have a definitive delivery mechanism in keeping with Fedora's style. While the package itself wouldn't fit into the official yum repositories, it could still keep a set of maintainers (who would hopefully be actively working with upstream to resolve the bundling issues at the same time). The specific use-case I'm trying to address with this proposal was brought up by Jeroen van Meeuwen on the Advisory Board mailing list. A package like rubygen-passenger, which enjoys heavy use in the real world, but can't be carried in Fedora due to a forked, bundled version of the Boost utility library, could be carried in this unofficial repository. Right now (according to Jeroen), it's very common for deployments relying on this package to just roll their own from the source tarball. - From Jeroen's original email: "This means that meanwhile, thousands of us downstream consumers run rubygem-passenger customly built, packaged (maybe) and deployed to production, whatever was the latest version when someone had a chance to look for updates. Bad, bad, bad. Very bad." I think we definitely want Fedora users to be able to use a common package for their deployments, even if it's not signed and carried in the official repository. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzK6KgACgkQeiVVYja6o6OZ4gCePg6kXYMRTXQjF463WVhNSx31 t2YAnRUlF8c+oaUzFNXUKcjAG+H/JPPG =wOAD -----END PGP SIGNATURE-----

1 0

Filled Seat on the Fedora Packaging Committee
by Tom Callaway 27 Oct '10

27 Oct '10

The Fedora Packaging Committee has filled its open seat. James Antill has accepted the invitation to help Fedora improve and expand our Packaging Guidelines. This was a difficult decision, as we had many interested (and qualified) candidates, and I would encourage any of them to attend and participate in our public IRC meetings. The Fedora Packaging Committee meets on Freenode IRC, in #fedora-meeting, every Wednesday at 1600 UTC. Thanks, ~spot

1 0

Fedora Packaging Committee Meeting - Wednesday November 3, 2010 - 1600 UTC
by Tom Callaway 27 Oct '10

27 Oct '10

The Fedora Packaging Committee will meet next week (Wednesday, November 3, 2010) at 1600 UTC, in #fedora-meeting on freenode IRC. Tentative Agenda: New Library Bundling Exception (specifically, how to handle them): https://fedorahosted.org/fpc/ticket/15 Treatment of Bundled Libraries: https://fedorahosted.org/fpc/ticket/19 Amend RequiringBasePackage to clarify -libs scenario: https://fedorahosted.org/fpc/ticket/20 rpmlint clarifications: https://fedorahosted.org/fpc/ticket/21 Ban %pretrans?: https://fedorahosted.org/fpc/ticket/22 Thanks in advance, ~spot

1 0

who should own /usr/include/X11 ?
by Parag Nemade 27 Oct '10

27 Oct '10

Hi, My rawhide installation shows me $ yum provides /usr/include/X11 xorg-x11-proto-devel-7.4-39.fc15.noarch : X.Org X11 Protocol headers Repo : rawhide Matched from: Filename : /usr/include/X11 xorg-x11-xtrans-devel-1.2.2-5.fc15.noarch : X.Org X11 developmental X transport library Repo : rawhide Matched from: Filename : /usr/include/X11 I also see xorg-x11-xbitmaps install header files in /usr/include/X11 but does not own that directory. All 3 are individual(no dependency on each other) packages and should own /usr/include/X11. Is it ok then all 3 to own it? Parag.

2 1

pvfs2
by Viji V Nair 22 Oct '10

22 Oct '10

Hi, I would like to have pvfs2 filesystem bundled with fedora, can I join the "Package Maintainers" group and follow the procedure. OR is there any issues in including the file systems like this, reiser4 etc Thanks & Regards Viji

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging October 2010