Re: [Bug 203864] Review Request: tripwire - IDS
by Thorsten Leemhuis
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
16 years, 1 month
Extras package enables 3rd party repository
by Michael Schwendt
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???
16 years, 1 month
Re: Announcing Dribble a new addon repo for Fedora Extras users
by Ralf Corsepius
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
16 years, 1 month
Apology to Axel and Lists
by Christopher Stone
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
16 years, 1 month
Kernel modules packaged for dkms
by Matthias Saou
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
16 years, 1 month
Refining today's "don't touch system fs" guideline
by Axel Thimm
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
16 years, 1 month
.so files in main package for python packages
by Christopher Stone
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.
16 years, 2 months
Vacation
by Tom Callaway
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
16 years, 2 months
