Canonical Voices

Posts tagged with 'software'

Timo Jyrinki

Qt 5.2.1 in Ubuntu

Ubuntu running Qt 5.2.1
Ubuntu running Qt 5.2.1
Qt 5.2.1 landed in Ubuntu 14.04 LTS last Friday, hooray! Making it into a drop-in replacement for Qt 5.0.2 was not trivial. Because of the qreal change, it was decided to rebuild everything against the new Qt, so it was an all at once approach involving roughly 130 source packages while the parts were moving constantly. The landing last week meant pushing to archives around three thousand binary packages - counting all six architectures - with the total size of closer to 10 gigabytes.

The new Qt brings performance and features to base future work on, and is a solid base for the future of Ubuntu. You may be interested in the release notes for Qt 5.2.0 and 5.2.1. The Ubuntu SDK got updated to Qt Creator 3.0.1 + new Ubuntu plugin at the same time, although updates for the older Ubuntu releases is a work in progress by the SDK Team.

How We Got Here

Throughout the last few months before the last joint push, I filed tens of tagged bugs. For most of that time I was interested only in build and unit test results, since even tracking those was quite a task. I offered simple fixes here and there myself, if I found out a fix.

I created automated Launchpad recipe builds for over 80 packages that rely on Qt 5 in Ubuntu. Meanwhile I also kept on updating the Qt packaging for its 20+ source packages and tried to stay on top of Debian's and upstream's changes.

Parallel to this work, some like the Unity 8 and UI Toolkit developers started experimenting with my Qt 5.2 PPA. It turned out the rewritten QML engine in Qt 5.2 - V4 - was not entirely stable when 5.2.0 was released, so they worked together with upstream on fixes. It was only after 5.2.1 release that it could be said that V4 worked well enough for Unity 8. Known issues like these slowed down the start of full-blown testing.

Then everything built, unit tests passed, most integration tests passed and things seemed mostly to work. We had automated autopilot integration testing runs. The apps team tested through all of the app store to find out whether some needed fixes - most were fine without changes. On top of the found autopilot test failures and other app issues, manual testing found a few more bugs

Sudoku
Some critical pieces of software
like Sudoku needed small fixing
Finally last Thursday it was decided to push Qt in, with a belief that the remaining issues had fixes in branches or not blockers. It turned out the real deployment of Qt revealed a couple of more problems, and some new issues were raised to be blockers, and not all of the believed fixes were really fixing the bugs. So it was not a complete success. Considering the complexity of the landing, it was an adequate accomplishment however.

Specific Issues

Throughout this exercise I bumped into more obstacles that I can remember, but those included:
  • Not all of the packages had seen updates for months or for example since last summer, and since I needed to rebuild everything I found out various problems that were not related to Qt 5.2
  • Unrelated changes during 14.04 development broke packages - like one wouldn't immediately think a gtkdoc update would break a package using Qt
  • Syncing packaging with Debian is GOOD, and the fixes from Debian were likewise excellent and needed, but some changes there had effects on our wide-spread Qt 5 usage, like the mkspecs directory move
  • xvfb used to run unit tests needed parameters updated in most packages because of OpenGL changes in Qt
  • arm64 and ppc64el were late to be added to the landing PPA. Fixing those archs up was quite a last minute effort and needed to continue after landing by the porters. On the plus side, with Qt 5.2's V4 working on those archs unlike Qt 5.0's V8 based Qt Declarative, a majority of Unity 8 dependencies are now already available for 64-bit ARM and PowerPC!
  • While Qt was being prepared the 100 other packages kept on changing, and I needed to keep on top of all of it, especially during the final landing phase that lasted for two weeks. During it, there was no total control of "locking" packages into Qt 5.2 transition, so for the 20+ manual uploads I simply needed to keep track of whether something changed in the distribution and accommodate.
One issue related to the last one was that some things needed were in progress at the time. There was no support for automated AP test running using a PPA. There was also no support on building images. If migration to Ubuntu Touch landing process (CI Train, a middle point on the way to CI Airlines) had been completed for all the packages earlier, handling the locking would have been clearer, and the "trunk passes all integration tests too" would have prevented "trunk seemingly got broken" situations I ended up since I was using bzr trunks everywhere.

Qt 5.3?

We are near to having a promoted Ubuntu image for the mobile users using Qt 5.2, if no new issues pop up. Ubuntu 14.04 LTS will be released in a month to the joy of desktop and mobile users alike.

It was discussed during the vUDS that Qt 5.3.x would be likely Qt version for the next cycle, to be on the more conservative side this time. It's not entirely wrong to say we should have migrated to Qt 5.1 in the beginning of this cycle and only consider 5.2. With 5.0 in use with known issues, we almost had to switch to 5.2.

Kubuntu will join the Qt 5 users next cycle, so it's no longer only Ubuntu deciding the version of Qt. Hopefully there can be a joint agreement, but in the worst case Ubuntu will need a separate Qt version packaged.

Read more
facundo

Algunas herramientas piolas


Hace rato que vengo con ganas de hablar acerca de una serie de herramientas interesantes que he encontrado.

Son de lo más variadas. Lo único que tienen en común es que solucionan un problema específico que tuve o tengo. Y que me parece que son piolas :)

Limitando el ancho de banda: ¿Tienen una aplicación que les usa mucho la red? Aunque la misma no esté preparada para autolimitarse, siempre se puede hacer desde afuera, y para ello nos viene a ayudar trickle, un utilitario que hace justamente lo que queremos: ejecutar otro programa limitándo su ancho de banda usable para download, para upload, o ambos.

Midiendo uso de recursos: Muy relacionado con lo anterior, a veces vemos que la red se está usando, pero no sabemos por qué proceso. Para contestarnos esto tenemos dos herramientas, IPTraf y NetHogs,  que nos muestran la info pertinente de forma bastante distinta, por lo cual está bueno tener ambas a mano, para probar cual nos va mejor en cada momento. También nos pasa parecido con el uso del disco. en este caso nos salva las papas el iotop. Para recursos como memoria y CPU tenemos el clásico top, obviamente, pero muchas veces uso htop que es más interactivo y me facilita la exploración.

Fijate si cambió:¿Alguna vez les pasó que tiran un comando en la terminal cada algunos segundos para monitorear algo, tratando de ver si algún dato cambia o viendo cómo cambia? En estos casos lo mejor es usar watch, que nos ejecuta el programa que queremos, cada los segundos que le especificamos, y encima nos resalta los lugares donde hubo cambios con respecto a la ejecución anterior. Más útil de lo que parece.

Mandando muchos mails:Me pasa seguido, para organizar jodas en casa, o eventos en PyAr, o cursos, etc, que tengo que mandar el mismo mail a mucha gente. Mandar uno por uno es mucho trabajo; mandar todos en "copia oculta" es muy impersonal; y ponerlos a todos en "copia visible" es una mala práctica. Por suerte está Mail Merge, un plug-in para Thunderbird que hace todo sencillo: uno pone todos los destinatarios en el campo de "Para:", pero luego en lugar de hacer click en "Enviar", se elige la opción de MailMerge, y en vez de salir uno para todos, el plug-in manda un mail a cada uno. Limpio, y útil. Y tiene opciones para lograr cosas más complejas, pero no lo exploré demasiado, con esta funcionalidad básica por ahora me alcanza.

