Conseguir código del bootmenu

Hola

Estoy intentando compilar la versión 0.7 desde Linux pero tengo un problema. La cosa es que el bootmenu.mk intenta descargarse el código fuente de bootmenu desde el svn de open7x0.org, pero el mismo ya no está disponible. ¿Existe algún sitio alternativo donde conseguirlo?

Concretamente se intenta descargar los fuentes de:
svn://open7x0.org/boxamp/tags/bootmenu/REL_0.2/src

¿Alguien ha hecho una copia del SVN de open7x0 antes de que haya desaparecido (quizás en github o en algún sitio parecido)?

Lo más parecido que he podido encontrar es https://github.com/stesee/open7x0.org pero no tiene los fuentes de bootmenu.

El bootmenu no es necesario para compilar la versión 0.7 y no creo que nadie aquí tenga una copia porque hace bastante tiempo que no lo usamos.

Puedes preguntar en el propio foro open7x0.org o mandar un mensaje privado en inglés al autor de ese código.
El autor es glotzi y puedes localizarlo en open7x0 o en este foro aquí, aunque no sé si sigue todavía por estos foros.

Si consigues el código, podemos añadirlo a nuestro SVN para tener una copia de seguridad.

Hola bittor

Ya he preguntado en open7x0 por el svn pero, de momento, no he recibido ninguna contestación.

Por otro lado... si el código de bootmenu no es necesario algo debo estar haciendo mal porque el make (ejecutado desde la raiz del toolchain) me falla al intentar construir por culpa de que no se lo puede descargar.

Voy a probar eliminando el fichero bootmenu.mk de make-incs y ver si así compila.



