gmane.linux.centos.general

Re: compiling python

Phil Schaffner — 2012-05-25T11:52:27

Rita wrote on 05/25/2012 06:29 AM:

Some advice on python 2.7 from the list archives:

http://lists.centos.org/pipermail/centos/2012-April/125174.html
http://lists.centos.org/pipermail/centos/2012-May/125808.html

Phil

Re: compiling python

John Doe — 2012-05-25T11:42:41

From: Rita <rmorgan466-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>



Read the file README from the python tar.gz file.
Use "--prefix".

JD

Re: biggest disk partition on 5.8?

Peter Kjellström — 2012-05-25T10:36:02

...
...
...
...

This is the problem, various filesystems issues are irrelevant. sfdisk only 
uses "the old" msdos type partition table and this does not support >2T 
devices. It is unfortunate that it lacks proper error checking and warnings...

You should do one of:

 1) don't use partitioning (mkfs directly on /dev/sdb)
 2) use LVM (pvcreate /dev/sdb ...)
 3) use a GPT type partition table (parted /dev/sdb or similar)

After this you'll have to tackle the current 16T limit for ext4 and other 
filesystem related oddities..

/Peter
_______________________________________________
CentOS mailing list
CentOS-IFYaIzF+flcdnm+yROfE0A< at >public.gmane.org
http://lists.centos.org/mailman/listinfo/centos

compiling python

Rita — 2012-05-25T10:29:52

Hello,

I would like to compile python 2.7.3 for centos and was wondering if there
were any instructions I should follow. I would like to keep the standard
python the way it is. I would like to compile to /opt. Any tips or ideas
would be much appreciated.

Re: openldap mmr + heartbeat hot standby

Benjamin Hackl — 2012-05-25T08:22:09

Dear Wessel,

I'd do the following.

give both servers a static non changing IP:

ldapA.yourdomain.tld, e.g. 10.0.0.1 on eth0
ldapB.yourdomain.tld, e.g. 10.0.0.2 on eth0

These two IPs will always be the same. You can access ldapA or ldapB
anytime via it's designated name.

For failover, use an alias:

ldap.yourdomain.tld, e.g. 10.0.0.3 on eth0:0 on the active node

Don't tell heartbeat of openldap and everything should be good.


Brgds

Re: Installing CIFS on CentOS4

Benjamin Hackl — 2012-05-25T07:58:57

Dear Jeff,

On Thu, 24 May 2012 15:16:13 -1000
Jeff Sadino <jsadino.queens-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


You can try the sernet samba repositories.

http://www.sernet.de/en/
http://ftp.sernet.de/pub/samba/3.6/centos/4/sernet-samba.repo

There are packages for various samba versions.

Brgds

Re: biggest disk partition on 5.8?

Warren Young — 2012-05-25T02:16:49

ext4 is limited to 16 TB.

Use xfs instead.  I explain how here:

http://unix.stackexchange.com/questions/29078/

Installing CIFS on CentOS4

Jeff Sadino — 2012-05-25T01:16:13

Hello,

I have a CentOS4 install and I am trying to mount a Windows Server 2008
folder.  When I use this command:
mount -t cifs //10.1.1.17/Org/MR\ Ops/ test, it only mounts the Org folder.
 When I try the same thing on a newer computer (Fedora 15), it mounts all
the way to MR Ops.  So I am pretty sure that my cifs file needs to be
updated, but I am having a really hard time doing this.  I updated to the
newest cif available for CentOS 4.9, but that still is not new enough.  Can
anyone tell me how to install the newer cifs on my CentOS 4?

Thank you,
Jeff Sadino

Re: google.repo

Phil Schaffner — 2012-05-25T00:05:32

fred smith wrote on 05/24/2012 07:27 PM:

# yum --disablerepo \* --enablerepo google-chrome list available

Loaded plugins: fastestmirror, priorities, refresh-packagekit

Loading mirror speeds from cached hostfile

Available Packages

google-chrome-beta.i386            20.0.1132.17-138701        google-chrome

google-chrome-stable.i386          19.0.1084.52-138391        google-chrome

google-chrome-unstable.i386        21.0.1145.0-138079         google-chrome

# cat /etc/yum.repos.d/google-chrome.repo

[google-chrome]

name=google-chrome

baseurl=http://dl.google.com/linux/chrome/rpm/stable/i386

enabled=1

gpgcheck=1

gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub

# rpm -q google-chrome-beta centos-release

google-chrome-beta-17.0.963.46-119351.i386

