devel July 2008

devel@lists.centos.org

31 participants
31 discussions

perl and perl::IO conflict
by Hugo van der Kooij 13 Jul '08

13 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The MailScanner software requires Perl IO v1.23 but perl still ships with v1.22 of the IO module. In the past the IO version was even older and the conflict betwen packages was limited to some manual pages. For that I could create a workaround by putting the manual pages in a different package. But with recent perl updates this no longer works. So the MailScanner community advises one to do the following: ~ - rpm -e perl-IO ~ - yum update (to update perl) ~ - rpm -i --force perl-IO... The bit about the --force option is something I am not at all comfortable with. Using --force on the rm command is about as bad as using it on the F* command. So I was thinking of rebuilding perl to include a new version of the IO module but I can not get my head around it. The goal is to make a repository that can be used beside the normal repositories of Centos and rpmforge to install and maintain MailScanner and the minimal required packages. Anyone any ideas on how to tackle this? BTW the conflict shows up as: ~ file /usr/lib/perl5/5.8.8/i386-linux-thread-multi/IO.pm from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/lib/perl5/5.8.8/i386-linux-thread-multi/IO/Dir.pm from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/lib/perl5/5.8.8/i386-linux-thread-multi/IO/File.pm from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/lib/perl5/5.8.8/i386-linux-thread-multi/IO/Handle.pm from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/lib/perl5/5.8.8/i386-linux-thread-multi/IO/Socket.pm from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/lib/perl5/5.8.8/i386-linux-thread-multi/auto/IO/IO.so from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/share/man/man3/IO.3pm.gz from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/share/man/man3/IO::Dir.3pm.gz from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/share/man/man3/IO::File.3pm.gz from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/share/man/man3/IO::Handle.3pm.gz from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/share/man/man3/IO::Pipe.3pm.gz from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/share/man/man3/IO::Poll.3pm.gz from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/share/man/man3/IO::Seekable.3pm.gz from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/share/man/man3/IO::Select.3pm.gz from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/share/man/man3/IO::Socket.3pm.gz from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/share/man/man3/IO::Socket::INET.3pm.gz from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 ~ file /usr/share/man/man3/IO::Socket::UNIX.3pm.gz from install of perl-IO-1.2301-1 conflicts with file from package perl-5.8.8-10.el5_2.3 Hugo. - -- hvdkooij(a)vanderkooij.org http://hugo.vanderkooij.org/ PGP/GPG? Use: http://hugo.vanderkooij.org/0x58F19981.asc A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting frowned upon? Bored? Click on http://spamornot.org/ and rate those images. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIecLEBvzDRVjxmYERAsikAJ9LJfU2a/7Ud6QceOS3K+c7RQS+owCfcaQM xvYVSAZDtkapHoReTSJXnVc= =d92R -----END PGP SIGNATURE-----

2 2

fixing broken yum update
by Ned Slider 10 Jul '08

10 Jul '08

Hi all, Not quite sure where best to float this idea so I thought I try here first to reach a wider audience. Recently we have seen a number of threads on the fora dealing with broken 'yum update' issues during updates from 5.1 to 5.2. I guess the mailing list has probably seen it's share of similar issues. Here's an example of one such thread: http://www.centos.org/modules/newbb/viewtopic.php?topic_id=14999&forum=37 I'm wondering if it would be useful to put together a *generic* procedure to recover from such issues, one that should work in most cases. In addition, maybe some advice/tips to minimise the risk of performing a large update. I'm thinking of things like performing updates in a screen session when remotely updating over an ssh login in case the ssh connection gets lost mid-update. Also, I tend to perform updates in smaller chunks like: manually install new kernel packages yum update yum\* rpm\* yum update open\* yum update gnome\* kde\* xorg\* etc to minimise the damage if it goes horribly wrong at any point. Not sure if that's good practice or not but it works for me. Plus any other advice relevant to the update procedure - how many times did people ask the difference between 'yum upgrade' and 'yum update', and which they should use :) If it's deemed a good idea, I'm happy to help put together a Wiki page or something although some help with the content (ie, a generic fix, tips and advice) would be appreciated.

2 1

Any news about next kvm release for centos 5.2?
by carlopmart 10 Jul '08

10 Jul '08

Hi all, Which will be next stable release for CentOS 5.2?? Can i use on a production enviromment?? Thanks. -- CL Martinez carlopmart {at} gmail {d0t} com

1 0

yum-cron missing from x86_64 tree
by Joshua Baker-LePain 10 Jul '08

10 Jul '08

It would seem that yum-cron is missing from the x86_64 tree. Is there any reason for this, or am I just missing something? Thanks! -- Joshua Baker-LePain QB3 Shared Cluster Sysadmin UCSF

