packaging October 2006

packaging@lists.fedoraproject.org

29 participants
19 discussions

Re: [Bug 203864] Review Request: tripwire - IDS
by Thorsten Leemhuis 20 Oct '06

20 Oct '06

Hi! I justed noticed this: bugzilla(a)redhat.com schrieb: > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. > Summary: Review Request: tripwire - IDS > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203864 > > ------- Additional Comments From zing(a)fastmail.fm 2006-10-19 11:08 EST ------- > please don't spam the rpm installation with a cat of the README.RPM file. > > I'd say a note in the %description pointing the user to the /path/to/README.RPM > is a fine place for that. > > At most, _maybe_ a one line echo of the /path/to/README.RPM... and even that > doesn't really sit to well with me... I strongly agree with the last sentence. Should we write it somewhere into the policies that %pre/%post script should never print stuff? Cu thl

10 9

Extras package enables 3rd party repository
by Michael Schwendt 19 Oct '06

19 Oct '06

Do we want to permit packages in Fedora Extras, which install and enable by default a 3rd party repository? Forwarded message below. It doesn't affect me personally, but in general it would be a tendency I dislike, particularly since this broke the user's system due to unavailability of the added repo. I don't want to file a bug report about this without prior backing from the FPG. [...] Begin forwarded message: Date: Mon, 16 Oct 2006 01:22:44 +0200 From: Michael Schwendt To: fedora-test-list(a)redhat.com Subject: Re: Working on the rawhide extras (Is it broken now?) On Sun, 15 Oct 2006 16:31:16 -0400, Ernest L. Williams Jr. wrote: > On Sun, 2006-10-15 at 16:24 -0400, Ernest L. Williams Jr. wrote: > > Hi, > > > > I was using yum install to get the Fedora extras from rawhide. I > > managed to get up through the letter "c" in terms of packages. > > > > > > Now, I am getting the following error: > > ================================================================== > > [root@python yum]# yum install ddd > > Loading "installonlyn" plugin > > Setting up Install Process > > Setting up repositories > > ftp://ftp.safe.ca/pub/clement-2.1/repodata/repomd.xml: [Errno 4] > > IOError: [Errno ftp error] 550 Failed to change directory. > > Trying other mirror. > > Error: Cannot open/read repomd.xml file for repository: clement > > [root@python yum]# > > ================================================================= > > > > Who/What by the way is clement??? $ rpm -qlvp clement-2.1-209.1.fc6.i386.rpm |grep yum -rw-r--r-- 1 root root 192 Sep 4 13:18 /etc/yum.repos.d/clement.repo Uhm... it's a package in Fedora Extras which installs and enables an external Yum repository for "updates". Highly questionable, since those updates ought to be provided within Fedora Extras. This asks for a new policy. Makes me wonder whether this has been like that during package review already or whether the packager added it later. > > Any ideas, how to work around this one? > > I disabled clement.repo > What does clement have to do with yum???

8 8

Re: Announcing Dribble a new addon repo for Fedora Extras users
by Ralf Corsepius 19 Oct '06

19 Oct '06

On Tue, 2006-10-17 at 10:08 -0500, Tom 'spot' Callaway wrote: > On Tue, 2006-10-17 at 05:32 -0500, Callum Lerwick wrote: > > On Mon, 2006-10-16 at 09:52 +0200, Hans de Goede wrote: > > > What I was trying to say with the above message is that if someone else > > > is willing to have the discussion for a package here and if the outcome > > > is that the package is ok for Extras then I'm more then happy to move it > > > to Extras including putting it through review (again as all packages in > > > dribble are already reviewed). > > > > I'll do it! (I used various Atari STs from 1987 to 1997...) > > > > On Mon, 2006-10-16 at 12:36 +0530, Rahul Sundaram wrote: > > > I believe the rule of thumb here is that if we have freely > > > redistributable "data" that runs on these emulators, we can include the > > > emulator in extras. In other words, the question to ask yourself, is > > > there any legal and Free software uses for the emulators? > > > > > > Since there's GPL ROMs available[1], and the commonly used FreeMiNT > > kernel is apparently a mix of GPL and BSD[2], and most anything open > > source has been ported, and even packaged into RPMs[3], seems to me any > > Atari ST series emulator should be okay in Extras. ARAnyM can even run > > Linux/68k[4]. > > > > Anyone disagree? Do we need a FESCo blessing? > > No disagreement here. This is fine for Fedora. Well, though I agree to you, I think you are about to construct a precedence, which longs for an explanation, which probably should be reflected to the package guidelines: This case clearly violates: http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement and also is not covered by http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware These ROMs aren't a linux system's firmware, these are a foreign system's firmware, to be interpreted by an interpreter (emulator). Ralf

3 5

Apology to Axel and Lists
by Christopher Stone 19 Oct '06

19 Oct '06

