packaging November 2010

packaging@lists.fedoraproject.org

33 participants
22 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

AutoProvidesAndRequiresFiltering doesn't work
by Thomas Spura 30 Nov '10

30 Nov '10

Hi list, I'm using AutoProvidesAndRequiresFiltering [1] to filter out *.so libs in %{python_sitearch}. Unfortunately, rpm can't detect the correct requires anymore with that macro, so I didn't use this anymore, and let the 'wrong' provides and requires propagate for now untill a new solution is found. It would be best to adjust that macro somehow, so rpm can still detect the requires, but the wrong *.so files are not listed in Requires or Provides. Is and how is that possible? Greetings, Thomas [1] https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#A… [bug report for python-visual] https://bugzilla.redhat.com/show_bug.cgi?id=657851

3 5

Docs outside %docdir
by Andrea Musuruane 29 Nov '10

29 Nov '10

Hi all, I was performing a package review for RPM Fusion: http://bugzilla.rpmfusion.org/show_bug.cgi?id=1153 RPM Fusion follows the Fedora Packaging Guidelines so I think I can ask here a question it came to me during the review. This package has some exec files correctly installed by the packager in %libexecdir/packagename/bin instead of %libdir/packagename/bin because they are called by the main program who sits in %bindir. The files in %libexecdir use some files in %libexecdir/packagename/doc to show help, options, examples, etc when called with some parameters. Is it acceptable to leave these files here? Or they should be moved somewhere else? They cannot be installed in %docdir because they affect the runtime of the application: https://fedoraproject.org/wiki/Packaging/Guidelines#Documentation Thanks in advance for you help. Bye, Andrea.

3 4

Javascript packaging guidelines
by Gianluca Sforna 21 Nov '10

21 Nov '10

I found the draft page for packaging JS libraries here: http://fedoraproject.org/wiki/JavaScript_libraries_packaging_guideline_draft Even if it is not yet ratified, do I need to take them into account for a package in review that needs and/or ships a JS library? -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu

3 3

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

Requires for "lower" version of packages
by Mamoru Tasaka 18 Nov '10

18 Nov '10

Hello. Now I am trying to see one of the review requests based on rubygems: https://bugzilla.redhat.com/show_bug.cgi?id=652400 (This review request of just one example for rubygem related packages) Rebuilding the srpm in this review ticket produces boxgrinder-build-0.6.4.gemspec under /usr/lib/ruby/gems/1.8/specifications (this directory is normal for .gemspec file) which contains: --------------------------------------------------------- s.add_runtime_dependency(%q<commander>, ["~> 4.0.3"]) s.add_runtime_dependency(%q<boxgrinder-core>, ["~> 0.1.3"]) --------------------------------------------------------- Here "~> 4.0.3" means ">= 4.0.3 but < 4.1" ("~>" often appears in rubygems). So in rpm spec world, this is interpreted as: --------------------------------------------------------- Requires: rubygem(commander) >= 4.0.3 Requires: rubygem(commander) < 4.1 Requires: rubygem(boxgrinder-core) >= 0.1.3 Requires; rubygem(boxgrinder-core) < 0.2 --------------------------------------------------------- This is technically correct, however it seems that currently Fedora packaging guideline mentions about higher version dependency (e.g. https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires ) and I am not sure that it is allowed on Fedora to write dependency for lower version. Any comments are appreciated. By the way, currently the highest version of the upstream one is: commander: 4.0.3 boxgrinder-core: 0.1.3 Regards, Mamoru

1 0

Co-maintaining packages - gdal, grass
by Viji V Nair 18 Nov '10

18 Nov '10

Hi, I would like to co-maintain gdal and grass packages. I am working on Fedora GIS spin: We need to fix some issues in the above packages: gdal : we care not shipping the jnis, java is broken and need to fix grass : A very old GRASS version is packaged, it lacks more than 9000 fixes and enhancements with respect to the current stable version which is GRASS 6.4.0 Please share your thoughts Thanks Viji On Mon, Nov 15, 2010 at 11:08 PM, Viji V Nair <viji(a)fedoraproject.org> wrote: > Hi, > > I am working on geoserver package for fedora. For the same I would > require the following libraries, those are not included in the gdal > package, is there any specific reason to exclude the same? can you > please let me know ? > > libgdaljni.so libogrjni.so libgdalconstjni.so libosrjni.so > > Thanks > Viji >

2 1

Prefix for database add-on packages?
by Michel Alexandre Salim 15 Nov '10

15 Nov '10

I'm currently reviewing pgRouting: https://bugzilla.redhat.com/show_bug.cgi?id=652533 the packager is currently using "postgresql-pgrouting" as the name, which is alright but a bit long. There does not seem to be a policy for naming DB add-ons yet (though I see a couple of postgresql-* packages). Would the same policy applied as to, say, the Python add-ons? e.g. "if the name starts with [pP]y then you don't need the python- prefix". In this case, "pg" would clearly indicate that it's to be used with PostgreSQL. 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

6 6

Wish list sshdfilter maintainer
by David Highley 15 Nov '10

15 Nov '10

We are hoping someone who is a package maintainer would be interested in maintaining another package sshdfilter. Sshdfilter monitors and improves the security of open ssh ports. We believe the package is close to ready for disttribution: http://www.highley-recommended.com/sshdfilter/sshdfilter.spec http://www.highley-recommended.com/sshdfilter/sshdfilter-1.5.7-5.fc14.src.r… http://www.highley-recommended.com/sshdfilter/sshdfilter-1.5.7-5.fc14.noarc… Along with the packaging we created the selinux policy for this filter and an extension to the rsyslog policy. A bugzilla.redhat.com report, 595011, in attempt to start this process.

1 0

packaging@lists.fedoraproject.org Rolex For You 28% 0FF!
by Rolex.com 13 Nov '10

13 Nov '10

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging November 2010