Solo sé que se querer, que tengo Dios y tengo fe

Roxette, forever Roxette

2025-04-06T00:17:00-03:00

Mas de 30 años mas tarde de escucharlo por primera vez, acá estoy reviviendo un gran album de mi juventud, Joyride. Y dándome cuenta (otra vez) de un detalle no menor: es un gran album de una gran banda. No, no es sólo el idilio adolescente con la banda que consiguió en un casette y se puso a escuchar de lado a lado agotando pilas del Walkman. Es mucho mas. Es mas que el casette que llegó luego de enganchar la cinta de un compilado por rebobinar para esuchar una y otra vez su tema insignia, el homónimo Joyride, con los efectos de gente en un circo.

No. Es una gran banda. Una banda con una sonoridad propia. Con una enorme atención a los detalles... y una enorme cantidad de delicados ellos en sus canciones y letras. Letras. Lo que menos tiendo a tener en cuenta al apreciar una canción... pero no con Roxette.

Tampoco me tendría que resultar raro que haya conseguido tanto éxito en América latina, y en particular en Argentina, donde según Wikipedia vendió mas de 400.000 copias, siendo el álbum en inglés mas vendido hasta la época, superando a The Beatles o Abba. Mamita, que pesos pesados. Pero no. No es la misma sonoridad que nuestro Rock Nacional, pero claramente comparte algo importante, indescriptible quizás. Algo que está mas del lado europeo continental que de norte América...

Pensar que estuve así 👉👈 de cerca de verlos en vivo... y lo dejé para mas tarde. Grave error. Quizás, algún dia, logre conocer a Per. A Marie la saludo al cielo. Y ambos (y la banda) les agradezco su música.

Mer än 30 år efter att jag hörde den för första gången, återupplever jag här en bra album från min ungdom, Joyride. OCH inser (igen) en ingen liten detalj: det är ett bra album av a bra band. Nej, det är inte bara tonårskärleken med bandet som han fick på en kassett och började lyssna från sida till sida, tömde Walkmans batterier. är mycket mer. Det är mer än kassetten som kom efter att ha hakat på bandet från en sammanställd genom att spola tillbaka för att lyssna på hans signaturlåt om och om igen, den eponymous Joyride, med effekterna av människor i en cirkus.

Nej. Det är ett bra band. Ett band med ett eget sound. Med en enorm uppmärksamhet på detaljer... och en enorm mängd känsliga dem i deras sånger och texter. Bokstäver. Det jag minst tenderar att ta hänsyn till när jag uppskattar en låt... men inte med Roxette.

Det borde inte heller verka konstigt för mig att han har nått så mycket framgångar i Amerika Latinamerika, och särskilt i Argentina, där det enligt Wikipedia sålde mer än 400 000 exemplar, som det hittills mest sålda albumet på engelska, överträffar till Beatles eller Abba. Mamma, vilka tunga vikter. Men inte. Det är inte samma sak sonoritet än vår National Rock, men den delar helt klart något viktigt, obeskrivligt kanske. Något som är mer på den kontinentaleuropeiska sidan än på Nordamerika...

Att tro att jag var så här 👉👈 nära att se dem live... och jag lämnade det för mer sent. Allvarligt misstag. Kanske träffar jag Per en dag. Jag hälsar Marie to heaven Och jag tackar er båda (och bandet) för er musik.

More than 30 years after hearing it for the first time, here I am reliving a great album from my youth, Joyride. And realizing (again) a significant detail: it's a great album from a great band. No, it's not just the teenage love affair with the band that I found on a cassette and started listening to from side to side, draining the batteries in my Walkman. It's much more. It's more than the cassette that arrived after plugging in a compilation tape to rewind it to listen to its signature track, the eponymous Joyride, over and over again, with the effects of people in a circus.

No. It's a great band. A band with its own sound. With enormous attention to detail... and an enormous amount of delicate detail in their songs and lyrics. Lyrics. What I tend to take least into account when appreciating a song... but not with Roxette.

It shouldn't seem strange to me that it's achieved so much success in Latin America, and particularly in Argentina, where according to Wikipedia it sold more than 400,000 copies, making it the best-selling English-language album to date, surpassing The Beatles and Abba. Damn, what heavyweights. But no. It's not the same sound as our National Rock, but it clearly shares something important, perhaps indescribable. Something that is more on the continental European side than North American...

To think that I was so close to seeing them live... and I put it off for later. Big mistake. Maybe, one day, I'll get to meet Per. I salute Marie. And I thank both of them (and the band) for their music.

Bahía Blanca floods - Mother nature says: no Nuremberg for you today

2025-03-08T19:27:00-03:00

Update 20250309 13:20-03:00 - How to help

A friend of mine living in the USA sent me this link to help the flood victims: Support Bahía Blanca (Argentina) Flood Victims

Original blog post

These are not good news. In fact, much the contrary. Compared to the real issue, the fact that I'm not able to attend Embedded World at Nuremberg is, well, a detail. Or at least that's what I'm forcing myself to believe, as I REALLY wanted to be there. But mother nature said otherwise.

Park "D. Alberto Martinelli", Las Cañitas, Bahía Blanca (Google Maps)

Bahía Blanca , the city I live, has received a lot on rainfall. Really, a lot. Let me introduce the number like this: the previous highest recorded measurement was 170mm (6.69 inch)... in a month. Yesterday Friday 07 we had more than 400mm (15.75 inch) in 9 hours.

But those are just numbers. Some things are better seen in images.

I'll start with some soft ones.

Sink in Fournier street near Cambaceres (Google Maps)

I also happen to do figure skating in the same school of the 4 times world champions (where "world" means the whole world) Roller Dreams precision skating team - Instagram, from Club El Nacional. Our skating rink got severely damaged with the hail we had like 3 weeks ago (yes, we had hail too!!!). Now it's just impossible:

The "real" thing

Let's get to the heavy, heartbreaker part. I did go to downtown Bahía Blanca, but during night, so let me share some links, most of them in Spanish, but images are images:

El día después de la catástrofe: Bahía volvió a amanecer destrozada, La Nueva.
En 20 imágenes, el inmenso daño que provocó el temporal en Bahía, La Nueva.
Drone footage of the nearby stream, which now seems a river, Instagram.
Drone footage of the same above stream nearer the golf club and entering the city - MP4. I do not know the author, happy to give the proper credits if contacted!!!

My alma matter, Universidad Nacional del Sur, lost its main library, great part of the Physics department and a lot of labs :-(

A nearby town, General Cerri, had even worst luck. In Bahía Blanca, a city of 300k+ people, has around 400 evacuated people. General Cerri, a town of 3000? people, had at least 800.

Bahía Blanca, devil's land

Every place has its legends. We do too. This land was called "Huecuvú Mapú", something like "Devil's land" by the original inhabitants of the zone, due to its harsh climate: string winters and hot summers, couple with fierce wind. But back in 1855 the Cacique (chief) José María Bulnes Yanquetruz had a peace agreement with commander Nicanor Otamendi. But a battle ensued, which Yanquetruz won. At this point history defers depending upon who tells it. Some say Yanquetruz was assigned a military grade as Captain of the indigenous auxiliary forces and provided a military suit, some say he stole it, some say this was a setup of another chief wanting to disrupt peace. But what is known is that Yanquetruz was killed, and his wife, the "machi" (sorceress), issued a curse over the land that would last 1000 years, and the curse was on the climate.

Aftermath

No, we are not there yet. This has just happened. The third violent climate occurrence in 15 months. The city needs to mourn and start healing itself. Time will say.

Going to Embedded World 2025 in Nuremberg

2025-03-03T10:44:00-03:00

This year I'll be participating of Embedded World 2025 in Nuremberg, representing the company I work for, ICS. You will be able to find me at the Automotive Grade Linux booth on hall 4, 4-209.

If you are around be sure to come and say hi, and why not, exchange PGP/GPG keys!

PGP/GPG transition from 0x6286A7D0 to 0xB48C1072

2025-03-02T20:16:00-03:00

I am currently transitioning my GPG/GPG key from D/4096 0x12DDFA84AC23B2BBF04B313CAB645F406286A7D0 to D/4096 0xA94C9FBFA49AA7CD4F40BB9F5E9030CCB48C1072.

Let's put this in plain text, signed with both keys:

The above can be found as a file here.

Mini DebConf 2023 in Montevideo, Uruguay

2023-11-12T08:41:00-03:00

15 years, "la niña bonita", if you ask many of my fellow argentinians, is the amount of time I haven't been present in any Debian-related face to face activity. It was already time to fix that. Thanks to Santiago Ruano Rincón and Gunnar Wolf that proded me to come I finally attended the Mini DebConf Uruguay in Montevideo.

I took the opportunity to do my first trip by ferry, which is currently one of the best options to get from Buenos Aires to Montevideo, in my case through Colonia. Living ~700km at the south west of Buenos Aires city the trip was long, it included a 10 hours bus, a ferry and yet another bus... but of course, it was worth it.

In Buenos Aires' port I met Emmanuel eamanu Arias, a fellow Argentinian Debian Developer from La Rioja, so I had the pleasure to travel with him.

To be honest Gunnar already did a wonderful blog post with many pictures, I should have taken more.

I had the opportunity to talk about device trees, and even look at Gunnar's machine one in order to find why a Display Port port was not working on a kernel but did in another. At the same time I also had time to start packaging qt6-grpc. Sadly I was there just one entire day, as I arrived on Thursday afternoon and had to leave on Saturday after lunch, but we did have a lot of quality Debian time.

I'll repeat here what Gunnar already wrote:

We had a long, important conversation about an important discussion that we are about to present on debian-vote@lists.debian.org.

Stay tuned on that, I think this is something we should all get involved.

All in all I already miss hacking with people on the same room. Meetings for us mean a lot of distance to be traveled (well, I live far away of almost everything), but I really should try to this more often. Certainly more than just once every 15 years :-)

sd-mux-ctrl in Debian

2023-09-28T16:19:00-03:00

Part of what I love to do is to play with embedded devices running Linux. And many times I need to juggle with an SD card in order to copy a filesystem to a board... until I found SDWire.

This little gadget is an SD muxer: it allows you to use it as a "normal" card reader or switch the SD card to the SD card slot. So next time I need to copy contents to a SD card and then push it to a board I can just do it from the command line.

Now the software to control this device was not in Debian, so I fixed that.

I am keeping the code and the packaging on GitLab, as "The Tizen project is not anymore really active".

At the time of writing the package was just accepted, so it might take a couple of hours to be available on the archive.

Enjoy!

Open question: Podman and user/group IDs

2023-07-08T17:45:00-03:00

Here is an open question for Podman users: is there a (ideally simple) way to keep the user/group ID between the real system and the container?

Let me be more verbose.

I use Docker mostly in two "special" cases:

As Yocto build environment: I can use whatever the people I work with/Yocto version wants.
For creating developer environments: I create Docker containers that have the same environments as the CI docker instances I use with GitLab + development tools I run sharing the X socket. In that way the people I work with can reuse the same environment and have the exact same set of tools, without the inconveniences of virtual machines.

Now in both setups I mount some system directory into the chroot, normally as $HOME. Using Docker I can do the right UID/GID mapping and any file I create inside the container will have my system's UID/GID. And that's the thing I so far could not do with Podman.

So dear Podman user: is there any way to do this with Podman? If you know, please feel free to send a comment/email!

Qt 6 in Debian bullseye, take 2

2023-06-16T10:45:00-03:00

Bookworm has been released and Bullseye is now old-stable. Non the less today I took the time to update the Qt 6 backports so they are as close as Bookworm as possible. Except security fixes are needed these ought to be the latest uploads of Qt 6 to bullseye-backports.

Hope you enjoyed them, and thanks again The Qt Company and ICS for making this possible.

Adventures in Debian's Qt land

2023-06-08T00:00:00-03:00

Debian (I might as well say "we", this is the beauty of it) is about to release Debian 12 aka Bookworm. Let's take a quick look at what is new in Debian Qt land.

Qt 5

Bookworm has Qt 5.15.8, which is nothing but great news. KDE will be switching to Qt 6 sooner than later and Qt 5 has been a fun ride, but Dmitry Shachnev and I needed a break, or at very least not handling two Qt versions. But in the end I need to be fair: you REALLY need to thank Dmitry for Qt 5. He has been the man power behind it in 99.5% of the cases.

Qt 6

This will be the first Debian release to have official Qt 6 packages. NOTHING would have happened if it weren't for Patrick "Delta-One" Franz standing up to maintain it. BIG kudos to him!

Well, there is a "little lie" in the paragraph above. Thanks to The Qt Company and ICS the current Qt 6 version, 6.4.2, is also available as Bullseye's backports. The Qt Company really also helped us here by providing us almost-to-be-released tarballs of Qt 6.4.2 so we were able to push them to unstable and do a transition in time for freeze, thanks a lot for that!

So, what is the Qt 6 state?

At the binary side all but OpenGL ES support should be there. Sadly this was discovered too late in the release process and we still might need help maintaining it (read the link to know why!).

We are still not building the documentation. Properly building the whole documentation, as with Qt 5, would require all the Qt submodules' source code in one place, which we can't (easily?) do in Debian. So building the doc means hacking the build system and getting semi-linked documentation, much like with Qt 5. Now if you think you have an idea to solve this... we are happy to hear from you!

Another great thing to know about Qt 6 is that, thanks to Helmut Grohne, pure Qt 6 applications should be able to cross compile. Applications using multi-arch enabled libraries ought to work too. Even more, many Qt submodules themselves should also cross compile! Not all of them, as we missed some patches in time, but hey, if you need to cross compile Qt, you surely can apply them yourselves!

And finally tests, unit tests. In Qt 5 we had some of those, but none yet in Qt 6. This is one of the areas I would love to be able to put time... but time is scarce.

The future?

In my point of view the Debian 13 "Trixie" development cycle will see Qt 5 diminishing it's usage and Qt 6 becoming the major Qt version used, but from the Qt 4 experience I do not expect Qt 5 being dropped during this release cycle... let's see what the future brings us.

Thanks!

While I mentioned Dmitry and Patrick many more people helped us reach this place. I personally want to thank the people behind the KDE software, both upstream and, of course, the Debian maintainers. You should be thankful with them too, many hours of effort go into this.

And thanks to you our dear users. We are normally overflowed with what we have in our hands and might not be up to the task sometimes, but hey, you are part of the reason we are doing this!

Qt 6 in Debian bullseye

2022-06-10T16:22:00-03:00

As announced some time ago on Debian Backport’s mailing list I will be backporting Qt 6 to Debian 11 “Bullseye”. This comprises the (so far) 29 source packages that compose Qt 6 and libassimp.

The Qt Company wanted to let us Debian users also enjoy Qt 6 on Bullseye, so they contacted me (and by extension my employer ICS) to bring this forward. As said in the mail I sent to the backports list I’m making the commitment to maintain the packages myself, but I’m really happy the Qt Company asked me for this.

You can download Qt 6 for Debian Bullseye’s backports by following the instructions.

Also a big kudos to IOhannes m zmölnig, the assimp maintainer, who promptly helped me to get it backported.

Enjoy!

CMake toolchain files with Debian's cross compilers

2021-10-21T10:02:00-03:00

Almost a year ago I added a script made by Helmut Grohne that is able to create a CMake toolchain file pre-filled with Debian-specifics ross compilers.

The tool is installed by the cmake package and located at /usr/share/cmake/debtoolchainfilegen.

It's usage is simple:

debtoolchainfilegen (arch) > cmake_toolchain_<arch>.cmake

Where $arch can be any of the Debian supported architectures, like arm64 (aka aarch64):

$ /usr/share/cmake/debtoolchainfilegen arm64 > /tmp/cmake_toolchain_aarch64
dpkg-architecture: warning: specified GNU system type aarch64-linux-gnu does not match CC system type x86_64-linux-gnu, try setting a correct CC environment variable
dpkg-architecture: warning: specified GNU system type aarch64-linux-gnu does not match CC system type x86_64-linux-gnu, try setting a correct CC environment variable
$ cat /tmp/cmake_toolchain_aarch64
# Use it while calling CMake:
#   mkdir build; cd build
#   cmake -DCMAKE_TOOLCHAIN_FILE="/path/to/cmake_toolchain_<arch>.cmake" ../
#
set(CMAKE_SYSTEM_NAME "Linux")
set(CMAKE_SYSTEM_PROCESSOR "aarch64")
set(CMAKE_C_COMPILER "aarch64-linux-gnu-gcc")
set(CMAKE_CXX_COMPILER "aarch64-linux-gnu-g++")
set(PKG_CONFIG_EXECUTABLE "aarch64-linux-gnu-pkg-config")
set(PKGCONFIG_EXECUTABLE "aarch64-linux-gnu-pkg-config")
set(QMAKE_EXECUTABLE "aarch64-linux-gnu-qmake")

Note: I kept the warnings, which can be ignored and won't end up on the final file.

As you might have noticed the file itself has instructions on how to use it. Of course we will need the requires cross toolchain for the selected arch. For example using arm64:

$ apt install crossbuild-essential-arm64

That's it, we can now start cross building our cmake-based software.

Creating an app with QML: a heater control

2021-06-22T14:48:00-03:00

Last week I took the ICS course "Building an Embedded Application with Qt" and now it's time to put the gained knowledge into action. I decided to create an application to (simulate?) a heater control. Why? Because I have a very basic one at home, and I always dreamed of getting something better. So time to implement it.

Requirements

General

Try to do the business logic in C++ as much as possible.

Thermostat

0.1 ºC resolution.
Regulable hysteresis in the range +/- [0.1 1.0].

Temperature profiles

