devel

devel@lists.centos.org

4 participants
4640 discussions

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

expect x86_64 dependecy
by David Hrbáč 03 Jul '08

03 Jul '08

Hi, seems to me there's bad dependency for expect on x86_64 system. Anyone to confirm? David Hrbáč [root@builder1 ~]# yum install expect Loading "fastestmirror" plugin Loading "security" plugin Determining fastest mirrors * rpmforge: ftp-stud.fht-esslingen.de * base: ftp.fi.muni.cz * updates: ftp.fi.muni.cz * addons: ftp.fi.muni.cz * extras: ftp.fi.muni.cz rpmforge 100% |=========================| 1.1 kB 00:00 base 100% |=========================| 1.1 kB 00:00 updates 100% |=========================| 951 B 00:00 addons 100% |=========================| 951 B 00:00 extras 100% |=========================| 1.1 kB 00:00 Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package expect.i386 0:5.43.0-5.1 set to be updated --> Processing Dependency: libtcl8.4.so for package: expect ---> Package expect.x86_64 0:5.43.0-5.1 set to be updated --> Running transaction check ---> Package tcl.i386 0:8.4.13-3.fc6 set to be updated --> Finished Dependency Resolution Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: expect i386 5.43.0-5.1 base 158 k expect x86_64 5.43.0-5.1 base 160 k Installing for dependencies: tcl i386 8.4.13-3.fc6 base 961 k Transaction Summary ============================================================================= Install 3 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 1.2 M Is this ok [y/N]:

4 4

Question about CentOS 5 comps.xml
by Hao Xu 27 Jun '08

27 Jun '08

Hi! The following packages are listed in CentOS 5.2 comps.xml but cannot be found in CentOS 5.2 i386 release Base repo: ckermit clustermon compat-gcc-295 compat-gcc-296 compat-gcc-32 compat-gcc-32-g77 compat-gcc-c++-32 compat-libgcc-295 compat-libstdc++-295 compat-libstdc++-32 conga-devel ddd elilo elsa fonts-ISO8859-9-75dpi gfs gnopernicus httpd-suexec inkscape iprutils java-1.4.2-gcj-compat-plugin kdepim-devel kernel-kdump kmod-gfs-kdump kmod-gnbd-kdump lha libica libipathverbs libpng10-devel libungif-devel longrun mcelog netconfig notify-daemon open openoffice.org-langpack-ur_IN openssl-ibmca perl-Cyrus ppc64-utils prctl pup rhel-instnum rhn-check rhn-setup rhn-setup-gnome ricci-modcluster s390utils salinfo strace64 sysfsutils-devel system-config-printer-gui totem-mozplugins valgrind-callgrind yaboot yum-rhn-plugin The following packages are listed in CentOS 5.2 comps.xml but cannot be found in CentOS 5.2 x86_64 release Base repo: apmd ckermit clustermon compat-gcc-295 compat-gcc-296 compat-gcc-32 compat-gcc-32-g77 compat-gcc-c++-32 compat-libgcc-295 compat-libstdc++-295 compat-libstdc++-32 conga-devel ddd elilo elsa fonts-ISO8859-9-75dpi gfs gnopernicus gnu-efi gpart httpd-suexec ibmasm inkscape iprutils java-1.4.2-gcj-compat-plugin kernel-kdump kmod-gfs-kdump kmod-gnbd-kdump lha libica libpng10-devel libungif-devel longrun netconfig notify-daemon open openoffice.org-langpack-ur_IN openssl-ibmca perl-Cyrus ppc64-utils prctl pup rhel-instnum rhn-check rhn-setup rhn-setup-gnome ricci-modcluster s390utils salinfo strace64 sysfsutils-devel system-config-printer-gui totem-mozplugins valgrind-callgrind yaboot yum-rhn-plugin In addition, an `eclipse' group is listed in category `apps', a `workstation' group is listed in category `base-system', but these two groups are not defined in comps.xml. I know that some packages only exist in one arch, e.g. apmd, s390utils, etc, but what about the others? Do we really need to keep them in the comps.xml file? Best regards, Hao

4 5

trouble building x86_64 gcc (w/ mock) for 5.2
by Paul B Schroeder 27 Jun '08

27 Jun '08

Hey all... I know what is causing it to fail, but I'm not certain why. The what is that mock/yum is not pulling in glibc-devel for i386 into the mock chroot. So it is causing the multi-lib stuff to fail. In my root.log I can see glibc-devel for x86_64 was installed in the chroot. But why is it not pulling glibc-devel.i386 into the chroot? I'm using mock-0.9.7-1.el5 from EPEL.. mock config file and relevent build.log portion below.. Thanks in advance... Paul... ---------------------- /etc/mock/centos-5-x86_64.cfg: #!/usr/bin/python -tt import os config_opts['root'] = 'centos-5-x86_64' config_opts['target_arch'] = 'x86_64' config_opts['dist'] = 'centos5' # only useful for --resultdir variable subst # ccache not available on epel5 config_opts['plugin_conf']['ccache_enable'] = False config_opts['yum.conf'] = """ [main] cachedir=/var/cache/yum debuglevel=1 reposdir=/dev/null logfile=/var/log/yum.log retries=20 obsoletes=1 gpgcheck=0 assumeyes=1 exclude=[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefhijklmnopqrstuvwxyz]*.i*86 g[abcdefghijkmnopqrstuvwxyz]*.i?86 glib2.i?86 glib.i?86 *-devel.i?86 # repos [os] name=os mirrorlist=http://mirrorlist.centos.org/?release=5&arch=x86_64&repo=os #baseurl=http://mirror.centos.org/centos/5/os/x86_64/ [updates] name=updates mirrorlist=http://mirrorlist.centos.org/?release=5&arch=x86_64&repo=updates #baseurl=http://mirror.centos.org/centos/5/updates/x86_64/ [groups] name=groups baseurl=http://dev.centos.org/centos/buildsys/5/ """ config_opts['macros']['centos_ver'] = '5' -------------------- mock command output: [pauls@smith gcc]$ mock -r centos-5-x86_64 --rebuild /net/tomcat/vol/vol1/builds/mirror/centos/5.2/os/SRPMS/gcc-4.1.2-42.el5.src.rpm INFO: mock.py version 0.9.7 starting... State Changed: init plugins State Changed: start INFO: Start(/net/tomcat/vol/vol1/builds/mirror/centos/5.2/os/SRPMS/gcc-4.1.2-42.el5.src.rpm) Config(centos-5-x86_64) State Changed: lock buildroot State Changed: clean State Changed: init State Changed: lock buildroot INFO: enabled root cache INFO: enabled yum cache State Changed: cleaning yum metadata State Changed: running yum State Changed: creating cache State Changed: setup State Changed: build ERROR: Exception(/net/tomcat/vol/vol1/builds/mirror/centos/5.2/os/SRPMS/gcc-4.1.2-42.el5.src.rpm) Config(centos-5-x86_64) 15 minutes 33 seconds INFO: Results and/or logs in: /var/lib/mock//centos-5-x86_64/result ERROR: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/gcc41.spec'] ----------------------------- relevant parts from /var/lib/mock//centos-5-x86_64/result/build.log: make[4]: *** [32/crtend.o] Error 1 make[4]: *** Waiting for unfinished jobs.... In file included from /usr/include/features.h:352, from /usr/include/stdio.h:28, from ../../gcc/tsystem.h:90, from ../../gcc/crtstuff.c:68: /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory make[4]: *** [32/crtbegin.o] Error 1 make[4]: *** [32/crtendS.o] Error 1 In file included from /usr/include/features.h:352 , from /usr/include/stdio.h:28 , from ../../gcc/tsystem.h:90 , from ../../gcc/crtstuff.c:68 : /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory make[4]: *** [32/crtbeginS.o] Error 1 make[4]: Leaving directory `/builddir/build/BUILD/gcc-4.1.2-20080102/obj-x86_64-redhat-linux/gcc' make[3]: *** [extra32] Error 2 make[3]: Leaving directory `/builddir/build/BUILD/gcc-4.1.2-20080102/obj-x86_64-redhat-linux/gcc' make[2]: *** [stmp-multilib] Error 2