centos-release-6-2.el6.centos.7.i686


Phil

Re: Third party repo differences (was: Re: Repositories inCentOS 5.8)

Lamar Owen — 2012-05-25T00:00:37

Yep, it sure is. Forward/backward compatibility is almost entirely in the hands of the upstream projects (upstream from Red Hat). Some do that kindof thing well; others do not. Open source not only gives choice to the user, but also transfers the responsibility for choosing wisely to the user making the choice.

The one that has bitten me the hardest is xrdp. It will bite harder once a release based on FreeRDP rather than rdesktop is released out of git. The compatibility depends entirely on the package's upstream policies, developers, and stage of development (xrdp isn't out of beta, after all).

Likewise amavisd-new. It's not rare to have issues, and lots of people have had them, thus my cautions. Not trying to scare anyone off from any third party repository; just want to give information that allows people to make informed decisions, and show people how I at least arrived at my conclusions that work for me with my particular setup; what my particular setup is isn't the important thing, it's how and why I got there that I consider potentially useful to others.

At the moment both EPEL and RPMforge are on a 2.6.x amavisd-new; 2.7 makes some changes in the AM.PDP protocol that can break, for instance, amavisd-milter (distinct from the much less useful amavis-milter). Neither repo has amavisd-milter, so that compatibility issue may not show up except to those who actually use amavisd-milter instead of the much less useful amavis-milter.

I'll step out on a limb here and generalize somewhat; I would think that most CentOS users use at least one third-party repository, if the traffic on this list is any indication (and, again, I reserve the right to be wrong). So knowing how to properly determine how to use those repos (which was the OP's question, after all) is very useful indeed, IMO.

And, again, FWIW, HTH, IMHO, YMMV, etc.

Re: google.repo

Jesus del Valle — 2012-05-24T23:39:16

Hi. I think to remember that I went to Google's website (with Firefox on a
CentOS 6.2 desktop) and I either searched for google chrome or Google
suggested it to me.
Regards,
Jesus

Re: google.repo

fred smith — 2012-05-24T23:27:18

Where do you find a Chrome package that works on Centos? Google seems
to provide only Fedora, not Centos, binaries. All I can find for
Centos is Chromium.

Fred

Re: Tomcat7

Jesus del Valle — 2012-05-24T22:58:24

Hi. I cannot help you with a repository, however I have been
installing/upgrading tomcat for a while now. I wrote the script I follow
here:
http://www.geilthings.com/wiki/Tomcat
Regards,
Jesus

Re: google.repo

2012-05-24T20:34:46

