{11} Ticket changes (100 matches)

Añadida la ayuda en pseint_20090408-max4

Es un bug de la maqueta y no del software... cerrando.

 https://bugs.launchpad.net/ubuntu/+source/mscore/+bug/292391

Parece que se arregla configurando el dispositivo ALSA como "hw:0" en lugar de default.

Voy a precargarlo....

Arreglado en max-skel-conf_5.0.max10 r570

Ya se han realizado las actualizaciones correctamente. Gracias.

Pues tras varios arranques creo que puedes cerrar el ticket.

Replying to mario.izquierdo:

Es gracioso pero en MaX 5.0 no existe el grupo scanner.

¿tiene que ver con la versión del kernel?. (lo del grupo, no creo, y lo de la creación del dispositivo)

Lo digo porque, yo juraría que he utilizado el escaner desde max5

Antes de instalar (sobre todo cuando se suben paquetes nuevos con bastante rapidez al repositorio) se suele pulsar el botón actualizar para que descargue las últimas versiones disponibles....

Y el icono blanco de TCOS se debe a que cuando instalas no tienes internet. Pincha un cable o configura la wifi y se instalarán los paquetes normalmente. Para la rc3 se podrá instalar sin internet.

En max4

crw-rw---- 1 root scanner 21, 2 2009-11-11 18:20 /dev/sg5

El dispositivo pertenece al grupo scanner y con poner madrid, o los usuarios, en el grupo todo funciona

Replying to mario.izquierdo:

¿Puedes ver los permisos del dispositivo?

crw-rw---- 1 root root 21, 5 2009-11-10 16:52 /dev/sg5

¿Has instalado VirtualBox? de la web oficial en lugar de el de MaX?

En esta máquina no he instalado vbox, ni este MAX se ejecuta sobre una máquina virtual.

El "error" de los permisos sobre este dispositivo ocurría en max3, en max4 ya no ocurrió.

Quizá relacionado:

En MAX4 con el escaner apagado y el equipo encendido, enciendes el escaner y al poco tiemepo puedes escanear. En MAX5 en la misma situación el dispositivo sg5 no se crea y tienes que reiniciar el equipo

Me ha pasado una vez y creo que el culpable era el paquete isdntools, lo he quitado para la rc3 y parece que se apaga bien.

De todos modos lo dejo abierto.

Arreglado en ubiquity-frontend-max (5.0.max0.11) r568

Subido paquete ltspfs-server_0.2-cvs20060920-max3 que entra en conflicto con los otros.

Visto...

Parece que falla cuando no hay conexión a internet. Lo revisaré e intento reproducirlo.

• Actualizar pingüinos de la galleta (solucionado)
• Quitar tipo de instalación Servidor (ya no existe) (solucionado)
• La contraseña de root no existe (se usa la contraseña de madrid para hacer sudo su) (solucionado)
• No hay contraseñas en modo live (la del usuario madrid está vacía) (solucionado)
• Kernel 2.6.28.16 (solucionado)
• Quitar la parte de créditos MaX 4.0 (solucionado)
• Quitar Kompozer del menú internet (sólo esta en Programación) (solucionado)

/var/log/installer es depués de reiniciar... si no has reiniciado el archivo sería /var/log/syslog

Hecho en max-meta 5.0.max46

En el DVD rc2 amd64 me lo ha instalado bien.

Necesito el directorio /var/log/installer en un equipo que no se haya podido instalar para ver de donde viene el problema.

Arreglado en moodle (1.9.5-0max2)

Fernando Lisón lo ha probado y funciona.

• Quitar la parte de créditos MaX 4.0
• Quitar Kompozer del menú internet (sólo esta en Programación)

Corregido en max-lxde-default-settings (5.0.max14) r556

Arreglado en max-meta (5.0.max43) r551

max-hardware va instalado en la nanoMaX: http://max.educa.madrid.org:8000/browser/trunk/max-meta/nanomax-i386#L33

y dentro de max-hardware en cada arranque se ejecuta esto: http://max.educa.madrid.org:8000/browser/trunk/max-hardware/debian/max-hardware.init

Si el modelo es 700 o 750 debería estar esta línea.

Aceptado para quitar, motivos de la lista:

• Nadie utiliza xtide para nada (nada confesable al menos)
• Estamos a salvo de sunamis sureños porque nos avisarían desde Malaga y de los demás me ha dicho Esperanza que ella se encarga.

Si se necesitan votos, añadir uno más :)

Ticket no valido en rc2, ya que sólo se produce desde rc1 a rc2

Perfecto. En la nueva actualización todo correcto

Arreglado en max-meta (5.0.max42) r545

Se usará el driver xserver-xorg-video-intel-2.4

Arreglado y subido, ahora i386 y amd64 tienen el mismo número de versión.

Arreglado en (5.0.max30)

En esa misma página de descarga, más abajo han añadido algunos enlaces a archivos .deb anteriores y archivos fuente.

Saludos.

Parcheado, compilado y probado, parece que ya no peta con el muelle.

Me huele que la solución puede estar en la forma de trabajar de nautilus-share

nautilus-share for Debian
-------------------------

A quick and easy way to have it running (must be done as root):

#export USERSHARES_DIR="/var/lib/samba/usershares"
#export USERSHARES_GROUP="sambashare"
#mkdir ${USERSHARES_DIR}
#groupadd ${USERSHARES_GROUP}
#chown root:${USERSHARES_GROUP} ${USERSHARES_DIR}
#chmod 01770 ${USERSHARES_DIR}
#mv /etc/samba/smb.conf{,.bak}
#cp /usr/share/doc/nautilus-share/examples/smb.conf /etc/samba/
#/etc/init.d/samba restart

You must add users who can share folder in the usershare group, in this example the group is "sambashare":

#usermod -a -G sambashare your_username

Quizás haya que mezclar /usr/share/doc/nautilus-share/examples/smb.conf con nuestro /usr/share/max-skel-conf/etc/samba/smb.conf

Solucionado.

Hoy lo probé y funciona. En alguna actualización

 http://bit.ly/5v2bG

Posterior a tu propuesta de solución en la lista:

Cada vez que se instale o se actualice el paquete maxmoodle se va a ejecutar esto:

http://max.educa.madrid.org:8000/browser/trunk/maxmoodle/usr/sbin/configure-moodle?rev=513

Lo que hace es muy simple, en los host permitidos ponemos 3 en lugar de uno: 127.0.0.0, 127.0.1.0 y por si las moscas el hostname original (max50)

Lo otro que edita del config.php es para permitir a moodle que no tengra grabao al fuego sólo el acceso localhost, sino que use el SERVER_NAME de apache.

Amd64 con la instalación de moodle realizada anteriormente. Después de actualizar los paquetes el lanzador abre una ventana de error. Adjunto pantallazo