3 profiles to select (in fact I think 2 would be enough, but one more shouldn't hurt).
Each profile will have each own target temperature and hysteresis.

Profile selection

The system should be able to configure the desired profile in slots of 15' for each day (Monday to Sunday). So 96 slots per day.

Manual button

Sometimes I want to override the predefined configuration for a special situation. This button should allow me to set a new target temperature in a time slot from 15 minutes to 3 hours.

Heater on indicator

We want to know when the heater is being commanded to turn on.

Temperature sensor

This is not strictly decided, so the ability to use different kinds of sensors, one at a time, would be just nice.

User interface

I did some sketches on what I would want as a UI. But I'm not a graphic designer, so I will first do a very simple but yet functional UI and then try to switch to a better designed UI. I dream on emulating an horizontal disc gauge, those where the user sees the border of the disc and the center of it shows the current temperature, perhaps even with a magnifier in the middle. Something like this, but with the needle fixed in the center.

Implementing the idea

The backend

Code repository at GitLab.

My first steps where to implement the C++ backend: a Settings class and a TemperatureEngine class.

For the temperature sensor I decided to make a very simple AbstractTemperatureSensor class and also implement a FakeTemperatureSensor. The later will come handy in order to be able to run tests.

Later on I can implement other temperature sources like reading an analog voltage from some GPIO, getting the data trough MQTT, etc.

The GUI

That's definitely Work In Progress :-)

Firsts steps into QML

2021-06-21T14:48:00-03:00

After years of using and maintaining Qt there was a piece of the SDK that I never got to use as a developer: QML. Thanks to ICS I've took the free (in the sense of cost) QML Programming — Fundamentals and Beyond.

It consists of seven sessions, which can be easily done in a few days. I did them all in 4 days, but with enough time available you can do them even faster. Of course some previous knowledge of Qt comes handy.

The only drawback was the need of a corporate e-mail in order to register (or at least the webpage says so). Apart from that it is really worth the effort. So, if you are planning into getting into QML this is definitely a nice way to start.

On configuring RAK LoRa devices, or how to avoid their Windows-only serial application

2021-03-16T11:02:00-03:00

tl;dr: use a serial terminal which can buffer input and send it all at once, lines should end with \CR\LF.

I'm am currently working on bringing up a LoRa network in Bahía Blanca. Parts of the nodes I need to set up are made by RAK Wireless.

According to their documentation the nodes can be configured by using a serial connection to them. So I quickly turned to minicom for it, with no avail. Somehow I could read whatever the device was writing to my machine but could not write any commands back to it.

In order to get the issue solved I switched to running their RAK serial port tool under wine. Making it work made me download and install a huge amount of Windows libraries and tools, but in the end I wanted a Linux-only solution.

After much digging the web, trial and error I've found a way to solve this:

Commands should end with \CR\LF.
The command needs to be sent quickly, all in one go, trough the serial port. This means it can't be typed and sent as normal serial consoles.

The solution for (1) in minicom is easy, but I don't know if minicom is capable of doing the buffering thing, so I went to use cutecom, for which one has to enter the input and send it all at once.

Stepping down as Qt 6 maintainers

2020-08-18T10:09:00-03:00

After quite some time maintaining Qt in Debian both Dmitry Shachnev and I decided to not maintain Qt 6 when it's published (expected in December 2020, see https://wiki.qt.io/Qt_6.0_Release). We will do our best to keep the Qt 5 codebase up and running.

We **love** Qt, but it's a huge codebase and requires time and build power, both things that we are currently lacking, so we decided it's time for us to step down and pass the torch. And a new major version seems the right point to do that.

We will be happy to review and/or sponsor other people's work or even occasionally do uploads, but we can't promise to do it regularly.

Some things we think potential Qt 6 maintainers should be familiar with are, of course, C++ packaging (specially symbols files) and CMake, as Qt 6 will be built with it.

We also encourage prospective maintainers to remove the source's -everywhere-src suffixes and just keep the base names as source package names: qtbase6, qtdeclarative6, etc.

It has been an interesting ride all these years, we really hope you enjoyed using Qt.

Thanks for everything,

Dmitry and Lisandro.

Note 20200818 12:12 ARST: I was asked if the move has anything to do with code quality or licensing. The answer is a huge no, Qt is a **great** project which we love. As stated before it's mostly about lack of free time to properly maintain it.

Simplified Monitoring of Patients in Situations of Mass Hospitalization (MoSimPa) - Fighting COVID-19

2020-06-02T09:49:00-03:00

I have been quite absent from Debian stuff lately, but this increased since COVID-19 hits us. In this blog post I'll try to sketch what I have been doing to help fight COVID-19 this last few months.

In the beginning

When the pandemic reached Argentina the government started a quarantine. We engineers (like engineers around the world) started to think on how to put our abilities in order to help with the situation. Some worked toward providing more protection elements to medical staff, some towards increasing the number of ventilation machines at disposal. Another group of people started thinking on another ways of helping. In Bahía Blanca arised the idea of monitoring some variables remotely and in masse.

Simplified Monitoring of Patients in Situations of Mass Hospitalization (MoSimPa)

This is where the idea of remotely monitored devices came in, and MoSimPa (from the spanish of "monitoreo simplificado de pacientes en situación de internación masiva") started to get form. The idea is simple: oximetry (SpO2), heart rate and body temperature will be recorded and, instead of being shown in a display in the device itself, they will be transmitted and monitored in one or more places. In this way medical staff doesn't has to reach a patient constantly and monitoring could be done by medical staff for more patients at the same time. In place monitoring can also happen using a cellphone or tablet.

The devices do not have a screen of their own and almost no buttons, making them more cheap to build and thus more in line with the current economic reality of Argentina.

This is where the project Para Ayudar was created. The project aims to produce the aforementioned non-invasive device to be used in health institutions, hospitals, intra hospital transports and homes.

It is worth to note that the system is designed as a complementary measure for continuous monitoring of a pacient. Care should be taken to check that symptomps and overall patient status don't mean an inmediate life threat. In other words, it is NOT designed for ICUs.

All the above done with Free/Libre/Open Source software and hardware designs. Any manufacturing company can then use them for mass production.

The importance of early pneumonia detection

We were already working in MoSimPa when an NYTimes article caught or attention: "The Infection That’s Silently Killing Coronavirus Patients". From the article:

A vast majority of Covid pneumonia patients I met had remarkably low oxygen saturations at triage — seemingly incompatible with life — but they were using their cellphones as we put them on monitors. Although breathing fast, they had relatively minimal apparent distress, despite dangerously low oxygen levels and terrible pneumonia on chest X-rays.

This greatly reinforced the idea we were on the right track.

The project from a technical standpoint

As the project is primarily designed for and by Argentinians the current system design and software documentation is written in spanish, but the source code (or at least most of it) is written in english. Should anyone need it in english please do not hesitate in asking me.

General system description

The system is comprised of the devices, a main machine acting as a server (in our case for small setups a Raspberry Pi) and the possibility of accessing data trough cell phones, tablets or other PCs in the network.

The hardware

As of today this is the only part in which I still can't provide schematics, but I'll update this blog post and technical doc with them as soon as I get my hands into them.

Again the design is due to be built in Argentina where getting our hands on hardware is not easy. Moreover it needs to be as cheap as possible, specially now that the Argentinian currency, the peso, is every day more depreciated. So we decided on using an ESP32 as the main microprocessor and a set of Maxim sensors devices. Again, more info when I have them at hand.

The software

Here we have many more components to describe. Firstly the ESP32 code is done with the Arduino SDK. This part of the stack will receive many updates soon, as soon as the first hardware prototypes are out.

For the rest of the stack I decided to go ahead with whatever is available in Debian stable. Why? Well, Raspbian provides a Debian stable-based image and I'm a Debian Developer, so things should go just natural for me in that front. Of course each component has its own packaging. I'm one of Debian's Qt maintainers then using Qt will also be quite natural for me. Plots? Qwt, of course. And with that I have most of my necessities fulfilled. I choose PostgreSql as database server and Mosquitto as MQTT broker.

Between the database and MQTT is mosimpa-datakeeper. The piece of software from which medical staff monitor patients is unsurprisingly called mosimpa-monitor.

MoSimPa's monitor main screen

Plots of a patient's data

Alarm thresholds setup

And for managing patients, devices, locations and internments (CRUD anyone?) there is currently a Qt-based application called mosimpa-abm.

ABM internments view

The idea is to replace it with a web service so it doesn't needs to be confined to the RPi or require installations in other machines. I considered using webassembly but I would have to also build PostgreSql in order to compile Qt's plugin.

Translations? Of course! As I have already mentioned the code is written in English. Qt allows to easily translate applications, so I keep a Spanish one as the code changes (and we are primarily targeting spanish-speaking people). But of course this also means it can be easily translated to whichever language is necessary.

Even if I am a packager I still have some stuff to fix from the packaging itself, like letting datakeeper run with its own user. I just haven't got to it yet.

A video showing the software in action

Certifications

We are working towards getting the system certified by ANMAT, which is the Argentinian equivalent for EEUU's FDA.

Funding

While all the people involved are working ad-honorem funding is still required in order to buy materials, create the prototypes, etc. The project created payments links with Mercado Pago (in spanish and argentinian pesos) and other bank methods (PDF, also in spanish).

I repeat the links here with an aproximation to US$.

You can check the actual convertion rate in https://www.google.com/search?q=argentine+peso+to+us+dollars

The project was also presented at a funding call of argentinian Agencia de Promoción de la Investigación, el Desarrollo Tecnológico y la Innovación (Agencia I+D+i). 900+ projects where presented and 64 funded, MoSimPa between them.

Qt 4 removed from Debian Sid (unstable)

2020-03-07T21:38:00-03:00

The day has finally arrived: Qt 4 is no longer part of Debian unstable. It's gone.

Thanks should go to many people. You know who you are, and I really appreciate the support and time you put into this. **Thanks**

Qt 4 removed from Debian bullseye (current testing)

2020-01-09T19:31:00-03:00

Today Qt 4 (aka src:qt4-x11) has been removed from Debian bullseye, what as of today we know as "testing". We plan to remove it from unstable pretty soon.

Developing Nordics' nRF9160 DK using Qt Creator

2019-08-09T15:12:00-03:00

So I've got my hands into a nRF9160DK (development kit). Like I did with the nRF51822 I would love to develop software for this board using as much FLOSS tools as possible to avoid any kind of vendor lock-in.

This board actually has two interesting ICs: the nRF9160 which anyone would expect and a nRF52840. At first I'm targeting the first one.

The nRF9160's firmware is based on Zephyr which uses CMake. This is great as my preferred IDE is Qt Creator which has quite nice CMake integration.

Preparing the toolchain and proprietary code

There is of course some Nordic proprietary code to put in the mix. So the first step is to setup Nordic's SDK. For that one needs to follow the "Get started with development" section in their web page. One needs to download an nRFConnect AppImage binary and start it. How safe it is to run proprietary code in our machines? Now that's an interesting question.

Once there, and still following Nordic's documentation, we need to install the "Getting started Assistant" and run it. We will follow all steps in it except the last ones for installing a proprietary IDE. We want to code using Qt Creator after all.

Building the asset tracker example from the command line

So let's start by trying to build the example (the only one so far?) from the command line. After some trial and error I've got the following:

mkdir build
cd build
GNUARMEMB_TOOLCHAIN_PATH="/opt/gcc-arm-none-eabi-7-2018-q2-update"

ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb ZEPHYR_BASE="$NCS_BASE/zephyr"

cmake -DBOARD_ROOT="$NCS_BASE/zephyr/boards/arm/nrf9160_pca10090"

-DBOARD="nrf9160_pca10090ns" ../

Where NCS_BASE is the path to the previously downloaded SDK. In this case I selected the non secure version build for this board.

The next step is then easy.

Building the asset tracker example from within Qt Creator

Once we've got to compile the example from the command line switching to Qt Creator is easy. First of all we want to set up a Kit as I did for the nRF51822. Follow the instructions there but this time set up the new GCC version required by this development kit.

The next step is to provide as much definitions as possible as part of the kit itself. Got to Tools → Options... and then to Kits. Select the newly created kit (I called it nRF9160) and then change "CMake Configuration" settings. The resulting text should look like:

BOARD:STRING=nrf9160_pca10090ns

BOARD_ROOT:STRING=path/to/ncs/zephyr/boards/arm/nrf9160_pca10090

CMAKE_CXX_COMPILER:STRING=%{Compiler:Executable:Cxx}

CMAKE_C_COMPILER:STRING=%{Compiler:Executable:C}

CMAKE_PREFIX_PATH:STRING=%{Qt:QT_INSTALL_PREFIX}

GNUARMEMB_TOOLCHAIN_PATH:STRING=/opt/gcc-arm-none-eabi-7-2018-q2-update

ZEPHYR_TOOLCHAIN_VARIANT:STRING=gnuarmemb

Some of those definitions are not really necessary in there. ZEPHYR_BASE needs to be set as an environment variable. This is the only akward part of this setup, as the only way I could find to do so from within Qt Creator is to set it up in a per-project fashion.

Once the above is done open \$NCS_BASE/nrf/applications/asset_tracker/CMakeLists.txt. The configuration will fail, as we haven't suplied ZEPHYR_BASE yet. To do so go to "Projects" on the right, Select "Build" within the kit and set up ZEPHYR_BASE within the "Build Environment" section at the bottom.

That's is, you are now ready to use "Run CMake" from within the "Build" menu and you are ready to go.

Using libgps instead of libQgpsmm within a Qt application

2018-11-17T16:12:00-03:00

I was in need of creating a Qt application using current Debian stable (Stretch) and gpsd. I could have used libQgpsmm which creates a QTcpSocket for stablishing the connection to the gpsd daemon. But then I hit an issue: libQgpsmm was switched to Qt 5 after the Strech release, namely in gpsd 3.17-4. And I'm using Qt 5.

So the next thing to do is to use libgps itself, which is written in C. In this case one needs to call gps_open()]{style="font-family: \"Courier New\", Courier, monospace;"} to open a connection, [gps_stream()]{style="font-family: \"Courier New\", Courier, monospace;"} to ask for the needed stream... and use [gps_waiting() to poll the socket for data.
[
]{style="font-family: \"Courier New\", Courier, monospace;"}gps_waiting() checks for data for a maximum of time specified in it's parameters. That means I would need to create a QTimer and poll it to get the data. Poll it fast enough for the application to be responsive, but not too excessively to avoid useless CPU cycles.

I did not like this idea, so I started digging gpsd's code until I found that it exposes the socket it uses in it's base struct, struct gps_data_t]{style="font-family: \"Courier New\", Courier, monospace;"}'s [gps_fd]{style="font-family: \"Courier New\", Courier, monospace;"}. So the next step was to set up a QSocketNotifier around it, and use it's [activated() signal.

So (very) basically:

// Class private:
struct gps_data_t mGpsData;
QSocketNotifier * mNotifier;
[
]{style="font-family: \"Courier New\", Courier, monospace;"}// In the implementation:
result = gps_open("localhost", DEFAULT_GPSD_PORT, &mGpsData);
// [...check result status...]

result = gps_stream(&mGPSData,WATCH_ENABLE|WATCH_JSON, NULL);
// [...check result status...]

// Set up the QSocketNotifier instance.
mNotifier = new QSocketNotifier(mGpsData.gps_fd, QSocketNotifier::Read, this);

connect(mNotifier, &QSocketNotifier::activated, this, &MyGps::readData);

And of course, calling gps_read(&mGpsData)]{style="font-family: \"Courier New\", Courier, monospace;"} in [MyGps::readData(). With this every time there is activity on the socket readData() will be called, an no need to set up a timer anymore.

Cross compiling CMake-based projects using Ubuntu/Debian's multi arch

2018-11-02T14:20:00-03:00

As you probably already know Ubuntu (and then Debian) added Multi-Arch support quite some time ago. This means that you can install library packages from multiple architectures on the same machine.

Thanks to the work of many people, in which I would like to specially mention Helmut Grohne, we are now able to cross compile Debian packages using standard sbuild chroots. He even was kind enough to provide me with some numbers:

We have 28790 source packages in Debian unstable.
Of those, 13358 (46.3%) build architecture-dependent binary packages.
Of those, 7301 (54.6%) have satisfiable cross Build-Depends.
Of those, 3696 (50.6% of buildable, 27.6% of sources) were attempted.
Of those, 2695 (72.9% of built, 36.9% of buildable, 20.1% of sources) were successful.
633 bugs affecting 772 packages (7.23% of 10663 unsuccessful) are reported.

Now I asked myself if I could use this to cross compile the code I'm working on without the need of doing a full Debian package build.

My projects uses CMake, so we can cross compile by providing a suitable CMAKE_TOOLCHAIN_FILE.

And so the first question is:

How do we create the necessary file using what Multi-Arch brings to our table?

I asked Helmut and he did not only provide me with lots of tips, he also provided me with the following script, which I modified a little:

Now we can run the script providing it with the desired host arch and voilá, we have our toolchain file.

Update 20230623: Since long Debian's cmake ships this script as /usr/share/cmake/debtoolchainfilegen.

#!/bin/sh
set -x

ARCH=$DEB_HOST_GNU_TYPE=$(dpkg-architecture -f "-a$1" -qDEB_HOST_GNU_TYPE)
DEB_HOST_GNU_CPU=$(dpkg-architecture -f "-a$1" -qDEB_HOST_GNU_CPU)

case "$(dpkg-architecture -f "-a$1" -qDEB_HOST_ARCH_OS)" in
  linux) system_name=Linux; ;;
  kfreebsd) system_name=kFreeBSD; ;;
  hurd) system_name=GNU; ;;
  *) exit 1; ;;
esac

cat < EOF > cmake_toolchain_$1.cmake
# Use it while calling CMake:
# mkdir build; cd build
# cmake -DCMAKE_TOOLCHAIN_FILE="../cmake_toolchain_`<arch>`{=html}.cmake" ../`</arch>`{=html}
set(CMAKE_SYSTEM_NAME "$system_name")
set(CMAKE_SYSTEM_PROCESSOR "$DEB_HOST_GNU_CPU")
set(CMAKE_C_COMPILER "$DEB_HOST_GNU_TYPE-gcc")
set(CMAKE_CXX_COMPILER "$DEB_HOST_GNU_TYPE-g++")
set(PKG_CONFIG_EXECUTABLE "$DEB_HOST_GNU_TYPE-pkg-config")
set(PKGCONFIG_EXECUTABLE "$DEB_HOST_GNU_TYPE-pkg-config")
EOF

Can we improve this?

Helmut mentioned that meson provides debcrossgen, a script that automates this step. Meson is written in python, so it only needs to know the host architecture to create the necessary definitions.

CMake is not interpreted, but maybe it has a way to know the host arch in advance. If this is true maybe a helper could be added to help in the process. Ideas (or even better, patches/code!) welcomed.

Running MPLAB X with a PickIt 3 on Debian sid

2018-05-23T15:30:00-03:00

Due to $JOB I need to work with MPLAB X (I wish I could simply open Qt Creator...). MPLAB X's installation went straightforward, but I could not make the PickIt 3 to work.

So I ran MPLAB X from a console and got:

$ /opt/microchip/mplabx/v4.15/mplab\_ide/bin/mplab\_ide
libusb couldn't open USB device /dev/bus/usb/006/013: Permission denied.

Yes, I rebooted my machine previous to running MPLABX (a udev restart would have been enough though) but something is not yet working.

Quick and dirty solution: chmod lisandro:lisandro /dev/bus/006/013

Yes, I'll have to re do this every time I plug the PickIt, but at least I've got it working.

moving Qt 4 from Debian testing (aka Buster): some statistics, update II

2018-04-21T09:47:00-03:00

As in my previous blogpost I'm taking a look at our Qt4 removal wiki page.

Of a total of 438 filed bugs:

181 bugs (41.32%) have been already fixed by either porting the app/library to Qt 5 or a removal from the archive has happened. On most cases the code has been ported and most of the deletions are due to Qt 5 replacements already available in the archive and some due to dead upstreams (ie., no Qt5 port available).
257 bugs (58.68%) still need a fix or are fixed in experimental.
35 bugs (8% of the total, 13% of the remaining) of the remaining bugs are maintained inside the Qt/KDE team.

We started filing bugs around September 9. That means roughly 32 weeks which gives us around 5.65 packages fixed per week, aka 0.85 packages per day. Obviously not as good as we started (remaining bugs tend to be more complicated), but still quite good.

So, how can you help?

If you are a maintainer of any of the packages still affected try to get upstream to make a port and package it.

If you are not a maintainer you might want to take a look at the list of packages in our wiki page and try to create a patch for them. If you can submit it directly to upstream, the better. Or maybe it's time for you to become the package's upstream or maintainer!

Experimental cross compiling Qt in Debian packages

2017-11-28T16:35:00-03:00

