martes, 26 de mayo de 2015

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

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

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

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

Have you started to port your project?

viernes, 1 de mayo de 2015

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

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.

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

Temporarily shipping both Qt4 and Qt5 builds of your library

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

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

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

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

Timeline

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

miércoles, 5 de noviembre de 2014

Early announce: Qt4 removal in Jessie+1

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

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

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

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

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

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

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

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

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

jueves, 9 de octubre de 2014

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

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

The rest of Qt 5 will arrive soon.

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

Don't forget: you better start porting your Qt4 apps to Qt5!

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

Note 2014-10-15: currently building!

martes, 30 de septiembre de 2014

Qt5 in Jessie: we will release with 5.3.2

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

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

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

jueves, 1 de mayo de 2014

Call for help from Debian's KDE Team

Hi all!


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


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


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



-- 
Regards,
Maximiliano Curia
On behalf of the KDE team

sábado, 8 de marzo de 2014

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

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

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

qmake -qt5

Then I just ran make:

make

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

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

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

Easy, wasn't it?

I have just pushed the new version to Debian unstable.