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.
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
Hi everyone! As you might know Qt4 has been deprecated (in the sense "you better start to port your code") since Qt5's first release in December 19th 2012. Since that point on Qt4 received only bugfixes. Upstream is about to release the last point release, 4.8.7. This means that only severe bugs like security ones will get a chance to get solved.
Moreover upstream recommended keeping Qt4 until 2017. If we get a Debian release every ±2 years that will make Jessie oldstable in 2017 and deprecated in 2018. This means we should really consider starting to port code using Qt4 to Qt5 during Stretch's developing life cycle.
It is important to note that Qt4 depends on a number of dependencies that their maintainers might want to get removed from the archive for similar reasons. In this case we will simply don't hesitate in removing their support as long as Qt4 keeps building. This normally doesn't mean API/ABI breakage but missing plugins that will diminish functionality from your apps, maybe even key ones. As an example let's take the **hypothetical** case in which the libasound2 maintainers are switching to a new libasound3 which is not API-compatible and removing libasound2 in the process. In this case we will have no choice but to remove the dependency and drop the functionality it provides. This is another of the important reasons why you should be switching to Qt5.
Qt4's webkit removal
Webkit is definitely not an easy piece of code to maintain. For starters it means having a full copy of the code in the archive for both Qt4 and Qt5. Now add to that the fact that the code evolves quickly and thus having upstream support even for security bugs will be getting harder and harder. So we decided to remove Qt4's webkit from the archive. Of course we still have a lot of KDE stuff using Qt4's webkit, so it won't disappear "soon", but it will at some point.
Porting
Some of us where involved in various Qt4 to Qt5 migrations [0] and we know for sure that porting stuff from Qt4 to Qt5 is much much easier and less painful than it was from Qt3 to Qt4.
We also understand that there is still a lot of software still using Qt4. In order to ease the transition time we have provided Wheezy backports for Qt5.
Don't forget to take a look at the C++ API changes page [1] whenever you start porting your application.
Temporarily shipping both Qt4 and Qt5 builds of your library
In case you maintain a library chances are that upstream already provides a way to build it using Qt5. Please note there is no point in shipping an application built with both flavours, please use Qt5 whenever possible. This double compilation should be left only for libraries.
You can't mix Qt4 and Qt5 in the same binary, but you may provide libraries compiled against one or the other. For example, your source package foo could provide both libqt4foo1 and libqt5foo1. You need to mangle your debian/rules and/or build system accordingly to achieve this.
A good example both for upstream code allowing both styles of compilation and debian packaging is phonon. Take a look at the CMakeLists.txt files for seeing how a source can be built against both flavours and another to debian/rules to see an example of how to handle the compilation. Just bear in mind that you
need to replace $(overridden_command) with the command itself, that variable substitution comes from internal stuff from our team and you should not be using it without a very good reason. If in doubt, feel free to ask us on IRC [2] or on the mailing list [3].
We the Debian Qt/KDE Team want to early-announce [maintainer warning] our decision to remove Qt4 from Jessie+1. This warning is mostly targeted at upstreams.
Qt4 has been deprecated since Qt5's first release on December 19th 2012, that means almost two years ago!
So far we had bugfixes-only releases, but upstream has announced that they will end this support on august 2015. This already means we will have to do a special effort from that point on for Jessie in case RC bugs appears, so having it in Jessie+1 is simply a non-go.
Some of us where involved in various Qt4 to Qt5 migrations [0] and we know for sure that porting stuff from Qt4 to Qt5 is much much easier and less painful than it was from Qt3 to Qt4.
We also understand that there is still a lot of software still using Qt4. In order to easy the transition time we have provided Wheezy backports for Qt5.
Don't forget to take a look at the C++ API change page [1] whenever you start porting your application.
[maintainer warning] **Remember the freeze** and do not upload packages ported to Qt5 to unstable. The best thing you can do now is to ask your upstream if the code can be compiled against Qt5 and, why not, try it yourself.
Our first priority now is to release Jessie, and this is why this is an early announce.
