And Gabe said –I know! Google thinks a self-driving car is cool and revolutionary? Wait 'till they see our SELF-PLAYING GAME!
–Erm, that's... that's INGENIOUS sir! >.>
–I know, rite? I AM, rite!?
(later on)
–Sir, Reddit says to stop trying so hard. They say all we needed was «one Button to rule 'em all, one Button to press them, one Press to bring them all, and in the boredoom juice 'em.» They say... we make Farmville look good...
...
Sir?
–I. Want. /u/powerlanguage. SELF-DELETED...
domingo, 14 de junio de 2015
sábado, 23 de mayo de 2015
Problemas para conectar un iPod con Amarok o GTKPod
Al conectar el iPod, Amarok marca el error:
amarok --debug no aporta ningún error útil, pero si se conectó el iPod antes de iniciar Amarok, el mismo sufre una violación de segmento. El backtrace nos dice que el problema es con libgpod:
gtkpod también muere con SEGFAULT al tratar de leer el iPod. Al parecer, el problema sucede cuando libgpod intenta leer las estadísticas de reproducción en 'iTunes_Control/iTunes/PlayCounts.plist', y está arreglado en upstream desde el 2013, pero por alguna razón no lo está así en los repositorios. En teoría, compilar libgpod a mano debería solucionarlo. O, si no te importan las estadísticas de reproducción en tu iPod, puedes borrar o renombrar el fichero de las mismas como workaround –después de montar tu iPod:
Y asunto arreglado.
Conexión a iPhone, iPad o iPod fallida. ("Connecting to iPhone, iPad or iPod touch failed." -- determined mount-point path to /tmp/kde-USUARIO/amarok/imobiledevice_uuid_XXXXUUIDXXXX created /tmp/kde-USUARIO/amarok/imobiledevice_uuid_XXXXUUIDXXXX directory calling `ifuse "-u" "XXXXUUIDXXXX" "-ofsname=afc://XXXXUUIDXXXX" "/tmp/kde-USUARIO/amarok/imobiledevice_uuid_XXXXUUIDXXXX"` with timeout of 10s ifuse: usbmuxd_get_device_list: error opening socket! ifuse: No device found, is it connected? ifuse: If it is make sure that your user has permissions to access the raw usb device. ifuse: If you're still having issues try unplugging the device and reconnecting it. ifuse: command exited with non-zero return code 1 Failed to mount iPhone on /tmp/kde-USUARIO/amarok/imobiledevice_uuid_XXXXUUIDXXXX
amarok --debug no aporta ningún error útil, pero si se conectó el iPod antes de iniciar Amarok, el mismo sufre una violación de segmento. El backtrace nos dice que el problema es con libgpod:
#6 0x0000003c8803348d in type_check_is_value_type_U (type=133143986208) at gtype.c:4107 #7 g_type_check_value_holds (value=value@entry=0x1fcf5e0, type=type@entry=34428496) at gtype.c:4156 #8 0x00007f38f2296d0a in playcounts_plist_read (fimp=, fimp= , plist_data=0x2134570) at itdb_itunesdb.c:1178 #9 playcounts_init (fimp=0x1fc1600) at itdb_itunesdb.c:1319 #10 itdb_parse_internal (itdb=itdb@entry=0x1fe3950, compressed=compressed@entry=1, error=error@entry=0x7fffe3defac0) at itdb_itunesdb.c:3309
gtkpod también muere con SEGFAULT al tratar de leer el iPod. Al parecer, el problema sucede cuando libgpod intenta leer las estadísticas de reproducción en 'iTunes_Control/iTunes/PlayCounts.plist', y está arreglado en upstream desde el 2013, pero por alguna razón no lo está así en los repositorios. En teoría, compilar libgpod a mano debería solucionarlo. O, si no te importan las estadísticas de reproducción en tu iPod, puedes borrar o renombrar el fichero de las mismas como workaround –después de montar tu iPod:
ifuse /mnt/pda mv /mnt/pda/iTunes_Control/iTunes/PlayCounts.plist /mnt/pda/iTunes_Control/iTunes/PlayCounts.plist.bak
Y asunto arreglado.
martes, 3 de febrero de 2015
DeVeDe se cierra al seleccionar directorio de destino
DeVeDe nos permite transformar muchos tipos de video en DVD, pero tiene problemas con algunos temas GTK2. Cambiar el tema lo resuelve, ya sea en las Preferencias de Sistema > Apariencia de las Aplicaciones > GTK en KDE, o ejecutando en la línea de comandos (para solo cambiar el tema para DeVeDe):
El error:
env GTK2_RC_FILES=/usr/share/themes/Clearlooks/gtk-2.0/gtkrc devede
El error:
/usr/lib/devede/devede_convert.py:349: GtkWarning: gtk_tree_model_filter_get_value: assertion 'GTK_TREE_MODEL_FILTER (model)->priv->stamp == iter->stamp' failed value=wfolder_dialog.run() /usr/lib/devede/devede_convert.py:349: Warning: /build/buildd/glib2.0-2.42.1/./gobject/gtype.c:4221: type id '0' is invalid value=wfolder_dialog.run() /usr/lib/devede/devede_convert.py:349: Warning: can't peek value table for type '<invalid>' which is not currently referenced value=wfolder_dialog.run() Violación de segmento (`core' generado)
sábado, 31 de enero de 2015
Audacity sufre de buffer underruns al grabar, después distorsiona el audio y se traba
El error se repite hasta el infinito (y más allá):
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
Algún problema hay entre ALSA y Pulseaudio (bug en Launchpad). Solución temporal:
Para hacerla permanente:
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
Algún problema hay entre ALSA y Pulseaudio (bug en Launchpad). Solución temporal:
alias audacity='env PULSE_LATENCY_MSEC=30 /usr/bin/audacity'
audacity
Para hacerla permanente:
sudo sed -i 's/^Exec=.*/Exec=env PULSE_LATENCY_MSEC=30 audacity %U/' /usr/share/applications/audacity.desktop
echo "alias audacity='env PULSE_LATENCY_MSEC=30 /usr/bin/audacity'" >> ~/.bashrc
jueves, 15 de enero de 2015
Habilitando la captura de paquetes de Wireshark en Debian/*Ubuntu
Wireshark recomienda usar tcpdump para capturar, para no tener que otorgar privilegios extra (sin los cuales, nos marca el error "The capture session could not be initiated on interface 'wlan0' (You don't have permission to capture on that device)."
Si queremos usarlo para captura de todos modos, podemos habilitarlo en la configuración del paquete, añadir nuestro usuario al grupo de wireshark, y por último, iniciar wireshark usando su, si no queremos reiniciar sesión para que se reconozca el nuevo grupo:
Si queremos usarlo para captura de todos modos, podemos habilitarlo en la configuración del paquete, añadir nuestro usuario al grupo de wireshark, y por último, iniciar wireshark usando su, si no queremos reiniciar sesión para que se reconozca el nuevo grupo:
sudo dpkg-reconfigure wireshark-common sudo usermod -a -G wireshark $USER su -c wireshark - $USER
lunes, 12 de enero de 2015
La red de Kubuntu se duerme en telarañas
Empezaron al actualizar a 14.10, pero los problemas habían sido reportados desde antes:
Primero, la hibernación fue removida del menú en sistemas no certificados, porque parece tener problemas en un número significativo de laptops nuevas. Mientras se añade una opción al panel de configuración, podemos hibernar ejecutando sudo pm-hibernate en una terminal, o agregando de nuevo la opción al menú con:
Si la hibernación falla, hay que revisar que tengamos una partición de intercambio ("swap") de al menos el mismo tamaño que nuestra memoria RAM, por ejemplo ejecutando free -h, y verificando que el total de "Mem" sea mayor que el de "Inercambio".
Además, la red inalámbrica dejó de conectarse automáticamente al iniciar o despertar el sistema. Una solución temporal es editar la conexión y activar Todos los usuarios pueden conectarse a esta red en la pestaña de Configuración general.
Peor aun, la red se desactivaba por completo al despertar de una hibernación. Hay varias causas para esto; en mi caso, despertar NetworkManager a mano funcionó: sudo nmcli nm sleep false. Para otros, es necesario reiniciar el servicio: sudo restart network-manager. Para hacerlo automáticamente:
Primero, la hibernación fue removida del menú en sistemas no certificados, porque parece tener problemas en un número significativo de laptops nuevas. Mientras se añade una opción al panel de configuración, podemos hibernar ejecutando sudo pm-hibernate en una terminal, o agregando de nuevo la opción al menú con:
cat << 'FinDeTexto' | sudo tee /etc/polkit-1/localauthority/50-local.d/com.ubuntu.enable-hibernate.pkla [Re-enable hibernate by default in upower] Identity=unix-user:* Action=org.freedesktop.upower.hibernate ResultActive=yes [Re-enable hibernate by default in logind] Identity=unix-user:* Action=org.freedesktop.login1.hibernate;org.freedesktop.login1.hibernate-multiple-sessions ResultActive=yes FinDeTextoy reiniciando sesión después.
Si la hibernación falla, hay que revisar que tengamos una partición de intercambio ("swap") de al menos el mismo tamaño que nuestra memoria RAM, por ejemplo ejecutando free -h, y verificando que el total de "Mem" sea mayor que el de "Inercambio".
Además, la red inalámbrica dejó de conectarse automáticamente al iniciar o despertar el sistema. Una solución temporal es editar la conexión y activar Todos los usuarios pueden conectarse a esta red en la pestaña de Configuración general.
Peor aun, la red se desactivaba por completo al despertar de una hibernación. Hay varias causas para esto; en mi caso, despertar NetworkManager a mano funcionó: sudo nmcli nm sleep false. Para otros, es necesario reiniciar el servicio: sudo restart network-manager. Para hacerlo automáticamente:
cat << 'FinDeTexto' | sudo tee /etc/pm/sleep.d/01_networkmanager_wake_up
#!/bin/sh
case "$1" in
resume|thaw)
nmcli nm sleep false
;;
suspend|hibernate)
# Do nothing
;;
esac
FinDeTexto
Suscribirse a:
Entradas (Atom)