3 7

Ethernet device __tmpXXXXXXXXXX
by Mark Deric 26 Jun '08

26 Jun '08

I have a CentOS 5 system that started exhibiting the unusual behavior similar to that described in CentOS bug #2791. I my case, the interface that used to be eth0, with modprobe.conf line "alias eth0 8139too" and lspci listing "02:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)", now comes up like the bug symptom. After boot, ifconfig shows __tmp1654060624 Link encap:Ethernet HWaddr 00:1D:09:6A:D8:1C BROADCAST MULTICAST MTU:1500 Metric:1 ... Humorously enough, it is possible to manually configure the interface using that name. And, using some "set -x" lines in the init scripts, I learned that this does not happen at boot time because the script cannot associate __tmp1654060624 with /etc/sysconfig/network-scripts/ifcfg-eth0. In the scripts the basic breakdown is that the "ip -o link" command returns the bogus __tmp device name; I'm not sure why, or how to fix this. A better workaround to getting the interface configured is to execute "ip link set __tmp1654060624 name eth0; service network restart" Unlike the bug, my setup always boots to a bogus device name (though the 10 digit number following __tmp always changes). I'm not sure what changed from when it booted to eth0 just fine (though I did have a power outage; but forced the fsck and everything, except this seems fine). The part I don't get is how the boot time "ip -o link" command gets the bogus device name. I'd appreciate any help. Thanks. Regards, Mark

1 0

RE: [CentOS] PHP 5.2 for CentOS 5.x
by Bleier Thomas 26 Jun '08

26 Jun '08

Hi, ok - now I'm on the centos-devel list... :-) I have a small system hosting two MediaWiki's which are occasionally hit by a few users - its currently running CentOS 5.0, I plan to update it to 5.2 in the next days, and I could install PHP 5.2 for testing since it's not a mission-critical site. Since it's a virtual machine, I could also do the first steps in a "lab-like" environment on a copy. Would that be helpful? Best regards, __ /homas -- Thomas Bleier, DI Information Management Austrian Research Centers GmbH - ARC HG Wien - FN 115980i - ATU14703506 2444 Seibersdorf, Austria Mobile: +43 (664) 8251279 E-Mail: thomas.bleier(a)arcs.ac.at -----Original Message----- From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On Behalf Of Karanbir Singh Sent: Tuesday, June 24, 2008 4:44 PM To: CentOS mailing list Subject: Re: [CentOS] PHP 5.2 for CentOS 5.x Bleier Thomas wrote: > Hi everybody, > > depends on what you expect, but I'm willing to help in testing that - > seems that I will need PHP 5.2 in the near future, and I'd be happy if > it would be available for CentOS 5. > Sounds good, over the next few days lets try and get something started. Are you on the centos-devel list ? thats where we'll handle this till its released. - KB _______________________________________________ CentOS mailing list CentOS(a)centos.org http://lists.centos.org/mailman/listinfo/centos

9 16

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel