[opensuse-translation-es] IMPORTANTE: Parches de actualizaciones y bug opensuseupdater en 10.3
Hola a todos, no estoy usando opensuse 10.3 de manera habitual, más bien de manera excepcional -al estar en spanglish-. Solamente lo tengo en el portátil. Hace un momento lo he arrancado porque me he dado cuenta que en la opensuse 10.2, que uso habitualmente kbabel no me abre algunos archivos que sí se abrían el otro día en opensuse 10.3. Bien, he arrancado el portátil y he visto que opensuseupdater indicaba que no hay ninguna actualización, lo cual me ha parecido sospechoso. Al ver esto, he arrancado YaST/Instalación de software, y he visto que había actulizaciones, una de ellas de las traducciones de YaST. Al hilo de esto me gustaría comentar dos cosas: 1.- Ayer o antes de ayer Miguel Ángel me comentó algo de un bug que ha dado de alta en bugzilla. Dicho bug consiste en que algo ocurre por causa desconocida que hace que opensuseupdater no indique actualización alguna, incluso dándole a comprobar, creo recordar que era una corrupción de un archivo que se solucionaba borrándolo, según Miguel Ángel. Ya nos contará él en qué consiste exactamente y cómo solucionarlo antes de que salga el parche correspondiente. Yo no soy muy habilidoso buscando en bugzilla, el que quiera y sepa que lo busque. De todas maneras seguro que Miguel Ángel nos da más detalles. 2.- Como ya he dicho antes hay actualización de traducciones de YaST. No sé si se habrán colado algunas de las nuestras. El que sepa puede comprobarlo y decir algo. Pero lo que me inquieta es que me he dado cuenta, después de traducir archivos, que en realidad muchos de ellos no sé dónde coloca las traducciones. Creo que deberíamos hacer una tabla con cada archivo para qué sirve y dónde se colocan las traducciones. De los de YaST tengo idea, pero de los lcn no. Es útil, creo, hacer esa tabla para que con cada parche podamos inspeccionar qué hemos traducido cada uno y comprobar, siempre que se pueda, si ha quedado realmente bien. Del bug que dio de alta Miguel Ángel he intentado mirar el correo o ver el registro de Psi, con el que suelo hablar con él y no está... Finalmente lo he encontrado en bugzilla: Bug 337657 - Repository database may corrupt and leave zypper/yast/opensuseupdater unusable Bug List: (5 of 200) <<First <Prev Next> Last>> Show last search results Bug #337657 Overview Opened: 2007-10-29 13:32 MST Last modified: 2007-11-08 13:06:40 MST Classification Product Component Found in Version openSUSE openSUSE 10.3 libzypp Final Severity Priority Status Fixed in Milestone Critical P5 - None REOPENED --- Hardware OS Resolution Keywords Other openSUSE 10.3 View Bug Activity Format For Printing Description Summary: Repository database may corrupt and leave zypper/yast/opensuseupdater unusable Description: For some unknown circunstance the repository database zypp.db file (probably trying to add a community repository which failed) got damaged. Then: Opensuseupdater failed to show new updates giving no sign of failure or error messages. yast software installation module showed only part of the installed repositories (4 from 8) Trying to add a new repository would fail with a sql error message, both with yast and zypper. Trying to manually refresh one repository ("Update repository") caused yast to segfault. Deleting it and adding it again didn't solved the problem. After deleting all repositories, some could be added again, but trying to add one ("Main OSS repository") caused yast/zypper to hang forever with 100% CPU usage while building the cache Trying to rebuild the database with "zypper -b" didn't solved the problem. The only way I could recover from such situation was to manually deleting zypp.db and adding/refreshing everything again. Crashing/being unable to recover if zypp.db gets corrupted/damaged for whatever reason is a very bad situation. I suggest for yast/zypper, as recovery procedure if a database error is detected: giving an error message, deleting zypp.db and rebuilding everything again from scratch. The user should have an option in yast/zypper to delete and rebuild, too. Comments ------- Comment #1 From Duncan Mac-Vicar Prett 2007-10-31 10:07:52 MST ------- *** Bug 333310 has been marked as a duplicate of this bug. *** ------- Comment #2 From Duncan Mac-Vicar Prett 2007-11-08 05:42:05 MST ------- This is a candidate for a bug worth to fix in 10.3. However the bug reports contain no useful information on how to reproduce. ------- Comment #3 From Bernhard Walle 2007-11-08 07:54:57 MST ------- I don't get where the problem is. If the database is corrupted, then rebuild it. As it's only a cache, this should be possible without loosing any information. ------- Comment #5 From Miguel Angel Alvarez 2007-11-08 08:45:16 MST ------- The bug is not solved. To Duncan: I'm sorry. This is one of those bugs related to some unusual condition. I'll try to reproduce it somehow. To Bernhard: The problem is not loosing any information. The problem is the imposibility to solve "the problem" for anyone but an expert, and I mean really expert. Get it, yast segfaults and doesn't work anymore. Zypper doesn't work anymore. opensuseupdater doesn't work anymore and gives no error or indication it is not working, while it seems to be working. _Anything_ related to repository management doesn't work anymore. You _can't_ repair it and have no clue why it doesn't work, why it can't be repaired, and how to repair. The fix is easy: it's only a cache, if any error, make yast/zypper delete it and rebuild it. ------- Comment #6 From Duncan Mac-Vicar Prett 2007-11-08 09:30:45 MST ------- The solution then will be to add a new exception for the sqlite3x layer in libzypp and handle it in yast, zypper somehow. ------- Comment #7 From Miguel Angel Alvarez 2007-11-08 13:06:40 MST ------- Don't forget to add a "rebuilddb" command to zypper/yast to be able to do it by hand too (sometimes it gets stuck and the exception would be not thrown) Yo no lo entiendo muy bien, pero parece que es un problema en el caché de zypper/Yast El enlace a bugzilla es este: https://bugzilla.novell.com/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=opensuseupdater%2BMiguel -- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- To unsubscribe, e-mail: opensuse-translation-es+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-11-11 a las 07:14 +0100, csalinux escribió:
no estoy usando opensuse 10.3 de manera habitual, más bien de manera excepcional -al estar en spanglish-. Solamente lo tengo en el portátil. Hace un momento lo he arrancado porque me he dado cuenta que en la opensuse 10.2, que uso habitualmente kbabel no me abre algunos archivos que sí se abrían el otro día en opensuse 10.3.
Puede ser por configuración, o por la base de datos de traducciones antiguas que está corrupto. Lo borras y en paz.
2.- Como ya he dicho antes hay actualización de traducciones de YaST. No sé si se habrán colado algunas de las nuestras.
Lo dudo, no he visto ninguna reciente sobre eso.
El que sepa puede comprobarlo y decir algo. Pero lo que me inquieta es que me he dado cuenta, después de traducir archivos, que en realidad muchos de ellos no sé dónde coloca las traducciones.
Todas van en el mismo sitio. Uno al azar, suseplugger.es.po. Bien, pues haz un locate de suseplugger.mo y suseplugger.gmo, y lo encuentras - y en este caso no existe. Estaría aquí (en 10.2 está): /opt/kde3/share/locale/es/LC_MESSAGES/suseplugger.mo Si miras en el directorio, encontrarás otros muchos que si están. A ver, uno del yast, control-center.es.po, sí que está: /usr/share/YaST2/locale/es/LC_MESSAGES/control-center.mo
Creo que deberíamos hacer una tabla con cada archivo para qué sirve y dónde se colocan las traducciones. De
Se colocan en lugares estandard, pero no debe preocuparte ese detalle. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHNuFRtTMYHG2NR9URAkdyAJ44O14AvOqvXpbCrCHcPHqL6u42igCfRpbw FVB8Rv4FmbXdm5tgxpB5IVI= =jxqi -----END PGP SIGNATURE-----
Carlos E. R. escribió:
Creo que deberíamos hacer una tabla con cada archivo para qué sirve y dónde se colocan las traducciones. De
Se colocan en lugares estandard, pero no debe preocuparte ese detalle.
-- Saludos Carlos E.R.
Me refiero a en qué parte de YaST o dónde sea se colocan para comprobar la traducción que está bien "sobre el campo". -- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- To unsubscribe, e-mail: opensuse-translation-es+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation-es+help@opensuse.org
1.- Ayer o antes de ayer Miguel Ángel me comentó algo de un bug que ha dado de alta en bugzilla. Dicho bug consiste en que algo ocurre por causa desconocida que hace que opensuseupdater no indique actualización alguna, incluso dándole a comprobar, creo recordar que era una corrupción de un archivo que se solucionaba borrándolo, según Miguel Ángel. Ya nos contará él en qué consiste exactamente y cómo solucionarlo antes de que salga el parche correspondiente. Yo no soy muy habilidoso ... La causa es la corrupción del archivo de base de datos sqlite3 que libzypp usa como caché de los repositorios (/var/cache/zypp/zypp.db). Yo creo que se debe a una actualización incompleta en la que no se cierra adecuadamente la base de datos. Como veis en el bug, hay algún desarrollador de reducida capacidad de comprensión al que le da por cerrar bugs de forma compulsiva, así que si alguno de vosotros se ve afectado por el problema, os ruego que entreis en el bug y pongais un comentario, para que se vea la verdadera dimensión del
El Domingo 11 Noviembre 2007, csalinux escribió: ... problema.
2.- Como ya he dicho antes hay actualización de traducciones de YaST. No sé si se habrán colado algunas de las nuestras. El que sepa puede comprobarlo y decir algo. Pero lo que me inquieta es que me he dado No, no hay nada nuestro cuenta, después de traducir archivos, que en realidad muchos de ellos no sé dónde coloca las traducciones. Creo que deberíamos hacer una tabla con cada archivo para qué sirve y dónde se colocan las traducciones. De los de YaST tengo idea, pero de los lcn no. Es útil, creo, hacer esa tabla para que con cada parche podamos inspeccionar qué hemos traducido cada uno y comprobar, siempre que se pueda, si ha quedado realmente bien. Los archivos (*.mo) de localización de lcn van en /usr/share/locale/es/LC_MESSAGES/ como el resto de los programas. Antes hay que compilarlos con "msgfmt fichero.po -o fichero.mo". Se puede hacer todo de una tacada con un sencillo script (solo para lcn) que os adjunto. Hay que ejecutarlo en el directorio lcn/es/po. El script crea una copia de seguridad del archivo original con la extensión .orig.
-- Don't see the world through a window, be open{source}minded, and be free :-)
Miguel Angel Alvarez escribió:si
alguno de vosotros se ve afectado por el problema, os ruego que entreis en el bug y pongais un comentario, para que se vea la verdadera dimensión del problema.
Yo estoy perjudicao :( -- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- To unsubscribe, e-mail: opensuse-translation-es+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation-es+help@opensuse.org
participants (3)
-
Carlos E. R.
-
csalinux
-
Miguel Angel Alvarez