packaging April 2013

packaging@lists.fedoraproject.org

36 participants
20 discussions

perl packaging with oracle library
by Christopher Meng 19 Apr '13

19 Apr '13

Hi, it's really tough for me to continue as I'm packaging a perl module (DBD::Oracle), this is an important module for ora2pg, a very nice database schema converter. In order to install this DBD module I have to setup some PATH of Oracle's product like Oracle Instant Client. That meens we must install basic and devel rpm of OIC shipped by Oracle after clicking agree OTN and blahblahblah... After installing these things we should also setup environment variables like : export ORACLE_HOME="/usr/lib/oracle/11.2/client/lib/" export LD_LIBRARY_PATH=$ORACLE_HOME ORACLE_HEADERS="/usr/include/oracle/11.2/client/" It's really boring. Should I stop current work? Thanks.

2 2

Static UIDs and GIDs
by Toshio Kuratomi 17 Apr '13

17 Apr '13

The FPC has recently been looking at a draft revision of the UID and Group handling: https://fedorahosted.org/fpc/ticket/269 https://fedoraproject.org/wiki/User:Mitr/UsersAndGroups This is an "interesting" draft on several fronts. Historically: * UID/GID allocation was one of the first major controversial guideline that the FPC decided upon. * The Guidelines specify that only dynamic UID and GID allocation is supposed to be used and the Guidelines give instructions for how sysadmins can adapt that to being static on a site-by-site basis by pre-allocating the uids. Despite this, some packages have added their own static uids and gids. This has lead to bugs. What things have changed since then? * New FPC members who might be able to either come up with something different or would vote differently on this * The 1000SystemAccounts[1]_ Feature of F16 has expanded the range of static system accounts. However, the range is still miniscule -- we only have from 0 to 200 and according to /usr/share/doc/setup-2.8.67/uidgid approximately 160 of those have already been allocated * As part of the 1000SystemAccount feature (IIRC), the allocation of system dynamic accounts was changed so that system dynamic accounts were allocated from the top of their range going down rather than from the bottom. This means that on boxes freshly installed after F16 the static range * fedora-usermgmt was what prompted the original uid/gid guidelines. The upstream author of that package has left fedora and there seems to be activity to remove the need for it from all remaining packages in the distro. This removes one of the sources of controversy that affected the original guidelines. .. [1]: http://fedoraproject.org/wiki/Features/1000SystemAccounts What does the current draft propose? * The draft needs some restructuring but the basic idea is that it would add a way for packages to request a static uid/gid when they are created but for that uid/gid to be overridden by the local sysadmin. What will that gain us? * If a sysadmin wants to modify the system id ranges for their site or pre-allocates ids (for instance, to match what another distribution does), they can do that with the soft-static allocation in the proposal. Sysadmins cannot do that currently with packages which do not conform to the Guidelines and allocate purely static uids and gids. Their systems are highly likely to simply end up broken (Unable to install the packages) * Out-of-the box sharing of files via a networked filesystem in a homogeneous Fedora (and possibly RHEL) environment. Sysadmins will have to modify the uids in heterogeneous networks because other distros have different ranges for their system uids. Things that we're considering adding to the draft: * Having a group be the gatekeeper for allocating the static uid and gids instead of that being solely the setup maintainer's responsibility. In the past the setup maintainers have often added static uids and gids without regard for whether they were needed or not. This leads to a scarcity of uids and gids. Both FPC and FESCo have been proposed as this group. I lean towards FPC since it is something where a lot of time has to be spent figuring out whether there really is a need for a static uid and then potentially instructing the packager as to why a dynamic uid is just as fitting for their use case as a static one. Some others propose FESCo as this is in the borderline between Guidelines and enforcement of Guidelines (enforcement being FESCo's jurisdiction). * Presently discussing whether static allocations should be done via scriptlets in the setup package and the scriptlets for adding uids and gids in the packages themselves will all be dynamic. Since the decision of what uid and gid is allocated is centralized, making the implementation actually be centralized has merit. It would also keep packagers from cargo culting a static allocation from a different package by mistake. However, it feels a little bit wrong. If someone can come up with a technical reason not to do this, please speak up. Some things I see us doing if we approve this revision: * All packages using hard static uid allocation will be converted to soft static allocation. - Usually, when guidelines are updated there is no requirement that the packages in the distro immediately adapt to the new guidelines. For this guideline, hard static allocations are actually a latent bug that sysadmins may not have reported but definitely could have run into. * Packages doing hard static allocation that aren't listed in the setup uidgid file should have their static allocation evaluated and be converted to dynamic if appropriate. * Some ways in which the useradd and groupadd scripts add dynamic system uids and gids should be treated as bugs and fixed. (In particular that they don't always allocate the highest available uid/gid in the SYS_UID range) https://bugzilla.redhat.com/show_bug.cgi?id=924501#c9 We (the FPC) would love to have feedback on the draft and comments to help iron out issues that it may cause. Ville: I am especially interested in what you have to say as the author of our current uid/gid guidelines. Thanks, -Toshio

9 20

doxygen and copied font files
by Richard W.M. Jones 14 Apr '13

14 Apr '13

