pedro.pena

Hola,

En el mismo PPA de Mozilla Security Tema, siguen estando: https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+packages?field.name_filter=firefox&field.status_filter=&field.series_filter=quantal

Un saludo.

Hola,

Se está tratando el tema en https://exelearning.net/forums/topic/problema-con-firefox-17-0/.

De momento no es posible ejecutar eXe en Firefox 17. La única solución es volver a instalar la versión 16.02 o inferior.

Un saludo.

Hola,

Ubuntu 10.04 i386: http://archive.ubuntu.com/ubuntu/ubuntu/pool/main/f/firefox/firefox_16.0.2+build1-0ubuntu0.10.04.1_i386.deb

Ubuntu 10.04 amd64: http://archive.ubuntu.com/ubuntu/ubuntu/pool/main/f/firefox/firefox_16.0.2+build1-0ubuntu0.10.04.1_amd64.deb

Ubuntu 12.04 i386: http://archive.ubuntu.com/ubuntu/ubuntu/pool/main/f/firefox/firefox_16.0.2+build1-0ubuntu0.12.04.1_i386.deb

Ubuntu 12.04 amd64: http://archive.ubuntu.com/ubuntu/ubuntu/pool/main/f/firefox/firefox_16.0.2+build1-0ubuntu0.12.04.1_amd64.deb

Ubuntu 12.10 i386: http://archive.ubuntu.com/ubuntu/ubuntu/pool/main/f/firefox/firefox_16.0.2+build1-0ubuntu0.12.10.1_i386.deb

Ubuntu 12.10 amd64: http://archive.ubuntu.com/ubuntu/ubuntu/pool/main/f/firefox/firefox_16.0.2+build1-0ubuntu0.12.10.1_amd64.deb

Como bien dice jrodero hay que descargar el paquete e instalarlo desde terminal mediante “sudo dpkg -i <nombre_de_paquete>”. Desde el Centro de Software no nos deja hacer downgrade, al menos en 12.04, donde he probado.

La versión intef6.3 todavía estará basada en interfaz XUL (o sea depende de firefox) y por tanto seguirá teniendo el mismo problema. Seguramente mañana pondremos a disposición del equipo de probadores una versión candidata a final. Cuando pase el corte del equipo de probadores se publicará.

No será hasta intef7 que podremos librarnos de XUL e independizarnos del navegador. Con esa versión Firefox >=17 volverá a funcionar. De momento no hay fecha prevista, pero podríamos pedírsela a Papá Noel o a los Reyes. Los mismo cae.

 Un saludo.

Hola,

En mi entorno de pruebas he replicado el problema con intef6.2, como he comentado antes. En ese mismo entorno he probado la última versión que tenemos en trunk y no se da el problema. Parece que la actualización de TinyMCE lo ha solucionado. Así que en la próxima intef6.3 estará arreglado.

Un saludo.

Disculpas. No está basado en código javascript. Es un swf el que parece que deja colgado firefox.

Un saludo.

Hola,

Parece que es un problema que se da solamente en la previsualización en eXe. He probado con Mac OS X 10.6.7 y el idevice Lupa (el código javascript) deja colgado el firefox de eXe. Sin embargo si puedo ver correctamente la prueba que ha colgado Ignacio con el mismo firefox.

Reviso y os cuento.

Un saludo.

Hola,