5 5

Distro Theming
by Alain Reguera Delgado 08 Jul '08

08 Jul '08

Hi guys, What do you think of adding some of modern-CentOS design into our CentOS distro ? Take a look at: http://wiki.centos.org/ArtWork/DistroDesign/modern-CentOS I would like to collect comments of people how really know what things must be changed, dimensions, CentOS Look and Feel, and stuff like that, in order to focus the actions over what is really needed. Here we propose: 1. Anaconda new designs (slides, splash, etc). 1. A Wallpaper 1. A LoginScreen 1. A GRUB Boot Image. I would like to build that page like a Template with useful information about the CentOS key elements that need to be changed, and how they could be changed (note that some elements like rhgb need modifications on a file splash.c that a "find / -iname splash.c" did'nt find, maybe that's on my pc only). Also how could we test an anaconda new design ? to make fixes and adjustments. Anything else you consider useful is welcome. This initial work is based on: http://fedoraproject.org/wiki/Artwork/ThemingOverview Cheers, al.

8 10

Satisfied User - Not.
by Alan Bartlett 05 Jul '08

05 Jul '08

Hi, I thought those who don't monitor the fora might be interested in reading this thread - http://www.centos.org/modules/newbb/viewtopic.php?topic_id=15033&forum=14 After reading it, parsing it into a semblance of English & extracting the pertinent information, I paused, took a couple of deep breaths and posted a reply on behalf of us all. Alan.

2 1

apr-devel and httpd-devel packaging problem
by Ralph Angenendt 04 Jul '08

04 Jul '08

Morning, we seem to have a packaging problem with httpd-devel.x86_64 and apr-devel.x86_64. If you install httpd-devel on an x86_64 machine, apr-devel is required by this package. It then goes on to install apr-devel - but the i386 version. Because of this apxs dies with: cannot open /httpd/build/config_vars.mk: No such file or directory at /usr/sbin/apxs line 201. See <http://bugs.centos.org/view.php?id=2934> apr-devel.x86_64 does not provide apr-devel in a 64 bit version *and* httpd-devel does not require apr-devel in a 64bit version. This way only the i386 version gets installed, while pkg-config on a 64bit machine will look in /usr/lib64/pkgconfig for the apr-1.pc package. Same goes for the 64bit apr-util-devel package. Can someone look into the RHEL 5.2 packages to see if that is an upstream problem? Strange thing: The Requires and Provides are the same in 5.1 - but there the x86_64 versions of apr-devel and apr-util-devel get installed when you install httpd-devel.x86_64 - and not the i386 versions. Ralph

9 17

Re: Too many kernels?
by Axel Thimm 03 Jul '08

03 Jul '08