Some time ago we the Qt/KDE team were contacted by [Helmut Grohne. He was trying to cross compile Debian packages in general thanks to Ubuntu/Debian's multi-arch support, and he was having problems with Qt-based ones.]{style="background-color: white;"}
[[
]{style="background-color: white;"}]{style="font-family: inherit;"}[As far as we understand Qt upstreams only support cross compiling by having a toolchain for each pair of architectures involved. In Debian terms, and only considering current official architectures, that would mean building 90 cross toolchains. It clearly doesn't scale.]{style="background-color: white;"}
[[
]{style="background-color: white;"}]{style="font-family: inherit;"}[So we set up to discuss if somehow we could use multiarch to let debian packages using Qt to cross compile.]{style="background-color: white;"}
[[
]{style="background-color: white;"}]{style="font-family: inherit;"}[In the meantime Enrico Zini had the same idea. He wrote a nice summary of the situation at that time in his blog.]{style="background-color: white;"}
[[
]{style="background-color: white;"}]{style="font-family: inherit;"}After many thinking some ideas were tested and we've got to the point of solving/hacking the issue. As this is not something directly supported by upstream you should take care, and file bugs whenever necessary.
[
]{style="background-color: white;"}Dmitry Schachnev from our team's side and Helmut from the debian-cross side worked a lot on it, and I would like to present what they have done. To be fair it's mostly described in our team's gobby qt-cross page, but I would like to give it some publicity in order to let people know about it and why not, find and help solving bugs.
[[
]{.underline}]{style="background-color: white;"}General stuff
[
]{style="background-color: white;"}The first thing that was done was to move Qt binaries from their (Debian original) multi-arch path to a non multi-arch one, providing symlinks for compatibility. In this way the path of the binaries is the same for any arch (why they were not there is a long story, but nothing to worry now).

This move needed some other touches, like qtchooser being updated with the new paths.

The other changes where related to how we do our packaging:

All packages containing binaries are now M-A:foreign.
Some packages (qt3d, qtwayland) had binaries split to allow that.
qttools5-dev-tools now depends on libqt5sql5-sqlite (not uploaded yet)

**qmake related changes**

We also needed to address qmake. To begin with we splitted the package containing it into qt5-qmake-bin (M-A:foreign) and qt5-qmake (M-A:same). The first one has the binaries and the second the relevant mkspecs for some arch.

The rest of the "magic" comes from debhelper. It generates a qt.conf file with the right paths for each cross compilation and also passes cross QMAKE\_CC and QMAKE\_CXX to qmake when needed.

[[
]{style="background-color: white;"}]{style="font-family: inherit;"}[autotools]{style="background-color: white;"}
[[
]{style="background-color: white;"}]{style="font-family: inherit;"}qt5-qmake will ship /usr/bin/\$(DEB_HOST_GNU_TYPE)-qmake executable for use with AC_CHECK_TOOL (not uploaded yet).

There is still work to be done, but so far we have been able to cross compile packages using for example sbuild.

Edit 20171129 11:43 ARST: You should really look at the new Enrico's post.

Removing Qt 4 from Debian testing (aka Buster): some statistics

2017-11-24T17:21:00-03:00

I have just looked upon our Qt 4 removal wiki page to see how we are doing. Out of 438 bugs filled:

88 (20.09%) have been already fixed by either porting the app/library to Qt 5 or a removal from the archive has happened. On most cases the code has been ported and most of the deletions are due to Qt 5 replacements already available in the archive and a few due to dead upstreams.
3 (0.68%) packages are marked as fixed an an upload is pending.
65 (14.84%) of the open bugs are maintained inside the Qt/KDE team. Many of them should get a Qt 5 version with the next KF5 uploads.

We started filing bugs around September 9. That means roughly 11 weeks, which gives us around 8 packages fixed a week, aka 1.14 packages per day. Not bad at all!

So, how can you help?

If you are a maintainer of any of the packages still affected try to get upstream to make a port and package it.

If you are not a maintainer you might want to take a look at the list of packages in our wiki page and try to create a patch for them. If you can submit it directly to upstream, the better.

Qt 4 and 5 and OpenSSL1.0 removal

2017-10-13T11:29:00-03:00

Today we received updates on the OpenSSL 1.0 removal status:

\<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828522#206>
\<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859671#19>

So those removal bugs' severities will be raised to RC in aproximately a month.

We still don't have any solutions for Qt 4 or 5.

For the Qt 5 case we will probably keep the bug open until Qt 5.10 is in the archive which should bring OpenSSL 1.1 support *or* FTP masters decide to remove OpenSSL1.0. In this last case the fate will be the same as with Qt4, below.

For Qt4 we do not have patches available and there will probably be none in time (remember we do not have upstream support). That plus the fact that we are actively trying to remove it from the archive it means we will remove openssl support. This might mean that apps using Qt4:

Might cease to work.
Might keep working:
- Informing their users that no SSL support is available → programmer did a good job.
- Not informing their users that no SSL support is available and establishing connections non the less → programmer might have not done a good job.

Trying to inform users as soon as possible,

Lisandro for the Qt/KDE team.

Qt 4 removal in Debian testing (Buster)/unstable

2017-08-15T13:50:00-03:00

We have been announcing it: we are going to remove Qt 4 during the Buster cycle.

Or at least that's the best outcome we can expect. Removing a very highly used library is hard, as Qt4's Webkit has proved. Qt 4 is long dead upstream and we have already started to need to patch it with untested patches as in the OpenSSL 1.1 case (will be in experimental in a few hours after this post).

We will try to put as less effort as possible in keeping it alive meaning that from now on if we need to patch it to make it support a newer lib or alike we will simply remove its support if possible. Using the OpenSSL case as an example, if we need to support any version > 1.1 we will simply remove the SSL support. That means things will break.

So, if you depend on FLOSS which is still based on Qt 4 be sure to try to port it. If you depend on a proprietary vendor software which uses Qt 4 then you better start telling them it's really time to update it. Really.

We will soon start filing bugs against packages using Qt 4. I'll update this blog post later to add that info.

For the Qt/KDE team, Lisandro.

Qt 5.7 submodules that didn't make it to Stretch but will be in testing

2017-06-24T19:41:00-03:00

There are two Qt 5.7 submodules that we could not package in time for Strech but are/will be available in their 5.7 versions in testing. This are qtdeclarative-render2d-plugin and qtvirtualkeyboard.

declarative-render2d-plugin makes use of the Raster paint engine instead of OpenGL to render the contents of a scene graph, thus making it useful when Qt Quick2 applications are run in a system without OpenGL 2 enabled hardware. Using it might require tweaking Debian's /etc/X11/Xsession.d/90qt5-opengl. On Qt 5.9 and newer this plugin is merged in Qt GUI so there should be no need to perform any action on the user's behalf.

Debian's VirtualKeyboard currently has a gotcha: we are not building it with the embedded code it ships. Upstream ships 3rd party code but lacks a way to detect and use the system versions of them. See QTBUG-59594, patches are welcomed. Please note that we prefer patches sent directly upstream to the current dev revision, we will be happy to backport patches if necessary.
Yes, this means no hunspell, openwnn, pinyin, tcime nor lipi-toolkit/t9write support.

Note 2017-07-16: please use 5.7.1+dfsg-2, it fixes a wrong dependency and adds use of the system's hunspell.

Developing an nrf51822 based embedded device with Qt Creator and Debian

2017-02-22T10:18:00-03:00

I'm currently developing an nRF51822-based embedded device. Being one the Qt/Qt Creator maintainers in Debian I would of course try to use it for the development. Turns out it works pretty good... with some caveats.

There are already two quite interesting blog posts about using Qt Creator on MAC and on Windows, so I will not repeat the basics, as they are there. Both use qbs, but I managed to use CMake.

Instead I'll add some tips on the stuff that I needed to solve in order to make this happen on current Debian Sid.

The required toolchain is already in Debian, just install binutils-arm-none-eabi, ]{style="background-color: white;"}[gcc-arm-none-eabi and ]{style="background-color: white;"}[gdb-arm-none-eabi.
You will not find arm-none-eabi-gdb-py on the gdb-arm-none-eabi package. Fear not, the provided gdb binary is compiled against python so it will work.
To enable proper debugging be sure to follow this flag setup](https://devzone.nordicsemi.com/question/116587/debugging-with-breakpoints-correct-gcc-flags/). If you are using CMake like in this example be sure to modify [CMake/toolchain_gcc.cmake as necessary.
In Qt Creator you might find that, while try to run or debug your app, you are greated with a message box that says ]{style="background-color: white;"}["Cannot debug: Local executable is not set." Just go to Projects →Run and change "Run configuration" until you get a valid path (ie, a path to the .elf or .out file) in the "Executable" field.

Cheers!

KDEPIM ready to be more broadly tested

2016-07-17T20:15:00-03:00

As was posted a couple of weeks ago, the latest version of KDEPIM has been uploaded to unstable.

All packages are now uploaded and built and we believe this version is ready to be more broadly tested.

If you run unstable but have refrained from installing the kdepim packages up to now, we would appreciate it if you go ahead and install them now, reporting any issues that you may find.

Given that this is a big update that includes quite a number of plugins and libraries, it's strongly recommended that you restart your KDE session after updating the packages.

Happy hacking,

The Debian Qt/KDE Team.

Note [lun jul 18 08:58:53 ART 2016: Link fixed and s/KDE/KDEPIM/.]{style="background-color: white;"}

Upcoming KDEPIM changes in unstable (KMail, Kontact, KOrganizer, etc)

2016-07-02T21:38:00-03:00

For those who care about kdepim (kmail, kontact, korganizer, etc)

Currently the latest version of kdepim is available in experimental. According to our limited tests it's working way better than kdepim 4.14 (more stable, more performant, less bugs). However migrating from one to the other is not a trivial process (distribution wise, hopefully not for our users).

Among the drawbacks in the new kdepim: knode, ktimetracker and kjots were dropped from the official kdepim components. kjots is now an independent project, not tied to the kdepim release cycle. But more importantly, knode and ktimetracker are not maintained upstream any more, we are temporarily still shipping the old KDE 4 versions, but we will drop them after stretch unless they get new upstream maintainers.

To iron out the wrinkles that are surely still there, we are now planning to start a transition for kdepim, effectively blocking all kdepim related packages in unstable until the transition is complete. This will allow us to keep the current kdepim in testing unchanged until kdepim 16.04 is ready to migrate fully to testing.

If you want to test the new kdepim versions right now, please use the version in experimental, as uploading all the packages to unstable will take some time until there is a working kdepim in unstable (mixing experimental and the unstable uploads should be fine).

If you depend on having a working kdepim, please avoid installing the new kdepim packages that will be landing in unstable in the following days, until all the components are available. We expect this will take a couple of weeks, we will post another entry when the packages are ready in unstable.

A list of the binary packages involved in the transition can be found [here].

If you find issues in the new packages, please let us know either via irc in #debian-kde, the kde mailing list debian-kde@lists.debian.org, or send us a bug report (please make sure that it wasn't reported before).

We'll send an updated note when kdepim is fully uploaded to unstable.

Happy hacking,

The Debian Qt/KDE Team.

Do you want Qt5's QWebEngine in Debian? Do you have library packaging skills? If so, step up!

2016-05-26T11:51:00-03:00

So far the only missing submodule in Debian's Qt5 stack is QtWebEngine. None of us the current Qt maintainers have the time/will to do the necessary stuff to have it properly packaged.

So if you would like to have QtWebEngine in Debian and:

You have C++ libraries' packaging skills.
You have a powerful enough machine/enough patience to do the necessary builds (8+ GB RAM+swap required).
You are willing to deal with 3rd party embedded software.
You are willing to keep up with security fixes.
You are accessible through IRC and have the necessary communications skills to work together with the rest of the team.

Then you are the right person for this task. Do not hesitate in pinging me on \#debian-kde, irc.oftc.net.

Important Akonadi fix in today's Debian Jessie's update (aka 8.2)

2015-09-05T20:42:00-03:00

Todays Debian Jessie's update brings a fix in Akonadi that you certainly want in your system.

There was a bug in Akonadi that made it leak files. And if you use Kmail you will certainly want to keep reading: most of us who tested it before pushing it to testing (and now to stable) removed more than 4 GiB of useless data from our homes.

The bug that makes Akonadi leak files gets solved with the latest stable update (and has been in testing for a couple of months already). But you need to purge the leaked files. It's pretty easy: with your normal user account just run:

akonadictl fsck

That's all. After a while you will get back a lot of disk space. Note that you don't need the Akonadi fix in order to run this tool and recover your space. The fix just makes sure this won't happen again.

plasma-desktop should enter testing today once the mirrors have caught up

2015-07-31T11:31:00-03:00

Exactly what the subject says: plasma-desktop has migrated to testing, it will be there as soon as the mirrors are synced. It is highly recommended for those in testing to upgrade today, although you might need to wait your mirror. Also note that the gcc5 transition has started, that means we are not going to upload new stuff in some days (possibly a week, maybe even more) to facilitate this **\*\*huge\*\*** transition. We really hope you enjoy the packages. If you filed a bug and after updating you findd that it is not there anymore then please follow-up the bug and state this. This is really **\*\*highly\*\*** appreciated. Once again, sorry for the inconveniences!

Plasma/KF5 : Testing situation

2015-07-28T12:19:00-03:00

Dear Debian/KDE users,

We are aware that the current situation in testing is very unfortunate, with two main issues:

systemsettings transitioned to testing before the corresponding KDE Control Modules. The result is that systemsettings displays an empty screen. This is tracked in the following bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790703.
plasmoids such as plasma-nm transitioned to testing before plasma-desktop 5. The result is that the plasmoid are no longer displayed in the system tray.

We are working on getting plasma-desktop to transition to testing as soon as possible (hopefully in 2 days time), which will resolve both those issues. We appreciate that the transition to KF5 is much rougher than we would have liked, and apologize to all those impacted.

On behalf of the Qt/KDE team,
Lisandro.

The last planned Qt 4 release is here: Qt 4.8.7. Is your app runnning with Qt5?

2015-05-26T13:36:00-03:00

Qt 4.8.7 has been released today. Quoting from the blog post (emphasis is mine):

Many users have already moved their active projects to Qt 5 and we encourage also others to do so. With a high degree of source compatibility, we have ensured that switching to Qt 5 is smooth and straightforward. It should be noted that Qt 4.8.7 provides only the basic functionality to run Qt based applications on Mac OS X 10.10, full support is in Qt 5.

Qt 4.8.7 is planned to be the last patch release of the Qt 4 series. Standard support is available until December 2015, after which extended support will be available. We recommend all active projects to migrate to Qt 5, as new operating systems and compilers with Qt 4.8 will not be supported. If you have challenges migrating to Qt 5, please contact us or some of our service partners for assistance

Have you started to port your project?

Qt4's status and Qt4's webkit removal in Stretch

2015-05-01T14:05:00-03:00

Hi everyone! As you might know Qt4 has been deprecated (in the sense "you better start to port your code") since Qt5's first release in December 19th 2012. Since that point on Qt4 received only bugfixes. Upstream is about to release the last point release, 4.8.7. This means that only severe bugs like security ones will get a chance to get solved.

Moreover upstream recommended keeping Qt4 until 2017. If we get a Debian release every ±2 years that will make Jessie oldstable in 2017 and deprecated in 2018. This means we should really consider starting to port code using Qt4 to Qt5 during Stretch's developing life cycle.

It is important to note that Qt4 depends on a number of dependencies that their maintainers might want to get removed from the archive for similar reasons. In this case we will simply don't hesitate in removing their support as long as Qt4 keeps building. This normally doesn't mean API/ABI breakage but missing plugins that will diminish functionality from your apps, maybe even key ones. As an example let's take the **hypothetical** case in which the libasound2 maintainers are switching to a new libasound3 which is not API-compatible and removing libasound2 in the process. In this case we will have no choice but to remove the dependency and drop the functionality it provides. This is another of the important reasons why you should be switching to Qt5.

[Qt4's webkit removal]{.underline}

Webkit is definitely not an easy piece of code to maintain. For starters it means having a full copy of the code in the archive for both Qt4 and Qt5. Now add to that the fact that the code evolves quickly and thus having upstream support even for security bugs will be getting harder and harder. So we decided to remove Qt4's webkit from the archive. Of course we still have a lot of KDE stuff using Qt4's webkit, so it won't disappear "soon", but it will at some point.

[Porting]{.underline}

Some of us where involved in various Qt4 to Qt5 migrations [0] and we know for sure that porting stuff from Qt4 to Qt5 is much much easier and less painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4. In order to ease the transition time we have provided Wheezy backports for Qt5.

Don't forget to take a look at the C++ API changes page [1] whenever you start porting your application.

[0] http://pkg-kde.alioth.debian.org/packagingqtstuff.html
[1] http://doc.qt.io/qt-5/sourcebreaks.html

[Temporarily shipping both Qt4 and Qt5 builds of your library]{.underline}

In case you maintain a library chances are that upstream already provides a way to build it using Qt5. Please note there is no point in shipping an application built with both flavours, please use Qt5 whenever possible. This double compilation should be left only for libraries.

You can't mix Qt4 and Qt5 in the same binary, but you may provide libraries compiled against one or the other. For example, your source package foo could provide both libqt4foo1 and libqt5foo1. You need to mangle your debian/rules and/or build system accordingly to achieve this.

A good example both for upstream code allowing both styles of compilation and debian packaging is phonon. Take a look at the CMakeLists.txt files for seeing how a source can be built against both flavours and another to debian/rules to see an example of how to handle the compilation. Just bear in mind that you
need to replace \$(overridden_command) with the command itself, that variable substitution comes from internal stuff from our team and you should not be using it without a very good reason. If in doubt, feel free to ask us on IRC [2] or on the mailing list [3].

[2] irc.debian.org #debian-kde
[3] debian-kde\@lists.debian.org

[Timeline]{.underline}

We plan to start filing wishlist bugs soon. Once we get most of KDE stuff running with Qt5's webkit we will start raising the severities.

Early announce: Qt4 removal in Jessie+1

2014-11-05T22:56:00-03:00

We the Debian Qt/KDE Team want to early-announce [maintainer warning] our decision to remove Qt4 from Jessie+1. This warning is mostly targeted at upstreams.

Qt4 has been deprecated since Qt5's first release on December 19th 2012, that means almost two years ago!

So far we had bugfixes-only releases, but upstream has announced that they will end this support on august 2015. This already means we will have to do a special effort from that point on for Jessie in case RC bugs appears, so having it in Jessie+1 is simply a non-go.

Some of us where involved in various Qt4 to Qt5 migrations [0] and we know for sure that porting stuff from Qt4 to Qt5 is much much easier and less painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4. In order to easy the transition time we have provided Wheezy backports for Qt5.

Don't forget to take a look at the C++ API change page [1] whenever you start porting your application.

[0] http://perezmeyer.blogspot.com.ar/2014/03/porting-qt-4-apps-to-qt-5-example-with.html
[1] http://qt-project.org/doc/qt-5.0/qtdoc/sourcebreaks.html

[maintainer warning] **Remember the freeze** and do not upload packages ported to Qt5 to unstable. The best thing you can do now is to ask your upstream if the code can be compiled against Qt5 and, why not, try it yourself.

Our first priority now is to release Jessie, and this is why this is an early announce.

Qt 5.3.2 in Wheezy-backports: just a few hours away

2014-10-09T15:50:00-03:00

In more ~~or less 24 hs~~ a few days most of Qt 5.3.2 will be available as a Wheezy backport. That means that if you are using Debian stable you don't need to wait for Jessie: just wait a few hours, add wheezy-backports's repo to your sources.list and get it :)

The rest of Qt 5 will arrive soon.

This is the same version that will be shipped in Jessie, so whatever you develop with it will work with the next Debian stable release :)

[Don't forget:]{.underline} you better start porting your Qt4 apps to Qt5!

Note 2014-10-10: uups, it will still take a few days, but it will be there soon :)

Note 2014-10-15: currently building!

Qt5 in Jessie: we will release with 5.3.2

2014-09-30T14:08:00-03:00

Qt 5.3.2 has entered testing a few hours ago. This will be the version of Qt we will release with Debian Jessie, and it happens to be a nice coincidence, because upstream focused in stability for the 5.3 branch.

I'll now focus in fixing as many bugs as possible and in backporting Qt5 to Wheezy.

Let me warn you: if you are an upstream for a Qt4 based project be sure to be ready to switch to Qt5. If you are a maintainer of a Qt4 based project you better start asking your upstream to be ready for it :)