Ewww... you mean I have to d/l the chrome rpm, yum localinstall it, and
*then* it creates google.repo? That's *ugly*, if true. And, of course,
there's no way to get support. I can't tell if I have to create a google
email account (which I don't want) to get into the support groups, and I
don't see any way to just send an email to any kind of support.

       mark

Re: google.repo

Daniel De Marco — 2012-05-24T20:21:04

* m.roth-x6lchVBUigD1P9xLtpHBDw< at >public.gmane.org <m.roth-x6lchVBUigD1P9xLtpHBDw< at >public.gmane.org> [05/24/2012 15:58]:

you can download the google-chrome rpm from their website.
It installs a cron job that runs daily and creates and makes sure the
/etc/yum.repos.d/google.repo is correct. 

Daniel.

Re: google.repo

Steve Clark — 2012-05-24T20:11:00

Don't remember where I found it but....
[root< at >sclark66 ~]# less /etc/yum.repos.d/google-chrome.repo
[google-chrome]
name=google-chrome
baseurl=http://dl.google.com/linux/chrome/rpm/stable/i386
enabled=1
gpgcheck=1

google.repo

2012-05-24T19:58:55

This is annoying. I've got a user who needs chrome installed. I google,
and find there's a google.repo. I rpm --import the signing key... and
cannot find *where* on google.com I can install their own repo from. Every
hit that looks even vaguely close tells me "edit
/etc/yum.repos.d/google.repo.

I don't want to manually create one, I want *theirs*.

Clues for the poor?

        mark

Re: Third party repo differences (was: Re: Repositories in CentOS 5.8)

2012-05-24T19:34:09

Yup - that drives me crazy, when someone's put a dependency on an *exact*
rev of a library, rather than >=.

And Lamar, that was a serious bit of research. Thanks for the job.

        mark

_______________________________________________
CentOS mailing list
CentOS< at >centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: Third party repo differences (was: Re: Repositories in CentOS 5.8)

Les Mikesell — 2012-05-24T19:26:02

Yes, you are right to bring it up, but I don't think it should scare
people off.  You just have to pay attention.



But many, probably most of those cases are revs with forward/backward
compatibility.  It's hard to generalize about that, though.  Even in
the scalpel case you mentioned the up-rev lib was likely compatible
but just specified as requiring an exact version in the spec file.
And on the other side there are things like viewvc that are at the
same rev in epel and rpmforge but have slightly different and
incompatible configurations (and there is a reason I know that...).

Third party repo differences (was: Re: Repositories inCentOS 5.8)

Lamar Owen — 2012-05-24T19:09:35

Probably so, and I know how to do that, but I wasn't illustrating a specific workaround, just illustrating the problem. Technically, once you rebuild a package yourself you have become yet another third party repository, even if it isn't yummable, and you'll still have to pin the locally built and installed version to prevent the other repo from updating that package. I have several locally rebuilt packages on that same system for other purposes, but that wasn't what I was illustrating.

It's only rare if you don't hit it.

After writing that sentence, I started wondering just how rare it might be, and could I throw a few lines of shell together to find out how rare it might or might not be. So I dug a little deeper. And it makes a really good exercise while taking a lunch break, so I decided to try to find out.

Since yum-utils does contain the interesting repodiff utility, I ran it, with interesting and voluminous results. I took the output of repodiff ran against the baseurls of EPEL and RPMforge (using the -a to specify arches instead of taking the default of running against source packages), pulled out the list of updated packages, removed the version, release, and tags with a combination of cut, sed, and a few manual edits, and ran repoquery against both EPEL and RPMforge for the list (948 packages where the name is the same but the EVR was different), cut the resulting lists at the colon epoch separator, dropped the release, arch, dist, and repo tags from the versions, and compared the two lists of version numbers alone.

Now, this is a snapshot in time, that is, the time I ran the repodiff and the repoquery commands, and things can change, and mirrors do change over time, especially with large repositories like these two. And I didn't run this on a CentOS 5.8 box, but an upstream EL6 box, so time for a subject line change. I have CentOS 6 boxes here, but none of them have both EPEL and RPMforge enabled, but my upstream EL6 box does.

I found, first of all, two packages that RPMforge has in both a i386/i686 and a .noarch form: facter and perl-AnyEvent; in both cases EPEL had but one package. So I dropped the oldest version of those two in RPMforge so that I could do a straight version-to-version comparison.

A simple side-by-side diff of just the version numbers produced 418 differences (424 lines of diff, twelve of which were marked with < and > instead of |, so I subtracted half of those). Manually reading through the diff, I found one difference where the version in one repo was 1.66.001 and in the other it was 1.66001, dropping a period, so that makes 417 packages where the name is the same, but the version is different. Some differences were small, some not so small.

Some differences are such that the epoch was different; I didn't do a count on those, since that's not an upstream version difference, but a packaging version difference. I found that when I was looking for why the EPEL list had two fewer lines than the RPMforge list.

The bottom line: out of the about 6,000 packages in EPEL, there are 7% or so that have the same name but a different version in RPMforge; out of the about 4,400 (4,381 listed by yum repolist) package in RPMforge, there are 9.5% or so that have the same name but a different version in EPEL. If anything you are running relies on any of those 417 packages, you have a potential for problems.

So, it's not rare.

And while I could share those lists, they will be out of date by tonight, and most certainly by when you might need or want them. Since there was a manual edit portion involved due to repodiff not outputting the epoch and its perfectly placed colon separator, it isn't very scriptable at this level.

I'm sure repodiff could be modified to use the actual version numbers and names stored in the yum and rpm databases and ignoring the epoch, release, arch, dist, and repo tags. Of course, EPEL doesn't have a repo tag, so you have to remember that, too. Then you'd have another tool to help you deal with repo collisions. Perhaps such a tool has been written; I don't know about it. The repodiff tool as it stands is made for other purposes than this, and has to be shoehorned in to do this sort of comparison.

Again, YMMV, FWIW, HTH, and all that.

And I of course as always reserve the right to be wrong.

Re: [OT] Cannot boot into GUI after Video Driver isInstalled

Earl Ramirez — 2012-05-24T17:57:32



Thanks Akemi,

I have installed Fedora and Ubuntu on a USB drive and I was able to get
bumblebee to work, however I was not so successful when I tried it on
CentOS 6.2. I used the packages from ELRepo and they were installed
successfully but it did no work from the get go. Modify the config file and
I will still boot up with the intel driver.