packaging May 2008

packaging@lists.fedoraproject.org

31 participants
17 discussions

file-not-utf8 complaints
by Jason L Tibbitts III 02 Jun '08

02 Jun '08

Normally we fix up non-utf8 documentation and such with a quick call to iconv. It seems that this is problematic for some; see https://bugzilla.redhat.com/show_bug.cgi?id=226079 Any comments on how much we actually care about this, especially in the case that it might not actually be as easy as a call to iconv (such as a changelog file with a pile of random encodings in it). - J<

5 12

eclipse plugin without feature.xml
by Sergio Pascual 02 Jun '08

02 Jun '08

Hello, I'm trying to package a eclipse plugin called veditor. I have followed the guidelines in wiki/Packaging/EclipsePlugins The zip with the source code contains a file plugin.xmll but doesn't contain feature.xml. When building, %{eclipse_base}/buildscripts/pdebuild -f net.sourceforge.veditor fails, because feature.xml doesn't exist. How do I build with plugin.xml but without feature.xml? Regards, Sergio

2 1

How to make SRPMs and RPMs?
by Michelle Konzack 25 May '08

25 May '08

Hello *, I am "new" to Fedora since I was using long time ago DLD (Deutsche Linux Distribution from Delix which was bougth by RedHat in 1999) and I need a little bit help to start. If this list is not the right one, please let me know. I am Debian GNU/Linux Consultant in Strasbourg and now have to work with RedHat and Fedora since my customers proprietary software does not work on ANY Debian machines. I need to package some software for my customer and like to know HOW to package it. Curently I run only Debian Unstable/Stable and I am doubt if I can create packages under Debian without installing a Xen Machine for it since learning the whole RedHat/Fedora thing is currently a little bit to much. Now I have some questions: 1) Where can I find the "Packaging Tutorial"? 2) Where can I find the "Guidelines for Packaging"? 3) Where can I find infos about the FSH (File System Hierarchy) since it is a little bit different from Debian? 4) What does I need to build my own private fedors mirror (RPMs and SRPMs) with GPG signed packages? 5) If I create my own private fedora mirror on my server, is it possibel under Fedora to have the mirror password protected? x) What should I know more? y) Is there a tutorial, "HOW TO INSTALL" a Fedora-Xen-DomU on a Debian host system. My Development station is a AMD Phenom Quad 9800 with 8 GByte of memory and 74 GByte SCI/SCA drives (one per guest OS). Thanks, Greetings and nice Day Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant Fedora Newbie :-) -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ ##################### Debian GNU/Linux Consultant ##################### Michelle Konzack Apt. 917 ICQ #328449886 +49/177/9351947 50, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)

4 4

shipping distribution-specific patches *separately*
by Thorsten Leemhuis 21 May '08

21 May '08

Hi! Quoting a paragraph from: http://lwn.net/Articles/283030/ > Debian's packaging policy resembles that of most other distributions. > A Debian source package is supposed to contain a tarball of the > upstream source distribution, without changes. Any > distribution-specific patches are included separately and applied > when the source package is prepared for building. Do we have a policy that all patches we apply in our packages need to be included *separately*? (I couldn't find anything like that in our guidelines, but maybe I missed it) And if not: Do we want such a statement in our guidelines? Background: I wanted to use grub as provided by Fedora on a FAT partition. That didn't work properly, as the Fedora grub includes this patch: http://cvs.fedora.redhat.com/viewcvs/rpms/grub/F-7/grub-0.93-configfile.pat… The main part of it (¹): - .string "/boot/grub/menu.lst" + .string "/boot/grub/grub.conf" That of course creates trouble, as FAT due to its 8.3 filemane limitations can't store a file called grub.conf. Thus I had to build a special grub where this patch wasn't applied. That was no big deal and at least for me a easy thing to do. In F8 and later that's way harder, as there is one patch (created from git afaics) where all the patches that in F-7 were applied separately are now merged into one giant 1,6 MByte big patch: http://cvs.fedora.redhat.com/viewcvs/rpms/grub/F-8/grub-fedora-8.patch?view… Building grub without that one patch of course is way harder now, as I need to get my hands on that one patch and revert it after the giant patch was applied. Not impossible, but way harder if one doesn't know where to find that one small patch to revert it. Do we care or do we want to ignore this (minor) issue? CU knurd (¹) Side note: I think it's wrong to add such a patch, as differing from upstream in things like config file naming just creates trouble and confusion for everyone.