Call for help from Debian's KDE Team

2014-05-01T15:58:00-03:00

Hi all!

[
]{.Apple-style-span style="background-color: #ffffe8; border-collapse: separate; border-spacing: 1px; color: #141312; font-family: 'Liberation Mono'; font-size: 16px;"}

For quite a while now the KDE team has been severely understaffed. We maintain a lot of packages, with many different kinds of bugs, but we don't have enough people to do all the work that needs to be done. We have tools that help us automate the update to new upstream releases, but that's just the tip of the iceberg of our work and so we are writing to invite more people to get involved in the team and help us get KDE software in Debian into better shape.

[
]{.Apple-style-span style="background-color: #ffffe8; border-collapse: separate; border-spacing: 1px; color: #141312; font-family: 'Liberation Mono'; font-size: 16px;"}

Some of the tasks that we need help with are:

Bug triaging: there are many many bugs in the BTS. We need people that go through them, understand the problem and how to reproduce it, confirm that they are still present in the latest versions. In particular, there are bugs affecting the version in wheezy, and we need people to go through those as well.
Bug forwarding: we are so understaffed that we have been asking users to forward the bugs upstream themselves. Some users do this, but some don't. It would help us a lot to have people in the team in charge of this.
Patch forwarding: we have quite a bunch of patches applied in the Debian packages that should be applied upstream. Some need to be generalized instead of being Debian-specific. This work would save us time in the future, so it's very important to get it done.
Upgrade-testing: in the past, the upgrade from one Debian stable to the other has been quite traumatic for KDE software users. We need people to try upgrading from wheezy to jessie and report any bugs that they might encounter so that we can fix them ahead of the release.
Creating patches: many of the bugs that we have require writing patches, some are easy and some are harder, but any help here would be really appreciated.
Packaging other KDE apps: we have packages for the core components of KDE software, but there are many other useful components that still need to get packaged.
Updating our welcoming wiki page [1], adding these tasks and any future tasks, and unifying the todo lists [2].

If you are interested in helping with any of these, please join our irc channel #debian-qt-kde in irc.oftc.net, or our mailing list [3]. We are happy to help you get started.

[
]{.Apple-style-span style="background-color: #ffffe8; border-collapse: separate; border-spacing: 1px; color: #141312; font-family: 'Liberation Mono'; font-size: 16px;"}

[1]: https://wiki.debian.org/PkgKde

[2]: https://wiki.debian.org/KDETodo

https://wiki.debian.org/KdeDebTasks

http://pkg-kde.alioth.debian.org/todo.html

gobby://gobby.debian.org/Teams/KDE/TODO

[3]: https://lists.debian.org/debian-qt-kde/

[]{.Apple-style-span style="background-color: #ffffe8; border-collapse: separate; border-spacing: 1px; color: #141312; font-family: 'Liberation Mono'; font-size: 16px;"}

[-- ]{.Apple-style-span style="background-color: #ffffe8; border-collapse: separate; border-spacing: 1px; color: #141312; font-family: 'Liberation Mono'; font-size: 16px;"}

[]{.Apple-style-span style="background-color: #ffffe8; border-collapse: separate; border-spacing: 1px; color: #141312; font-family: 'Liberation Mono'; font-size: 16px;"}

Regards,

Maximiliano Curia

On behalf of the KDE team