Seguridad, seguridad: Por último, la herramienta que más me tiene fascinado estos últimos tiempos. Se llama KeePassX, y marcó un antes y un después en mi administración de contraseñas. En el pasado, yo tenía tres o cuatro claves... una genérica, una para lugares de "alta seguridad" como el banco, etc, y las repetía en varios sitios. Así y todo, las claves no eran demasiado complejas (usaba mayúsculas, minúsculas y números, pero no caracteres extraños, y nunca superaba los 10-12 caracteres). ¿Por qué? ¡Por que me las tenía que acordar! Con KeePassX, sin embargo, ya no me las tengo que acordar: se guardan en un archivo (cifrado con una clave que sí tengo que acordarme, y la hice complicada y larga, pero es una sola). El programa no es mucho más que eso, pero también te permite relacionar campos con la clave (en qué sitio va, el nombre de usuario,etc), y también tiene campos genéricos donde uno puede escribir cualquier cosa. Ah, y también te autogenera claves... entonces, la realidad es que ni siquiera veo las alguna vez! Todo esto, sumado a la facilidad de uso (por ejemplo, ctrl-B sobre una entrada te copia el nombre del usuario, y ctrl-C te copia la clave) y que tiene clientes para muchas plataformas (incluida Android), hace que sea una herramienta maravillosa.

Read more
Timo Jyrinki

Background

I upgraded from Linux 3.8 to 3.11 among with newer Mesa, X.Org and Intel driver recently and I found a small workaround was needed because of upstream changes.

The upstream change was the Add "Automatic" mode for "Broadcast RGB" property, and defaulting to the Automatic. This is a sensible default, since many (most?) TVs default to the more limited 16-235, and continuing to default to Full from the driver side would mean wrong colors on the TV. I've set my screen to support the full 0-255 range available to not cut the amount of available shades of colors down.

Unfortunately it seems the Automatic setting does not work for my HDMI input, ie blacks become grey since the driver still outputs the more limited range. Maybe there could be something to improve on the driver side, but I'd guess it's more about my 2008 Sony TV actually having a mode that the standard suggests limited range for. I remember the TV did default to limited range, so maybe the EDID data from TV does not change when setting the RGB range to Full.

I hope the Automatic setting works to offer full range on newer screens and the modes they have, but that's probably up to the manufacturers and standards.

Below is an illustration of the correct setting on my Haswell CPU. When the Broadcast RGB is left to its default Automatic setting, the above image is displayed. When set to Full, the image below with deeper blacks is seen instead. I used manual settings on my camera so it's the same exposure.


Workaround

For me the workaround has evolved to the following so far. Create a /etc/X11/Xsession.d/95fullrgb file:
 
if [ "$(/usr/bin/xrandr -q --prop | grep 'Broadcast RGB: Full' | wc -l)" = "0" ] ; then
/usr/bin/xrandr --output HDMI3 --set "Broadcast RGB" "Full"
fi
And since I'm using lightdm, adding the following to /etc/lightdm/lightdm.conf means the flicker only happens once during bootup:

display-setup-script=/etc/X11/Xsession.d/95fullrgb

Important: when using the LightDM setting, enable executable bits (chmod +x) to /etc/X11/Xsession.d/95fullrgb for it to work. Obviously also check your output, for me it was HDMI3.

If there is no situation where it'd set back to "Limited 16:235" setting on its own, the display manager script should be enough and having it in /etc/X11/Xsession.d is redundant and slows login time down. I think for me it maybe went from 2 seconds to 3 seconds since executing xrandr query is not cheap.

Misc

Note that unrelated to Full range usage, the Limited range at the moment behaves incorrectly on Haswell until the patch in bug #71769 is accepted. That means, the blacks are grey in Limited mode even if the screen is also set to Limited.

I'd prefer there would be a kernel parameter for the Broadcast RGB setting, although my Haswell machine does boot so fast I don't get to see too many seconds of wrong colors...

Read more
Timo Jyrinki

A new Compiz window manager performance update reached Ubuntu 12.04 LTS users last week. This completes the earlier [1] [2] enabling of 'unredirected' (compositing disabled) fullscreen gaming and other applications for performance benefits.

The update has two fixes. The first one fixes a compiz CPU usage regression. The second one enables unredirection also for Intel and Nouveau users using the Mesa 9.0.x stack. That means up-to-date installs from 12.04.2 LTS installation media and anyone with original 12.04 LTS installation who has opted in to the 'quantal' package updates of the kernel, X.Org and mesa *)

The new default setting for the unredirection blacklist is shown in the image below (CompizConfig Settings Manager -> General -> OpenGL). It now only blacklists the original Mesa 8.0.x series for nouveau and intel, plus the '9.0' (not a point release).


I did new runs of OpenArena at openbenchmarking.org from a 12.04.2 LTS live USB. For comparison I first had a run with the non-updated Mesa 9.0 from February. I then allowed Ubuntu to upgrade the Mesa to the current 9.0.3, and ran the test with both the previous version of Compiz and the new one released.

12.04.2 LTS    Mesa 9.0   | Mesa 9.0.3 | Mesa 9.0.3
               old Compiz | old Compiz | new Compiz
OpenArena fps    29.63    |   31.90    | 35.03     

Reading into the results, Mesa 9.0.3 seems to have improved the slowdown in the redirected case. That would include normal desktop usage as well. Meanwhile the unredirected performance remains about 10% higher.

*) Packages linux-generic-lts-quantal xserver-xorg-lts-quantal libgl1-mesa-dri-lts-quantal libegl1-mesa-drivers-lts-quantal. 'raring' stack with Mesa 9.1 and kernel 3.8 will be available around the time of 12.04.3 LTS installation media late August.

Read more
John Pugh

Oh boy. June stormed in and the May installment is late! Not much changed at the top. The Northern Hemisphere spring storms keep Stormcloud at the top with Fluendo DVD staying put at the number two spot. Steam continues its top of the chart spree on the Free Top 10.

Want to develop for the new Phone and Tablet OS, Ubuntu Touch? Be sure to check out the “Go Mobile” site for details.

Top 10 paid apps

  1. Stormcloud
  2. Fluendo DVD Player
  3. Filebot
  4. Quick ‘n Easy Web Builder
  5. MC-Launcher
  6. Mini Minecraft Launcher
  7. Braid
  8. UberWriter
  9. Drawers
  10. Bastion

Top 10 free apps

  1. Steam
  2. Motorbike
  3. Master PDF Editor
  4. Youtube to MP3
  5. Screencloud
  6. Nitro
  7. Splashtop Remote Desktop App for Linux
  8. CrossOver (Trial)
  9. Plex Media Server
  10. IntelliJ IDEA 12 Community Edition

Would you like to see your app featured in this list and on millions of user’s computers? It’s a lot easier than you think:

Notes:

  • The lists of top 10 app downloads includes only those applications submitted through My Apps on the Ubuntu App Developer Site. For more information about of usage of other applications in the Ubuntu archive, check out the Ubuntu Popularity Contest statistics.
  • The top 10 free apps list contains gratis applications that are distributed under different types of licenses, some of which may not be open source. For detailed license information, please check each application’s description in the Ubuntu Software Center.

Follow Ubuntu App Development on:

Social Media Icons by Paul Robert Lloyd

Read more
facundo

Un largo camino al .exe


Algunas versiones de Encuentro (si no recuerdo mal la 0.5 y 0.6) estaban empaquetadas para Windows (con instalador y todo).

