Archive for the 'Debian' Category

Python3.5 is default python3 in sid

As of today, python3 -> python3.5.  There’s a bit of a transition, but fortunately because most extensions are packaged to build for all supported python3 versions, we started this transition at about 80% done.  Thank you do the maintainers that have done that.  It makes these transitions much smoother.

As part of getting ready for this transition, I reviewed all the packages that needed to be rebuilt for this stage of the transition to python3.5 and a few common errors stood out:

  1. For python3 it’s {python3:Depends} not {python:Depends}.
  2. Do not use {python3:Provides}.  This has never been used for python3 (go read the policy if you doubt me [1]).
  3. Almost for sure do not use {python:Provides}.  The only time it should still be used is if some package depends on python2.7-$PACKAGE. It would surprise me if any of these are left in the archive.  If so, since python2.7 is the last python2, then they should be adjusted.  Work with the maintainer of such an rdepend and once it’s removed, then drop the provides.
  4. Do not use XB-Python-Version.  We no longer use this to manage transitions (there won’t be any more python transitions).
  5. Do not use XB-Python3-Version.  This was never used.

Now that we have robust transition trackers [2], the purpose for which XB-Python-Version is obsolete.

In other news, pysupport was recently removed from the archive.  This means that, following the previous removal of pycentral, we finally have one and only one python packaging helper (dh-python) that supports both python and python3.  Thanks to everyone who made that possible.





Debian LTS Work December 2015

This was my eighth month as a Freexian sponsored LTS contributor. I was assigned 8 hours for the month of December.  It’s also the month in which I (re)learned an important lesson.

I decided to take another run at backporting the security fixes for Quassel.  Unlike the first time, I was successful at getting the fixes backported.  Then I ran into another problem: the changes took advantage of new features in c++11 such as std::function.

I made an attempt to change things away from c++11 with my limited c++ foo and after running head first into a brick wall several times finally consulted with the upstream author of the original fixes.   He let me know that while the problematic code is in fact present in the quassel versions in squeeze and wheezy, it’s not actually possible to trigger the security issue and that the CVEs should not actually apply to those versions.

That’s my report of a singularly unproductive and unpleasant 8 hours.  Next time I ask upstream first if there’s any doubt.  I shouldn’t assume they only care about current/recent releases.

Debian LTS Work November 2015

This was my seventh month as a Freexian sponsored LTS contributor. I was assigned 8 hours for the month of November.

As I did last month, I worked on review and testing of the proposed MySQL 5.5 packages for squeeze-lts and did a bit more work on Quassel.  It has been suggested that maybe we ought to just EOL Quassel since backporting the necessary fixes is so complicated.  I think they may be right, but I haven’t quite given up yet.

I reviewed CVE-2015-6360 for SRTP and my assessment was that squeeze-lts was not affected (same for the other Debian releases while I was at it).

I published one security update, it was for libphp-snoopy.  This resolves the outstanding security issues by updating to the newest version as was done for all other Debian releases.

Finally, in the interest of getting better support in tools for Debian LTS, I came up with a patch for the pull-debian-source[1] script in ubuntu-dev-tools so that it will download Debian LTS packages correctly.  Although it took a bit of investigating, the patch turned out to be very simple.  I filed bug #806749.  I also started looking at the distro-info package (thinking I’d need it updated to fix pull-debian-source, which turned out not to be the case), but didn’t finish it yet.  I plan to work on that this month.

[1] Even though this is in ubuntu-dev-tools and not devscripts, there’s really nothing Ubuntu specific about it.

Debian LTS Work October 2015

This was my sixth month as a Freexian sponsored LTS contributor. I was assigned 4 hours for the month of October and I had 4 unused hours from September for a total of 8.

With that time I started working on backporting security fixes for Quassel, but it’s turned into a major project. The commit message for one of the commits between what’s in squeeze-lts and what I was trying to backport is “Reformat ALL the source!”. That’s never a good sign.

I set that aside and focused instead on reviewing the MySQL 5.5 packages that the LTS team is working on. They are getting there, but we need to make sure we have it all right as we don’t want to break existing installations.

