tag:blogger.com,1999:blog-63571722977370574752024-03-13T19:47:35.369-03:00Solo sé que sé querer, que tengo Dios y tengo fe.(y eso no es poca cosa)Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.comBlogger231125tag:blogger.com,1999:blog-6357172297737057475.post-3010177667770674252021-05-30T16:51:00.005-03:002021-05-30T16:51:50.401-03:00Moved!<p> This blog has been moved to <a href="https://perezmeyer.com.ar/">https://perezmeyer.com.ar/</a></p>Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com2tag:blogger.com,1999:blog-6357172297737057475.post-27668399417735668262021-03-16T11:02:00.002-03:002021-05-29T15:06:58.965-03:00On configuring RAK LoRa devices, or how to avoid their Windows-only serial application<p><b>tl;dr:</b> use a serial terminal which can buffer input and send it all at once, lines should end with \CR\LF. <br /></p><p>I'm am currently working on bringing up a <a href="https://en.wikipedia.org/wiki/LoRa" target="_blank">LoRa</a> network in Bahía Blanca. Parts of the nodes I need to set up are made by <a href="https://www.rakwireless.com/en-us" target="_blank">RAK Wireless</a>.</p><p>According to their documentation the nodes can be configured by using a serial connection to them. So I quickly turned to <a href="https://salsa.debian.org/minicom-team/minicom" target="_blank">minicom</a> 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.</p><p>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.</p><p>After much digging the web, trial and error I've found a way to solve this:</p><ol style="text-align: left;"><li>Commands should end with \CR\LF.</li><li>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.</li></ol><p>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 <a href="http://cutecom.sourceforge.net/" target="_blank">cutecom</a>, for which one has to enter the input and send it all at once.</p>Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-63469753746073923682020-08-18T10:09:00.006-03:002020-08-18T12:14:49.516-03:00Stepping down as Qt 6 maintainers<p>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 <a href="https://wiki.qt.io/Qt_6.0_Release">https://wiki.qt.io/Qt_6.0_Release</a>). We will do our best to keep the Qt 5 codebase up and running.<br /><br />We <b>**love**</b> 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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />It has been an interesting ride all these years, we really hope you enjoyed using Qt.<br /><br />Thanks for everything,<br /><br /></p><p style="margin-left: 40px; text-align: right;">Dmitry and Lisandro.</p><b>Note 20200818 12:12 ARST:</b> I was asked if the move has anything to do with code quality or licensing. The answer is a huge <b>no</b>, Qt is a <b>**great**</b> project which we love. As stated before it's mostly about lack of free time to properly maintain it. <p style="margin-left: 40px; text-align: left;"> <br /></p>Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com4tag:blogger.com,1999:blog-6357172297737057475.post-39756213057367442142020-06-02T09:49:00.002-03:002020-06-02T10:26:20.798-03:00Simplified Monitoring of Patients in Situations of Mass Hospitalization (MoSimPa) - Fighting COVID-19I 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.<br />
<h1 style="text-align: left;">
In the beginning</h1>
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 <a href="https://en.wikipedia.org/wiki/Ventilator">ventilation machines</a> at disposal. Another group of people started thinking on another ways of helping. In <a href="https://en.wikipedia.org/wiki/Bah%C3%ADa_Blanca">Bahía Blanca</a> arised the idea of monitoring some variables remotely and in masse.<br />
<br />
<h1 style="text-align: left;">
Simplified Monitoring of Patients in Situations of Mass Hospitalization (MoSimPa)</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiirMCV5fhmwD3wZMO1Vks51O8Wumo16zMlhmLlCLdUeN7vkq_cr4SAUgBATcPdT7JhAKxoZrhYIcPwRUoRJO6clgPFe9qnUKZGGhaROM6SJRO40sAER_WYHuHHtz8h4dZs_jVr3aSmy_h0/" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="720" data-original-width="1270" height="362" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiirMCV5fhmwD3wZMO1Vks51O8Wumo16zMlhmLlCLdUeN7vkq_cr4SAUgBATcPdT7JhAKxoZrhYIcPwRUoRJO6clgPFe9qnUKZGGhaROM6SJRO40sAER_WYHuHHtz8h4dZs_jVr3aSmy_h0/w640-h362/device.jpg" title="The system" width="640" /></a></div>
<div>
<br /></div>
<div>
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: <a href="https://en.wikipedia.org/wiki/Pulse_oximetry">oximetry</a> (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.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYvNepejoy6trjGty8HnHt03RQOZcqBqC-aXAMw0FzJserXRFowG99nPdWuhQOXaWMJ7U0ZzILwuUfvU1acaKgrOyOHaBZQ_-myhcJItm-5mtBHnQ51hsUdWzCT4nWHD1VXb5XmJkKsdhS/" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="158" data-original-width="418" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYvNepejoy6trjGty8HnHt03RQOZcqBqC-aXAMw0FzJserXRFowG99nPdWuhQOXaWMJ7U0ZzILwuUfvU1acaKgrOyOHaBZQ_-myhcJItm-5mtBHnQ51hsUdWzCT4nWHD1VXb5XmJkKsdhS/s320/paraayudar.png" width="320" /></a></div>
<div>
</div>
<br />
This is where the project <a href="https://www.facebook.com/paraayudardar/">Para Ayudar</a> was created. The project aims to produce the aforementioned non-invasive device to be used in health institutions, hospitals, intra hospital transports and homes.<br />
<div>
<br /></div>
<div>
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 <b>NOT</b> designed for ICUs.</div>
<div>
<br /></div>
<div>
All the above done with <a href="https://en.wikipedia.org/wiki/Free_and_open-source_software">Free/Libre/Open Source</a> <a href="https://gitlab.com/mosimpa/">software and hardware</a> designs. Any manufacturing company can then use them for mass production.</div>
<div>
<br /></div>
<div>
<h2 style="text-align: left;">
The importance of early pneumonia detection</h2>
</div>
<div>
<br /></div>
<div>
We were already working in MoSimPa when an NYTimes article caught or attention: <a href="https://www.nytimes.com/2020/04/20/opinion/sunday/coronavirus-testing-pneumonia.html">"The Infection That’s Silently Killing Coronavirus Patients"</a>. From the article:</div>
<div>
<br /></div>
<div>
<blockquote>
<span style="font-size: medium;"><b>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.</b></span></blockquote>
<br /></div>
<div>
This greatly reinforced the idea we were on the right track.</div>
<div>
<br /></div>
<div>
<h1 style="text-align: left;">
The project from a technical standpoint</h1>
</div>
<div>
</div>
<div>
<br /></div>
<div>
As the project is primarily designed for and by Argentinians the <a href="https://mosimpa.gitlab.io/">current system design and software documentation</a> 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.</div>
<div>
</div>
<div>
<h2 style="text-align: left;">
</h2>
<h2 style="text-align: left;">
General system description</h2>
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGFCzkunfiAM2SkmOdi-LJKmp4SRoOdmJPfPUGugWTtTX2vUo8-aaEb-gri0yjszeqLH5qWnEjunQPmfaFSh5-bgrs8gdrTJwwJQGEeBkarJpZzIccKL0FgrqN0HTqwI4L2dKHMYgG3Ef5/" style="margin-left: 1em; margin-right: 1em;"><img alt="System schema" border="0" data-original-height="497" data-original-width="714" height="446" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGFCzkunfiAM2SkmOdi-LJKmp4SRoOdmJPfPUGugWTtTX2vUo8-aaEb-gri0yjszeqLH5qWnEjunQPmfaFSh5-bgrs8gdrTJwwJQGEeBkarJpZzIccKL0FgrqN0HTqwI4L2dKHMYgG3Ef5/w640-h446/esquema_conexiones.png" title="The system schema" width="640" /></a></div>
<div>
<br /></div>
<div>
</div>
<div>
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.</div>
<div>
<h2 style="text-align: left;">
</h2>
<h2 style="text-align: left;">
The hardware</h2>
</div>
<div>
</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
<h2 style="text-align: left;">
The software</h2>
</div>
<div>
</div>
<div>
<br /></div>
<div>
Here we have many more components to describe. Firstly the <a href="https://gitlab.com/mosimpa/esp32-firmware">ESP32 code</a> 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.</div>
<div>
<br /></div>
<div>
For the rest of the stack I decided to go ahead with whatever is available in <a href="https://www.debian.org/">Debian</a> 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 <a href="https://qt-kde-team.pages.debian.net/">Qt maintainers</a> then using <a href="https://www.qt.io/">Qt</a> will also be quite natural for me. Plots? <a href="https://qwt.sourceforge.io/">Qwt</a>, of course. And with that I have most of my necessities fulfilled. I choose <a href="https://www.postgresql.org/">PostgreSql</a> as database server and <a href="https://mosquitto.org/">Mosquitto</a> as MQTT broker.</div>
<div>
<br /></div>
<div>
Between the database and MQTT is <a href="https://gitlab.com/mosimpa/datakeeper">mosimpa-datakeeper</a>. The piece of software from which medical staff monitor patients is unsurprisingly called <a href="https://gitlab.com/mosimpa/monitor">mosimpa-monitor</a>.</div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMgmOOkaGOhYGptLySzKPWzLwcILKZ7juzH1SzRk_BZDhLsXzftpdxSvo3cRFuAMQ_7KvduKY4Amps-zRcR4nD5nfZETPI_KjdiMrUAV0-twApvG_fpNLj3mpefy6OGJVkCDBq3863DugB/" style="margin-left: auto; margin-right: auto;"><img alt="mosimpa-monitor" border="0" data-original-height="541" data-original-width="1635" height="133" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMgmOOkaGOhYGptLySzKPWzLwcILKZ7juzH1SzRk_BZDhLsXzftpdxSvo3cRFuAMQ_7KvduKY4Amps-zRcR4nD5nfZETPI_KjdiMrUAV0-twApvG_fpNLj3mpefy6OGJVkCDBq3863DugB/w400-h133/monitor_main.png" title="MoSimPa's monitor main screen" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">MoSimPa's monitor main screen</td></tr>
</tbody></table>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhI-tL_bDmKSqVybR0dOXF2PE_JjWtjzJeepOlc5QrLxnBuZGVobfNaJogqx5tQOatv1fhX7i1Jh6-9lsVP-pckIJ0EiYYFjD-1zgN5SueBsfGAK3GdjmswtWIj02pDVcnqUK7eHNl9l73k/" style="margin-left: auto; margin-right: auto;"><img alt="mosimpa-monitor plots" border="0" data-original-height="621" data-original-width="913" height="272" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhI-tL_bDmKSqVybR0dOXF2PE_JjWtjzJeepOlc5QrLxnBuZGVobfNaJogqx5tQOatv1fhX7i1Jh6-9lsVP-pckIJ0EiYYFjD-1zgN5SueBsfGAK3GdjmswtWIj02pDVcnqUK7eHNl9l73k/w400-h272/monitor_plots.png" title="Plots of a pacient's data" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Plots of a patient's data</td></tr>
</tbody></table>
<div>
<br /></div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsZjHCJgazGKiAefmU57cTcYjU33D3W_7UGiXzqSfdOneRwj_4iVjh4w97zNn0ft6QYJ758Sc-gaEDttXxwWV_B_qVt2hmyQqjr4XMREnUwSzD2_BYq6Zir7IcdJHbt45ZeFoa53L86KpI/" style="margin-left: auto; margin-right: auto;"><img alt="mosimpa-monitor-alarms-setup" border="0" data-original-height="460" data-original-width="911" height="203" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsZjHCJgazGKiAefmU57cTcYjU33D3W_7UGiXzqSfdOneRwj_4iVjh4w97zNn0ft6QYJ758Sc-gaEDttXxwWV_B_qVt2hmyQqjr4XMREnUwSzD2_BYq6Zir7IcdJHbt45ZeFoa53L86KpI/w400-h203/monitor_alarms.png" title="MoSimPa's monitor alarms setup" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Alarm thresholds setup</td></tr>
</tbody></table>
<div>
<br /></div>
<div>
<br /></div>
<div>
And for managing patients, devices, locations and internments (CRUD anyone?) there is currently a Qt-based application called <a href="https://gitlab.com/mosimpa/abm/">mosimpa-abm</a>. </div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrS6CJ9JgThp8t6nn8Uhxx9fgmd1nrciky075ltccgZdfzEV5FIGfYxz4BbdUykFIjvRgTlUUPI0z-Aw4N8CIlGxsTh5dc_9W4YOMTRLcDbXdmOieUTSKuuQ56c0iwJARINn2Ji64_Kim0/" style="margin-left: auto; margin-right: auto;"><img alt="mosimpa-abm" border="0" data-original-height="673" data-original-width="1024" height="263" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrS6CJ9JgThp8t6nn8Uhxx9fgmd1nrciky075ltccgZdfzEV5FIGfYxz4BbdUykFIjvRgTlUUPI0z-Aw4N8CIlGxsTh5dc_9W4YOMTRLcDbXdmOieUTSKuuQ56c0iwJARINn2Ji64_Kim0/w400-h263/abm.png" title="MoSimPa's ABM main screen" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">ABM main screen</td></tr>
</tbody></table>
<div>
<br /></div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiSFcNyORtkCQa7fpk_ozt1UPv5mDZaY_aR6mO-ZHLlAHTGro8D2g25EbgaHZEFFS0W6wGponcf1GrMh9_9pG2HXT8GdI9kuN_2I-mPPpqUmi2PDIwUzeIaVmTlCfzbF0TsQMz2daWBCJu/" style="margin-left: auto; margin-right: auto;"><img alt="mosimpa-abm-internments" border="0" data-original-height="673" data-original-width="1024" height="263" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiSFcNyORtkCQa7fpk_ozt1UPv5mDZaY_aR6mO-ZHLlAHTGro8D2g25EbgaHZEFFS0W6wGponcf1GrMh9_9pG2HXT8GdI9kuN_2I-mPPpqUmi2PDIwUzeIaVmTlCfzbF0TsQMz2daWBCJu/w400-h263/abm_internments.png" title="MoSimPa's ABM internments view" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">ABM internments view</td></tr>
</tbody></table>
<div>
<br /></div>
<div>
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 <a href="https://webassembly.org/">webassembly</a> but I would have to also build PostgreSql in order to compile Qt's plugin.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
Even if I am a packager I still have some stuff to fix from the packaging itself, like <a href="https://gitlab.com/mosimpa/datakeeper/-/issues/12">letting datakeeper run with its own user</a>. I just haven't got to it yet.</div>
<div>
<br /></div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="BLOG_video_class" height="266" src="https://www.youtube.com/embed/ml7ay9wAoOA" width="320" youtube-src-id="ml7ay9wAoOA"></iframe></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://www.youtube.com/watch?v=ml7ay9wAoOA">A video showing the software in action</a></div>
<div>
<br /></div>
<div>
<h1 style="text-align: left;">
Certifications</h1>
</div>
<div>
</div>
<div>
<br /></div>
<div>
We are working towards getting the system certified by <a href="https://www.argentina.gob.ar/anmat">ANMAT</a>, which is the Argentinian equivalent for EEUU's FDA.</div>
<div>
<br /></div>
<div>
<h1 style="text-align: left;">
Funding</h1>
</div>
<div>
</div>
<div>
<br /></div>
<div>
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 <a href="https://www.facebook.com/story.php?story_fbid=121793116135824&id=112910973690705">payments links with Mercado Pago (in spanish and argentinian pesos)</a> and <a href="https://perezmeyer.com.ar/mosimpa/files/Para_Ayudar_200331_como_donar.pdf">other bank methods (PDF, also in spanish)</a>.</div>
<div>
<br /></div>
<div>
I repeat the links here with an aproximation to US$.</div>
<div>
<br /></div>
<div>
<span class="_3FXB1 selectable-text invisible-space copyable-text" dir="ltr">- <a href="https://www.mercadopago.com.ar/checkout/v1/redirect/219d7beb-da60-4ea9-acfe-e6af7b4578fb/express/?fbclid=IwAR3B_tMTbvFGM0EVXnnEaO_YZhCLgsKRWXDZpjp_mCHzliWfJDZ_VowBhKg&preference-id=543887262-38d90bb3-2da4-4bb6-84a4-6466f74ff5fc&p=f94300b30193bc0ffa289b5e5dfda527">500 AR$ (less than 8 US$)</a> </span></div>
<div>
<span class="_3FXB1 selectable-text invisible-space copyable-text" dir="ltr">- <a href="https://www.mercadopago.com.ar/checkout/v1/redirect/f5135e22-52e3-4471-b2be-9df0f72c174d/express/?fbclid=IwAR16GTCM9XMFgqlI4CAqp4xxVIqRVWuab5B1bqv5dZRemBCOxjb0AJxDQM8&preference-id=543887262-2673caa0-397c-4ced-8925-8f1fbcd0289a&p=f94300b30193bc0ffa289b5e5dfda527">1000 AR$ (less than 15 US$)</a></span></div>
<div>
<span class="_3FXB1 selectable-text invisible-space copyable-text" dir="ltr">- <a href="https://www.mercadopago.com.ar/checkout/v1/redirect/6fd51283-61f2-46f0-b535-96fb8c18d1d0/express/?fbclid=IwAR2XU2TMEtLXVR7PmR5nyTrcezDVd3GU-YAjGvLCIvqhPm2q6dERK1IIyco&preference-id=543887262-20380998-df6f-4936-af1e-f420565a11cb&p=f94300b30193bc0ffa289b5e5dfda527">2000 AR$ (less than 30 US$)</a> </span></div>
<div>
<span class="_3FXB1 selectable-text invisible-space copyable-text" dir="ltr">- <a href="https://www.mercadopago.com.ar/checkout/v1/redirect/b828dd55-abb0-4561-a5f9-b0beaa8d9a16/express/?fbclid=IwAR2Sp-WSb8fqGdE2h9z8TGm2uB2BNxIDUXUj2oQnWFXc6vDS32uD0i__A9s&preference-id=543887262-ba71f4ce-b177-4967-8573-38a04c117fcc&p=f94300b30193bc0ffa289b5e5dfda527">3000 AR$ (less than 45 US$)</a> </span></div>
<div>
<span class="_3FXB1 selectable-text invisible-space copyable-text" dir="ltr">- <a href="https://www.mercadopago.com.ar/checkout/v1/redirect/04231597-fcf7-4623-b7c6-53113f442b38/express/?fbclid=IwAR2agEbemfc2K5u-psdlR45qDmC9WvRNDKn_D8XRXBWab8C2ImMtBEqlroQ&preference-id=543887262-9d719b5e-02e5-48ec-8935-b98e8d36113e&p=f94300b30193bc0ffa289b5e5dfda527">5000 AR$ (less than 75 US$)</a> </span></div>
<div>
<span class="_3FXB1 selectable-text invisible-space copyable-text" dir="ltr"><br /></span></div>
<div>
<span class="_3FXB1 selectable-text invisible-space copyable-text" dir="ltr">You can check the actual convertion rate in <a class="_3FXB1 selectable-text invisible-space copyable-text" href="https://www.google.com/search?q=argentine+peso+to+us+dollars" rel="noopener noreferrer" target="_blank" title="https://www.google.com/search?q=argentine+peso+to+us+dollars">https://www.google.com/search?q=argentine+peso+to+us+dollars</a></span><span class="ZhF0n WyHOW"></span></div>
<div>
<br /></div>
<div>
The project was also presented at a funding call of argentinian <span class="subheadline"> <a href="https://www.argentina.gob.ar/ciencia/agencia">Agencia de Promoción de la Investigación, el Desarrollo Tecnológico y la Innovación</a> (Agencia I+D+i). 900+ projects where presented and 64 funded, MoSimPa between them.</span></div>
Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com2San Andres, B8002 Bahía Blanca, Buenos Aires, Argentina-38.694653736169649 -62.248012057214488-38.695428236169647 -62.249272557214489 -38.69387923616965 -62.246751557214488tag:blogger.com,1999:blog-6357172297737057475.post-42984851680836558832020-03-07T21:38:00.003-03:002020-03-07T21:38:54.771-03:00Qt 4 removed from Debian Sid (unstable)The day has finally arrived: <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953294#10">Qt 4 is no longer part of Debian unstable</a>. It's gone.<br />
<br />
Thanks should go to many people. You know who you are, and I really appreciate the support and time you put into this. <b>**Thanks**</b>Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-27598484006562780462020-01-09T19:31:00.001-03:002020-01-09T19:31:03.902-03:00Qt 4 removed from Debian bullseye (current testing)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.<br />
<br />
<br />
<br />Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-67699739611104062482019-08-09T15:12:00.001-03:002019-08-09T15:12:54.582-03:00Developing Nordics' nRF9160 DK using Qt CreatorSo I've got my hands into a <a href="https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF9160-DK">nRF9160DK (development kit)</a>. Like <a href="http://perezmeyer.blogspot.com/2017/02/developing-nrf51822-based-embedded.html">I did with the nRF51822</a> I would love to develop software for this board using as much FLOSS tools as possible to avoid any kind of vendor lock-in.<br />
<br />
This board actually has two interesting ICs: the nRF9160 which anyone would expect and a nRF52840. At first I'm targeting the first one.<br />
<br />
The nRF9160's firmware is based on <a href="https://www.zephyrproject.org/">Zephyr</a> which uses <a href="https://cmake.org/">CMake</a>. This is great as my preferred IDE is <a href="https://en.wikipedia.org/wiki/Qt_Creator">Qt Creator</a> which has quite nice CMake integration.<br />
<br />
<h3>
Preparing the toolchain and proprietary code</h3>
<br />
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 <a href="https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF9160-DK/GetStarted#infotabs">follow the "Get started with development" section</a> 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.<br />
<br />
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.<br />
<br />
<h3>
Building the asset tracker example from the command line</h3>
<br />
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:<br />
<br />
<pre><code>mkdir build
cd build
GNUARMEMB_TOOLCHAIN_PATH="/opt/gcc-arm-none-eabi-7-2018-q2-update" \</code></pre>
<pre><code>ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb ZEPHYR_BASE="$NCS_BASE/zephyr" \</code></pre>
<pre><code>cmake -DBOARD_ROOT="$NCS_BASE/zephyr/boards/arm/nrf9160_pca10090" \</code></pre>
<pre><code>-DBOARD="nrf9160_pca10090ns" ../</code></pre>
<br />
Where NCS_BASE is the path to the previously downloaded SDK. In this case I selected the non secure version build for this board.<br />
<br />
The next step is then easy.<br />
<br />
<h3>
Building the asset tracker example from within Qt Creator</h3>
<br />
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 <a href="http://perezmeyer.blogspot.com/2017/02/developing-nrf51822-based-embedded.html">I did for the nRF51822</a>. Follow the instructions there but this time set up the new GCC version required by this development kit.<br />
<br />
The next step is to provide as much definitions as possible as part of the kit itself. Got to <b>Tools</b> → <b>Options...</b> and then to <b>Kits</b>. Select the newly created kit (I called it nRF9160) and then change "CMake Configuration" settings. The resulting text should look like:<br />
<br />
<div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<span style="font-family: "Courier New", Courier, monospace;">BOARD:STRING=nrf9160_pca10090ns</span></div>
<span style="font-family: "Courier New", Courier, monospace;">
</span><div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<span style="font-family: "Courier New", Courier, monospace;">BOARD_ROOT:STRING=path/to/ncs/zephyr/boards/arm/nrf9160_pca10090</span></div>
<span style="font-family: "Courier New", Courier, monospace;">
</span><div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<span style="font-family: "Courier New", Courier, monospace;">CMAKE_CXX_COMPILER:STRING=%{Compiler:Executable:Cxx}</span></div>
<span style="font-family: "Courier New", Courier, monospace;">
</span><div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<span style="font-family: "Courier New", Courier, monospace;">CMAKE_C_COMPILER:STRING=%{Compiler:Executable:C}</span></div>
<span style="font-family: "Courier New", Courier, monospace;">
</span><div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<span style="font-family: "Courier New", Courier, monospace;">CMAKE_PREFIX_PATH:STRING=%{Qt:QT_INSTALL_PREFIX}</span></div>
<span style="font-family: "Courier New", Courier, monospace;">
</span><div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<span style="font-family: "Courier New", Courier, monospace;">GNUARMEMB_TOOLCHAIN_PATH:STRING=/opt/gcc-arm-none-eabi-7-2018-q2-update</span></div>
<span style="font-family: "Courier New", Courier, monospace;">
</span><div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<span style="font-family: "Courier New", Courier, monospace;"></span></div>
<span style="font-family: "Courier New", Courier, monospace;">
</span><div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<span style="font-family: "Courier New", Courier, monospace;">ZEPHYR_TOOLCHAIN_VARIANT:STRING=gnuarmemb</span></div>
<div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<br /></div>
<div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
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.</div>
<div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<br /></div>
<div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
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.</div>
<div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<br /></div>
<div style="-qt-block-indent: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
That's is, you are now ready to use "Run CMake" from within the "Build" menu and you are ready to go.</div>
Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-70466601382042749062018-11-17T16:12:00.000-03:002018-11-17T16:12:44.968-03:00Using libgps instead of libQgpsmm within a Qt applicationI 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.<br />
<br />
So the next thing to do is to use libgps itself, which is written in C. In this case one needs to call <span style="font-family: "Courier New", Courier, monospace;">gps_open()</span> to open a connection, <span style="font-family: "Courier New", Courier, monospace;">gps_stream()</span> to ask for the needed stream... and use <span style="font-family: "Courier New", Courier, monospace;">gps_waiting()</span> to poll the socket for data.<br />
<span style="font-family: "Courier New", Courier, monospace;"><br /></span>
<span style="font-family: "Courier New", Courier, monospace;">gps_waiting()</span> 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.<br />
<br />
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, <span style="font-family: "Courier New", Courier, monospace;">struct gps_data_t</span>'s <span style="font-family: "Courier New", Courier, monospace;">gps_fd</span>. So the next step was to set up a QSocketNotifier around it, and use it's <span style="font-family: "Courier New", Courier, monospace;">activated()</span> signal.<br />
<br />
So (very) basically:<br />
<br />
<span style="font-family: "Courier New", Courier, monospace;">// Class private:</span><br />
<span style="font-family: "Courier New", Courier, monospace;">struct gps_data_t mGpsData; </span><br />
<span style="font-family: "Courier New", Courier, monospace;">QSocketNotifier * mNotifier;</span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br /></span>
<span style="font-family: "Courier New", Courier, monospace;">// In the implementation:</span><br />
<span style="font-family: "Courier New", Courier, monospace;">result = gps_open("localhost", DEFAULT_GPSD_PORT, &mGpsData);</span><br />
<span style="font-family: "Courier New", Courier, monospace;">// [...check result status...]</span><br />
<br />
<span style="font-family: "Courier New", Courier, monospace;">result = gps_stream(&mGPSData,WATCH_ENABLE|WATCH_JSON, NULL);</span><br />
<span style="font-family: "Courier New", Courier, monospace;">// [...check result status...]</span><br />
<br />
<span style="font-family: "Courier New", Courier, monospace;">// Set up the QSocketNotifier instance.</span><br />
<span style="font-family: "Courier New", Courier, monospace;">mNotifier = new QSocketNotifier(mGpsData.gps_fd, QSocketNotifier::Read, this); </span><br />
<br />
<span style="font-family: "Courier New", Courier, monospace;">connect(mNotifier, &QSocketNotifier::activated, this, &MyGps::readData);</span><br />
<br />
And of course, calling <span style="font-family: "Courier New", Courier, monospace;">gps_read(&mGpsData)</span> in <span style="font-family: "Courier New", Courier, monospace;">MyGps::readData()</span>. With this every time there is activity on the socket readData() will be called, an no need to set up a timer anymore.Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-80826715046743845352018-11-02T14:20:00.000-03:002018-11-02T16:04:41.682-03:00Cross compiling CMake-based projects using Ubuntu/Debian's multi archAs you probably already know Ubuntu (and then Debian) added <a href="https://wiki.debian.org/Multiarch/HOWTO">Multi-Arch support</a> quite some time ago. This means that you can install library packages from multiple architectures on the same machine.<br />
<br />
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:<br />
<br />
<pre>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.</pre>
<br />
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.<br />
<br />
My projects uses <a href="https://cmake.org/">CMake</a>, so we can cross compile by providing a suitable <a href="https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html#cross-compiling">CMAKE_TOOLCHAIN_FILE</a>.<br />
<br />
And so the first question is:<br />
<br />
<h3>
How do we create the necessary file using what Multi-Arch brings to our table?</h3>
<br />
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:<br />
<br />
Now we can run the script providing it with the desired host arch and voilá, we have our toolchain file.<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">#!/bin/sh</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"><br /></span>
<span style="font-family: "courier new" , "courier" , monospace;">#set -x</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"><br /></span>
<span style="font-family: "courier new" , "courier" , monospace;">ARCH=$1</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"><br /></span>
<span style="font-family: "courier new" , "courier" , monospace;">DEB_HOST_GNU_TYPE=$(dpkg-architecture -f "-a$1" -qDEB_HOST_GNU_TYPE)</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">DEB_HOST_GNU_CPU=$(dpkg-architecture -f "-a$1" -qDEB_HOST_GNU_CPU)</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">case "$(dpkg-architecture -f "-a$1" -qDEB_HOST_ARCH_OS)" in</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> linux) system_name=Linux; ;;</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> kfreebsd) system_name=kFreeBSD; ;;</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> hurd) system_name=GNU; ;;</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> *) exit 1; ;;</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">esac</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"><br /></span>
<span style="font-family: "courier new" , "courier" , monospace;">cat <<eof>> cmake_toolchain_$1.cmake</eof></span><br />
<span style="font-family: "courier new" , "courier" , monospace;"># Use it while calling CMake:</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"># mkdir build; cd build</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"># cmake -DCMAKE_TOOLCHAIN_FILE="../cmake_toolchain_<arch>.cmake" ../</arch></span><br />
<span style="font-family: "courier new" , "courier" , monospace;">set(CMAKE_SYSTEM_NAME "$system_name")</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">set(CMAKE_SYSTEM_PROCESSOR "$DEB_HOST_GNU_CPU")</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">set(CMAKE_C_COMPILER "$DEB_HOST_GNU_TYPE-gcc")</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">set(CMAKE_CXX_COMPILER "$DEB_HOST_GNU_TYPE-g++")</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">set(PKG_CONFIG_EXECUTABLE "$DEB_HOST_GNU_TYPE-pkg-config")</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">set(PKGCONFIG_EXECUTABLE "$DEB_HOST_GNU_TYPE-pkg-config")</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">EOF</span><br />
<h3>
<br /></h3>
<h3>
Can we improve this?</h3>
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.<br />
<br />
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.Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-20951762490641791512018-05-23T15:30:00.000-03:002018-05-23T15:30:05.902-03:00Running MPLAB X with a PickIt 3 on Debian sidDue 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.<br />
<br />
So I ran MPLAB X from a console and got:<br />
<br />
<span style="font-family: monospace;"><span style="background-color: white;">$ /opt/microchip/mplabx/v4.15/mplab_ide/bin/mplab_ide </span><br />libusb couldn't open USB device /dev/bus/usb/006/013: Permission denied.</span><br />
<br />
Yes, I rebooted my machine previous to running MPLABX (a udev restart would have been enough though) but something is not yet working.<br />
<br />
Quick and dirty solution: chmod lisandro:lisandro /dev/bus/006/013<br />
<br />
Yes, I'll have to re do this every time I plug the PickIt, but at least I've got it working.Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-25954502327636922092018-04-21T09:47:00.002-03:002018-04-21T09:50:19.205-03:00moving Qt 4 from Debian testing (aka Buster): some statistics, update IIAs in my <a href="http://perezmeyer.blogspot.com.ar/2017/11/removing-qt-4-from-debian-testing-aka.html">previous blogpost</a> I'm taking a look at our <a href="https://wiki.debian.org/Qt4Removal">Qt4 removal wiki page</a>.<br />
<br />
Of a total of 438 filed bugs:<br />
<br />
<ul>
<li>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).</li>
<li>257 bugs (58.68%) still need a fix or are fixed in experimental.</li>
<li>35 bugs (8% of the total, 13% of the remaining) of the remaining bugs are maintained inside the Qt/KDE team.</li>
</ul>
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.<br />
<br />
<h3>
So, how can you help?</h3>
If you are a maintainer of any of the packages still affected try to get upstream to make a port and package it.<br />
<br />
If you are not a maintainer you might want to take a look at the list of packages in our <a href="https://wiki.debian.org/Qt4Removal">wiki page</a> 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!<br />
<br />
<br />
<br />Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-72997785989466782352017-11-28T16:35:00.000-03:002017-11-29T15:01:35.767-03:00Experimental cross compiling Qt in Debian packages<span style="font-family: inherit;">Some time ago we the Qt/KDE team were contacted by <span style="background-color: white;">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.</span></span><br />
<span style="font-family: inherit;"><span style="background-color: white;"><br /></span></span>
<span style="font-family: inherit;"><span style="background-color: white;">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.</span></span><br />
<span style="font-family: inherit;"><span style="background-color: white;"><br /></span></span>
<span style="font-family: inherit;"><span style="background-color: white;">So we set up to discuss if somehow we could use multiarch to let debian packages using Qt to cross compile.</span></span><br />
<span style="font-family: inherit;"><span style="background-color: white;"><br /></span></span>
<span style="font-family: inherit;"><span style="background-color: white;">In the meantime Enrico Zini had the same idea. He wrote a nice summary of the situation at that time <a href="https://www.enricozini.org/blog/2017/debian/qt-cross-architecture-development-in-debian/">in his blog</a>.</span></span><br />
<span style="font-family: inherit;"><span style="background-color: white;"><br /></span></span>
<span style="background-color: white;">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.</span><br />
<span style="background-color: white;"><br /></span>
<span style="background-color: white;">Dmitry Schachnev from <a href="http://pkg-kde.alioth.debian.org/">our team</a>'s side and Helmut from the <a href="https://lists.debian.org/debian-cross">debian-cross</a> 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 <a href="https://gobby.debian.org/export/Teams/KDE/qt-cross">gobby qt-cross page</a>, 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.</span><br />
<span style="background-color: white;"><u><b><br /></b></u></span>
<span style="background-color: white;"><b>General stuff</b></span><br />
<span style="background-color: white;"><br /></span>
<span 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).</span><br />
<br />
This move needed some other touches, like qtchooser being updated with the new paths.<br />
<br />
The other changes where related to how we do our packaging:<br />
<br />
<br />
<ul>
<li>All packages containing binaries are now <a href="ps://wiki.ubuntu.com/MultiarchSpec#Binary_package_control_fields">M-A:foreign</a>.</li>
<li>Some packages (qt3d, qtwayland) had binaries split to allow that.</li>
<li>qttools5-dev-tools now depends on libqt5sql5-sqlite (not uploaded yet)</li>
</ul>
<div>
<br /></div>
<div>
<b>qmake related changes</b></div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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.</div>
<br />
<span style="font-family: inherit;"><span style="background-color: white;"><br /></span></span>
<span style="font-family: inherit;"><span style="background-color: white;"><b>autotools</b></span></span><br />
<span style="font-family: inherit;"><span style="background-color: white;"><br /></span></span>
qt5-qmake will ship /usr/bin/$(DEB_HOST_GNU_TYPE)-qmake executable for use with AC_CHECK_TOOL (not uploaded yet).<br />
<br />
There is still work to be done, but so far we have been able to cross compile packages using for example <a href="https://wiki.debian.org/CrossCompiling#Building_with_sbuild">sbuild</a>.<br />
<br />
<b>Edit 20171129 11:43 ARST:</b> You should <b>really</b> look at the new <a href="http://www.enricozini.org/blog/2017/qt-creator-cross-platform-development-in-stretch-consolidation/">Enrico's post</a>.Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-7235210264117752852017-11-24T17:21:00.002-03:002017-11-24T17:21:40.662-03:00Removing Qt 4 from Debian testing (aka Buster): some statisticsI have just looked upon our <a href="https://wiki.debian.org/Qt4Removal">Qt 4 removal wiki page</a> to see how we are doing. Out of 438 bugs filled:<br />
<br />
<ul>
<li>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.</li>
<li>3 (0.68%) packages are marked as fixed an an upload is pending.</li>
<li>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.</li>
</ul>
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!<br />
<br />
So, how can you help?<br />
<br />
If you are a maintainer of any of the packages still affected try to get upstream to make a port and package it.<br />
<br />
If you are not a maintainer you might want to take a look at the list of packages in our <a href="https://wiki.debian.org/Qt4Removal">wiki page</a> and try to create a patch for them. If you can submit it directly to upstream, the better.Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-48763291063879793952017-10-13T11:29:00.000-03:002017-10-13T11:32:06.816-03:00Qt 4 and 5 and OpenSSL1.0 removalToday we received updates on the OpenSSL 1.0 removal status:<br />
<br />
<<a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828522#206">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828522#206</a>><br />
<<a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859671#19">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859671#19</a>><br />
<br />
So those removal bugs' severities will be raised to RC in aproximately a month.<br />
<br />
We still don't have any solutions for Qt 4 or 5.<br />
<br />
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 <b>*or*</b> FTP masters decide to remove OpenSSL1.0. In this last case the fate will be the same as with Qt4, below.<br />
<br />
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:<br />
<br />
- Might cease to work.<br />
- Might keep working:<br />
- Informing their users that no SSL support is available → programmer did a good job.<br />
- Not informing their users that no SSL support is available and establishing connections non the less → programmer might have not done a good job.<br />
<br />
Trying to inform users as soon as possible,<br />
<br />
Lisandro for the Qt/KDE team.Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-4063325254722143612017-08-15T13:50:00.001-03:002017-08-15T22:47:41.109-03:00Qt 4 removal in Debian testing (Buster)/unstable<span style="font-size: x-large;">We <a href="http://perezmeyer.blogspot.com.ar/2014/11/early-announce-qt4-removal-in-jessie1.html" target="_blank">have been</a> <a href="http://perezmeyer.blogspot.com.ar/2015/05/qt4s-status-and-qt4s-webkit-removal-in.html" target="_blank">announcing</a> <a href="http://perezmeyer.blogspot.com.ar/2015/05/the-last-planned-qt-4-release-is-here.html" target="_blank">it</a>: <b>we are going to remove Qt 4</b> during the Buster cycle.</span><br />
<br />
Or at least that's the best outcome we can expect. Removing a very highly used library is hard, as <a href="https://wiki.debian.org/Qt4WebKitRemoval" target="_blank">Qt4's Webkit has proved</a>. 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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
We will soon start filing bugs against packages using Qt 4. I'll update this blog post later to add that info.<br />
<br />
For the Qt/KDE team, Lisandro.Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-18507467510713580312017-06-24T19:41:00.000-03:002017-07-16T18:27:29.142-03:00Qt 5.7 submodules that didn't make it to Stretch but will be in testingThere 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 <a href="https://anonscm.debian.org/cgit/pkg-kde/qt/qtdeclarative-render2d.git/" target="_blank">qtdeclarative-render2d-plugin</a> and <a href="https://anonscm.debian.org/cgit/pkg-kde/qt/qtvirtualkeyboard.git/" target="_blank">qtvirtualkeyboard</a>.<br />
<br />
<b>declarative-render2d-plugin</b> 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 <i>/etc/X11/Xsession.d/90qt5-opengl</i>. 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.<br />
<br />
Debian's <b>VirtualKeyboard</b> 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 <a href="https://bugreports.qt.io/browse/QTBUG-59594" target="_blank">QTBUG-59594</a>, patches are welcomed. Please <b>note</b> that we prefer patches sent directly upstream to the current dev revision, we will be happy to backport patches if necessary.<br />
Yes, this means no hunspell, openwnn, pinyin, tcime nor lipi-toolkit/t9write support.<br />
<br />
<b>Note 2017-07-16:</b> please use 5.7.1+dfsg-2, it fixes a wrong dependency and adds use of the system's hunspell.Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-7557555465564813962017-02-22T10:18:00.001-03:002017-03-28T10:54:58.854-03:00Developing an nrf51822 based embedded device with Qt Creator and DebianI'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.<br />
<br />
There are already two quite interesting blog posts about using Qt Creator <a href="https://devzone.nordicsemi.com/blogs/702/debugging-using-qtcreator-on-mac/">on MAC</a> and <a href="http://morf.lv/starting-with-nrf51-ble-and-qt-creator">on Windows</a>, so I will not repeat the basics, as they are there. Both use qbs, but I managed to use CMake.<br />
<br />
Instead I'll add some tips on the stuff that I needed to solve in order to make this happen on current Debian Sid.<br />
<br />
<br />
<ul>
<li>The required toolchain is already in Debian, just install <span style="background-color: white;">binutils-arm-none-eabi, </span><span style="background-color: white;">gcc-arm-none-eabi and </span><span style="background-color: white;">gdb-arm-none-eabi.</span></li>
<li><span style="background-color: white;">You will not find arm-none-eabi-gdb-py on the </span>gdb-arm-none-eabi package. Fear not, the provided gdb binary is compiled against python so it will work.</li>
<li>To enable proper debugging be sure to follow <a href="https://devzone.nordicsemi.com/question/116587/debugging-with-breakpoints-correct-gcc-flags/">this flag setup</a>. If you are using CMake like <a href="https://github.com/thomsten/nrf-blinky">in this example</a> be sure to modify <span style="background-color: white;">CMake/toolchain_gcc.cmake as necessary.</span></li>
<li><span style="background-color: white;">In Qt Creator you might find that, while try to run or debug your app, you are greated with a message box that says </span><span 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.</span></li>
</ul>
<div>
<br /></div>
<div>
Cheers!</div>
Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-31866087956657410872016-07-17T20:15:00.001-03:002016-07-18T08:59:57.664-03:00KDEPIM ready to be more broadly testedAs was posted <a href="http://perezmeyer.blogspot.com/2016/07/upcoming-kdepim-changes-in-unstable.html">a couple of weeks ago</a>, the latest version of KDEPIM has been uploaded to unstable.<br />
<br />
All packages are now uploaded and built and we believe this version is ready to be more broadly tested.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Happy hacking,<br />
<br />
The Debian Qt/KDE Team.<br />
<b><br /></b>
<span style="font-family: inherit;"><b>Note </b><span style="background-color: white;"><b>lun jul 18 08:58:53 ART 2016:</b> Link fixed and s/KDE/KDEPIM/.</span></span>Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com1tag:blogger.com,1999:blog-6357172297737057475.post-34955777766937783002016-07-02T21:38:00.000-03:002016-07-02T21:38:47.901-03:00Upcoming KDEPIM changes in unstable (KMail, Kontact, KOrganizer, etc)For those who care about kdepim (kmail, kontact, korganizer, etc)<br />
<br />
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).<br />
<br />
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 <b>we will drop them after stretch</b> unless they get new upstream maintainers.<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
A list of the binary packages involved in the transition can be found <a href="https://wiki.debian.org/KDE/PIM/16.04_transition">[here]</a>.<br />
<br />
If you find issues in the new packages, please let us know either via irc in #debian-kde, the kde mailing list <a href="mailto:debian-kde@lists.debian.org">debian-kde@lists.debian.org</a>, or <a href="https://wiki.debian.org/reportbug">send us a bug report</a> (please make sure that it wasn't reported before).<br />
<br />
We'll send an updated note when kdepim is fully uploaded to unstable.<br />
<br />
Happy hacking,<br />
<div>
<br /></div>
<div>
The Debian Qt/KDE Team.</div>
Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-73287413865282592802016-05-26T11:51:00.003-03:002016-05-26T16:01:08.346-03:00Do you want Qt5's QWebEngine in Debian? Do you have library packaging skills? If so, step up!So far the only missing submodule in Debian's Qt5 stack is <a href="http://doc.qt.io/qt-5/qtwebengine-index.html">QtWebEngine</a>. None of us the current Qt maintainers have the time/will to do the necessary stuff to have it properly packaged.<br />
<br />
So if you would like to have QtWebEngine in Debian and:<br />
<br />
<ul>
<li>You have C++ libraries' packaging skills.</li>
<li>You have a powerful enough machine/enough patience to do the necessary builds (8+ GB RAM+swap required).</li>
<li>You are willing to deal with 3rd party embedded software.</li>
<li>You are willing to keep up with security fixes.</li>
<li>You are accessible through IRC and have the necessary communications skills to work together with the rest of the team.</li>
</ul>
<div>
Then you are the right person for this task. Do not hesitate in pinging me on #debian-kde, irc.oftc.net.</div>
Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-49771503438316865492015-09-05T20:42:00.000-03:002015-09-05T20:42:47.252-03:00Important Akonadi fix in today's Debian Jessie's update (aka 8.2)Todays Debian Jessie's update brings a fix in Akonadi that you certainly want in your system.<br />
<br />
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.<br />
<br />
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:<br />
<br />
<span style="font-family: "Courier New",Courier,monospace;"> akonadictl fsck</span><br />
<br />
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.Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-41215385760398996952015-07-31T11:31:00.004-03:002015-07-31T11:31:38.783-03:00plasma-desktop should enter testing today once the mirrors have caught up
<style type="text/css">
p, li { white-space: pre-wrap; }
</style>
<br />
<div style="-qt-block-indent: 0; -qt-user-state: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
Exactly what the subject says: plasma-desktop has migrated to testing, it will be there as soon as the mirrors are synced.</div>
<div style="-qt-block-indent: 0; -qt-paragraph-type: empty; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<br /></div>
<div style="-qt-block-indent: 0; -qt-user-state: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
It is highly recommended for those in testing to upgrade today, although you might need to wait your mirror.</div>
<div style="-qt-block-indent: 0; -qt-paragraph-type: empty; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<br /></div>
<div style="-qt-block-indent: 0; -qt-user-state: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
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 <b>**huge**</b> transition.</div>
<div style="-qt-block-indent: 0; -qt-paragraph-type: empty; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<br /></div>
<div style="-qt-block-indent: 0; -qt-user-state: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
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 <b>**highly**</b> appreciated.</div>
<div style="-qt-block-indent: 0; -qt-paragraph-type: empty; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
<br /></div>
<div style="-qt-block-indent: 0; -qt-user-state: 0; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-indent: 0px;">
Once again, sorry for the inconveniences!</div>
Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-32873916468033622482015-07-28T12:19:00.000-03:002015-07-28T12:19:12.992-03:00Plasma/KF5 : Testing situationDear Debian/KDE users,<br />
<br />
We are aware that the current situation in testing is very unfortunate, with two main issues:<br />
<br />
<ol>
<li><b>systemsettings transitioned to testing before the corresponding KDE Control Modules.</b> The result is that systemsettings displays an empty screen. This is tracked in the following bug <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790703">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790703</a>.</li>
<li><b>plasmoids such as plasma-nm transitioned to testing before plasma-desktop 5.</b> The result is that the plasmoid are no longer displayed in the system tray.</li>
</ol>
<br />
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.<br />
<br />
On behalf of the Qt/KDE team,<br />
Lisandro.Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-57921744427332589882015-05-26T13:36:00.000-03:002015-05-26T13:36:46.388-03:00The last planned Qt 4 release is here: Qt 4.8.7. Is your app runnning with Qt5?Qt 4.8.7 <a href="https://blog.qt.io/blog/2015/05/26/qt-4-8-7-released/" target="_blank">has been released today</a>. Quoting from the blog post (emphasis is mine):<br />
<br />
<blockquote class="tr_bq">
<div style="text-align: left;">
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, <b>we have ensured that switching to Qt 5 is smooth and straightforward</b>. It should be noted that Qt 4.8.7 provides <b>only the basic functionality</b> to run Qt based applications on Mac OS X 10.10, full support is in Qt 5.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Qt 4.8.7 is planned to be <b>the last patch release of the Qt 4 series</b>. Standard support is available until December 2015, after which extended support will be available. We recommend all active projects to migrate to Qt 5, <b>as new operating systems and compilers with Qt 4.8 will not be supported</b>. If you have challenges migrating to Qt 5, please contact us or some of our service partners for assistance</div>
</blockquote>
<br />Have you started to port your project?<br />
Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com0tag:blogger.com,1999:blog-6357172297737057475.post-20372799929177125072015-05-01T14:05:00.000-03:002015-05-01T14:05:53.963-03:00Qt4's status and Qt4's webkit removal in StretchHi 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.<br />
<br />
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.<br />
<br />
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 <b>**hypothetical**</b> 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.<br />
<br />
<h2>
<b><u>Qt4's webkit removal</u></b></h2>
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.<br />
<br />
<h2>
<b><u>Porting</u></b></h2>
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.<br />
<br />
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.<br />
<br />
Don't forget to take a look at the C++ API changes page [1] whenever you start porting your application.<br />
<br />
[0] <a href="http://pkg-kde.alioth.debian.org/packagingqtstuff.html">http://pkg-kde.alioth.debian.org/packagingqtstuff.html</a><br />
[1] <a href="http://doc.qt.io/qt-5/sourcebreaks.html">http://doc.qt.io/qt-5/sourcebreaks.html</a><br />
<br />
<h2>
<b><u>Temporarily shipping both Qt4 and Qt5 builds of your library</u></b></h2>
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.<br />
<br />
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.<br />
<br />
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<br />
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].<br />
<br />
[2] irc.debian.org #debian-kde<br />
[3] debian-kde@lists.debian.org<br />
<br />
<h2>
<b><u>Timeline</u></b></h2>
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.Lisandro Damián Nicanor Pérez Meyerhttp://www.blogger.com/profile/09966442884730426878noreply@blogger.com1