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.

Does your app use Qt4? You better start porting it to Qt5

As you might know, Qt 4 is now in bug-fixes-only maintenance mode. This means that only bug fixes are allowed to be pushed to Qt 4's repository, but no new features.

On the other hand, Qt 5 is already here. Porting existing apps from Qt 4 to Qt 5 is actually easier than it was to port Qt 3 stuff to Qt 4. Take a look at this Qt project's wiki page for more info. Also pay attention at the links at the bottom of it under "Recommended Reading".

Some time ago I blogged about the 5.2.0 status in Debian experimental. We currently have it in testing with a much better status:


And we also have 5.2.1 in experimental with an even better status:

Note: qttools is FTBFS in armhf just because of some symbols changes, it will be fixed on the next upload.
Don't be afraid of getting it from experimental! Take a look at this blog post to know how to compile with Qt 5 in Debian.

Bonus

I have also uploaded Qt Creator built against Qt 5 to experimental. I plan to push it to unstable with Qt 5.2.1.

martes, 11 de febrero de 2014

Qt 5.2.0 in testing

Today we have Qt 5.2.0 in testing, a.k.a. Jessie. On the other hand we are slowly pushing 5.2.1 to experimental.

Enjoy!

P.S.: yes, this is turning more into tweets rather than blog posts :-)

martes, 4 de febrero de 2014

Qt 5.2.0 in unstable

We the Qt/KDE team have the pleasure to announce that we currently have Qt 5.2.0 in unstable. It brings Qt 5 to all official archs in Debian, minus some stuff that needs porting like Qt Webkit.

We hope to get this version in testing soon :-)

domingo, 5 de enero de 2014

Qt 5.2.0 in Debian experimental, now available for more archs

Qt 5.2.0 is already available in experimental until we get a transition slot, but don't be afraid to test it. With this release we had major improvements. With 5.1.1 currently in sid we have the following buildd chart:

Qt 5.1.1 in Debian Sid
Now with 5.2.0 in Debian experimental we have:

Qt 5.2.0 in Debian experimental

As you can see Qt has compiled in more archs, thanks to the effort of the Debian's porters and from the Qt/KDE team.

Note that Qt JS Backend has dissapeared: it's functionality (the javascript engine) is now in Qt Declarative itself. It has been ported away from Google's v8 to a Qt-based engine, allowing it to build in more archs among other features.

You can also note that we still have quite some FTBFS, mostly coming from Qt Webkit. Feel free to send patches ;-)

domingo, 11 de agosto de 2013

Qt in Debian: using Qt4 and/or Qt5 in your packages

Hi everyone! We now have both Qt4 and Qt5 in the archive. Those using Qt4 should not need to make any changes in their packages, although you can be extra-safe with a few steps. Don't rush, just read below.

Some background

Sune took the time some months ago to consult upstream for a sane way to allow both SDKs to coexist without us distros having to reinvent the wheel choosing which tools have to be in use in each case.

After a long discussion, upstream decided to write qtchooser (already in the archive) to be able to select between Qt4, Qt5 and even special user's cases like cross-platform builds.

So instead of going trough Debian's alternatives as we did with Qt3/Qt4, we will make use of this new tool.

My package uses Qt, how should I proceed?

There are many ways of choosing either of the versions of Qt:

- Using any qtchooser method (preferred):

  * Exporting QT_SELECT with 4, qt4, 5 or qt5 as a value in debian/rules.
  * Call the tool using the '-qtx' parameter, where x can be replaced with any of the options above.

- Build-depending on qt4-default or qt5-default. You can't B-D on both of them, as they can't coexist.

It is good to notice that:

- any qtchooser method will take precedence over build depending on qtX-default.
- If you export XDG_CONFIG_DIRS it will ignore the default paths to qtchooser's configs we setted up in the packages.

We have also provided qt4-[arch-triplet] and qt5-[arch-triplet] options for special cases.

Once again, if you are already using Qt4, there is no need to rush. See below.

Can is use both Qt4 and Qt5 in my package?

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. At the time of this writing I don't know of any examples yet.

So are you going to break the archive with a big transition?

No, we have done our best to avoid having to make any changes to existing Qt4 packages. Qt tools should default to Qt4 except if overriden by any method described above.

My package uses Qt4, can I leave it as it is?

While there is no need to apply the changes in this case, explicitly setting the Qt version will surely not hurt at all. But don't rush ;-)

Note 2014-05-07: exporting XDG_CONFIG_DIRS is now safe.