I would like to apologize to Axel and the mailing lists for some of the things I have written in the past few days which has lead to quite an extensive flame war over an issue we are all passionate about -- Fedora. When building bridges it is good to look for commonality between adversaries and Axel and I have one thing in common which is that we both want the best experience possible for Fedora users. Accomplishing this goal through flame wars is *not* the way to go, and I apologize to the mailing list and Axel for feeding the flame. From this point on I promise to try my best to be as tactful as possible in this and all future discussions on the list. I am confident that going from here forward we can all work together to make Fedora the best distribution on the planet, and I hope Axel feels the same way. Hopefully we can work together to work out our problems and come to an agreeable solution for everyone. I look forward to working with Axel and the rest of the community with technical discussions to make the highest quality packages and repositories to ultimately give the best possible experience for Fedora users. Sincerely, Christopher Stone aka XulChris

2 1

libtool(.la) archive policy proposal
by Rex Dieter 15 Oct '06

15 Oct '06

See http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives Comments? -- Rex

9 83

Kernel modules packaged for dkms
by Matthias Saou 12 Oct '06

12 Oct '06

Hi, Regarding kernel modules, as many, I got tired of : 1) Packaging them as binary rpms, tracking new kernels to release new packages (it's almost impossible to track Rawhide btw). 2) Endless discussions about what packaging method is the best, upgrade paths, ugliness of versions inside names, common vs. kernel specific bits etc. etc. So I decided to go for the dkms approach to install 3rd party kernel modules, and things got so much simpler. It's pretty obvious : If one can issue a simple "make" to get a required module, why go through so much complexity for rpm packages? There are two possible discussions which can start here : 1) What do Fedora packagers think of dkms? Up to now, no kernel modules packages using dkms have been released in Extras, nor in 3rd party repositories AFAIK. Maybe there are some good reasons, in which case I'm interested in knowing them. 2) If kernel modules packages using dkms are acceptable for Extras, what guidelines should they follow? Here we'd need at least : - A naming guideline, for which I'd suggest "dkms-<modulename>" (Mandrake seems to be using that). - Recommendations for the dkms calls in the scriplets. Do we build the module for the current kernel on install (I do)? Do we run depmod on install (I don't, but maybe I should)? I'm possibly missing stuff. Anyway, here are some pointers : http://svn.rpmforge.net/svn/trunk/rpms/dkms-tiacx/ (Extras candidate) http://svn.rpmforge.net/svn/trunk/rpms/dkms-ipw3945/ (Needs fw/daemon) http://svn.rpmforge.net/svn/trunk/rpms/madwifi/ (HAL license problem) http://svn.rpmforge.net/svn/trunk/rpms/nvidia-x11-drv/ (definite NO!) The last two are good examples of packages that provide both userland tools and kernel modules, and show how splitting out sub-packages isn't even required for this case. Obviously, most 3rd party kernel modules aren't Extras candidates because of licensing issues, but it would be nice nevertheless to have some official Extras packaging guidelines for packages using dkms. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2726.fc6 Load : 2.72 2.84 1.53

11 19

Refining today's "don't touch system fs" guideline
by Axel Thimm 12 Oct '06

12 Oct '06

We voted today on "Build scripts of packages (%prep, %build, %install and %check) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process). Further clarification: That should hold true irrespective of the builder's uid" But after thinking about it I'm not quite happy now. Since we go into details naming what the build scripts are, we should make clear that they are not equal in what they may or may not do. For example %{buildroot} should only be modified by %install, not %prep/%build and %check. How about extending the rule and having a root/non-root rule, too, e.g. o Package builds should yield the same results irrespective of the packaging process' uid/gid, for example builds under root and non-root users should behave the same. o Build scripts of packages (%prep, %build, %install and %check) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process). %{buildroot} should only be allowed to be altered in %install scripts. Note I: The first part of this rule is automatically fulfilled for typical non-user build process uids but the packager should not rely on that, since users may rebuild the src.rpm under root Note II: As a consequence $HOME and similar parts of the filesystem are not to be used directly. Of course some of the allowed write spaces like the builddir, buildroot or $TMPDIR may have been placed under $HOME, so indirectly a user may be writing under $HOME, but direct access to parts under $HOME are strictly forbidden. Note III: Cheating with relative paths (".." escapes) grants you a ticket to packaging hell. -- Axel.Thimm at ATrpms.net

5 13

.so files in main package for python packages
by Christopher Stone 05 Oct '06

05 Oct '06

Upstream says there is a packaging error in one of my packages, pypoker-eval-devel. Upstream claims that the .so file should not be in the devel package but should be in the main package. I told upstream about our .so rule saying .so files should be in -devel, but he said this is not the case for python packages, and promptly demonstrated that the libxml2-python package is similar and that this package puts the .so files in the main pacakge on Fedora as well. So is libxml2-python package in error, or is upstream correct and there are exceptions to the .so rule for python packages? Upstream informs me that my package will break unless I put the .so file in the main package.

3 3

Vacation
by Tom Callaway 04 Oct '06

04 Oct '06

I'm leaving for vacation tomorrow morning, and I will not be back in the continental US until Friday, October 13th. Accordingly, I will not be attending the FESCO or FPC meetings this week or next. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging October 2006