Discuss January 2006

discuss@lists.centos.org

240 participants
336 discussions

GFS and gnbd for 2.6.9-22.0.2 kernel
by carlopmart 23 Jan '06

23 Jan '06

hi all, Someboby knows when gfs and gbd will be released for 2.6.9-22.0.2 kernel?? Thanks. -- CL Martinez carlopmart {at} gmail {d0t} com

2 1

RFE: centos-announce subject line rearrange
by Farkas Levente 23 Jan '06

23 Jan '06

hi, it's a nice thing that we've a centos-announce list, but currently the subject of this mails on this list has very long lines. eg: ----------------------------------------- [CentOS-announce] CESA-2006:0160 Moderate CentOS 3 i386 tetex - security update [CentOS-announce] CESA-2006:0140 Important CentOS 3 ia64 kernel - security update ----------------------------------------- which means 1280x1024 sreen in mozilla the mailer's preview line is not wide enough to show thre real important part of the mail ie. the name of the package which is updated. wouldn't be it possible to shorten somehow the subject line? solutions: - drop the name of the list (ie: [CentOS-announce] ) - drop the CESA reference number (ie: CESA-2006:0160 ) - or simple rearrange the subject eg into: [CentOS-announce] CentOS 3 ia64 kernel - CESA-2006:0140 Important security update for me it's totaly inrelevant the solution just move the package name somehow left. yours. just my 2c. -- Levente "Si vis pacem para bellum!"

3 8

Whither LM87 sensor driver?
by Steve Snyder 23 Jan '06

23 Jan '06

From my reading of the Linux Kernel mailing list, it seems that the LM87 sensor driver made it into kernel 2.6.8. Anyone know why it is not present in the RHEL4/Centos4.2 current kernel? Thanks.

2 1

Tyan 2895 in production?
by Chris Mauritz 23 Jan '06

23 Jan '06

I stand to "inherit" some of these motherboards from another project. They seem like a nice dual socket 940 board that also supports dual core opterons, but I don't have any personal experience with them. Anyone using them in production w/CentOS 4.2? Best regards,

2 2

mplayer compile on x86_64
by Jerry Geis 22 Jan '06

22 Jan '06

All I am trying to get mplayer going on x86_64. I used the following command ./configure --with-x11libdir=/usr/X11R6/lib64 --with-codecsdir=/usr/local/lib/codecs make make install It erros with the requested audio codec is not found. I have alsa devel package installed... Does anyone have mplayer running on x86_64 and wish to share the compile instructions? Thanks, Jerry

2 1

Customizing desktop systems
by Collins Richey 22 Jan '06

22 Jan '06

My company is now in the process of rolling out enterprise desktop systems (mostly rhel3 since we have some commercial software that is not quite ready for rhel4). Most of our users (ca. 120 workstations) are using RH9. I've developed a simple, extensible set of kickstart post procedures and firstboot procedures that provide a quick way to image new systems, but one thing is missing. I haven't found a good way to deliver a common desktop image for KDE or Gnome. We want to provide each new user with a common set of desktop icons, for example. I tried using a preloaded /etc/skel, but that doesn't work very well. There are too many individual hidden files and directories where userid is imbedded. I would need to search and replace userid in a lot of files. Has anyone in the group tackled this sort of problem, and would you care to share your methods? What I'm trying to avoid is having to configure each new desktop manually to have a common look and feel. -- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan

2 2

Re: [CentOS] Bittorrent RPM/Python Issue
by Jim Perrin 22 Jan '06

22 Jan '06