`{=html}

Porting Qt 4 apps to Qt 5: an example with QAntenna

2014-03-08T23:27:00-03:00

As a followup for my previous blog post, I decided to port QAntenna to Qt 5. Here's my experience.

First of all, I ran Qt 5's qmake:

qmake -qt5

Then I just ran make:

make

The first error that appeared was that QFileDialog does not has a setFilters() method. I couldn't find this on on the C++ API change page but looking at the class' documentation I found it was renamed to setSectionsMovable(). Fine, let's just change that and continue compiling.

The next errors came all from the same class QHeaderView. This time the changes are documented in the above linked page, so it was a matter to replace setMovable() with setSectionsMovable() and setResizeMode() with setSectionResizeMode(). Fixed, let's continue.

The following error turned out to be the last one: toAscii() has been deprecated in favor of toLatin1(). Once this was fixed voilá, QAntenna is running with Qt 5.

Easy, wasn't it?

I have just pushed the new version to Debian unstable.

Does your app use Qt4? You better start porting it to Qt5

2014-03-08T16:52:00-03:00

As you might know, Qt 4 is now in bug-fixes-only maintenance mode. This means that only bug fixes are allowed to be pushed to Qt 4's repository, but no new features.

On the other hand, Qt 5 is already here. Porting existing apps from Qt 4 to Qt 5 is actually easier than it was to port Qt 3 stuff to Qt 4. Take a look at this Qt project's wiki page for more info. Also pay attention at the links at the bottom of it under "Recommended Reading".

Some time ago I blogged about the 5.2.0 status in Debian experimental. We currently have it in testing with a much better status:

And we also have 5.2.1 in experimental with an even better status:

Note: qttools is FTBFS in armhf just because of some symbols changes, it will be fixed on the next upload.

Don't be afraid of getting it from experimental! Take a look at this blog post to know how to compile with Qt 5 in Debian.

Bonus

I have also uploaded Qt Creator built against Qt 5 to experimental. I plan to push it to unstable with Qt 5.2.1.

Qt 5.2.0 in testing

2014-02-11T15:32:00-03:00

Today we have Qt 5.2.0 in testing, a.k.a. Jessie. On the other hand we are slowly pushing 5.2.1 to experimental.

Enjoy!

P.S.: yes, this is turning more into tweets rather than blog posts :-)

Qt 5.2.0 in unstable

2014-02-04T20:55:00-03:00

We the Qt/KDE team have the pleasure to announce that we currently have Qt 5.2.0 in unstable. It brings Qt 5 to all official archs in Debian, minus some stuff that needs porting like Qt Webkit.

We hope to get this version in testing soon :-)

Qt 5.2.0 in Debian experimental, now available for more archs

2014-01-05T11:47:00-03:00

Qt 5.2.0 is already available in experimental until we get a transition slot, but don't be afraid to test it. With this release we had major improvements. With 5.1.1 currently in sid we have the following buildd chart:

Qt 5.1.1 in Debian Sid

Now with 5.2.0 in Debian experimental we have:

Qt 5.2.0 in Debian experimental

As you can see Qt has compiled in more archs, thanks to the effort of the Debian's porters and from the Qt/KDE team.

Note that Qt JS Backend has dissapeared: it's functionality (the javascript engine) is now in Qt Declarative itself. It has been ported away from Google's v8 to a Qt-based engine, allowing it to build in more archs among other features.

You can also note that we still have quite some FTBFS, mostly coming from Qt Webkit. Feel free to send patches ;-)

Qt in Debian: using Qt4 and/or Qt5 in your packages

2013-08-11T15:42:00-03:00

Hi everyone! We now have both Qt4 and Qt5 in the archive. Those using Qt4 should not need to make any changes in their packages, although you can be extra-safe with a few steps. Don't rush, just read below.

Note 2014-12-12: the current official doc is available here.

Some background

Sune took the time some months ago to consult upstream for a sane way to allow both SDKs to coexist without us distros having to reinvent the wheel choosing which tools have to be in use in each case.

After a long discussion, upstream decided to write qtchooser (already in the archive) to be able to select between Qt4, Qt5 and even special user's cases like cross-platform builds.

So instead of going trough Debian's alternatives as we did with Qt3/Qt4, we will make use of this new tool.

My package uses Qt, how should I proceed?

There are many ways of choosing either of the versions of Qt:

Using any qtchooser method (preferred):

* Exporting QT_SELECT with 4, qt4, 5 or qt5 as a value in debian/rules.
* Call the tool using the '-qtx' parameter, where x can be replaced with any of the options above.

~~- Build-depending on qt4-default or qt5-default. You can't B-D on both of them, as they can't coexist.~~ Don't build depend nor depend on qt4-default and/or qt5-default.

It is good to notice that:

any qtchooser method will take precedence over build depending on qtX-default.
~~- If you export XDG_CONFIG_DIRS it will ignore the default paths to qtchooser's configs we setted up in the packages~~.

We have also provided qt4-[arch-triplet] and qt5-[arch-triplet] options for special cases.

Once again, if you are already using Qt4, there is no need to rush. See below.

Can is use both Qt4 and Qt5 in my package?

So are you going to break the archive with a big transition?

No, we have done our best to avoid having to make any changes to existing Qt4 packages. Qt tools should default to Qt4 except if overriden by any method described above.

My package uses Qt4, can I leave it as it is?

While there is no need to apply the changes in this case, explicitly setting the Qt version will surely not hurt at all. ~~But don't rush ;-)~~ See note 2014-11-06

Note 2014-05-07: exporting XDG_CONFIG_DIRS is now safe.
Note 2014-07-26: We decided it's not good to build depend or even depend on qt4-default or qt5-default.
Note 2014-11-06: Qt4 will get removed in Jessie+1.
Note 2016-02-08: fixed doc URL.

My experiences with KMail2 in Debian

2013-07-14T12:21:00-03:00

Thanks to the Qt/KDE team, specially to Maxy who has done most of the packaging and uploading, sid users are now enjoying KDE 4.10.5, including the new KDE PIM stuff that we have held out for the Wheezy release.

I started using KMail2 (inside Kontact) a few days after Wheezy's release, getting it from experimental. And I have to admit that I really like it, just like with KMail1.

But my upgrade did have some bumps on the road, so I'm sharing them here so you can now how I solved them.

Mail import worked as we were waiting: it did work. So it was really useful to hold back Kmail1 until this really worked.

Now, I had a problem with my hard disk: whenever KMail started, it would start accessing it without pause. There where two reasons (for what I could test, I haven't looked at the source to really see if there was some other oddity) for this: I had a nepomuk/virtuoso DB created quite some time ago and initial mail indexing.

The initial mail indexing takes lots of time. For 1GB of DIMAP I had to wait like 5 hours (yes, 5 hours) on a 5600 rpm disk to let it fully finish. My desktop machine, with a faster hard drive, took a little less.

As far as people told me, that should have been enough, but my disk kept crawling. So I remembered someone from the team saying something about people with early-created nepomuk/virtuoso databases will have some speed issues. Mine where more than that, buy trying was worth the shot.

I had nepomuk disabled since I tried it the first version due to this exact problem. So I closed my KDE session and removed the nepomuk/virtuoso data:

rm -r \~/.kde/share/apps/nepomuk/

Then I logged back in KDE and waited (again) the 5 hours to let nepomuk re index my mail, this time totally finishing after 5 hours. Starting from that point, I get some one or two minutes of disk trashing some times I log in (not always), but it's actually not that bad. And I heard that in KDE 4.11 this has been improved a lot, so I should see a better behavior from that point on.

Please understand that this was my trial-and-error fix, it may be possible that someone comes with a better solution :-)

Presenting qtchooser

2013-05-29T17:30:00-03:00

A few days ago we the Qt/KDE team uploaded a new tool in the Qt ecosystem: qtchooser.

This tool is a wrapper tool used to select between different Qt versions. Of course, the first and easiest example is choosing between Qt4 and Qt5. But it doesn't end there: it can also be used to select a user's build of Qt.

To experienced Debian users, at first sight, it might resemble Debian's alternatives system. But it goes much further than that, allowing users (not sysadmins) to decide their defaults, and even adding new ones, user-wide. All this can be done using different methods like command line arguments, environment variables and configuration files.

Apart from all that, this is the recommended upstream way of managing Qt, being picked up by several (if not all) distributions, so it can easily be supported by upstream in their documentation.

My Qt4 package in Debian does not uses qtchooser, do I need to change anything?

No, we have tried to make things as smooth as possible. Your Qt4 packages should be safe. There will be more info on this later.

Debian/Ubuntu packages caching and mobile workstations

2013-05-22T14:31:00-03:00

Not so long ago I read Dmitrijs' blog post on how to configure apt-cacher-ng to advertise it's service using avahi. As I normally use my laptop in my home and at work, and both networks have apt-cacher-ng running, I decided to give it a try.

I have been administering apt-cacher-ng for three networks so far, and I really find it a useful tool. Then, thanks to the aforementioned blog post, I discovered squid-deb-proxy. I don't use squid, so it's not for my normal use case, but some people will surely find it interesting.

But I found it's client package to be really interesting. It will discover any service providing _apt_proxy._tcp through avahi and let apt use it. But then the package wasn't available in Debian. So, I contacted Michael Vogt to see if he was interested in putting at least the client in Debian's archive. He took the opportunity to upload the full squid-deb-proxy, so thanks a lot Michael :-)

I then filled a wishlist bug against apt-cacher-ng to provide the avahi configuration for publishing the service, which Eduard included in the last version of it. So thanks a lot Eduard too!

tl;dr

You know only need apt-cacher-ng >= 0.7.13-1 and avahi-daemon installed on your server and your mobile users just need squid-deb-proxy-client. Then the proxy autoconfiguration for apt will just work.

One again, thanks a lot to the respective maintainers for allowing this into Jessie :-)

Gotchas

Yes, there are still some rough edges. On one of the networks I'm behind a proxy. While configuring my machine to use apt-cacher-ng's service as a proxy trough apt.conf, apt-listbugs would just work. But now, using the service as discovered by squid-deb-proxy-client, apt-listbugs just times out. Maybe I need to fill some other bug yet...

Qt 4.8.4 in experimental.

2013-05-15T12:22:00-03:00

Since a few days we have Qt 4.8.4 (4:4.8.4+dfsg-3) in some archs of the experimental Debian archive. This release allows Qt4 to coexist with Qt5 while avoiding FTBFSs of current Qt4 packages in the archive.

So if you maintain a Qt4 app and want to check how it works with 4.8.4, you should be ready to go.

On the road to Qt5: declarative, graphicaleffects and svg in experimental.

2013-04-29T20:20:00-03:00

Some more Qt 5 packages have entered Debian experimental:

Enjoy :-)

On the road to Qt 5: Qt 5 base, tools, jsbackend and xmlpatterns in experimental

2013-04-21T10:32:00-03:00

The first Qt 5 packages have been accepted in Debian experimental.

What's there

qtbase-opensource-src: lib[concurrent core dbus gui network opengl printsupport sql test widgets xml], examples, development packages and debug symbols.
qttools-opensource-src: lib[qtlucene designer help], qdbus, development headers and debugging symbols.
qtjsbackend-opensource-src: libqt5v8-5
qtxmlpatterns-opensource-src
qtchooser, which allows to select between Qt4 or Qt5 at build time.

To start building Qt 5 apps you will need to export QT\_SELECT=qt5, install the package qt5-defaults or read qtchooser's man page. Note that exporting QT\_SELECT has precedence over installing qt5-defaults.

What's not there

#### Architectures AMD64 is already there because it's the arch used by maintainers to build the packages. i386 should be following as soon as [buildds](http://www.debian.org/devel/buildd/) catch up. Most surely ARM-based archs will be there at some point too. Other archs will need some love. Not strange, the Qt project supports amd64, i386 and ARM, but we Debian have normally prepared patches to make it build in other archs. And yes, we try to push them upstream for everyone's benefit. So, if you are missing it in your arch, take a look. You may be the one who enables Qt 5 in it :-) #### GLES2 and Wayland We don't have GLES2 or Wayland support yet. Building it will most probably break the desktop for people using proprietary video drivers (or at least I was told so). I'll surely provide **non-official** packages with GLES2/Wayland enabled to allow people testing it, but not soon.

This also means that we are not currently able to split X11 and framebuffer support. But we have time to work on it :-) #### Non DFSGs compliant files

If you get the original source code tarball from Debian you will notice that it has dfsg in it's name. That means that we had to remove some non [DFSG](http://www.debian.org/social_contract) compliant stuff from the original tarball, namely:

- Every [RFC](http://wiki.debian.org/NonFreeIETFDocuments). - Three files used for testing the build, which are made of RFCs. - Some fonts.

What's following ----------------

Other parts of Qt 5 are on the way. And remember, this packages would not have been possible if it weren't for the great Debian's [pkg-kde](http://pkg-kde.alioth.debian.org/) team. My kudos to them.

On the road to Qt 5: Qt 4.8.4 and qtchooser uploaded to experimental

2013-04-01T18:41:00-03:00

I have just uploaded Qt 4.8.4 to experimental. Apart from being the newest upstream release of the 4 series, it adds the basic support for coexisting with Qt 5. Because of this support it will need to go trough the NEW queue though, so we will need to be patient.

Developers will be interested in qtchooser, the tool that allows to switch between Qt 4 and 5 development apps. It has also been uploaded to experimental.

Of course, all this has been possible thanks to the efforts of the wonderful Qt/KDE team =)

Update: our efficacious FTP masters have already made Qt pass the NEW queue. Thanks a lot!

Entrevista en La Nueva Provincia

2013-03-25T09:42:00-03:00

Hace unos dias Guillermo Burastero me llamó para comentarme que le habían pedido una nota en el diario local de Bahía Blanca, La Nueva Provincia, para que habláramos de software libre. La entrevista se concretó y he aquí el resultado (y acá en PDF).

Hice algunas menciones a Debian, pero bueno, no todo es posible a veces :-)

Tip: los nombres no coinciden con las fotografías. Les dejo adivinar el orden correcto ;-)

Día de la libertad del hardware

2013-03-18T12:13:00-03:00

El sábado 20 de Abril se va a llevar a cabo el Hardware Freedom Day en todo el mundo, y Argentina no es excepción. Este año tenemos la suerte que se realice en dos lugares: La Plata (que cuenta con Alejo como uno de los coordinadores) y Buenos Aires.

A mi me van a quedar un poco lejos, pero invito al que pueda a acercarse al evento.

No se lo pierdan :-)

My Debian freeze experience (so far)

2013-03-04T23:30:00-03:00

This is the first freeze in which I'm involved with upload rights. And it turned out to be a quite interesting ride so far, so I thought it would be nice to write about it.

As some of you may know, I'm a part of the [Qt/KDE team](http://pkg-kde.alioth.debian.org/). Before the freeze I was mostly involved in leaf packages, with some patch here or there, nothing fancy. And then the freeze came...

**Bugs in Qt** --------------

...and bugs appeared in [Qt](http://qt-project.org/). But they didn't get solved, even if the patches were there. Due to personal reasons, the manpower in Qt/KDE land decreased below normal levels (which were already low).

I took the time to review them, apply them in a local branch, build and test the fixes. I did a Qt upload before, but it was a team-consented one. This time there was not much reaction in our IRC channel as it used to be, so I was doubting if going ahead or not. I asked [Ana](http://ekaia.org/), my great friend and former sponsor, for an opinion on the subject, and she gave me a really important advice: the patches were looking good and there is one really big true: if something get's broken, it can be fixed with a later upload.

You might be asking yourself why I was that afraid of doing the upload. Well, when one maintains such a medular package for many users one has to be careful And I also got used that those "big ones" like Qt where normally handled by hand skilled people. Do not take me wrong here, it's not that those people where keeping them for themselves, it's knowing that one does not has the same skills nor experience as them.

But again, no one was able to upload and I had the chance and will to do another upload if needed, so off it went. That was Qt 4:4.8.2-2.

Then new experiences followed: asking a buildd maintainer for a giveback, asking the Release Team for an unblock (more on this later), etc. While sponsoring me, Ana gave me another excellent advice which I always keep in my mind:

You can't know **everything** about Debian.

And that also includes a not so technical skill: communicating with other teams. But finally we got this new version of Qt in testing. Cool :-)

Of course, new bugs appeared, and my lack of skills (and sometimes, time) where replaced by team work: [Pino](http://www.behindkde.org/pino-toscano) looking at patches and [Sune](http://pusling.com/blog/) contacting upstream. The eleven uploads that followed are a nice example of team work, even if I was the one who signed and did the uploads. Whoever uses Qt must know that these wonderful people (including those who are not so active nowadays like [Modestas](http://www.linkedin.com/pub/modestas-vainius/2/ba5/3a) or [Fathi](http://www.linaro.org/linux-on-arm/meet-the-team/fathi-boudra)) have done lots to bring the better to their users.Thank you guys!

**Be careful, they might bite you back!** -----------------------------------------

Coming back to the non-technical skills, sometimes you have to communicate with other teams in Debian. And each team is (naturally) a separate world: possibly different people, different goals, etc. Of course, we share the goal to make Debian the best experience we can, but we do not necessarily agree on the paths to achieve so.

During the freeze, there is a team that gets lots of pressure, and not by chance: the [Release Team](http://wiki.debian.org/Teams/ReleaseTeam). They handle a very important task, which is to ride the freeze to get to a release. OK, that's what everyone knows. Now, one thing is knowing that and another is really understanding what does that means.

Of course I was in the first group. From the outside, communicating with the RT was a kind of "special art", and not an easy one. I have even been advised to not ask for more than one or two unblocks per weekend, as they might "bite me back". So I put on my flamesuit on and... launched reportbug release.debian.org.

Now I'm really **happy** to say that my experience was far from what I described above. And yes, I had the chance to even disagree on some stuff. But remember: non-technical skills, a.k.a. social skills. Once I started to know what was going on inside the RT (joining \#debian-release was a big help for that) I learnt some nice tips to approach them. Please allow me to list some of them:

- Remember: you are the maintainer of the package, they are like gatekeepers that are there to help us coordinate to do a release. But they don't maintain the code, you do that. So try to be verbose when needed, explain the changes and don't forget a nice diff. They need to understand what is going on: they can't read your mind. - They are human beings too: not everyday might be their best day (the same goes for you too!). And they are under the pressure of a release. Be patient, that finally pays off. - Does your changes seem not so clear? try to improve them. - The package has a lot of changes but you really feel they are needed? Try to explain that as good as you can. - Try to put yourself in **their** position: do we really want this? If in doubt, there is a nice way to know what they think: a pre-approval bug.

I want to make a stop in this last point. A pre-approval bug it's an unblock bug in which you edit the subject to add "pre-approval" in it. Easy, isn't it? It gives you the opportunity to know what the RT thinks before doing the upload. In other words: it gives you the chance to communicate and do things in the best possible way for all the parts involved.

I've have also seen pre-approval bugs that were really not needed. But to learn where the threshold of what can be directly uploaded and what deserves a pre-approval bug is you need to know the guidelines the RT gives you. Do you still have doubts? fire a pre-approval bug and try to be clear.

Of course, this are all fruits of my experience with the RT during this time. If the RT thinks different from what I'm writing here, please stand up: we are hear to listen to you and learn :-)

As a side note, I think I should file a wishlist bug to include the pre-approval bug option in reportbug. Yes, I'm lazy :-)

**Summing up** --------------

Overall this was a very nice and positive experience. We are not done yet. Are we really done at some point? Let's hope not, because this is where the fun comes from :-)

Aprendiendo sobre LDAP

2012-11-23T16:40:00-03:00

En mi trabajo ha surgido la necesidad de crear una infraestructura de LDAP+kerberos, que voy a montar sobre (adivinaron) Debian. Si bien en la web hay varios artículos al respecto, ésto es lo que les recomiendo dentro de lo que vengo leyendo:

Un Red Book de IBM muy bueno al respecto, ideal para arrancar si se desconoce totalmente el tema. Si van a usar OpenLDAP, con leer los tres primeros capítulos alcanza.
Un libro en la web de Zytrax, mas informal pero con muchos ejemplos, excelente para leer a continuación del anterior.
Una guía de como instalar un servidor LDAP en Debian.

Un problema general que me he encontrado en convertir los ejemplos de configuraciones de slpad.conf al formato manejado dentro del mismo árbol de LDAP. Pero si hubiese leído las cosas en el orden que puse arriba, me hubiese sido mas fácil de entrada :-)

Un amigo me recomendó mirar la [wiki de DebianLan](http://wiki.debian.org/DebianLAN/) para lograr un setup mucho más rápido. Todavía no he llegado a ésa parte.

¿Tu sesión de KDE está leeeeenta? Chequeá tu interface de loopback

2012-11-01T21:23:00-03:00

Mientras reviso los bugs del equipo Qt-KDE de Debian, no es raro encontrar gente que reporta que se sesión de KDE está muy lenta. La gran mayoría de las veces el problema es que la interfaz de loopback (aka lo) no está habilitada. A veces el usuario hizo algo mal, a veces algún manejador de redes metió la pata, pero el resultado final es el mismo: KDE está lento.

Un usuario llenó un bug en KDE upstream pidiendo por un diálogo que avise al usuario en caso de que ésto ocurra. esperemos que sea implementado :-)

Bueno, pero... ¿como chequeo de que la interfaz esté activa?

Simplemente corriendo:

\$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:1f:c6:ba:70:f3
...
[
]{style="font-family: Courier New, Courier, monospace;"}lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1807 errors:0 dropped:0 overruns:0 frame:0
TX packets:1807 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:494525 (482.9 KiB) TX bytes:494525 (482.9 KiB)

La última entrada "lo" nos dice que la interface está activa.

En Debian, el archivo /etc/network/interfaces debería contener algo como:

# The loopback network interface
auto lo
iface lo inet loopback

La próxima vez que tu sesión de KDE esté lenta, ya sabés por donde empezara mirar ;-)

Is your KDE slooooow? Check your loopback interface

2012-11-01T21:06:00-03:00

While digging Debian Qt-KDE's bugs, it has become more common to find people reporting that their KDE is very slow. Most of the time (if not every time) it turns out that the loopback interface is down. Sometimes the user did something wrong, sometimes some network manager, but the end result is the same: KDE is terribly slow.

A user [filled a bug upstream](https://bugs.kde.org/show_bug.cgi?id=309047) to ask for a dialogue in KDE that warns the user about this fact. Let's hope it get's implemented :-)

OK, so, how do I check that my lo interface is up?

You can simply run:

\$ /sbin/ifconfig

eth0 Link encap:Ethernet HWaddr 00:1f:c6:ba:70:f3

[](http://www.blogger.com/blogger.g?blogID=6357172297737057475)

[ ]{style="font-family: Courier New, Courier, monospace;"}

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

inet6 addr: ::1/128 Scope:Host

UP LOOPBACK RUNNING MTU:16436 Metric:1

RX packets:1807 errors:0 dropped:0 overruns:0 frame:0

TX packets:1807 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:494525 (482.9 KiB) TX bytes:494525 (482.9 KiB)

The last entry "lo" tells us that the interface is up.

In Debian, the file /etc/network/interfaces should have something like:

\# The loopback network interface

auto lo

iface lo inet loopback

So, next time you find a KDE session is slow, you know what to do ;-)

QExtSerialPort in Debian experimental

2012-08-16T17:14:00-03:00

After some rants about the status of different Qt-based serial port libs, I'm happy to announce that today QExtSerialPort was accepted in Debian experimental (this last link may give a 404 for some time, that's ok).

A great effort was done upstream to put the source in a suitable state for being included in Debian. Thank you all guys!

I packaged a beta version, so I uploaded it to experimental.

In case you are wondering why packaging a lib with (yet) no apps depending on it, the answer is quite simple: there are lots of people already using it in it's home projects (me included). Now those projects have the chance to get into Debian too :-)

As a side note, there is also another nice implementation called QtSerialPort. I have also tested it and works pretty fine too. It aims to become part of Qt as an add-on someday.

¡Feliz cumpleaños Debian! 19 y vamos por mas :-)

2012-08-16T11:56:00-03:00

¡Feliz cumpleaños Debian! Por supuesto, vamos por mas :-)

Poniendo la rama del repositorio de git en el prompt

2012-07-13T19:00:00-03:00

A partir de la charla Git and Debian packaging me saltó la duda de como lograr un prompt que me diga la rama actual de git cuando me encuentre en un repositorio.

Christian "bubulle" Perrier nos ofreció éste link. La idea me gustó mucho, pero tuve que twikearlo un poco para que use colores :-)

El resultado, en mi \~/.bashrc

[...]
# Search for git repos.
parse_git_branch() {
git branch 2> /dev/null | sed -e '/\^[\^*]/d' -e 's/* $.*$/(\1)/'
}
[
]{style="font-family: 'Courier New', Courier, monospace;"}
# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
force_color_prompt=yes
[
]{style="font-family: 'Courier New', Courier, monospace;"}
if [ -n "\$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
[ ]{.Apple-tab-span style="white-space: pre;"}# We have color support; assume it's compliant with Ecma-48
[ ]{.Apple-tab-span style="white-space: pre;"}# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
[ ]{.Apple-tab-span style="white-space: pre;"}# a case would tend to support setf rather than setaf.)
[ ]{.Apple-tab-span style="white-space: pre;"}color_prompt=yes
else
[ ]{.Apple-tab-span style="white-space: pre;"}color_prompt=
fi
fi
[
]{style="font-family: 'Courier New', Courier, monospace;"}
if [ "\$color_prompt" = yes ]; then
]{style="font-family: 'Courier New', Courier, monospace;"}[[PS1='\${debian_chroot:+(\$debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\[\033[01;31m\]\$(parse_git_branch)\[\033[00m\] \\$ ]{style="font-family: 'Courier New', Courier, monospace;"}]{style="background-color: white;"}['
else
PS1='\${debian_chroot:+(\$debian_chroot)}\u@\h:\w\$(parse_git_branch)\\$ '
fi
unset color_prompt force_color_prompt
[...]

Como verán, agregué la función parse_git_branch() tal y como se describe en el link. Luego agregué la llamada en la definición del color prompt.

Por supuesto, se puede mejorar aún mas :)

Nota 201207172003GMT-3: bubulle parece haber hecho lo mismo, sólo que él lo mejoró. Y por supuesto, cambié el post de forma acorde :)

Charla sobre el puerto USB y experiencias de programar un driver para un circuito integrado

2012-07-06T21:05:00-03:00

El miércoles 11 de Julio (el próximo miércoles al momento de escribir ésto) en la sala de conferencias del DIEC, Universidad Nacional del Sur, Bahía Blanca, voy a estar dando dos charlas en una: "El puerto USB: mas que un puerto serie con energía" y "Experiencias de programar un driver para un circuito integrado".

En la primera charla voy a presentar las ideas básicas detrás del puerto USB en forma de sistema y con énfasis en los dispositivos. Voy a hablar sobre los pro y los contras del mismo.

En la segunda parte, que debería durar no mas de 10', voy a hablar de mi experiencia haciendo un driver para el Texas CC1101.

En ambos casos no voy a tocar muchos aspectos de software, sino que voy a conentrarme mas en presentar ideas y contar tips y experiencias con los mismos.

¡Los espero!

Un tackle por Candela

2012-06-28T12:05:00-03:00

Y ustedes se dirán ¿Lisandro haciendo una cadena en su blog? Algo así. Pero ésta vez lo hago con toda la alegría de intentar ayudar a alguien que sé que existe, y no sólo porque la "he visto", sino porque la he tenido en brazos y jugado con ella.

El anuncio de la Sociedad Sportiva de Rugby:

El próximo sábado 30/6/2012 va a haber un encuentro de rugby en Carrindanga, Bahía Blanca. Los motivos:

M12 y M14 juegan el encuentro de infantiles de la URS (junto a 13 clubes de bahía y la zona).
Las juveniles participan de una fecha del norpatagónico con Neuquén
La inter juega un amistoso con universitario
y como si fuera poco la primera de Sociedad Sportiva Rugby se mide con Universitario en la ultima fecha del campeonato

Sin embargo, y porque el rugby es mucho más que el juego, te vamos a presentar a Candela, una amiga de 4 años... mas abajo sus padres Seba y Pata nos cuentan su historia... leela, sentila y acompañanos con tu ayuda durante el encuentro... las seños del jardín de cande traerán café y tortas, el bere sorteará una camiseta y una pelota y algunas amigas del blanco recorrerán las canchas con urnas... sumate... entre todos es posible...

Y si no vas a Carrindanga (por que tu hijo juega en otro club... o porque no podés...) sumate igual.. te damos los datos de la cuenta bancaria; seguramente vas a saber que hacer.

BANCO NACIÓN ARGENTINA
CAJA DE AHORRO EN PESOS
Nº: 1308689672
CBU: 0110130630013086896729

Escriben Seba y Pata, los papis de Candela:

[Candela una noche calurosa de Enero llegó a nuestras vidas muchísimo antes de lo esperado. Hay algunas causas y explicaciones científicas por las que ocurre un nacimiento prematuro pero ninguna de esas fue la nuestra, Pata no tuvo infección, no tuvo un accidente, no tenía presión alta ni ninguna de las explicaciones que aun hoy reconoce la medicina. Asi que tan sólo así se dió, y como dijimos llegó para quedarse.]{style="color: blue;"}
[
]{style="background-color: white; color: blue;"}
En los tres meses de terapia neonatal, por su inmadurez extrema tuvo muchas complicaciones: ]{style="background-color: white; color: blue;"}[infecciones, cirugías, le colocamos una válvula en la cabecita y quedo con varias secuelas.
[
]{style="color: blue;"}
Entre ellas, hipoacusia severa bilateral por la que usa audífonos, la lesión cerebral hoy se denomina ENCEFALOPATIA CRÓNICA NO EVOLUTIVA, por la que usa un andador ortopédico y valvas en sus piernas, ademas al día de hoy se desconoce cuanto daño hizo en su sistema nervioso.
[
]{style="color: blue;"}
Una de las 3 noches que de madrugada nos llamaron para que vayamos a estar a su lado porque estaba muy complicada y era dificil que pase la noche, estando muy pocos minutos al lado de su cunita especial, le susurramos que apoyaríamos lo que ella decida. Si por fin quería dejar de luchar y descansar (se veía día a día literalmente que peleaba por su vida) o si quería seguir.Pero le prometimos que si se quedaba con nosotros, íbamos a hacer todo cuanto este a nuestro alcance para ayudarla a ser feliz.
[
]{style="color: blue;"}
Lo que nosotros estuvimos haciendo durante estos 4 años y pico es tan solo eso.
[
]{style="color: blue;"}
Ella hace 6 estimulaciones semanales, mas la estimulación en casa.
[
]{style="color: blue;"}
Los médicos siempre dijeron que ha evolucionado mucho para los pronósticos que tuvo, y que debemos aprovechar el período de mayor plasticidad neuronal (hasta los 5,6 años) para mejorar sus capacidades, pero ningun esfuerzo garantiza un resultado, es hacer, hacer, hacer y esperar.
[
]{style="color: blue;"}
Muchísimas noches nos preguntamos:
[
]{style="color: blue;"}
¿podrá caminar algún día?
¿podrá hacer las cosas que hace un niño de su edad, correr, saltar?
¿podrá ir a 1º grado, a 2º, que pasará?
¿podrá hablar y que otros la entiendan?
[
]{style="color: blue;"}
Dedicamos mucho tiempo también para hablar con otras familias de casos similares, indagar en medicinas alternativas, leemos, investigamos, cursamos a distancia y seguimos en la búsqueda.
[
]{style="color: blue;"}
Nosotros estamos AL PIE, no desde la resignación sino con la CERTEZA de que esto es PLAN DE DIOS.
[
]{style="color: blue;"}
Candela hace unos días se paró.
[
]{style="color: blue;"}
Ella y nosotros estamos listos para ir por mas, para redoblar los esfuerzos.
[
]{style="color: blue;"}
A partir de ahora daremos un paso mas grande, hemos decidido hacer dos grandes apuestas.
[
]{style="color: blue;"}
Llevaremos a Candela al "Instituto de Rehabilitación y Educación Terapéutica" FLENI de ESCOBAR, el lugar es uno de los mas reconocidos de Latinoamérica para el tratamiento de pacientes con problemas neuronales y motores.
[
]{style="color: blue;"}
El otro paso es llevarla al CIREN (Centro Internacional de Restauración Neurológica) en Cuba.
[
]{style="color: blue;"}
Los dos tratamientos son costosos para afrontarlos solos.
[
]{style="color: blue;"}
Debemos contar aproximadamente con unos 165 mil pesos argentinos, el calculo no es exacto porque tanto en Fleni como en Ciren, una vez que la evalúen pueden sugerir otros estudios complementarios o cirugías. Además en Cuba es en dólares (que hoy parece mala palabra)
[
]{style="color: blue;"}
Si llegaste hasta acá y te estás preguntando: Estos padres ME ESTÁN PIDIENDO PLATA?
[
]{style="color: blue;"}
Intentaremos darte una respuesta
[
]{style="color: blue;"}
No tenés idea de cuantas veces nos preguntamos si estaba bien que te llegue un mail así
[
]{style="color: blue;"}
Lo charlamos con muchas personas y cada uno nos iba ayudando a tomar la decisión.
[
]{style="color: blue;"}
Recibir este mail no te compromete en nada, no te obliga a nada, solo te informa, solo te pide y tenes la libertad absoluta de ni siquiera responderlo.
[
]{style="color: blue;"}
Pero si tan sólo una fibra tuya quiere hacer algo, si la causa te parece justa y honesta y tenes la plata para ayudar, la respuesta a tu pregunta es SI.
[
]{style="color: blue;"}
Si no dispones de ella pero tenes una idea, un amigo, un conocido, para sumar es bienvenido.
GRACIAS por la paciencia de leer un mail tan largo, si te sirve, nosotros lo leímos 84 veces antes de enviarlo.
[
]{style="background-color: white; color: blue;"}
Pata y Seba

Nota: no estoy afiliado de ninguna manera a ningún club de rugby, pero (insisto), tengo el gusto y honor de conocerla a Cande :)

Docsis 0.9.6+git16 disponible en Debian unstable (bueno, en unas horas)

2012-04-17T16:10:00-03:00

Docsis 0.9.6+git16 acaba de ser aceptado en Debian unstable. Pero ¿que es Docsis? Es un programa homónimo a la especificación usada por los modems de redes HFC (Hybrid Fibre Coaxial), o "los modems del cable de TV", como mas o menos los conocemos acá en Argentina. Sirve para generar configuración binaria para los mismos.

Como siempre, espero que les sea de provecho :-)

KDE 4.7.4 en Debian testing

2012-03-22T19:55:00-03:00

Desde hace unos pocos dias KDE 4.7.4 se encuentra disponible en testing. La actualización es mas que recomendada. Como siempre, muchas gracias al equipo Qt-KDE en Debian.

Por otro lado hace poco se pidió que se remueva kaboom de Wheezy. Kaboom fué la primera herramienta desarrollada colaborativamente entre los miembros del citado equipo. Su misión: migrar las configuraciones de KDE 3 (o las configuraciones experimentales de KDE 4 que proporcionaba el equipo) a KDE 4. Con Squeezy se completó la migración, y por ende la herramienta ya queda obsoleta en Wheezy.

QtSerialPort: a new hope

2012-03-13T21:47:00-03:00

Some time ago I wrote about the status of Qt-based libs for using the serial port. Some days later I was pointed to the QtSerialPort project. The good news on this is that this is a project aimed to enter into Qt 5.

I have tested the lib with some apps that originally used QExtSerialPort. So far, so good. The license terms seems pretty OK (it wouldn't have got that far in the Qt code review if it weren't).

In the meantime, I received a reply to one of my messages from an upstream dev of QSerialPort (note that is Q and not Qt). He was very kind, but considering the effort to get QtSerialPort inside Qt itself, I think it's better to try to develop with this last lib.

Maybe I should try to package it and upload it to experimental.

Entretenimiento en vuelo: volando con Emirates

2012-03-07T18:35:00-03:00

Algún tiempo atrás ví un video sobre el uso de Qt en plataformas de inflight entertainment (entretenimiento en vuelo) de Panasonic:

`{=html}

