Last week we held our promised miniDebConf in Santa Fe City, Santa Fe province, Argentina just across the river from Paran , where I have spent almost six beautiful months I will never forget. Around 500 Kilometers North from Buenos Aires, Santa Fe and Paran are separated by the beautiful and majestic Paran river, which flows from Brazil, marks the Eastern border of Paraguay, and continues within Argentina as the heart of the litoral region of the country, until it merges with the Uruguay river (you guessed right the river marking the Eastern border of Argentina, first with Brazil and then with Uruguay), and they become the R o de la Plata. This was a short miniDebConf: we were lent the APUL union s building for the weekend (thank you very much!); during Saturday, we had a cycle of talks, and on sunday we had more of a hacklab logic, having some unstructured time to work each on their own projects, and to talk and have a good time together. We were five Debian people attending: santiago debacle eamanu dererk gwolf @debian.org. My main contact to kickstart organization was Mart n Bayo. Mart n was for many years the leader of the Technical Degree on Free Software at Universidad Nacional del Litoral, where I was also a teacher for several years. Together with Leo Mart nez, also a teacher at the tecnicatura, they contacted us with Guillermo and Gabriela, from the APUL non-teaching-staff union of said university. We had the following set of talks (for which there is a promise to get electronic record, as APUL was kind enough to record them! of course, I will push them to our usual conference video archiving service as soon as I get them)

Hour	Title (Spanish)	Title (English)	Presented by
10:00-10:25	Introducci n al Software Libre	Introduction to Free Software	Mart n Bayo
10:30-10:55	Debian y su comunidad	Debian and its community	Emanuel Arias
11:00-11:25	Por qu sigo contribuyendo a Debian despu s de 20 a os?	Why am I still contributing to Debian after 20 years?	Santiago Ruano
11:30-11:55	Mi identidad y el proyecto Debian: Qu es el llavero OpenPGP y por qu ?	My identity and the Debian project: What is the OpenPGP keyring and why?	Gunnar Wolf
12:00-13:00	Explorando las masculinidades en el contexto del Software Libre	Exploring masculinities in the context of Free Software	Gora Ortiz Fuentes - Jos Francisco Ferro
13:00-14:30	Lunch
14:30-14:55	Debian para el d a a d a	Debian for our every day	Leonardo Mart nez
15:00-15:25	Debian en las Raspberry Pi	Debian in the Raspberry Pi	Gunnar Wolf
15:30-15:55	Device Trees	Device Trees	Lisandro Dami n Nicanor Perez Meyer (videoconferencia)
16:00-16:25	Python en Debian	Python in Debian	Emmanuel Arias
16:30-16:55	Debian y XMPP en la medici n de viento para la energ a e lica	Debian and XMPP for wind measuring for eolic energy	Martin Borgert

As it always happens DebConf, miniDebConf and other Debian-related activities are always fun, always productive, always a great opportunity to meet again our decades-long friends. Lets see what comes next!

Review: Nettle & Bone, by T. Kingfisher

Publisher:	Tor
Copyright:	2022
ISBN:	1-250-24403-X
Format:	Kindle
Pages:	242

Nettle & Bone is a standalone fantasy novel with fairy tale vibes. T. Kingfisher is a pen name for Ursula Vernon. As the book opens, Marra is giving herself a blood infection by wiring together dog bones out of a charnel pit. This is the second of three impossible tasks that she was given by the dust-wife. Completing all three will give her the tools to kill a prince. I am a little cautious of which T. Kingfisher books I read since she sometimes writes fantasy and sometimes writes horror and I don't get along with horror. This one seemed a bit horrific in the marketing, so I held off on reading it despite the Hugo nomination. It turns out to be just on the safe side of my horror tolerance, with only a couple of parts that I read a bit quickly. One of those is the opening, which I am happy to report does not set the tone for the rest of the book. Marra starts the story in a wasteland full of disease, madmen, and cannibals (who, in typical Ursula Vernon fashion, turn out to be nicer than the judgmental assholes outside of the blistered land). She doesn't stay there long. By chapter two, the story moves on to flashbacks explaining how Marra ended up there, alternating with further (and less horrific) steps in her quest to kill the prince of the Northern Kingdom. Marra is a princess of a small, relatively poor coastal kingdom with a good harbor and acquisitive neighbors. Her mother, the queen, has protected the kingdom through arranged marriage of her daughters to the prince of the Northern Kingdom, who rules it in all but name given the mental deterioration of his father the king. Marra's eldest sister Damia was first, but she died suddenly and mysteriously in a fall. (If you're thinking about the way women are injured by "accident," you have the right idea.) Kania, the middle sister, is next to marry; she lives, but not without cost. Meanwhile, Marra is sent off to a convent to ensure that there are no complicating potential heirs, and to keep her on hand as a spare. I won't spoil the entire backstory, but you do learn it all. Marra is a typical Kingfisher protagonist: a woman who is way out of her depth who persists with stubbornness, curiosity, and innate decency because what else is there to do? She accumulates the typical group of misfits and oddballs common in Kingfisher's quest fantasies, characters that in the Chosen One male fantasy would be supporting characters at best. The bone-wife is a delight; her chicken is even better. There are fairy godmothers and a goblin market and a tooth extraction that was one of the creepiest things I've read without actually being horror. It is, in short, a Kingfisher fantasy novel, with a touch more horror than average but not enough to push it out of the fantasy genre. I think my favorite part of this book was not the main quest. It was the flashback scenes set in the convent, where Marra has the space (and the mentorship) to develop her sense of self.