On 1/22/06, Sam Trenholme <sam+centos(a)hotaru.chaosring.org> wrote: > >Building from source on an rpm based distro isn't a good idea. > > I disagree with this statement. Building from source is something I have > been doing on RPM-based distros since long before Fedora Core or CentOS > existed. It's a very old UNIX tradition. Basically, this is why there > is a /usr/local; the files that are installed from RPMs are in /usr (or > just the root directory) and programs compiled and installed from source > are in /usr/local. Almost all programs, when compiled and installed from > source, will install in /usr/local by default. You're allowed to disagree. It doesn't make your point right however. My statement doesn't make me right either. Just because something was done in the past doesn't make it a tradition, or make it the proper way to do things. Package management by source sucks. Many source applications don't allow for 'make uninstall' etc. So you have to dig by hand to figure out what it put on the system, and dig to remove it if need be. If you're going to take the time to build from source, take the time to put it in an rpm. > The issue, though, is that one shoudn't instll from source to replace a > program already on their system unless they go to great care to make > sure the replaced program doesn't step over the already installed program. > The simplest way to ensure this is to simply remove the RPM install of the > offending program before installing from source. However, some programs > have dependencies on the already-installed RPM which you really don't want > to mess with. The way I work around this is by having my own perl be > called "perl5.8.7" instead of perl in /usr/local/bin, and having my own > from-source install of ghostscript called gs-afpl. This way, the newly > installed program is seen as a completely separate program from the already > installed program. Except that it can't really be duplicated reliably system to system, upgrade to upgrade. There is no changelog for how you built it unless you take the time to do it, and most people don't. Basically once you start down this road you're on your own for support. So yes, as a rule, I stick by my statement of "don't build from source". While it may work well in limited circumstances, it is NOT something that I recommend. It's a last resort option. One major reason for this has to do with RHEL's (and therefore CentOS's) policy of backporting. People look at a version number and assume it's old or has holes. They don't know that the fix they want has already been backported and patched into the current distribution release of the app. The combination of ignorance (intentional or otherwise) of the backporting policy and the desire people have to combine gentoo/solaris/unix logic to a particular distribution leads to problems. Each distribution has its own way of doing things. Whether it's deb, emerge, slackpack, or rpm, you should ALWAYS work within the framework provided by your distribution. > Installing from source can be done, but care has to be taken when installing > from source for a package already on your system. I don't install from > source unless the RPM-based program has a known problem, and the RPM-based > program is the latest official update. I make sure to change the name of > the program which I install from source, and always install in /usr/local. Yes, installing from source can be done. It's quick, but in the end it's far more time-consuming when things don't go as planned. It's not tough to write a spec and build an rpm for something, if you REALLY have to build it yourself. If it works for you, great. But it's bad advice for a mailing list for someone who is learning and potentially far less skilled than you. - Hide quoted text - -- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center

1 0

Kolab on Centos 4.x
by Denis Croombs 22 Jan '06

22 Jan '06

Does anyone have Kolab running on Centos 4.x. I have always used Centos 3.x and Kolab 1.0 todate, but cannot find a howto for Kolab V2.x Any clues/url's welcome. Thanks Denis

1 0

htdbm
by Paul R. Ganci 22 Jan '06

22 Jan '06

According to the man page for htdbm: NAME htdbm - Manipulate DBM password databases SYNOPSIS <snipped> htdbm -l [ -TDBTYPE ] <snipped> -l Print each of the usernames and comments from the database on stdout. yet when I execute htdbm I am finding that the output of the command is going to stderr not stdout. I have proved this by trying the following two commands: $ htdbm -l -TDB passwords > junk; wc junk Dumping records from database -- ./passwords Username Comment <snipped> 0 0 0 junk $ /usr/bin/htdbm -l -TDB ./passwords >&junk; wc junk 28 37 1034 junk Note in the first command the output still goes to the screen despite the stdout redirect with ">". In the second command line I added the "&" ito redirect stderr to the file. This time note that there is no htdbm output to the screen and that the file junk now contains the expected data. This is clearly a bug. Does anyone know of a work around to this problem or where I can find a RPM for dbmmanage? -- Paul (ganci(a)nurdog.com)

2 2

Latest kde/tetex updates fail on my attempts. Is it me or ...?
by William L. Maltby 22 Jan '06

22 Jan '06

Trying to apply the latest updates to an Athalon base fully updated CentOS 4.2. In the past used the update process kicked off by clicking the hand-dandy red icon. This failed, so I tried yum. Somewhere in the process, it complained that there was no GPG key for the lame libraries (IIRC, everything's a little hazy after all the Googling trying to fix this). Anyway, tried "yum update", same problem (I think). Tried importing some GPG keys that I thought were from CentOS, tried rm -rf on the cache, tried "yum clean headers" and "yum clean packages" (suspecting temporarily bad mirrors?), etc. Reread *in toto* the yum guide again, googled for hours, which has caused the observed hazing of the cornea and glazing of countenance. The rhn config file is out-of-box stock, but I've added the extras, kb and such to the repos directory. All this has worked in the past. Caveat: I manually installed mplayer on the system before I learned enough to realize it is available from the other repositories. I've not yet corrected the situation, which I suspect is the underlying cause of the 1st error regarding the GPG key for the lame libraries (which I could not resolve, btw). I have *not* googled for what I'm about to show, having given up for the week, except for this posting. Edited Yum output is shown below. Update goes into an endless install process after reporting sources are downloaded already. =========== Edited yum output: abbreviated ============= yum update kdelibs >&/tmp/errs error: rpmdbNextIterator: skipping h# 1875 Header V3 DSA signature: BAD, key ID 443e1821 error: rpmdbNextIterator: skipping h# 1553 Header V3 DSA signature: BAD, key ID 443e1821 error: rpmdbNextIterator: skipping h# 1875 Header V3 DSA signature: BAD, key ID 443e1821 ==== 8 more of above and many other DSA keys once or more each ==== <snipped a hundred or more?> Error: Missing Dependency: perl(File::Basename) is needed by package kdelibs Error: Missing Dependency: perl >= 0:5.000 is needed by package kdelibs Error: Missing Dependency: perl(Getopt::Long) is needed by package kdelibs Error: Missing Dependency: perl(strict) is needed by package kdelibs Error: Missing Dependency: perl(Data::Dumper) is needed by package kdelibs Error: Missing Dependency: /usr/bin/perl is needed by package kdelibs Error: Missing Dependency: libcom_err.so.2 is needed by package kdelibs Error: Missing Dependency: perl(File::Path) is needed by package kdelibs Error: Missing Dependency: perl(vars) is needed by package kdelibs Error: Missing Dependency: perl(Exporter) is needed by package perl- Devel-Carp Error: Missing Dependency: qt-devel >= 1:3.3.3 is needed by package kdelibs-devel Setting up Update Process Setting up repositories Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package kdelibs.i386 6:3.3.1-3.14 set to be updated --> Running transaction check --> Processing Dependency: perl(File::Basename) for package: kdelibs --> Processing Dependency: perl >= 0:5.000 for package: kdelibs --> Processing Dependency: perl(Getopt::Long) for package: kdelibs --> Processing Dependency: perl(strict) for package: kdelibs --> Processing Dependency: perl(Carp) for package: kdelibs --> Processing Dependency: perl(Data::Dumper) for package: kdelibs --> Processing Dependency: kdelibs = 6:3.3.1-3.11 for package: kdelibs- devel --> Processing Dependency: /usr/bin/perl for package: kdelibs --> Processing Dependency: libcom_err.so.2 for package: kdelibs --> Processing Dependency: perl(File::Path) for package: kdelibs --> Processing Dependency: perl(vars) for package: kdelibs --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package kdelibs-devel.i386 6:3.3.1-3.14 set to be updated ---> Package perl-Devel-Carp.noarch 0:0.04-1.2.el4.rf set to be updated --> Running transaction check --> Processing Dependency: perl(File::Basename) for package: kdelibs --> Processing Dependency: perl >= 0:5.000 for package: kdelibs --> Processing Dependency: perl(Getopt::Long) for package: kdelibs --> Processing Dependency: perl(strict) for package: kdelibs --> Processing Dependency: perl(Data::Dumper) for package: kdelibs --> Processing Dependency: perl(Exporter) for package: perl-Devel-Carp --> Processing Dependency: openssl-devel for package: kdelibs-devel --> Processing Dependency: /usr/bin/perl for package: kdelibs --> Processing Dependency: libcom_err.so.2 for package: kdelibs --> Processing Dependency: qt-devel >= 1:3.3.3 for package: kdelibs- devel --> Processing Dependency: perl(File::Path) for package: kdelibs --> Processing Dependency: perl(vars) for package: kdelibs --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package openssl-devel.i586 0:0.9.7a-43.4 set to be updated --> Running transaction check --> Processing Dependency: perl(File::Basename) for package: kdelibs --> Processing Dependency: perl >= 0:5.000 for package: kdelibs --> Processing Dependency: perl(Getopt::Long) for package: kdelibs --> Processing Dependency: perl(strict) for package: kdelibs --> Processing Dependency: perl(Data::Dumper) for package: kdelibs --> Processing Dependency: perl(Exporter) for package: perl-Devel-Carp --> Processing Dependency: /usr/bin/perl for package: kdelibs --> Processing Dependency: libcom_err.so.2 for package: kdelibs --> Processing Dependency: qt-devel >= 1:3.3.3 for package: kdelibs- devel --> Processing Dependency: perl(File::Path) for package: kdelibs --> Processing Dependency: perl(vars) for package: kdelibs --> Finished Dependency Resolution TIA for any help, Bill

1 0

← Newer
1
...
10
11
12
13
14
15
16
...
34
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss January 2006