packaging February 2009

packaging@lists.fedoraproject.org

45 participants
27 discussions

Suggested ScriptletSnippets (icon cache) changes
by Ville Skyttä 22 Feb '09

22 Feb '09

Hello, I'd suggest the following changes to the "GTK+ icon cache" entry in Packaging:ScriptletSnippets: 1) Rename the entry to "Icon cache". It's not all about GTK+ but KDE as well. 2) Append " &>/dev/null" to the "touch" line in %postun. If "touch" is not available when the package is removed, I find it more than likely that GTK+ or KDE are not there to benefit from icon cache updates any longer either. /usr/share may also be mounted read only with %_netsharedpath. 3) Append " &>/dev/null" to the "touch" line in %post. If "touch" is not yet available, neither should be kdelibs, and thus there is no reason to touch the dir. kdelibs itself does a forced update in its %post. /usr/share may also be mounted read only with %_netsharedpath. (This avoids the need to add unnecessary "Requires(post): coreutils" to every package that installs icons just to quiet down a pretty rare and harmless warning.) 4) Remove the -x test and --quiet option to gtk-update-icon-cache, redirect all output (including stderr) to /dev/null. gtk-update-icon-cache may not be installed, /usr/share may be mounted read only with %_netsharedpath, etc... and the --quiet tells me that there was no interest in seeing g-u-i-c's stdout anyway. 5) Wrap %post in "if [ $1 -eq 1 ] ; then ..." to take care of the initial installation and let %postun handle package upgrade cases in order to eliminate one touch and one g-u-i-c invocation per package upgrade. I suppose this would be "safe enough" to do, it'd just result in possibly stale icon caches for the duration of the upgrade transaction. (Icons change relatively rarely, and even if they do, does this smallish stale cache window really matter at all?) So the scriptlets would become: %post if [ $1 -eq 1 ] ; then touch --no-create %{_datadir}/icons/hicolor &>/dev/null gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : fi %postun touch --no-create %{_datadir}/icons/hicolor &>/dev/null gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :

8 21

Three drafts
by Toshio Kuratomi 22 Feb '09

22 Feb '09

I've updated the Explicit Requires draft with feedback from FESCo. It makes the guideline only apply to library Requires: http://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires === Source URL section that deals with upstream URLs that are not parsable by rpmbuild: http://fedoraproject.org/wiki/PackagingDrafts/Troublesome_source_URLs === Section to be added to package naming and linked to Conflicts Guidelines about when upstream has used generic names for a package. http://fedoraproject.org/wiki/PackagingDrafts/Common_package_names Patrice has linked me to a similar section in the Packaging Tricks section. if someone would like to merge the rationale from there, that would be helpful. Otherwise I'll try to get to it later this week. http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_co… -Toshio

1 0

rpmbuild and false dependancies when installing new rpm
by Gregory Machin 18 Feb '09

18 Feb '09

Hi all. I'm quite new to building rpms. I’m trying to build an rpm for lightsquid . I have got the rpm to build without any issues but now when I try and install it, it dies with missing dependencies the files are in the install list. [root@gregory-workstation ~]# rpm -i /home/builder/rpm/RPMS/noarch/lightsquid-1.7-1.noarch.rpm error: Failed dependencies: perl(common.pl) is needed by lightsquid-1.7-1.noarch perl(lightsquid.cfg) is needed by lightsquid-1.7-1.noarch [root@gregory-workstation ~]# I have also used mc to browse the contents on the rpm and the files are in it.. so why do I get this error ? I have also removed the "Requires" reference from the spec file and this did not help. I have attacked my lightsquid.spec file for review maybe a guru will see what my green eyes have missed. Thanks Regards Gregory Machin Email: gmachin(a)techconcepts.co.za Cell: +27 (0) 72 524 5098 gtalk: gmachin.techconcepts(a)gmail.com Support helpdesk(a)techconcepts.co.za Tell: +27 (0) 11 803 2169 Fax: +27 (0) 11 803 2189 After Hours Cell: +27 (0) 82 790 0796

2 1

review cgilib issues
by Lucian Langa 17 Feb '09

17 Feb '09

Hello, I'm currently reviewing cgilib package (#450050). The same functionality is provided by a similar package already in fedora libcgi. I would initially suggest using Conflicts for cgilib as those two package will most obviously conflict. Mamoru was kind enough to detail this issues a little further: * For these packages both packages the library named "libcgi.so.1", which is really a problem. - In this case a simple conflict method (like "Conflicts: libcgi" on cgilib") won't work as you desire, where there are some packages which Requires libcgi.so.1, because - An admin tries to install the package by "yum install foo" (where foo has the dependency for libcgi.so.1) - yum tries to resolve the dependency on foo, then finds that two packages have "Provides: libcgi.so.1". - Then yum will install either of libcgi or cgilib according to yum's implementation, i.e. we cannot expect which will actually be installed. However foo requires one of them, and perhaps foo won't work with the other one. - Here "Conflicts" does not work, because yum will try to install one of them, not both. * Another problem is that the soname major version "1" on libcgi.so."1" in libcgi (in Fedora) was, actually, arbitrarily chosen by Fedora maintainer, not by the upstream. And unfortunately this decision now conflicts with cgilib. - You can check this from libcgi srpm, especially libcgi-1.0-Makefile.in.patch in libcgi.srpm. The original upstream tarball only creates libcgi.so with no soname, however the Fedora maintainer seems to have created a patch to add the proper soname to libcgi.so. Then the soname "libcgi.so.1" seems to have chosen. Actually on Debian (as far as I checked debian's libcgi) the soname is libcgi.so."0" (and here .0 was arbitrarily chosen by Debian's maintainer). Any thoughts on this ? Thank you, --lucian

5 5

Guidelines#DuplicateFiles clarification
by Michael Schwendt 16 Feb '09

16 Feb '09

> http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles: > > A Fedora package must not contain any duplicate files in the %files > listing. What exactly does that refer to? Only the rpmbuild "warning: File listed twice ..."? Or actual files included in multiple %files sections for (sub-)packages? The latter is not detected by rpmbuild.

4 11

Build failed in rawhide
by Eric Tanguy 15 Feb '09

15 Feb '09

Someone could help me to understand why a package build fine for F-10 : http://koji.fedoraproject.org/koji/taskinfo?taskID=1128601 and the same package fail for rawhide : http://koji.fedoraproject.org/koji/taskinfo?taskID=1128665 Thanks Eric

2 1

Rawhide's Mono stack
by Michel Salim 10 Feb '09

10 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Fedora Mono developers, (ps if you are not in http://fedoraproject.org/wiki/SIGs/Mono, I get your name from the changelog of relevant *-sharp packages; please consider adding your name) The current Mono stack in post-alpha Rawhide is rather broken -- as of today, on my machine (x86_64) none of these packages work: - - monodevelop - - banshee - - tomboy - - f-spot It seems that the entire stack of libraries need to be recompiled -- gtk-sharp2, etc., and as such we should probably coordinate the rebuilding process. If B depends on A, does a rebuild of A affect B with Mono packages? Not so sure about this; if not, it makes life easier. If there are dependencies, then one way I could suggest is that we all commit updated specs, and then someone (Paul?) could do a chain build of all the packages. Another item: as I proposed in -devel recently, we could probably get more Infrastructure support. - - our own disttag, similar to the one for the gcc44 test rebuilds earlier - - that would probably require our own mailing list, to coordinate matters like this Thoughts? Suggestions? Thanks in advance, - -- miʃel salim • http://hircus.jaiku.com/ IUCS • msalim(a)cs.indiana.edu Fedora • salimma(a)fedoraproject.org MacPorts • hircus(a)macports.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmQLWYACgkQWt0J3fd+7ZCnZgCdFCbgxeipw/BiW6zzyt1k8Do4 mXAAnjXi9gPVJziqPakbU8uLcKUsMCCN =UBGD -----END PGP SIGNATURE-----

3 4

MimeType error in desktop file
by Eric Tanguy 09 Feb '09

09 Feb '09

Building a package for rawhide i obtain this error : /builddir/build/BUILDROOT/scidavis-0.1.4-1.fc11.i386/usr/share/applications/fedora-scidavis.desktop: error: value "application/x-sciprj;;" for key "MimeType" in group "Desktop Entry" contains value "" which does not look like a MIME type Someone could explain where the problem come from and how to solve it ? Thanks Eric

2 1

Vala packaging guidelines - are there any?
by Richard W.M. Jones 09 Feb '09

09 Feb '09

Do we have packaging guidelines applicable for the Vala programming language? I've reviewed a couple of packages now and they don't have a consistent naming convention. eg: vala - the base package emacs-vala - emacs mode gupnp-vala - vala bindings for gupnp (universal plug'n'play) library vtg - "Vala Toys for gEdit" currently under review here: https://bugzilla.redhat.com/show_bug.cgi?id=484360 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

2 1

awesome tiling window manager
by Haluk Dogan 09 Feb '09

09 Feb '09

Hi, I was trying to build awesome for few days, unfortunately I got several errors. When I looked its official web site, they made a package for many linux distribution except fedora. I wonder that would someone able to make an rpm package and put it to repository? Many thanks in advance. Regards Haluk --- HD

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2009