Perl requires/provides proposal
by Chip Turner
The problem: It's not always obvious what perl RPMs under which an RPM
containing perl modules can run. Perl itself is generally
module-compatible inside of major revisions, but currently we don't
build RPMs that have strong dependencies enforcing this (and
protecting from installing modules under different versions of perl).
Currently some perl modules have requires on the perl NVRE they want
but this requires manual intervention and epoch-awareness, which is
not always programmatically doable.
Proposed solution: All future perl packages will contain new provides
in the perl() namespace to specify both the modules they can run as
well as the embedded environments they provide. All future perl
modules will contain similar requires.
Currently, all perl modules and the perl package itself have sets of
Perl provides and requires that are "namespaced." These dependencies
look like perl(FOO) where FOO is a module name, or perl(:BAR) where
:BAR is a tag made up by me that means something to me. Currently the
:BAR style tags are used for things that break binary compatibilty
(check "rpm -q perl --provides | grep 'perl(:'" -- things like
threading module, perlio, etc show up).
So the plan is to add perl(:MODULE-COMPAT-5.8.3) (and 5.8.2, 5.8.1,
and 5.8.0) as Provides to the perl package itself, and add this
equivalent to any perl module: perl(:MODULE-COMPAT-$(perl -MConfig -e
'print $Config{version}')). In other words, a module, when compiled,
will require the :MODULE-COMPAT tag of the version of perl it was
compiled under.
Also, the perl module itself will explicitly own all dirs listed in
its @INC list. Some perl modules have requires on these dirs to solve
the problem above, and this would make those modules work, but that's
not really the right solution, hence the need for a more "official"
expression of the dependencies involved.
Thoughts?
Chip
--
Chip Turner cturner(a)redhat.com
Red Hat, Inc.
20 years, 3 months
XFree86 4.3.0-56 EPIA test results
by Pekka Pietikäinen
Hiya
I did some testing on the new via XFree86 driver, and it certainly
works a lot better than the old one (which didn't work at all for me :-) )
Biggest annoyance was Xv not working very well (basically the colors were
quite a bit off, hard to explain how :-) ). Grabbing the driver from
http://www.shipmail.org/%7Ethomas/via/xfree43/epia7.2/
fixed that.
For DRI I just patched 2.6.2-1.81 with
http://epia.kalf.org/gryle_patches/via-v4l-1.4a-drm.patch.gz
(with use of floating point in ddmpeg.c fixed, there are two uses of *1.5 in
the code, which were trivially fixed :-). With
http://www.uk.linux.org/~alan/via_dri.so that was enough to make glx and
tuxracer work (colors were somewhat off in the latter, tho...)
Will bugzilla once -57 (and the devel kernel with via dri support the
existance of which was suggested a while back, but which is nowhere to be
found), that hopefully should make the dust settle enough to a bug report to
be useful at all :-)
--
Pekka Pietikainen
20 years, 3 months
Gnome-panel update?
by Leonard den Ottolander
Hi,
Seeing the multitude of issues with gnome-panel that have not been
solved I thought it might be time for an update. There are two
approaches to this: Fixing the current tree, or updating to 2.4.2 which
is a bug fix release.
Considering the first option I have gathered some issues and patches.
Please have a look at http://www.ottolander.nl/gnome-panel/ for details.
You might want to give the attached spec file and patches a try.
I am not sure how difficult an update to 2.4.2 would be in relation to
patches that have already been applied to 2.4.0. Thoughts?
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
20 years, 3 months
FC2 on DVD?
by Simon
Is there any chance that FC2 will be released also as a single DVD iso too?
Isn't that more handy?
Thanks.
--
Simon.
20 years, 3 months
Self-Introduction: Zoltan Kota - new key
by Zoltan Kota
1. Full legal name
Zoltan Kota
Something went wrong on my computer, so I had to create a new pgp key:
7. GPG KEYID and fingerprint
pub 1024D/F2594A58 2004-02-16 Zoltan Kota <z.kota(a)gmx.net>
Key fingerprint = 9CCB A661 FE96 800F 31F0 40DB 9C65 8C7A F259 4A58
sub 1024g/18904A30 2004-02-16 [expires: 2006-02-15]
Zoli
20 years, 3 months
Testers Required for Next Generation Input Method
by Lawrence Lim
The Fedora Project will be adopting a revolutionary new Input Method
system in the upcoming release of the Fedora Core 2. We would like to
extend an invitation at this time to East Asian users in particular to
test this preliminary release and provide us with feedback so we can
improve the software and ensure that the Input Methods will be easier,
more efficient and pleasant to use.
Intranet/Internet Input Method Framework (IIIMF) is the next generation
Input Method Framework set to replace the legacy X Window System Input
Method (XIM) used by existing Input Methods such as chinput, xcin,
kinput2, ami and many others. As the technology is still at its infancy,
wider testing effort by community is needed to expediate the maturity of
the technology.
IIIMF server loads Language Engines (LE) dynamically at runtime as
requested by clients. In this first round of testing, four LEs are
available:
+ iiimf-le-inpinyin for Simplified Chinese (zh_CN.UTF-8)
+ iiimf-le-xcin for Traditional Chinese (zh_TW.UTF-8)
+ iiimf-le-canna for Japanese (ja_JP.UTF-8)
+ iiimf-le-hangul for Korean (ko_KR.UTf-8)
If you wish to participate in this first round of testing, a Testing Guide
is now available at <URL>. It will give you the necessary information in
setting up the IIIMF and using the LE specific to your locale.
Input Method Testing Discussion
Mailing List: fedora-i18n-list(a)redhat.com
Subscribe at:
https://www.redhat.com/mailman/listinfo/fedora-i18n-list
IRC: Channel #fedora-i18n on irc.freenode.net
Best Regards,
Fedora I18N Team
20 years, 3 months
Modifications at the GNOME main menu
by Adriano Del Vigna de Almeida
Hello there!
I'm working in modifications in the GNOME main menu, reorganizing it,
adding and removing some features. Currently I'm working into the
'redhat-menus' package, simply making modifications for tests. But I got
no results.
For example, I removed the 'Accessories' section from
'applications-submenu.m4' file, recompiled the package and re-installed
the package, and got no results. The 'Accessories' menu section remains
there. Any other modification get no results. Am I working at the
correct package and files?
Thanks in advance!
Adriano Del Vigna de Almeida
Free Software
Brasília - Curitiba - Rio de Janeiro - São Paulo
Email: katmandu(a)fs.inf.br
ICQ#: 14898488
20 years, 3 months
Help building an rpm
by Nate Bradley
I hope this is the right list.
I am trying to build an rpm for mod_perl-1.29 (I'm using apache 1.3)
rpmbuild is complaining that the perl files cannot be found and that is
true because the directory cannot be cd'd to directly.
It is looking for the files in /var/tmp/mod_perl-root/usr/lib/perl?/...
but when I cd to '/var/tmp/mod_perl-root/usr/lib/perl? the directory
doesn't exist.
if I cd to '/var/tmp/mod_perl-root/usr/lib' there is a 'debug' directory
instead of 'perl?'.
only when I cd to '/var/tmp/mod_perl-root'
then cd to 'usr/lib' does the perl (and everything else) directory
appear.
What is this behavior?? I'm including the .spec file modified from
mod_perl-1.26-5.
%define defperlver 5.8.1
%define perlver %(rpm -q perl --queryformat '%%{version}' 2> /dev/null
|| echo %{defperlver})
%define perlmajor %(echo %{perlver} | cut -f1 -d.)
%define contentdir /var/www
Summary: An embedded Perl interpreter for the Apache Web server.
Name: mod_perl
Version: 1.29
Release: 1
Group: System Environment/Daemons
Source0: http://perl.apache.org/dist/mod_perl-1.29.tar.gz
License: GPL
URL: http://perl.apache.org/
BuildRoot: %{_tmppath}/%{name}-root
Requires: webserver, perl = %{perlver}
BuildPrereq: apache-devel, perl
Prereq: perl
%description
Mod_perl incorporates a Perl interpreter into the Apache web server,
so that the Apache web server can directly execute Perl code.
Mod_perl links the Perl runtime library into the Apache web server and
provides an object-oriented Perl interface for Apache's C language
API. The end result is a quicker CGI script turnaround process, since
no external Perl interpreter has to be started.
Install mod_perl if you're installing the Apache web server and you'd
like for it to directly incorporate a Perl interpreter.
%prep
%setup -q -n mod_perl-%{version}
%build
# Compile the module.
perl Makefile.PL \
USE_APXS=1 WITH_APXS=%{_sbindir}/apxs PERL_USELARGEFILES=0 \
EVERYTHING=1 CCFLAGS="$RPM_OPT_FLAGS -fPIC -DEAPI"
make
# Run the test suite.
make test
%install
[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
make pure_install INSTALLDIRS=vendor PREFIX=$RPM_BUILD_ROOT%{_prefix}
# Install the module itself.
mkdir -p $RPM_BUILD_ROOT/etc/httpd/modules
install -c -m 755 apaci/libperl.so $RPM_BUILD_ROOT/etc/httpd/modules/
# Install its manual.
mkdir -p $RPM_BUILD_ROOT%{contentdir}/html/manual/mod/mod_perl
install -c -m 644 htdocs/manual/mod/mod_perl.html \
$RPM_BUILD_ROOT%{contentdir}/html/manual/mod
make -C faq
rm faq/pod2htm*
install -m644 faq/*.html
$RPM_BUILD_ROOT%{contentdir}/html/manual/mod/mod_perl/
# Remove the temporary files.
#find $RPM_BUILD_ROOT%{_libdir}/perl?/vendor_perl/*/*/auto -name "*.bs"
| xargs rm
#rm
$RPM_BUILD_ROOT%{_libdir}/perl?/vendor_perl/*/*/auto/%{name}/.packlist
%clean
[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
%doc CREDITS Changes README SUPPORT cgi_to_mod_perl.pod mod_perl.pod
%doc mod_perl_method_handlers.pod mod_perl_traps.pod mod_perl_tuning.pod
%doc INSTALL faq/*.html eg faq
%doc apache-modlist.html
%{contentdir}/html/manual/mod/*
#%{_libdir}/apache/libperl.so
/etc/httpd/modules/libperl.so
%{_libdir}/perl?/vendor_perl/*/*/auto/*
%{_libdir}/perl?/vendor_perl/*/*/Apache*
%{_libdir}/perl?/vendor_perl/*/*/Bundle/*
%{_libdir}/perl?/vendor_perl/*/*/cgi*
%{_libdir}/perl?/vendor_perl/*/*/mod_perl*
%{_mandir}/man3/*.3*
20 years, 3 months