Pensé que iba a pasar bastante hasta que viera un sistema así en vivo y en directo... arriba de un avión (lo digo porque lamentablemente no he estado pudiendo viajar mucho que digamos). La sorpresa me la dí al viajar en un vuelo de Emirates. ¡Y aún viajando en clase económica!

El sistema se llama ICE: Information, Communication and Entertainment. La verdad, desconozco si es el mismo sistema que produce Panasonic con Qt (puede que si), pero si me pareció muy bueno.

Algunas cosas que me llamaron la atención:

El sistema está disponible en clase económica.
Por el cursor, diría que corre bajo Linux (además, si fuese un sistema operativo propietario, es muy probable que le haya visto un logo en algún lado).
La pantalla es táctil, aunque parece resistiva por como reacciona. Creo que, en ese caso, los botones que se dibujan en pantalla deberían ser un poco mas grandes.
El "control remoto/joystick/horquilla de teléfono" es muy piola. Se nota que fué construído con la premisa de robustez antes que comfort al usarlo, pero es mas que entendible por la función que cumple.
Si bien es particular a Emirates, la selección de música me pareció excelente :-) No estuve viendo las películas en mi sistema, pero si en la de otros. Había estrenos y todo. ¡Y gratis! (bueno, uno paga el pasaje ;-) ).
Mi pantalla estaba pidiendo que la recalibren un poco, la parte superior era complicada para acceder con el sistema táctil.
El "mini joystick" para mover el cursor (similar al botoncito de las notebooks para el mismo fin) resultó muy práctico.
El sistema generaba mucho calor. Bastaba con girarlo un poco y poner la mano atrás para sentirlo.
Las vistas de las cámaras inferior y delantera del avión son geniales. Y si, están encendidas todo el tiempo, por lo que podemos ver como despegamos.

En fin, golazo para Emirates, me dejaron con una muy buena impresión mas allá del servicio, que realmente fué muy bueno también.

Por las dudas: no, no trabajo en Emirates ni Panasonic ni Qt, ni estoy relacionado con ninguno de ellos.

Y digo yo, si el sistema fuese Software Libre ¿que podría mejorar?

The license mess with serial port Qt-based libs

2012-02-03T19:14:00-03:00

I am currently working on a Qt-based app that needs to communicate through the serial port. Apart from all the benefits that a normal lib with a serial port implementation will bring in this case, having a Qt-based serial port lib would make even more sense, as it should be as multiplatform as possible and use the signal/slot mechanism. Also it should have a DFSG-compatible license, so I can package it for Debian, of course :-)

So I have found two libs which seemed to have the above mentioned features: QExtSerialPort and QSerialPort.

QExtSerialPort seems to be the most recommended lib in the web. It features polled and signal-based functionality; it uses Qt's standard types inheriting QIODevice. But it does not states the license in any file within the source code. The original project page at SourceForge says it's in public domain. And the newer project page at Google code says it's under the new BSD license. I have asked in the mailing list for a clarification. So far nothing has changed (although in further threads the authors showed some willing to change this). And then I got to the point of finding a bug, but I don't want to spend time to track it down and make a patch without a clear license.

QSerialPort it's another lib with more or less the same features as QExtSerialPort. It's main LICENSE file says it's under the LGPL2, but licensecheck will say that the present files are LGPL3. Also, on reviewing the code, I found some minor stuff that could be improved. Well, I could contact the author and see if [s]he would receive the patches... but his site seems down. And I could not find a real-person's name in the code so far :-/

So I made a last attempt to try to get QExtSerialPort in a suitable license. If it doesn't suceed, I think I'll have to start writing one myself. The downside: I only use Linux, so there will be no multiplatform features unless someone else contributes it. Of course, if you have another option or any idea to share, I'll be happy to know it :-)

By the way, this should be my first post on Planet Debian in english, so hello planet!

¿Que pasa si instalo todos los discos de Debian?

2012-01-18T23:32:00-03:00

Hay algunos que quizás abran las ojos "como dos de oro" por ésta pregunta, pero no es la primera vez que la leo ni que me la hacen, así que vá la respuesta:

Si instalás todos los DVDs/CDs de Debian, vas a tener mucho espacio en disco rígido ocupado. Muy posiblemente, de gusto.

Tener todos los discos a mano sirve si no tenés una buena conexión a internet. Con eso sabés que la gran mayoría de las cosas las tenés disponibles en cualquier momento. Pero no instales todo, solo lo que vos necesites, aunque solo sea del primer medio. Dejá que apt se haga cargo del resto :-)

Si tenés un contraejemplo... sabés lo que estás haciendo y no necesitás que te lo explique =)

Seguimos moviendo partículas, ésta vez con OpenCL

2011-11-21T16:23:00-03:00

Y ahora le toca el turno al segundo trabajo práctico de HPC\@UNS. Ésta vez vamos a seguir moviendo partículas, pero con mayor grado de paralelización, ya que vamos a usar OpenCL sobre una placa nVidia GeForce 8800 GTS 512 (rev a2) y Debian.

Cada punto del gráfico es el promedio de 5 corridas del mismo algoritmo con los mismos parámetros.

Por si solo no nos dice mas que el algoritmo tiene una dependencia O(n²) con el número de partículas. Ésto es natural ya que se trata del mismo código serial que en el práctico anterior, ésta vez convertido a OpenCL.

Nota: el código original está bajo la licencia BSD modificada (¡Gracias Vasily Volkov!). El código modificado mantiene la licencia.

Como en el caso del práctico anterior, se pueden tomar otras estrategias para reducir el orden de complejidad del código... pero no es lo que nos intereza ahora. La idea es comparar estos resultados con los ya obtenidos. Pero antes...

Nota importante: el código de OpenCL utiliza floats en vez de doubles para los cálculos. Ésto es debido a que la placa gráfica no soporta éste último tipo. Ésto llevó a la necesidad de aumentar la masa de la partícula, ya que el valor original producía errores numéricos que producían que las partículas se aceleraran.

Lo primero que podemos observar es que el tiempo de cálculo requerido para un número de partículas menor a \~[64 128] (según la implementación y el host) es menor para el caso serial que para el caso con OpenCL. Ésto era de esperarse, ya que se consume un tiempo importante en pasar datos hacia y desde la placa de video al host. Es decir, vale la pena implementar éstas soluciones si el número de datos a procesar es grande.

Es interesante notar como OpenMP sobre Luna (AMD Athlon (tm) 64 X2 Dual core processor 5000+) presenta mejor tiempo de cálculo que OpenCL para menos de 1024 partículas. A su vez, la implementación de OpenMP en cardumen (UltraSparc T2 (Niagara2)) es mas lenta. A medida que el volumen de datos aumenta, OpenCL comienza a ser mas eficiente.

Las comparaciones para PThreads son bastante similares a las anteriores. Tarea para el lector :-)

Notas y conclusiones

OpenCL tiene muy buen desempeño para volumenes de datos grandes, aunque vale la salvedad de que se utilizaron floats en vez de doubles. Quizás si algún dia pongo mis manos en una placa con soporte para doubles pruebe a ver que pasa.
OpenCL es un estándar, pero sólo provee los headers (API). Las implementaciones dependen de cada fabricantes, y no son software libre, al menos por ahora. Ésto atenta contra la portabilidad del código.
QtOpenCL está genial :-)

Moviendo partículas y binarizando imágenes

2011-10-18T17:25:00-03:00

Como parte de la entrega del trabajo práctico Nº 1 de la materia HPC\@UNS era requerido hacer una página web con los resultados. Me pareció mas práctico usar mi blog... y acá estamos.

Partículas en movimiento

La primera parte del TP era ir a un sitio de Berkeley y bajar el código para simular la interacción entre partículas usando un algoritmo totalmente serial, otro utilizando PThreads y otro OpenMP. Lo primero que hice fué hacer unas corridas y ver los resultados que obtenía.

Nota: cada punto del gráfico es el promedio de 5 corridas del mismo algoritmo con los mismos parámetros. -Esto es válido para todos los gráficos de éste blog post, pero en los datos usados para generar los primeros solo se encuentran los valores ya promediadios.

Respuesta en tiempo al número de partículas de cada implementación en un servidor Sparc T2 (Niágara2) de 8 cores con 8 hilos livianos cad uno.

Respuesta en tiempo al número de partículas de cada implementación en una máquina AMD Athlon 64 X2 Dual Core processor 5000+.

Notemos que el número de threads de OpenMP no está definido, sino que se toma el de la instalación por defecto (Debian Wheezy en ambas máquinas).

Enseguida podemos notar varias cosas:

Los algoritmos son O(n²). Nada raro si uno mira el código fuente, los ciclos for anidados saltan a la vista.
Paralelizar el algoritmo vale la pena a partir de una cierta cantidad de datos. Se podría pensar en ~256 como un buen número de threshold, aunque seguramente es dependiente del hardware y del problema/implementación del algoritmo.
Crear hilos tiene un costo mínimo asociado. En el caso del Sparc, el costo es mayor, aunque es notable como mejora el rendimiento con OpenMP.

Intentemos mejorar éste desempeño

Mirando el código fuente vemos que la interacción entre partículas se calcula todas entre todas. Lo interesante es que el resultado de la interacción de una partícula p con una partícula q es la misma pero de signo contrario a la interacción de la partícula q con la partícula p. Entonces podemos hacer los cálculos una sola vez entre dos partículas cualquiera.

Por otro lado, la interacción entre partículas es basada en la distancia entre ellas. Si la distancia es cero, no hay interacción. Entonces una partícula no interactúa con si misma.

Desde el punto de vista del hardware y el paralelismo, podemos utilizar la máxima cantidad e hilos posibles para cada caso. Definitivamente ésto va a traer acarreado mayor tiempo de ejecución en los casos de pocas partículas, pero debería ser mejor a medida que el número de partículas aumenta.

~~Nota: debido a que el código fuente original no estipula una licencia y por ende se debe interpretar como "todos los derechos reservados", no hago públicas las modificaciones del código.~~
Actualización 18/11/2011: le escribí a Vasily Volkov, responsable del sitio y código de Berkeley arriba linkeado, y tuvo la gentileza de reponderme diciéndome que la licencia en BSD modificada. En el repositorio del código incluyo el mail (en formato mbox) y la licencia propiamente dicha. ¡Gracias Vasily!

Veamos entonces los resultados, empezando por el caso serial.

Comparación del algoritmo original (1.0.1) con el algoritmo modificado 1.1.6 para el caso serial.

En éste caso vemos que tanto para Cardumen (Sparc) como para Luna (AMD Athlon) los cambios generaron una reducción del tiempo de ejecución. A su vez, podemos comparar el desempeño de ambos procesadores.

Comparación del algoritmo original (1.0.1) con el algoritmo modificado 1.1.6 para el caso con OpenMP.

En el caso de OpenMP resalta claramente como influye utilizar una excesiva cantidad de hilos en Cardumen para muy pocos datos. Notar que lso tiempos tienden a ser levemente menores para mas de \~4000 partículas.

Comparación del algoritmo original (1.0.1) con el algoritmo modificado 1.1.6 para el caso con PThreads.

Aquí también se puede observar el costo que tiene utilizar muchos threads con pocos datos. En éste caso se hace notoria la mejora de rendimiento entre las dos versiones de PThreads en Cardumen.

No puede faltar un gráfico con todos los resultados:

Todos los resultados juntos.

¿Podemos mejorar aún mas el algoritmo?

Si, y (teóricamente) mucho. El "truco" está en reducir la complejidad del algoritmo lo mas posible. Para eso hay que detectar el cuello de botella, que no es otro que el cálculo de las fuerzas entre cada partícula. Dijimos que la interacción entre las mismas es una relación de la distancia. Pero lo que no nombramos es que, luego de una cierta distancia r, ya no interactúan entre ellas. Debemos entonces encontrar una forma de que cada partícula solo calcule la fuerza que podrían llegar a ofrecerles posibles partículas aledañas.

Una posible solución sería dividir el espacio bidimensional en una matriz donde cada casillero sea de tamaño rxr. Cada vez que se mueve una partícula se la ubica en el casillero correspondiente a su zona final. Luego basta considerar sólo las fuerzas que aplican las partículas en el mismo casillero y en los casilleros aledaños. Si bien suena sencillo, se hace necesario sincronizar el acceso a cada partícula entre los hilos y sus propiedades.

Yo no llegué a implementarlo, pero MorningCoffee si lo ha hecho. Lamentablemente tampoco lo llegué a probar :-(

Haciendo trabajar a Cardumen

Ahora la idea no es analizar el algoritmo sino como responde el servidor con ése algoritmo ante distintas cargas y números de threads.

En el caso de OpenMP podemos ver como se va incrementando el costo fijo de generar una cantidad determinada de threads. Podemos ver que, para muy pocas partículas (hasta \~20), tener un solo hilo de OpenMP (que debería ser el mismo caso que el algoritmo totalmente serial) tiene un overhead.

También se puede observar que dada una cierta cantidad de partículas realmente vale la pena usar paralelización.

El mismo análisis se puede hacer para PThreads.

Y, por supuesto, podemos ver todos los resultados juntos. Las referencias corresponden a la simulación serial, luego las de OpenMP terminando con las de PThreads.

Veamos ahora el speedup de cada caso:

Puede verse que la performance de PThreads es similar.

Resulta posible observar que en ambos casos el speedup se aproxima al teórico para cada número de threads.

¿Y que pasaría si tuviésemos una cantidad fija de threads para utilizar?

¿Tenés los resultados a mano?

Si, pueden obtenerlos acá.

Binarizando imágenes

La idea de la segunda parte del TP es binarizar dos juegos de 100 imágenes de 360 y 1080 pixeles cada uno. Primero resolver el problema de forma serial y luego paralelizarlo. Visto gráficamente, la idea es pasar de una imagen como:

A una imagen con solo dos tonos:

Para lograr ésto usé Qt. no lo hice la manera mas eficiente, ya que utilicé QImage::pixel() y QImage::setPixel(). Podría haber utilizado los métodos de QImage para acceder a los pixeles como vecotres de datos. Pero bueno, para el propósito de éste TP, alcanza. Aproveché el envión que llevo de aprender CMake y lo usé para compilar. Se los recomiendo. El código fuente lo pueden encontrar acá.

La estrategia

Tan sencilla como hacer que cada hilo se ocupe de procesar una imagen. No hay interdependencia entre ellas, por lo que no es necesario sincronizar los threads. Dicho de otra manera, no hay necesidad de procesar las imágenes en ningún orden en particular.

Los gráficos obtenidos

Podemos ver el tiempo de ejecución vs. el número de threads:

Es interesante ver la meseta que se forma entre los \~8 y \~20 threads.

En éste caso, la meseta no aparece.

Y también podemos medir el speedup. En amarillo, el speedup teórico ideal.

Realmente me sorpendió lo bajo del speedup :-/

Como nota al margen, Cardumen empezó a dar "Bus error" al momento de correr los algoritmos (entre ejecución y ejecución). Es posible que haya un problema de hardware en el mismo.

¿Y los resultados?

También están disponibles acá.

Algunas conclusiones

OpenMP hace la vida de un programador mucho mas sencilla que PThreads por poca o nada de diferencia en tiempo de ejecución.
Esperaba que el Sparc tuviese un mejor rendimiento. Mi sospecha es que no se trata de un servidor diseñado para procesar datos de punto flotante (posee una sola FPU por core, es decir, una FPU por cada 8 hilos).
Estaría bueno poder decirle a OpenMP/Sistema Operativo que ponga un hilo por core. hasta donde sé, pueden crearse 8 hilos pero no hay ninguna garantía de que cada uno corra en un core. Ésto serviría para reducir el tiempo en cálculos con mucho uso de FPU.

Desarrollador de Debian

2011-09-25T11:18:00-03:00

Ésta madrugada recibí el mail que confirma la creación de mi cuenta en los servidores de Debian. En otras palabras ¡soy DD! Tengo una alegría enorme :)

Por supuesto, no llegué hasta acá sin el invalorable esfuerzo de otras personas. Mi seguramente incompleta lista de agradecimientos va a (en orden cronológico) Marga Manterola y la muchachada entera del LugFI, Ana Guerrero, el equipo Qt-KDE, Hauke Rahm que fué mi AM, Telma, mi novia, que me conoció y aceptó como debianita con todo lo que eso implica y a un montón de gente mas que me acompaña desde hace años.

A todos ustedes muchas gracias. Espero poder seguir siendo útil en la tarea de lograr el mejor Sistema Operativo Universal.

A veces a uno le falta teoría...

2011-08-04T21:59:00-03:00

Antes que nada, no tengo formación teórica-pura de Programación Orientada a Objetos (POO). Lo que sé lo aprendí de libros varios que apuntan a enseñar programación orientada a objetos para un cierto lenguaje. Y tampoco tengo un conocimiento de compiladores+assembler lo suficiente bueno como para no estar preguntandome ésto. El lado bueno: al menos se me ocurre pensarlo :-)

Veamos éste caso:

class PublicFoo {
public:
  int mFoo;
}

Si, justo lo que no debiese hacerse en POO. Pero suponiendo que ya instancié un objeto con ésta clase y éste tuviese un valor, podría accederlo como:

PublicFoo data = new PublicFoo();
// De alguna manera se carga un dato...
int valor = data.mFoo;

Desde el punto de vista de acceso, debería ser inmediato. Si ahora usamos:

class PrivateFoo {
public:
  int foo() { return mFoo; };
  void setFoo(int foo) { mFoo = foo; };
private:
  int mFoo
}

Para obtener el valor de foo haríamos:

PrivateFoo data = new PrivateFoo();
// De alguna manera se carga un dato...
int valor = data.foo();

Lo que puede llegar a implicar que el compilador genere código para entrar en el método foo(), haciendo mas lento el acceso al valor.

Ahora, en éste otro caso:

class PrivateInlineFoo {
public:
  inline int foo() { return mFoo; };
private:
  int mFoo
}

Un acceso quizás sea tan rápido como en el primero, ya que se me ocurre que el compilador tenga el hint del inline para mejorar el acceso.

Seguramente me estoy perdiendo *mucho* a causa de mi ignorancia. Pero les cuento a que vino todo ésto: se me ocurrió pensar que pasaría si existiese una propiedad de visivilidad que permita que cualquiera acceda al valor de la propiedad de la clase para lectura, pero sólo la clase pueda modificar dicho valor. ¿sería mas "sencillo" programar?

