Re: [CentOS] Re: Hard disk recomendation for a software raid 5 array. Does Linux Software Raid support/interacts well with TLER enabled disks.
> Not necessarily from different vendors as much as from different build > lots, etc. > > The theory is ... items build from the same components at the same time > and the same place should fail/EOL at about the same time (all things > being equal). > > In practice, I have not seen that. If you are concerned about it, > getting drives from different factories or lots (but the same > manufacturer) should be OK. > I have seen 18 out of 20 gone in 2 weeks period. Those were 20 PCs manifactured by IBM. I guess it must have been the famous Deathstar bug. I am not sure if I can buy disks of different lots here(I live in Bulgaria, where a rumour is spread, that hard disk on sale are from lots that have failed the tests for robustness). What I can do is to spread the purchase in 4 weeks period - buying each week a disk. I am not in a hurry on this project. However I wanted to do this in a 2 weeks period - buying each week one Barracuda and one Hitachy. As I intend to use software raid which in theory can even work with volumes on different channel types - like using one external USB disk and one internal ATA disk, I was not expecting problems mixing different vendors disks. BTW According to O'relly's book on linux hardware raid, the only reason to choose disks from the same vendor is not to jeopardise performance by combining one less performant disk with a more performant one. As this is a rsync server - performance is not a requirement. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
Rex Dieter wrote:
> Dag Wieers wrote:
>
>> On Fri, 27 Jul 2007, JC Júnior wrote:
>>
>>> I received a message about EPEL repository, I would like to know if this
>>> repo is long term support too.
>> Let me add that an effort to make sure EPEL is compatible with RPMforge
>> failed as EPEL wants to become the only repository for RHEL and there is
>> no interest to consider current RPMforge users.
> ...
>> EPEL refused the repotag, so one cannot easily identify where a package
>> comes from and mixing repositories becomes harder. Since compatibility is
>> a 2 way interaction and EPEL shows no interest, it is certain that mixing
>> EPEL with other repositories may break something.
>
> Interesting you say that. It's quite a stetch from "no repotags" to
> conclude "EPEL has no interest" in compatibility.
>
> In fact, epel (and fedora) repo is, by design and policy, supposed to be
> compatible and considerate of other repos, e.g. most notably,
> http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration
> (among other project policy documents).
>
> When I posted the aforementioned repository collaboration document to the
> rpmforge list(s) for comment, it received none.
As much as I don't want the CentOS list to become the place where EPEL
cooperation is discussed, it is obvious what their policy is.
There is talk about cooperation and collaboration, however whenever Axel
or Dag made any kind of suggestions on the EPEL list, they were not
given very much "real" consideration. Certainly not the consideration
that the current EXPERTS on 3rd party repositories should get. I found
this especially troubling since RPMForge (and it's predecessors) and
ATRPMS saw the 3rd party repo need and filled that need before Fedora
even existed. The replies these repo maintainer where ... that is not
how Fedora does things. EPEL is Fedora's project to do with as they see
fit, so this is not really a problem. It did leave a bitter taste in my
mouth on a personal level though.
There is also now this posting on the EPEL message list and wiki too:
Message list:
https://www.redhat.com/archives/epel-devel-list/2007-July/msg00239.html
Wiki:
http://fedoraproject.org/wiki/EPEL/FAQ#head-9ddfe705d75fe928468e3c64c1135de7cb187860
(the link does not seem to work directly ... look for "Section 2",
"subsection 4", entitled "What about compatibility with other third
party repositories?")
There is absolutely nothing wrong with EPEL doing whatever they want,
but their policy on collaboration is really that they are the one add-on
repository that all should use. Their reckoning is that all people who
want to use or contribute packages should do so within their framework
and guidelines. I'm sorry, but that is _NOT_ how it has to be.
Some other shortcomings have also already been addressed, but not
resolved, on the EPEL list (and Red Hat is taking action to solve some
of them {to give credit where credit is due}).
Issues like, What happens when someone with the "Desktop Product" tries
to install foo, but foo requires bar, and bar is only in "Server
Product" and not in "Desktop Product". There are only really 3 answers
to this issue (well, 4 if you count use the CentOS package) and they are:
1. EPEL can provide packages in a separate part of the repo to act as
glue if there are package differences between the least populated EL
project (ie, Red Hat Desktop) and the most populated project (ie, RHEL
AS). This does not need to be everything to upgrade (Red Hat would not
like that) ... just unmet dependences for packages in EPEL. EPEL
recently worked with CentOS to do just that with all the requirements to
get yum and it's requirements into the EPEL repos for EL4. It is not
quite as easy though if RHEL is involved (they can't upgrade desktop
products to server products).
2. EPEL can say to users of the least populated project ... sorry, this
doesn't work for you. They might also just not put things in the repo
at all if there are unmet dependencies between versions.
3. EPEL could just create a separate repo where all deps are met for
the desktop products. This would be a subset of packages from the EPEL
server repo. (The CentOS policy of putting all the desktop and server
packages in one repo is looking fairly good now, isn't it).
4. The people who need dependencies solved can just use a CentOS
package if they can't get a dependency for something in EPEL.
Again, I am not telling anyone to not use EPEL. I personally know and
like many of the people who are maintaining packages in EPEL and it will
be a great asset to the EL community. Dag Wieers, Dries Verachtert and
Axel Thimm are also great assets to the EL community.
What users can do is use the yum priorities plugin (yum-priorities in
CentOS-5, yum-plugin-priorities in CentOS-4) and you can then get more
than 1 repo to play together. For some complex installs, you may also
need to use "exclude=" in your higher priority repos to get those filled
by your l
Re: [CentOS] Re: Hard disk recomendation for a software raid 5 array. Does Linux Software Raid support/interacts well with TLER enabled disks.
Alexander Georgiev wrote: >> Not necessarily from different vendors as much as from different build >> lots, etc. >> >> The theory is ... items build from the same components at the same time >> and the same place should fail/EOL at about the same time (all things >> being equal). >> >> In practice, I have not seen that. If you are concerned about it, >> getting drives from different factories or lots (but the same >> manufacturer) should be OK. >> > > I have seen 18 out of 20 gone in 2 weeks period. Those were 20 PCs > manifactured by IBM. I guess it must have been the famous Deathstar > bug. > > I am not sure if I can buy disks of different lots here(I live in > Bulgaria, where a rumour is spread, that hard disk on sale are from > lots that have failed the tests for robustness). > > What I can do is to spread the purchase in 4 weeks period - buying > each week a disk. I am not in a hurry on this project. > > However I wanted to do this in a 2 weeks period - buying each week one > Barracuda and one Hitachy. As I intend to use software raid which in > theory can even work with volumes on different channel types - like > using one external USB disk and one internal ATA disk, I was not > expecting problems mixing different vendors disks. > > BTW According to O'relly's book on linux hardware raid, the only > reason to choose disks from the same vendor is not to jeopardise > performance by combining one less performant disk with a more > performant one. > > As this is a rsync server - performance is not a requirement. The real issue with different vendors on hardware RAID controllers are things like firmware incompatibility. Combining different vendors adds different complexities ... where performance is one problem, stability is the problem I would fear if using different vendors in the same array. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
On Sun, Jul 29, 2007 at 03:29:11PM -0500, Rex Dieter wrote: > Dag Wieers wrote: > > > On Fri, 27 Jul 2007, JC Júnior wrote: > > > >> I received a message about EPEL repository, I would like to know if this > >> repo is long term support too. > > > > Let me add that an effort to make sure EPEL is compatible with RPMforge > > failed as EPEL wants to become the only repository for RHEL and there is > > no interest to consider current RPMforge users. > ... > > EPEL refused the repotag, so one cannot easily identify where a package > > comes from and mixing repositories becomes harder. Since compatibility is > > a 2 way interaction and EPEL shows no interest, it is certain that mixing > > EPEL with other repositories may break something. > > Interesting you say that. It's quite a stetch from "no repotags" to > conclude "EPEL has no interest" in compatibility. It's not really about the topic itself, but how it was handled. And the fact that this topic was a rather effortless thing epel could had agreed to makes the non-collaboration just more obvious. The repotag system was a common loosely agreed on interrepo coexistance mechanism with one weak spot: It takes one big bad repo to destroy it. And that's what happened. > In fact, epel (and fedora) repo is, by design and policy, supposed to be > compatible and considerate of other repos, e.g. most notably, > http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration > (among other project policy documents). > > When I posted the aforementioned repository collaboration document to the > rpmforge list(s) for comment, it received none. But you also received close to none comments from EPEL itself. In fact many 3rd party repo maintainers liked Tim Jackson's original draft (which you placed unaltered in the wiki), but not even he himself likes what this document mutated to: https://www.redhat.com/archives/epel-devel-list/2007-May/msg00049.html Maybe the original draft will be picked up by other projects to signal their mode of collaboration, let's see. It certainly was in thge spirit of the existing 3rd party repos. Furthermore there have been many quotes in IRC and mail of various current EPEL steering members that they "aim higher" than the existing repos or see EPEL as the only repo long term and the like. On the positive side one must say that Max Spevack was interested in a collaboration between EPEL and the rest of the world, but he's not forcing it onto the EPEL people. -- Axel.Thimm at ATrpms.net pgpzYoVX6xNFg.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
Axel Thimm wrote: Maybe the original draft will be picked up by other projects to signal their mode of collaboration, let's see. It certainly was in thge spirit of the existing 3rd party repos. Maybe you should cut them a little slack considering that they are not so experienced as the rest of you... Furthermore there have been many quotes in IRC and mail of various current EPEL steering members that they "aim higher" than the existing repos or see EPEL as the only repo long term and the like. As long as there are policies about what can be in a repo or who can put it there, there can never be just one repo. Everyone should understand that by now. On the positive side one must say that Max Spevack was interested in a collaboration between EPEL and the rest of the world, but he's not forcing it onto the EPEL people. I've never quite understood why you don't just give the packages different names if they already exist in the disto-supported repo but there might be some reason to want your version instead (or besides). -- Les Mikesell [EMAIL PROTECTED] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
On Mon, Jul 30, 2007 at 07:51:45AM -0500, Les Mikesell wrote: > Axel Thimm wrote: > > >Maybe the original draft will be picked up by other projects to > >signal their mode of collaboration, let's see. It certainly was in > >thge spirit of the existing 3rd party repos. > > Maybe you should cut them a little slack considering that they are not > so experienced as the rest of you... Experienced in what? Hidden agendas and politics? I'm not experienced in that really. Please check the epel list where these topics were discussed over *months* and often revealed their political background instead of a "lack of experience". > >Furthermore there have been many quotes in IRC and mail of various > >current EPEL steering members that they "aim higher" than the existing > >repos or see EPEL as the only repo long term and the like. > > As long as there are policies about what can be in a repo or who can put > it there, there can never be just one repo. Everyone should understand > that by now. > > >On the positive side one must say that Max Spevack was interested in a > >collaboration between EPEL and the rest of the world, but he's not > >forcing it onto the EPEL people. > > I've never quite understood why you don't just give the packages > different names if they already exist in the disto-supported repo but > there might be some reason to want your version instead (or besides). First of all there is no distro supported repo in this context, we're talking about 3rd party repos. Next, what use would it be to give a different name? E.g. xemacs vs xemacs-myrepo? The two packages would conflict so xemacs-myrepo has to either Conflict: or Obsolete:/Provide: with the standard name, and the end result is a worse setup than having the proper name since there will be no way back to the unadorned name unless the xemacs package starts obsoleting/providing the alternate name as well. So there is no real improvement in obfuscating names. And I didn't even mention dependent packages that would break with perl-Bar-myrepo and libfoo-devel-myrepo instead of perl-Bar and libfoo-devel. ATM we'll just live and let live, and there will not be any one-side effort to rectify any compatibility issues EPEL created. It's their mess, they'll have to clean it up. -- Axel.Thimm at ATrpms.net pgpmt6EDwvj9t.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] incredible heartbeat 2.X depencies
# activating extras repo # issuing "yum install heartbeat" # got : (...tons of depedencies resolution...) ttmkfdir-3.0.9-20.el4.i38 100% |=| 6.6 kB00:00 ---> Package ttmkfdir.i386 0:3.0.9-20.el4 set to be updated --> Running transaction check Dependencies Resolved = Package Arch Version RepositorySize = Installing: heartbeat i386 2.0.7-1.c4 extras1.8 M Installing for dependencies: atk i386 1.8.0-2 base 170 k chkfontpath i386 1.10.0-2 base 13 k cpp i386 3.4.6-8 base 1.6 M curli386 7.12.1-11.el4base 230 k fontconfig i386 2.2.3-7.centos4 base 117 k fonts-xorg-base noarch 6.8.2-1.EL base 7.3 M gnutls i386 1.0.20-3.2.3 base 259 k gtk2i386 2.4.13-22base 4.3 M heartbeat-pils i386 2.0.7-1.c4 extras124 k heartbeat-stonith i386 2.0.7-1.c4 extras223 k libglade2 i386 2.4.0-5 base 91 k libidn i386 0.5.6-1 base 169 k libjpeg i386 6b-33base 127 k libtiff i386 3.6.1-12 base 257 k nx i386 1.5.0-1.centos4 extras2.5 M pango i386 1.6.0-9 base 271 k pygtk2 i386 2.4.0-1 base 639 k switchdesk noarch 4.0.6-3 base 13 k ttmkfdiri386 3.0.9-20.el4 base 44 k xinitrc noarch 4.0.14.3-1 base 26 k xorg-x11i386 6.8.2-1.EL.18base 13 M xorg-x11-Mesa-libGL i386 6.8.2-1.EL.18base 383 k xorg-x11-Mesa-libGLUi386 6.8.2-1.EL.18base 448 k xorg-x11-font-utils i386 6.8.2-1.EL.18base 307 k xorg-x11-libs i386 6.8.2-1.EL.18base 2.7 M xorg-x11-tools i386 6.8.2-1.EL.18base 516 k xorg-x11-xauth i386 6.8.2-1.EL.18base 284 k xorg-x11-xfsi386 6.8.2-1.EL.18base 319 k Transaction Summary = Install 29 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 38 M 38Mb and xorg-x11 seems a bit too much for a "simple" heartbeat, no ? -- Martin Hamant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] incredible heartbeat 2.X depencies
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Martin Hamant > Sent: Monday, July 30, 2007 9:29 AM > To: centos@centos.org > Subject: [CentOS] incredible heartbeat 2.X depencies > > # activating extras repo > # issuing "yum install heartbeat" > > # got : > > (...tons of depedencies resolution...) Yes, heartbeat package currently includes gui and cli parts which makes it a thick install... :-( Hopefully in the future they will split it into 2. -Ross __ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] incredible heartbeat 2.X depencies
Martin Hamant wrote: > # activating extras repo > # issuing "yum install heartbeat" > > # got : > > (...tons of depedencies resolution...) > ttmkfdir-3.0.9-20.el4.i38 100% |=| 6.6 kB00:00 > > ---> Package ttmkfdir.i386 0:3.0.9-20.el4 set to be updated > --> Running transaction check > > Dependencies Resolved > > = > Package Arch Version RepositorySize > = > Installing: > heartbeat i386 2.0.7-1.c4 extras1.8 M > Installing for dependencies: > atk i386 1.8.0-2 base 170 k > chkfontpath i386 1.10.0-2 base 13 k > cpp i386 3.4.6-8 base 1.6 M > curli386 7.12.1-11.el4base 230 k > fontconfig i386 2.2.3-7.centos4 base 117 k > fonts-xorg-base noarch 6.8.2-1.EL base 7.3 M > gnutls i386 1.0.20-3.2.3 base 259 k > gtk2i386 2.4.13-22base 4.3 M > heartbeat-pils i386 2.0.7-1.c4 extras124 k > heartbeat-stonith i386 2.0.7-1.c4 extras223 k > libglade2 i386 2.4.0-5 base 91 k > libidn i386 0.5.6-1 base 169 k > libjpeg i386 6b-33base 127 k > libtiff i386 3.6.1-12 base 257 k > nx i386 1.5.0-1.centos4 extras2.5 M > pango i386 1.6.0-9 base 271 k > pygtk2 i386 2.4.0-1 base 639 k > switchdesk noarch 4.0.6-3 base 13 k > ttmkfdiri386 3.0.9-20.el4 base 44 k > xinitrc noarch 4.0.14.3-1 base 26 k > xorg-x11i386 6.8.2-1.EL.18base 13 M > xorg-x11-Mesa-libGL i386 6.8.2-1.EL.18base 383 k > xorg-x11-Mesa-libGLUi386 6.8.2-1.EL.18base 448 k > xorg-x11-font-utils i386 6.8.2-1.EL.18base 307 k > xorg-x11-libs i386 6.8.2-1.EL.18base 2.7 M > xorg-x11-tools i386 6.8.2-1.EL.18base 516 k > xorg-x11-xauth i386 6.8.2-1.EL.18base 284 k > xorg-x11-xfsi386 6.8.2-1.EL.18base 319 k > > Transaction Summary > = > Install 29 Package(s) > Update 0 Package(s) > Remove 0 Package(s) > Total download size: 38 M > > > 38Mb and xorg-x11 seems a bit too much for a "simple" heartbeat, no ? > That version of heatbeat is probably not the best one to use ... how about trying the 2.0.8 version in the testing repository (it has the heartbeat-gui split out). also, nx is not good, so whatever it supples should come from something else ... I am working right now with the Linux-HA project lead (Alan Robertson) to get version-2.1.2 out as soon as they release it. There was an install problem in 2.1.1 (not CentOS specific) ... however, there is a fairly well testing one here that might be better than 2.0.8 here: http://people.centos.org/~hughesjr/heartbeat/4/RPMS/ (or substitute 5 for 4 if necessary) Or wait 1-2 days for 2.1.2 ... we are REALLY close now :D Thanks, JOhnny Hughes signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] incredible heartbeat 2.X depencies
Le Mon, 30 Jul 2007 09:54:29 -0400 "Ross S. W. Walker" <[EMAIL PROTECTED]> écrivait: > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Martin Hamant > > Sent: Monday, July 30, 2007 9:29 AM > > To: centos@centos.org > > Subject: [CentOS] incredible heartbeat 2.X depencies > > > > # activating extras repo > > # issuing "yum install heartbeat" > > > > # got : > > > > (...tons of depedencies resolution...) > > > Yes, heartbeat package currently includes gui and cli parts which > makes it a thick install... :-( > > Hopefully in the future they will split it into 2. > > -Ross Thanks both of you Ross & Johnny, For instance I use 1.2.23cvs, and i was planning to upgrade :) I'll wait for 2.1.2 ! -- Martin Hamant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] kmod-drbd-smp (2.6.9-55.0.2.EL) has unknown symbols (kmod-drbd not).
Hi ! Not very blocking because the smp module loads perfectly. # yum --exclude=kmod-drbd*\plus\* install kmod-drbd Setting up Install Process Setting up repositories Reading repository metadata in from local files Excluding Packages in global exclude list Finished Reducing CentOS-4 - Plus to included packages only Finished Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package kmod-drbd.i686 0:0.7.24-1.2.6.9_55.0.2.EL set to be updated --> Running transaction check Dependencies Resolved = Package Arch Version RepositorySize = Installing: kmod-drbd i686 0.7.24-1.2.6.9_55.0.2.EL extras 472 k Transaction Summary = Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 472 k Is this ok [y/N]: y Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: kmod-drbd# [1/1] WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs unknown symbol _spin_unlock_irq WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs unknown symbol _spin_unlock WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs unknown symbol _spin_unlock_irqrestore WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs unknown symbol _spin_lock_irq WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs unknown symbol del_timer_sync WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs unknown symbol _spin_lock_irqsave WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs unknown symbol _spin_lock Installed: kmod-drbd.i686 0:0.7.24-1.2.6.9_55.0.2.EL Complete! # uname -a Linux *** 2.6.9-55.0.2.EL #1 Tue Jun 26 14:08:18 EDT 2007 i686 i686 i386 GNU/Linux # modprobe drbd FATAL: Error inserting drbd (/lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko): Invalid module format (PS: I think something really needs to be done with the --exclude / plus issue) -- Martin Hamant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] kmod-drbd (2.6.9-55.0.2.EL) has unknown symbols (kmod-drbd-smp not).
/!\ sorry, inverted smp and no-smp in the subject ! Le Mon, 30 Jul 2007 16:32:32 +0200 Martin Hamant <[EMAIL PROTECTED]> écrivait: > Hi ! > > Not very blocking because the smp module loads perfectly. > > # yum --exclude=kmod-drbd*\plus\* install kmod-drbd > Setting up Install Process > Setting up repositories > Reading repository metadata in from local files > Excluding Packages in global exclude list > Finished > Reducing CentOS-4 - Plus to included packages only > Finished > Parsing package install arguments > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Package kmod-drbd.i686 0:0.7.24-1.2.6.9_55.0.2.EL set to be > updated --> Running transaction check > > Dependencies Resolved > > = > Package Arch Version > RepositorySize > = > Installing: kmod-drbd i686 > 0.7.24-1.2.6.9_55.0.2.EL extras472 k > > Transaction Summary > = > Install 1 Package(s) > Update 0 Package(s) > Remove 0 Package(s) > Total download size: 472 k > Is this ok [y/N]: y > Downloading Packages: > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > Installing: kmod-drbd# > [1/1] WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs > unknown symbol _spin_unlock_irq > WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs unknown > symbol _spin_unlock > WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs unknown > symbol _spin_unlock_irqrestore > WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs unknown > symbol _spin_lock_irq > WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs unknown > symbol del_timer_sync > WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs unknown > symbol _spin_lock_irqsave > WARNING: /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko needs unknown > symbol _spin_lock > > Installed: kmod-drbd.i686 0:0.7.24-1.2.6.9_55.0.2.EL > Complete! > > # uname -a > Linux *** 2.6.9-55.0.2.EL #1 Tue Jun 26 14:08:18 EDT 2007 i686 i686 > i386 GNU/Linux > > # modprobe drbd > FATAL: Error inserting drbd > (/lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko): Invalid module format > > > (PS: I think something really needs to be done with the --exclude / > plus issue) > -- Martin Hamant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: SOLVED: Re: KStars on CentOS 4.4?
Lanny Marcus spake the following on 7/28/2007 5:36 AM: > On 27 July 2007, Scott Silva wrote: >> You can get Fedora 3 src rpms for Centos 4 and Fedora 6 srpms for >> Centos 5. Then it can be as simple as rpmbuild --rebuild bla- >> bla-.src.rpm. It can also be difficult if other dependencies creep in. >> But the rpmbuild process should warn you. > > Scott: Thank you again! I think I have the SRC RPMS for FC3 and FC6. > I will do some reading, about rpmbuild. Lanny You are very welcome! -- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] memory query
On 28 July 2007, simon wrote: > > I have recently installed centOS 5 on DELL pentium 2.7ghz (model > > optiplex GX270) and have 512 memory I received the CentOS 5.0 DVD today. ASAP, I will upgrade from 4.4. After that, I will let you know how 5.0 sees the available RAM, in the same box. The first place you need to look, is in the BIOS, to see how the box sees the RAM. If it doesn't see the RAM as available, CentOS won't either. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Problem maillog
Dear Friends, How I restart logrotate ? Because file /var/log/maillog doesn't rotate log. Thanks Adriano ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Problem maillog
Le Mon, 30 Jul 2007 12:55:57 -0300 Adriano Frare <[EMAIL PROTECTED]> écrivait: > Dear Friends, > > How I restart logrotate ? > > Because file /var/log/maillog doesn't rotate log. Hello, maillog rotation is done from /etc/logrotate.d/syslog. You can take a look in it. logrotate is started each day as a cron job /etc/cron.daily/logrotate. cheers -- Martin Hamant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
Axel Thimm wrote: Maybe the original draft will be picked up by other projects to signal their mode of collaboration, let's see. It certainly was in thge spirit of the existing 3rd party repos. Maybe you should cut them a little slack considering that they are not so experienced as the rest of you... Experienced in what? Hidden agendas and politics? I'm not experienced in that really. Please check the epel list where these topics were discussed over *months* and often revealed their political background instead of a "lack of experience". I meant experience with running a repo, but experience in trying to coordinate disparate policies is probably more relevant. It just isn't going to happen and everyone might as well recognize that up front. Next, what use would it be to give a different name? E.g. xemacs vs xemacs-myrepo? It would be very useful to me in any case where the versions differ. I like to know what I'm running and why. > The two packages would conflict so xemacs-myrepo has to either Conflict: or Obsolete:/Provide: with the standard name, and the end result is a worse setup than having the proper name since there will be no way back to the unadorned name unless the xemacs package starts obsoleting/providing the alternate name as well. If the package name makes the difference visible, can't I "yum remove xemacs-myrepo" and "yum install xemacs-otherrepo" depending on which I want to have installed? So there is no real improvement in obfuscating names. But there is an improvement if I can see and control what I install and understand the differences. The names are obfucated now since the same name can refer to any of several different things. And I didn't even mention dependent packages that would break with perl-Bar-myrepo and libfoo-devel-myrepo instead of perl-Bar and libfoo-devel. That's only a problem if you overwrite each other's files. Put them somewhere else. Yes, having files of the same name in different path locations can confuse people who don't understand that path order searches have been used since the invention of the tree structured directory to permit multiple versions of the same things to co-exist, but the concept isn't that difficult. It's just too bad the package managers didn't get it and had to go through contortions after realizing that there are things that people need to have multiple versions installed at the same time, like the kernel and architecture-dependent libraries. ATM we'll just live and let live, and there will not be any one-side effort to rectify any compatibility issues EPEL created. It's their mess, they'll have to clean it up. Live and let die, you mean - at least as far as the users are concerned. I don't think this issue has any solution other than separate namespaces. -- Les Mikesell [EMAIL PROTECTED] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Scripting a directory change on CentOS
This is probably a FAQ item but despite searching extensively with google I am unable to find an answerer to this question. Perhaps I am using the wrong words. In any case, at the risk of inducing some mirth at my ignorance, how can one script a cd command so that that the user remains in that directory when the script exits? I have to work with a long path to a project working directory and I would like to have a simple script called "current" which would produce the same effect as issuing this from the shell: cd ./very/long/path/to/obscurely/titled/project/directory I cannot seem to find anything that directly addresses this, other than to point out that shell scripts run in their own copy of the shell interpreter and so anything done to the PWD therein is local to the duration of the script. I could create a logical link from my home directory I suppose, but I desire a scripted solution. I really do not wish to program a utility to do this and I cannot believe that many people have not already addressed this desire with a straight forward answer. So if any of you have a simple to implement solution then could you share your answer with me? As I am a digest subscriber in addition to your answer to the list the favour of a direct reply is requested Sincerely, -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:[EMAIL PROTECTED] Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Scripting a directory change on CentOS
James B. Byrne wrote: > This is probably a FAQ item but despite searching extensively with google > I am unable to find an answerer to this question. Perhaps I am using the > wrong words. In any case, at the risk of inducing some mirth at my > ignorance, how can one script a cd command so that that the user remains > in that directory when the script exits? > > I have to work with a long path to a project working directory and I would > like to have a simple script called "current" which would produce the same > effect as issuing this from the shell: > > cd ./very/long/path/to/obscurely/titled/project/directory > > I cannot seem to find anything that directly addresses this, other than to > point out that shell scripts run in their own copy of the shell > interpreter and so anything done to the PWD therein is local to the > duration of the script. I could create a logical link from my home > directory I suppose, but I desire a scripted solution. > > I really do not wish to program a utility to do this and I cannot believe > that many people have not already addressed this desire with a straight > forward answer. So if any of you have a simple to implement solution then > could you share your answer with me? > > As I am a digest subscriber in addition to your answer to the list the > favour of a direct reply is requested > In this case the use of an alias is probably what you want ... alias current='cd /path' You can then type current at the command prompt can go there. You can put that command in your .bashrc with your other aliases as well to make it persistent across reboots. Thanks, Johnny Hughes signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Perl-related problem on rrdtool?
On CentOS 4.5, I have Cacti and Nagios installed. I'm trying to "glue" them together with a program called n2rdd but am having a problem that I wondering is Perl-related. When I run "tail /var/log/nagios/rra/n2rrd.log", I see lots of this sort of thing: server01: Missing template for "server01" service "check_ping" "/etc/n2rrd/templates/rra/ping.t" I have a ping.t template in that file path, but it's still not working. In fact, I did one exactly like the example in the instructions (step 7, example 1: http://n2rrd.diglinks.com/cgi-bin/trac.cgi/wiki/InstallationGuide) and then I copied that icmp.t template to ping.t While I don't expect a CentOS list to help me with a non-CentOS, perhaps someone can tell me if this is a "Perl on CentOS" issue. I'm relatively new to installs requiring Perl and assumed I was ready to go Perl-wise on this version of CentOS Thanks. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Scripting a directory change on CentOS
On Mon, July 30, 2007 13:02, Johnny Hughes wrote: > > In this case the use of an alias is probably what you want ... > > alias current='cd /path' > > You can then type current at the command prompt can go there. > > You can put that command in your .bashrc with your other aliases as well > to make it persistent across reboots. > > Thanks, > Johnny Hughes > and On Mon, July 30, 2007 13:06, Brent L. Bates wrote: > Instead of a script, how about a shell alias? In the csh shell, I'd > do > something like the following: > > alias cd_project"cd ./very/long/path/to/whatever" Thank you both ever so much. I would never have though of using an alias but that seems the sensible solution. Sincerely, -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:[EMAIL PROTECTED] Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] kmod-drbd (2.6.9-55.0.2.EL) has unknown symbols (kmod-drbd-smp not).
On 7/30/07, Martin Hamant <[EMAIL PROTECTED]> wrote: > > # uname -a > > Linux *** 2.6.9-55.0.2.EL #1 Tue Jun 26 14:08:18 EDT 2007 i686 i686 > > i386 GNU/Linux > > > > # modprobe drbd > > FATAL: Error inserting drbd > > (/lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko): Invalid module format What do you see with this command? /sbin/modinfo /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko Akemi ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Scripting a directory change on CentOS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James B. Byrne wrote: > This is probably a FAQ item but despite searching extensively with google > I am unable to find an answerer to this question. Perhaps I am using the > wrong words. In any case, at the risk of inducing some mirth at my > ignorance, how can one script a cd command so that that the user remains > in that directory when the script exits? > pushd newdir # at the beginning of the script popd # before exiting Alternately: curdir=$(pwd) # at the beginning of the script cd $curdir # before exiting For further information (and to find a list of the really useful features of the BASH shell) do: man bash Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFGrhn3CFu3bIiwtTARAmv6AJ4kb6VG4HSyj/aChZgzJ9M64PW8SwCfYHV6 kJhMc6RYuZVW7JXSpYOPczg= =I0qY -END PGP SIGNATURE- ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] kmod-drbd (2.6.9-55.0.2.EL) has unknown symbols (kmod-drbd-smp not).
On 7/30/07, Martin Hamant <[EMAIL PROTECTED]> wrote: > # uname -a > Linux *** 2.6.9-55.0.2.EL #1 Tue Jun 26 14:08:18 EDT 2007 i686 i686 > i386 GNU/Linux > > # modprobe drbd > FATAL: Error inserting drbd > (/lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko): Invalid module format What do you see with this command? /sbin/modinfo /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko Akemi I had the same unknown symbol errors when installing the x86_64 kmod-drbd modules from the centosplus repo. I resolved this myself by rebuilding the source RPM. -ken ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] kmod-drbd (2.6.9-55.0.2.EL) has unknown symbols (kmod-drbd-smp not).
On 7/30/07, Ken Price <[EMAIL PROTECTED]> wrote: > > On 7/30/07, Martin Hamant <[EMAIL PROTECTED]> wrote: > > > >> > # uname -a > >> > Linux *** 2.6.9-55.0.2.EL #1 Tue Jun 26 14:08:18 EDT 2007 i686 i686 > >> > i386 GNU/Linux > >> > > >> > # modprobe drbd > >> > FATAL: Error inserting drbd > >> > (/lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko): Invalid module format > > > > What do you see with this command? > > > > /sbin/modinfo /lib/modules/2.6.9-55.0.2.EL/extra/drbd.ko > > > > Akemi > > I had the same unknown symbol errors when installing the x86_64 > kmod-drbd modules from the centosplus repo. I resolved this myself by > rebuilding the source RPM. > > -ken Yes, I did, too. This is under investigation now. Akemi ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
On Mon, 30 Jul 2007, Les Mikesell wrote: ATM we'll just live and let live, and there will not be any one-side effort to rectify any compatibility issues EPEL created. It's their mess, they'll have to clean it up. Live and let die, you mean - at least as far as the users are concerned. I don't think this issue has any solution other than separate namespaces. Les Your issue belongs on another list -- the 'mark by nameing' the rpm's in a way obvious to a low sophistication user (rather than some checksum based method that does not exist) has been proposed and rejected already. sad, but still the case. We'll be having pain for this for years and years. See: https://www.redhat.com/archives/epel-devel-list/2007-June/msg00031.html Please read the archive and the back thread leading up to it. Several @redhat.com showed up to pack the gallery at the 'last chance' epel meeting which could have avoided this train wreck -- Russ Herrold highlighted extract 00:03 < knurd> | I'm wondering if we should try a different route: ask the FPC for a official statement if repotags are fine for them ... 00:05| we're not going to give that statement. 00:05 | just as an FYI ... 00:05 < knurd> | spot, ohh, I didn#t expect you would be around 00:05 < knurd> | spot, why? 00:05 < spot> | if you really want repotags vote on it, and we'll figure out how to implement them. ... 00:06 | its not our domain to decide whether they're ok or not, thats FESCo ... 00:06 < knurd> | spot, would you share your opnion on repotags? 00:07 | I don't know what technical problem they solve. 00:07 | spot: none 00:07 | They clutter up the namespace. 00:07 < knurd> | dag tried to explain one two me, and it made a bit of sense 00:07 < nirik> | they allow end users to trivially see what repo packages are causing them conflicts/problems... or so the theory goes. 00:07 < knurd> | say there is clamav in both epel and dags repo 00:07 | i dont know how any sane person can expect to mix repos providing the same packages and get a consistent and sane result 00:07 < knurd> | with different sub-packages 00:07--> | smooge (Stephen J Smoogen) has joined #fedora-meeting 00:08 | i'd tend to agree that mixing repos with the same packagesets == BOOM 00:08 | and repotags won't resolve that. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: Perl-related problem on rrdtool?
On 7/30/07, Rogelio Bastardo <[EMAIL PROTECTED]> wrote: > On CentOS 4.5, I have Cacti and Nagios installed. I'm trying to > "glue" them together with a program called n2rdd but am having a > problem that I wondering is Perl-related. I feel stupid. I didn't have "#!/usr/bin/perl -w" at the top of my perl script! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
R P Herrold wrote: ATM we'll just live and let live, and there will not be any one-side effort to rectify any compatibility issues EPEL created. It's their mess, they'll have to clean it up. Live and let die, you mean - at least as far as the users are concerned. I don't think this issue has any solution other than separate namespaces. Les Your issue belongs on another list Sorry, but I believe that the people affected need to know about it at least as much as the people who control it. > -- the 'mark by nameing' the rpm's in a way obvious to a low sophistication user (rather than some checksum based method that does not exist) has been proposed and rejected already. That misses the point that there may very well be reasons to want to have more than one version installed at once. Every developer should know that there are times you need to at least test 2 different versions of something on the same machine - and they generally know how to do it so they don't conflict. Sadly, the FHS guys seem to live on some planet of perfection where real world issues of version differences and places to store them don't exist, and packagers have followed along with this mistake. sad, but still the case. We'll be having pain for this for years and years. See: https://www.redhat.com/archives/epel-devel-list/2007-June/msg00031.html Please read the archive and the back thread leading up to it. Several @redhat.com showed up to pack the gallery at the 'last chance' epel meeting which could have avoided this train wreck Reasons for disagreements are pretty much irrelevant to their effect. There is not much reason to ever expect everyone to agree and lots of reasons to provide a mechanism to allow them to disagree in separate spaces. Try to imagine what the internet would be like if DNS did not provide managed hierarchal namespace and anyone could usurp anyone else's domain. That's what we get when different people can put different contents into packages of the same names. And it isn't going to go away until there is a namespace based system that lets the end user choose which he wants. I'd just like to see a little less granularity in that namespace than centos vs. ubuntu... -- Les Mikesell [EMAIL PROTECTED] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
Stupid question redux. With some more explanation Why not? Make a mirror of the epel repo. For each package in the repo. Create a repotag using the original signature. Sign the package with repotag using a new key. Anyone wanting to mix repos. Should require signatures with the new key. Problems will certainly remain, but I think this will help with some of the problems. On 7/30/07, Les Mikesell <[EMAIL PROTECTED]> wrote: > > R P Herrold wrote: > > >>> ATM we'll just live and let live, and there will not be any one-side > >>> effort to rectify any compatibility issues EPEL created. It's their > >>> mess, they'll have to clean it up. > >> > >> Live and let die, you mean - at least as far as the users are > >> concerned. I don't think this issue has any solution other than > >> separate namespaces. > > > > Les > > > > Your issue belongs on another list > > Sorry, but I believe that the people affected need to know about it at > least as much as the people who control it. > > > -- the 'mark by nameing' the rpm's in > > a way obvious to a low sophistication user (rather than some checksum > > based method that does not exist) has been proposed and rejected > already. > > That misses the point that there may very well be reasons to want to > have more than one version installed at once. Every developer should > know that there are times you need to at least test 2 different versions > of something on the same machine - and they generally know how to do > it so they don't conflict. Sadly, the FHS guys seem to live on some > planet of perfection where real world issues of version differences and > places to store them don't exist, and packagers have followed along with > this mistake. > > > sad, but still the case. We'll be having pain for this for years and > > years. See: > > https://www.redhat.com/archives/epel-devel-list/2007-June/msg00031.html > > > > > Please read the archive and the back thread leading up to it. Several > > @redhat.com showed up to pack the gallery at the 'last chance' epel > > meeting which could have avoided this train wreck > > Reasons for disagreements are pretty much irrelevant to their effect. > There is not much reason to ever expect everyone to agree and lots of > reasons to provide a mechanism to allow them to disagree in separate > spaces. Try to imagine what the internet would be like if DNS did not > provide managed hierarchal namespace and anyone could usurp anyone > else's domain. That's what we get when different people can put > different contents into packages of the same names. And it isn't going > to go away until there is a namespace based system that lets the end > user choose which he wants. I'd just like to see a little less > granularity in that namespace than centos vs. ubuntu... > > -- > Les Mikesell > [EMAIL PROTECTED] > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > -- Drew Einhorn ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
On Mon, Jul 30, 2007 at 11:21:10AM -0500, Les Mikesell wrote: > >ATM we'll just live and let live, and there will not be any one-side > >effort to rectify any compatibility issues EPEL created. It's their > >mess, they'll have to clean it up. > > Live and let die, you mean - at least as far as the users are concerned. Nah, while I was a James Bond fan in my early youth, I'm not a fan of repo wars. "Let live" was all right, there will not be a war, but neither any one-sided fixing army on this. > I don't think this issue has any solution other than separate > namespaces. Looking at your requests on this you should realize that repotags are what you are really asking for the minimum level, which is what epel nuked to ashes. So the discussion should probably move away from this list to the epel list. And since it's a dead topic there as well you will not really get very far. -- Axel.Thimm at ATrpms.net pgpZH1vNn492g.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
> Looking at your requests on this you should realize that repotags are > what you are really asking for the minimum level, which is what epel > nuked to ashes. So the discussion should probably move away from this > list to the epel list. And since it's a dead topic there as well you > will not really get very far. I know EPEL acknowledged that the whole repo-conflicts thing is an issue that needed to be addressed... as has been rehashed many times, they just didn't like repotags. However, perhaps adding something into RPM itself could go a long way to addressing this in a more integrated manner? https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01537.html That thread might be a good place to request that something like this be added. Not sure how high of a priority everyone would consider it. Ray ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: Re: Mixing RPMforge and EPEL (Was: EPEL repo)
Johnny Hughes wrote: > Rex Dieter wrote: >> It's quite a stetch from "no repotags" to >> conclude "EPEL has no interest" in compatibility. >> In fact, epel (and fedora) repo is, by design and policy, supposed to be >> compatible and considerate of other repos, e.g. most notably, >> http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration >> (among other project policy documents). >> When I posted the aforementioned repository collaboration document to the >> rpmforge list(s) for comment, it received none. > There is talk about cooperation and collaboration, however whenever Axel > or Dag made any kind of suggestions on the EPEL list, they were not > given very much "real" consideration. Only wrt to repotags. Don't remember any serious/significant discussions outside of that since. Am I missing something? So, is rpmforge interested in collaboration or not? Does the RepositoryCollaboration sound like a reasonable starting place? -- Rex ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
Axel Thimm wrote: I don't think this issue has any solution other than separate namespaces. Looking at your requests on this you should realize that repotags are what you are really asking for the minimum level, which is what epel nuked to ashes. So the discussion should probably move away from this list to the epel list. And since it's a dead topic there as well you will not really get very far. I don't know enough about repotags to understand why everyone needs them. Can't any repotag be distinguished from no repotag? Why is there any need for cooperation beyond not choosing the same tag or lack thereof? -- Les Mikesell [EMAIL PROTECTED] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] C5 RPM for RequestTracker now available
Hello, I took a stab at packaging RequestTracker for CentOS 5. Basically some needed FC6 packages were rebuilt as el5. The results are here: http://www.tlviewer.org/rt3/ I'm an rt3 newbie. I'm in the process of reading the DOCS and setting up the DB. The install via RPM appears to be sound. So far the login page for RT opens successfully. I've yet to setup the mail-dispatcher. -- Mark - Got a little couch potato? Check out fun summer activities for kids.___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
On Mon, Jul 30, 2007 at 03:57:23PM -0500, Les Mikesell wrote: > Axel Thimm wrote: > > >> I don't think this issue has any solution other than separate > >>namespaces. > > > >Looking at your requests on this you should realize that repotags are > >what you are really asking for the minimum level, which is what epel > >nuked to ashes. So the discussion should probably move away from this > >list to the epel list. And since it's a dead topic there as well you > >will not really get very far. > > I don't know enough about repotags to understand why everyone needs > them. Can't any repotag be distinguished from no repotag? Why is > there any need for cooperation beyond not choosing the same tag or lack > thereof? All the repotags request was about is to idntify epel packages as such with a simple tag in the file name, no more, no less. And that already died with an awful sound. -- Axel.Thimm at ATrpms.net pgpXkoj6nePGw.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
On Mon, Jul 30, 2007 at 12:15:31PM -0700, Ray Van Dolson wrote: > I know EPEL acknowledged that the whole repo-conflicts thing is an > issue that needed to be addressed... as has been rehashed many times, > they just didn't like repotags. The history goes as follows: o Dag suggests repotags, Axel back them up o _very_ long discussion about repotags o repotags get killed by epel, lots of pain for the repos that did carry repotags (at least for ATrpms it was a painful transition) o Many repo maintainers and users complain about epel's lack of cooperation o epel suddenly reconsiders So after the fact everyone can claim anything. The important thing is how did epel (or better said certain key persons in there) deal with it when they did not see the political ramifications they inflicted upon themselves? -- Axel.Thimm at ATrpms.net pgpgMKL7XR3ej.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
On Mon, Jul 30, 2007 at 03:43:31PM -0500, Rex Dieter wrote: > Johnny Hughes wrote: > > > Rex Dieter wrote: > >> It's quite a stetch from "no repotags" to > >> conclude "EPEL has no interest" in compatibility. > > >> In fact, epel (and fedora) repo is, by design and policy, supposed to be > >> compatible and considerate of other repos, e.g. most notably, > >> http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration > >> (among other project policy documents). > > >> When I posted the aforementioned repository collaboration document to the > >> rpmforge list(s) for comment, it received none. > > > There is talk about cooperation and collaboration, however whenever Axel > > or Dag made any kind of suggestions on the EPEL list, they were not > > given very much "real" consideration. > > Only wrt to repotags. Don't remember any serious/significant discussions > outside of that since. Am I missing something? Lots of things, there was even a face-to-face meeting at LT07. Where it was revealed that it was spot's fault that repotags were killed (but I guess that's just the non-present scape-goat methology) > So, is rpmforge interested in collaboration or not? Does the > RepositoryCollaboration sound like a reasonable starting place? The orginal one, yes, the current one which even lacks the presence of EPEL no. -- Axel.Thimm at ATrpms.net pgpMahulCC2Je.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
On Mon, Jul 30, 2007 at 11:08:49PM +0200, Axel Thimm wrote: > On Mon, Jul 30, 2007 at 12:15:31PM -0700, Ray Van Dolson wrote: > > I know EPEL acknowledged that the whole repo-conflicts thing is an > > issue that needed to be addressed... as has been rehashed many times, > > they just didn't like repotags. > > The history goes as follows: > > o Dag suggests repotags, Axel back them up > o _very_ long discussion about repotags > o repotags get killed by epel, lots of pain for the repos that did > carry repotags (at least for ATrpms it was a painful transition) > o Many repo maintainers and users complain about epel's lack of > cooperation > o epel suddenly reconsiders > > So after the fact everyone can claim anything. The important thing is > how did epel (or better said certain key persons in there) deal with > it when they did not see the political ramifications they inflicted > upon themselves? I understand how a lot of it "went down" (saw the meetings and am on the lists as well), I'm just wondering if that aside (I know, hard to do :), could there feasibly be an RPM-based solution to this that would make repo-tags obsolete? Ray ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
On 7/30/07, Ray Van Dolson <[EMAIL PROTECTED]> wrote: > On Mon, Jul 30, 2007 at 11:08:49PM +0200, Axel Thimm wrote: > > So after the fact everyone can claim anything. The important thing is > > how did epel (or better said certain key persons in there) deal with > > it when they did not see the political ramifications they inflicted > > upon themselves? > > I understand how a lot of it "went down" (saw the meetings and am on > the lists as well), I'm just wondering if that aside (I know, hard to > do :), could there feasibly be an RPM-based solution to this that would > make repo-tags obsolete? > Not sure if in RPM itself (in its current incarnations). It would be sort of a layer above it that at its simplest is the yum priorities list.. and in a more complicated version would rank against rpm signatures so that package X with X1 signature could not replace anything with Y1 signatures. However, even if it were possible, I doubt it would stop it being brought up every couple of weeks.. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
On Mon, Jul 30, 2007 at 02:12:43PM -0700, Ray Van Dolson wrote: > I understand how a lot of it "went down" (saw the meetings and am on > the lists as well), I'm just wondering if that aside (I know, hard to > do :), could there feasibly be an RPM-based solution to this that would > make repo-tags obsolete? Sure, but repotag are not the real issue, they were just the tip of the iceberg that rammed the Titanic. The discussion about them revealed certain aspects of EPEL or at least key persons inside EPEL that showed that there is no real interest in cooperating with other repos other than helping EPEL during the startup phase. EPEL created in RHEL-land the same rift that fedora.us created years back in Fedora-land. So maybe even the success of fedora.us is an ethically questionable roadmap for EPEL for dealing with repo-darwinism. Fedora.us ignored the existance of other repos and solely concentrated on their own growth while the other repos tried to remain compatible. This time the burden will not be pushed away, if EPEL breaks something they will have to fix it. So to get back to the original question: Should RPMforge and EPEL be mixed? Please ask EPEL on this and about the (lack of) guaranty that EPEL will not break RPMforge (or any other repo). -- Axel.Thimm at ATrpms.net pgpHnitsLnK84.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
On Mon, Jul 30, 2007 at 03:20:49PM -0600, Stephen John Smoogen wrote: > On 7/30/07, Ray Van Dolson <[EMAIL PROTECTED]> wrote: > > On Mon, Jul 30, 2007 at 11:08:49PM +0200, Axel Thimm wrote: > > > > So after the fact everyone can claim anything. The important thing is > > > how did epel (or better said certain key persons in there) deal with > > > it when they did not see the political ramifications they inflicted > > > upon themselves? > > > > I understand how a lot of it "went down" (saw the meetings and am on > > the lists as well), I'm just wondering if that aside (I know, hard to > > do :), could there feasibly be an RPM-based solution to this that would > > make repo-tags obsolete? > > > > Not sure if in RPM itself (in its current incarnations). It would be > sort of a layer above it that at its simplest is the yum priorities > list.. and in a more complicated version would rank against rpm > signatures so that package X with X1 signature could not replace > anything with Y1 signatures. Only reason I ask about the RPM-based solution is that (at least to me) it would seem to be the cleanest way to do it -- to store the equivalent of the "repository" or origination inside a defined field within the RPM... something that could be actually spit out via a queryformat query. And the RPM guys are actively seeking feature suggestions right now. It doesn't seem to me this would be too hard, but I'm _far_ from knowledgeable on RPM-internals so maybe there are other hurdles. > However, even if it were possible, I doubt it would stop it being > brought up every couple of weeks.. I don't anticipate bridges ever being fully mended over this unfortunately, but it would be nice to move past it if possible and look at other technical solutions to the issue. I think most people agreed the repotag was a temoprary solution at best Ray ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
Axel Thimm wrote: I don't know enough about repotags to understand why everyone needs them. Can't any repotag be distinguished from no repotag? Why is there any need for cooperation beyond not choosing the same tag or lack thereof? All the repotags request was about is to idntify epel packages as such with a simple tag in the file name, no more, no less. And that already died with an awful sound. If everyone else has added unique repo tags, isn't the lack of a tag an equally unique identifier? I'm missing the point of argument here. -- Les Mikesell [EMAIL PROTECTED] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
On Mon, Jul 30, 2007 at 04:58:19PM -0500, Les Mikesell wrote: > Axel Thimm wrote: > > >>I don't know enough about repotags to understand why everyone needs > >>them. Can't any repotag be distinguished from no repotag? Why is > >>there any need for cooperation beyond not choosing the same tag or lack > >>thereof? > > > >All the repotags request was about is to idntify epel packages as such > >with a simple tag in the file name, no more, no less. And that already > >died with an awful sound. > > If everyone else has added unique repo tags, isn't the lack of a tag an > equally unique identifier? I'm missing the point of argument here. So you want to reiterate the whole epel-devel repotag fiasco here argument by argument? The argument was that once a repo drops the repotag and foo-1.2.3-4 conflicts with foo-2.0.0-1.blahrepo the typical user assumes the former to belong to the distro proper and the latter to be the one causing the conflict. This is no academia, freshrpms had dropped repotags in December and suddely it started to rain such bug reports like "ATrpms replaces Fedora's mplayer". But really this becomes more and more off-topic and a repetition of the epel-devel list discussion. If you have more questions on the nature of repotags and the repo rifts created by epel, please check the epel archives. Be assured that every aspect has been brought up and beaten to death. -- Axel.Thimm at ATrpms.net pgpE776PiSqu3.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
Axel Thimm wrote: On Mon, Jul 30, 2007 at 04:58:19PM -0500, Les Mikesell wrote: Axel Thimm wrote: I don't know enough about repotags to understand why everyone needs them. Can't any repotag be distinguished from no repotag? Why is there any need for cooperation beyond not choosing the same tag or lack thereof? All the repotags request was about is to idntify epel packages as such with a simple tag in the file name, no more, no less. And that already died with an awful sound. If everyone else has added unique repo tags, isn't the lack of a tag an equally unique identifier? I'm missing the point of argument here. So you want to reiterate the whole epel-devel repotag fiasco here argument by argument? No, I want to understand the effect on an end user when only one repo refuses to add a unique tag. I don't want to fight the war - I want to know which way to duck. The argument was that once a repo drops the repotag and foo-1.2.3-4 conflicts with foo-2.0.0-1.blahrepo the typical user assumes the former to belong to the distro proper and the latter to be the one causing the conflict. I don't get it. What does the potential to drop a tag have to do with a tag not existing in the first place? -- Les Mikesell [EMAIL PROTECTED] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
> No, I want to understand the effect on an end user when only one repo > refuses to add a unique tag. I don't want to fight the war - I want to > know which way to duck. I think the issue now is that other repo's decided to drop their own repo tags as a result of EPEL's decision. So that could potentially lead to some conflict. I think a lot of this stems from the fact that EPEL considered themselves a bit like Fedora Extras aka "upstream" in a sense. Which actually seemed somewhat to make sense to me, but... > >The argument was that once a repo drops the > >repotag and foo-1.2.3-4 conflicts with foo-2.0.0-1.blahrepo the > >typical user assumes the former to belong to the distro proper and the > >latter to be the one causing the conflict. > > I don't get it. What does the potential to drop a tag have to do with a > tag not existing in the first place? I think in general it's just not a good idea to mix repo's at all -- and if you do to only selectively enable the packages you want. Ray ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
On Mon, 30 Jul 2007, Ray Van Dolson wrote: I understand how a lot of it "went down" (saw the meetings and am on the lists as well), I'm just wondering if that aside (I know, hard to do :), could there feasibly be an RPM-based solution to this that would make repo-tags obsolete? 'could be'? Sure. Check the package signing key against a well maintained index of the same, posibly on an automated basis with a small tool-let (TUI and widget). Have a well maintained central archive to query against, which accepts new keys countersigned with a GPG key off record at a public keyserver, from a person in a chain of trust/chain of 'known'. Lock the network down with a CACert CA mediated SSL layer. Likely to happen? dunno -- step up and write it. I cannot write it for free. There have been proposals along these lines in one form or another, and the widget hasn't happened yet. Until then, externally visible repotags were the next best option. But they are 'unsightly' to the Red Hat person quoted, as they "clutter up the namespace". Fine. He wins. We all lose. Tech support load sauce for the goose works on the gander as well. I assume Dag and Axel will have to send people away when it is EPEL is present or conflicting for load management. -- Russ Herrold ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Misterious Yum install Error: "package ... is reduced"
Hi, Here is a newbie to Yum on Centos 5. I got an interesting yet misterious problem here. When I rolled a mod_jk package and tried to install it onto a bunch of Centos 5 boxes with comand 'yum -e 10 -d 10 install mod_jk', it fails with the messages at end; and so mod_jk just ended up ignored. But when I manually run 'rpm -ivh --test mod_jk...rpm' on command line it reports no problem. Please help. - ... Reading Local RPMDB Parsing package install arguments No other mod_jk installed, adding to list for potential install reduced installs : mod_jk.x86_64 0:1.2.23-1_myRolled skipping reposetup, pkgsack exists skipping reposetup, pkgsack exists Building updates object ... skipping reposetup, pkgsack exists skipping reposetup, pkgsack exists Package httpd - 2.2.3-7.el5.centos.x86_64 already installed and latest version Nothing to do ... Any Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Misterious Yum install Error: "package ... is reduced"
Hi, Here is a newbie to Yum on Centos 5. I got an interesting yet misterious problem here. When I rolled a mod_jk package and tried to install it onto a bunch of Centos 5 boxes with comand 'yum -e 10 -d 10 install mod_jk', it fails with the messages at end; and so mod_jk just ended up ignored. But when I manually run 'rpm -ivh --test mod_jk...rpm' on command line it reports no problem. Please help. - ... Reading Local RPMDB Parsing package install arguments No other mod_jk installed, adding to list for potential install reduced installs : mod_jk.x86_64 0:1.2.23-1_myRolled skipping reposetup, pkgsack exists skipping reposetup, pkgsack exists Building updates object ... skipping reposetup, pkgsack exists skipping reposetup, pkgsack exists Package httpd - 2.2.3-7.el5.centos.x86_64 already installed and latest version Nothing to do ... Any Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] memory query
On 28 July 2007, simon wrote: > I have recently installed centOS 5 on DELL pentium 2.7ghz (model > optiplex GX270) and have 512 memory Simon: Below is on the same box, after I did a clean install of CentOS 5.0. Still showing 512 MB of RAM, as it did with CentOS 4.4, which is what's installed in the box. Look at the information in the BIOS of that box and see what it shows you there. I'm using x86. Lanny > [EMAIL PROTECTED] ~]$ free > total used free sharedbuffers cached > Mem:514084 507700 6384 0 11148 226780 > -/+ buffers/cache: 269772 244312 > Swap: 10441841441044040 > [EMAIL PROTECTED] ~]$ cat /proc/meminfo > MemTotal: 514084 kB > MemFree: 5704 kB > Buffers: 11292 kB > Cached: 226316 kB > SwapCached: 0 kB > Active: 281128 kB > Inactive: 130944 kB > HighTotal: 0 kB > HighFree:0 kB > LowTotal: 514084 kB > LowFree: 5704 kB > SwapTotal: 1044184 kB > SwapFree: 1044040 kB > Dirty: 176 kB > Writeback: 0 kB > AnonPages: 174476 kB > Mapped: 62020 kB > Slab:21928 kB > PageTables: 4396 kB > NFS_Unstable:0 kB > Bounce: 0 kB > CommitLimit: 1301224 kB > Committed_AS: 684364 kB > VmallocTotal: 507896 kB > VmallocUsed: 4748 kB > VmallocChunk: 502772 kB > HugePages_Total: 0 > HugePages_Free: 0 > HugePages_Rsvd: 0 > Hugepagesize: 4096 kB > [EMAIL PROTECTED] ~]$ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] VMWare hiccup on CentOS 5, 2.6.18-8.1.8
For reasons which escape me, my VMWare Server, which was working perfectly a week ago when I shut down my machine for vacation, no loner comes up with the formerly working Windows XP system - it just stays in the small window where it normally boots and does nothing. The vmware serverd log shows nothing particularly interesting, and I have reconfigured the vmware twice to try and fix this (which interestingly enough could not find the vmware modules for my os either time). I am running CentOS 5.0 with all the latest updates through this morning, plus a 2.6.18-8.1.8 kernel with NTFS file system support compiled in as a module, and vmware server shows this: $ vmware -v /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libpng12.so.0/libpng12.so.0: no version information available (required by /usr/lib/libcairo.so.2) VMware Server 1.0.3 build-44356 (Not sure what that note about libpng12 means) Here is the server log's tail: Jul 30 17:57:48: app| SP: Retrieved username: mhr Jul 30 17:57:54: app| Adding to list of running vms: /F/vmware/Windows XP Professional/Windows XP Professional.vmx Jul 30 17:57:54: app| Attempting to launch vmx : /F/vmware/Windows XP Professional/Windows XP Professional.vmx Jul 30 17:57:55: app| New connection on socket server-vmxvmdb from host localhost (ip address: local) , user: mhr Jul 30 17:57:55: app| Connection from : /F/vmware/Windows XP Professional/Windows XP Professional.vmx Jul 30 17:57:55: app| Setting up autoDetect info. Jul 30 17:57:55: app| VMServerdConnect: connecting to /F/vmware/Windows XP Professional/Windows XP Professional.vmx Jul 30 17:57:55: app| Connected to /F/vmware/Windows XP Professional/Windows XP Professional.vmx It is now 18:43 and the window is still hung. Any suggestions or clues? This is the first glitch I've had with vmware server on CentOS 5. Thanks. mhr ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Lost file associations, too - urgent
I just returned from a week's vacation and brought my CentOS 5.0 system back up, updated it, and somehow it has lost all the .doc file associations. These used to be associated with the OpenOffice writer, but that's now gone. ACtually, all the "open with" associations are gone (rtf's now think they should be opened by the text editor!). I'm not sure exactly what the association should be - can anyone point me in the right direction? Thanks. mhr ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] yum remove 'tomcat*'?
On CentOS 5, why does 'yum remove tomcat*' remove all of the openoffice packages? -- Les Mikesell [EMAIL PROTECTED] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] yum remove 'tomcat*'?
Les Mikesell wrote: > On CentOS 5, why does 'yum remove tomcat*' remove all of the openoffice > packages? > That would be because openoffice requires tomcat to install it ... if you tell yum that you want to remove tomcat ... since openoffice requires tomcat, it has to also remove openoffice. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
