tl;dr: use a serial terminal which can buffer input and send it all at once, lines should end with \CR\LF.
I'm am currently working on bringing up a LoRa network in Bahía Blanca. Parts of the nodes I need to set up are made by RAK Wireless.
According to their documentation the nodes can be configured by using a serial connection to them. So I quickly turned to minicom for it, with no avail. Somehow I could read whatever the device was writing to my machine but could not write any commands back to it.
In order to get the issue solved I switched to running their RAK serial port tool under wine. Making it work made me download and install a huge amount of Windows libraries and tools, but in the end I wanted a Linux-only solution.
After much digging the web, trial and error I've found a way to solve this:
Commands should end with \CR\LF.
The command needs to be sent quickly, all in one go, trough the serial port. This means it can't be typed and sent as normal serial consoles.
The solution for (1) in minicom is easy, but I don't know if minicom is capable of doing the buffering thing, so I went to use cutecom, for which one has to enter the input and send it all at once.
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 beginning
When the pandemic reached Argentina the government started a quarantine. We engineers (like engineers around the world) started to think on how to put our abilities in order to help with the situation. Some worked toward providing more protection elements to medical staff, some towards increasing the number of ventilation machines at disposal. Another group of people started thinking on another ways of helping. In Bahía Blanca arised the idea of monitoring some variables remotely and in masse.
Simplified Monitoring of Patients in Situations of Mass Hospitalization (MoSimPa)
This is where the idea of remotely monitored devices came in, and MoSimPa (from the spanish of "monitoreo simplificado de pacientes en situación de internación masiva") started to get form. The idea is simple: oximetry (SpO2), heart rate and body temperature will be recorded and, instead of being shown in a display in the device itself, they will be transmitted and monitored in one or more places. In this way medical staff doesn't has to reach a patient constantly and monitoring could be done by medical staff for more patients at the same time. In place monitoring can also happen using a cellphone or tablet.
The devices do not have a screen of their own and almost no buttons, making them more cheap to build and thus more in line with the current economic reality of Argentina.
This is where the project Para Ayudar was created. The project aims to produce the aforementioned non-invasive device to be used in health institutions, hospitals, intra hospital transports and homes.
It is worth to note that the system is designed as a complementary measure for continuous monitoring of a pacient. Care should be taken to check that symptomps and overall patient status don't mean an inmediate life threat. In other words, it is NOT designed for ICUs.
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.
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.
I was in need of creating a Qt application using current Debian stable (Stretch) and gpsd. I could have used libQgpsmm which creates a QTcpSocket for stablishing the connection to the gpsd daemon. But then I hit an issue: libQgpsmm was switched to Qt 5 after the Strech release, namely in gpsd 3.17-4. And I'm using Qt 5.
So the next thing to do is to use libgps itself, which is written in C. In this case one needs to call gps_open() to open a connection, gps_stream() to ask for the needed stream... and use gps_waiting() to poll the socket for data. gps_waiting() checks for data for a maximum of time specified in it's parameters. That means I would need to create a QTimer and poll it to get the data. Poll it fast enough for the application to be responsive, but not too excessively to avoid useless CPU cycles.
I did not like this idea, so I started digging gpsd's code until I found that it exposes the socket it uses in it's base struct, struct gps_data_t's gps_fd. So the next step was to set up a QSocketNotifier around it, and use it's activated() signal.
So (very) basically:
// Class private: struct gps_data_t mGpsData; QSocketNotifier * mNotifier; // In the implementation: result = gps_open("localhost", DEFAULT_GPSD_PORT, &mGpsData); // [...check result status...]
result = gps_stream(&mGPSData,WATCH_ENABLE|WATCH_JSON, NULL); // [...check result status...]
// Set up the QSocketNotifier instance. mNotifier = new QSocketNotifier(mGpsData.gps_fd, QSocketNotifier::Read, this);
And of course, calling gps_read(&mGpsData) in MyGps::readData(). With this every time there is activity on the socket readData() will be called, an no need to set up a timer anymore.
As you probably already know Ubuntu (and then Debian) added Multi-Arch support quite some time ago. This means that you can install library packages from multiple architectures on the same machine.
Thanks to the work of many people, in which I would like to specially mention Helmut Grohne, we are now able to cross compile Debian packages using standard sbuild chroots. He even was kind enough to provide me with some numbers:
We have 28790 source packages in Debian unstable.
Of those, 13358 (46.3%) build architecture-dependent binary packages.
Of those, 7301 (54.6%) have satisfiable cross Build-Depends.
Of those, 3696 (50.6% of buildable, 27.6% of sources) were attempted.
Of those, 2695 (72.9% of built, 36.9% of buildable, 20.1% of sources) were successful.
633 bugs affecting 772 packages (7.23% of 10663 unsuccessful) are reported.
Now I asked myself if I could use this to cross compile the code I'm working on without the need of doing a full Debian package build.
Helmut mentioned that meson provides debcrossgen, a script that automates this step. Meson is written in python, so it only needs to know the host architecture to create the necessary definitions.
CMake is not interpreted, but maybe it has a way to know the host arch in advance. If this is true maybe a helper could be added to help in the process. Ideas (or even better, patches/code!) welcomed.
181 bugs (41.32%) have been already fixed by either porting the app/library to Qt 5 or a removal from the archive has happened. On most cases the code has been ported and most of the deletions are due to Qt 5 replacements already available in the archive and some due to dead upstreams (ie., no Qt5 port available).
257 bugs (58.68%) still need a fix or are fixed in experimental.
35 bugs (8% of the total, 13% of the remaining) of the remaining bugs are maintained inside the Qt/KDE team.
We started filing bugs around September 9. That means roughly 32 weeks which gives us around 5.65 packages fixed per week, aka 0.85 packages per day. Obviously not as good as we started (remaining bugs tend to be more complicated), but still quite good.
So, how can you help?
If you are a maintainer of any of the packages still affected try to get upstream to make a port and package it.
If you are not a maintainer you might want to take a look at the list of packages in our wiki page and try to create a patch for them. If you can submit it directly to upstream, the better. Or maybe it's time for you to become the package's upstream or maintainer!
Some time ago we the Qt/KDE team were contacted by Helmut Grohne. He was trying to cross compile Debian packages in general thanks to Ubuntu/Debian's multi-arch support, and he was having problems with Qt-based ones. 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. So we set up to discuss if somehow we could use multiarch to let debian packages using Qt to cross compile. In the meantime Enrico Zini had the same idea. He wrote a nice summary of the situation at that time in his blog. 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. Dmitry Schachnev from our team's side and Helmut from the debian-cross side worked a lot on it, and I would like to present what they have done. To be fair it's mostly described in our team's gobby qt-cross page, but I would like to give it some publicity in order to let people know about it and why not, find and help solving bugs. General stuff The first thing that was done was to move Qt binaries from their (Debian original) multi-arch path to a non multi-arch one, providing symlinks for compatibility. In this way the path of the binaries is the same for any arch (why they were not there is a long story, but nothing to worry now).
This move needed some other touches, like qtchooser being updated with the new paths.
The other changes where related to how we do our packaging:
All packages containing binaries are now M-A:foreign.
Some packages (qt3d, qtwayland) had binaries split to allow that.
qttools5-dev-tools now depends on libqt5sql5-sqlite (not uploaded yet)
qmake related changes
We also needed to address qmake. To begin with we splitted the package containing it into qt5-qmake-bin (M-A:foreign) and qt5-qmake (M-A:same). The first one has the binaries and the second the relevant mkspecs for some arch.
The rest of the "magic" comes from debhelper. It generates a qt.conf file with the right paths for each cross compilation and also passes cross QMAKE_CC and QMAKE_CXX to qmake when needed.
autotools
qt5-qmake will ship /usr/bin/$(DEB_HOST_GNU_TYPE)-qmake executable for use with AC_CHECK_TOOL (not uploaded yet).
There is still work to be done, but so far we have been able to cross compile packages using for example sbuild.
Edit 20171129 11:43 ARST: You should really look at the new Enrico's post.
I have just looked upon our Qt 4 removal wiki page to see how we are doing. Out of 438 bugs filled:
88 (20.09%) have been already fixed by either porting the app/library to Qt 5 or a removal from the archive has happened. On most cases the code has been ported and most of the deletions are due to Qt 5 replacements already available in the archive and a few due to dead upstreams.
3 (0.68%) packages are marked as fixed an an upload is pending.
65 (14.84%) of the open bugs are maintained inside the Qt/KDE team. Many of them should get a Qt 5 version with the next KF5 uploads.
We started filing bugs around September 9. That means roughly 11 weeks, which gives us around 8 packages fixed a week, aka 1.14 packages per day. Not bad at all!
So, how can you help?
If you are a maintainer of any of the packages still affected try to get upstream to make a port and package it.
If you are not a maintainer you might want to take a look at the list of packages in our wiki page and try to create a patch for them. If you can submit it directly to upstream, the better.
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.
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.
There are two Qt 5.7 submodules that we could not package in time for Strech but are/will be available in their 5.7 versions in testing. This are qtdeclarative-render2d-plugin and qtvirtualkeyboard.
declarative-render2d-plugin makes use of the Raster paint engine instead of OpenGL to render the contents of a scene graph, thus making it useful when Qt Quick2 applications are run in a system without OpenGL 2 enabled hardware. Using it might require tweaking Debian's /etc/X11/Xsession.d/90qt5-opengl. On Qt 5.9 and newer this plugin is merged in Qt GUI so there should be no need to perform any action on the user's behalf.
Debian's VirtualKeyboard currently has a gotcha: we are not building it with the embedded code it ships. Upstream ships 3rd party code but lacks a way to detect and use the system versions of them. See QTBUG-59594, patches are welcomed. Please note that we prefer patches sent directly upstream to the current dev revision, we will be happy to backport patches if necessary.
Yes, this means no hunspell, openwnn, pinyin, tcime nor lipi-toolkit/t9write support.
Note 2017-07-16: please use 5.7.1+dfsg-2, it fixes a wrong dependency and adds use of the system's hunspell.
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.
As was posted a couple of weeks ago, the latest version of KDEPIM has been uploaded to unstable.
All packages are now uploaded and built and we believe this version is ready to be more broadly tested.
If you run unstable but have refrained from installing the kdepim packages up to now, we would appreciate it if you go ahead and install them now, reporting any issues that you may find.
Given that this is a big update that includes quite a number of plugins and libraries, it's strongly recommended that you restart your KDE session after updating the packages.
Happy hacking,
The Debian Qt/KDE Team. Note lun jul 18 08:58:53 ART 2016: Link fixed and s/KDE/KDEPIM/.
For those who care about kdepim (kmail, kontact, korganizer, etc)
Currently the latest version of kdepim is available in experimental. According to our limited tests it's working way better than kdepim 4.14 (more stable, more performant, less bugs). However migrating from one to the other is not a trivial process (distribution wise, hopefully not for our users).
Among the drawbacks in the new kdepim: knode, ktimetracker and kjots were dropped from the official kdepim components. kjots is now an independent project, not tied to the kdepim release cycle. But more importantly, knode and ktimetracker are not maintained upstream any more, we are temporarily still shipping the old KDE 4 versions, but we will drop them after stretch unless they get new upstream maintainers.
To iron out the wrinkles that are surely still there, we are now planning to start a transition for kdepim, effectively blocking all kdepim related packages in unstable until the transition is complete. This will allow us to keep the current kdepim in testing unchanged until kdepim 16.04 is ready to migrate fully to testing.
If you want to test the new kdepim versions right now, please use the version in experimental, as uploading all the packages to unstable will take some time until there is a working kdepim in unstable (mixing experimental and the unstable uploads should be fine).
If you depend on having a working kdepim, please avoid installing the new kdepim packages that will be landing in unstable in the following days, until all the components are available. We expect this will take a couple of weeks, we will post another entry when the packages are ready in unstable.
A list of the binary packages involved in the transition can be found [here].
If you find issues in the new packages, please let us know either via irc in #debian-kde, the kde mailing list debian-kde@lists.debian.org, or send us a bug report (please make sure that it wasn't reported before).
We'll send an updated note when kdepim is fully uploaded to unstable.
So far the only missing submodule in Debian's Qt5 stack is QtWebEngine. None of us the current Qt maintainers have the time/will to do the necessary stuff to have it properly packaged.
So if you would like to have QtWebEngine in Debian and:
You have C++ libraries' packaging skills.
You have a powerful enough machine/enough patience to do the necessary builds (8+ GB RAM+swap required).
You are willing to deal with 3rd party embedded software.
You are willing to keep up with security fixes.
You are accessible through IRC and have the necessary communications skills to work together with the rest of the team.
Then you are the right person for this task. Do not hesitate in pinging me on #debian-kde, irc.oftc.net.
Todays Debian Jessie's update brings a fix in Akonadi that you certainly want in your system.
There was a bug in Akonadi that made it leak files. And if you use Kmail you will certainly want to keep reading: most of us who tested it before pushing it to testing (and now to stable) removed more than 4 GiB of useless data from our homes.
The bug that makes Akonadi leak files gets solved with the latest stable update (and has been in testing for a couple of months already). But you need to purge the leaked files. It's pretty easy: with your normal user account just run:
akonadictl fsck
That's all. After a while you will get back a lot of disk space. Note that you don't need the Akonadi fix in order to run this tool and recover your space. The fix just makes sure this won't happen again.
We are aware that the current situation in testing is very unfortunate, with two main issues:
systemsettings transitioned to testing before the corresponding KDE Control Modules. The result is that systemsettings displays an empty screen. This is tracked in the following bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790703.
plasmoids such as plasma-nm transitioned to testing before plasma-desktop 5. The result is that the plasmoid are no longer displayed in the system tray.
We are working on getting plasma-desktop to transition to testing as soon as possible (hopefully in 2 days time), which will resolve both those issues. We appreciate that the transition to KF5 is much rougher than we would have liked, and apologize to all those impacted.
Many users have already moved their active projects to Qt 5 and we encourage also others to do so. With a high degree of source compatibility, we have ensured that switching to Qt 5 is smooth and straightforward. It should be noted that Qt 4.8.7 provides only the basic functionality to run Qt based applications on Mac OS X 10.10, full support is in Qt 5.
Qt 4.8.7 is planned to be the last patch release of the Qt 4 series. Standard support is available until December 2015, after which extended support will be available. We recommend all active projects to migrate to Qt 5, as new operating systems and compilers with Qt 4.8 will not be supported. If you have challenges migrating to Qt 5, please contact us or some of our service partners for assistance
