In an earlier F-? release, I had added a cyphesis-selinux subpackage
which added selinux protection to the cyphesis game server. This policy
has now been added to the selinux-policy-targeted package, and I need to
have cyphesis-selinux removed. There are two places where this can be
done safely, afaik:
(a) Add 'Obsoletes: cyphesis-selinux' to the cyphesis base package
(b) Add 'Obsoletes: cyphesis-selinux' to the selinux-policy-targeted
package
I'm tempted to go with (a) because it keeps us from having to add many
Obsoletes: tags to the selinux policy packages as the -selinux
subpackage get merged in.
Is (a) an acceptable solution?
--Wart

Hi, I must share this report with you.
I don't use Ubuntu but I installed it on one PC in a lab for students
and kids to learn using it (we have half Fedora and half Ubuntu lab).
I opened Firefox and went to www.redhatmagazine.com and immediately I
got a pop up window with a choice to install Adobe Flash, Swhdec or
Gnash plugin. I was amazed how well this worked and that I had a
choice to pick any one plugin that I believe it better.
I know about Fedora's upstream mentality but I must take my hat to
Ubuntu devels for making their "Ubuntu plugin service" work great. I
know that this is what Mozilla should have made but with their track
for supporting linux isn't the best one. And also I see some projects
that fedora made and didn't wait for the others but fedora and red hat
devels made them because they were missing (pulseaudio,
networkmanager, and lots of others...) so does it make sense to you
that Fedora makes also "Fedor plugin service" for Fedora 10 or do you
believe that if it is not in Firefox by default than Fedora should not
touch it in anyway? Why?
Cheers,
Valent.
--
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic

Hi all,
At Thursday's FESCo meeting, it was decided to delay the upcoming FESCo
election since we are working on defining what FESCo's
role/responsibility will be in the future. Until this is finished, we
felt that it didn't make sense to run the election since candidates
expectations of FESCo's role might be different than what it evolves
into. We're hoping this will be resolved fairly soon, and we'll send
out an announcement on the decision and when the new election will be
held. If anyone has any questions, don't hesitate to contact me.
Later,
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E

Hi,
since some days I get absolutely no updates.
Under bodhi I can see (just a simple example)
gstreamer-plugins-base-0.10.19-2.fc9 on my system there is
[choeger@choeger6 svn]$ rpm -q gstreamer-plugins-base
gstreamer-plugins-base-0.10.19-1.fc9.i386
and yum says: no packages found.
I assume that goes for a lot of packages (including yum, gedit and
others I've had a look at).
What went wrong?
regards
christoph

Hi,
I'm trying to package JCC/PyLucene. Now that OpenJDK made it into Fedora (and
EPEL 5), PyLucene with JCC could possibly be included with Fedora.
But I'm facing some problems writing the spec files, therefore I did not
submit the packages for a review:
- JCC rpm [1]: include and lflags are set in setup.py which I have to change
so that the file contains the rights paths. How can I get these paths while
avoid these pitfalls:
a) Do not have to rebuild JCC every time OpenJDK gets a version bump?
b) Use the correct arch? (...lib/i386) - ok that one could be solved with
some shell scripting in the spec file
c) How to get the correct vm type? On i386 there is a client and a server
vm. Is there a way I can "just" get the client vm directory (and as a
fallback the server vm)?
d) JCC uses JNI so the library paths must be set correctly at runtime.
Unfortunately, the OpenJDK package does not add its paths to
/etc/ld.so.conf.d (did I miss something?) Is there another workaround
besides using rpath (bad, see a) or filing a bug against OpenJDK?
- PyLucene rpm [2]: Besides the linker search path I have another problem with
the version number. PyLucene uses version numbers which are illegal in RPM
such as "2.3.2-1" (sic!). I think the best way to handle it (besides
upstream changing the numbering schema) is just to use "2.3.2.1". Any
objections?
And last but not least the naming: PyLucene seems pretty clear to me, it
conforms to the Python packaging guidelines. But what to do with JCC? It is
essentially a python application containing a C++ library which links against
the JDK. Should this be called python-jcc?
Probably many of these questions are very much newbie-style and may be trivial
for the more experienced but all pointers are appreciated :-)
fs
[1] http://www.schwarz.eu/opensource/rpm/JCC/1.9-2/
[2] http://www.schwarz.eu/opensource/rpm/PyLucene/2.3.2-1/

Dear all,
I have mutilated Jakub Jelinek's excellent binutils and gcc packages to
create binutils-spu and gcc-spu. Both mutant packages need a
significant amount of polishing. However, I'm wondering if others are
interested in a Fedora tool chain for the Cell processor? I'm primarily
interested in the PS3 architecture.
So
(a) Are you interested in a Fedora Architecture SIG for Cell who would
test and maintain a SPU tool chain, and
(b) Are you interested in taking the route I've taken in constructing a
tool chain for Fedora (GCC 4.3 based) rather than supporting the IBM
Cell SDK (GCC 4.1 based)?
--
Aidan Delaney

