ReviewGuidelines: What are proper permissions?
by Till Maas
Hiyas,
ReviewGuidelines say:
MUST: Permissions on files must be set properly. Executables should be set
with executable permissions, for example.
I just noticed that there are some files with permissions 0444 on my fc5
system installed, for example manpages:
-r--r--r-- 1 root root 24410 15. Feb 2006 cdrecord.1.gz
-r--r--r-- 1 root root 1229 11. Feb 2006 dos2unix.1.gz
-r--r--r-- 1 root root 1790 11. Feb 2006 hesinfo.1.gz
Are 0444 proper permission bits for manpages / non-executable files?
Regards,
Till
17 years, 7 months
Kernel Module Packaging
by Parag Nemade
Hi,
I am planning to submit kernel module packages which are not in
mainstream kernel yet. May i know what guidelines should i follow? Do
Fedora Packaging people confirmed on any kernel module packaging
guidelines? I saw already many packages waiting for review in FE and
yet no progress for them. why so?
I don't understand why Fedora people don't want kernel module
package that do not satisfy
"A publishable explanation from the author(s) why the module is not
merged with the mainline kernel yet and when it's planed to get
merged. You of course can ask the author to explain it directly in the
bug report. "
How then ubuntu/debian distribution got them included in their OS? I
saw many peoples claiming on IRC channels that they got many kernel
module packages from their distro only and enjoying their usage then
why Fedora is having objection on those waiting FE review packages?
BTW is kmdl approach accepted or not? If not then should we let new
kernel modules submissions according to kmod approach?
Regards,
Parag.
17 years, 7 months
Including a CHANGELOG in php-pear extension package.
by Remi Collet
Do you thinks it's a good idea ?
I wrote a little script to extract the CHANGELOG from the package.xml
provided by the upstream package.
Only have to add to the spec :
Source2: xml2changelog
In %prep :
%setup -q -c
[ -f package2.xml ] || mv package.xml package2.xml
+ %{_bindir}/php -n %{SOURCE2} package2.xml >CHANGELOG
mv package2.xml %{pear_name}-%{version}/%{pear_name}.xml
and, of course
%doc CHANGELOG
Here is my script :
<?php
$prog=array_shift($_SERVER['argv']);
if ($_SERVER['argc']<2) die ("usage : " . $prog . " path_to_package.xml\n");
$file=array_shift($_SERVER['argv']);
($xml=simplexml_load_file($file)) || die ($file . " not found !\n");
printf("* Version %s (%s) - %s\n\n%s\n\n",
$xml->release->version, $xml->release->state, $xml->release->date,
$xml->release->notes);
foreach($xml->changelog->release as $rel)
printf("* Version %s (%s) - %s\n\n%s\n\n",
$rel->version, $rel->state, $rel->date, $rel->notes);
?>
17 years, 7 months
pkgconfig dependency question
by Orion Poplawski
After skimming some of the thread about .pc files in -devel or not, it
seems like .pc files should be generating automatic dependencies. Is
that not correct?
I package plplot, and plplot-devel contains:
# cat /usr/lib/pkgconfig/plplotd.pc
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=/usr/include/plplot
drvdir=${libdir}/plplot5.6.1/driversd
Name: PLplot
Description: Scientific plotting library (double precision)
Requires:
Version: 5.6.1
Libs: -L${libdir} -lplplotd -L/usr/lib -lqhull -L/usr/lib -lcsironn
-ldl -lm -L/usr/lib -lcsirocsa -lz -L/usr/lib -lfreetype
Cflags: -I${includedir}
But there are no dependencies on qhull-devel (via libqhull.so) and so
forth. Should there be?
--
Orion Poplawski
System Administrator 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
17 years, 7 months
Removing of unwanted compiler flags from $RPM_OPT_FLAGS
by Jochen Schmitt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
becouse I have to find out, that some packages like blender have
trouble if you are specify $RPM_OPT_FLAGS I have tried to search
a method to remove selected compiler options from $RPM_OPT_FLAGS.
My suggestion to solve this problem you may find at
http://www.fedoraproject.org/wiki/JochenSchmitt/RemoveCFlagsFromRpmOptFla...
I will be happy for any comment and improvements.
Best Regards:
Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.2 (Build 2424)
iQA/AwUBRQWfq09gByurcX4MEQJ6sgCg2XjHBWBAJww22r44/5RhqiP6JIAAoI+K
PRZSyaFRredlXj4YLKXW2XwC
=jsLk
-----END PGP SIGNATURE-----
17 years, 7 months
SELinux testing
by James Morris
Many packages are not being tested with SELinux enabled before release,
which is increasing the number of software defects being shipped, and
causing users to disable SELinux. It is well documented that the cost of
fixing software defects rises dramatically the further from the source
they are experienced, and the worst possible case is after the software is
shipped and deployed. For Fedora, these costs can be thought of in terms
of cost to the project's goodwill and cost of everyone's time dealing with
usually trivially addressable SELinux policy issues.
Given that SELinux is a core security feature of the OS, enabled by
default, I'd like to propose that the Fedora project establishes a simple
guideline for package maintainers in relation to SELinux testing.
This guideline would request that developers test their package with
SELinux enabled (and by this I mean in enforcing mode) and follow a simple
procedure:
1. Ensure they have the latest SELiunx policy installed.
2. Boot with selinux=1 and in enforcing mode.
3. Perform the normal testing of their application.
4. Check syslog (or /var/log/audit/audit.log if audit is enabled) for AVC
messages related to their package.
If there are any bugs or AVC messages:
5. Obtain support from the SELinux team. The best way to do this I
believe is to file a bugzilla against the selinux-policy package. They
should note that they are a Fedora packager (and expect a high priority
response). If SELinux is running all or most of the time, issues will be
caught and fixed eariler in their dev cycle.
6. Don't release the package until the SELinux issue is resolved.
7. If for some reason, #2 is not possible, and the release of the package
is important enough to warrant disabling a core security feature of the
OS:
7a. Make a note of the bugzilla # from (1) in the rpm info, cvs commit and
release notes, with an explanation. Also include a standardized
disclaimer in the rpm info which advises the user of the security risks
arising from disabling SELinux. This should only happen in truly
exceptional cases. I'm not sure how we can reliably notify users that
SELinux can be re-enabled again, and whether they'll tolerate the entire
fs being relabeled on reboot. Really, this just should not happen.
Perhaps we can establish some kind of approval scheme for releasing a
package which requires SELinux to be disabled (or for that matter, any
security feature).
Thoughts?
--
James Morris
<jmorris(a)redhat.com>
17 years, 7 months
Importance of debuginfo packages
by Jason L Tibbitts III
Often when doing package reviews I find a package that needs some hack
in order to get rpmbuild to build a complete debuginfo package. Some
of this relates to passing the proper compiler flags and making sure
the package doesn't strip its own binaries, which I think is
necessary, but occasionally rpmbuild needs the source to be moved
around in the build tree, or it needs symlinks flattened or somesuch.
These are just hacks to work around rpmbuild deficiencies, and I can
understand if packagers are reticent to clutter up their packages for
something of unknown value. So, how important is it to have a proper
debuginfo package? How much hacking is permissible or necessary in
order to achieve that goal? Is an incomplete debuginfo package (that
contains, say, the striped debug information but is missing some or
all of the source code) still useful, or would it be better to have
none at all?
- J<
17 years, 7 months