En fin, nada mas mostrándole al mundo mis dudas e ignorancia :-)

Una mandarina en Debian

2011-07-03T14:53:00-03:00

Hace unos 16 dias (tarde me vengo a avivar.. ¿será porque lo compilé de fuentes?) Clementine, el reproductor de música multiplataforma insipirado en Amarok 1.4, está disponible en Debian.

El trabajo necesario para empaquetarlo fué mucho, y por eso agradezco a Thomas Pierson por eso :-)

Sugiero que no dejen de probarlo. Sabe mejor con una mandarina en mano ;-)

La imagen fué tomada de la Wikipedia.

Carta abierta al presidente de CoNEAU

2011-07-01T11:07:00-03:00

Bahía Blanca/Internet, 1º de Julio de 2011

Sr. Presidente de CoNEAU:

Tengo el gusto de dirigirme a Ud. para hacerle llegar mis inquietudes con respecto al software necesario para realizar las acreditaciones en las universidades nacionales de nuestro país.

Permitame primero comentarle acerca de mi situación actual: yo fuí empleado de la Universidad Nacional del Sur hasta el 31 de Diciembre de 2011. Hace unos pocos dias unos ex compañeros de trabajo me pidieron si no podía colaborar llenando la "ficha docente". Mas allá de que no estoy obligado a hacerla debido a que no soy mas un agente de dicha universidad, soy Argentino y creo que colaborar es una de las actividades que nos engrandece como pueblo y nación.

Para tal actividad se requiere del uso de un software (lo cuál encuentro totalmente entendible). Lamentablemente dicho software sólo corre bajo el sistema operativo Windows de Microsoft. Como presidente de la comisión encargada de evaluar pares seguramente estará al tanto de que no todo el sistema académico ni privado (como es mi posición actual) usa esa plataforma. Mi caso particular es ése: yo soy usuario de GNU/Linux [0], software libre[1], legal y gratuito. Comprar una licencia de Windows, además de costoso, va contra mi libertad de saber que es lo que mi máquina está haciendo. Y usted sabe que una buena formación académica lleva a que uno pueda saber como funcionan las cosas, mucho mas aún en mi caso particular de Ingeniero Electrónico y el software que corro.

[0] \<http://es.wikipedia.org/wiki/GNU/Linux>

[1] \<http://es.wikipedia.org/wiki/Software_libre>

Resultado: me veo imposibilitado de ayudar a mi universidad a cumplir con vuestros requisitos.

Por supuesto, puedo entender que el desarrollo de un software tiene un costo. Pero permítame decirle que el costo de desarrollar un software multiplataforma es, hoy por hoy, el mismo que desarrollar un software atado a una sola plataforma. De hecho, si se tiene en cuenta los beneficios de realizarlo como multiplataforma, la inversión resulta ser mas redituable en términos de uso.

Aún mas, los costos de obtener una plataforma de desarrollo para dicho software se reduce a una conexión a Internet: existen bibliotecas de alto nivel y calidad sin costo alguno, como por ejemplo el caso de Qt [2], por nombrar solo una.

[2] \<http://es.wikipedia.org/wiki/Qt_(biblioteca)>

Finalmente, permitame ir un paso mas allá y proponerle que la implementación de dicho programa sea también software libre. Si mal no tengo entendido, la CoNEAU se trata de una evaluación de pares. Como tal, las herramientas utilizadas a tal efecto no son lo importante, sino la información que ellas manejan. La posibilidad de que los distintos pares sean capaces de evaluar y mejorar la herramienta, sin perjuicio de los datos que ella maneje, contribuye a la mejora de la misma y a la credibilidad en el sistema.

Atte.,

Lisandro Damián Nicanor Pérez Meyer

DNI 29508104

¡No al canon digital en Argentina!

2011-06-29T10:44:00-03:00

Porqué parece que siempre tenemos solo dos opciones (o de como las matemáticas pueden ayudar a explicarnos la situación política actual)

2011-06-27T22:42:00-03:00

Varias veces he pensado que la historia política siempre termina en votar por el partido A o por el partido B, sin siquiera poder considerar a C, porque si lo voto, obtiene pocos votos y evito que A (que realmente NO me gusta) gane. Entonces mejor voto a B.

Y acá es donde quizás alguno de ustedes quiera decirme "¡tenés que votarlo igual!". Bueno, mi idea con éste post es mostrar que hay razones matemáticas que muestran porqué estamos (al menos en parte) como estamos.

Antes de seguir, una aclaración: no estoy inventando nada. Ya lo inventó otro ;-) El contenido de lo que les quiero mostrar sale de un blog post de los tantos que ofrece CGPGrey. Pero sólo la parte audivisual, la parte teórica la pueden ver en la Wikipedia.

Otro detalle: los videos están en inglés, pero para el que le cueste, va un link a el texto de los mismos.

El primero muestra como funciona nuestro sistema de votación actual.

`{=html}

El texto lo pueden leer acá.

El segundo video muestra un método alternativo. Tiene muchas deficiencias (al igual que el anterior), pero una gran ventaja. Y no deja de ser sencillo de computar.

`{=html}

El texto lo pueden leer acá.

Por supuesto, si fuese por mí, usaría el método que se usa en Debian: el método de votación Condorcet con el método de disminución secuencial Schwartz.

KDE SC 4.6.3 en inestable

2011-05-27T21:10:00-03:00

El equipo Debian Qt/KDE hizo disponible hoy la versión 4.6.3 de KDE SC. El salto desde testing sería entonces desde KDE SC 4.4.5.

Muchas gracias a los mantenedores por su esfuerzo :-)

Qt 3 en busca de gente interesada en adoptarlo

2011-05-01T21:36:00-03:00

Con KDE 3 casi ya no presente en inestable, el equipo Qt/KDE no está interesado en continuar manteniendo Qt3. Por ende, estamos buscando a gente interesada en adoptarlo.

Si te interesa que Qt 3 esté presente en Wheezy, éste es el momento de involucrarse. Por favor, leé este mail y respondé en la lista.

Y no, no es coincidencia que éste post se parezca a éste otro :-)

¿Entradas de NFS en fstab que no se montan? Hay que mirar los logs

2011-04-03T22:49:00-03:00

Ésta es una entrada "ayuda memoria" por si me vuelve a ocurrir, pero quizás le pueda servir a otro también.

Resulta ser que un cliente NFS que corre Debian, de un día para el otro, dejó de montar automáticamente sus entradas correspondientes en /etc/fstab, pero sin embargo si se montaban si se llamaba manualmente a mount -a.
Luego de mucho buscar, dí con un par de entradas en /var/log/user.log que me dieron la llave del problema:

[if-up.d/mountnfs[eth0]: lock /var/run/network/mountnfs exist, not mounting]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"}

Un directorio "lock", /var/run/network/mountnfs, estaba presente al momento de iniciar el sistema, evitando que las unidades se monten automáticamente. Y como no se montaban, no había necesidad de borrar ningún lock, ya que el mismo no debiera haber sido creado...

Bastó con borrar el susodicho directorio para que todo vuelva a la normalidad.

Viviendo el release de Debian 6.0 "Squeeze" (o sencillamente "Squeeze" para los amigos)

2011-02-05T19:45:00-03:00

[[Por voz]{.Apple-style-span style="font-size: large;"}]{.underline}

Desde ayer viernes 04/02 estoy conectado al servidor de mumble que Joey Hess preparó para la ocasión, la "Debian Party line". La idea: establecer un canal de voz para compartir entre gente de todo el mundo éste momento tan importante para el proyecto.

Fué la oportunidad para poder empezar a linkear nombres con voces. Hasta tuve el gusto de escuchar a nuestro ya famoso Jacob Goerzen :-)

[[Por dents]{.Apple-style-span style="font-size: large;"}]{.underline}

Mi cuenta de identi.ca hace rato ya sigue al usuario debian, que fué proveyendo de información sobre el progreso de la publicación, además de distinta información adicional para el evento.

[[Por IRC]{.underline}]{.Apple-style-span style="font-size: large;"}

Por supuesto, no todo termina ahí. Me conecté a #debian-release y #debian-cd en irc.oftc.net para seguir mas de cerca el proceso... tan de cerca que terminé probando imágenes previas de los CDs de instalación.

Tip: fíjense de qu etengan suficiente espacio para instalar, en especial después de particionar. Si no, van a terminar reinstalando un par de veces hasta encontrar el error... créanme, me pasó hace muuuy poco ;-)

El evento es una excelente oportunidad de ver la cantidad de esfuerzo de la gente que componen (¡componemos!) Debian. Ahora me queda poder ir a la DebConf 11 :-)

Y no nos olvidemos de algo muy importante

[¡¡¡Gracias a todos por el enorme esfuerzo que es crear y mantener Debian!!!]{.Apple-style-span style="font-size: x-large;"}

Instalando Debian Squeeze con particiones encriptadas

2011-01-23T13:53:00-03:00

En mi post anterior, un usuario me pidió que hiciese un tutorial sobre como instalar Debian Squeeze con una o varias particiones encriptadas. Y bueno, he aquí cumplo con el pedido.

Nota: todos los pasos que sigo aquí son cosas que he aprendido en forma ad-hoc, puede que haya cosas que necesiten correcciones. Por supuesto, se agradece que las dejen en los comentarios =)

Voy a cubrir algunos pasos esenciales y luego saltar directamente hacia la parte del particionado de discos. También vale aclarar que voy a usar el instalador en modo texto sencillamente porque lo encuentro mas cómodo, pero su análogo gráfico es igual de sencillo.

El primer paso es bootear el instalador de Debian Squeeze:

Para hacer las cosas mas interesantes, voy a elegir la opción "expert install".

Y como éste post es en español... usemos español para la instalación.

A partir de ahí, hago un gran salto hasta elegir que componentes del instalador deben descargarse. Y debo ser sincero: éste paso estimo que debe hacerse ya que vamos a particionar manualmente, pero la verdad no sé si es necesario. El componente a cargar es cfdisk-udeb.

Seguimos adelante hasta llegar al particionado de discos.

La primera opción que se nos ofrece es hacer un particionado guiado utilizando todo el disco. Noten que también está la posibilidad de hacer un LVM cifrado en forma guiada.

Pero nosotros vamos a hacer las cosas de forma manual :-)

Para éste ejemplo, utilicé una máquina virtual con VirtualBox. Como la máquina tiene el disco vacío, es necesario hacer algunos pasos previos. Si el disco sobre el que van a instalar Debian Squeeze ya tenía algún sistema operativo, éstos pasos seguramente no les va a tocar hacerlos. La idea aquí es elegir en qué disco (y no en que partición) vamos a instalar nuestro SO.

Como les decía, el disco estaba vacío, por lo que es necesario crear una tabla de particiones. Noten que en la imagen está seleccionado "No", pero obviamente van a necesitar elegir "Sí" :-)

Bien, ya tenemos nuestro disco con tabla de particiones listo para ser usado. Nuestro pŕoximo paso va a ser crear una partición /boot no encriptada, para poder permitir que el sistema bootee. Seleccionamos el espacio libre de nuestro disco.

Creamos una nueva partición de 100 MB.

La hacemos una partición primaria (aunque es muy posible que funcione sobre una lógica).

Al principio del espacio libre, sólo por gusto.

Por defecto el instalador queire establecer una partición /, por lo que es necesario cambiarle el punto de montaje.

Finalmente, guardamos los cambios.

Hora de configurar los volúmenes cifrados.

Para proceder, es necesario guardar los cambios a los discos.

Y creamos un volumen cifrado.

Elegimos el espacio libre de nuestro disco para crear tal volumen.

Guardamos los cambios.

Y terminamos la creación del volumen cifrado.

Al crear un volumen cifrado, el sistema ofrece sobreescribir los datos actuales con datos aleatoreos. Éste paso no es estrictamente necesario, pero si altamente recomendable.

La sobreescritura de los datos con datos aleatoreos puede tardar mucho tiempo. Tardé mas de tres horas en éste paso en un disco de 160G. Se puede cancelar en cualquier momento sin problemas aparentes.

Un paso mas que importante: establecer la frase-contraseña para cifrar el disco.

Por supuesto, hay que repetir la misma para validar que se haya escrito correctamente. ¡Y a no olvidársela!

Ahora nos toca configurar el gestor de volúmenes lógicos (LVM).

Otra vez, hay que guardar los cambios.

La idea ahora es crear un grupo de volúmenes y crear dentro de él los volúmenes lógicos que querramos (swap y / en nuestro caso).

Un nombre para el grupo de volúmenes.

Creamos el grupo de volúmenes en nuestra partición encriptada.

Una vez creado el grupo de volúmenes, hay que crear los volúmenes lógicos para la swap y /.

Hay que repetir éstos últimos pasos para crear /. Luego seleccionamos nuestro volúmen lógico para la swap y establecemos una partición de éste tipo en él:

Otra vez, hay que repetir los pasos anteriores para /, normalmente queda como la siguiente figura.

¡Terminamos el particionado! Hora de guardar los cambios.

El resto sigue siendo el mismo proceso de instalación de siempre. Una vez que se reinicia el sistema, podemos ver como se nos pide la frase-contraseña que establecimos antes para poder bootear.

Y eso es todo :-)

Cuenta regresiva para Squeeze

2011-01-22T15:13:00-03:00

El equipo de liberación anunció que Squeeze será liberado el fin de semana del 5 y 6 de Febrero de éste año.

¡Únete a nosotros en la cuenta regresiva!

El banner fué hecho por mvd basado en el tema "Spacefun" de Valessio. Te invitamos a linkearlo desde tu sitio web.

Y mientras esperas, puedes actualizar tus sistemas Lenny a 5.0.8.

Post original en inglés.

Lo que ¿todo? programador debe saber sobre memoria

2011-01-13T18:06:00-03:00

Estuve leyendo el artículo de Ulrich Drepper "What every programmer should know about memory", de Noviembre de 2007.

En mi caso particular, educado como ingeniero electrónico, leer este trabajo fué sin duda una gran idea. Lo que no implica que lo pude "desglosar" totalmente, o dicho de otra manera, hay partes del texto que me siguen resultando "oscuras", pero nada que con un poco de esfuerzo no se logre comprender. Sencillamente estoy usando un algoritmo de lectura/comprensión bastante perezoso ;-)

El hecho de no tener mucha formación "formal" de software no influyó mucho sobre la comprensión del texto. Dicho de otro modo, no es excusa para no leerlo :-)

Lo único que me gustaría notar como crítica muy leve es el hecho de que no todo el texto es para todo programador. Los primeros capítulos son fundantes, aunque quizás mi óptica de hardware adquirida a través de los años me nuble la visión un poco :-) Pero sin duda ayudan a comprender muchísimo lo que pasa por dentro de una computadora. La parte que creo que no todo programador pueda llegar a aprovechar es en donde se explica como mejorar el código para casos particulares de hardware. Muchas veces lo que queremos es que nuestro software corra razonablemente bien en toda plataforma, y no que se destaque en una en particular. También es posible aplicar algo de ésta lógica a un mantenedor de paquetes de una distribución binaria, como es mi caso con Debian.

Sin embargo, vuelvo a hacer énfasis de que es una muy buena lectura.

Publicado QAntenna 0.2.3

2011-01-09T18:08:00-03:00

Ésta nueva versión de QAntenna trae un par de bugfixes y features nuevos:

Agrega soporte drag and drop, gracias a Graham Seale.
Muestra los alambres radiales cuando se especifican en la tarjeta GN (tierra o ground).
Acepta los comentarios en la tarjeta CE.
Arregla el parseo de la tarjeta GD.
Las salidas input.necin son ahora creadas con nomenclatura exponencial.

Como siempre, la pueden descargar desde [SourceForge](https://sourceforge.net/projects/qantenna/). Por otro lado, el paquete para Debian va a estar disponible en breve en Sid. Y va a ser mi primer paquete con la bandera DM-Upload-Allowed: yes =)

El orden natural de las cosas

2011-01-08T15:51:00-03:00

Gracias a Fede Heinz, la próxima versión de Choqok va a tener un feature nuevo: mostrar los dents en orden natural. ¿Cómo es ésto? Sencillo: cada nuevo dent va a aparecer abajo del dent anterior, y no encima. Nada mejor que una imagen para ilustrar:

Para los que usamos Debian Sid, y gracias a Noah, ya podemos disfrutar de éste feature a través de un paquete release candidate.

Si todavía piensan que ésto no es una buena idea, consideren el caso de una conversación. No mas ir leyendo de abajo para arriba para poder entenderla (o, en términos mas geeks, ir leyéndolas de arriba hacia abajo y cargando un buffer de ideas para poder entenderla).

Reviviendo una pedalera Zoom G9.2tt

2011-01-07T20:52:00-03:00

Hace un par de semanas un amigo, S, intentó actualizar el firmware de una pedalera Zoom G9.2tt. El resultado: una pedalera en estado catatónico.

El proceso se realiza utilizando únicamente Windows (ya empezamos mal), con un software propietario (típico...) bastante viejo y a través de ¡los puertos MIDI! Y eso a pesar de que la pedalera cuenta con un conector USB.

Revisando un poco su instalación, mi primer sospechoso fué el cable MIDI, que no es otra cosa que un conversor USB ←→ MIDI. Teniendo en cuenta mi experiencia con conversores de éste tipo utilizados para una funcionalidad alternativa (tienden a no andar), le sugerí a S que se consiga una máquina con Windows y que se venga a casa, en donde tengo una placa con hardware MIDI real.

En el primer intento llegamos a un punto del proceso de reflasheado mucho mas avanzado que con el cable MIDI por USB. Pero el mismo seguía fallando dando un simple mensaje de error. Muy informativo :-(

S había leído en algún foro que mucha gente probó muchas veces hasta que finalmente anduvo. Y éso fué lo que hicimos, hasta que, en un momento, logramos terminar el proceso.

Sin embargo no todo quedó bien: la pedalera acusa que los pedales no están calibrados. Y ésto, hasta el momento, no tenemos ni idea como solucionarlo. ¿Alguien con alguna idea?

Algunos corolarios de la situación:

Cuando se va a utilizar algún medio para un uso atípico, tratar de evitar los conversores. Por ejemplo, usar un puerto paralelo mediante conversor USB puede andar para una impresora, pero es mucho mas difícil que lo haga utilizándolo para transferencias JTAG. O un cable MIDI←→USB ;-) Mejor conseguirse un cable específico o una máquina con el puerto correcto.
No sé que estaba pensando la gente de Zoom al usar los puertos MIDI para flashear una pedalera. En Windows. Uugh.

El nacimiento de Jesús

2010-12-09T12:05:00-03:00

18 de Diciembre, 21hs. en el Paseo de las Esculturas (Urquiza entre Salta y Perú), Bahía Blanca. En caso de lluvia se realizará en el gimnasio del Colegio Don Bosco (Güemes y Moreno), Bahía Blanca.

Declarado de interés provincial y municipal.

OpenVox G400P en Debian

2010-12-01T00:37:00-03:00

This post is also available in english.
Éste post también se encuentra redactado en inglés.

Instalando un servidor de telefonía IP no tuve mejor idea que adquirir una placa OpenVox G400P para conectarme a la red GSM sin buscar lo suficiente en la web antes. Mi error.

**[Los problemas]{.underline}**:

- Al momento de adquirir la placa (hace apenas \~6 meses) no existía soporte oficial para [Dahdi](http://www.voip-info.org/wiki/view/DAHDI). - Cuando el mismo [apareció](http://www.chan-extra.org/index.php/OpenVox_G400P_User_Manual_for_dahdi), resulta ser que no constaba de unos simples parches, sino un script que supone que uno usa un sistema basado en RPMs, baja y modifica las fuentes de Dahdi y [Asterisk](http://www.asterisk.org/), los compila e instala, sin dejar lugar a modificaciones por parte del usuario. - Al preguntar al soporte, me dijeron que me lo instalaban ellos mismos... si les daba acceso SSH (de no creer). Me tomé el trabajo de explicarles que pedir acceso SSH a sus clientes era una **mala idea**, pero me parece que [no entendieron](http://bbs.openvox.cn/viewthread.php?tid=1463&page=1#pid6399).

**[Desarmando el script:]{.underline}**

Mi idea entonces fué instalar una máquina virtual con la versión de Elastix o Trixbox que ellos pedían para hacer correr el script, obtener el código fuente parcheado, revisarlo y compilarlo en mi Debian. Llegué a bajar tres versiones distintas de ésas distros... y parece ser que ninguna de ellas era la que el script esperaba. Para ese momento decidí hacer lo que debía haber hecho desde un principio: imprimir el script, desarmarlo y armar ése código fuente yo mismo.

Por supuesto, usé [git](http://git-scm.com/) para el proceso :)

[**El código fuente resultante:**]{.underline}

Dahdi:

Asterisk: (puede estar incompleto, todavía lo tengo que chequear).

En el caso de Dahdi, la rama *openvox-g400p* contiene las modificaciones de chan-extra, la rama *oslec* contiene el soporte para el cancelador de eco [OSLEC](http://www.rowetel.com/blog/?page_id=454). Finalmente la rama *master* es un merge de ambas. Todavía no probé que la placa funcione con oslec, pero está ahí porque la uso en la otra placa que tengo en el servidor.

**[Recomendaciones para la gente de OpenVox:]{.underline}** Si bien me parece excelente que quieran proveer a sus clientes de un script "automágico", un usuario de otras distribuciones y/o un usuario avanzado va a encontrar mejor que le proporcionen un patch para el código fuente. Lo bueno es que gracias a git ésto no es complicado. Les sugiero el siguiente workflow: 1.- Descomprimir el código fuente original de Dahdi, renombrar el directorio y crear un repositorio git del mismo. [\$ tar -xf dahdi-x.y.z.tar.gz]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ mv dahdi-x.y.z dahdi]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ cd dahdi]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git init]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git add -A]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git commit -m "Original Dahdi source code version x.y.z."]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"}

