Fwd: Re: [opensuse-es] ¿Está fallando Yast o es ignorancia mía?
On Wednesday 03 June 2009 18:17:05 Gabriel wrote:
Buenas tardes, foro.
Debes haber tocado las prioridades de los repositorios y el que tiene la mas actual tiene menos prioridad.
He cambiado las prioridades y le he dado al repositorio KDE4 la máxima y me sigue pasando lo mismo. ¿ Alguna idea más?
De todas formas, si miras uno de los paquetes en rojo, en la pestaña "versiones" deberías ver el que es mas actual. Basta marcarlo y ya entiende quieres cambiar de versión.
No lo entiendo. Ya dije que eran versiones anteriores de Kde 3.1 Saludos y gracias por interesarte por el tema. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Wednesday 03 June 2009 22:51:40 Gabriel wrote:
He cambiado las prioridades y le he dado al repositorio KDE4 la máxima y me sigue pasando lo mismo. ¿ Alguna idea más?
Ojo! 100 = menor prioridad 0 = MAYOR PRIORIDAD
De todas formas, si miras uno de los paquetes en rojo, en la pestaña "versiones" deberías ver el que es mas actual. Basta marcarlo y ya entiende quieres cambiar de versión.
No lo entiendo. Ya dije que eran versiones anteriores de Kde 3.1
Revise el post original y no veo que mencionaras KDE ¿¿¿ 3.1 ???
Saludos.
Alfredo J.V.P.
--
"Una vez que se descarta lo imposible, lo que queda es la verdad por
improbable que parezca" (Sherlock Holmes
On Wednesday 03 June 2009 22:51:40 Gabriel wrote:
He cambiado las prioridades y le he dado al repositorio KDE4 la máxima y me sigue pasando lo mismo. ¿ Alguna idea más?
Ojo! 100 = menor prioridad 0 = MAYOR PRIORIDAD
Así lo he hecho
De todas formas, si miras uno de los paquetes en rojo, en la pestaña "versiones" deberías ver el que es mas actual. Basta marcarlo y ya entiende quieres cambiar de versión.
No lo entiendo. Ya dije que eran versiones anteriores de Kde 3.1
Revise el post original y no veo que mencionaras KDE ¿¿¿ 3.1 ???
Perdona, quise decir 4.1, que es el que viene por defecto en el DVD de Opensuse. He hecho un zypper refresh y todo sigue igual. ¿A alguien más le pasa? -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Thursday 04 June 2009 09:15:23 Gabriel wrote:
On Wednesday 03 June 2009 22:51:40 Gabriel wrote:
He cambiado las prioridades y le he dado al repositorio KDE4 la máxima y me sigue pasando lo mismo. ¿ Alguna idea más?
Ojo! 100 = menor prioridad 0 = MAYOR PRIORIDAD
Así lo he hecho
Con las prioridades tal y como las tienes: Ver si interfieren las resoluciones de conflictos de dependencias resueltas hasta ahora: En Yast2 --> Extras --> Restablecer conflictos ... Intenta actualizar como hasta ahora. Si de repente sueltas un : "Andaaaa! mira lo que era..." vamos por buen camino. Vuelve a resolver los conflictos pero esta vez <dejavu> acuerdate </dejavu> de lo que haces. ;-) Y si no: Apunta las prioridades que tengas ahora. Iguala las prioridades de todos los repositorios. Es Yast : Paquete -->TODOS los paquetes --> Actualizar si hay versión nueva Te saca una lista de todo lo que tiene una versión mas reciente que lo que tienes instalado. Como ahora todo tiene la misma prioridad se fijara en la versión del paquete nada mas. Si te resulta coherente lo que te ofrece a instalar, adelante; pero si tienes dudas ES el MOMENTO de CANCELAR y dejar las prioridades como estaban. Mejor malo conocido que peor por conocer.
He hecho un zypper refresh y todo sigue igual. ¿A alguien más le pasa?
Pues parece que la base de datos de paquetes no es.
Saludos.
Alfredo J.V.P.
--
"Una vez que se descarta lo imposible, lo que queda es la verdad por
improbable que parezca" (Sherlock Holmes
El 2009-06-03 a las 22:51 +0200, Gabriel escribió:
On Wednesday 03 June 2009 18:17:05 Gabriel wrote:
Buenas tardes, foro.
Debes haber tocado las prioridades de los repositorios y el que tiene la mas actual tiene menos prioridad.
He cambiado las prioridades y le he dado al repositorio KDE4 la máxima y me sigue pasando lo mismo. ¿ Alguna idea más?
Además de lo que te comenta Alfredo, podrías hacer un "zypper clean" y un "zypper refresh" no vaya a ser que esté tomando datos atiguos :-? Otra cosa que se me ocurre es que el redirector te esté llevando a un mirror que no esté actualizado... en ese caso prueba con un mirror fijo. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Wednesday 03 June 2009 23:23:07 Camaleón wrote:
El 2009-06-03 a las 22:51 +0200, Gabriel escribió:
On Wednesday 03 June 2009 18:17:05 Gabriel wrote:
Buenas tardes, foro.
Además de lo que te comenta Alfredo, podrías hacer un "zypper clean" y un "zypper refresh" no vaya a ser que esté tomando datos atiguos :-?
Cierto. Me pasó con la versión 10.1. Pero no menciona lentitud en la actualización de los repositorios. Si la base de datos de paquetes tuviera alguna inconsistencia se tomaría su tiempo para resolver.
Otra cosa que se me ocurre es que el redirector te esté llevando a un mirror que no esté actualizado... en ese caso prueba con un mirror fijo.
Pregunto desde mi ignorancia al respecto: ¿No es labor del redirector balancear la carga de peticiones entre los mirrors?. Si es así, raro sería que le haya enviado siempre al mismo. ¿Cual es el mayor lapso de tiempo que un mirror puede estar desactualizado?
Saludos,
-- Camaleón
--
"Una vez que se descarta lo imposible, lo que queda es la verdad por
improbable que parezca" (Sherlock Holmes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-06-04 a las 01:44 +0200, Alfredo J. V. P. escribió:
Otra cosa que se me ocurre es que el redirector te esté llevando a un mirror que no esté actualizado... en ese caso prueba con un mirror fijo.
Pregunto desde mi ignorancia al respecto: ¿No es labor del redirector balancear la carga de peticiones entre los mirrors?. Si es así, raro sería que le haya enviado siempre al mismo. ¿Cual es el mayor lapso de tiempo que un mirror puede estar desactualizado?
El redirector (mirror brain) es bastante complejo. Los metadatos los sirve directamente el servidor de opensuse, mientras que la descarga va a los "mirrors". Si usas 11.1 (no me he leido el hilo entero y no tengo tiempo, salgo para el curro ya) la descarga se hace o se puede hacer mediante el protocolo metalink, que divide la descarga automáticamente entre varios servidores, lo que haría muy dificil, se piensa, que la falla de un espejo hiciera fallar la descarga. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkonVkEACgkQtTMYHG2NR9XLHgCeIgaR5vz63cFWFGhunM7x9HSi C5kAnAstD4BQKm/U04obSmmyoKw2sg/a =UZI6 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-06-04 a las 07:06 +0200, Carlos E. R. escribió:
El 2009-06-04 a las 01:44 +0200, Alfredo J. V. P. escribió:
Pregunto desde mi ignorancia al respecto: ¿No es labor del redirector balancear la carga de peticiones entre los mirrors?. Si es así, raro sería que le haya enviado siempre al mismo. ¿Cual es el mayor lapso de tiempo que un mirror puede estar desactualizado?
El redirector (mirror brain) es bastante complejo. Los metadatos los sirve directamente el servidor de opensuse, mientras que la descarga va a los "mirrors". Si usas 11.1 (no me he leido el hilo entero y no tengo tiempo, salgo para el curro ya) la descarga se hace o se puede hacer mediante el protocolo metalink, que divide la descarga automáticamente entre varios servidores, lo que haría muy dificil, se piensa, que la falla de un espejo hiciera fallar la descarga.
Releyendo con más calma, te cuento cosas. El redirector funciona distinto según que versión de openSUSE usas. En la 11.1 el balanceo de carga lo hace el cliente: el redirector lo que manda son los datos para un cliente metalink (no se como); con esos datos, el cliente descarga de varios espejos simultaneamente, repartiendo la carga automáticamente y sin que un espejo que no funcione le afecte. Creo que lo que les falta es un sistema que reporte automáticamente los fallos de los espejos para desactivarlos al vuelo. Este comportamiento no se si lo tiene por defecto, pero si no se activa con la variable "ZYPP_ARIA2C=1" en el entorno. Por otro lado, el redirector da un conjunto de espejos basados en la localización geográfica del cliente (antiguamente basado enla zona horaria), sin reparto aleatorio. Hace poco un usuario en China tenía problemas, no le funcionaba el YOU, y en cambio con un mirror puesto fijo sí funcionaba. El problema era que el redirector le daba un espejo situado en la isla de Taiwan, que es bloqueado por el cortafuegos "corporativo" de la China comunista. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkooHV0ACgkQtTMYHG2NR9WLwwCeIc7LtdeZ5Yqc4y9tR8T9GjvK zcYAmgIIaQqJM6ZA/a2xsjHYIErMr8mX =6JDG -----END PGP SIGNATURE-----
On Thursday 04 June 2009 21:15:28 Carlos E. R. wrote:
El 2009-06-04 a las 07:06 +0200, Carlos E. R. escribió:
Soberbia explicación. Gracias. Había oído hablar sobre el protocolo metalink refiriendose al P2P como sustituto del torrent.
El redirector (mirror brain) es bastante complejo. Los metadatos los sirve directamente el servidor de opensuse, mientras que la descarga va a los "mirrors". Si usas 11.1 (no me he leido el hilo entero y no tengo tiempo, salgo para el curro ya) la descarga se hace o se puede hacer mediante el protocolo metalink, que divide la descarga automáticamente entre varios servidores, lo que haría muy dificil, se piensa, que la falla de un espejo hiciera fallar la descarga.
Releyendo con más calma, te cuento cosas. El redirector funciona distinto según que versión de openSUSE usas. En la 11.1 el balanceo de carga lo hace el cliente: el redirector lo que manda son los datos para un cliente metalink (no se como); con esos datos, el cliente descarga de varios espejos simultaneamente, repartiendo la carga automáticamente y sin que un espejo que no funcione le afecte. Creo que lo que les falta es un sistema que reporte automáticamente los fallos de los espejos para desactivarlos al vuelo.
Este comportamiento no se si lo tiene por defecto, pero si no se activa con la variable "ZYPP_ARIA2C=1" en el entorno.
Por otro lado, el redirector da un conjunto de espejos basados en la localización geográfica del cliente (antiguamente basado enla zona horaria), sin reparto aleatorio. Hace poco un usuario en China tenía problemas, no le funcionaba el YOU, y en cambio con un mirror puesto fijo sí funcionaba. El problema era que el redirector le daba un espejo situado en la isla de Taiwan, que es bloqueado por el cortafuegos "corporativo" de la China comunista.
Si, supongo, los propios mirrors usan la parte cliente para actualizarse y
existen "políticas" como la de China ¿No podría darse el caso de creación
de "islas" geográficas desactualizadas?
Dada la lista finita de espejos en el fichero (XML) .metalink y siendo el
cliente el que balancea la carga ¿Puede, en caso de fallo o conexión
deficiente, solicitar un .metalink que amplíe la zona geográfica ?
Si pido demasiado paradme. Es que el articulo de Wikipedia no es demasiado
extenso sobre la dinámica del protocolo.
Un saludo.
Alfredo J.V.P.
--
"Una vez que se descarta lo imposible, lo que queda es la verdad por
improbable que parezca" (Sherlock Holmes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-06-04 a las 23:42 +0200, Alfredo J. V. P. escribió:
On Thursday 04 June 2009 21:15:28 Carlos E. R. wrote:
El 2009-06-04 a las 07:06 +0200, Carlos E. R. escribió:
Soberbia explicación. Gracias. Había oído hablar sobre el protocolo metalink refiriendose al P2P como sustituto del torrent.
No, no es substituto del torrent. Lo que pasa es que un enlace metalink puede contener enlaces http, ftp, o torrent. El cliente elige usar los métodos que pueda/quiera para hacer la descarga lo más rápida posible. Y no es un protocolo P2P, en tanto en cuanto no es anónimo.
Este comportamiento no se si lo tiene por defecto, pero si no se activa con la variable "ZYPP_ARIA2C=1" en el entorno.
Por otro lado, el redirector da un conjunto de espejos basados en la localización geográfica del cliente (antiguamente basado enla zona horaria), sin reparto aleatorio. Hace poco un usuario en China tenía problemas, no le funcionaba el YOU, y en cambio con un mirror puesto fijo sí funcionaba. El problema era que el redirector le daba un espejo situado en la isla de Taiwan, que es bloqueado por el cortafuegos "corporativo" de la China comunista.
Si, supongo, los propios mirrors usan la parte cliente para actualizarse y existen "políticas" como la de China ¿No podría darse el caso de creación de "islas" geográficas desactualizadas?
No, no realmente. No, porque el sistema consiste en que los metadatos, esto es, la lista de lo que tienes que actualizar, se baja desde el servidor central de openSUSE, no desde los mirrors. El fallo que le daba a esta persona es que le salían actualizaciones, pero estas fallaban al intentarlas, y por una causa que a los diseñadores del sistema de espejos (mirrorbrain) no se les ocurrió pensar. Creo que no estaba usando el nuevo sistema mediante metalink, se cree que eso hubiera podido evitar el problema, salvo que la lista de espejos dada sólo fuera de la región prohibida.
Dada la lista finita de espejos en el fichero (XML) .metalink y siendo el cliente el que balancea la carga ¿Puede, en caso de fallo o conexión deficiente, solicitar un .metalink que amplíe la zona geográfica ?
No lo se. Pero se lo puedes preguntar al responsable de ese sistema :-) Imagino que algo se les habrá ocurrido. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkooRwIACgkQtTMYHG2NR9XdcwCfZIjqoTOpmUqzfbchSiG2igfe CsEAniEfBd9H1DkerhDOj5jt8zGeocJZ =vU5K -----END PGP SIGNATURE-----
El 2009-06-04 a las 01:44 +0200, Alfredo J. V. P. escribió:
On Wednesday 03 June 2009 23:23:07 Camaleón wrote:
Además de lo que te comenta Alfredo, podrías hacer un "zypper clean" y un "zypper refresh" no vaya a ser que esté tomando datos atiguos :-?
Cierto. Me pasó con la versión 10.1. Pero no menciona lentitud en la actualización de los repositorios. Si la base de datos de paquetes tuviera alguna inconsistencia se tomaría su tiempo para resolver.
"zypper clean" permite eliminar las cachés de paquetes rpm y los metadatos. Por defecto creo que sólo borra la de los rpm. "zypper clean -a" borra ambos. "zypper refresh" actualiza los metadados.
Otra cosa que se me ocurre es que el redirector te esté llevando a un mirror que no esté actualizado... en ese caso prueba con un mirror fijo.
Pregunto desde mi ignorancia al respecto: ¿No es labor del redirector balancear la carga de peticiones entre los mirrors?. Si es así, raro sería que le haya enviado siempre al mismo. ¿Cual es el mayor lapso de tiempo que un mirror puede estar desactualizado?
El redirector es un misterio para mí. No sé qué hace ni cómo ni por qué, así que si zypper o yast no me dan los paquetes que espero, sencilamente cambio de mirror a uno estático donde al menos pueda comprobar por algún medio (usando el navegador) qué datos tiene. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (5)
-
Alfredo J. V. P. -
Camaleón -
Carlos E. R. -
Carlos E. R. -
Gabriel