https://bugzilla.redhat.com/show_bug.cgi?id=905255 (long bug -- comment 43 onwards is probably the place to start) This package (open-vm-tools) uses doxygen to generate API documentation. doxygen copies a font file from '/usr/share/fonts/gnu-free/FreeSans.ttf' into the API docs directory, and as a result [assuming you don't do anything else] the font file gets copied into the final RPM as part of the %doc. I don't quite understand how precisely this font file is used. The CSS (doxygen.css) contains a reference to "FreeSans" as a font choice, but I didn't know that browsers would use this reference to start downloading *.ttf files from the same directory. Removing the font file shows no obvious change to the doxygen docs when viewed in my Firefox browser. So question: Should the font file be removed? Left alone? Linked? Something else? Also there's a suggestion that this is a bug in doxygen: http://lists.fedoraproject.org/pipermail/devel/2009-January/019434.html although it was closed as NOTABUG (I don't think the doxygen packager understood Nicolas Mailhot's bug report). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/

2 1

Could and how we use jpackage repository to packaging?
by Chen, Wei D 12 Apr '13

12 Apr '13

Hi, Our project is working on package our source code to follow redhat package standard, we want the rpm package we built could be accepted by fedora repository. One critical issue we found is some dependent binary (such as jaxws-tools.jar, jaxws-rt.jar and streambuffer.jar) cannot find relevant rpm package from fedora18 repository. Our source code cannot be built successfully without these binary, something weird is, we can find these jar binary from JPackage repository, and located in "glassfish-jaxws-repolib-2.1.3-8.jpp6.noarch.rpm" or " glassfish-jaxws-2.1.3-8.jpp6.noarch.rpm". So, my question is can we use JPackage repository in our rpm building process? How to use? Does this violate package standard? Why glassfish-jaxws related rpm package has been removed from fedora official repository? Is there any substitute solution? Great thanks for any of your suggestion. Best Regards, Dave Chen

2 1

Web server conf selection
by Christopher Meng 11 Apr '13

11 Apr '13

Hi, I'm packaging a software which can be used under apache/nginx/lighttpd. Should I choose httpd as default and put conf into /etc/httpd/conf.d or just put everything in doc and let users choose? Thanks. *Yours sincerely,* *Christopher Meng* Always playing in Fedora Project http://cicku.me

8 16

Problem when packaging Google's product
by Christopher Meng 10 Apr '13

10 Apr '13

Hi all, I'm planning packaging mod_spdy for Fedora but how can I fill the URL field? Thanks. *Yours sincerely,* *Christopher Meng* Always playing in Fedora Project http://cicku.me

3 4

libtool rpath issues
by Daniel Pocock 09 Apr '13

09 Apr '13

Hi, This has been discussed here before: http://lists.fedoraproject.org/pipermail/packaging/2010-June/007187.html but never really solved. Even if libtool is fixed, it's not clear to me that existing packages will benefit until maintainers release new tarballs. My reSIProcate upstream tarball is bootstrapped on Debian, so when I just do tar xzf resip.... ./configure && make on Fedora x86_64 it uses rpath /usr/lib64. Same outcome when using rpmbuild. The issue is discussed in more detail in the review request for my package: https://bugzilla.redhat.com/show_bug.cgi?id=892625 It would be really helpful for me and presumably other packages to answer two questions: a) out of the available hacks (such as those described in the earlier discussion on this list), which one is currently recommended to solve the issue in the existing package? b) should libtool or something else change to avoid this problem in future? This has also been raised in the libtool mailing list: http://lists.gnu.org/archive/html/libtool/2013-04/msg00000.html Regards, Daniel

2 2

Required use of /opt for AWS compatability
by Jeff Peeler 09 Apr '13

09 Apr '13

The spec file in question is located here: https://github.com/sdake/heat-rpms/blob/master/heat-cfntools.spec I assume that since it is against Fedora guidelines to install to /opt, that there aren't any exceptions. We do have in the repo a script to create the AWS compatible symlinks in /opt, rather than the actual files: https://github.com/openstack/heat-cfntools/blob/master/bin/cfn-create-aws-s… Would it be acceptable to call the above script in the %post section? I'm just not sure the proper way to proceed with the compatability and guidelines being in conflict. Jeff

3 2

JFYI: snappy conflicts
by Michael Schwendt 03 Apr '13

03 Apr '13

This one is amazing! Just forwarding it for anyone interested in these conflicts caused by too generic file names. ;-) [...] https://bugzilla.redhat.com/947640 Review Request: snappy - An open-source Gnome media player | Actually, 'snappy player' collides with 'snappy compression/decompression | library' already included in Fedora. | There is also another 'snappy' binary provided by spice-gtk-tools package: | | $ repoquery --whatprovides /usr/bin/snappy | spice-gtk-tools-0:0.15.3-1.fc18.x86_64

2 1

python3-pyside package issue
by Truong Anh Tuan 31 Mar '13

31 Mar '13

Hello folks, I got a problem when packaging a new package, ibus-bogo [1]. Upstream developers use Python 3 bindings for Qt4 while I just found python-pyside (for Python 2) in Fedora package database [2]. Seems I need to work on another new package python3-pyside too, right? Any ideas and suggestions? Btw, I submitted a new request on Bugzilla [3] to get that new package reviewed. It's highly appreciated if someone can take a look at. [1] https://github.com/BoGoEngine/ibus-bogo-python [2] https://admin.fedoraproject.org/pkgdb/acls/name/python-pyside [3] https://bugzilla.redhat.com/show_bug.cgi?id=917365 Thanks in advance, Tuan

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging April 2013