"We're a mystery religion," said the abbess, when she'd had a bit more wine than usual, "for people who have too much work to do to bother with mysteries. So we simply get along as best we can. Occasionally someone has a vision, but [the goddess] doesn't seem to want anything much, and so we try to return the favor."

If you have read any other Kingfisher novels, much of this will be familiar: the speculative asides, the dogged determination, the slightly askew nature of the world, the vibes-based world-building that feels more like a fairy tale than a carefully constructed magic system, and the sense that the main characters (and nearly all of the supporting characters) are average people trying to play the hands they were dealt as ethically as they can. You will know that the tentative and woman-initiated romance is coming as soon as the party meets the paladin type who is almost always the romantic interest in one of these books. The emotional tone of the book is a bit predictable for regular readers, but Ursula Vernon's brain is such a delightful place to spend some time that I don't mind.

Marra had not managed to be pale and willowy and consumptive at any point in eighteen years of life and did not think she could achieve it before she died.

Nettle & Bone won the Hugo for Best Novel in 2023. I'm not sure why this specific T. Kingfisher novel won and not any of the half-dozen earlier novels she's written in a similar style, but sure, I have no objections. I'm glad one of them won; they're all worth reading and hopefully that will help more people discover this delightful style of fantasy that doesn't feel like what anyone else is doing. Recommended, although be prepared for a few more horror touches than normal and a rather grim first chapter. Content warnings: domestic abuse. The dog... lives? Is equally as alive at the end of the book as it was at the end of the first chapter? The dog does not die; I'll just leave it at that. (Neither does the chicken.) Rating: 8 out of 10

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 :-)

Meeting Debian people for having a good time together, for some good hacking, for learning, for teaching Is always fun and welcome. It brings energy, life and joy. And this year, due to the six-months-long relocation my family and me decided to have to Argentina, I was unable to attend the real deal, DebConf23 at India. And while I know DebConf is an experience like no other, this year I took part in two miniDebConfs. One I have already shared in this same blog: I was in MiniDebConf Tamil Nadu in India, followed by some days of pre-DebConf preparation and scouting in Kochi proper, where I got to interact with the absolutely great and loving team that prepared DebConf. The other one is still ongoing (but close to finishing). Some months ago, I talked with Santiago Ruano, jokin as we were Spanish-speaking DDs announcing to the debian-private mailing list we d be relocating to around R o de la Plata. And things worked out normally: He has been for several months in Uruguay already, so he decided to rent a house for some days, and invite Debian people to do what we do best. I left Paran Tuesday night (and missed my online class at UNAM! Well, you cannot have everything, right?). I arrived early on Wednesday, and around noon came to the house of the keysigning (well, the place is properly called Casa Key , it s a publicity agency that is also rented as a guesthouse in a very nice area of Montevideo, close to Nuevo Pocitos beach). In case you don t know it, Montevideo is on the Northern (or Eastern) shore of R o de la Plata, the widest river in the world (up to 300Km wide, with current and non-salty water). But most important for some Debian contributors: You can even come here by boat! That first evening, we received Ilu, who was in Uruguay by chance for other issues (and we were very happy about it!) and a young and enthusiastic Uruguayan, Felipe, interested in getting involved in Debian. We spent the evening talking about life, the universe and everything Which was a bit tiring, as I had to interface between Spanish and English, talking with two friends that didn t share a common language On Thursday morning, I went out for an early walk at the beach. And lets say, if only just for the narrative, that I found a lost penguin emerging from R o de la Plata! For those that don t know (who d be most of you, as he has not been seen at Debian events for 15 years), that s Lisandro Dami n Nicanor P rez Meyer (or just lisandro), long-time maintainer of the Qt ecosystem, and one of our embedded world extraordinaires. So, after we got him dry and fed him fresh river fishes, he gave us a great impromptu talk about understanding and finding our way around the Device Tree Source files for development boards and similar machines, mostly in the ARM world. From Argentina, we also had Emanuel (eamanu) crossing all the way from La Rioja. I spent most of our first workday getting my laptop in shape to be useful as the driver for my online class on Thursday (which is no small feat people that know the particularities of my much loved ARM-based laptop will understand), and running a set of tests again on my Raspberry Pi labortory, which I had not updated in several months. I am happy to say we are also finally also building Raspberry images for Trixie (Debian 13, Testing)! Sadly, I managed to burn my USB-to-serial-console (UART) adaptor, and could neither test those, nor the oldstable ones we are still building (and will probably soon be dropped, if not for anything else, to save disk space). We enjoyed a lot of socialization time. An important highlight of the conference for me was that we reconnected with a long-lost DD, Eduardo Tr pani, and got him interested in getting involved in the project again! This second day, another local Uruguayan, Mauricio, joined us together with his girlfriend, Alicia, and Felipe came again to hang out with us. Sadly, we didn t get photographic evidence of them (nor the permission to post it). The nice house Santiago got for us was very well equipped for a miniDebConf. There were a couple of rounds of pool played by those that enjoyed it (I was very happy just to stand around, take some photos and enjoy the atmosphere and the conversation). Today (Saturday) is the last full-house day of miniDebConf; tomorrow we will be leaving the house by noon. It was also a very productive day! We had a long, important conversation about an important discussion that we are about to present on debian-vote@lists.debian.org. It has been a great couple of days! Sadly, it s coming to an end But this at least gives me the opportunity (and moral obligation!) to write a long blog post. And to thank Santiago for organizing this, and Debian, for sponsoring our trip, stay, foods and healthy enjoyment!

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!

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!

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.

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!

