Problems with kernel-2.6.26 and 2.6.27-0.x.rc2
by Joshua C.
I have a strange problem with the 2.6.26 series kernel. 2.6.27-rc1
branch is ok but the same thing happens with 2.6.27.rc2 and the
following. 2.6.25 branch is ok.
I filed a bug report here https://bugzilla.redhat.com/show_bug.cgi?id=458901.
The kernel loads fine until showing "starting udev". then it just
stops and cannot continue. on the 2.6.26 branch i need to keep pressed
atleast one key for it to continue. Then it goes further and
everything freezes when no key is pressed.
2.6.27.rc1 was ok but the same thing showed in 2.6.27.rc2 onwards.
with the lastes kernel-2.6.27-0.287.rc4.git7.fc10 after "startig udev"
I get black and white stripps on my screen and only hardware reset
helps. This makes me think it is something connected with the kernel
modesetting and my radeon gpu. It could also be udev but it is fine
with 2.6.25 and if i keep at least one key pressed then 2.6.26 works
fine. in everycase dmesg shows nothing. What could it be? How can I
see where the problem is?
15 years, 7 months
Very nice of you to write the tl2rpm converter
by Vasile Gaburici
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:
http://tug.org/pipermail/tex-live/2008-August/017190.html
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
<fedora-devel-list(a)redhat.com>
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
packager's sources:
http://www.tug.org/svn/texlive/trunk/Master/tlpkg/TeXLive/. Besides
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
this weekend...
15 years, 7 months
libdvdread slight API breakage
by Dominik 'Rathann' Mierzejewski
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
you'd use
#include <dvdread/dvd_reader.h>
now you have to use
#include <libdvdread/dvd_reader.h>.
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.
Affected packages:
dvdauthor
k3b
lsdvd
python-kaa-metadata
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
15 years, 7 months
wirteable config files path
by Johan Cwiklinski
Hello,
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
relevant package.
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
files.
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 ?
Regards,
Johan
15 years, 7 months
using yum/repoquery to provide dependency trees
by Peter Robinson
Hi All,
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.
Peter
15 years, 7 months
system autodeath
by Seth Vidal
A friend forwarded me this blog:
http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
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.
Any thoughts?
-sv
--
I only speak for me.
15 years, 8 months
Re: Building from svn broken due to missing gnome-doc-utils.make
by Vasile Gaburici
That fixed it. Thanks.
On Sun, Aug 31, 2008 at 10:22 PM, Nickolay V. Shmyrev
<nshmyrev(a)yandex.ru> wrote:
> В Вск, 31/08/2008 в 22:20 +0300, Vasile Gaburici пишет:
>> I'm using Fedora's spec which first does:
>> intltoolize --force
>> autoreconf
>>
>> 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.
>
>
15 years, 8 months
help required regarding coredumper package
by Rakesh Pandit
Hello list,
I need a help regarding package review:
https://bugzilla.redhat.com/show_bug.cgi?id=458204
Home page:
http://code.google.com/p/google-coredumper/
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.
--
Thanks,
rakesh
15 years, 8 months
libgnutls-openssl and real openssl conflict
by Hans de Goede
Hi All,
The story begins here:
https://bugzilla.redhat.com/show_bug.cgi?id=446860
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
'libgnutls-openssl.so.26()(64bit)'
mcabber-0:0.9.7-1.fc10.x86_64
gnutls-0:2.4.1-1.fc10.x86_64
gnutls-devel-0:2.4.1-1.fc10.x86_64
zoneminder-0:1.23.3-1.fc10.x86_64
gkrellm-0:2.3.1-4.fc10.x86_64
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?
Regards,
Hans
15 years, 8 months