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 backgroundSune 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 ;-)

[no pictures here, just a short report]. Today DebConf, this year's edition of the annual Debian developer conference, started with two inspiring talks about Debian proper, one by Lucas Nussbaum, the other by Joey Hess. This also means that yesterday DebCamp ended, the period preceeding DebConf and dedicated to working on Debian together with others. Here's a short report from my point of view: I arrived here on Tuesday, the first day of DebCamp. I immediately fell in love with the venue, & despite the early stage of setup, everything I needed was working fine for me from the very start. Like in previous years, I used the time to do work in the Debian Perl Group, especially taking advantage of the presence of other team members. That's the great thing about DebCamp & DebConf: collaborating in real-life & real-time, from quickly asking a question over sitting together to think about solutions for a problem to "just" chatting & thereby developping ideas for the future. In the previous days I

• tried to get down the amount of packages with not-yet uploaded new upstram releases;
• looked into the pending bugs around the Perl 5.18 transition;
• investigated with others the details of the upcoming new timezone file handling in the Perl world, which will make our lives easier but still needs some work on the Debian side;
• prepared with others the Perl Group's BoF that will take place during DebConf on Thursday;
• helped with the creation of a new pkg-perl-tools package.

I really enjoy my time here, & I'm especially happy to meet some people for the first time in meat space. This is only possible due to the generous support of the DebConf sponsors & the immense efforts of the DebConf team. Thank you!

Yesterday evening I've arrived at DebConf 13. I was quite tired after traveling so I just had few beers and went to bed. The travel went quite well besides somebody else broke wine and my suitcase was all wet from it. Fortunately almost nothing got inside so I have some clean clothes for next week :-). As I went to bed quite early, I woke up early as well so I went to short walk to see what is nearby:

Filed under: English Debian Photography 0 comments Flattr this!

This is just a quick note that the video streams of DebConf13 will be available at the following URLs:

• Main talk room, chat on #debconf-talkroom1 on irc.debian.org
• Second talk room, guess what - #debconf-talkroom2 it is.

May you have a productive and joyful DebConf - and thanks for volunteering + talking if you do so! DebConf is what you make it.

Cloud is passing the hype curve and we are seeing more stable developments and offerings on the market. Lately I ve been playing with RedHat s Openshift. Openshift is a PaaS (Platform as a Service) offering that intends to be an alternative for vendors such as Heroku. The focus for such offerings is to give developers enough flexibility and tools that handle the application deployment and maintenance process in a way that is integrated with their existing development workflow and tools. I ve been using Heroku for a while to deploy small to medium size projects. I liked the tools and developer-centered experience they offer. Openshift is quite new on the market and it comes in two flavors: Openshift Online, which is a PaaS service, and Openshift Enterprise, which allows organization to setup a PaaS within their own infrastructure. Both of them powered by the Openshift origin software. I ll not compare Heroku vs. Openshift feature by feature but from my experience I can tell that Openshift is far from mature and will need to give developers more features to increase adoption. When developing applications for Openshift developers are given a set of application stack components, similar to Heroku s buildpacks. They call them cartridges. You can think of them as operating system packages, since the idea is the same: have a particular application stack component ready to be used by application developers. Most of the cartridges offered by the service are base components such as application server, programming language interpreters (Ruby, Python, etc), web development frameworks and data storage, such as relational and non-relational databases. Cartridges are installed inside a gear, which is a sort of application container (I believe it uses LXC internally). Unsurprisingly this Openshift component doesn t leverage on existing packaging for RHEL 64bit, the OS that powers the service. I d expect such things from the RedHat ecosystem. I had to develop a cartridge to have a particular BI engine to be used as embed component by application developers. After reading docs and reference I realized this can be piece of cake, since I have packaging experience. Wrong. Well, quite so. The tricky part for Openshift Online is that it does not offer enough information on the cartridge install process so you can see what s going wrong. To be able to see more details on the process you ll need to setup an Openshift origin server and use it as a testing facility. Turns out that having a Origin server to operate correctly is also a challenging task and consumed a lot of my time. Over the recent weeks I ve learned from origin developers that such features are on the road map for the upcoming releases. That s good news. One of the challenges I had, and still have to figure out, is that unlike the normal cartridges mine didn t required to launch any service. Since it is a BI engine I just needed to configure and deploy to an application server such as JBoss. Cartridge format requires to have a sort of service init.d script under bin along with setup, install and configuration scripts that are ran on install. Although every day I become more familiar with origin and Openshift internals I still have work to do. Nice thing is that I was already familiar with LXC and Ruby-based applications so I could figure where things are placed and where to look for errors on origin quite easily. The cartridges are on my github account if you care to take a look and offer advice.

In the Dutch language area (Netherlands and Flanders) most e-book publishers changed from using DRM to using a watermark since February. It's now something like 62% with watermark, 24% with DRM and 14% without either. I was hoping that more with move to the watermark, but it doesn't seem to change much. The watermark in the e-books are used to find the original buyer in case of piracy. The information in the e-book does not itself identify the buyer, it just some random ID. That ID can then be used to trace back to buyer. We work with a 3rd party to deliver the e-books to our consumers. They get a random string from us that we can use to trace back the order, and from there we can trace back who bought it. The 3rd party than generates their own random string and puts that in the e-book. They only only keep those 2 random strings, and so have no way to trace this back to the buyer, we are the only one that known who bought it. And I think this is how it should work. I think this is also what the privacy laws require us to do. But now we got a new contract that states that we must directly give information about the buyer if some anti-piracy agency (BREIN) finds an e-book file online. We must keep the information about the buyer for minimum of 2 years and maximum of 5 years. And if we don't sign the contract we won't be allowed to sell e-books with watermark anymore. So this means that they want to bypass the normal judicial system, and probably contact those buyers they accuse of piracy directly. I questioned that this was legal. They say that it is legal according to the Dutch privacy law, but I have a hard time interpreting any of the options in article 8 as that we can give that information without the explicit consent of the person. I guess you can interpret option f in several ways, and that their lawyers do it differently than me. This will probably remain unclear until some court decides on it.

So debcamp has been going on for just over five days now, and it's been a success and a failure at the same time. A success, because the organization is wonderful, the food is good, the location is excellent, and the fun is everywhere. A failure, because with all these nice things going on, I've done only 300 lines of code (or so) of the nbd-server rewrite that I'd planned to do. Ah well. I suppose I'll have to either cram, or find another time to do so, then.

I'm going to debconf13. After been in debian for quite a long time, I finally will see in person some of those mail address I see for so long.

If you're tempted to add a platform-specific quirk to a Linux driver, pause and do the following:

1. Check whether the platform works correctly with the generic Windows driver for the hardware in question. If it requires a platform-specific driver rather than the generic one, adding a quirk is probably ok.
   
2. If the generic Windows driver works, check whether there's any evidence of platform-specific code in the Windows driver. This will typically be in the .inf file, but occasionally you'll want to run strings against the Windows driver and see whether any functions or strings match the platform in question. If there's evidence of special-casing in the generic Windows driver, adding a quirk is probably ok
   
3. If the generic Windows driver works and doesn't appear to have any platform-specific special casing, don't add a quirk. You'll plausibly fix the machine you care about, but you won't fix any others that have the same behaviour. Even worse, if someone does eventually fix the problem properly, there's a risk that your special-casing will now break your system.

The moral to this story is: if you think adding a quirk is the right solution, you're almost certainly wrong.

comments

This hasn't been my week. I had to fix two of my Hurd installations I use for development and testing. I spent countless hours waiting for some package to be rebuilt, reading scientific papers about adding stuff to the Mach kernel. Fascinating stuff like thread migration that would (among other things) allow for proper resource accounting on Mach kernels. Oh, and gcc is a sadistic bastard:

In file included from printf-parsewc.c:2:0:
printf-parsemb.c: In function  __parse_one_specwc :
printf-parsemb.c:407:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.

A similar error came up like five hours into my libc rebuild. How nice of gcc to retry the build to figure out whether it is to blame or the environment only to throw away the successful build and abort my build process :/

• I published my patch series addressing all sysvinit-related issues: http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00000.html
• I since found three minor issues, so I'll roll another series shortly. But since this somewhat breaks the ABI (/hurd/init is no longer PID 1) this is waiting for a libc rebuild that I haven't managed to get done so far.
• I updated my patch series for the sysvinit package. I'm quite pleased with it as it is and I'll propose it for inclusion with the sysvinit package shortly. Unfortunately this depends on the patched hurd package with is blocked by the libc package :/

Next week I'll finally propose my sysvinit patch series. Oh, and implement the -d flag in our umount. I thought I had implemented all the flags used by the initscripts, but somehow I missed -d. If I get bored, I'll take a look at the network related issues, but I bet I won't get there...

So... Well, contrary to the popular sentiment in Planet Debian, this year I'm very sorry to inform that... This is the first DebConf I miss in ten years, so... Yes, it's a big bummer for me. I'm not attending because this year, DebC(amp onf) coincide with the two first weeks of classes at my university And as a new teacher, I cannot afford to miss it! Anyway, but that should not stand in the way to attend a nice Debian 20th anniversary party! Parties will be held around the world. (Didn't find your city? Plan something and add it *now!*). In Mexico City, the nice guys at the very interesting Rancho Electr nico hackerspace took the lead, and organized the following activities: Don't you yet know the hackerspace? You should go there! It's in a very centric location, just two blocks West from Metro San Antonio Abad (Juan Lucas Lassaga 114, col. Obrera). And the only two times I have been there, it has been good fun. Surely this Saturday we can have a nice party as well! The planned activities are from 13:30 to 20:30. See you there!

As a more or less random data point for DebConf13, here's the current bug stats for Debian. Hope to see you there, and if you want to attend the BoF Gitify ALL the things or the talk Gitify your life you can do so on site, via IRC in #vcs-home on OFTC, or simply follow the live streams. If you see my in person, I have two crates of Scheider Aventinus with me and don't plan on bringing home any full bottles. The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 1532
  • Affecting Jessie: 1019 That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting Jessie and unstable: 832 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 51 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 38 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 743 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting Jessie only: 187 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 0 bugs are in packages that are unblocked by the release team.
      • 187 bugs are in packages that are not unblocked.

Graphical overview of bug stats thanks to azhag:

A minor maintenance release of inline is now on CRAN, and has just been already included in Debian. This release contains a patch kindly contributed by Mikhail Umorin which fixes the of \code cfunction with lists of signatures and function bodies. The complete NEWS entry is below.

Changes in inline version 0.3.13 (2013-08-08)

• Applied contributed patch by Mikhail Umorin which corrects cfunction() in the case of a list of signature and body arguments.

Courtesy of CRANberries, there is also a diffstat report for the most recent release. A few more details are available at the R-Forge page.

pidof is a program that finds the PID of a named program. In some ways it is like a cut-down pgrep found in the procps package. pidof currently sits in sysvinit-tools. There are plans to move all utilities that use the proc filesystem under one package which will make the maintenance of them simpler, which in effect means moving pidof from sysvinit-tools to procps. The short-term bump should make it better in the long term. Now as I wear two hats (Debian maintainer and procps upstream) there are two very important things I/we need to know.

• If your Debian package depends on pidof being present, then we need to discuss dependencies. procps is generally installed on most systems but there might be corner cases. Possibly just depending on a specific version of procps will do it
• If you, your Debian package or anything else (including other distributions) need the non-LSB options of pidof (ie they use -c -n or -m) then we (upstream) need to know about it. There are provisional plans not to support these options but they re needed, or a subset is, then that could change.

Debian developers can chime in on the debian-devel email list, or email myself. If its an upstream issue then either email me, or even better, the procps email list

pidof is a program that finds the PID of a named program. In some ways it is like a cut-down pgrep found in the procps package. pidof currently sits in sysvinit-tools. There are plans to move all utilities that use the proc filesystem under one package which will make the maintenance of them simpler, which in effect means moving pidof from sysvinit-tools to procps. The short-term bump should make it better in the long term. Now as I wear two hats (Debian maintainer and procps upstream) there are two very important things I/we need to know.

• If your Debian package depends on pidof being present, then we need to discuss dependencies. procps is generally installed on most systems but there might be corner cases. Possibly just depending on a specific version of procps will do it
• If you, your Debian package or anything else (including other distributions) need the non-LSB options of pidof (ie they use -c -n or -m) then we (upstream) need to know about it. There are provisional plans not to support these options but they re needed, or a subset is, then that could change.

Debian developers can chime in on the debian-devel email list, or email myself. If its an upstream issue then either email me, or even better, the procps email list

Weblate 1.6 is already two weeks out without any regressions, so now it's time to think about features for 1.7. I definitely want to improve support for monolingual translation formats as they currently suffer by various metadata issues (eg. checks not working correctly). This requires quite big change in underlying database, but I think it's quite manageable. When talking about checks, I want to make them configurable per project as global configuration is quite limiting for shared sites like hosted Weblate. I will definitely need to touch registration and authentication, either by supporting latest django-registration API or to move some other solution with support for federated login. Which of these approaches will be used depends on my time, what is always the most limiting factor. This might sound as too few features, but I'd like to make releases more often, so that should fit into this plan. However if you want to push for some feature, you still have two days to fund something on Catincan!

Filed under: English Weblate 0 comments Flattr this!