This month I hope to continue the work on both these packages.

Debian LTS Work August 2015

This was my fourth month as a Freexian sponsored LTS contributor. I was assigned 4 hours which was enough for me to release a fix for screen and review CVEs for libvpx and determine that they did not apply to squeeze-lts. The screen update is covered under DLA 305-1.

Why we care about administrivia (some of it, anyway)

We have enough debate about are things required by policy in Debian that, in my opinion we sometimes lose track of why things are a good idea to begin with. I just had a conversation via GitHub with a potential upstream developer (I’m looking into packaging something he developed) that reminded me about some of the reasons some of the non-code we try to ship are a good idea.

This is a Python based project. References to (manifest) translate to “extra files to put in the tarball” and references to sdist mean the source tarball.

UPSTREAM: Thanks for the pull request. Is there any place where I can find more information about this manifest file, and why it’s important to have one?

ME: There are two files (LICENSE and CHANGELOG) that it would be good to have in the sdist, each for their own reason:
We want LICENSE because since Debian distributes both source and binary we want a copy of the exact license for the code in our source distribution so the the requirements are clear and self-contained. I think this is a good general practice anyway.
We want CHANGELOG so we can ship it in the package documentation to enable users to see what has changed over time with the package. is just a way to add files to the sdist (it’s the normal way in distutils). I’m not that versed in setuptools myself, but I do know there are other ways to do it. What’s important (at least from our point of view) isn’t the file itself, but the added files it would add to the sdist.

If the isn’t shipped with the sdist, then a downstream distributor that modified the package might get a different result. I believe it’s a good general practice to include all the components of a package build system when you ship it.

That’s probably way more information than you wanted …

Plasma 5 (KDE) In Testing

A few days ago, fellow Qt/KDE team member Lisandro gave an update on the situation with migration to Plasma 5 in Debian Testing (AKA Stretch).  It’s changed again.  All of Plasma 5 is now in Testing.  The upgrade probably won’t be entirely smooth, which we’ll work on that after the gcc5 transition is done, but it will be much better than the half KDE4 SC half Kf5/Plasma 5 situation we’ve had for the last several days.

The issues with starting kwin should be resolved once users upgrade to Plasma 5.  To use the current kwin with KDE SC 4, you will need to add a symlink from /usr/bin/kwin to /usr/bin/kwin_x11.  That will be included in the next upload after gcc5.

Systemsettings and plasma-nm now work.

In my initial testing, I didn’t see anything major that was broken.  One user reported an issue with sddm starting automatically, but it worked fine for me.  During the upgrade you should get a debconf prompt asking if you want to use kdm or sddm.  Pick sddm.

When I tried to dist-upgrade, apt wanted to remove task-kde-desktop.  I let it remove it and some other packages and then in a second step did apt-get install task-kde-desktop.  That pulled it back in successfully along with adding and removing a reasonably large stack of packages.  Obviously we need to make that work better before Stretch is released, but as long as you don’t restart KDE in between those two steps it should be fine.  Lastely, I used apt-get autoremove to clear out a lot of no longer needed KDE4 things (when it asks if you want to stop the running kdm, say no).

Here are a few notes on terminology and what I understand of the future plans:

What used to be called KDE is now three different things (in part because KDE is now the community of people, not the software):

KDE Frameworks 5 (Kf5): This is a group of several dozen small libraries that as a group, roughly equate to what used to be kdelibs.

Plasma (Workspaces) 5: This is the desktop that we’ve just transitioned to.

Applications: These are a mix of kdelibs and Kf5 based applications.  Currently in Testing there are some of both and this will evolve over time based on upstream development.  As an example, the Kf5 based version of konsole is in Unstable and should transition to Testing shortly.

Finally, thanks to Maximiliano Curia (maxy on IRC) for doing virtually all of the packaging of Kf5, Plasma 5, and applications.  He did the heavy lifting, the rest of us just nibbled around the edges to keep it moving towards testing.