April 2007 - packaging - Fedora mailing-lists

Tcl packaging guidelines proposal
by Michael Thomas 02 Jan '08

02 Jan '08

I sent this proposal to f-m-l about a week ago to gather comments, and there were no serious disagreements with the proposal which have not yet been addressed (thanks to Tibbs and Toshio for their feedback). Basically, I want to establish a set of guidelines for packaging Tcl extensions, as we already have guidelines for other popular scripting languages. In addition to making Tcl packages more consistent with each other, it will also help work toward fixing my pet-peeve bug (bz #226893) http://fedoraproject.org/wiki/PackagingDrafts/Tcl Please let me know if I need to do anything to help get these draft guidelines adopted. Thanks, --Wart

4 10

font package naming
by Jens-Ulrik Petersen 21 Sep '07

21 Sep '07

Hi, I would like to propose adding the following text to our "Package Naming Guidelines". http://fedoraproject.org/wiki/Packaging/NamingGuidelines ''' == Fonts Packages == Font packages should be named with the upstream name appended with `-fonts`. Examples: {{{ bitmap-fonts dejavu-lgc-fonts ghostscript-fonts urw-fonts xorg-x11-fonts }}} ''' Should the text discuss what to do when the upstream name contains the word "font" already? See https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00794.h… and https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00262.html for some recent discussion of <upstreamname>-fonts vs fonts-<language> and "-fonts" vs "-font" for singlet font packages. Comments or objections? Jens ps We might even consider renaming some of our "fonts-*" packages to follow this naming scheme for F8.

4 10

Hardlinking *.pyc and *.pyo
by Ville Skyttä 19 Jun '07

19 Jun '07

Hello, Related to recent space saving discussions, I came across PLD's rpm-build-macros package recently, and found that they hardlink identical *.pyc and *.pyo. In a lot of cases, they're the same, and there's some potential for saving some MB "for free", on my FC6 x86_64 box: $ /usr/sbin/hardlink -ncv /usr/lib*/python2.4 2>&1 | tail -n 1 Would save 11116544 The PLD implementation looks like this: # Hardlink binary identical .pyc and .pyo files # (idea by glen <at> pld-linux <dot> org) %__spec_install_post_py_hardlink {\ %{!?no_install_post_py_hardlink: __spec_install_post_py_hardlink() { \ [ ! -d "$RPM_BUILD_ROOT" ] || find "$RPM_BUILD_ROOT" -name '*.pyc' | while read a; do \ b="$(echo $a|sed -e 's/.pyc$/.pyo/')"; \ if cmp -s "$a" "$b"; then \ ln -f "$a" "$b"; \ fi; \ done \ }; __spec_install_post_py_hardlink } } The use of "cmp" would require diffutils installed. Or the above could be converted to use hardlink instead (which would have to be made sure to be around) or maybe sha1sum (in coreutils, pretty much always around in buildroots). I suppose something like the above could be easily added to redhat-rpm-config or rpm, eg. embedded in brp-python-bytecompile or run after it in %__os_install_post. Worth it? Other comments?

5 7

First user/group handling discussion draft
by Ville Skyttä 15 May '07

15 May '07

Hello, The first draft about user and group handling (creation etc) is ready for discussion: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups The draft was presented in yesterday's FPC meeting, but the quick conclusion was that it'd be better to discuss it on list first. The draft currently contains only an implementation of the all-dynamic uid/gid mapping scheme - more may follow later if the consensus is that other schemes are actually required in packages (ie. not adequately addressable outside of them).

7 38

http://fedoraproject.org/wiki/Packaging/NewMeetingTime
by Tom Callaway 01 May '07

01 May '07

FPC members: Please go to http://fedoraproject.org/wiki/Packaging/NewMeetingTime and put in times which will work for you to attend. I've also put in the other times which are already taken in #fedora-meeting, so that we don't accidentally choose a time which is already in use. Thanks in advance, ~spot

2 3

missing tomorrow's FPC meeting
by Ralf Corsepius 01 May '07

01 May '07

Hi, Due to a public holiday in Germany, I'll be AFK most of the day and therefore probably will not be able to attend the FPC meeting. No matter if it will take place at 17:00 or 16:00 UTC ;) Ralf

3 2

Using %global instead of %define in conditionalized macro expressions
by Axel Thimm 24 Apr '07

24 Apr '07

Or to place it more explicit make %{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} [%{!?foo: %define foo ...}] to %{!?python_sitelib:%global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} %{!?python_sitearch:%global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} [%{!?foo:%global foo ...}] Otherwise using parametrized macros can mess things up (#237448). The nesting levels seems to get mixed up and the conditionalized definition above get swallowed away. The %global ensures that this bug doesn't happen. It may also be cleaner to remove the space between the colon and the percent sign. -- Axel.Thimm at ATrpms.net

3 4

satic libs package naming
by Patrice Dumas 20 Apr '07

20 Apr '07

Hello, In the guidelines it is said that static libs subpackages should be called *-static. This triggers lots of rpmlint warnings so I currently use (and propose in reviews) *-static-devel. Should I revert to *-static? If *-static-devel is acceptable, maybe it could be said so in the guidelines. Also, unless I am wrong on that point, maybe in the guidelines there could be a note that when there is only static libraries there is no need of static subpackage and the static libs may be in -devel. -- Pat

4 10

Using of date in snapshot versions
by Till Maas 19 Apr '07

19 Apr '07

Hiyas, the naming guidelines say that one should use the date do describe the snapshot: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-cfd71146dbb6f… | If a snapshot package is considered a "pre-release package", you should | follow the guidelines listed in Pre-Release Packages, and use an %{alphatag} | in the following format: | YYYYMMDDcvs Maybe this is useful for cvs, because there is no better way to describe a snapshot. But e.g. with svn, which uses a global revision number, it is possible to use a unique id for the snapshot, where it is not uncertain which changes are included. For this reason I suggest to change the guideline, so that it suggests better identification strings for a snapshot, when it is avaiable, e.g. 123svn for a snapshot of an svn repository at revision 123. Regards, Till

10 26

Issues with Ocaml and Static Linking
by Nigel Jones 19 Apr '07

19 Apr '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, While putting in a couple of packages for Extras Review I've stumbled into a couple of issues regarding how Ocaml links libraries and how the Fedora Packaging Guidelines are set. My packages in question are: ocamlSDL (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804) camlimages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805) freetennis (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815) Basically, ocamlSDL and camlimages produce two sets of libraries (a set of dynamic libraries, and another set for development etc), sadly when other packages like freetennis build, they staticly link to libraries such as camlimages/ocamlSDL. I found it semi-suspect when I built freetennis, and hence why I asked on bugzilla when I posted the three packages for review, however I did some more questioning today and after a quick IRC discussion in #ocaml was told: 12/04 13:39 < G> hmmm, .a .cma and .cmxa are all static ocaml libraries right? 12/04 13:44 < Smerdyakov> Those are the two library extensions, yes. 12/04 13:44 < Smerdyakov> Native code OCaml doesn't support dynamic loading. 12/04 13:44 < Smerdyakov> I expect that bytecode uses the same files for dynamic loading as static loading. Looking at my installed files on my laptop, lablgl, lablgtk and labltk (as well as the main ocaml package) store .a, .cma and .cmxa files in /usr/lib/ocaml (and subfolders). As I'm only new to Fedora packaging, could someone please advise on where I should from here on the matter and what the position of FESCO is on Ocaml static libraries, and where I should go from here. Thanks, Nigel Jones -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGHZpipldg9bRmG6kRAk8IAJ9JepuGRc7m3AH35XFhRUKG+w1xYgCgis+F BhyetHeiFfS5U9svDsy9Ufc= =RmdN -----END PGP SIGNATURE-----

2 3

Statistics on usage of disttags in Fedora Core and Extras
by Axel Thimm 16 Apr '07

16 Apr '07

Hi, I checked on the percentage of how many packages do use disttags these days. And since I was at it I did some historical reseach to see the tendency (I don't have access to Pre-Extras, so the Extras and Sum slots for FC1 and FC2 are empty). The results are quite interesting: release Fedora Core Fedora Extras Sum 1 2 / 936 <1% 2 0 / 947 0% 3 9 / 970 1% 711 / 1115 64% 720 / 2085 35% 4 12 / 965 1% 1530 / 1786 86% 1542 / 2751 56% 5 36 / 1157 3% 2686 / 2778 97% 2722 / 3935 69% 6 336 / 1154 29% 3008 / 3068 98% 3344 / 4222 79% rawhide 846 / 1218 69% 2833 / 2897 98% 3679 / 4115 89% Some notes: o Fedora Extras has always used more packages w/ disttags than w/o, the tendency up to its last incarnation in FC6 was steadily increasing until it reached 98% and remained at that level. o Fedora Core has adopted disttags very late in comparison to Fedora Extras, but also has the steepest growth - since FC6 every third package has already been disttag'ed, by F7 it's more than two thirds. This is mostly due to the fact that previously the Fedora Core buildsystem would not support setting the disttag macros, while the Fedora Extras buildsystem did so for the very beginning. o In their sum the disttagged packages have also reached the majority since FC4. Conclusions: o The disttag idiom was very successful, even though it is not mandatory it managed to be adopted in over 98% of Fedora Extras and 69% of Fedora Core. o From EPEL's POV, since it is a Fedora Extras rebuild for RHEL the package pool comes from the 98% of disttagged packages. Although RHEL is smaller than Fedora Core and one would assume some packages in EPEL coming from Fedora Core and thus getting at a lower than 98% share, current EPEL shows that almost all packages but some special ones like epel-release use the disttag. o For any other application that would require mandatory disttags like for example disttags of fc7.89, fc7.90 etc for rawhide and test releases this setup is not very far away. Looking at the sum of packages, this could happen by F8 by itself (the sum gains at least 10% each year and there are only 11% left). Suggestions: o watch the tendency and when it really reaches about 100% (e.g. F8) think about what gains mandatory disttags could bring us. If it is worth it fix the remaining few packages to use disttags (note: not all packages make sense to carry one, firmwares or XXX-release packages for example don't really need them) o continue suggesting the use of disttags to new packagers - even though optional it should be the recommended way to package things up. -- Axel.Thimm at ATrpms.net

12 49

UTF-8 Encoding update
by Toshio Kuratomi 14 Apr '07

14 Apr '07

Hey, After some correspondence with Nicolas Mailhot on -maintainers, we arrived at some updated wording for UTF-8 (Encoding and Filename). Do we need to approve the wording changes? If so it would be nice to vote on list as I don't think there's any changes to the spirit of the guideline, just clarifications in language:: == Encoding == Unless you need to use characters outside the [http://commons.wikimedia.org/wiki/Image:Ascii_full.png ASCII repertoire], you will not need to be concerned about the encoding of the spec file. If you do need non-ASCII characters, save your spec files as UTF-8. If you're in doubt as to what characters are ASCII, please refer to [http://commons.wikimedia.org/wiki/Image:Ascii_full.png this chart]. === Non-ASCII Filenames === Similarly, filenames that contain non-ASCII characters must be encoded as UTF-8. Since there's no way to note which encoding the filename is in, using the same encoding for all filenames is the best way to ensure users can read the filenames properly. If upstream ships filenames that are not encoded in UTF-8 you can use a utility like convmv (from the convmv package) to convert the filename in your %install section. -Toshio

5 4

-devel arch dependencies
by Orion Poplawski 12 Apr '07

12 Apr '07

Here's a question. Should -devel package requirements be of the form: Requires: package-devel.%{arch} I ask because of the following: # yum list libX11-devel Loading "installonlyn" plugin Setting up repositories Reading repository metadata in from local files Excluding Packages from Fedora Core 6 - x86_64 - Updates Finished Installed Packages libX11-devel.i386 1.0.3-6.fc6 installed Available Packages libX11-devel.x86_64 1.0.3-7.fc6 updates libX11-devel.i386 1.0.3-7.fc6 updates [root@apollo ~]# rpm -e libX11-devel error: Failed dependencies: libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.x86_64 libX11-devel is needed by (installed) libXt-devel-1.0.2-3.1.fc6.x86_64 libX11-devel is needed by (installed) libXmu-devel-1.0.2-5.x86_64 libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.x86_64 libX11-devel is needed by (installed) mesa-libGL-devel-6.5.1-9.fc6.x86_64 libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.i386 libX11-devel is needed by (installed) libXt-devel-1.0.2-3.1.fc6.i386 libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.i386 Should the libXpm-devel-3.5.5-3.x86_64 requirement for "libX11-devel" be satisfied by libX11-devel.i386? The needed libraries won't be there for linking. Can this be done in packaging, or does this need to be done in rpm? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

13 35

Fedora Packaging Committee Meeting Time Change
by Tom Callaway 12 Apr '07

12 Apr '07

Since some of the folks on the Committee have trouble attending our weekly meetings at 1700 UTC, I propose that we move it up an hour to 1600 UTC. FPC members, please vote. I'd like this to be unanimous. :) ~spot

9 18

Unadressed bugs as part of reviews
by Toshio Kuratomi 09 Apr '07

09 Apr '07

I saw this set of comments in a merge review and it struck me as a little off: > 5. There are outstanding bugs for [pkg] please address them. This is not relevant to the packaging review process. I see two problems with the above statements: 1) The reviewer is not specifying a specific problem that they consider a blocker for approval of the package. 2) The packager is not acknowledging that potential problems with the runtime of the package are relevant to the review. Perhaps we need to have some statement of reviewers' and packagers' responsibilities at the top of the Guidelines: "It is the reviewer's responsibility to point out specific problems with a package and a packager's responsibility to deal with those issues. The reviewer and packager work together to determine the severity of the issues (whether they block a package or can be worked on after the package is in the repository.) The Packaging Guidelines are a collection of common issues and the severity that should be placed on them. If a reviewer or packager believe their package reveals a flaw in the Guidelines, examples of how the rule is failing should be brought to the attention of the Packaging Committee so they can consider whether the rule has unanticipated consequences and modify it to better fit all situations." [1]_ Let me know what you think of having such a statement in general and this wording in particular. [1]_: http://fedoraproject.org/wiki/PackagingDrafts/OverallReviewGoals -Toshio

2 3

[Fwd: Re: [CMake] cmake does not set execute bit on shared libraries]
by Orion Poplawski 09 Apr '07

09 Apr '07

Some interesting information about the shared library execute bit issue. Why is it that we require the execute bit? I found an old post about it maybe being tied to the kernel protecting overwriting running programs, but no idea if that ever was put it place. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

6 8

exemptions for .la files in some -devel packages ?
by Jeremy Hinegardner 09 Apr '07

09 Apr '07

Hi all, I'm doing a couple of Merge Reviews for apr[1] and apr-util[2] and there seems to be an issue over the inclusion of the .la files in the apr-devel and apr-util-devel rpms. According to the Review Guidelines .la files are NOT allowed, but I have been informed via the bugzilla tickets that the .la files in these packages are required and cannot be removed. I do not have enough insight on libtool archives to render a decision here, so from my perspective, it appears that one of two things must happen: 1) There needs to be a clarification in the Review Guidelines regarding .la files that there are rare(?) instances where .la files are required and either list them or bring them up on a case-by-case basis to this list. 2) There is a misunderstanding from the packagers perspective on this issue. I'm initially assuming that the former is the correct approach here and just want to get confirmation from the list, as I'm probably newer than most at this process. enjoy, -jeremy [1] - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225253 [2] - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225254 -- ======================================================================== Jeremy Hinegardner jeremy(a)hinegardner.org

4 4

rpm output guidelines
by Christopher Stone 06 Apr '07

06 Apr '07

Why is my console littered with tons of output when I update selinux-policy-targeted rpm? I get tons of crap spewed out to my console. Aren't there any guidelines to prevent packages from doing this, and if not can we please make some? Wouldn't it be great if all this garbage output went to some place nice like syslog? selinux-policy-target puke: /sbin/restorecon reset /etc/cron.daily/000-delay.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/00webalizer context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/0anacron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/beagle-crawl-system context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/certwatch context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/cups context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/logrotate context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/makewhatis.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/mlocate.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/prelink context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/rpm context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/tmpwatch context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.hourly/mcelog.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.monthly/0anacron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.weekly/0anacron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.weekly/makewhatis.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 Do I really need to know all this? Because personally I have absolutely no idea what all this garbage means.

2 1

license for concurrent package
by Permaine Cheung 04 Apr '07

04 Apr '07

Hi, The concurrent package in core has stated the following (under the Notes section of its URL http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.…) 'All classes are released to the public domain and may be used for any purpose whatsoever without permission or acknowledgment. Portions of the CopyOnWriteArrayList and ConcurrentReaderHashMap classes are adapted from Sun JDK source code. These are copyright of Sun Microsystems, Inc, and are used with their kind permission,' (link is http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/sun-u.c.license.p…) And further down from that page it states: 'Do I need a license to use it? Can I get one? No!' Is this okay? Thanks, Permaine

3 3

Missing today's meeting
by Axel Thimm 03 Apr '07

03 Apr '07

Hi, I won't be able to make the meeting today. -- Axel.Thimm at ATrpms.net

3 3

Is this license okay for a fedora package?
by Jarod Wilson 03 Apr '07

03 Apr '07

I'd like to package up Maia Mailguard, and the license appears to be original BSD (advertising clause included) with a branding extension added. Thoughts? http://www.maiamailguard.org/license.php -- Jarod Wilson jwilson(a)redhat.com

5 13

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging April 2007