3 2

My absence at yesterdays FPC meeting
by Hans de Goede 20 May '08

20 May '08

Hi All, Sorry for not being there yesterday (again), I'm currently in a bit of a rough spot / time in my personal (well actually paid work) life. Its not that I cannot be there, its more that I just have so much on my mind I forgot. Apologies. Regards, Hans

1 0

Using alternatives
by Dominik 'Rathann' Mierzejewski 20 May '08

20 May '08

Hi. While reviewing a package, I stumbled across the use of alternatives and found out it's not regulated in any way in Fedora. So far, I've encountered three ways of handling the symlinks that are set up using alternatives: 1. some packages have Provides: for them (like cups or postfix), 2. some don't own those files at all (like lam or scim), 3. some %ghost them. All seem to work, but in case of 2. it's not possible to find out which packages own/provide those files using rpm -qf, thus I consider it an inferior solution. Personally, I'm leaning towards 1., but I don't see any disadvantages in 3., either. Comments? Having said that, I'm going to write up a guideline to cover that. I expect to have a presentable draft ready in a week or two. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

4 4

[Fwd: [JPackage-discuss] Moving jpp# to Provides:]
by Jesse Keating 19 May '08

19 May '08

I sent this over to the jpackage discussion list after a lengthy talk on IRC with a few Fedora and jpackage folks. So far there hasn't been any response other than some clarification of the rpm level drawback of using Provides. I thought I would toss it over here for some consideration on our side of things. -------- Forwarded Message -------- From: Jesse Keating <jkeating(a)redhat.com> Reply-To: Discussion about JPackage project <jpackage-discuss(a)zarb.org> To: Discussion about JPackage project <jpackage-discuss(a)zarb.org> Subject: [JPackage-discuss] Moving jpp# to Provides: Date: Mon, 19 May 2008 16:05:01 -0400 In trying to find a compromise for jpackage packages in Fedora, we asked somebody from the jpackage side to provide a list of technical reasons why 'jpp#' needed to continue to be in the Release: string of an rpm. Deepak provided us with http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP In reviewing this and in the various arguments that have happened over the past few years surrounding the jpp vendor tag, I think I've struck upon something that just may work, at least work to the best of the requirements that I know of. If we simply move the 'jpp#' part of the release string to a Provides: line in the spec file, here is what happens: Exclusion of jpp* from a specific repo can still be done, since excludes work upon Provides too. It can be even more precise since currently a package with the name of foolalajpp4me would trigger the excludes and cause problems. Deploying an entire jpackage stack is still possible. This is actually better accomplished at the yum repo level. yum --disablerepo=\* --enablerepo=jpackage install \* <-- that will install everything from jpackage, which I am understanding is the goal of this data point. JPackage is still given credit as the package provides jpp, has the jpp changelogs, can have # comments regarding the jpackage interaction, summary, description, etc... Grouping by jpp is still possible. yum --disablerepo=\* --provides jpp* ---- A current drawback to using jpp# is that the '#' can change, so using rpm itself becomes more tricky as rpm doesn't accept globs. That said, instead of doing jpp# you could just do 'jpp' and then rpm would be able to do things like: rpm -q --whatprovides jpp and well, whatever you want to do with that output. However if you wanted to keep the versioning information, and still retain the ability to query on 'jpp', you could do: Provides: jpp = # or =< if that fills your needs. Since rpm does handle versioning in Provides you can still do rpm -q --whatprovides jpp and that will work. Anyway I'm drifting a bit here, but I did want to start a conversation about the feasibility of using Provides to accomplish the listed goals rather than added characters in the release string. I should also note that for best results, this Provides should be /added/ at both the jpackage and Fedora level. Removal of the jpp# information from release string technically only needs to be done at the Fedora level, it could remain at the jpackage level if so desired. The existence of "jpp#" can easily be controlled by a %{_dist} like tag in the release string. In jpackage build roots that value can expand to 'jpp#' and in Fedora buildroots that value would expand to '.fc#'. Since the other version-release parts should be used for version comparison it shouldn't much matter if jpp# is on the jpackage side and .fc# is on the Fedora side. _______________________________________________ JPackage-discuss mailing list JPackage-discuss(a)zarb.org https://www.zarb.org/mailman/listinfo/jpackage-discuss -- Jesse Keating Fedora -- Freedom² is a feature!

1 0

Broken dependency /bin/sh?
by Roland Wolters 19 May '08

19 May '08

Hi list, I recently got error messages for all my (three) packages stating a broken dependency: ktorrent has broken dependencies in the development tree: On ppc: ktorrent-3.0.2-3.fc10.ppc64 requires /bin/sh On ... I'm not sure what the cause of this is, and what I should do about. Should I add /bin/sh as a fixed dependency? Roland -- Typical Canadian wimpiness! That's why you have snowballs and we have the H-bomb! -- Simpsons

4 8

New packager question
by Gregory Hosler 19 May '08

19 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, new packager here. Apologies in advance for any ignorant questions. :) I'm the package maintainer/co-maintainer and I am now getting ready to do my first package update (the original commit was done for me :). I have been thru the PackageMaintainers/UpdatingPackageHowTo wiki. I have setup my cvs stage area. That was straight forward. I now am preparing to update the fedora package from upstream. The recent upstream package updates (i.e. since the original commit to fedora) include not only a new source tarball, but in addition, some spec file changes (to incorporate a division of sub-packages, as well as re-arrange the directory structure of the package deployment layout, stuff like that). As I walk thru the PackageMaintainers/UpdatingPackageHowTo, it instructs me how to setup cvs (done), import my new tarball to the devel branch and then to do a make. But I am not seeing how my new (changed) spec file is to be integrated into the structure. First question: What is the procedure when there are changes to the spec file ? Next, as I study PackageMaintainers/UpdatingPackageHowTo and my cvs area, in my cvs area I see {common, CVS, devel, EL-4, EL-5, F-7, F-8, F-9} CVS I understand. and I understand that the {EL-4, EL-5, F-7, F-8, F-9} sub dirs are for the different fedora/epel repos. I'm lacking some clarity as to the migration of files from devel to {EL-4, EL-5, F-7, F-8, F-9}, and/or {common} I am gathering that changes are done in devel first, and then after they build correctly, those changes/updates are then applied to the respective branch from {EL-4, EL-5, F-7, F-8, F-9}, one at a time. Is this correct ? now, the pc I'm using for development is presently F-8, i386; How do I verify a package for other platforms, other hardware ? I have heard of mock, koji, and have been to the relevant wiki pages. I'm more needing some step-by-step guidance, as to what needs to be done, and the order of things :) I'm guessing that once I've been thru this once or twice, it'll become 2nd nature, so please bear with me thru this introduction :) Any help / suggestions / (and esp) clarifications regarding the above, are most welcome. All the best, - -Greg - -- +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler ghosler(a)redhat.com | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIMNpw404fl/0CV/QRAklfAKC/+IMlDOsv9VgxtEHR0D8KGzKTdwCfTZS3 a5nTCfd6S0ETA1Xa8KR0CLs= =toZE -----END PGP SIGNATURE-----

5 10

jpp naming exception
by Tom Callaway 19 May '08

19 May '08

Hi FPC members, I would like to propose that we eliminate the jpp naming exception. I think that Bill Nottingham summarized the issue nicely: <notting> ok, as far as I can see: <notting> jpackage wants (the equivalent of) repotags <notting> we do not support repotags in fedora <notting> we have grandfathered in a %{release} hack for jpacakge for a while <notting> we'd like to get rid of that <notting> if they're going to insist that anything done to get rid of that is unacceptable because it's not a repotag... oh well <notting> but yum-priorities is a 'better' solution for repotags than Group-hackery :) I would agree with this assessment, and accordingly, I would like us to vote to eliminate the jpp naming exception during tomorrows meeting. Bring your flame-retardant underwear, but I would like to put this to bed. A few points to keep in mind: 1. This is solely about the naming exception in Fedora, not in any other repositories. 2. We do not permit repotags in any other scenario in Fedora. 3. Using the yum-priorities plugin permits weighting a third party repository over Fedora for packages. As usual, FESCo will have to ratify this. Thanks in advance, ~spot

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging May 2008