I'm happy to report that I'm finally feeing myself of everything
Fedora! Starting around a year ago Fedora's red tape and horrible
bureaucracy started turning me off. It all culminated with the
legendary "No KMODs in Fedora" blanket policy on Sept 13. So obviously
when I submitted open-vm-tools as a new package 5 days later (I didn't
know they passed such a ridiculous policy at the time) here:
https://bugzilla.redhat.com/show_bug.cgi?id=294341, it was rejected.
Since then I've been migrating all my boxes at home and work away from
Fedora/CentOS/RHEL to other distros and found the move to be very
refreshing. Fedora now only lives in a couple VMs here at home for me
to maintain my packages (a strange bit of irony, since it was Fedora's
unwillingness to play nicely in a VM that pushed me away to begin
with...), but I haven't even been doing a good job at that. Therefore,
I am hereby relinquishing my responsibilities of everything Fedora,
which include the following packages:
eclipse-phpeclipse -- PHP Eclipse plugin
maradns -- Security-aware DNS Server
mod_auth_pam -- PAM authentication module for Apache
php-json -- An extremely fast PHP extension for JSON
php-pear-Mail-Mime -- Classes to create and decode mime messages
php-pear-Mail-mimeDecode -- transcodes mime messages
php-pear-Net-Sieve -- Communication with timsieved
php-pecl-Fileinfo -- Fileinfo is a PHP extension that wraps the libmagic
library
php-shout -- PHP module for communicating with Icecast servers
tripwire -- IDS (Intrusion Detection System)
From the Horde groupware suite:
horde -- The common Horde Framework for all Horde applications
imp -- The Internet Messaging Program: webmail access to IMAP/POP3
accounts
ingo -- The Horde web-based Email Filter Rules Manager
jeta -- Horde Java SSH module
kronolith -- The Horde calendar application
turba -- The Horde contact management application
Denis Leroy said throughout this process that such a blanket policy was
shortsighted, would hurt Fedora more than it helped, and drive people
away to other distros. He was right, I'm one of those people. Good
luck clinging to your "principles", Fedora, and farewell.
-Brandon

One of the oldest review tickets still open is
https://bugzilla.redhat.com/show_bug.cgi?id=188542, for the fax server
hylafax. Earlier this month I picked this up an attempt to try and
shepherd it through the process, but I'm stuck on a couple of issues
and the submitter does not seem to be willing to address them
satisfactorily. Maybe I should just say "hell no" and drop the
review, but I guess my objections could be wrong so I figured I'd try
to start some discussion.
Issue one is the name: There are multiple pieces of software claiming
to be hylafax. There's the software at hylafax.org, and then there's
the package at hylafax.sourceforge.net, where it is called
"hylafax+". I quote:
The "+" means that it is better.
There's also an "enterprise" version from ifax.com. The second
version, which upstream calls itself "hylafax+" is the one being
submitted, but the submitter argues against using that name (see
comment 38):
However, my suggestion would follow what I've said above about the
Apache http server. The distinction of the "+" will mean very
little to Fedora users (and in-fact may make the package
more-difficult to identify) unless there is more than one HylaFAX
package being distributed by Fedora (say, for example, separate
"hylafax+" and "hylafax.org" packages).
Anyone else agree with that reasoning? What about using
Provides: hylafax
until the hylafax.org package makes it into the distro (assuming
someone actually wants to submit it)?
The second issue is an FHS violation: several directories are
installed under /var/spool which contain things that aren't really in
the spirit of /var/spool. There's a /var/spool/hylafax/bin directory
which, you guessed it, contains executables, a
/var/spool/hylafax/config directory containing config files, and
/var/spool/hylafax/etc containing other, different config files.
Here's what the submitter has to say (see comment 83):
While the vast majority of HylaFAX binaries and their respective
configuration files are installed outside of /var/spool/hylafax,
those three directories (etc, bin, and config) are configuration
files and configuration utility scripts, etc., that control how the
spools are handled.
Due to the way that HylaFAX daemons operate it would be extremely
cumbersome (if not impossible - as in the case of a chroot) for
these to be elsewhere. They're very much like the configuration
files that LPRng had under /var/spool/lpd.
So, that's my argument. I hope that it's acceptable. But if it's
not... unfortunately there's not much that I am willing to do about
it.
Now, lprng isn't in the distro and I really don't think it would have
passed review like that, so I can't buy that as an argument.
"cumbersome", well, too bad I guess. I'm not sure about a chroot. I
mean, just fix the code to look elsewhere. How hard could it be?
But even if, it's too hard to fix, what about a few symlinks? (To
somewhere under /usr/libexec for the bin stuff, and somewhere under
/etc for for config and etc directories.) Do three symlinks violate
the FHS significantly enough to cause issues? My understanding is
that this should be OK with chroots (as long as the links are
relative.) And how does all of this square with selinux?
I'd be appreciative of any suggestions.
- J<