packaging July 2010

packaging@lists.fedoraproject.org

25 participants
16 discussions

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

Cleanup of packaging guidelines wiki
by Susi Lehtola 31 Jul '10

31 Jul '10

Hi, I think the wiki pages for drafts that have been approved as packaging guidelines should be removed, or moved to another namespace. Having the approved stuff still around can be rather confusing. Furthermore, the link at https://fedoraproject.org/wiki/Packaging:Guidelines#Environment_Modules is broken - it should refer to Packaging:EnvironmentModules instead of Packaging:Environment Modules. -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

1 0

Guideline for D packaging
by Jonathan MERCIER 28 Jul '10

28 Jul '10

hello, i have do guideline (draft) for D packaging. here: https://fedoraproject.org/wiki/D%2Bpackaging%2Bguideline%2Bdraft What i need do now someone review it? best regards -- Jonathan MERCIER <bioinfornatics(a)gmail.com>

2 1

ownership of /usr/share/gtk-doc
by Rex Dieter 19 Jul '10

19 Jul '10

See tracking bug, https://bugzilla.redhat.com/show_bug.cgi?id=604169 Seems an enterprising soul mass-filed bugs arguing packages placing content under /usr/share/gtk-doc doesn't necessarily need to Requires: gtk-doc that leaves the question of what should own/provide /usr/share/gtk-doc To start the bikeshedding, let me offer my own personal-preference orderred list: 1. gnome-filesytstem (comment #20) 2. add to 'filesystem' itself 3. gtk-doc-filesystem ... 83. make each consumer of /usr/share/gtk-doc own it and please suggest other alternatives, if none of these are appealing to you. -- Rex

9 11

gnome/nautilus filetype detection and default opening application
by Development discussions related to Fedora 18 Jul '10

18 Jul '10

Hi, Basically, my package (pyvnc2swf) creates shockwave flash files with an extension of .swf. Nautilus detects the file as Shockwave flash file, and sets the default handler to gnash. 1. gnash crashes on at least some pyvnc2swf created swf files, yet it is the default for this file extension (at least on my system). 2. pyvnc2swf includes a limited .swf player that is able to only play files created by pyvnc2swf. Previously I added a .desktop file for vnc2swf-play, which causes nautilus to show pyvnc2swf-play as a possible player of swf files. However, it can't play all swf files. I was hoping to improve upon this by creating a subtype: glob "*.vnc2.swf", and change the package to output files with this "pre" extension, and then "tell" nautilus about that extension, so that: 1. pyvnc2swf files are automatically opened by vnc2swf-play 2. normal swf files are opened by any other swf player Is the way to do this as described at: http://people.gnome.org/~shaunm/admin-guide/mimetypes-9.html correct for f12/f13/devel ? Or do you have better ideas on how to achieve the above ?

1 0

[Koji] Koji timing out (error code 110)
by Denis Arnaud 15 Jul '10

15 Jul '10

Hello, for (at least) a few days, each time I use Koji, either from the command line, or directly on SSL Web site (https://koji.fedoraproject.org/koji/login), it times out and nothing happens. For instance: [build@vm13 devel]$ fedora-cvs R-msm [build@vm13 devel]$ cd R-msm/devel [build@vm13 devel]$ make tag [build@vm13 devel]$ make build /usr/bin/koji build dist-rawhide 'cvs:// cvs.fedoraproject.org/cvs/pkgs?rpms/R-msm/devel#R-msm-0_9_5-2_fc14' timeout: (110, 'Operation timed out.') make: *** [build] Error 1 My FAS certificates had expired, and I had to renew it (directly from https://admin.fedoraproject.org/accounts/home). I downloaded the new server-side certificate and stored it as ~/.fedora.cert Then, I downloaded a new client certificate for the browser: [build@vm13 devel]$ fedora-packager-setup and checked the new server-side certificate: [build@vm13 ~]$ fedora-cert -v .fedora.cert Verifying Certificate cert expires: 2011-01-10 CRL Checking not implemented yet I see the same symptoms as in https://bugzilla.redhat.com/show_bug.cgi?id=542767#c13 and as in http://www.spinics.net/lists/fedora-packaging/msg06987.html(though, it is not transient in my case: that issue is persistent for me) =============== Moreover: * I have a SSH-RSA key (in ~/.ssh/id_rsa, there does not seem to have an expiration date), for which I've added the public key to my FAS account ( http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html…). Could that SSH-RSA key interfere with the ~/.fedora.cert certificate? * I have a GPG key, still valid, for which I have added the public key to my FAS account ( http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html… ). ==== Any help would be welcome! Thanks in advance Best Regards Denis

1 1

Arch-specific Requires
by Braden McDaniel 10 Jul '10

10 Jul '10

I brought up the issue of arch-specific Requires some months ago in response to problems I experienced with xulrunner. This issue has reared its head again with gvfs on F13: https://bugzilla.redhat.com/show_bug.cgi?id=573183 I've put up this draft: https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires Comments welcome. -- Braden McDaniel <braden(a)endoframe.com>

10 31

Upstream version strings with a hyphen
by Siddhesh Poyarekar 10 Jul '10

10 Jul '10

Hi, I'm sorry if this has been asked earlier but I could not find anything relevant through searches on the wiki and on Google, which is why I'm asking my query here. Gource upstream has released a new version as gource-0.27-beta1-20100710. This is not accepted by rpmbuild for obvious reasons. Is there a standard way to accomodate such situations? I was otherwise thinking of defining a %{upstream_version} as 0.27-beta-20100710 and the version for the package as 0.27.beta.20100710. Thanks, Siddhesh

3 3

pyx files?
by Ray Van Dolson 09 Jul '10

09 Jul '10

I'm updating one of my packages (pymssql) which has moved to using Cython. As such, it includes .pyx files. By default, the setup tools place these .pyx files in %{_usr}. As we typically wouldn't include the generated .c files, I'm not sure we need to package .pyx files, though I do see a few packages out there which contain some. Anyone have any thoughts? Should my upstream configure their setup.py to put these .pyx files elsewhere? I'm not familiar enough with Cython to have a feel for how this typicaly works. Thanks, Ray

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging July 2010