Es un problema bastante grave para eXe. Mozilla ha decidido quitar completamente la función enablePrivilege de su api (https://developer.mozilla.org/en-US/docs/Bypassing_Security_Restrictions_and_Signing_Code). En eXe se usa intensivamente esta función para poder operar con archivos locales, así que habría que migrar esa funcionalidad al nuevo modelo que propone Mozilla. Esto será costoso y estamos estudiando si merece o no la pena, ya que la siguiente versión posterior a intef6.3 ya no dependerá de Firefox.

De momento la única solución rápida es volver a una versión anterior de Firefox. La pega es que por ejemplo en Ubuntu, Firefox 16 no está visible en sus repositorios. Sin embargo físiscamente siguen estando en http://archive.ubuntu.com/ubuntu/ubuntu/pool/main/f/firefox/.

Un saludo.

Hola,

He comprobado que la librería está en el dmg de intef6.2. Cuando se abre el dmg el fichero está en /Volumes/exe/exe.app/Contents/Resources/lib/python2.7/lib-dynload/_imaging.so.

Una vez instalado eXe, quedará en /Applications/exe.app/Contents/Resources/lib/python2.7/lib-dynload/_imaging.so. Verifica que éste fichero existe después de instalar. Si está, el error no debería darse.

Un saludo.

Hola,

Se trata del bug #1360 (https://forja.cenatic.es/tracker/index.php?func=detail&aid=1360&group_id=197&atid=883). Se arregló hace algún tiempo. ¿Estás usando la versión intef6.2? Si es así prueba a descargarla e instalarla de nuevo. Acabo de probar con el último instalador de la versión intef6.2 y no he tenido problema. De todas formas voy a confirmar que la librería PIL está en el dmg.

Un saludo.

Hola,

Se han añadido 2, pero ha dejado de usarse 1. De ahí que pasemos de 841 a 842.

Un saludo.

Hola José Miguel,

Efectivamente en el fichero VP03_Contenidos.elp hay un problema de nodos zombies. Abriendo y guardándo con la versión que tenemos en trunk actualmente, se hace limpieza de dichos nodos y efectivamente ya se puede insertar en otros elp’s.

En el otro fichero, TFM02_Contenidos.elp, no hay problema de nodos zombies. Sin embargo si que, como indicas, hay un problema de indexado de recursos. Concretamente en el elp está indexado un recurso (TFM02_CONT_Medicion_tiempo_Desc.1.html) que físicamente no está. Eso no impide abrir el elp normalmente, pero sí que hace saltar el error al insertar en otro elp. En la consola de error de eclipse puede verse lo siguiente al tratar de insertar el elp:

  File “/home/pedro/Desarrollo/workspace/juno/python/iteexe-trunk/exe/engine/path.py”, line 925, in copyfile

    return shutil.copyfile(toUnicode(self), toUnicode(dst))

  File “/usr/lib/python2.7/shutil.py”, line 82, in copyfile

    with open(src, ‘rb’) as fsrc:

<type ‘exceptions.IOError’>: [Errno 2] No such file or directory: u’/tmp/tmpA6tC3F/TFM02_CONT_Medicion_tiempo_Desc.1.html‘

Está tratando de copiar un fichero que no existe físicamente en el elp, de ahí el error “No such file or directory”. Creo que habría que abrir un bug para solucionar esta excepción no controlada y que al menos siga adelante. Otra cosa es la fuente del problema: la gestión de archivos.

Ahora mismo, con la versión actual, no veo proceso automático para limpiar esos recursos que realmente no existen para éste caso concreto. He probado a forzar una limpieza de recursos zombies, pero los recursos siguen en los metadatos. Tan solo quedaría editar a mano el content.xml. Otra opción es aprovechar la corrección del bug para meter código que elimine el recurso de los metadatos cuando se dé la excepción mencionada.

Respecto a la gestión de archivos se me ocurren varias ideas. Una nueva pestaña al mismo nivel de la de autoría, en la que se vería un árbol de todos los recursos indexados. Ya que habría que mostrarlos, y eso implicaría explorar tanto los metadatos como lo que realmente hay en el elp, se podría verificar si ambos índices concuerdan y mostrar visualmente al usuario las incosistencias. Éstas serían de 2 tipos: un recurso indexado en los metadatos que no está físicamente, o un recurso que está físicamente pero no está indexado en los metadatos. A parte se podrían realizar acciones, comó añadir físicamente un archivo, añadirlo a los metadatos, eliminar, etc, etc. Con la nueva interfaz javascript seria bastante sencillo de implementar a nivel interfaz de usuario. Aunque estas ideas mejor sería trasladarlas a otro hilo.

Un saludo.

Hola,

No hay proceso automático para hacer merge de trunk a jsui de los PO. Preferiría que lo hicieráis vosotros cuando nos pasemos a jsui.

Por otro lado, para que aparezca como opción el idioma Català (Valencià) en preferencias tan solo hay que añadir el PO y el MO en el directorio de locales. He hecho un commit subiendo los provisionales que aportó cferrando y comprobado que se establece correctamente.

Un saludo.

Hola,

Por si no podemos dar con la fuente del problema (cómo se generan esos apuntadores a nodos zombies), he hecho un commit para limpiar esos apuntadores a nodos zombies cuando se encuentren.

En mis pruebas he podido insertar correctamente las 2 muestras problemáticas después de abrir y guardar los elp’s.

Dicho cambio irá en la próxima versión (intef6.3).

Un saludo.

Hola,

He estado analizando el elp Busquedasv5 y compruebo que el original ya contiene nodos zombies (2 concretamente). Por lo tanto al extraer el nodo problemático (“Bing y Yahoo!” que contiene apuntadores a los 2 nodos zombies), éste no se podrá insertar ya que dará el error que comentáis.

Necesitaría replicar cómo se han generado dichos nodos zombies y así atajar la fuente del problema. Aporto más información a ver si Raúl se acuerda de cómo se pudo originar:

-Al principio del nodo “Bing y Yahoo” está el primer idevice de Texto libre que empieza por “Existe el mundo más allá de Google”. Cada idevice contiene un campo interno que a su vez contiene un apuntador al nodo padre. En este caso debería ser “none”, pero en lugar de eso apunta a un nodo que ya no existe llamado “Otros buscadores audiovisuales” (el primer nodo zombie).

-El otro idevice problemático es el que lleva por título “Búsqueda de imagenes y vídeos en Bing y Yahoo!”, que está al final del nodo. Dicho idevice contiene un campo interno que a su vez contiene un apuntador al nodo zombie llamado “Altavista”, cuando debería ser “none”.

Eliminando los idevices problemáticos, la extracción/inserción funcionan correctamente. Sin embargo deberíamos intentar replicar el proceso que ha generado esta situación. Raúl, ¿te refresca la memoria la información que te he aportado?.

Mientras seguiré haciendo pruebas. Entiendo que los tiros pueden venir al haber movido idevices y eliminado nodos (ya es algo para empezar a probar).

Un saludo.

Hola,

Espero que para finales de esta semana tendremos una nueva versión (intef6.3) usando la vieja interfaz XUL de eXe. Esta versión se sacará a partir de la rama trunk. Por lo tanto tenéis en torno a una semana para revisar los .po que haya en trunk. Esperamos que esta sea la última versión que use la vieja interfaz XUL.

Después de ésta versión se pasará a estabilizar y depurar la rama con la nueva interfaz javascript (jsui). Nos gustaría tener algo para finales de noviembre (intef7). En esa versión no se incluirá nada de los metadatos LOM. Por lo tanto podréis seguir trabajando con lo que ya hay en jsui (que no es poco).

Recordad que podéis montar un entorno de desarrollo/pruebas con ayuda de éstos vídeos y así poder probar las traducciones al instante.

Un saludo.