Pero hacer ese trabajo era un perno. En este caso lo hacía un muchacho que se llama Javier Andalia, pero después no lo continuó. El drama es básicamente que GTK, la biblioteca que se usaba para la interfaz gráfica es muy poco amigable para hacerla andar en Windows. Siempre fue un dolor de muelas, lo sigue siendo, y no creo que cambie.

Todo empeoró cuando del lado del server cambiaron todo obligándome a cambiar un montón de cosas de mi lado. Ahí salió la versión 0.7, que funcionaba correctamente con el estado actual de situación, pero dejaba a los usuarios de Windows sin tener algo que les funcione.

Y la verdad es que el contenido de Encuentro, Conectate, BACUA, etc, está buenísimo y da para que lo disfruten todos, aunque el usuario tenga un sistema operativo de mierda.

Entonces, encaré el laburo de migrar de GTK a Qt. Y una vez estuvo eso, empaqueté nuevamente para Windows y armé el instalador.

Luego de un par de semanas de "beta", tengo el orgullo de presentarles Encuentro 1.0, :D

Es una release rara porque a nivel funcionalidad real no hay mucho impacto, pero internamente cambió todo.  Igual, lo importante acá es el nuevo público al que puede llegar.

Ah, y mañana jueves con Diego Mascialino (el otro gran desarrollador de Encuentro) hacemos la release party de esta versión... o sea, nos juntamos a tomar algo y jugar unos pooles en Wrangler's... el que quiere venir que venga, están todos invitados! (pero cada uno se paga lo suyo :p).

Read more
Timo Jyrinki

Packages

I quite like the current status of Qt 5 in Debian and Ubuntu (the links are to the qtbase packages, there are ca. 15 other modules as well). Despite Qt 5 being bleeding edge and Ubuntu having had the need to use it before even the first stable release came out in December, the co-operation with Debian has gone well. Debian is now having the first Qt 5 uploads done to experimental and later on to unstable. My work contributed to pkg-kde git on the modules has been welcomed, and even though more work has been done there by others, there haven't been drastic changes that would cause too big transition problems on the Ubuntu side. It has of course helped to ask others what they want, like the whole usage of qtchooser. Now with Qt 5.0.2 I've been able to mostly re-sync all newer changes / fixes to my packaging from Debian to Ubuntu and vice versa.

There will remain some delta, as pkg-kde plans to ask for a complete transition to qtchooser so that all Qt using packages would declare the Qt version either by QT_SELECT environment variable (preferable) or a package dependency (qt5-default or qt4-default). As a temporary change related to that, Debian will have a debhelper modification that defaults QT_SELECT to qt4 for the duration of the transition. Meanwhile, Ubuntu already shipped the 13.04 release with Qt 5, and a shortcut was taken there instead to prevent any Qt 4 package breakage. However, after the transition period in Debian is over, that small delta can again be removed.

I will also need to continue pushing any useful packaging I do to Debian. I pushed qtimageformats and qtdoc last week, but I know I'm still behind with some "possibly interesting" git snapshot modules like qtsensors and qtpim.

Patches

More delta exists in the form of multiple patches related to the recent Ubuntu Touch efforts. I do not think they are of immediate interest to Debian – let's start packaging Qt 5 apps to Debian first. However, about all of those patches have already been upstreamed to be part of Qt 5.1 or Qt 5.2, or will be later on. Some already were for 5.0.2.

A couple of months ago Ubuntu did have some patches hanging around with no clear author information. This was a result of the heated preparation for the Ubuntu Touch launches, and the fact that patches flew (too) quickly in place into various PPA:s. I started hunting down the authors, and the situation turned out to be better than I thought. About half of the patches were already upstreamed, and work on properly upstreaming the other ones was swiftly started after my initial contact. Proper DEP3 fields do help understanding the overall situation. There are now 10 Canonical individuals in the upstream group of contributors, and in the last week's sprint it turned out more people will be joining them to upstream their future patches.

Nowadays about all the requests I get for including patches from developers are stuff that was already upstreamed, like the XEmbed support in qtbase. This is how it should be.

One big patch still being Ubuntu only is the Unity appmenu support. There was a temporary solution for 13.04 that forward-ported the Qt 4 way of doing it. This will be however removed from the first 13.10 ('saucy') upload, as it's not upstreamable (the old way of supporting Unity appmenus was deliberately dropped from Qt 5). A re-implementation via QPA plugin support is on its way, but it may be that the development version users will be without appmenu support for some duration. Another big patch is related to qtwebkit's device pixel ratio, which will need to be fixed. Apart from these two areas of work that need to be followed through, patches situation is quite nice as mentioned.

Conclusion

Free software will do world domination, and I'm happy to be part of it.

Read more
facundo


Con el gran Nico César hace tiempo definimos lo que serían los términos de un servicio que queríamos ofrecer. Por cuestiones varias de la vida, al final nunca terminamos armando algo que cumpla con todos estos requisitos, aunque arrancamos con el proyecto. Pero lo arrancamos en un repo privado.

Muchos meses después, viendo que jamás vamos a seguir eso, le pedí permiso para liberar el código y las especificaciones que armamos. Entonces, subí el código del proyecto a GitHub, y tengo reservado el dominio kilink.com.ar para ofrecer el servicio ahí.

Este proyecto, entonces, lo declaro abierto a la comunidad, para el que quiera participar, participe. Yo lo voy a empujar en el PyCamp de este año!


Descripción general

La idea es ofrecer un "espacio de colaboración de corta vida".  Algo así como un pastebin dinámico, pero que al mismo tiempo sea fácil de usar. En definitiva, algo útil.

Los kilinks van a poder ser editables, y cada nueva edición será hija del kilink editado (cada "submit" es un commit en un virtual versionado de código). Aclaración importante de terminología: el kilink es *uno solo*, que tiene distintas versiones; este kilink único tiene siempre la misma URL, el mismo "kilink id".

Habrá tener coloreado de código, como todos los pastebines, pero con dos grandes diferencias: detección y coloreado automático de tipo de texto, y edición coloreada.

La autenticación será lo más sencilla posible para que un visitante pueda decir "soy Fulano" en la menor cantidad de clicks posibles. La idea es ofrecer de esas autenticaciones que son tan automágicas ahora: openid, via twitter, o facebook, etc, o de última un "usuario/clave" por si la persona no tiene ninguno de los otros mecanismos fáciles.

No hay mecanismos de "compartición" de los kilinks: cualquiera puede acceder a cualquier kilink (en general por la URL que se comparte, pero también buscando, ver abajo).

La autoría del kilink y la responsabilidad sobre ese texto es del usuario que lo pegó ahí. Hay que declinar explícitamente responsabilidad.  El texto incluido en el mismo es de "dominio público" y puede ser mostrado/usado indiscriminadamente.

¿Por qué usar kilink?

  • Se puede usar anonimamente...
  • ...pero recuerda quien sos
  • Permite compartir un texto en pocos clicks
  • Se da cuenta del lenguaje
  • Es amigable a nivel de interfaz
  • Copia el texto directamente a tu clipboard
  • Se puede integrar el texto en donde quieras, por versión o siempre actualizado!


Facilidad de uso / primera impresión