PD: Comentar también que para que el gcc-4.7.0 compile en mi equipo (que tengo actualizada la versión de textinfo a la 5) he tenido que modificar los ficheros cppopts.texi, generic.texi e invoke.texi del directorio build/gcc-4.7.0/gcc/doc (más info: https://bugs.archlinux.org/task/34000?project=1&openedfrom=-1+week ).

Confirma que en tu archivo .config tienes esto:

Código:

# CONFIG_BOOTMENU is not set

Por defecto está desactivado en las configuraciones lite y pro, pero si intenta compilarlo aparentemente es porque está activado.

Para evitar el problema con el gcc y textinfo, lo que hice en trunk fue desactivar directamente la generación de archivos info, porque no los necesitamos y así de paso aceleramos el proceso de compilación.
Puedes usar este parche de trunk copiándolo al directorio "patches/gcc/4.7.0" (este parche es mucho más simple y hace su función correctamente).

Si te funciona, lo paso para que se pueda compilar la versión 0.7.

Ok, parce que el parche funciona y he visto que es cierto que bootmenu está desactivado y por tanto no debería influir en el proceso de construcción.

Ahora bien, por alguna razón no se me procesa automáticamente yucompressor.mk y pngout.mk antes de procesar webif.mk (¿quizás habría que ponerlos como dependencias en el webif.mk?) y he tenido que forzar su ejecución "a mano" para que se pueda construir el webif al ejecutar el make.

Una vez solucionado esto, el proceso de construcción me falla con lo siguiente:

Código:

/toolchain/m7x0_xtc_uclibc_Linux-i686/bin/mksquashfs /toolchain/rootfs_dir_m740_pro /toolchain/rootfs-squash_m740_pro.img \
   -all-root -be -noappend -noI -no-fragments -d /toolchain/m7x0_xtc_uclibc_Linux-i686/stagefiles/file_tab.rootfs_dir_m740_pro.lst
Duplicate device table entry '/etc' in line  292
Duplicate device table entry '/etc' in line  304
Duplicate device table entry '/etc' in line  323
FATAL ERROR:Duplicate device table entry '/etc' in line (differs) 349
make: *** [/toolchain/rootfs-squash_m740_pro.img] Error 1

¿Alguna idea?

ACTUALIZACION: Ouch!! Creo que ya se donde está el problema... hoy se me olvidó hacer el umask 022 antes de relanzar el make... arggg!!!

Adjunto el fichero file_tab.rootfs_dir_m740_pro.lst donde, efectivamente, en la línea 349 se dan permisos 775 al directorio /etc, mientras que en el resto de apariciones se les da permiso 755 (¿de dónde sale esto? ).

NOTA: Lo mismo ocurre con el /etc/webif de la siguiente línea (350).

Haciendo la sustitución de los dos 775 por 755 "a mano" finalmente se generan los ficheros open7x0.org-m740-pro.ofi y open7x0.org-m740-pro.wsw (que aún no he podido probar )

rubensa escribió:Ok, parce que el parche funciona

Gracias, lo subo en cuanto pueda.

rubensa escribió:por alguna razón no se me procesa automáticamente yucompressor.mk y pngout.mk antes de procesar webif.mk (¿quizás habría que ponerlos como dependencias en el webif.mk?)

Ya están como dependencias, quizás sea algo de tu distribución Linux.

rubensa escribió:Adjunto el fichero file_tab.rootfs_dir_m740_pro.lst donde, efectivamente, en la línea 349 se dan permisos 775 al directorio /etc, mientras que en el resto de apariciones se les da permiso 755 (¿de dónde sale esto? ).

Ese archivo se genera dinámicamente usando los archivos .lst que hay en "rootfs-file-lists" y también pone las rutas y permisos de algunos archivos/directorios dentro de "buildin/base-<lite|pro>" y "prg-fw-configs", por eso si tu distribución no crea por defecto los archivos/directorios con 755 te va a dar error, porque en los .lst tienen 755 y los archivos que te has bajado del svn tendrán el que le de la gana a tu distribución, por eso hay que hacer el "umask 022", así nos aseguramos que siempre funcionará.

Gracias por tus respuestas @bittor

Como comenté tres mensajes atrás (editado después de poner mi último mensaje), tienes toda la razón en lo del umask (se me había olvidado establecerlo ya que en mi sistema -ArchLinux-, por defecto, es 002).

En cuanto a las dependencias de lo objetivos del make ¿dónde se supone que está especificado que la construcción del webif necesita que antes se construyan el yuicompressor y el pngout (tengo realmente verde el tema de los Makefiles ya que hace un montón de años que no reviso ninguno)?

Yo, para solicionarlo, he tenido que cambiar en el webif.mk esto:

Código:

#
# copy webapp
#
$(STAGEFILES_DIR)/.webif_copied: $(STAGEFILES_DIR)/.webapp_downloaded


por esto:

Código:

#
# copy webapp
#
$(STAGEFILES_DIR)/.webif_copied: $(STAGEFILES_DIR)/.webapp_downloaded $(YUI_COMPRESSOR_JAR) $(HOSTUTILS_PREFIX_BIN)/pngout


EDITADO: Aunque aquí se vea cortado, la regla que está después de los comentarios va en una única línea.

(vamos, decir que el target .webif_copied depende no solo del .webapp_downloaded sino también de la obtención del jar de yuicompressor y del binario de pngout)

Las dependencias del yui_compressor y pngout en webif se definen sólo si están activados en el .config y están aquí:

Código:

ifeq ($(CONFIG_YUI_COMPRESSOR),y)
   WEBIF_DEPS +=  $(YUI_COMPRESSOR_JAR)
endif
ifeq ($(CONFIG_PNGOUT),y)
   WEBIF_DEPS +=  $(PNGOUT_BIN)
endif

De esta manera puedes generar un webif sin "reducir" con los archivos originales.

Y luego en esta línea está el WEBIF_DEPS como dependencia:

Código:

$(STAGEFILES_DIR)/.webif_compiled: $(STAGEFILES_DIR)/.webif_copied $$(WEBIF_DEPS)

Pero has detectado un error y debería estar en el ".webapp_downloaded" como has puesto tú, aunque usando "WEBIF_DEPS" porque si no tienes estos programas activados en el .config no son una dependencia.

Ya está corregido en el SVN en 0.7 y trunk, thx.

Vaya!! Tienes toda la razón!! No me había fijado que se definían más arriba. Solamente me había fijado en las dependencias del .webif_compiled

Bueno, con estos cambios (y solucionado el problema de los permisos) parecía que todo tenía que ir bien pero... ahora me encuentro con este error:

Código:

make[1]: Entering directory `/toolchain/build/slin_m740_pro'
mips-linux-egcs -D__KERNEL__ -I/toolchain/build/slin_m740_pro/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /toolchain/build/slin_m740_pro/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mcpu=vr4100 -mips2 -Wa,--trap,-mfix-vr4120  -DKBUILD_BASENAME=main -c -o init/main.o init/main.c
as: unrecognized option '-G'
In file included from /toolchain/build/slin_m740_pro/include/linux/blkdev.h:11,
                from /toolchain/build/slin_m740_pro/include/linux/blk.h:4,
                from init/main.c:25:
/toolchain/build/slin_m740_pro/include/asm/io.h:496: warning: `CONFIG_NONCOHERENT_IO' redefined
/toolchain/build/slin_m740_pro/include/linux/autoconf.h:860: warning: this is the location of the previous definition
init/main.c: In function `calibrate_delay':
init/main.c:167: warning: unused variable `lps_precision'
init/main.c:166: warning: unused variable `loopbit'
init/main.c:166: warning: unused variable `ticks'
init/main.c:213: output pipe has been closed
make[1]: *** [init/main.o] Error 1
make[1]: Leaving directory `/toolchain/build/slin_m740_pro'
make: *** [/toolchain/m7x0_xtc_uclibc_Linux-i686/stagefiles/.siemens-linux-kernel_m740_pro_compiled] Error 2


¿antes te había generado el wsw y ofi pero ahora no?
¿has probado a generar el firmware sin tocar ningún archivo Makefile tal y como está en el SVN?

Creo que puede ser un problema con el PATH y use el programa "as" de tu host.
Comprueba el PATH que pone cuando se ejecuta el make del kernel, sería una línea de este estilo:

Código:

PATH='...:...:...' make CROSS_COMPILE=

Hola bittor

Voy a intentar realizar una compilación "limpia" descargandome todo desde el principio, otra vez. A ver si así compila bien.

PD: Sí, anteriormente me había llegado a generar el wsw y el ofi así que alguna cosa tuve que tocar para que dejase de compilar (aunque no soy consciente de ello ).

Hurra!!! I'm ready to rumble!!

Esta vez todo fué ok y ya tengo generados el open7x0.org-m740-pro.ofi y el open7x0.org-m740-pro.wsw.

PD: Por cierto, una duda... ¿porqué no hay una versión pre-generada para su descarga directa? (Ya se que el generador de windows se basa en partes ya generados y solamente "junta" todo según las preferencias de cada usuario pero entiendo que sería más sencillo poder descargar directamente una versión completa pre-generada con las opciones por defecto)

Muchas gracias por tu ayuda bittor (ya se que no es facil estar al pié del cañón para ayudar una y otra vez a la gente con menos experiencia )

Puedes buscar GPL en el foro (usando la opción de Google) y verás por qué no publicamos un firmware completo, pero básicamente porque es ilegal distribuir binarios (los drivers) que proceden de código GPL sin publicar el código fuente con los cambios que ha hecho Siemens, incluso ellos tampoco pueden hacerlo y lo hacen.
En el caso de que los drivers no fueran GPL tendríamos que tener el permiso expreso de Siemens para hacerlo.

Yo lo denuncié a la Free Software Foundation y gpl-violations.org pero no sirvió de nada.

Gracias por la aclaración.

De hecho, había visto la publicación que tienes en tu web al respecto (de la ilegalidad de Siemens) pero dado que ellos (entiendo que) argumentan que su código es "cerrado", supuse que no habría problema en que diesen permiso para redistribuir sus drivers (máxime teniendo en cuenta que actualmente se trata de un producto "obsoleto" ).

Pregúntale a Microsoft si puedes distribuir drivers de su Windows 2000 porque está obsoleto

Siemens (al menos antes) no quiere firmwares alternativos, por eso cuando los alemanes crackearon la clave RSA privada para firmar los firmwares y poder instalar firmwares no oficiales como Lemmi aumentaron la longitud de la clave y actualizaron su firmware para que sólo admitiera esa nueva clave, aunque desde el menú de los 4 apagados se podía instalar un firmware con la clave vieja porque no actualizaron esa parte.
Aunque finalmente Siemens publicó la nueva clave por la presión de gpl-violations.org, seguro que no les hizo mucha gracia.

Así que no te van a dar permiso para incluir los drivers en un firmware que no es suyo, aunque quizás en este momento les de igual y te den hasta el código fuente, lo que nos permitiría corregir los diversos errores que tienen y actualizar nuestro anciano kernel.