On Thu, Jul 03, 2008 at 10:50:35AM -0400, Jarod Wilson wrote: > Red Hat suggests building once for each flavor/arch combo and being done > with it. As long as the required kernel symbols are present, they'll > keep working. You make the kernel module deps on the necessary kernel > symbols, which are provided by the kernel package. For example, the > packages provided here... > > http://rhn.redhat.com/errata/RHBA-2007-0654.html > > ...are designed to work with any version-release of a given arch/flavor > RHEL5 kernel. > > But then maybe you already knew that, and don't like that scheme much... > :) I'd love it if it would work :) > But that's what's recommended to all ISV's who build kernel modules > for RHEL5, and so far, its worked out great. Of course, if some out > of tree driver requires a symbol not on the whitelist (i.e., not in > the kernel's Provides:), you lose, but... My experience is that there is no guaranteed kernel ABI nor API by RHEL. Otherwise the kmdl builds would not start to fail between say the 53 series and the 92 ones. On every quarterly update I have to fix several kmdl packages for RHEL due to backports. Usually with RHEL4/5 these are wireless updates. Also at the very least I know of a glibc ABI discrepancy that was fixed in 62, so I'm quite sure that there is no such stable ABI yet, and since upstream will never provide one, it is very difficult for a vendor to provide one (unless in deep maintenance mode where only severe bugfixes/security issues, but no enhancements are addressed). But speaking of policies I meant more the "you are required to update withing XYZ days of an update to have Red Hat support etc.". If a kernel is not anymore supported by Red Hat or CentOS then no kmdl should be built for it. -- Axel.Thimm at ATrpms.net

2 1

Too many kernels?
by Axel Thimm 03 Jul '08

03 Jul '08

Hi, currently ATrpms builds kmdls for the following RHEL5/CentOS5 kernels (actually for CentOS it also builds plus for plus kernels, but let's keep the discussion simple): el5/2.6.18-92.1.6.el5 \ el5/2.6.18-92.1.1.el5 \ el5/2.6.18-92.el5 \ el5/2.6.18-53.1.21.el5 \ el5/2.6.18-53.1.19.el5 \ el5/2.6.18-53.1.14.el5 \ el5/2.6.18-53.1.13.el5 \ el5/2.6.18-53.1.6.el5 \ el5/2.6.18-53.1.4.el5 \ el5/2.6.18-53.el5 \ el5/2.6.18-8.1.15.el5 \ el5/2.6.18-8.1.14.el5 \ el5/2.6.18-8.1.10.el5 \ el5/2.6.18-8.1.8.el5 \ el5/2.6.18-8.1.6.el5 \ el5/2.6.18-8.1.4.el5 \ el5/2.6.18-8.1.3.el5 \ el5/2.6.18-8.1.1.el5 \ el5/2.6.18-8.el5 \ Similar for RHEL4/3. This slows down kmdl updates as say for a new nvidia driver one need to build kmdls for all these kernels in all flavours/archs etc. I start to think whether these kernels are indeed being all used to the extend of justifying full kmdl support. Maybe it would make sense to keep the full last series (2.6.18-92* above) and the highest one from the series before (2.6.18-53.1.21.el5 and 2.6.18-8.1.15.el5). Or is there any other idea? What are Red Hat's, CentOS' policies wrt support of kernels? ATrpms should probably just copy that policy and drop kernel support once the respective upstream support drops it. -- Axel.Thimm at ATrpms.net

5 4

Missing DVB driver(s) in centosplus 5.2 kernel
by Andy Burns 03 Jul '08

03 Jul '08

I've been trying to install a mythtv backend in centos 5.2 under Xen, with PCI passthrough of a DVB-T tuner to the domU. In theory I should just need to use the centosplus kernel to get the additional video capture drivers. In practice I've got two problems, the first of which I think is easy to solve. Once I got the PCI device visible in the domU, I could load the saa7134 driver for the analogue section of the card, but I couldn't load the saa7134_dvb driver for the digital section of the card, this driver is missing from the centosplus kernel. I've installed the kernel source, and modified the .config file as shown in the patch below (the extra SAA7134_DVB settings are what my card requires, but I figure there are potentially users of the BT848_DVB driver that might appreciate that being included too). After re-building the relevant modules, copying them to /lib/modules and doing "depmod -a" I can load the saa7134_dvb module. I saw another user who experienced the same issue with centos 5.1 and Johnny Hughes said he would be willing to enable extra modules if they would help. http://lists.centos.org/pipermail/centos/2007-December/091890.html Could the relevant .config files for centosplus kernels be patched as follows? --- .config.pre 2008-06-29 00:41:18.000000000 +0100 +++ .config.post 2008-06-29 01:33:04.000000000 +0100 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.18-prep -# Sun Jun 29 00:41:10 2008 +# Sun Jun 29 01:33:04 2008 # CONFIG_X86_64=y CONFIG_64BIT=y @@ -2035,7 +2035,7 @@ # CONFIG_VIDEO_ADV_DEBUG is not set CONFIG_VIDEO_VIVI=m CONFIG_VIDEO_BT848=m -# CONFIG_VIDEO_BT848_DVB is not set +CONFIG_VIDEO_BT848_DVB=y CONFIG_VIDEO_SAA6588=m CONFIG_VIDEO_BWQCAM=m CONFIG_VIDEO_CQCAM=m @@ -2057,7 +2057,8 @@ CONFIG_VIDEO_ZORAN_AVS6EYES=m CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_SAA7134_ALSA=m -# CONFIG_VIDEO_SAA7134_DVB is not set +CONFIG_VIDEO_SAA7134_DVB=m +CONFIG_VIDEO_SAA7134_DVB_ALL_FRONTENDS=y CONFIG_VIDEO_MXB=m CONFIG_VIDEO_DPC=m CONFIG_VIDEO_HEXIUM_ORION=m My second problem is a bit harder, or possibly a sign that I've not configured xen pciback/pcifront properly. When the saa7134 driver is loaded in the domU, I see the following messages in dmesg saa7130/34: v4l2 driver version 0.2.14 loaded saa7130[0]: found at 0000:00:00.0, rev: 1, irq: 17, latency: 64, mmio: 0xfebffc00 saa7130[0]: subsystem: 185b:c901, board: Compro Videomate DVB-T200 [card=71,autodetected] saa7130[0]: can't ioremap() MMIO memory saa7134: probe of 0000:00:00.0 failed with error -5 I'm not sure if the saa7134 driver is unusual in trying to perform an ioremap which is causing the error? dev->lmmio = ioremap(pci_resource_start(pci_dev,0), 0x1000); Any suggestions on that one?

3 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel July 2008