El diseño tiene que ser simple y efectivo, orientado a bajar la barrera de entrada del visitante, el "costo" que el usuario tiene que pagar desde que llega a la página hasta que tiene el kilink en su portapapeles para pegarlo en otro lado. Esto se ve en varios detalles, por ejemplo:

  • que el cursor por default esté en el textarea destino
  • que el textarea, en lugar de estar 100% vacío, tenga adentro un "pegar acá" o algo similar en gris, suavecito, que desaparezca al pegarle algo.
  • que entre el textarea y el botón de submit no haya nada que distraiga
  • que el botón de submit se llame "crear kilink" o lo que corresponda
  • que pueda llevar la url del kilink creado sin tener que seleccionar un texto
  • que se pueda crear un kilink sin registrarse ni loguearse
  • botones para copiar automaticamente al clipboard: URL y texto del kilink
  • download as file
  • botón de imprimir, y CSS especial para que quede linda la impresión
  • etc

Visualmente, la página tiene que ser lo menos intrusiva posible, hay que minimizar la "polución visual", pero sin dejar de ofrecer la información necesaria (al hacer hover con el mouse, o en colores que no llamen demasiado la atención).

Otras características:

  • una URL o kilink ID que casi funciona como  URL corta, ej: kilink.com.ar/4g3jxd
  • el contenido del kilink debería ser indexado por google y otros buscadores


Contribución anónima

Se va a poder crear o editar un kilink sin tener que registrarse ni loguearse, pero va a aparecer "Anonymous" como autor (o algo más divertido).

Dicho esto, al usuario le conviene autenticarse, ya que de esta manera puede tener distintas ventajas:

  • Es autor de los tuits que cree (figura su nombre, digamos)
  • Como es autor, puede borrar sus tuits
  • Tiene en su perfil preferencias para adaptar mejor kilink a sus necesidades (habría que ver cuales :p )


Edición, versionado, diffs

Un gran detalle con respecto a la edición es que va a ser "in place". En otras palabras, en lugar de ofrecer un texto estático y un área nueva (como la mayoría de los pastebines), queremos mostrar el texto del kilink, y que el usuario lo pueda editar ahí mismo.

Obviamente, poder editar nos va a generar una estructura de árbol para las versiones. Este árbol será mostrado de forma explícita en la interfaz web, pudiendo el usuario hacer click en cualquiera de los nodos, viendo las distintas versiones del mismo kilink. Al mostrar las distintas versiones como nodos de un árbol se evita confundir al usuario con cosas como versiones "hermanas", "padres" o "hijas". El usuario ve la versión que tiene elegida, y si la edita aparecerá un nuevo nodo hijo del que estaba viendo.

También, se podrá elegir dos versiones, y pedir un "diff" entre las mismas.


Coloreado del texto y tipo del mismo

¿Qué es la autodetección? En lugar del funcionamiento "pastebin clásico" (de pegar un texto y elegir qué tipo de texto es), cuando el usuario pegue el texto se debe autodetectar qué tipo de texto y colorearlo en el momento según el tipo detectado. Obviamente, va a haber un combobox con todos los tipos, que cambia automáticamente al tipo autodetectado, pero que el usuario puede modificar para rectificar una autodetección erronea (obviamente, si el usuario cambia a mano el tipo de texto, el coloreado cambiará correspondientemente).

La "edición coloreada" es la habilidad de poder editar el kilink y que se vaya coloreando mientras se edita (recordemos que vamos a mostrar un sólo texto y el usuario podrá editar directamente allí).

Ambos comportamientos no son fáciles de lograr, pero facilitaría mucho la interacción del usuario, y quizás con herramientas como google-code-prettify no sea tan complicado.


Caducidad de los kilinks

Los kilinks serán permanentes, nunca vencen y siempre estarán online, a menos que el autor del mismo los borre explícitamente. Esta no-caducidad hay que comunicarla explícitamente, pero aclarando que no nos hacemos cargo si un kilink desaparece por problemas ajenos o propios, o por la baja del servicio.

Con respecto a que los usuarios puedan borrar kilinks, sólo será posible si el usuario es el autor del mismo.

Como esta es una acción poco probable (nadie borra un paste, a menos que se de cuenta que metió info muy sensible o demasiado privada), la idea es que sólo se pueda hacer desde la página de perfil del usuario, para no ensuciar la interfaz de uso "normal".


Herramientas

Hay que tener una colección de herramientas, entre ellas:

  • plugin para editores (seleccioná el texto → kilink, salta a la pag web con el kilink ya creado)
  • plugin para navegador (seleccioná el texto → kilink, idem)
  • linea de comando ("grep ERROR *.log | kilink" y este escupe la url de un kilink nuevo)
  • applet que permita meter una "ventanita para rápidamente crear kilinks" en cualquier lado
  • applet que permita meter un "visualizador de un kilink particular" en cualquier lado
  • applet que permita meter "mis últimos kilinks" en cualquier lado


Tags

Los kilinks tendrán tags asociados, los cuales se crearán de forma semimanual, y servirán como filtros.

Habrá un área cerca del texto donde haya una colección de tags. Al crear un kilink, al momento de pegar el texto, en esa zona aparecerán N tags sugeridos por el sistema (luego de analizar el texto), el usuario puede borrar alguno de esos tags, o agregar más.

Mecanismos para autosugerir tags:

  • lenguaje de programación usado (if any)
  • bibliotecas específicas usadas en el código


API

Se debe implementar una API HTTP sobre la cual se podrá hacer todo lo que se pueda hacer, al punto que la interfaz web usará esa misma API para trabajar contra el backend.

La API tendrá dos modos: autenticado y público. Para el modo público no se necesita nada en particular, pero no se puede hacer todo desde ahí (por ejemplo, borrar kilinks).

Idea: Debemos revisar las APIs de pastebin, snip y tinypaste, que son las más piolas que vimos, para diseñar de entrada algo que tenga sentido. También hay que ver cómo autenticar.

Idea: Ofrecer en el sitio bindings para distintos lenguajes de programación.

Read more
Timo Jyrinki

Whee!! zy

Congrats and thanks to everyone,

Debian 7.0 Wheezy released

Updating my trusty orion5x box as we speak. No better way to spend a (jetlagged) Sunday.

Read more
facundo

LocoLander


En el último sprint internacional que fui en el laburo se me ocurrió una idea a la que le fui dando forma. Se la he contado a varias personas, y la encontraron interesante.

Es un proyecto donde la idea es dar un servicio gratis a la comunidad de software libre. Esto va más allá que Python, pero si lo podemos hacer desde PyAr para toda la comunidad, no estaría nada mal.

Estoy contando acá entonces de qué va el proyecto, y también voy a poner algo de esto en la página del PyCamp, a ver si genera tracción para ser laburado este Junio.


Contexto

La idea surge de una necesidad en particular. Una gran idea dentro de un proyecto de software es "la revisión por pares" (peer review). En ese contexto, cuando uno escribe el código de un cambio, ese código no va directamente al trunk (main, o head, o lo que sea) del proyecto, sino que uno termina el branch, y lo propone a revisión.

Entonces vienen los "pares" y revisan el código, a veces sugieren mejoras (a veces desaprueban totalmente los cambios, puede pasar) y uno tiene que hacer cambios posteriores, a veces lo aprueban sin más trámite, etc. El punto es que en determinado momento el cambio está listo para ser integrado a trunk (main, head, etc.). La acción de "meter el cambio en trunk" se la denomina muchas veces como landear (el código aterriza en el branch principal del proyecto).

