Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'compilar'.

  • 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 16 resultados

  1. Tenía ganas de probar RetroArch, y ya como no encontré mucha información sobre como compilarlo y renegué bastante dejo una mini guía Teóricamente RetroArch es una interfaz (frontend) para la API de libretro. libretro es una interfaz de desarrollo (API) que permite la creación de emuladores, juegos y programas de multimedia que pueden correr fácilmente en cualquier interfaz (frontend) compatible. Lo que tiene de bueno es que RetroArch carga los emuladores como "cores", entonces uno puede elegir los emuladores (o cores) que uno quiera y cargarlos con RetroArch. Entonces RetroArch termina siendo como un emulador de todas las consolas que uno quiera, desde el programa se elige la consola que se quiere emular (se elige el core) y se carga la ROM que uno quiera Yo descargué RetroArch y todos los cores con un repositorio que se llama libretro-super, que sería algo así como un instalador. A lo mejor es demasiado descargar todos los cores porque son muchos, pero no sabía como hacer para descargar de a uno y además esta bueno tener emuladores de todas las consolas aunque no las vaya a usar Otras páginas que pueden ser útiles: http://libretro.com/forums/showthread.php?t=1645 https://github.com/libretro/RetroArch http://wiki.libretro.com/index.php?title=RetroArch_Compilation http://emulation-general.wikia.com/wiki/Building_RetroArch https://github.com/libretro/RetroArch/wiki/Compilation-guide-%28Linux%29 Yo usé un Debian 8 Jessie Stable con Gnome recíen instalado y todo por defecto. Si tenés Ubuntu a lo mejor te conviene instalar desde el PPA en vez de compilar ya que es más fácil, creo que no es bueno usar el PPA de Ubuntu en Debian Para compilar se necesita bastante espacio, mi carpeta pesaba 5.6GB, pero una vez instalado se puede borrar esa carpeta y queda una de 1.8GB No encontré bien cuáles son las dependencias que se necesitan para compilar, con las que instalé pude instalar casi todos los cores. Las dependencias serían todos los paquetes que instalé con aptitude install, si hay problemas los links de arriba tienen listas de paquetes que pueden hacer falta. sudo aptitude update sudo aptitude upgrade sudo aptitude install git pkg-config libegl1-mesa-dev libgl1-mesa-dev libsdl2-dev zlib1g-dev libavcodec-dev libasound2-dev libavformat-dev libavutil-dev libswscale-dev libgbm-dev libdrm-dev libxml2-dev libv4l-dev libfreetype6-dev libudev-dev python3 qmake make gcc g++ cd Escritorio Lo que hace git clone es descargar los archivos de libretro-super git clone git://github.com/libretro/libretro-super.git Vamos a la carpeta descargada cd libretro-super Esto va a descargar RetroArch y todos sus cores (no sé como descargar core por core), son muchos archivos y puede que se descarguen algunos mal, así que conviene ejecutarlo varias veces hasta que deje de descargar cosas, solo va a volver a descargar los que estén mal y si está todo bien dice "Already up to date" ./libretro-fetch.sh Esto compila RetroArch, si hay errores hacer libretro-fetch puede solucionarlo, también puede que el error sea porque faltan dependencias, leer el error puede ayudar a encontrar qué paquete falta ./retroarch-build.sh Esto compila todos los cores, también, si hay errores libretro-fetch puede solucionarlo, también puede que el error sea porque faltan dependencias NOCLEAN=1 ./libretro-build.sh Al final muestra algo como esto Se puede volver a intentar compilar los cores que estén marcados como fallidos, por ejemplo mame078 se me compiló en el tercer intento, para hacer libretro-fetch de un solo core se puede hacer por ejemplo ./libretro-fetch.sh mame078 Y para compilar de a uno es parecido (no se si al compilar de a uno hace falta el NOCLEAN) NOCLEAN=1 ./libretro-build.sh mame078 No pude compilar el core ffmpeg porque uso libav y por lo que vi hay que hacer algunas modificaciones al makefile, todos los que estaban en el mensaje anterior como fallidos no los pude compilar Lo que sigue es para instalar todo, se puede instalar en cualquier lugar, yo lo instalé dentro de RetroArch en la carpeta personal (por eso el ~) mkdir -p ~/RetroArch/cores Hay que moverse a la carpeta retroarch que está dentro de libretro-super, no a la recien creada cd retroarch Acá si se escribe la carpeta recién creada make DESTDIR=~/RetroArch install cd .. ./libretro-install.sh ~/RetroArch/cores Para probar que ande bien se puede abrir RetroArch desde ~/RetroArch/usr/local/bin/retroarch Para moverse en los menús usa las flechas, para seleccionar usa x, para volver z, para salir Esc y hay configur aciones que se cambian con las fle chas de los costados Yo lo primero que probé es el core 2048, que es un juego independiente. Ir a Load core y navegar hasta el core (entrar en / (lo único que hay) e ir a /home/usuario/RetroArch/cores/2048_libretro.so) Para apretar start usa Enter, para jugar usa las flechas, en este juego se deben ir uniendo los bloques de igual valor, al apretar una flecha todos los bloques caen a esa dirección Para salir de RetroArch apreta Esc, o para abrir el menú (QuickMenu) usa F1 Para los emuladores hice una carpeta roms en ~/RetroArch, adentro le puse subcarpetas como n64, snes, gba, etc. una para cada consola En Settings - Directory se puede elegir la ubicacion predeterminada para varias cosas, por ejemplo para los cores. Para elegir el directorio predeterminado de los cores hay que ir a Core Dir y navegar hasta la carpeta con los cores, una vez ahí seleccionar <Use this directory> Otra ubicación útil es File Browser Dir, especifica desde donde el navegador de archivos comienza al elegir carpeta o algun archivo, conviene elegir /home/usuario/RetroArch. Entonces por ejemplo ahora al elegir ROM (Content) el explorador de archivos empieza desde ahí Para emular algún juego se debe elegir el core correspondiente a la consola y después elegir la ROM en Load Content - Select File. Hay una característica para configurar una colección, supongo que es para organizar mejor las ROMs, pero no puedo hacerla funcionar. Si la ROM está en un zip puede que te pregunte cómo abrirla, hay que seleccionar Load Archive With Core En Settings - User se puede elegir el idioma con las flechas de los costados, pero prefiero inglés antes que español porque en español los textos son muy largos y no entran en la pantalla Para cambiar los controles del jugador 1 hay que ir a Settings - Input User 1 Binds Los controles de RetroArch, como por ejemplo Esc para salir o F1 para el menú se pueden cambiar desde Settings - Input Hotkey Binds No tengo ningún Joystick, pero supongo que para configurar uno hay que ir a Settings - Input y ahí seleccionar qué Joytick usará cada jugador, luego hay que ir a Settings - Input User 1 Binds para elegir los controles Para poder configurar los analógicos usando el teclado tuve que cambiar el Bind Mode a RetroKeyboard (En Settings - Input) Otra cosa que se puede hacer es agregar RetroArch al menú de aplicaciones con MenuLibre (Ya hay bastantes tutoriales sobre eso) Para guardar el progreso de los juegos se puede hacer como si se tratara de una consola, guardando desde el juego. Si no se puede usar Save State y Load State desde el QuickMenu (que se abre al apretar F1 mientras se está jugando), de esta forma se guarda el juego exáctamente como está en este momento (es algo así como hacer trampa). Si se selecciona Load o Save State y se apreta la flecha de los costados se puede elegir el Slot desde el que se está guardando o cargando Si todo anda bien se puede borrar la carpeta libretro-super que tendría que estar en el Escritorio en donde se compiló todo Si hay algo mal en la guía estaría bueno que lo aclaren en los comentarios
  2. Hace tiempo escribí un tema similar y aunque las ansias de trastear siguen siendo las mismas, hay cosas que debemos poner al día. Es por eso que he querido rehabilitar esta "pequeña" guía que a más de uno, incluyéndome, le ha servido de ayuda en más de una ocasión Importante: Todos los comandos son ejecutados como Root, salvo el utilizado para la descompresión del kernel. Si usas Ubuntu o derivados, anteponer siempre sudo. Paciencia, no apresurarse, el proceso no es complicado, pero hay que ser meticulosos, y tomarse tiempo para indagar y recapacitar Un kernel con demasiados añadidos será muy lento, y uno con muy pocos, estará muy limitado en compatibilidad. Buscar un término medio aceptable La regla de oro a la hora de configurar el kernel será: Si no se sabe o no se está seguro, no se toca Utilizaré dos métodos (Y algunas variantes) distintos para compilar el kernel: Método General Método Debian Método "Externo" Proceso de configuración (es igual para todos los métodos) Otros procedimientos útiles https://www.kernel.org/doc/Documentation/
  3. Gracias a la excelente información que existe en la web para desarrolladores de Mozilla y movido por el contenido del blog de Eduardo González, que fue el que me dio los pasos para meterle mano al Zte Open de una manera más profunda he decidido liarme nuevamente la manta a la cabeza y tratar de actualizar mi ZTE Open compilando directamente el código fuente de una de las últimas versiones disponibles de Firefox OS Antes de empezar con el meollo tengo que aclarar, para aquellos más experimentados que lo estén pensados, no hay posibilidad de fastboot, tiene que ser por la bravas dejando el smartphone otra vez "De fábrica" Dicho eso, he aquí una crónica del suceso, aunque no revelaré si lo conseguí a la primera o me quedé con un pisapapeles azul muy bonito que tuve que resucitar Empezaremos haciendo acopio de todos los paquetes que vamos a necesitar para poder llevar a cabo el proceso Dependencias Debian aptitude install cmake autoconf2.13 bison bzip2 ccache curl flex gawk gcc g++ g++-multilib git lib32ncurses5-dev lib32z1-dev zlib1g:amd64 zlib1g-dev:amd64 zlib1g:i386 zlib1g-dev:i386 libgl1-mesa-dev libx11-dev make zip libxml2-utils ADB aptitude install android-tools-adb Make Para poder compilar con éxito B2G tendremos que recurrir a Make 3.81, es decir, una versión anterior a la que tendemos en repositorios de Debian stable/Testing wget http://ftp.us.debian.org/debian/pool/main/m/make-dfsg/make_3.81-8.2_amd64.deb dpkg -i make_3.81-8.2_amd64.deb rm make_3.81-8.2_amd64.deb Dependencias Fedora 17/18/19 yum install cmake autoconf213 bison bzip2 ccache curl flex gawk gcc-c++ git glibc-devel glibc-static libstdc++-static libX11-devel make mesa-libGL-devel ncurses-devel patch zlib-devel ncurses-devel.i686 readline-devel.i686 zlib-devel.i686 libX11-devel.i686 mesa-libGL-devel.i686 glibc-devel.i686 libstdc++.i686 libXrandr.i686 zip perl-Digest-SHA wget ADB yum install android-tools Make Para poder compilar con éxito B2G tendremos que recurrir a Make 3.81, es decir, una versión anterior a la que tendemos en repositorios de Fedora 17 o superior curl -O https://people.mozilla.org/~gsvelto/make-3.82-fc21.tar.xz sudo tar -x -a -C /opt -f make-3.82-fc21.tar.xzEn el archivo .userconfig añadir PATH=/opt/make-3.82/bin:$PATH Dependencias Arch Linux pacman -S --needed cmake alsa-lib autoconf2.13 bison ccache curl firefox flex gcc-multilib git gperf libnotify libxt libx11 mesa multilib-devel wget wireless_tools yasm zip lib32-mesa lib32-mesa-libgl lib32-ncurses lib32-readline lib32-zlib Debemos forzar el uso de Python 2.X sudo pacman -S python-virtualenvwrapper source /usr/bin/virtualenvwrapper.sh mkvirtualenv -p `which python2` firefoxos workon firefoxos Make Para poder compilar con éxito B2G tendremos que recurrir a Make 3.81, es decir, una versión anterior a la que tendemos en repositorios de Arch, pero que está disponible en AUR yaourt -S make-3.81 Limitar ccache ccache --max-size 10GB Configurar Udev para el terminal a actualizar, en este caso el ZTE Open: nano /etc/udev/rules.d/android.rulesEl contenido debe incluir la ID del fabricante y del dispositivo. En nuestro caso: Damos permisos y reiniciamos el servicio chmod a+r /etc/udev/rules.d/android.rules service udev restartSin olvidar que en el teléfono, dentro de las opciones para desarrolladores debemos tener habilitada la opción "Depuración Remota" Hacemos un backup de los datos del teléfono, pues con el flasheo se perderá todo, así que vamos a guardar lo que tenemos por si la cosa no acaba como esperamos podamos devolver el teléfono a su estado anterior. adb pull /system system adb pull /data data adb pull /vendor vendor Desbloquear el ZTE para instalar "custom rooms" Para esto utilizaremos ClockWorkMod recovery. recovery-clockwork-6.0.3.3-roamer2.img NOTA Antes de aventurarnos a hacer esto tendremos que haber rooteado el Zte Ope, de lo contrario no podremos hacer los cambios pertinentes porque no tendremos permisos Primero haremos un backup de nuestra imagen recovery de fábrica por si acaso (Usaré /data/local/tmp como intermediario) adb shellDentro del terminal nos logueamos root y salvamos los datos de fábrica su dd if=/dev/mtd/mtd0 of=/data/local/tmp/stock-recovery.img bs=4kLa guardamos en nuestro PC adb pull /data/local/tmp/stock-recovery.imgY ahora flasheamos la imagen de desbloqueo clockwork que descargamos antes adb push recovery-clockwork-6.0.3.3-roamer2.img /data/local/tmp/cwm.img adb shell su flash_image recovery /data/local/tmp/cwm.imgAhora ya podremos flashear nuestro Zte Open con cualquier Rom sin preocuparnos de la firma Obtener el código fuente de B2G De entrada quiero recalcar que el ZTE Open está incluido como dispositivo INARI, así que no debemos olvidarnos de configurar B2G como tal antes de empezar a compilar. Descargamos el código fuente con el que vamos a trabajar git clone https://github.com/mozilla-b2g/B2G.git cd B2GPara posteriores compilaciones, podremos actualizar el código fuente de B2G ejecutando: git pull ./repo sync Configurar Firefox OS Compilar la última versión de Firefox OS Y repito, para el ZTE Open especificaremos que es un dispositivo INARI ./config.sh inariEste proceso es muy lento, pues tiene que descargar la mayor parte de los componentes sobre la marcha, así que tendremos por delante un par de horas de descarga. Afortunadamente podemos detener el proceso en cualquier momento (Control + C) y retomarlo más tarde donde mismo lo dejamos NOTA Es posible que al intentar configurar recibamos un error indicándonos que no se ha podido verificar la clave pública. Podemos solucionarlo de la siguiente manera curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ./repo chmod a+w repoY volvemos a ejecutar el ./config.sh ./config.sh inari Compilar una versión concreta de Firefox OS Aunque compilar la última versión de Firefox OS disponible en el repositorio git es tentador, es muy probable que muchos de nosotros obtemos por una de las versiones anteriores de canales más "estables". Para eso tendremos que especificarlo de la siguiente manera BRANCH=versión ./config.sh dispositivoSi no estamos seguros de qué versiones son las que están disponibles podemos ejecutar el config.sh sin más y una de las primeras cosas que nos aparecerán en la terminal es precisamente la lista de versiones: v1.2.0, v1.3, v1.4, v2.0, v2.2, etc Por ejemplo, si quisiéramos compilar la versión 2.2 para nuestro Zte Open lo configuraríamos así BRANCH=v2.2 ./config.sh inari Incluir más idiomas en la imagen Descargaremos los locales que nos interesen desde https://hg.mozilla.org/gaia-l10ncon mercurial y los incluiremos dentro del directorio gaia, dentro de locales cd gaia/locales/ hg clone https://hg.mozilla.org/releases/gaia-l10n/esY exportamos dichas locales export LOCALE_BASEDIR=$PWD/gaia/locales export LOCALES_FILE=$PWD/gaia/locales/languages_dev.json export GAIA_DEFAULT_LOCALE=esPodemos sustituir el languages_dev.json por nuestro propio languages_own.json, que contendrá sólo los idiomas que hayamos decidido utilizar: { "en-US" : "English (US)", "es" : "Español" }Sólo tendríamos que introducir la ruta correcta hacia el nuevo archivo export LOCALE_BASEDIR=$PWD/gaia/locales export LOCALES_FILE=$PWD/gaia/locales/languages_own.json export GAIA_DEFAULT_LOCALE=esEn lo referente al teclado, podremos definir los idiomas disponibles mediante el comando GAIA_KEYBOARD_LAYOUTS= GAIA_KEYBOARD_LAYOUTS=en,es,it Compilar B2G Compilar lleva su tiempo, nos da tiempo de darnos una vuelta mientras todo termina En este punto el teléfono para el que vamos a compilar la imagen tiene que esta conectado para que, mediante adb, el script de compilado e instalación pueda acceder a él ./build.shSin olvidar que si queremos modificar algo o afinar el proceso un poco más, ya sea para definir los nuevos locales como para opciones de resolución o actualización, tendremos que añadir las opciones correspondientes precediendo al Build. Entre las opciones más interesantes tendríamos: MOZILLA_OFFICIAL=1 Esta opción nos permite construir la imagen como si fuera una oficial de Mozilla PRODUCTION=1 Esta opción hace que creemos una imagen de Gaia de producción, no de desarrollo GAIA_OPTIMIZE=1 Habilitando esta opción conseguimos optimizar el desempeño javascript de Gaia concatenando/comprimiendo los archivos. GAIA_MEMORY_PROFILE=low Esta variable genera una versión de Gaia con un perfil de baja memoria, especialmente recomendado para dispositivos de bajos recursos como el Inari o el Tarako. B2G_SYSTEM_APPS=1 Esta opción hace que las aplicaciones terminen en /system/b2g en lugar de en /data/local. Esto es útil cuando tratamos de crear una imagen para el usuario común. B2G_UPDATER=1/td][td]Habilitar el sistema de actualizaciones B2G_UPDATE_CHANNEL=default Definir el canal de actualización para Firefox OS Para conocerlas todas podemos recurrir a la sección correspondiente dentro de la página de desarrolladores de Mozilla https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/make_options_reference Anteponiendo las opciones que vayamos a utilizar al ./build.sh ya sólo quedaría ejecutar y sentarnos a esperar PRODUCTION=1 GAIA_MEMORY_PROFILE=low GAIA_KEYBOARD_LAYOUTS=en,es LOCALES_FILE=gaia/locales/languages-own.json GAIA_OPTIMIZE=1 B2G_UPDATER=1 B2G_UPDATE_CHANNEL=default ./build.shListo. Si todo ha salido bien ya tenemos lista la nueva versión de Firefox OS que posteriormente subiremos a la memoria de nuestro Zte Open Install system fs image: out/target/product/inari/system.img out/target/product/inari/system.img+ total size is 115264512 real 31m23.018s user 86m23.456s sys 5m25.260s Run |./flash.sh| to flash all partitions of your device Actualizando Nuestro ZTE Por ha llegado el momento de poner a prueba el fruto de nuestro esfuerzo. ./flash.shPara evitar que se instalen las herramientas para desarrolladores, podemos indicarle que queremos usar el sistema como usuarios comunes: VARIANT=user ./flash.sh gaia NOTA: Para actualizar partes concretas del sistema sólo tendremos que especificar cuáles. oNormalmente, las que nos interesan son Gaia y Gecko cd B2G ./flash.sh gaia ./flash.sh geckoSi el teléfono se queda en "el limbo", ejecutaremos lo siguiente desde el directorio B2G para reiniciar Gaia cd gaia make reset-gaia Rooteo profundo Haremos uso de la herramienta abootimg. La instalamos desde repositorios de nuestra distribución Debian aptitude install abootimg Fedora yum install abootimg Arch pacman -S abootimgEntramos al teléfono vía adb shellNos logueamos como root y ahora vamos a extraer la partición boot original (Usaré /data/local/tmp como intermediario): cat /dev/mtd/mtd1 > /data/local/tmp/boot.imgLa extraemos con adb adb pull /data/local/tmp/boot.imgAhora haremos uso de abootimg abootimg -x boot.imgCreamos un subdirectorio a_dir, entramos en él y expandimos initrd.img mkdir a_dir; cd a_dir gunzip -c ../initrd.img | cpio -idmvCambiamos el contenido de default.prop con el siguiente texto # # ADDITIONAL_DEFAULT_PROPERTIES # ro.secure=0 ro.allow.mock.location=1 ro.debuggable=1 persist.usb.serialno=full_inari persist.sys.usb.config=adbAhora debemos crear un nuevo ramdisk con el contenido original y el archivo default.prop modificado ../B2G/out/host/linux-x86/bin/mkbootfs . | gzip > newinitramfs.cpio.gzEmpaquetamos la nueva imagen boot.img con el ramdisk modificado cd .. B2G/out/host/linux-x86/bin/mkbootimg --kernel zImage --ramdisk newinitramfs.cpio.gz --base 0x200000 --cmdline 'androidboot.hardware=roamer2' -o newboot.imgReiniciamos el teléfono en modo CWM recovery (Botón de encendido + subir volumen) para poder flashear boot con toda seguridad. Montamos la tarjeta SD desde el menú de CWM Subimos al teléfono la nueva imagen boot, bien con adb o con con el administrador de ficheros copiando directamente la imagen a la tarjeta SD adb push newboot.img /sdcard/newboot.imgLuego entramos al teléfono vía adb shell para flashear el nuevo boot adb shell su flash_image boot /sdcard/newboot.imgReiniciamos el teléfono para que la versión original de Firefox OS quede ahora disponible para ser modificada Fuentes de información https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Firefox_OS_build_prerequisites https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Preparing_for_your_first_B2G_build https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Building https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Installing_on_a_mobile_device http://sl.edujose.org/2013/09/zte-open-hack-actualizando-fxos-11.html
  4. Buenas a todos, recientemente me encontre con un problema que me ha quebrado la cabeza las ultimas semanas, y es que, aunque los usuarios de arch disponemos de AUR, que nos facilita la instalacion/compilacion de una bastisima coleccion de software y herramientas, me encontre con un problema que no me habia pasado hasta ahora. resulta que llevo todo este tiempo intentando compilar kernel liquorix, que nunca me habia fallado, pero esta vez, tanto liquorix, como zen y demas kernels que veo en AUR, me dan error a la hora de verificar las firmas pgp. despues de mucho indagar encontre la solucion, y quiero dejarlo aqui, a modo de recordatorio para mi mismo, porque ya me ha pasado tanto en el portatil, sobremesa, y el notebook del curro. y he tenido que tirar de los comandos uno a uno. bueno, en el caso de querer compilar un kernel de linux, si te encuentras con el error de las firmas, y por mas que añadas la firmas te sigue dando el mismo fallo, la solucion es la siguiente. entramos en el directorio de gnupg: cd .gnupg/ luego: gpg --export-ownertrust > otrust.tmp borramos: rm trustdb.gpg y por ultimo: gpg --import-ownertrust < otrust.tmp ahora ya tenemos creado ese "deposito temporal nuevo" donde podremos importar todas esas claves que nos falten y necesitemos, para importar la clave, en este caso, de linus torvals, para poder compilar el kernel de linux... gpg2 --keyserver hkp://keys.gnupg.net --recv-keys 79BE3E4300411886 porque pasa esto?, la verdad es que no lo se, yo en otras ocasiones he podido compilar el kernel de liquorix sin tener que recurrir a todo esto, pero ahora no puedo, no se si debe de ser algo nuevo que hayan implementado en gpg, o en AUR, pero esta seria la solucion, en el caso del kernel de linux. salu2 PD: ademas de liquorix, mi favorito, encontre este kernel, que es el que estoy probando ahora en mi manjaro OpenRC del escritorio, ya os contare...https://aur.archlinux.org/packages/linux-covolunablu-gaming/
  5. Desde que se de la existencia de Wayland he tenido una pequeña obsesion por hacerlo funcionar con Enlightenment, mi escritorio predilecto para Debian, asi que aprovechando mi reciente tiempo libre decido ponerme manos a la obra Partiendo de la base de la guia de enlightenmente escrita por Shiba87, practicamente lo que he cambiado ha sido el codigo fuente y los parametros de compilacion, ademas de instalar los paquetes de wayland en el sistema. Basicamente quiero plasmar mi experiencia sobre este post para formar una especie de guia experimental, lo que me ha funcionado tal vez de error al resto de personas y etc, asi que agradeceria cualquier observacion o experiencia que podamos añadir Utilizo una tarjeta grafica integrada Intel HD4000 asi que me libro de problemas de drivers, a los de Nvidia y demas les aconsejaria cerrar los ojos y llevar casco Instalando librerias y 'cosas' Pasamos a la parte de obtencion del codigo fuente, al principio probe a compilar la version estable pero lo resumire en horas de trabajo en vano hasta que utilice los repos git El arranque ya a la carta de uno, yo tire de entrance como login manager y ha arrancado perfectamente, no se que tal tirara con autologin o con otro LM
  6. Sería útil una guía de como instalar programas en GNU/Linux para recien iniciados, porque es bastante distinto de como se maneja en Windows Esta guia esta pensada para distribuciones (lease "tipos de Linux") basadas en Ubuntu (por lo tanto Linux Mint, Ubuntu, Xubuntu, Kubuntu, etc.). También sirve un poco para Debian. Hay distintas formas de conseguir programas. Se puede usar un gestor de paquetes, instalar un paquete manualmente, copiar el ejecutable o compilarlo vos mismo Con un gestor de paquetes (recomendado): Termina siendo algo así como una tienda de aplicaciones, similar a la tienda de Android (Play Store) o la tienda de Apple (Apple Store) Te instalan el programa, te lo agregan al menu de inicio para poder usarlo y se encargan de actualizarlo Mas info: A fines prácticos: Hay gestores de paquetes con interfaz gráfica y gestores que se usan desde la terminal De forma grafica (mas fácil) Con la terminal (más eficiente y rápido): Que pasa si el programa que quiero no está? Los paquetes se descargan de repositorios, que son servidores que tienen los paquetes que usamos. Si el programa que queremos no está en los repositorios que tenemos configurados vamos a tener que agregar el repositorio necesario. Hay repositorios que son "oficiales" o algo así como manejados por los creadores de tu distribución, puede que tengas desactivado uno de estos repositorios, no por qué hay que tenerlos a todos activados. En el caso de Ubuntu y Linux Mint (Debian no) tenemos estos repositorios: Hay otro tipo de repositorios llamados PPA, que son algo así como repositorios personales, normalmente son repositorios que solamente tienen unos pocos programas y están generalmente mantenidos por los desarrolladores del programa, se utilizan como alternativa cuando el programa no esta en los repositorios anteriores. Para saber qué repositorio necesitamos tenemos que buscar en la página web del programa en donde debería decir. También podemos probar a agregar repositorios "oficiales" de arriba. Agregar repositorios "oficiales": Agregar PPAs: Instalando un archivo .deb En vez de usar un gestor de paquetes podés instalar el paquete manualmente. Como desventaja las actualizaciones se hacen de forma manual instalando otro .deb nuevo Es lo más parecido a Windows, el archivo .deb se puede pensar como un instalador. Siempre es recomendable usar un gestor de paquetes. Al parecer Ubuntu está buscando crear un reemplazo para los .deb, llamado Snappy, de todos modos si termina implementandose se podrá seguir usando los .deb y la transición no será rápida. Hay más tipos de "instaladores", el otro más común es .rpm, pero en Debian y derivadas (por lo tanto Ubuntu y derivadas) usamos .deb Instalar de forma grafica: Instalar con la terminal: Copiando el ejecutable (no recomendado): Esto no es muy común, técnicamente no es instalar. Es lo mismo que en Windows copiar un .exe Como desventaja tenemos que actualizarlo manualmente Una desventaja muy grande es que si queremos ver el programa en el menú de inicio tenemos que hacer el "acceso directo" o lanzador de forma manual Compilando el programa (avanzado): La ultima forma es bastante común en GNU/Linux, directamente se descarga el código fuente, que para ser ejecutado debe ser compilado El código fuente es el programa escrito en un lenguaje entendible para las personas, luego se tiene que compilar así se obtiene el programa en un lenguaje entendible para la PC (ceros y unos!) Olvidate de hacerlo de forma gráfica, hay que hacerlo desde la terminal. El problema es que para compilar se necesitan programas que varían dependiendo que hay que compilar. Así que antes de compilar se necesitan instalar varios paquetes, el paquete indispensable es build-essentials, contiene varios programas dentro. sudo aptitude install build-essentials Después hay que instalar los demás paquetes que digan en las instrucciones, normalmente estos paquetes terminan en -dev (viene de development, desarrollo en ingles) Para compilar varía de programa en programa, hay que buscar las intrucciones, lo más común son estos tres comandos en orden: ./configure make make install Previamente hay que moverse a la carpeta del código fuente con el comando cd Lo malo también es que no siempre se crean los accesos directos al menú de inicio, y para actualizar hay que compilarlo de nuevo.
  7. Con la idea de ofrecer un Linux bien configurado y mucho más optimizado para equipos de escritorio de uso general, multimedia y Gaming que las imágenes precompiladas que ofrecen las distribuciones por defecto, que para las que usan una configuración muy genérica, nace el proyecto Liquorix. Además de una configuración enfocada a conseguir una mejor respuesta del kernel en los equipos de escritorio, también se aplican un gran número de parches y mejoras específicas para estos equipos, como por ejemplo BFS (Brain Fuck Scheduler). Existe un repositorio para Debian que nos permitirá tener nuestra imagen del kernel siempre al día como si de cualquier otro paquete se tratase. Para ello, hay que añadir la correspondiente línea del repositorio a nuestro sources.list y también las correspondientes llaves: Debian echo 'deb http://liquorix.net/debian sid main' > /etc/apt/sources.list.d/liquorix.list aptitude update apt-get install '^liquorix-([^-]+-)?keyring.?' Además del repositorio principal, existen dos ramas más que podemos utilizar: Si somos algo osados y queremos probar futuras versiones del kernel, podemos utilizar la rama "future" deb http://liquorix.net/debian/ sid main future Si, por el contrario, preferimos quedarnos con una versión del kernel más antigua y con soporte prolongado, apuntaremos a la rama "past" deb http://liquorix.net/debian/ sid main past La posterior instalación de la imagen y cabeceras del kernel se hará teniendo en cuenta nuestra arquitectura y la del sistema Debian instalado: x86 (i386) aptitude install linux-headers-liquorix-686 linux-image-liquorix-686 x86_64 (amd64) aptitude install linux-headers-liquorix-amd64 linux-image-liquorix-amd64 Tras este sencillo proceso ya estaríamos listos para iniciar con el nuevo kernel, sin olvidar que podríamos necesitar algún ajuste o reinstalación de nuestros controladores gráficos, aunque hoy en día con Dkms eso no debería ser ningún problema Scripts de configuración/optimización Además del repositorio para Debian, este proyecto va aún más allá y cuenta con varios scripts que podemos utilizar para realizar las tareas de optimización más específicas en nuestro sistema, tanto con el script general Smxi, como con el que está centrando únicamente en el aspecto gráfico con Sgfxi La utilización de dichos scripts es bastante sencilla, basta con descargarlos, darles permisos y ejecutarlos, pero con una pega y es que algunas de sus funciones sólo podrán utilizarse desde fuera del entorno gráfico, especialmente las relacionadas con Sgfxi. En nuestro caso los colocaremos en /usr/local/bin para poder tenerlos más a mano: NOTA aunque pueden funcionar para otros casos,los scripts están pensados para trabajar con las ramas Testing y Unstable de Debian, no con Debian Stable u otros derivados Ciclyng release. instalación Smxi (Script General) cd /usr/local/bin && wget -Nc smxi.org/smxi.zip && unzip smxi.zip && smxi Sgfxi (Script para temas gráficos) cd /usr/local/bin && wget -Nc smxi.org/sgfxi && chmod +x sgfxi && sgfxi Uso Ejecución dentro del entorno gráfico: Soy consciente que un par de líneas atrás he dicho que algunas tareas debían realizarse fuera del entorno gráfico, pero mientras no sea estrictamente necesario, ejecutaremos liquorix de la siguiente manera, para indicarle que nos encontramos dentro del entorno gráfico. smxi -G La primera vez que lo ejecutemos, Smxi empezará haciéndonos preguntas sobre nuestro sitema para ajustar la configuración convenientemente, tan sólo tendremos que ir eligiendo la opción correspondiente en cada caso introduciendo en la terminal el número correspondiente a dicha opción. Una vez configurado, podremos acceder a todas las opciones y menús del script, incluyendo el proceso descrito en el apartado anterior, instalar una versión kernel Liquorix desde el repositorio oficial, desde el menú kernel-options >> alternate-kernel-install Estos scripts dan muchísimo juego y nos permitirán realizar un gran número de tareas, desde instalar un entorno gráfico a mejorar el desempeño de firefox, jugar con nuestros repositorios, instalar el último libreoffice... Todo mediante menús muy simples y bien explicados (en inglés, eso sí) No obstante, nunca está demás leer el manual para saber más acerca de lo que podemos hacer con este impresionante script: Manual oficial de Sxmi: http://smxi.org/docs/smxi-manual.htm En el caso de Sfgxi el panorama es muy similar, aunque en este caso sí que debemos tener muy en cuenta la recomendación de ejecutarlo fuera del entorno gráfico, aunque al contar con las mismas opciones que Smxi también podremos utilizar: sgfxi -G En este caso, el script se centrará específicamente en lo referente a nuestros controladores gráficos, permitiéndonos instalar la última versión de los mismos, modificar la configuración de Xorg, habilitar/deshabilitar funciones gráficas específicas... Igualmente, no está demás leer el manual para saber más acerca de lo que podemos hacer él: Manual oficial de Sgfxi: http://smxi.org/docs/sgfxi-manual.htm Actualización de los scripts En ambos casos, podremos mantener siempre al día los scripts de liquorix mediante la opción -U smxi -U sgfxi -U Compilando el kernel manualmente Para los que prefieran compilar un kernel a medida, pero aprovechando las mejoras del proyecto liquorix, también existe la opción de descarga los parches y la configuración de liquorix por separado, para luego aplicárselos al código fuente oficial de Linux para después compilarlo en nuestro equipo. Como se indica en la guía para "Configurar y compilar el kernel Linux (varios métodos), el parche lo aplicaremos, tras descomprimir el código fuente y situándonos dentro del directorio resultante mediante la orden: patch -p1 < /ruta/del/Parche.patch Además de esto, debemos descargar el archivo de configuración correspondiente a nuestra arquitectura e incluirlo dentro del directorio anterior, con el nombre ".config" Ambos los encontraremos en la FTP del proyecto, el parche dentro de un comprimido tar.gz y los config dentro del directorio correspondiente a la versión del kernel a compilar: http://liquorix.net/sources/ Una vez aplicados todos los parches e incluidos (y renombrados) los ficheros de configuración, podremos compilar nuestra versión Liquorix "casera" de Linux de la manera habitual, sin olvidar que aún podemos dar otra vuelta de tuerca más haciendo alguna configuración más personalizada primero: make menuconfig Una vez terminada la configuración o si no queremos configurar nada más, procederemos a compilarlo make make modules make modules_install make install Si todo ha salido bien ya estaríamos listos para iniciar con el nuevo kernel, sin olvidar que podríamos necesitar algún ajuste o reinstalación de nuestros controladores gráficos, aunque hoy en día con Dkms eso no debería ser ningún problema. Para más información sobre este proyecto: http://liquorix.net/ http://smxi.org/
  8. Hace unos días, en uno de eso brotes psicóticos que tengo, decidí hacer borrón y cuenta nueva y compilar Enlightenment 0.19 desde cero, ya que hasta ahora venía arrastrando librerías desde la época de e17. Uno de los requisitos indispensables del nuevo núcleo de E19, que ahora incluye el motor de composición y otras muchas cosas, es la necesidad de contar con librerías para simulación de físicas en tiempo real, que en este caso se consigue con Bullet Pero, al compilar EFL 1.9 por un lado y la última versión de Bullet por otro, acabamos con un error que nos tira todo abajo. ¿Qué ocurre? PIC es la abreviatura de Position-Independent Code. Bueno, pues ya tenemos una ligera idea del por qué, ahora sólo queda saber: ¿Cómo proceder? De manera global, e insisto en lo de global, porque aunque se podría especificar junto con el resto de opciones de configuración/make, posiblemente no funcione Establecemos el flag -fPIC, tal como nos indica el mensaje de error CFLAGS="-fPIC" export CFLAGS Ahora toca volver a configurar y compilar TODO . En esta ocasión deberíamos obtener un resultado satisfactorio. http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3
  9. Apt-build nos brinda la oportunidad de compilar los paquetes de los repositorios para ajustarlos a las especificaciones de nuestro sistema y, de esa manera, aumentar el rendimiento. Permite compilar cada paquete manteniendo las reglas y dependencias del sistema. Al hacerlo no vamos a perder la habilidad de administrar el programa a través de apt, ya que el propio apt-build se encarga de crear el paquete .deb para luego instalarlo como si se tratara de un paquete descargado directamente desde repositorios. La desventaja es que hay que perder tiempo compilando y seguramente instalar multitud de dependencias para poder llevarlo a cabo dicho proceso. Por no hablar de tener que repetir todo cada vez que sea actualizado el paquete. Lo primero que debemos hacer es asegurarnos de que tenemos los repositorios "source" (deb-src) En el caso de Debian podemos consultarlos en Debian Source list generator En ambos casos es tan simple como añadir deb-src delante de la dirección del repositorio en lugar del típico deb (El repositorio debe contener las fuentes, de lo contrario no funcionará aunque añadamos la línea deb-src) Ambas direcciones son idénticas, sólo cambia la cabecera de la línea Instalar y configurar apt-build: aptitude install apt-build[Mientras se instala nos preguntará qué nivel de optimización nos interesa: El nivel agresivo no es muy recomendado porque puede dar algunos problemas. El nivel escaso, personalmente no lo aconsejo ¿Que gracia tiene hacer toda esta locura para obtener un rendimiento "escaso"? Esto deja como nivel recomendado, el nivel medio Lo siguiente que pregunta es el modelo de procesador que tenemos en el equipo, de esto depende el resultado de la optimización. En caso de duda, podemos ver toda la información de nuestra cpu con el comando: lscpu Proceso de compilado [Apt-build tiene un funcionamiento muy similar a apt-get o aptitude Lo primero es actualizar la lista de sources: apt-build updatePara compilar e instalar un paquete Para compilar e instalar un paquete que ya está instalado Para eliminar un paquete Limpiar después de compilar/instalar apt-build clean-sources; apt-build clean-buildEl resto de opciones pueden consultarse con el habitual apt-build --help Compilar código fuente ajeno a los repositorios Para paquetes que provengan de repositorios, para compilar el código fuente de algún programa que descarguemos y vayamos a compilar también nos puede servir de ayuda. Suele ocurrir que aparece una nueva versión de determinado programa, y no hay ningún paquete .deb y los repositorios sólo ofrecen versiones antiguas de ese programa, por lo que no tenemos más remedio que descargar el código fuente y compilarlo por nuestra cuenta. A la hora de compilar siempre nos encontramos con que son necesarias multitud de dependencias previas y es algo que molesta, y mucho. Eso se puede solucionar con un: De esta manera se descargarán e instalarán todas las dependencias necesarias para poder compilar ese programa/paquete en concreto. Una vez instaladas ya podremos proceder a compilarlo manualmente teniendo instalado todo lo necesario para que se complete el proceso. (No es necesario el apt-build para hacer esto último) (Tampoco es necesario aptitude build-dep para paquetes que compilemos con apt-build) Apt-build world Llega la parte peliaguda. El apt-build con el parámetro "world" lo que hace es compilar absolutamente todo lo que hay en el sistema. Este proceso es sólo para los más osados, porque no ofrece garantías de que todo funcione correctamente una vez termine y, encima, tardará una barbaridad en compilar todo el sistema. Si termina y todo sale bien, mejorará el rendimiento notablemente y con el apt-build podremos administrar las actualizaciones y paquetes que vayan surgiendo sin tener que volver a empezar, pero si no sale, habremos perdido unas cuantas horas compilando y las que nos quedarán para arreglarlo Vale, ahora que ya los he asustado, empecemos con el proceso Antes de ejecutar el apt-build world hay que tener en cuenta una cosa, y es que no se deben compilar los mismos paquetes que se utilizan para compilar (suena redundante pero es así), por lo que debemos excluirlos para que no haya problemas. Creamos una lista de los paquetes que tenemos instalados para que la lea apt-build dpkg --get-selections | awk '{if ($2 == "install") print $1}' > /etc/apt/apt-build.listUna vez termine debemos acceder al archivo y eliminar los paquetes que no queremos que se compilen: nano /etc/apt/apt-build.listLos paquetes que tenemos que eliminar de la lista son los siguientes: Cuando nos hayamos asegurado de que hemos excluido esos paquetes del proceso, ejecutamos el comando: apt-build worldAunque algunos no lo tengan en cuenta, lo siguiente es muy importante, y es que si no le pones unas velitas a San Ignucio, y le rezas a San Torvalds, tienes muchas menos posibilidades que que el proceso se complete satisfactoriamente Después de varias Horas/Días compilando verás como te tomas la última recomendación mucho más en serio
  10. Compila y descompila aplicaciones con ApkTool (Windows) Bien hoy les explicare como se usa apktool, para descompilar y compilar aplicaciones en windows. En el foro hay otro tutorial para compilar y descompilar, pero con ApkManager no con ApkTool. Yo coloque este, porque algunas aplicaciones no van con ApkManager y si con este, y viceversa. Archivos necesarios: Android JDK: Descargar aquí!! ApkTool: Descargar aquí!! framework-res.apk: lo sacamos de la ROM twframework-res.apk (en caso de tener un Samsung): lo sacamos de la ROM Paciencia jaja Aclaraciones: - Cuando descarguen el jdk, deben indicar para que sistema operativo es, ademas si es para 32bits o 64bits. - Cuando vallan a descargar el apktool, necesitan descargar dos archivos, el apktool propiamente dicho (actualmente es este: apktool1.5.2.tar.bz2) y las dependencias para windows (actualmente es este: apktool-install-windows-r05-ibot.tar.bz2). Instalación de los archivos: ~ Ya una vez descargado e instalado el jdk, procedemos a descargar el apktool.. son dos archivos por descargar, los cuales encontramos 2 dentro de un .tar.gz y 1 dentro del otro .tar.gz, lo que tenemos que hacer es crear una carpeta llamada "apktool" (por ejemplo, yo la creo en C:\sdk/apktool ya que uso la sdk de android). Y descomprimimos los dos .tar.gz con cualquier compresor de archivos, dentro de esta otra carpeta. ~ Si ya tenemos todo lo anterior, entonces podemos seguir. Como utilizar ApkTool: Descompilar APK: ~ Estos pasos son importantes, debes copiar las siguientes apks que estan en estas rutas: framework-res.apk -> /system/framework/ apk a descompilar (Por lo general esta aquí) /system/app, pero cualquiera vale. Si tienes un samsung tambien necesitaras twframework-res.apk que esta en /system/framework ~ Presionamos la tecla Windows o simple vamos a Inicio y escribimos: cmdY le damos enter. Esto nos abrira una consola como esta: ~ Ya ahora tenemos que acceder a la carpeta donde esta el ApkTool, asi: cd C:\sdk/apktool ~ Ahora el codigo para descompilar: ~ Primero necesitamos instalar el framework-res.apk, así: apktool if framework-res.apkEn caso de tener Samsung, abre el "spoiler": apktool d nombre_de_la_aplicacion.apk Cosas a tener en cuenta con este codigo: La aplicacion no puede contener espacios en su nombre si por error se olvidan del poner el ".apk" les saldra error ~ Ya esto nos creara una carpeta con el mismo nombre de la apk en el mismo directorio, en el caso del codigo anterior, me creara dentro de la carpeta apktool una carpeta con el nombre de nombre_de_la_aplicacion. Bien, dentro encontraran todas las carpetas de la apk, quizás en otro tutorial, expliquemos que función cumple cada una de ellas. Compilar APK: El proceso de compilado es mas corto, así que relájate XD ~ Ya supongo que has modificado todo lo que necesitabas, bien ahora es momento de compilar: ~ Colocamos este codigo: apktool b nombre_de_la_aplicacion Cosas a tener en cuenta con este codigo: El nombre es el nombre de la carpeta que nos creo al descompilarla Si por error ponen la extension ".apk" les saldra error, la carpeta no tiene extensión, no deben ponerle. Bien, cuando ya compile y revisando de no tener errores, entonces encontraremos la aplicación compilada dentro de: nombre_de_la_aplicacion/dist y dentro de nombre_de_la_aplicacion/build encontraran la apk pero sin empaquetarse como .apk, o sea, es lo mismo que contiene la apk pero "desempaquetado". Hablando mal y pronto seria como abrir la apk con "winrar" o algún otro compresor y darle a extraer. Bien, ya tenemos la apk, descompilada, modificada y compilada. Ahora tenemos que firmarlas, para esto hay varios metodos, los explicare en el segundo comentario luego, que me va a llevar un buen tiempo jeje Fuente: http://www.darksideteam.com/showthread.php?tid=130
  11. Si bien Linux, como kernel, cumple de sobra con los requisitos que podemos tener con cualquier equipo y su hardware, hay situaciones en las que los módulos incluidos en el kernel de nuestra distribución no son suficientes y debemos recurrir a instalar y o compilar algún módulo externo. Esto ocurre muy a menudo con los controladores privativos de Nvidia o AMD y también con muchos periféricos que bien por su carácter privativo o por no haber entrado todavía en la línea de desarrollo del kernel, no pueden ser incluidos en éste. Desde hace ya varios años, existe DKMS (Dynamic Kernel Module Support), que nos permite gestionar los módulos ajenos al kernel de manera sencilla o, como su propio nombre indica, dinámica. Para los que solemos compilar las últimas versiones de Linux antes de que lleguen a nuestra distribución o configuradas de alguna manera especial, los que instalamos algún controlador de hardware manualmente porque no está incluidos en repositorios o queremos tener una versión concreta del mismo, podemos valernos de DKMS para que, ante cualquier cambio o actualización del kernel, los controladores ajenos a este sigan funcionando sin tener que volver a instalarlos o compilarlos por nuestra propia mano una y otra vez. El proceso llevado a cabo por DKMS, explicado un poco por encima para entendernos, es básicamente una comprobación durante el arranque del sistema de los módulos instalados y el Kernel en ejecución. En caso de detectar cambios, automáticamente se compilarán de nuevo los módulos externos que hayan dejado de funcionar para la versión de Linux con la que estamos arrancando. De esta manera, podremos tener diferentes versione del kernel en la misma máquina sin temor a que los módulos funcionen para unas versiones y al arrancar con otras no lo hagan, así como también nos servirá para evitar perder los controladores compilados/instalados a mano cada vez que aparece una actualización del kernel oficial de nuestra distribución o cualquier otra situación similar ¿Cómo podemos aprovecharnos de todas las ventajas que DKMS nos ofrece? A día de hoy, la mayoría de las distribuciones tienen paquetes preparado para hacer uso de la "magia" de dkms para los módulos externos incluidos en sus repositorios o en las ramas no-libres de estos. Siendo así, sólo tendríamos que instalar dkms (si no lo tenemos ya) y los paquetes correspondientes al módulo que queremos instalar/automatizar, ya sea nvidia-kernel-dkms, fglrx-modules-dkms, virtualbox-dkms, etc Por poner un ejemplo sencillo, veamos cómo se instalarían los controladores de Nvidia en varias distribuciones, haciendo uso de los paquetes preparados para dkms provisto por cada una ellas. Sin olvidar en ninguno de los casos, que necesitaremos las cabeceras del kernel para poder compilar los módulos, ya sea el kernel oficial de la distribución que usamos o el código fuente compilado por nosotros. Debian aptitude install dkms linux-headers-`uname -r` nvidia-kernel-dkms Fedora En este caso concreto, vamos a hacer una excepción. En lugar de dkms, Fedora se decanta más por aKmod, que es muy similar dkms y cumple el mismo objetivo, automatizar la instalación de controladores ajenos al kernel. Simplemente instalamos el paquete creado para tal fin yum install akmod-nvidia Arch Para Arch no existe ningún paquete dkms en el repositorio principal de la distribución, salvo los de Virtuabox y Open-VM, por lo que tendremos que valernos de los paquetes de AUR. Necesitaremos nvidia-hook que nos permitirá automatizar el proceso, y también nvidia-dkms para tener el código fuente que vamos a compilar luego. Como es habitual, en la wiki de Arch está muy bien explicado por si queremos profundizar aún más o realizar toda la configuración/compilación manualmente yaourt -S nvidia-dkms nvidia-hook ¿Y si el módulo cuya compilación queremos automatizar no se encuentra en ningún paquete de los repositorios de nuestra distribución? Como hemos visto en el ejemplo, cada distribución tiene su propia manera de hacer las cosas y no ofrecen los mismos paquetes o, a veces, ni siquiera los mismos métodos. Este es realmente el punto de este pequeño tutorial, porque instalar un paquete que ya ha sido preparado para trabajar con dkms es muy sencillo, no hay ninguna diferencia con instalar otro paquete o la versión "convencional" sin dkms. Para posteriores ejemplos no lo volveré a escribir, pero vuelvo a recordar que es imperativo que tengamos las cabeceras del kernel instaladas o, si hemos compilado una versión concreta de Linux por nuestra cuenta tener las cosas en su lugar y bien enlazadas. También se cae de maduro que para poder hacer uso de Dkms tendremos que tener instalados los paquetes del mismo y dicho servicio habilitado en el arranque (Los que trabajen con systemD pongan especial atención a esto último) Procedimiento Lo primero y posiblemente lo más importante, es contar con el código fuente o instalador del módulo que vamos a compilar, sin eso no podemos hacer nada Como todo se entiende mejor con un ejemplo, ya que antes fueron controladores gráficos, ahora vamos a por controladores Wireless. Supongo que todos, en alguna ocasión hemos tenido que lidiar o hemos oído hablar de los Compat-Wireless, actualmente renombrados como Compat-Drivers. Simplemente ir a la página de descarga y conseguir la versión que corresponde a nuestro caso. Personalmente me decantaré por la 3.11, que es la versión de Linux que estoy utilizando en estos momentos, teniendo en cuenta que las fuentes y el archivo de configuración deben ir siempre en /usr/src, así que lo descargaré directamente ahí: cd /usr/src wget http://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.11-rc3/backports-3.11-rc3-1.tar.bz2 tar xvf backports-3.11-rc3-1.tar.bz2 Una vez hemos descargado y descomprimido el material en /usr/src, empieza el verdadero trabajo. La clave de todo será el archivo de configuración dkms.conf, que como no lo tenemos, tendremos que crearlo manualmente. Aunque no es necesario que completemos todos los datos, cuanto más específico lo hagamos, mejores resultados podremos obtener. Así, en este caso, un archivo de configuración que nos podría servir sería algo parecido a esto: ##Archivo de configuración dkms.conf para la instalación automática de los controladores compat-drivers haciendo uso de dkms PACKAGE_NAME="backports" PACKAGE_VERSION="3.11-rc3-1" MAKE[0]="make; make install" BUILT_MODULE_NAME[0]="${PACKAGE_NAME}" BUILT_MODULE_LOCATION[1]="drivers/net/ethernet/${PACKAGE_NAME}/" DEST_MODULE_NAME[0]="${PACKAGE_NAME}" DEST_MODULE_LOCATION[0]="/extra/${PACKAGE_NAME}/" AUTOINSTALL="yes" Como vemos, es bastante específico, tenemos nombre y versión del módulo que, si se fijan bien, coinciden con lo que está indicado en el nombre de la carpeta que contiene el código fuente que hemos descomprimido en /usr/src. Esto es importante para que luego dkms pueda dar con ella. También hemos usado el nombre y la versión para llevar a cabo el resto de pasos, tanto para definir rutas como comandos para compilar el módulo, así como el nombre que tendrá el módulo compilado, dónde estará localizado una vez termine el proceso. Una cuestion de simple comodidad. Por supuesto, hemos puesto la autoinstalación como "yes" para que cumpla con lo que nos hemos propuesto Aún sin ser necesario, crear un buen archivo de configuración dkms.conf puede resultar muy útil. En el caso de este ejemplo, podríamos querer compilar únicamente un controlador o familia de controladores de los compat-drivers y no todos los controladores a la vez. Tan sólo habría que hacer una pequeña modificación en la línea de compilado (Make[x]), con los cambios que queremos introducir, que vamos a suponer que para este ejemplo es la instalación de la familia de controladores iwlwifi Sabemos que para este menester, los compat-drivers permiten seleccionar el controlador con la orden "make defconfig-`modulo`" (Con los compat wireless se utilizaba el script "driver-select"), así que nos valdremos de ella y la incluiremos en el archivo de configuración. ##Archivo de configuración dkms.conf para la instalación automática de los controladores iwlwifi pertenecientes al conjunto de los compat-drivers haciendo uso de dkms PACKAGE_NAME="backports" PACKAGE_VERSION="3.11-rc3-1" MAKE[0]="make defconfig-iwlwifi" MAKE[1]="make; make install" BUILT_MODULE_NAME[0]="${PACKAGE_NAME}" BUILT_MODULE_LOCATION[1]="drivers/net/ethernet/${PACKAGE_NAME}/" DEST_MODULE_NAME[0]="${PACKAGE_NAME}" DEST_MODULE_LOCATION[0]="/extra/${PACKAGE_NAME}/" AUTOINSTALL="yes" Como ven, lo único que he hecho es añadir la parte de driver-select a las instrucciones de compilado/instalación La localización de destino del módulo no es realmente necesaria salvo que sustituamos algún módulo Si observamos otros ejemplos, vemos que es siempre el mismo procedimiento e incluso más sencillo. Volviendo al ejemplo inicial, si consultamos el archivo dkms.conf de Nvidia, veremos que es bastante escueto: Y a modo de ejemplo general, tal y como figura en la wiki de Debian: También podremos consultar ejemplos más complejos provistos con el propio paquete dkms y que encontraremos en /usr/share/doc/dkms/examples que muestran configuraciones más complejas, incluyendo el parcheado de módulos antes de compilarlos e instalarlos Una vez tengamos la configuración en función de los requisitos del módulo a compilar, nombre, versión y todos los ajustes que hayamos hecho, nos queda la parte de añadir y compilar: dkms add -m <nombre> -v <versión> dkms build -m <nombre> -v <versión> dkms install -m <nombre> -v <versión> || true No es necesario que nos posicionemos en la carpeta correspondiente al módulo que queremos compilar, dkms asumirá que ésta se encuentra en /usr/src y que el nombre y la versión que le hemos suministrado son los que figuran en dicha carpeta. Una vez en ella, dkms seguirá los pasos que le hemos marcado en el archivo de configuración dkms.conf Que si nos ceñimos al ejemplo de los compat-drivers: dkms add -m backports -v 3.11-rc3-1 dkms build -m backports -v 3.11-rc3-1 dkms install -m backports -v 3.11-rc3-1 || true Resultado root@Shiba87:/usr/src# dkms add -m backports -v 3.11-rc3-1 Creating symlink /var/lib/dkms/backports/3.11-rc3-1/source -> /usr/src/backports-3.11-rc3-1 DKMS: add completed. NOTA Si en algún momento queremos que dkms deje de tener en cuenta el módulo que hemos incluido, porque queremos cambiarlo por una versión diferente, dejemos de utilizar ese hardware o lo que sea, sólo tendremos que realizar el proceso a la inversa: dkms remove nombre/version all O en caso de querer impedir que se compile para un kernel específico dkms remove nombre/version -k version-del-kernel Para nuestro ejemplo dkms remove backports/3.11-rc3-1 all ó dkms remove backports/3.11-rc3-1 -k 3.11.0 Y eliminar la carpeta del módulo de /usr/src para que no queden restos: rm -R /usr/src/backports-3.11-rc3-1 Generando nuestro paquete Deb DKMS Aunque el proceso de configuración, compilado e instalación del nuevo módulo con dkms ya habría terminado, veamos cómo podríamos preservar todo ese trabajo en un cómo paquete deb. Los comandos siguen en la misma línea que los anteriores, sólo que esta vez no añadiremos, compilaremos o instalaremos sino le indicaremos que lo que queremos es empaquetar el código fuente y la configuración que acabamos de utilizar: Empezando por el paquete que contiene el código fuente dkms mkdsc -m nombre -v versión --source-only Seguido del que contiene el binario y configuración pertinentes dkms mkdeb -m nombre -v versión --source-only Al completarse el proceso nos indicará dónde se han guardado los respectivos paquetes, que no será otro lugar sino: /var/lib/dkms/nombre/versión/deb y /var/lib/dkms/nombre/versión/dsc NOTA Podría ser necesario eliminar la carpeta en la que hemos estado trabajando /var/lib/dkms/nombre/versión/ para no generar conflictos a la hora de instalar el paquete deb. En el caso del ejemplo con Compat-drivers con el que hemos estado trabajando hasta ahora: dkms mkdeb -m backports -v 3.11-rc3-1 --source-only dkms mkdsc -m backports -v 3.11-rc3-1 --source-only Como ven, no es algo tan complicado y seguramente los responsables de nuestra distribución ya se habrán ocupado de todo el trabajo por nosotros, pero en caso de necesitarlo, en cuestión de unos minutos podemos tener el problema resuelto. SalUnix
  12. Como dijimos hace algún tiempo y aún cuando Disney no estuvo muy de acuerdo, el código de los juegos de Star Wars, Jedi Academy y Jedi Outcast ha sido liberado y ahora está disponible para cualquiera bajo el proyecto OpenJK Uno de los primeros pasos dados por los Modders de Jedi Kinght ha sido brindar soporte multiplataforma y es lo que ahora vamos a ver cómo aprovechar. Al igual que en el caso de Doom3, debemos recordar que, aunque el cliente está bajo la GPL, el contenido de juego está bajo licencias privativas, por lo que debemos contar previamente con dicho contenido para poder hacer uso del cliente libre. Una vez tengamos el contenido del juego Jedi Academy, podremos jugarlo de manera masiva siguiendo estos pasos. Dependencias Antes de nada, debemos cumplir una serie de requisitos para poder compilar OpenJK, que son los siguientes: [/code]git openal-dev cmake sdl-2-dev libasm-dev gcc zlib[/code] Para distribuciones basadas en Debian (Testing o superior), el proceso se llevaría a cabo tal que así: aptitude install build-essential cmake git libopenal1 zlib1g-dev libopenal-dev libsdl2-dev libasm-dev Compilado Lo primero será obtener el código fuente de OpenJK valiéndonos de su repositorio git git clone http://github.org/Razish/OpenJK OpenJK cd OpenJK mkdir build cd build Después de situarnos en la carpeta build, haremos uso de cmake para obtener los archivos necesarios para compilar luego OpenJK cmake -G "Unix Makefiles" -i ../ NOTA No es posible compilar OpenJK para sistemas de 64 sin algunas consideraciones previas. Para poder compilarlo en sistemas x86_64 tendremos que ejecutar cmake de la siguiente forma: cmake -G "Unix Makefiles" -i -DCMAKE_CXX_FLAGS=-m32 -DCMAKE_C_FLAGS=-m32 -DCMAKE_SHARED_LINKER_FLAGS=-m32 -DCMAKE_SIZEOF_VOID_P=4 ../ Una vez generados los archivos y sin movernos de build, queda simplemente compilar: make Esto nos generará los ejecutables openjkded.x86, openjk_sp.x86 y openjk.x86 o openjkded.x86_64, openjk_sp.x86_64 y openjk.x86_64, según nuestra arquitectura. Jugar Una vez tengamos el cliente, la carpeta "base" que contiene los archivos .pk3 del juego tendremos que colocarla junto a los ejecutables que acabamos de compilar para que el juego inicie. https://github.com/Razish/OpenJK/wiki/Compilation-guide
  13. Shiba87

    Compilar el cliente libre de Doom 3 BFG

    Tras ser comprada por ZeniMax, ID Software técnicamente dejó de existir, algo que se hizo evidente tras la salida al mercado de Rage, que aunque prometía ser un juego multiplataforma, gráficamente rompedor y cuyo motor ID-tech se rumoreaba podía ser Open Source, finalmente se quedó en nada, el cliente GNU/Linux nunca apareció, el motor de ID no fue liberado y fue un caos en cuanto a problemas gráficos. Recientemente fue lanzado el juego del que vamos a hablar ahora, Doom 3 BFG, una remasterización del doom 3 Original, con mejores gráficos, sonido, soporte 3D (pensado para Oculuss RIft) y nuevo contenido jugable, incluida la expasión "Resurrection of Evil". Dado que tanto el juego original como la expansión contaban con soporte nativo para GNU/Linux y el motor ID Tech 4 fue liberado bajo licencia GPL, todo parecía indicar que esta nueva versión del título de ID sería multiplataforma, pero una vez más lo intereses de ZeniMax han echado por tierra el proyecto y el juego no sólo no es jugable en plataformas No-Windows, sino que ha entrado en escena el DRM. Afortunadamente, como dije antes, el motor ID-tech 4 está bajo la GPL, así que no ha sido problema para Robert Beckebans crear el cliente nativo libre del que vamos a hablar a continuación. IMPORTANTE: El cliente libre no contiene los datos del juego, necesitaremos una copia de la versión para Windows de Doom 3 BFG para extraer dicho contenido. El juego viene encriptado, así que aún teniendo la versión física en DVD necesitaremos la versión de Steam para Windows o instalar la versión en DVD a través de Steam (Windows). En otras palabras, es una de esas ocasiones en donde ser legal no tiene ninguna ventaja sino todo lo contrario, así que busquen de dónde descargar una copia desencriptada y gaste o donen el dinero que iba a embolsarse ZeniMax en cualquier otra cosa que de verdad merezca la pena Dependencias Lo primero que necesitamos es git y cmake, de lo contrario no podremos compilarlo. Además también necesitaremos las librerías de desarrollo de OpenAL y Sdl 1.2 En distribuciones basadas en Debian bastaría con: yum install cmake SDL-devel openal-devel git cmake Para cualquier otra distribución, las dependencias son las mismas, basta con instalar los paquetes correspondientes en cada caso. Descargar y compilar Una vez tenemos las dependencias descargamos el código fuente desde Github https://github.com/RobertBeckebans/RBDOOM-3-BFG.git Accedemos a la carpeta recién descargada cd neo/./cmake-eclipse-linux-profile.sh Una vez hecho, salimos de la carpeta neo y compilamos Añadiendo el contenido del juego Lo único que necesitamos del paso anterior es el ejecutable RBDoom3BFG que encontraremos dentro de la carpeta "build", el resto ya no nos hace falta, por lo que para que nos sea más cómodo vamos a crear una nueva carpeta para el juego en la que pondremos únicamente dicho ejecutable. Dado que soy muy creativo, en mi caso voy a trabajar directamente en mi home y la carpeta la llamaré Doom3BFG (¿A que nunca lo hubieran adivinado? :P/>), es donde copiaré el ejecutable RBDoom3BFG. No diré nada sobre cómo obtener el contenido desde Windows, ni tengo ni quiero ni aconsejo utilizar "eso", yo me he decantado por "el método alternativo" y tengo ya los archivos desencriptados listos para ser copiados en su lugar. Lo que debemos conseguir es básicamente la carpeta de un Doom3BFG ya instalado tal cual, sin alteraciones, da igual cómo la consigamos. Ahora toca colocar en esa misma carpeta el contenido del juego. Una vez hayamos copiado todo nos debería quedar algo similar a esto: RBDoom3BFG (ejecutable) base/ (carpeta) classicmusic/ _common.crc etc, etc Los .exe, .bat, .dll y demás archivos propios de Windows no los necesitamos, sólo "base" y su contenido Jugar Una vez tengamos todo copiado dentro de la carpeta ya sólo queda ejecutar el juego haciendo uso del RBDoom3BFG que hemos compilado y disfrutar del juego. https://github.com/R...ns/RBDOOM-3-BFG Una muestra de los resultados El vídeo no ha quedado demasiado bien, pero bueno, sirve para hacerse una idea :P/>
  14. ¿Sabían que desde la versión 14.0 Firefox para GNU/Linux es capaz de utilizar Gstreamer para reproducir cualquier formato de Audio y vídeo con el que se encuentre en la web? Así, aprovechando las ventajas de este proyecto, Firefox sería capaz de reproducir contenido bajo codecs en un principio vetados para el navegador de Mozilla, como pueden ser los privativos H.264, Mp3 o Acc. Pero esto es algo que hasta ahora la fundación Mozilla y la mayoría de distribuciones no activan cuando compilan el navegador, por ahora la reproducción de contenidos bajo codecs privativos está disponible sólo para la versión Mobile del navegador. Para sistemas de escritorio tendremos que compilar por nuestra cuenta si queremos utilizar gstreamer para reproducir contenido de este tipo (Como pueden ser los vídeos de Vimeo en HTML5). NOTA Cumpliendo con las dependencias necesarias para compilar Firefox, el proceso es bastante sencillo, pero compilarlo puede llevar mucho tiempo, no es para hacerlo en 5 minutos, una vez configurado, tendremos que esperar un buen rato hasta que termine de compilar. NOTA2 Quien dice Firefox, dice cualquiera de sus forks, el procedimiento no varía, la única diferencia sería que tendríamos que utilizar el código fuente del fork en lugar del código oficial de Mozilla Requisitos Previos Antes de proceder a descargar el código fuente de firefox, necesitamos algunas dependencias para poder compilar el navegador en nuestro equipo. Para hacer esto hay varios métodos, los propios de cada distribución y un script universal que provee la propia Mozilla: Script Universal Debian OpenSUSE Fedora/Red Hat/CentOS Arch Linux Descargando el código fuente Configurando las opciones de compilado Compilando Probando Empaquetar Actualizar/Compilar nuevas versiones Para más detalles sobre el proceso podemos consultar la documentación de Mozilla https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions EDITO Una pequeña muestra del resultado después de compilar la versión 20 de iceweasel siguiendo este método. EDITO 2 Para quien no tenga ganas de compilar, pero sí de probarlo: Firefox 21 alpha2 x86_64 (Gstreamer enabled).tar.bz2
  15. Tras una serie de retrasos de ultima hora, Linus Torvalds ha anunciado por fin el lanzamiento de Linux 3.7. Algunas de las novedades son Soporte para módulos firmados Network Address Translation (NAT) para el protocolo de Internet IPv6 perf trace, una alternativa a strace Soporte para ARM 64 bits y soporte multiplataforma para ARM Nuevo sistema SMAP (Supervisor Mode Access Prevention) Optimización de Btrfs fsync CIFS soporta ahora SMB (Server Message Block) 2.0 (2.1 en estado experimental) NFS 4.1 abandona el estado experimental y pasa a ser estable Soporte power-save para los chips HD audio Como es habitual, el código fuente ya se puede descargar desde www.kernel.org: http://www.kernel.or...nux-3.7.tar.bz2 Lista completa y detallada de las novedades: http://kernelnewbies.org/Linux_3.7
  16. Como bien dice el título, lightspark es una prometedora alternativa libre a flash (player) bastante potente y bajo licencia GPL v3. Seguramente encuentren lightspark y/o lightsprk-plugin disponible en sus repositorios, no tendrán más que instalarlo desde ellos si quieren empezar a utilizarlo, este tuto es sólo para poder compilar la última versión disponible. Para poder compilar lightspark tendremos que complir con las dependencias. Para ello, los usuarios de distribuciones deb, puede recurrir a liblzma-dev cmake nasm git Para los que no puedan recurrir a build-dep o les falle algo, la lista completa de paquetes que necesitamos e esta: Pasemos a descargar la última versión de Lightspark: cd lightsparkmkdir objcd obj Y pasamos a compilar make install Este último paso copiará el plugin de lightspark en la carpeta de plugins de firefox automáticamente, así que lo único que nos quedaría hacer es ir a nuestro navegador y habilitarlo. De no ser así, el plugin lo encontraremos en la ruta /usr/local/lib/mozilla/plugins/liblightspark.so, sólo tendremos que crear un enlace simbólico: ln -s /usr/local/lib/mozilla/plugins/liblightsparkplugin.so /usr/lib/mozilla/plugins/liblightsparkplugin.so
×