[CentOS-docs] First translation: HowToContribute
=== Come contribuire al wiki === Vorremmo un wiki dove chiunque potesse scrivere senza dover fare i salti mortali, ma non ci è consentito. Dite grazie a tutti gli Spammer là fuori che spargono il loro contributo ovunque sul web. Perciò, per mantenere i contenuti puliti e accurati, moderiamo gli articoli che ci vengono sottoposti. Per poterci inviare dei contributi occorre: * Creare un login con un nome utente nel formato !NomeCognome * Sottoscrivere la [http://lists.centos.org/mailman/listinfo/centos-docs mailing list Centos-Docs ] * Mandare una mail a centos-docs@centos.org , dopo aver effettuato la registrazione, nella quale descrivete come e dove volete contribuire al wiki. Sarebbe carino se ci indicaste dove collocare il/gli articolo/i che state scriverndo. Ah, abbiamo anche bisogno del !NomeUtente che avete creato. * Aspettare che qualcuno del AdminGroup o dell' EditGroup crei la pagina e vi dia i permessi per modificarla. * Se non succede nulla - p. es. perché qualcuno è in vacanza, allora sentitevi liberi di contattare le persone elencate nelle pagine dell' AdminGroup o dell' EditGroup. * Seguire le [:EditingCentOSWiki:linee guida] per l'uso del wiki. La mailing list centos-doc non serve soltanto per chiedere i permessi necessari per scrivere sul wiki ma è anche il luogo delle discussioni sulla documentazioni di CentOS e sulla qualità degli articoli del wiki. Inizialmente i permessi di modifica saranno accordati solo su alcune sezioni del wiki (principalmente le pagine che creerete). Quando avrete postato un numero significativo di contribuiti vi daremo la possibilità di mantenerli aggiornati. A meno che non siate uno sviluppatore di CentOS, non aspettavi di avere accesso completo al wiki. Come già detto: siamo realmente dispiaciuti di dover fare così, ma non vediamo altro modo per mantenere il wiki pulito. Speriamo comunque che vogliate contribuire. -- Quando ti trovi d'accordo con la maggioranza, è il momento di fermarti e riflettere - Mark Twain ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] EditingCentOSWiki in Italian
Roberto wrote: = Linee guida per la modifica del Wiki di CentOS = Thanks - we'll come back at you shortly. I don't see any real problems - just give us a day or two. Cheers, Ralph pgpwvR2syZmgq.pgp Description: PGP signature ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
[CentOS-announce] CESA-2007:0720 Important CentOS 3 i386 cups - security update
CentOS Errata and Security Advisory CESA-2007:0720 cups security update for CentOS 3 i386: https://rhn.redhat.com/errata/RHSA-2007-0720.html The following updated file has been uploaded and is currently syncing to the mirrors: i386: updates/i386/RPMS/cups-1.1.17-13.3.45.i386.rpm updates/i386/RPMS/cups-devel-1.1.17-13.3.45.i386.rpm updates/i386/RPMS/cups-libs-1.1.17-13.3.45.i386.rpm source: updates/SRPMS/cups-1.1.17-13.3.45.src.rpm You may update your CentOS-3 i386 installations by running the command: yum update cups\* Tru -- Tru Huynh (CentOS-3 i386/x86_64 Package Maintenance) http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xBEFA581B pgpoe49EmgzQj.pgp Description: PGP signature ___ CentOS-announce mailing list CentOS-announce@centos.org http://lists.centos.org/mailman/listinfo/centos-announce
[CentOS-announce] CESA-2007:0720 Important CentOS 3 x86_64 cups - security update
CentOS Errata and Security Advisory CESA-2007:0720 cups security update for CentOS 3 x86_64: https://rhn.redhat.com/errata/RHSA-2007-0720.html The following updated file has been uploaded and is currently syncing to the mirrors: x86_64: updates/x86_64/RPMS/cups-1.1.17-13.3.45.x86_64.rpm updates/x86_64/RPMS/cups-devel-1.1.17-13.3.45.x86_64.rpm updates/x86_64/RPMS/cups-libs-1.1.17-13.3.45.i386.rpm updates/x86_64/RPMS/cups-libs-1.1.17-13.3.45.x86_64.rpm source: updates/SRPMS/cups-1.1.17-13.3.45.src.rpm You may update your CentOS-3 x86_64 installations by running the command: yum update cups\* Tru -- Tru Huynh (CentOS-3 i386/x86_64 Package Maintenance) http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xBEFA581B pgp4Diylt0Shu.pgp Description: PGP signature ___ CentOS-announce mailing list CentOS-announce@centos.org http://lists.centos.org/mailman/listinfo/centos-announce
[CentOS-announce] CESA-2007:0735 Important CentOS 3 i386 xpdf - security update
CentOS Errata and Security Advisory CESA-2007:0735 xpdf security update for CentOS 3 i386: https://rhn.redhat.com/errata/RHSA-2007-0735.html The following updated file has been uploaded and is currently syncing to the mirrors: i386: updates/i386/RPMS/xpdf-2.02-10.RHEL3.i386.rpm source: updates/SRPMS/xpdf-2.02-10.RHEL3.src.rpm You may update your CentOS-3 i386 installations by running the command: yum update xpdf Tru -- Tru Huynh (CentOS-3 i386/x86_64 Package Maintenance) http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xBEFA581B pgpEURYyGOBXu.pgp Description: PGP signature ___ CentOS-announce mailing list CentOS-announce@centos.org http://lists.centos.org/mailman/listinfo/centos-announce
[CentOS-es] Saludos
Buenas tardes lista, Acabo de unirme a la lista de correo de centos en español, aunque soy un usuario de debian, donde trabajo utilizamos centos para cualquier cosa. Asi que bueno, espero poder aportar algo para la comunidad mientras este a mi alcance. Saludos... -- Rhonny Lanz R. Linux Counter 377315 Debian Lenny User -- Enlightenment Cel 0412-5019537 :~$ /Caracas_ Venezuela/ Blog -- http://lanzr.blogspot.com/ ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
[CentOS-es] transmición de videos en CentOS
alguien sabe si puedo con CentOS hacer transmisión de videos parecido al servicio que viene con Windows 2000 o 2003 server ¿?¿?¿?___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
RE: [CentOS-es] proxy con dhcp de windows
Levanta un DHCP y configuralas con la direccion MAC _ De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Alexander Usea Enviado el: lunes, 30 de julio de 2007 04:10 p.m. Para: centos-es@centos.org Asunto: [CentOS-es] proxy con dhcp de windows Buenas tardes, estoy instakando centos con proxy para administrar las conexiones de internet en una red de windows con 200 usuarios. en realidad no puedo crear las acces list en squid porque las direcciones ip son dinamicas... por favor quien podria darme una ayuda y decirme que hacer. saludos desde valencia- venezuela -- Usea Alexander ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS-es] proxy con dhcp de windows
Lo que puedes hacer si deseas, es configurar el dhcp, para que el te asigne ip fijas a tus clientes por la mac de la tarjeta, puedes encontrar mas informacion en www.alcancelibre.org en la seccion de manuales Alexander Usea [EMAIL PROTECTED] escribió: Buenas tardes, estoy instakando centos con proxy para administrar las conexiones de internet en una red de windows con 200 usuarios. en realidad no puedo crear las acces list en squid porque las direcciones ip son dinamicas... por favor quien podria darme una ayuda y decirme que hacer. saludos desde valencia- venezuela -- Usea Alexander ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS-es] Instalar centos5 en intelDP965LT
se copia el contenido de los 7 cds? o es otra cosa lo que se tiene que copiar , o son los iso? El día 26/07/07, Juan Oliva [EMAIL PROTECTED] escribió: Hola , yo pase por el mismo caso lo solucione haciendo una instalacion por red es decir copie todos los cds a un webserver interno y realice una instalacion via http , la otra es usar un repositorio de centos por internet , razon por la que no reconoce por hay dicen que el el fash de las lectoras en otros dicen el tipo de ide que maneja las nuevas placas como esa. espero que te sea util. Saludos Juan Blog: http://jroliva.wordpress.com *tildes omitidas intencionalmente On 7/25/07, Richard Lopez [EMAIL PROTECTED] wrote: Quiero instalar Centos 5 en un cpu -placa Intel DP965LT -procesador Pentium D - 512 mb de memoria , lg cdrom ,2 discos sata samsung 150 Gb Empieza la instalacion me pide el lenguaje , luego el teclado y luego es como que ya no reconoce la lectora de cd porque me pregunta donde tengo las imagenes . Es como si dejara de reconocer la lectora. A alguien le paso esto? Ojala me puedan ayudar quizas tenga que ver el que sea procesador pentium d ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es -- ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
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 lower priority repos.
Thanks,
Johnny Hughes
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...) snip package list 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...) snip package list 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
[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
[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_projectcd ./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] 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:03knurd | 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 spot | we're not going to give that statement. 00:05 spot | just as an FYI ... 00:05knurd | spot, ohh, I didn#t expect you would be around 00:05knurd | spot, why? 00:05spot | if you really want repotags vote on it, and we'll figure out how to implement them. ... 00:06 spot | its not our domain to decide whether they're ok or not, thats FESCo ... 00:06knurd | spot, would you share your opnion on repotags? 00:07 spot | I don't know what technical problem they solve. 00:07 dgilmore | spot: none 00:07 spot | They clutter up the namespace. 00:07knurd | dag tried to explain one two me, and it made a bit of sense 00:07nirik | they allow end users to trivially see what repo packages are causing them conflicts/problems... or so the theory goes. 00:07knurd | say there is clamav in both epel and dags repo 00:07 dgilmore | i dont know how any sane person can expect to mix repos providing the same packages and get a consistent and sane result 00:07knurd | with different sub-packages 00:07-- | smooge (Stephen J Smoogen) has joined #fedora-meeting 00:08 spot | i'd tend to agree that mixing repos with the same packagesets == BOOM 00:08 spot | 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
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
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
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