¿Cómo se landea un branch? Bueno, hay formas y formas. Pero la más correcta, o completa, o la que está realmente buena hacer es....

  1. agarrar el trunk más reciente, y mergear los cambios del branch en cuestión
  2. si no hubo conflicto, correr los tests de integración del proyecto, y cualquier serie de pruebas (por ejemplo, verificadores de código como lint o pychecker).
  3. si todo estuvo bien, landear el código (esto es, commitear los cambios al trunk)


¿Cual es el problema de esta secuencia? Uno solo: es mucho trabajo. Entonces, o nadie lo hace, o el que lo hace termina tardando mucho en hacerlo. Y ambas situaciones son malas.

¿Por qué malas? En el primer caso, donde no se hace toda la secuencia, se corre el riesgo de meter en trunk código que rompe el mismo, o que no cumple con los estándares de calidad del proyecto. En el segundo caso, el tardar es malo para la colaboración: (me ha pasado que) a veces alguien externo al proyecto sugiere un cambio y escribe el código, y los desarrolladores del proyecto ven que está todo bien, pero demoran todos estos pasos, y finalmente el resultado es que los cambios propuestos tardan semanas en entrar a trunk, lo cual sólo sirve como desmoralizador de la gente que quiere ayudar.

Ahora, imagínense que uno, como desarrollador del proyecto, pudiera decir "este branch está aprobado, está listo para entrar en trunk", y viniera un bot al ratito, y ejecutase todos esos pasos que indiqué yo antes.

LocoLander


El proyecto

En detalle, lo que LocoLander haría es armar un entorno donde uno luego registraría su proyecto, el cual sería revisado de tanto en tanto, y si hay un branch para landear, se realizarían todos estos pasos automáticamente.

Para lograrlo, se levantaría una máquina virtual con un determinado sistema operativo instalado, se instalarían las dependencias que el proyecto necesite (y declare), se copiaría trunk y se le incorporaría los cambios del branch a probar, se correrían luego todos los tests y verificaciones, y finalmente si todo está como corresponde, se meterían esos cambios en trunk.

Algunas consideraciones:

- Configuración para el uso: Cuando se quiera usar LocoLander, se deberá dar de alta el proyecto en la página de LocoLander, autenticando de alguna manera para luego poder ver los resultados de cada intento de merge, etc., indicando qué otras personas pueden ver esa información, e ingresando algunos datos del proyecto en sí.

- Entorno para el proyecto: La idea es que el proyecto lo declare y que el entorno se arme solo en función de las necesidades de cada proyecto. Por ejemplo, que instale un Ubuntu Precise, más estos cuatro paquetes con apt-get, más estos dos con easy_install. Esta información viviría en un archivo especial del proyecto, que LocoLander leería en el momento del armado del entorno. Toda la salida a stdout/stderr de esta etapa quedaría logueada para poder revisarse.

- Ejecución de las pruebas: LocoLander, una vez armado el entorno y con el código brancheado, ejecutaría un archivo puntual (que también está indicado en el archivo de configuración antedicho). Ese archivo puede correr las pruebas unitarias y cualquier control sobre el proyecto, pero la idea es que termina con el resultado en ok o en error, y esto determina si el branch está listo para mergearse a trunk o no. Como en el caso anterior, toda la salida de stdout/stderr estaría disponible para el usuario.

- Repositorios: Aunque tenemos mucha variabilidad en el cómo usarlos, la intención es que LocoLander sea multi-repositorio. O sea que trabaje con Launchpad, GitHub, BitBucket, etc. El trabajo de soportar varios varía más que nada en función de las determinades capacidades que tiene cada repositorio y qué API presenta para no tener que andar scrapeando HTML o haciendo cosas locas para laburar autenticado.

- Autenticación de LocoLander: Esto depende del repositorio en sí, pero en general sería así: LocoLander tendría un usuario en cada repositorio, y si uno quiere usarlo todo lo que tiene que hacer a nivel autenticación es "incorporarlo como colaborador", o "darle permisos de commit en el proyecto", o lo que corresponda en cada repositorio. Lo que no se haría de ninguna manera es poner en el sitio de LocoLander tokens de autenticación de los distintos repositorios. De esta forma, los riesgos de seguridad son mínimos: LocoLander no posee datos críticos de nadie, y el dueño de cualquier proyecto puede en cualquier momento sacarle los permisos de commit a LocoLander.

- Elección de qué branch está listo para intentar mergear: Este punto también depende de cada repositorio. Por ejemplo, en Launchpad, cuando se hace un "merge proposal", el mismo tiene un "estado" que cualquiera con derecho de commit puede poner como "Aprobado", entonces LocoLander revisaría eso. Hay otros repositorios que no son tan completos, pero siempre se puede solucionar con algún texto especial en los comentarios que se dejan. Creo que este es el punto de más variabilidad.

- Previniendo abusos del código que se ejecuta: Un detalle importante en el funcionamiento de LocoLander es que hace muchas cosas él mismo (levantar una VM en particular, instalarle paquetes, etc), pero en algún momento ejecuta código que está en el branch. O sea, le está dando el control a alguien más. ¿Qué podemos hacer para evitar abusos (que la máquina no se ponga a mandar spam, o que no sea un nodo de seti@home...) Creo que el punto crítico acá es que en el momento de tomar el control el proceso potencialmente maligno no pueda acceder a internet para nada, ni a ningún recurso fuera de la máquina virtual en sí. Después se pueden poner condiciones de uso, cortar los procesos que están corriendo más de N minutos, o revisar periódicamente lo que parezca raro, pero creo que ya cortando la posibilidad de conectarse a cualquier lado se está restringiendo bastante la posibilidad de mal uso.

- Recursos necesarios: ¿Qué máquina se necesita para que esto corra? Mi idea es que no mucha. Quizás el más crítico es la memoria: hay que levantar una VM y ejecutar un proceso adentro que debería disponer de al menos unos centenares de megas para correr. Y también se necesita bastante disco (para guardar snapshots de muchas VMs, principalmente), pero cualquier VPS medio pelo da mucho disco. A nivel de velocidad de la máquina en sí, no me jode mucho: si los tests tardan en correr, alpiste.

Creo que cubrí todos los puntos importantes a la hora de definir el proyecto, pero si alguien tiene una duda, es bienvenido a preguntar.

Read more
Timo Jyrinki

I'd like to modify my discussion comment and earlier thoughts into a short blog post touching only some of the technical concerns voiced, and my opinion to those.

Claim (my version): Ubuntu/Canonical is going the "Google route" to become another Android, while Android has not benefited the Linux ecosystem in any way, forking everything

