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 : 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 : 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 "126.96.36.199". Any
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 :-)
On Mon, 2008-06-02 at 11:55 -0300, Mauro Carvalho Chehab wrote:
> Hi David,
> On Mon, 02 Jun 2008 11:31:56 +0100
> David Woodhouse <dwmw2(a)infradead.org> wrote:
> > A few moments with git-annotate showed that the missing ioctls were
> > removed in commit 26d507fcfef7f7d0cd2eec874a87169cc121c835¹ by Brandon
> > Philips. In their place, we have the following:
> > /* Deprecated, use V4L2_CID_PAN_RESET and V4L2_CID_TILT_RESET */
> > #define V4L2_CID_HCENTER_DEPRECATED (V4L2_CID_BASE+22)
> > #define V4L2_CID_VCENTER_DEPRECATED (V4L2_CID_BASE+23)
> > That seems like a rather dubious change to the user API -- shouldn't we
> > ensure that existing software continues to build, but maybe add a
> > compile-time or run-time warning for those using the deprecated ioctls?
> > Mauro, Brendan: unless the removal of those ioctls has been properly
> > documented in Documentation/feature-removal-schedule.txt for an
> > appropriate amount of time, please could you put them back as they were.
> > Changing the userspace API like this isn't acceptable.
> IMO, there's nothing to be added at feature-removal-schedule.txt. Those controls
> aren't used by any kernel drivers on a long time (I suspect that they were
> never used).
> The issue is that they are targeted to do exactly what V4L2_CID_PAN_RESET and
> V4L2_CID_TILT_RESET do. So, they are duplicated stuff.
> I was not aware that an userspace is using those symbols, but, if so, it is
> likely to be related to some binary-only or out-of-tree drivers .
It was part of the published API, and it was being used by the gstreamer
v4l2 plugin -- which now fails to build.
Yes, of course we'll fix the code in question, but just removing APIs
from the headers and causing source code to break without any prior
warning is not acceptable. That's precisely what
feature-removal-schedule.txt is _for_.
I would like the Spin SIG members, current spin maintainers and other
enthusiasts to get together in #fedora-meeting at Tuesday, June 10th, at
18:00 UTC, so you are hereby invited to join us.
There's several items on the Agenda.
- How come we did not have Fedora 9 Spins of:
- Electronic Lab
The Electronic Lab does have a certain amount of people interested but
no one "accountable" maintainer, while there was a lot of exposure,
whereas the Developer spin did not get any maintenance, afaics.
Regardless, we will need to contact maintainers during the Alpha-Beta
time-frame to update their spins, or come up with a policy/guideline for
the maintainers to hold on to.
- Drafted policies
I've submitted the drafted policies for the Spin SIG to -devel, but
they did not get much feedback. We need to determine if they are
sufficient to enter the F10 development/release cycle with.
- The release process / spin process
Right now, we put in a request at the Release Engineering Team to
have certain spins spun. This may or may not be "golden" spins, but
regardless, I think we prefer to trigger building our own spins, and
then hand one over to Release Engineering, that can be released. Let's
talk about this at our meeting.
- Updates to kickstarts are submitted... where?
I think the spin-kickstarts GIT repository at fedorahosted.org needs
to have the latest kickstarts, whereas now developments still take place
in the livecd-tools GIT repository at fedorahosted.org. I've tried to
come up with a branching policy that makes development go into the
master branch, which we branch off for maintenance purposes every
release. I've also been thinking about a commit access policy, and I
think having commit access for at least the primary maintainers of each
spin makes the most sense.
- kickstarts RPM package for "Home Use"
A review request has been submitted for a "spin-kickstarts" package,
which I'd like you to look at and give some feedback on. This is to
enable people getting approved (by Spin SIG and Board) kickstarts to
their own computers in a controllable fashion.
If you have any other topics you want to discuss at the meeting, please
let me know; there's a bunch of kickstarts from Rahul that need
reviewing as well.
I hope to see you all so that we can accomplish something (and a little
more). I'm also planning to have a HackFest/BarCamp session at FUDCon in
Boston, in two weeks.
Jeroen van Meeuwen
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.
(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)?
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
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
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.
I have prepared a bunch of updates for F-9 in coordination with
the involved maintainers for the following packages:
I am now at the step to submit the request to bodhi but there is one
little problem I am not sure how to address.
All the updates need to go into testing/stable at the same time in order
What is the right procedure to guarantee that it will happen properly?