Archive Page 2

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.

 

[1] https://www.debian.org/doc/packaging-manuals/python-policy/

[2] https://release.debian.org/transitions/html/python3.5.html

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.

Resolving Tension …

I just noticed this post with the same title. At least in my case, I feel the tension with the community council is resolved.

In my case I resolved it by resigning from the Kubuntu Council, stopping work on Ubuntu development, and starting to migrate more of my systems to Debian.

For me, the tension is resolved because it’s not my problem any more.

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.in (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.

MANIFEST.in 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 MANIFEST.in file itself, but the added files it would add to the sdist.

If the MANIFEST.in 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 …