Firstly, Ubuntu is open to development and community for also mobile and tablet - Android has none of that, just code drops that get modded. (yes, some people have a problem with CLA like Canonical's or Qt's, I have no problem with those - let's keep that discussion elsewhere). Ubuntu contributes back to Debian and upstream projects like Qt - those upstream projects it's not upstream of itself. There are not too many free software mobile UIs for example. SHR has some E17 apps, Nemo Mobile a handful of Qt apps and so on.

Secondly, I disagree about Android - even in its current shape and after creating everything from scratch with mobile on mind, Android has done tremendous things for the free software community, kernel development, mobile device driver and making things like Replicant possible. If those aren't directly seen on the desktop side, that's because it's not the desktop and most free software desktop users don't use free software mobile products (usually at most a vendor provided Android).

I feel people get too attached to software projects or even the desktop in general. The money to pay desktop has traditionally largely come from the server. As a discussion-heating example Wayland has been a great promise for 5 years and continues to be, yet no products use it (software products like distributions or hardware+software products). That's not a problem per se for a great and ambitious project, but it means no interested party has taken it to create products. I was very excited about Gallium3D and Wayland in 2008, but somewhat optimistic in believing they would conquer the world in one or two years. In perspective, I've always seen the "version staring" a common habit in enthusiasts me included. I think it extents to "shiny development projects that should be taken into production use immediately".

The Nokia N9 triumphs all other 2011 mobile phones in general and even the current user interfaces like iOS, Android and Windows Phone in general usability ideas (if only it'd run Cortex-A15 instead of OMAP3..). It uses X.org and Qt 4.7. Jolla's plans for their first phone at the end of this year? Qt 4.8, no Wayland. Like N9 which otherwise had unfortunate fate, I hope Jolla will sell millions of free software wielding products to the masses. The biggest problem with X.org is, though, the drivers, generally zero support from vendors so hard to make products. Hooking into Android EGL drivers and building on top of that seems a good compromise at the moment. Note that from product creation point of view it's not the non-shininess of X.org that IMHO is the blocker. Wayland and Mir may help on the driver side.

I want products!

I'd love to see more push to have actual products on the market, since otherwise we don't get free software to the masses. If Mir helps Ubuntu to do that in one year, fine (I don't know how it's going to be). Yes Mir is a new shiny project, but it's a very product/target oriented project one. If Android would be open as a project, it wouldn't hurt - other than feelings attached to the other projects especially by the core developers and fans of those - if it was the superior alternative from product creation perspective making all of X.org, upstart, systemd, Wayland, Pulseaudio, D-Bus, glibc less interesting to product creators while even more interest would go to Android. It's not so now, Android is not an open project in any sense, even though still beneficial for free software. Ubuntu will keep using a lot more of the traditional stack anyway than Android (which also just got rid of BlueZ), but I have zero problem of changing any of the components if it's visioned to be required to get finished, ready to use products out. IMHO the key is to get products out, and I hope all the parties manage to do that.

Of the traditional GNU/Linux desktop distributions only Ubuntu seems to be adapting for the mobile in large steps at the moment. The other distributions in the mobile playing field are: (Android/)Replicant, Mer/Sailfish, Firefox OS, Tizen, added with OpenEmbedded based distributions like SHR. Have you used those on a daily basis on your devices? I believe you should. I think KDE will bring with its Plasma Active - currently focusing on building on top of Mer - mobile power to the traditional GNU/Linux distributions, but otherwise it's all up to the new players - and Ubuntu.

Like many know, I used Debian exclusively on my primary phone for ca. two years before switching mostly to N9. During all that time, I already pondered why people and distributions are so focused on x86 and desktop. And the reason is that that's what their history is, and I stared at the wrong place - desktop distributions. I dismissed Android and some of the small newcomers in the mobile distro playing field, but it seems that big changes are needed to not need completely new players. I think Ubuntu is on the completely right track to both benefit from the history and adapt for the future. I still hope more developers to Debian Mobile, though!! Debian should be the universal operating system after all.

Disclaimer: I'm an Ubuntu community person from 2004, Debian Developer since 2008 and a contractor for Canonical for ca. 1 year. My opinions haven't changed during the 1 year, but I've learned a lot more of how free software is loved at Canonical despite critics.

Read more
facundo

Launcherposta 0.9


Una nueva versión de este programa que es básicamente un ayudante para lanzar aplicaciones que uno lanza seguido (como poner launchers en el panel, pero como eso no existe más en Unity...).

La principal novedad es que ahora hay una manera muy fácil de buscar las aplicaciones instaladas en el sistema para agregarlas en el menú (en el diálogo de agregar una entrada, hay un botón que muestra todas las aplicaciones con sus iconos).

También muestra un mensaje de error (no sólo el código) cuando hay un error al ejecutar algo, ahora tiene una man page, y algún que otro detalle.

Supongo que esta es la última versión del programa, ya que tiene toda la funcionalidad que buscaba y no hay ningún bug abierto.

Más info, cómo descargarlo, etc., en la página del proyecto. Enjoy.

Read more
Timo Jyrinki

Update January 2013: Both Ubuntu 12.04 LTS and Ubuntu 12.10 now have this new feature enabled by default!

Here's an update to my previous entry. In summary, the Compiz update for Ubuntu 12.10 is now in the quantal-proposed updates, and enables unredirection by default for fullscreen applications like games. Happy gaming holidays! A new Compiz update 0.9.7.12 enabling unredirection by default for Ubuntu 12.04 LTS users is in the SRU PPA.

Several changes have happened since the last update, addressing some potential issues uncovered by the people testing the updates (thanks to all!). Daniel has again done all the hard work with regards to actual development.

Changes affecting both 12.10 & 12.04 LTS:

  • Some drivers do not offer tear-free Xv output without a compositor (or glXSwapBuffers in general). Therefore there is a new option available, for which the default setting enables redirection exception in case of some common video players (eg. Adobe Flash plugin and Totem). The option is Composite -> Undirect Match (unredirect_match) available in the CompizConfig Settings Manager (ccsm). The most notable driver is intel on Intel SB/IVB. Those newer chips don't support the XvPreferOverlay xorg.conf option that would bring tear-free non-composited Xv video on earlier Intels.
  • The default setting for unredirect_match should be fine for existing users. But if you want to enable unredirection also for the common/default video players and risk tearing on some drivers and some applications, change the unredirect_match option to be just '(any)'. This might help with video playback on older/slower integrated graphics which are only barely powerful enough to play HD videos.
12.04 LTS only:
  • 0.9.7.10 will not be uploaded to precise, it was just used for early testing. 0.9.7.12 currently tested in the SRU PPA enables unredirection by default also on the 12.04 LTS release.
  • Intel and nouveau mesa drivers are now blacklisted from unredirection on Mesa 8.0 because of so far unresolved driver problems. The blacklist is however configurable in OpenGL -> unredirect_driver_blacklist. The default blacklist regexp is '(nouveau|Intel).*Mesa 8.0'. This does not affect other drivers or Mesa 9.0, so those intel and nouveau users that install 12.04.2 LTS after the end of January or opt-in into the 'LTS-Q' hardware enablement stack for existing installations around the same time will not be blacklisted anymore. Update January 2013: on 12.04 LTS (only), as a last minute change, also Mesa 9.0 in combination with Intel or Nouveau is blacklisted by default at least until LTS-Q stack is properly testable. You can modify the unredirect_driver_blacklist in CCSM -> OpenGL. It was found out that at least mesa 9.0 _only_ from x-updates is not enough - Intel has graphics display problems. It is probable that the problems go away with the full 12.04.2 stack (kernel, X.org, libdrm, mesa) at which point the Intel/nouveau blacklisting can be removed.
  • The original unredirect_fullscreen_windows option is actually forced on now, because of potential gconf setting migration problems. Disabling unredirection can be done via the unredirect_match option above, by simply blanking the string in there, including removing the '(any)' part - everything will be redirected in that case.

Read more
Timo Jyrinki

Unity, which uses Compiz and Nux for drawing, recently had a regression with full screen gaming speeds (LP: #1024304). While the performance of Compiz itself was improved significantly in Ubuntu 12.10, the big changes like full OpenGL ES support brought in some regressions at least from benchmarking point of view. Unity/Compiz has had a small performance impact also in Ubuntu 12.04 LTS depending on what it's being compared to. Any compositing method will necessarily bring some performance hit, but there's another option...

Many people know already about enabling the setting "Unredirect Fullscreen Windows" in Compiz's Composite plugin, but having to enable it manually meant that most people didn't get to use it. The feature detects when an application is running full screen, and simply takes compositing out of the equation, improving performance. Getting the feature work fluently has required fixes in both Compiz and drivers, which is why it hasn't been enabled by default before (LP: #1063690).

But things are progressing now. The Unity team's SRU PPA now has a test build of the new Compiz 0.9.8.6 for Ubuntu 12.10, which enables this feature by default:

ppa:unity-team/sru

Since Phoronix is a frequent reporter on Linux gaming performance, I (very) quickly run phoronix-test-suite's Open Arena test on my Sandy Bridge machine with the stock Ubuntu 12.10 (quantal) Compiz and with Compiz upgraded from the PPA: 18% increase in fps! (test1_1 has older compiz, test1_2 the newer, no settings touched)

The idea is to get the new Compiz into quantal-proposed after the previous snapshot release 1:0.9.8.4+bzr3412-0ubuntu0.1 gets its bug fixes properly verified via the Stable Release Updates process. Note that also this previous snapshot contains all the needed fixes for unredirecting fullscreen windows, the final tagged 0.9.8.6 version just switches the default to be enabled.

For Ubuntu 12.04 LTS (precise) there will be two steps. First of all, Daniel van Vugt has just backported the required Compiz fixes to the 0.9.7 branch of Compiz that the 12.04 LTS uses and tagged the 0.9.7.10 release. Also in the case of precise, there is an earlier snapshot release in the SRU system, but that one does not yet include the needed backports even though it includes many other fixes. The 0.9.7.10 will be available in the same SRU PPA soon. Secondly, once the fixes are in but the feature is not yet enabled by default, the X.org driver team will need to look at additional fixes for the drivers before enabling the Unredirect Fullscreen Windows by default. But after that, Ubuntu 12.04 LTS should also see a Compiz release with this feature turned on by default.

Read more

Cross-compile-o-naut wookey has recently posted a set of Debian & Ubuntu packages for an aarch64 (ie, 64-bit ARMv8) cross compiler:

The repositories here contain sources and binaries for the arm64 bootstrap in Debian (unstable) and Ubuntu (quantal). There are both toolchain and tools packages for amd64 build machines and arm64 binaries built with them. And corresponding sources.

For the lazy:

[jk@pecola ~]$ wget -O - http://people.debian.org/~wookey/bootstrap/bootstrap-archive.key |
    sudo apt-key add -
[jk@pecola ~]$ sudo apt-add-repository 'deb http://people.debian.org/~wookey/bootstrap/ubunturepo/ quantal-bootstrap main universe'
[jk@pecola ~]$ sudo apt-get update
[jk@pecola ~]$ sudo apt-get install --install-recommends gcc-4.7-aarch64-linux-gnu

... which gives you a cross compiler for aarch64:

[jk@pecola ~]$ cat helloworld.c 
#include <stdio.h>
int main(void) { printf("hello world\n"); return 0; }
[jk@pecola ~]$ aarch64-linux-gnu-gcc-4.7 -Wall -O2 -o helloworld helloworld.c
[jk@pecola ~]$ aarch64-linux-gnu-objdump -f helloworld 
helloworld:     file format elf64-littleaarch64
architecture: aarch64, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000000000400450

Read more
Timo Jyrinki

OpenPhoenux GTA04

Postman was on a kind mood yesterday. My OpenPhoenux GTA04 arrived! I had my newer Neo FreeRunner upgraded via the service from Golden Delicious.

First, something rare to behold in phones nowadays - Made in Bavaria:






As a sidenote, also rare now - my Nokia N9 is one of the last phones that had this:

It's sad that's now a thing of the past for both hardware assembly and software! But that's just a hint for new companies to step in.

But back to GTA04 - a quick boot to the pre-installed Debian w/ LXDE:






And then as a shortcut unpacked and booted into QtMoko (well, it's also Debian) instead to test that phone functionality also works - and it does:



Next up: brewing something of my own!

Read more
Timo Jyrinki

I believe I'm not the only one who thinks that use case oriented Grub2 documentation is hard to find, and a lot of the documentation is obsolete or wrong. My main cause for writing this blog post is a currently unanswered question regarding 2.00, but meanwhile it seems months have passed and still most 1.99 documentation is wrong as well, which might be interesting to some.

The aim is to prevent grub entries from being edited, while not restricting actual booting. This protection is meant for computers not having any confidential stuff, but just wanting to do some light weight security with the assumption that the computer isn't physically opened.

Common setup

You will obviously want to disable any automatically generated root access giving entries, by for example uncommenting GRUB_DISABLE_RECOVERY="true" in /etc/default/grub on Debian or Ubuntu. Also you would disable allowing any external boot devices to be used in BIOS/EFI/coreboot, which you would also have protected with a password. And that often means you need to also disable USB legacy support, since some BIOSes tend to offer all USB devices as bootable without password otherwise (note that I guess that could also cause problems accessing setup on desktop computers if your only keyboard is USB).

1.99

So to first fix the false instructions in various places - no, setting the superuser in 00_header as instructed is not enough. It might be, but does not apply if eg. old kernels are put into submenu (Ubuntu bug 718670, Fedora bug 836259). The protection from editing does not apply there. And if you remove all but one kernel so that there is no submenu, a submenu will be automatically created when there is a new kernel installed via security updates. I didn't need the submenu feature anyway, so I used to comment out the following lines in /etc/grub.d/10_linux:

  #if [ "$list" ] && ! $in_submenu; then
    #echo "submenu \"Previous Linux versions\" {"
    #in_submenu=:
  #fi
...
#if $in_submenu; then
#  echo "}"
#fi

I hope that was useful. I can imagine it causing a couple of family battles if the commonly instructed setup was the only protection used and there's for example a case of two computer savvy siblings that are eager to get to each others' computers...

2.00 & The Question

The problem with 2.00 is that the superusers setup yields a non-bootable system, ie. password is required for booting. But Google wasn't smiling at me today! Terrible. Can you help me (and others) with 2.00? The aim would be to have a 1.99-like setup where superuser password protects all entries from editing, but booting is fine without any passwords.

Update: Thanks, problem solved, see comments! Find the following line in /etc/grub.d/10_linux:

      echo "menuentry '$(echo "$os" | grub_quote)' ${CLASS} \$menuentry_id_option 'gnulinux-simple-$boot_device_id' {" | sed "s/^/$submenu_indentation/"

And add --unrestricted there. Don't mix the line with the another menuentry line two lines earlier. The submenu problem doesn't exist anymore in 2.00.

Read more

Most of the components of the 64-bit ARM toolchain have been released, so I've put together some details on building a cross compiler for aarch64. At present, this is only binutils & compiler (ie, no libc), so is probably not useful for applications. However, I have a 64-bit ARM kernel building without any trouble.

Update: looking for an easy way to install a cross-compiler on Ubuntu or debian? Check out aarch64 cross compiler packages for Ubuntu & Debian.

pre-built toolchain

If you're simply looking to download a cross compiler, here's one I've built earlier: aarch64-cross.tar.gz (.tar.gz, 85MB). It's built for an x86_64 build machine, using Ubuntu 12.04 LTS, but should work with other distributions too.

The toolchain is configured for paths in /opt/cross/. To install it, do a:

[jk@pecola ~]$ sudo mkdir /opt/cross
[jk@pecola ~]$ sudo chown $USER /opt/cross
[jk@pecola ~]$ tar -C /opt/cross/ -xf aarch64-x86_64-cross.tar.gz

If you'd like to build your own, here's how:

initial setup

We're going to be building in ~/build/aarch64-toolchain/, and installing into /opt/cross/aarch64/. If you'd prefer to use other paths, simply change these in the commands below.

[jk@pecola ~]$ mkdir -p ~/build/arm64-toolchain/
[jk@pecola ~]$ cd ~/build/arm64-toolchain/
[jk@pecola ~]$ prefix=/opt/cross/aarch64/

We'll also need a few packages for the build:

[jk@pecola ~]$ sudo apt-get install bison flex libmpfr-dev libmpc-dev texinfo

binutils

I have a git repository with a recent version of ARM's aarch64 support, plus a few minor updates at git://kernel.ubuntu.com/jk/arm64/binutils.git (or browse the gitweb view). To build:

Update: arm64 support has been merged into upstream binutils, so you can now use the official git repository. The commit 02b16151 builds successfully for me.

[jk@pecola arm64-toolchain]$ git clone git://gcc.gnu.org/git/binutils.git
[jk@pecola arm64-toolchain]$ cd binutils
[jk@pecola binutils]$ ./configure --prefix=$prefix --target=aarch64-none-linux
[jk@pecola binutils]$ make
[jk@pecola binutils]$ make install
[jk@pecola binutils]$ cd ..

kernel headers

Next up, the kernel headers. I'm using Catalin Marinas' kernel tree on kernel.org here. We don't need to do a full build (we don't have a compiler yet..), just the headers_install target.

[jk@pecola arm64-toolchain]$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
[jk@pecola arm64-toolchain]$ cd linux-aarch64
[jk@pecola linux-aarch64]$ git reset --hard b6fe1645
[jk@pecola linux-aarch64]$ make ARCH=arm64 INSTALL_HDR_PATH=$prefix headers_install
[jk@pecola linux-aarch64]$ cd ..

gcc

And now we should have things ready for the compiler build. I have a git tree up at git://kernel.ubuntu.com/jk/arm64/gcc.git (gitweb), but this is just the aarch64 branch of upstream gcc.

[jk@pecola arm64-toolchain]$ git clone git://kernel.ubuntu.com/jk/arm64/gcc.git
[jk@pecola arm64-toolchain]$ cd gcc/aarch64-branch/
[jk@pecola aarch64-branch]$ git reset --hard d6a1e14b
[jk@pecola aarch64-branch]$ ./configure --prefix=$prefix \
    --target=aarch64-none-linux --enable-languages=c \
    --disable-threads --disable-shared --disable-libmudflap \
    --disable-libssp --disable-libgomp --disable-libquadmath
[jk@pecola aarch64-branch]$ make
[jk@pecola aarch64-branch]$ make install
[jk@pecola aarch64-branch]$ cd ../..

That's it! You should have a working compiler for arm64 kernels in /opt/cross/aarch64.

Read more
facundo

Un lanzador, posta


Una de las primeras cosas que extrañé fuertemente cuando empecé a laburar 100% en unity2d (con Precise) fue la posibilidad de poner iconitos con lanzadores en la misma barra que estaba el systray, el reloj, calendario, etc.

Yo ahí tenía un lanzador para editar el .txt con anotaciones de Canonical, otro con anotaciones para mi blog, para abrir con openoffice mi planilla de gastos, para ejecutar el mumble o el controlador de pulseaudio, etc, etc.

Claro, en unity2d el "launcher" es la barra vertical de la izquierda, pero por diseño tiene funcionalidades opuestas a lo que necesito. La más evidente es que abre "programas"... y si yo quiero abrir mi archivo de anotaciones del blog, para el launcher es abrir un gvim, y como tengo otros gvim abiertos para otras cosas, se confunde.

También se pueden abrir o lanzar cosas desde el "dash" (eso que aparece cuando uno hace click en la tecla que está entre el el control y el alt). Pero no funciona del todo bien si uno quiere abrir archivos (antes me los mostraba, ahora no... e incluso cuando me los mostraba, si tenía dos con el mismo nombre me mostraba ambos, y no sabía cual era cual). En el mejor de los casos, hay que apretar una tecla, escribir parte de lo que queremos ejecutar, esperar a que se refresque, ubicar visualmente lo que uno quiere, hacer click... lentísimo.

En fin. Había perdido la posibilidad de "facilmente lanzar programas o abrir archivos", y decidí hacer algo yo para reemplazarlo. Lo tomé también como excusa para jugar con Gtk3 (obviamente desde Python), ya que cambia mucho con respecto a Gtk2 y todavía no lo había usado para nada.  El resultado: LauncherPosta.

LauncherPosta es un lanzador. Realmente un lanzador. Uno que te deja ejecutar programas, o abrir archivos facilmente, :D.

LauncherPosta

Al ejecutar el programa lo que sucede es que aparece un iconito en el systray, el cual es la principal interfaz con el programa. Allí estarán las opciones que carguemos para ejecutar aplicaciones o abrir archivos.

También tenemos las opciones de Edit (para editar justamente el menu), para ver datos del programa, y para salir.

El detalle es (para la versión que acabo de liberar, ya con la funcionalidad básica):

  • Pone un ícono en el systray, para ser usado como interfaz principal
  • Automáticamente corrige la configuración de unity para hacer que permita poner el ícono en el systray
  • Haciendo click en el ícono te muestra Editar, Acerca de, y Salir
  • "Editar" permite agregar, borrar, o cambiar las opciones del menú, e incluso reordenarlas
  • Las opciones se componene por un ícono (opcional), una descripción, y el comando a ejecutarse
  • Haciendo click en esas opciones del menú ejecutará el comando configurado

En fin, más info y cómo instalarlo, en la página oficial. ¡Que lo disfruten!

Read more
facundo

Conferencias por dos


El sábado pasado fuí a la UbuConLA, la conferencia de Ubuntu organizada conjuntamente por Argentina y Uruguay.

La conferencia era dos días, el viernes más orientado a empresas, el sábado a usuarios finales. Yo fuí solamente el sábado, y di la charla "El futuro de Python en Ubuntu", una presentación que preparé puntualmente para ese evento.

Estuvo todo muy bien, aunque yo creí que iba a ir más gente. Hubieron un par de charlas bien interesantes... me gustó la de Anthony Lenton hablando del Ubuntu Software Center, la de Diego Sarmentero sobre Unity Lens, y la de Martín Eschoyez, sobre animaciones hechas con Blender (en particular, no dejen de ver la animación de apertura del evento, hecha por este muchacho).

Luego de que terminaron las charlas, y de las palabras y sorteos de rigor, nos fuimos todos a por pizza y cerveza al Orsai bar (ya a esta altura confirmo: lo único bueno del lugar es que tienen cerveza decente, y la onda... las pizzas son medio pelo).

Por otro lado, mañana miércoles participo del panel "¿Por qué programar libre?" (junto a Juan Manuel Schillaci y Álvaro Soliverez) en el 3er. Evento de Software Libre y Economía Social, en el Centro Cultural de la Cooperación. Va a estar bueno.

Read more