The OpenSSH project added support for a hybrid Streamlined NTRU Prime post-quantum key encapsulation method sntrup761 to strengthen their X25519-based default in their version 8.5 released on 2021-03-03. While there has been a lot of talk about post-quantum crypto generally, my impression has been that there has been a slowdown in implementing and deploying them in the past two years. Why is that? Regardless of the answer, we can try to collaboratively change things, and one effort that appears strangely missing are IETF documents for these algorithms. Building on some earlier work that added X25519/X448 to SSH, writing a similar document was relatively straight-forward once I had spent a day reading OpenSSH and TinySSH source code to understand how it worked. While I am not perfectly happy with how the final key is derived from the sntrup761/X25519 secrets it is a SHA512 call on the concatenated secrets I think the construct deserves to be better documented, to pave the road for increased confidence or better designs. Also, reusing the RFC5656 4 structs makes for a worse specification (one unnecessary normative reference), but probably a simpler implementation. I have published draft-josefsson-ntruprime-ssh-00 here. Credit here goes to Jan Moj of TinySSH that designed the earlier sntrup4591761x25519-sha512@tinyssh.org in 2018, Markus Friedl who added it to OpenSSH in 2019, and Damien Miller that changed it to sntrup761 in 2020. Does anyone have more to add to the history of this work? Once I had sharpened my xml2rfc skills, preparing a document describing the hybrid construct between the sntrup761 key-encapsulation mechanism and the X25519 key agreement method in a non-SSH fashion was easy. I do not know if this work is useful, but it may serve as a reference for further study. I published draft-josefsson-ntruprime-hybrid-00 here. Finally, how about a IETF document on the base Streamlined NTRU Prime? Explaining all the details, and especially the math behind it would be a significant effort. I started doing that, but realized it is a subjective call when to stop explaining things. If we can t assume that the reader knows about lattice math, is a document like this the best place to teach it? I settled for the most minimal approach instead, merely giving an introduction to the algorithm, included SageMath and C reference implementations together with test vectors. The IETF audience rarely understands math, so I think it is better to focus on the bits on the wire and the algorithm interfaces. Everything here was created by the Streamlined NTRU Prime team, I merely modified it a bit hoping I didn t break too much. I have now published draft-josefsson-ntruprime-streamlined-00 here. I maintain the IETF documents on my ietf-ntruprime GitLab page, feel free to open merge requests or raise issues to help improve them. To have confidence in the code was working properly, I ended up preparing a branch with sntrup761 for the GNU-project Nettle and have submitted it upstream for review. I had the misfortune of having to understand and implement NIST s DRBG-CTR to compute the sntrup761 known-answer tests, and what a mess it is. Why does a deterministic random generator support re-seeding? Why does it support non-full entropy derivation? What s with the key size vs block size confusion? What s with the optional parameters? What s with having multiple algorithm descriptions? Luckily I was able to extract a minimal but working implementation that is easy to read. I can t locate DRBG-CTR test vectors, anyone? Does anyone have sntrup761 test vectors that doesn t use DRBG-CTR? One final reflection on publishing known-answer tests for an algorithm that uses random data: are the test vectors stable over different ways to implement the algorithm? Just consider of some optimization moved one randomness-extraction call before another, then wouldn t the output be different? Are there other ways to verify correctness of implementations? As always, happy hacking!

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!

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: Where $arch can be any of the Debian supported architectures, like arm64 (aka aarch64): 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: That's it, we can now start cross building our cmake-based software.

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 :-)

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.

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.

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 beginningWhen 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 main screen

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$.

- 500 AR$ (less than 8 US$)

- 1000 AR$ (less than 15 US$)

- 2000 AR$ (less than 30 US$)

- 3000 AR$ (less than 45 US$)

- 5000 AR$ (less than 75 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.

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**

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.

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.

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.

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, gcc-arm-none-eabi and 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. 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 "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.