It would have been even nicer had you cc'd fedora-devel-list...
For those that don't read the tex-live@tug list, or the ambassadors'
list, here's the tl2rpm (prototype) announcement:
My main concern is that %post actions will turn out quite hairy, see
below (you were probably on vacation then):
---------- Forwarded message ----------
From: Vasile Gaburici <vgaburici(a)gmail.com>
Date: Sun, Aug 10, 2008 at 8:19 AM
Subject: Re: TeXLive 2008 in F10?
To: Jonathan Underwood <jonathan.underwood(a)gmail.com>, Patrice Dumas
<pertusus(a)free.fr>, Development discussions related to Fedora
Initially I thought we could do without their installer, because I
found only 4 types of "execute", i.e. post install script actions in
the master texlive.tlpdb on CTAN. Then I had a look at their new
the 4 generic "execute" types, there are plenty of hardcoded
package-specific things in TLPostActions.pm.
So, I don't see an easy way of dealing with this. Duplicating all that
stuff in rpm post scriptlets would be highly unmaintanable. The only
sane way would be to install their packager library first, and to
execute post actions from there as needed, which needs at least a
wrapper script since that code is Perl. It's more than I have time for
Since libdvdnav (and libdvdread) have been forked by one of MPlayer's
developers, there's been a significant bugfixing effort going on.
Unfortunately, the new upstream broke the API a bit. While before
now you have to use
A libdvdread build that requires the above change has already landed
in rawhide. The ABI hasn't changed, so there's no immediate need to rebuild.
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
I'm the maintainer of BackupPC, a backup software written in perl.
I have some SELinux issues actually, and need your advices to create the
BackupPC provides a web interface that needs write access to its config
files (actually located under /etc/BackupPC). Problem is that /etc
should not be writeable.
So my question is : where should I place those config files ? Config
files should be located under /etc, but /etc should be readonly.
/var/lib/backuppc would be a good idea, but it's not relevant for config
Solutions I see :
1- keep config files under /etc, and make them writeable from apache,
2- simply move config files to /var/lib/backuppc
3- move config files to /var/lib/backuppc, and then create a symlink to
this path in /etc
What would you advice ?
I just installed rawhide (F10 Alpha LiveCD + yum update) into a
virtual machine to play around with what I could get into a 4GB
location like you'd get on a some of the netbooks out there to see
what sort of milage you'd get. Doing a standard install by booting the
LiveCD, selecting the install to hard disk icon and then selecting all
the the defaults it installed in an lvm vol of around 2.3 gig with the
remaining going to swap. It installed but basically I then had space
issues when trying to do a 'yum update'... interesting!
Anyway I'm wondering if there's a way to some dep tree style bits with
packages that are installed to see what causes the dependencies of
what is actually installed. EG if I do a 'yum remove perl' it
basically wants to uninstall gnome and a lot more but it would be nice
to be able to see exactly what installed packages depend on perl or
perl-Pop-Simple for example.
A friend forwarded me this blog:
and I wondered if it would be something to consider for fedora releases.
This would NOT be as a default, but as a package you can install, if you
wish, to drop the route on your box after whatever expiration date. We
can set the release date in a file in the package and key from there.
If the package was included in a fedora repo we could have it have a
death date of whenever the release started + 14months (some wiggle room
for release slips) for example.
I only speak for me.
That fixed it. Thanks.
On Sun, Aug 31, 2008 at 10:22 PM, Nickolay V. Shmyrev
> В Вск, 31/08/2008 в 22:20 +0300, Vasile Gaburici пишет:
>> I'm using Fedora's spec which first does:
>> intltoolize --force
>> gnome-doc-utils.make is now longer in svn, but is still referenced in
>> help/Makefile.am, so the build is broken.
> Please install gnome-common package and try autogen.sh instead of that.
I need a help regarding package review:
It used linux/dirent.h which has been removed from kernel-headers on rawhide.
So does not build on rawhide.
I patched up to use glibc-headers dirent.h which contains dirent &
dirent64 structures. This patch is wrong.
After investigating code base coredumper checks kernel structure sizes
by including specific kernel headers
containing those structures. So, my question is after removing
dirent.h which dirent & dirent64 structures does kernel use now?
Those defined by glibc-header dirent.h ? If yes, i can fix it quickly.
The story begins here:
The problem is, or I believe it to be, that when an application uses
libgnutls-openssl (meant for easy use of porting openssl programs to gnutls)
for example because of the openssl license issues, and then a library uses the
real openssl (for example glibc through nss_ldap) then in the nss_ldap example,
the layer dlopen's nss_ldap starts using the openssl symbols from gnutls
instead of those from openssl, but they are not ABI compatible -> boom.
Luckily the list of libgnutls-openssl users seems small:
[hans@localhost src]$ repoquery -q --whatrequires
So only 3 programs are affected, given that the same may happen when any used
library uses the real openssl and the application or any other library uses
gnutls-openssl, I would like to suggest the removal of libgnutls-openssl from
Fedora, as long as we have this openssl libraries mess (which we unfortunately
do) we should make sure that the various ssl libraries do not have symbol
clashes, as changes are that through a mix of libraries an application may be
using 2 (or even 3) different ssl libs.
So whats your 2 cents on this?
I have a couple of proposals which I wanted to sound out.
+ Would it be possible to run FEver
(http://fedoraproject.org/wiki/PackageMaintainers/FEver) on a regular
basis? Currently I get the feeling that it is run manually at
irregular intervals, and since I depend heavily on it for tracking
upstream releases this often means that a release is missed
+ Would it be a good idea to have rpath related checks in Koji? Although I use
in my ~/.rpmmacros, some rpath issues are only detected on x86_64
systems? Although I have a x86_64 desktop, it can be a bit problematic
when a x86_64 system is not available. Such issues do not get detected
during the Koji build resulting in violation of the packaging
Free software for the Indian community: