Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'bug'.

  • Buscar Por Etiquetas

    Añade etiquetas separadas por comas.
  • Buscar Por Autor

Tipo de Contenido


Foros

  • Contacto con el staff
    • Novedades / Anuncios del foro
    • Sugerencias
    • Problemas relacionados con el foro
  • Zona general de charla
    • Presentaciones
    • Charla
    • Zona de Humor, Curiosidades y Otros
    • Mascotas Vagos
    • Noticias del Mundo
    • Tecnología
    • Ayuda y consultas de carácter general
  • Zona GNU/Linux
    • Ayuda, consultas y soporte GNU/Linux
    • Distribuciones GNU/Linux
    • Repositorios. Software GNU/Linux
    • Personalización
    • Raspberry Pi
    • Arduino
    • Manuales / Tutoriales / Guías GNU/Linux
    • Programación
    • Noticias GNU/Linux
    • Hablando de GNU/Linux
  • Zona Gaming
    • Juegos GNU/Linux
    • Noticias Gamer
    • Charla Gamer
  • Zona Móvil
    • Ayuda y soporte para dispositivos móviles
    • Apps Móviles
    • Manuales / Tutoriales / Guías Móviles
    • Roms para dispositivos Móviles
    • Noticias sobre dispositivos Móviles
    • Hablando sobre dispositivos Móviles
  • Zona Mozilla
    • Ayuda, consultas y soporte Mozilla
    • Aplicaciones Mozilla
    • Roms Firefox OS
    • Manuales / Tutoriales / Guías Mozilla
    • Noticias Mozilla
    • Hablando de Mozilla
  • Microsoft
    • Papelera del Foro

Encontrar resultados en...

Encontrar resutados que...


Fecha de Creación

  • Start

    Fin


Última Actualización

  • Start

    Fin


Filtrar por numero de...

Joined

  • Start

    Fin


Grupo


Página Web


Diaspora


Pump


GNU Social


Google +


Twitter


Facebook


Xmpp


Skype


Steam


Desura


MediaGoblin


Youtube


Vimeo


Picasa


Flickr


Email


Lugar


Intereses

Encontramos 5 resultados

  1. Bueno teniendo en cuenta que hace tiempo no escribimos nada en el blog y justo tengo un poco de "mala" suerte y cuando quise actualizar Archlinux tuve el error con la dependencia fontsproto>=2.1.3, entonces armo éste mini how to para solucionar ése "cuasi" bug que tienen algunos archers. Más allá que pasó hace unos días, aproximadamente el 10/02, tal vez antes, lo dejo aquí por las dudas. Asi que como decimos habitualmente... Comencemos! 1- Cuando queremos actualizar nuestro sistema con el clásico (o en mi caso): Actualiza correctamente los repositorios, pero, luego de confirmar el reemplazar diferentes paquetes del repo extra que tenemos, me encuentro con el error: Y claro, quedaba ahí. Doy de nuevo por las dudas y seguía lo mismo, hasta que dije, mmm ése paquete no depende de ningún otro. 1.a - Nos fijamos si lo tenemos instalado con: 2 - Entonces lo elimino: 3 - Luego volví con la misma sentancia del paso 1. 4 - Listo! ¿Por qué sucede ésto? Sabemos que tenemos una distribución y algunas veces nos puede suceder ésto, tal vez en algún momento en el repositorio "extra" se encontraba ése paquete y lo utilizamos por alguna razón. Actualmente ahora no está en el mismo, entonces es lo que nos produjo dicho error de dependencias; tan simple como éso, entonces procedemos a desintalarlo para solucionar el "inconveniente" que teníamos. Nota: Quiero aclarar que ésto está, bah o sucedió en varias distribuciones derivadas de Arch también, llámese Antergos, Manjaro, Chakra, etc. Nota 1: Por las dudas aclaro que desestimamos la cantidad de paquetes para actualizar, porque dependerá del tiempo que lleven sin actualizar. Nota 2: También voy aclarar por las dudas que el uso de yaourt es opcional. ¿Qué usamos? Distribución: Archlinux. Cómandos: pacman. Abrazo de gol!
  2. Una de los problemas que mas suelo tener con KDE, es a la hora de activar el salvapantallas personalizado Por defecto, KDE tiene el salvapantallas simple, un wallpaper y el menu del pass, funciona sin problemas pero aburre al rato, de manera que vamos a configuracion y le anyadimos widgets... cambiamos el fondo.... Y a la hora de bloquear pantalla, Pluf*, pantalla congelada y sin salvapantallas, donde la unica opcion es abrir tty y reiniciar la sesion grafica, o reiniciar. Pues ya no, esta vez me he cansado ( basicamente porque el salvapantallas que me personalice me molo bastante :lol: ) y he encontrado solucion ===== Instalamos qdbus Arch Debian Desde kickoff mismo, ejecutamos kdebugdialog, deseleccionamos todo (unselect all), y en la barra de busqueda escribimos ksmserv, y seleccionamos las dos cosaceses que aparecen, y Ok Luego.. Y listo Fuente: forums.kde.org
  3. Para los osados que se encuentren ahora mismo probando las versiones en desarrollo de Firefox OS en algún terminal "inari", entre los que está el ZTE Open, seguramente se hayan topado una regresión bastante molesta surgida en la versión 1.4 y que ha pasado inadvertida hasta que ha entrado posteriormente en la versión 1.3 donde ha causado más de un dolor de cabeza. El bug en cuestión provoca una serie de "pantallazos blancos" a la hora de iniciar cualquier aplicación, abrir algún menú o en cualquier desplazamiento por la pantalla o, directamente hacen que el entorno gráfico se venga abajo provocando un reinicio tras otro de la interfaz. El problema, según se comenta en bugzilla, es debido a los últimos cambios del HWComposer y/o algún conflicto con los controladores gráficos del ZTE. La forma más sencilla de prevenir este mal hasta que el parche sea incluido en una de las próximas actualizaciones es a través del menú de ajustes, deshabilitando el "Hardware composer": Ajustes -> Información -> Más Información -> Desarrollador -> Enable hardware composer Pero claro, si ya hemos actualizado y sin poder ver lo que ocurre en pantalla o sufriendo continuos reinicio ¿Cómo llegamos hasta ese menú? En este caso tendremos que llevar a cabo una pequeña chapuza previa para dejar fuera de juego el compositor. Para ello nos valdremos, una vez más, de ADB adb shell mv /system/lib/hw/hwcomposer.msm7627a.so /system/lib/hw/hwcomposer.msm7627a.s_ Como ven lo único que hemos hecho ha sido cambiar el nombre de la librería correspondiente al compositor dejándolo, momentáneamente, fuera de juego. Ahora, tras reiniciar el dispositivo, veremos que todo ha vuelto a la normalidad y podremos acceder al menú de ajustes para deshabilitar por fin el hwcomposer. Luego desharemos la chapuza, no vaya a ser que alguien la vea adb shell mv /system/lib/hw/hwcomposer.msm7627a.s_ /system/lib/hw/hwcomposer.msm7627a.so Aunque no es habitual, este tipo de cosas son las que pueden ocurrir por arriesgarse con versiones en desarrollo. Nada que no se resuelva con una pequeña búsqueda y trasteando un poco https://bugzilla.mozilla.org/show_bug.cgi?id=952916
  4. He detectado un 'bug' que se da en la versión 4 de LibreOffice que no aparecía en la versión 3, en Calc. Mi distribución es Debian y el programa que tengo instalado se encuentra en los repositorios. Por eso he pensado que quien debe conocer el problema es quien se encargue de su mantenimiento en Debian. El título del post es afirmativo porque confío en que entre todos pueda ser así. He leído que puede hacerse mediante el programa reportbug o a través de una cuenta de correo. Como soy novato, optaré por enviar un correo aprovechando la plantilla de reportbug "novice". En resumen, mi consulta es si voy a emplear el método correcto: Voy hasta esta página para comprobar que no existe el bug a reportar buscando el paquete concreto seleccionando el paquete, la versión de la distribución y otros detalles. Me remite a esta otra. Salto a la siguiente en que especifico que el paquete es libreoffice-calc y leo que NO está reportado el bug que creo que deben conocer estos señores. En un terminal escribo: reportbug -q --template -T none -s none -S normal -b --list-cc none -q libreoffice-calc para obtener una plantilla para informar acerca del bug. De todo el texto generado, creo que debo iniciar en donde se indica cómo redactar el correo: From: indicando mi cuenta de correo To: indicando el destinatario (en este caso, debian-openoffice@lists.debian.org) Subject: indicando la descripción del bug 'libreoffice-calc: Manage names no muestra el rango de los nombres de rango existentes' Y a partir de ahí, sigo las indicaciones con la descripción del error y cómo prodría resolverse incluso, y copio el resto de la información hasta la línea que dice "-- no debconf information" inclusive. Sugieren que incluso se incluyan archivos con el error, si no pesan mucho, o enlaces de acceso público a esos archivos. Creo que voy a incluir los enlaces de dos imágenes de Manage Names: una de la versión 3 (good) y otra de la versión 4 (bad) en que se aprecia el "error", en lugar de adjuntar los archivos (70 KB), que no pesan mucho pero aún menos los enlaces. Como mi nivel de inglés es parecido al que tenía la perra Laika, contrataré a un buen traductor después de redactarlo en español siguiendo las indicaciones que nos sugieren en esta página, procurando ser breve. Antes de darle al botón de 'Enviar' (y para no hacer demasiado el ridículo), ¿alguno de vosotros tiene experiencia en estas cosas?, ¿me olvido de algo?, ¿debo incluir algo en particular? Os agradezco vuestras opiniones y sugerencias.
  5. Recientemente se descubrió un extraño bug que provocaba corrupción de datos en particiones ext4, aunque eso sí bajo unas condiciones bastante extremas. El bug parece ser fruto de una combinación de diversos factores como la utilización de opciones no-estandar para el montaje, precedido por un desmontaje incorrecto de la partición, pero la principal causa era que las modificación del inode bitmap se llevaban a cabo sin terminar el jornaling. Esto podía llevar a una corrupción menor del sistema de ficheros después de un apagado no limpio bajo erróneas/desafortunadas cargas de trabajo, pero sólo se convertía en algo serio si el journal_checksum y/o el jouaral_async_commit estaban habilitados al mismo tiempo. Ya ha aparecido en Kernel.org una nueva versión de Linux (3.6.5) que debería incluir ya los parches pertinentes http://git.kernel.or...069cac20c09e160 EDITO El último "repaso" al bug de ext4 llega con Linux 3.6.6 ext4: fix unjournaled inode bitmap modification commit ffb5387e85d528fb6d0d924abfa3fbf0fc484071 upstream. commit 119c0d4460b001e44b41dcf73dc6ee794b98bd31 changed ext4_new_inode() such that the inode bitmap was being modified outside a transaction, which could lead to corruption, and was discovered when journal_checksum found a bad checksum in the journal during log replay. Nix ran into this when using the journal_async_commit mount option, which enables journal checksumming. The ensuing journal replay failures due to the bad checksums led to filesystem corruption reported as the now infamous "Apparent serious progressive ext4 data corruption bug" [ Changed by tytso to only call ext4_journal_get_write_access() only when we're fairly certain that we're going to allocate the inode. ] I've tested this by mounting with journal_checksum and running fsstress then dropping power; I've also tested by hacking DM to create snapshots w/o first quiescing, which allows me to test journal replay repeatedly w/o actually power-cycling the box. Without the patch I hit a journal checksum error every time. With this fix it survives many iterations. http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.6.6.tar.bz2
×
×
  • Crear Nuevo...