packaging January 2009

packaging@lists.fedoraproject.org

46 participants
33 discussions

Update request for /wiki/Packaging:UnownedDirectories
by Michael Schwendt 07 Mar '09

07 Mar '09

https://fedoraproject.org/wiki/Packaging:UnownedDirectories needs an update (it's read-only). The section about "Inaccessible Directories" applies only to RPM < 4.4.2.3 according to information on fedora-devel-list, and that means Fedora < 9 if the information is correct. At least since Fedora 10, RPM sets a sane default umask, so unowned directories are created with mode 0755.

2 4

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

Remove "Encoding=UTF-8" from sample desktop file
by Milos Jakubicek 02 Feb '09

02 Feb '09

Hi, yesterday when reviewing a package I noticed that although we have a MUST: follow the desktop-entry-spec in the Guidelines, the example on that page includes a line with: Encoding=UTF-8 which is deprecated according to: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-late… We should get rid of that line, as some people (including me) are taking that sample as a basis when creating new desktop files, shouldn't we? Regards, Milos Jakubicek

3 3

PackageMaintainers wiki cleanup update
by Susan Lauber 31 Jan '09

31 Jan '09

Greetings to the authors/maintainers of Package Maintainer wiki pages, I introduced myself last week [1] and since then I have dug into the pages and set up a task table [2] I have already added a category to most pages so they can all be found together [3]. If there are others or if you create a new page just add the string [[Category:Package Maintainers]] to the bottom of the page. The next step is renaming so that pages are easier to find in a search. It will also make the category page easier to use. I have started making suggested in the packagemaintainers.psv [4] file in the wikirename.git repo and ***I encourage others to check the proposed names and offer additional suggestions.*** I would like to have this file ready for the wikibot by the end of the week (Feb 7). Lack of response will be seen as a vote of confidence :) Thanks, Susan [1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01545.html [2] https://fedoraproject.org/wiki/Docs_tasks_for_Packaging_Guide_and_related_m… [3] https://fedoraproject.org/wiki/Category:Package_Maintainers [4] http://git.fedorahosted.org/git/?p=wikirename.git;a=blob_plain;f=packagemai… with naming instructions at https://fedoraproject.org/wiki/Help:Wiki_structure -- Susan Lauber, (RHCX, RHCA, RHCSS) Lauber System Solutions, Inc. http://www.laubersolutions.com gpg: 15AC F794 A3D9 64D1 D9CE 4C26 EFC3 11C2 BFA1 0974

1 0

update cpanspec section in perl packaging guidelines
by Parag Nemade 29 Jan '09

29 Jan '09

Hi, Can someone with ACL modify https://fedoraproject.org/wiki/Packaging:Perl#cpanspec and add link there to https://fedoraproject.org/wiki/Perl/cpanspec ? Regards, Parag.

1 0

guideline for OnlyShowIn?
by Rex Dieter 28 Jan '09

28 Jan '09

Per: "Base KDE applications (e.g. ksysguard) should have OnlyShowIn=KDE" https://bugzilla.redhat.com/show_bug.cgi?id=481739 Prompted me to try to come up with a good/simple guideline when it is and is not appropriate to use OnlyShowIn. Problem is, I couldn't, not easily or quickly anyway. I thought I'd start on the packaging list first, any thoughts? -- Rex

4 5

Intro and wiki info
by susan_lists＠ties.org 27 Jan '09

27 Jan '09

Greetings, I thought I should introduce myself to the packaging list and devel list. I'm here to help with documentation in general and packaging related wiki pages specifically. This includes the Packaging:, PackageMaintainers/*, and PackagingDrafts/* pages of the wiki. My immediate tasks include helping with page naming and categories to aid with searches. I am also available to assist with any proofreading. My $dayjob is mostly teaching and mostly for Red Hat (RHCE and RHCA classes). I've been *nix user and admin and instructor for years but I am fairly new as contributer. I have started out helping with the Fedora Docs Project and after meeting several people at FUDConF11, accepted the lead on the docs team side for the packaging docs. It is really a liaison position between the docs team and the packaging team and other contributors to packaging documentation. In addition to the renaming, categorizing, and proofreading, I am sure I will be helping with moving the Packaging Guidelines to the CMS when we decide on a system and I have DocBook experience to assist if any of the pages move to XML for other publishing. >From a docs side, the first thing that needs to occur is some renaming and categorization. Since it is a wiki and it is easy to undo changes, I am going to dig in add some categories and then start some page renaming. I won't be offended if anything gets undone but I hope that those who have worked so hard to get the pages where they are will also jump in with some suggestions. Here are some links that will help explain what needs to occur: https://fedoraproject.org/wiki/Help:Wiki_structure - This page explains page naming, namespaces, and categories. https://fedoraproject.org/wiki/User:Ianweller/Wiki_tip_of_the_week - The first week is about moving pages (preview available now) For example the current page [[PackageMaintainers/MaintainerResponsibility]] would not currently be found in a search for either "package" or "maintainers" because the mediawiki search uses whole word searches only. We also want to eliminate the hierarchy. A better name would be [[Package maintainer responsibilities]]. I was looking at the page https://fedoraproject.org/wiki/PackageMaintainersand see a lot of good naming suggestions in the link names and descriptions. With renaming, categories, and subcategories we can even generate a similar page automatically. Check out the fonts pages for an example: https://fedoraproject.org/wiki/Category:Fonts Something similar can be done for https://fedoraproject.org/wiki/Category:Package_Maintainers I am still looking for suggestions for subcategories for the Package Maintainers pages. If there are pages that are old or no longer in use they can be moved to the Archive namespace. Simply click the move button at the top of the page and add Archive: at the beginning of the name. For instance PackageMaintainers/FC3Status has recently been moved to Archive:PackageMaintainers/FC3Status Anything pointing to the original name is automatically redirected to the new name. This way the page still exists and can be found with an advanced search but will not appear in default search that a visitor to the site may use. Can PackageMaintainers/PackageStatus/CompsF9Missing also be archived? Finally, there is a fedora-wiki mailing list that has announcements and tips, but is also a good place to ask questions and discuss names and categories. https://admin.fedoraproject.org/mailman/listinfo/fedora-wiki And I am often on #fedora-docs as laubersm (or some variation) but anyone there should also be able to help. I look forward to helping and I appreciate any suggestions. Thanks, Susan -- Susan Lauber, (RHCX, RHCA, RHCSS) Lauber System Solutions, Inc. http://www.laubersolutions.com gpg: 15AC F794 A3D9 64D1 D9CE 4C26 EFC3 11C2 BFA1 0974

2 1

PHP Guidelines update proposal
by Remi Collet 26 Jan '09

26 Jan '09

What I was thinking (in an quite old discussion, during initial PHP Guidelines writing) is now reality According to PHP Guidelines, pear extension must be named php-pear-<extension>. That's ok for standard pear.php.net channel. With non standard channel we can encounter conflicts. llaumgui is working on submitting ezComponents for review. http://ezcomponents.org/ For example, one of the extension is Mail and php-pear-Mail already exists. My proposal is : http://fedoraproject.org/wiki/PackagingDrafts/PHP With this proposal, ezComponents will be named php-ezc-<extensionname> Comments ? Remi.

4 5

Use of dos2unix in %prep
by Richard W.M. Jones 23 Jan '09

23 Jan '09

While a package was being reviewed, the reviewer picked up on a use of the 'dos2unix --keepdate' command: https://bugzilla.redhat.com/show_bug.cgi?id=478640 The guidelines do indeed say not to use dos2unix, because quote "that can cause build fail on FC3" (like I care). http://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors But I've used dos2unix before, and it appears that using 'dos2unix --keepdate' is a superior solution because it keeps the original timestamp, and is generally simpler and more obvious to people reading the specfile. So is this guideline for real? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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://et.redhat.com/~rjones/virt-df/

12 22

Check for fonts during package review
by Nicolas Mailhot 22 Jan '09

22 Jan '09

Hi, As discussed during last FPC meeting, I've queued this (one-line) addition for FPC review http://fedoraproject.org/wiki/PackagingDrafts/ReviewGuideline_for_fonts_(20… -- Nicolas Mailhot

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging January 2009