2.- Crear una rama *upstream* para seguir el desarrollo de Dahdi. [\$ git checkout -b upstream]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} 3.- Taggear la release específica de Dahdi en la rama upstream. [\$ git tag -a dahdi-x.y.z]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} 4.- Volver a la rama *master* y realizar el desarrollo del driver en la misma. [\$ git checkout master]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\[... desarrollo...\]]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} 5.- Una vez terminada una release, taggearla. [\$ git tag -a chan-extra-x.y.z]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} 6.- Crear un parche a partir de ambas ramas (aunque sería mejor publicar el repositorio git directamente): [\$ git diff upstream master \> chan-extra-x.y.z.patch]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} Nota: hay mejores formas para obtener un parche que ésta manera... pero no es algo que haya explorado lo suficiente. Se aceptan comentarios ;) 7.- Cuando se deba desarrollar para una nueva versión de Dahdi, basta con actualizar la rama correspondiente y hacer un merge: [\$ git checkout upstream]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git rm '\*']{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git clean -xdff]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ tar zxfv ../../dahdi-x.y.z+1.tar.gz --strip=1]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git add -A]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git commit -m "Import upstream x.y.z+1 release."]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git checkout master]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git merge upstream]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} Luego el usuario podrá aplicar el parche usando *patch* y compilar. Basta con seguir el mismo workflow para crear parches para Asterisk. Por supuesto, se aceptan comentarios sobre éste workflow :-)

OpenVox G400P in Debian

2010-12-01T00:37:00-03:00

Éste post está también disponible en español.
This post is also available in spanish.

I bought an OpenVox G400P GSM telephony card to set up a VoIP server running Debian. I clearly didn't do my research homework before starting, and it turned out that it was not easy to set up this card with Dahdi, wich I had to keep in order to be able to use another card I already had on that server.

**[Problems I found]{.underline}**:

- There was not official [Dahdi](http://www.voip-info.org/wiki/view/DAHDI) support for this board until about \~6 months ago. - When it finally [appeared](http://www.chan-extra.org/index.php/OpenVox_G400P_User_Manual_for_dahdi), it turned out that there were not just some patches to the original source code, but some scripts that supossed that my system was RPM based. Oh, and it also downloads, modifies, compiles and installs Dahdi and [Asterisk](http://www.asterisk.org/), leaving no room for customization. - When I asked the support about this issue, they told me that if I gave them SSH access they would install it for me (!?). I took the time to explain them that asking their clients for SSH access to their servers was **not** a good idea. Sadly, it seems that [they didn't took my advice](http://bbs.openvox.cn/viewthread.php?tid=1463&page=1#pid6399).

**[Dissasembling the script:]{.underline}**

So my next move was to get and install either Elastix or Trixbox in a virtual machine, supossedly supported by the script they provide, get the modified source code, check it and compile it in my Debian box. I got to download three different versions of those distros, and it seems I couldn't get the correct version the script needed. So the next step was obvious: print the script, analyze it and modify it to get the source code.

Of course, I used [git](http://git-scm.com/) to keep the changes :-)

[**Final source code:**]{.underline}

Dahdi:

Asterisk: (might be incomplete, I still have to check it).

In the Dahdi repo, the *openvox-g400p* branch has the chan-extra modifications, the *oslec* branch contains the support for [OSLEC](http://www.rowetel.com/blog/?page_id=454) echo canceler. Finally *master* is a merge of both. I still didn't check if the G400P supports oslec, but I have it there because I use it with the other card I have in the server.

**[Recommendations for OpenVox:]{.underline}** While I find an excellent idea to have an "automagic" script for your clients, a user os another distributions or/and an advanced user will find a patch most suitable. The good thing about this is that git makes it's creation quite simple. I suggest the following workflow: 1.- Uncompress Dahdi's source code, rename the new directory and create a git repo out of it. [\$ tar -xf dahdi-x.y.z.tar.gz]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ mv dahdi-x.y.z dahdi]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ cd dahdi]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git init]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git add -A]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git commit -m "Original Dahdi source code version x.y.z."]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"}

2.- Create an *upstream* branch to follow Dahdi's development. [\$ git checkout -b upstream]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} 3.- Tag Dahdi's release in the *upstream* branch. [\$ git tag -a dahdi-x.y.z]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} 4.- Go back to the *master* branch and develop the driver. [\$ git checkout master]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\[... desarrollo...\]]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} 5.- Once finished a release, tag it. [\$ git tag -a chan-extra-x.y.z]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} 6.- Make a patch out of it (althought it would be better to just publish the git repo). [\$ git diff upstream master \> chan-extra-x.y.z.patch]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} Note: there are far more better ways to generate a proper patch using git... but I had no time to get into that yet :-/ Comments welcomed :-) 7.- Whenever we need to develop with a newer Dahdi's release, we just need to update the *upstream* branch and merge it back to *master*. [\$ git checkout upstream]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git rm '\*']{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git clean -xdff]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ tar zxfv ../../dahdi-x.y.z+1.tar.gz --strip=1]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git add -A]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git commit -m "Import upstream x.y.z+1 release."]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git checkout master]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} [\$ git merge upstream]{.Apple-style-span style="font-family: 'Courier New', Courier, monospace;"} Then the user will just need to patch the original source code and compile. Of course, the same workflow can be used for making patches for Asterisk. Comments on this workflow will be much appreciated :-)

El planeta Debian en español también está en identi.ca

2010-10-23T19:57:00-03:00

Cuando ví el anuncio de Zack de que el feed de Planet Debian se estaba exportando a la cuenta \@planetdebian de identi.ca, le pregunté si también iba a haber una cuenta similar para el Planeta Debian en español. Me dijo que no, pero que me sintiese libre de hacerlo yo mismo. Y eso hice :-)

Señoras y señores, con ustedes, [\@planetdebianes](http://identi.ca/planetdebianes).

Configurando la placa de sonido M-Audio Delta 1010LT por defecto

2010-10-20T00:49:00-03:00

Me compré una placa M-Audio Delta 1010LT a la que quiero usar como placa por defecto. Pero las cosas ya no son como antes que bastaba desactivar la placa on board:

$ cat /proc/asound/cards]
0 [SB      ]: HDA-Intel - HDA ATI SB
              HDA ATI SB at 0xfe024000 irq 16
1 [E320SE  ]: USB-Audio - Eye 320SE
              PixArt Imaging Inc. Eye 320SE at usb-0000:00:13.1-2, full speed]
2 [Generic ]: HDA-Intel - HD-Audio Generic
              HD-Audio Generic at 0xfdffc000 irq 19
3 [M1010LT ]: ICE1712 - M Audio Delta 1010LT
              M Audio Delta 1010LT at 0xbf00, irq 21

La primera es la placa onboard, que quiero dejar activada por el momento. La segunda, el mic de la webcam. La tercera, el HDMI de la placa de video. Y la cuarta, la M1010LT.

Y acá viene el problema: la M1010LT no es la placa por defecto, por ende algunas aplicaciones no la van a usar (¿les suena flash player?). Ya me había pasado algo similar antes (la E320SE quedaba por defecto), así que recurrí al archivo asound.conf. Mi primer intento fué:

pcm.!default {
 type hw
 card M1010LT
}

ctl.!default {
 type hw
 card M1010LT
}

El resultado: silencio absoluto :-( . Luego usé el script sugerido en la página de asound.conf y llegué a:

pcm.SB { type hw; card SB; }
ctl.SB { type hw; card SB; }
pcm.E320SE { type hw; card E320SE; }
ctl.E320SE { type hw; card E320SE; }
pcm.M1010LT { type hw; card M1010LT; }
ctl.M1010LT { type hw; card M1010LT; }
pcm.Generic { type hw; card Generic; }
ctl.Generic { type hw; card Generic; }
pcm.!default pcm.M1010LT
ctl.!default ctl.M1010LT

Otra vez, silencio absoluto :-/. Me cansé de buscar en la web y no encontrar soluciones. No uso pulseaudio y no sé si vale la pena usar jack. Bueno, de todas maneras las aplicaciones que usan phonon andaban bien, y para los videos podía usar los auriculares. Pero cuando uno tiene que ver un stream en vivo que dura muchas horas (¿les suena el rescate de los 33 mineros?), se hace una molestia. ¿que tal un hack rápido? Cable de audio conectado a la salida de la placa on board y en su otra punta a una de las entradas de la M1010LT. Feo, pero anda.

La "suerte" a veces ayuda.

Ayer, siguiendo un link en la web, dí con unos videos en You Tube. Me puse los auriculares, apreté play y... el sonido salía por los parlantes :S. Un cat /proc/asound/cards me decía que la M1010LT estaba como placa 0. Bien, entonces era posible usarla por defecto, mas allá de que no lo haya logrado con asound.conf. Buscando en la web un poco mas de información sobre toda la que ya busqué, dí con una página donde explican como setear los módulos de las placas restantes como placa 1 (o lo que siga por defecto). No es la solución, pero al menos es mas prolija que el cable externo :-)

Por supuesto, lo mejor sería solucionarlo desde asound.conf, pero no lo he logrado aún :-/ . Por cierto, uso Debian.

Actualización 20101025 00:21 ARST: parece ser que la cosa no termina ahí. Como puse en un comentario mas abajo, tuve que modificar /etc/modprobe.d/alsa-base.conf. Y encima empecé a dar con un bug: la placa no siempre se detecta al arrancar el sistema. Así que finalmente hice ésto en el citado archivo:

# Options for the M1010LT.
alias snd-card-0 snd-ice1712
options snd-ice1712 model=delta1010lt index=0

Y si la placa no es detectada, basta ejecutar alsa force-reload como root.

Ensalada con riñón de vaca

2010-09-14T23:37:00-03:00

Mi mamá dice que, en lo que a comidas se refiere, de lo que hay le pongo. Y tiene razón. Hoy salimos de compras con mi novia y mientras ella compraba carnes, dí con un paquetito de riñón de vaca. "Excelente para hacerlos salteados en una ensalada" pensé. Y eso salió :-)

Con ustedes, una mitad de nuestro invitado especial:

La mitad de un riñón de vaca. cc-by-sa 3.0.

La otra mitad ya estaba en la sartén:

Riñones en la sartén. cc-by-sa 3.0.

Por supuesto, una ensalada no se puede hacer solo con riñón. Por eso incorporamos algunos ingredientes mas:

Algunos ingredientes mas para la ensalada. cc-by-sa 3.0.

La lista completa:

Zanahoria.
Lechuga.
Atún al natural.
Arvejas (de las congeladas y no en conserva, las conocí gracias a mi novia).
Aceitunas negras.
Granos de choclo amarillo.
Ajo granulado.
Perejil disecado.
Pimienta.
Aceite de oliva.

El resultado final:

Ensalada de rinón de vaca completa. cc-by-sa 3.0.

Espero que no me caiga tan pesado como a éste morocho ;-)

Paquetes semi oficiales de KDE SC 4.5.1

2010-09-09T21:30:00-03:00

[George Kiagiadakis](http://gkiagia.wordpress.com/) envió un [correo](http://lists.debian.org/debian-kde/2010/09/msg00002.html) a la [lista debian-kde](http://lists.debian.org/debian-kde/) anunciando paquetes semi-oficiales de KDE SC 4.5.1, los que se encuentran disponibles en .

Algunos detalles mas del correo:

*"Desafortunadamente no todos los paquetes están listos, por lo que puede que noten algunos faltantes. Los paquetes fuentes faltantes hasta el momento son kdeaccessibility, kdeadmin, kdegames, kdemultimedia, kdebindings, kdetoys, kdewebdev y kde-l10n como también meta-kde (el paquete kde-standard y misceláneos). A pesar de ésto pueden actualizar todo lo demás a partir de su instalación de KDE SC 4.4.5 usando las instrucciones del sitio (en inglés).*

* *

*Una vez que todos los paquetes estén preparados y funcionando, planeamos liberarlos a Debian experimental. Hasta que eso ocurra, todas las actualizaciones o paquetes nuevos irán a ése repositorio.*

* *

*Pedimos disculpas for el largo retrazo desde que 4.5.0 fué liberado, pero espero que entiendan las razones detrás de ésto (preparando a Squeeze para que esté listo, trabajo, vida real, vacaciones de verano, pocas personas activas en el equipo, etc...).*

* *

*A toda la gente que se ofreció para ayudar: apreciamos su oferta y pedimos disculpas por la falta de documentación acorde. Empaquetar KDE SC no es una tarea fácil y normalmente le recomendamos a los recién llegados que intenten empaquetar algo mas chico primero, como algo de* [*kde-apps.org*](http://kde-apps.org/)*. Intentaremos hacer las cosas mejores en el futuro, documentando mejor nuestro flujo de trabajo y políticas. Si aún quieren ayudar, como pueden ver, todavía hay trabajo por hacer. Además de empaquetar, hay otras cosas que pueden hacer, como actualizar archivos de copyright (lo que encuentro fácil, pero consume mucho tiempo).*

* *

*Los mejores deseos,*

*George*

* *

*PS: Por favor lean bien las instrucciones y por favor reporten los bugs de empaquetamiento aquí (n. del e.: en la* [*lista debian-kde*](http://lists.debian.org/debian-kde/)*) y en irc, pero no en el sistema de seguimiento de bugs de Debian. Gracias por adelantado"*.

Particularmente nunca me pude dar el gusto de compilar KDE SC por mi mismo. Lo intenté un par de veces, pero mi peor enemigo es el tiempo. Y mantener paquetes para Debian **tiene** que ser un gusto y no una carga. Por eso encuentro la sugerencia de George de empaquetar cosas de [kde-apps.org](http://kde-apps.org/) muy adecuada, en especial para los que tenemos poco tiempo ;-) ya que suelen ser programas de menor complejidad de empaquetado.

Por otro lado, si bien estoy lejos de tener muchos conceptos claros, en breve me voy a juntar con unos amigos a enseñarles a empaquetar software. Con un poco de suerte vamos a mantener una serie de paquetes, muy posiblemente relacionados con la electrónica. Espero poder generar sinergia suficiente para que ésto se expanda :-)

Ah, cabe aclarar que gran parte del trabajo para creaer los paquetes de KDE SC 4.5.1 fué realizado por George (o al menos eso tengo entendido) ¡Gracias George!

¡Feliz 17 años Debian!

2010-08-16T12:24:00-03:00

Hace algunos años, un tocayo mío escribía en la lista de correo del LugFI una frase que decía algo así como "No entiendo como la gente no usa Debian". Tamaña curiosidad me agarró que, un mes antes de su release oficial, y por no tener banda ancha aún, llegaban desde Buenos Aires dos DVDs con un snapshot de Debian Sarge.

Casi siete años mas tarde, una [DebConf](http://debconf8.debconf.org/) y un montón de buenos momentos, yo mismo me hago esa pregunta.

[¡¡¡Feliz cumpleaños Debian!!!]{.Apple-style-span style="font-size: x-large;"}

Si sentís lo mismo que yo, no dudes en decir gracias.

Diego: al fin voy a tener un buen recuerdo tuyo

2010-07-03T20:10:00-03:00

Estimado Diego:

Tengo que admitirlo, no soy una persona a la que le interese mucho el fútbol. Criado como riverplatense, con ya casi 28 años de edad, hasta el día de hoy no tenía un buen recuerdo tuyo. Ésos venían de documentales o apasionadas historias de gente mas grande que yo. Tu imagen fué siempre la de un gran jugador venido a menos por las drogas, que se metía en escándalos de poca monta, una vida que no te envidio en lo mas mínimo.

Debo admitir que cuando me enteré que ibas a ser el director técnico de la Selección Argentina sentí miedo que fueras a arruinar nuestra (poca) buena imagen como argentinos otra vez, haciéndo algún escándalo (bueno, algo de eso hiciste) o con algún otro problema de dopping.

Tampoco esperaba grandes resultados. De hecho, no esperaba que pasemos la primera ronda del mundial.

Pero debo admitirlo: lo lograste. Lograste que al menos tenga una buena imagen tuya que haya presenciado yo mismo. Lograste que te gane algo de respeto, mas del que alguna vez pensaba llegar a tenerte. Y, al menos por eso, debo presentarte mis disculpas. Y no olvidarme de darte las gracias, la Selección hizo un muy buen trabajo representándonos, mas allá de los resultados.

Querido Diego: es hora de decir perdón y gracias.

Generar paquetes Debian a través de CMake

2010-06-30T21:30:00-03:00

This post is also available in english.

Un compañero de trabajo insiste en generar paquetes Debian a través de CMake. Pero yo pienso (al igual que muchas personas a las que le pregunté por IRC) que es una mala idea, en especial considerando los archivos copyright y control. ¿Que opinan ustedes del asunto?

On creating Debian packages with CMake

2010-06-30T21:19:00-03:00

A co-worker of mine insists on creating Debian packages trough cmake instead of doing them as usual. But I think (as many other people I asked trough IRC) that this is a bad idea, specially considering copyright and control files. What's you opinion on this topic?