Search Results: "kitterman"

12 July 2017

Reproducible builds folks: Reproducible Builds: week 115 in Stretch cycle

Here's what happened in the Reproducible Builds effort between Sunday July 2 and Saturday July 8 2017: Reproducible work in other projects Ed Maste pointed to a thread on the LLVM developer mailing list about container iteration being the main source of non-determinism in LLVM, together with discussion on how to solve this. Ignoring build path issues, container iteration order was also the main issue with rustc, which was fixed by using a fixed-order hash map for certain compiler structures. (It was unclear from the thread whether LLVM's builds are truly path-independent or rather that they haven't done comparisons between builds run under different paths.) Bugs filed Patches submitted upstream: Reviews of unreproducible packages 52 package reviews have been added, 62 have been updated and 20 have been removed in this week, adding to our knowledge about identified issues. No issue types were updated or added this week. Weekly QA work During our reproducibility testing, FTBFS bugs have been detected and reported by: diffoscope development Development continued in git with contributions from: With these changes, we are able to generate a dynamically loaded HTML diff for GCC-6 that can be displayed in a normal web browser. For more details see this mailing list post. Misc. This week's edition was written by Ximin Luo, Bernhard M. Wiedemann and Chris Lamb & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

4 July 2017

Reproducible builds folks: Reproducible Builds: week 114 in Stretch cycle

Here's what happened in the Reproducible Builds effort between Sunday June 25 and Saturday July 1 2017: Upcoming and past events Our next IRC meeting is scheduled for July 6th at 17:00 UTC (agenda). Topics to be discussed include an update on our next Summit, a potential NMU campaign, a press release for buster, branding, etc. Toolchain development and fixes Packages fixed and bugs filed Ximin Luo uploaded dash, sensible-utils and xz-utils to the deferred uploads queue with a delay of 14 days. (We have had patches for these core packages for over a year now and the original maintainers seem inactive so Debian conventions allow for this.) Patches submitted upstream: Reviews of unreproducible packages 4 package reviews have been added, 4 have been updated and 35 have been removed in this week, adding to our knowledge about identified issues. One issue types has been updated: One issue type has been added: Weekly QA work During our reproducibility testing, FTBFS bugs have been detected and reported by: diffoscope development tests.reproducible-builds.org Misc. This week's edition was written by Chris Lamb, Ximin Luo, Holger Levsen, Bernhard Wiedemann, Vagrant Cascadian & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

1 June 2017

Raphaël Hertzog: My Free Software Activities in May 2017

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donors (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS I was allocated 12 hours to work on security updates for Debian 7 Wheezy. During this time I did the following: Misc Debian work Debian Handbook. I started to work on the update of the Debian Administrator s Handbook for Debian 9 Stretch. As part of this, I noticed a regression in dblatex and filed this issue both in the upstream tracker and in Debian and got that issue fixed in sid and stretch (sponsored the actual upload, filed the unblock request). I also stumbled on a regression in dia which was due to an incorrect Debian-specific patch that I reverted with a QA upload since the package is currently orphaned. Django. On request of Scott Kitterman, I uploaded a new security release of Django 1.8 to jessie-backports but that upload got rejected because stretch no longer has Django 1.8 and I m not allowed to maintain that branch in that repository. Ensued a long and heated discussion that has no clear resolution yet. It seems likely that some solution will be found for Django (the 1.8.18 that was rejected was accepted as a one-time update already, and our plans for the future make it clear that we would have like to have an LTS version in stretch in the first place) but the backports maintainers are not willing to change the policy to accomodate for other similar needs in the future. The discussion has been complicated by the intervention of Neil Williams who brought up an upgrade problem of lava-server (#847277). Instead of fixing the root-problem in Django (#863267), or adding a work-around in lava-server s code, he asserted that upgrading first to Django 1.8 from jessie-backports was the only upgrade path for lava-server. Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

31 January 2017

Raphaël Hertzog: My Free Software Activities in January 2017

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donors (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS I was allocated 10 hours to work on security updates for Debian 7 Wheezy. During this time I did the following: Debian packaging With the deep freeze approaching, I made some last-minute updates: Misc work Sponsorship. I sponsored a new asciidoc upload demoting a dependency into a recommends (#850301). I sponsored a new upstream version of dolibarr. Discussions. I seconded quite a few changes prepared by Russ Allbery on debian-policy. I helped Scott Kitterman with #849584 about a misunderstanding of how the postfix service files are supposed to work. I discussed in #849913 about a regression in building of cross-compilers, and made a patch to avoid the problem. In the end, Guillem developed a better fix. Bugs. I investigated #850236 where a django test failed during the first week after each leap year. I filed #853224 on desktop-base about multiple small problems in the maintainer scripts. Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

13 June 2016

Raphaël Hertzog: Freexian s report about Debian Long Term Support, May 2016

A Debian LTS logoLike each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In May, 166 work hours have been dispatched among 9 paid contributors. Their reports are available: Evolution of the situation The number of sponsored hours stayed the same over May but will likely increase a little bit the next month as we have two new Bronze sponsors being processed. The security tracker currently lists 36 packages with a known CVE and the dla-needed.txt file lists 36 packages awaiting an update. Despite the higher than usual number of work hours dispatched in May, we still have more open CVE than we used to have at the end of the squeeze LTS period. So more support is always needed Thanks to our sponsors New sponsors are in bold.

No comment Liked this article? Click here. My blog is Flattr-enabled.

17 May 2016

Raphaël Hertzog: Freexian s report about Debian Long Term Support, April 2016

A Debian LTS logoLike each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In April, 116.75 work hours have been dispatched among 9 paid contributors. Their reports are available: Many contributors did not use all their allocated hours. This is partly explained by the fact that in April Wheezy was still under the responsibility of the security team and they were not able to drive updates from start to finish. In any case, this means that they have more hours available over May and since the LTS period started, they should hopefully be able to make a good dent in the backlog of security updates. Evolution of the situation The number of sponsored hours reached a new record with 132 hours per month, thanks to two new gold sponsors (Babiel GmbH and Plat Home). Plat Home s sponsorship was aimed to help us maintain Debian 7 Wheezy on armel and armhf (on top of already supported amd64 and i386). Hopefully the trend will continue so that we can reach our objective of funding the equivalent of a full-time position. The security tracker currently lists 45 packages with a known CVE and the dla-needed.txt file lists 44 packages awaiting an update. This is a bit more than the 15-20 open entries that we used to have at the end of the Debian 6 LTS period. Thanks to our sponsors New sponsors are in bold.

No comment Liked this article? Click here. My blog is Flattr-enabled.

27 April 2016

Niels Thykier: auto-decrufter in top 5 after 10 months

About 10 months ago, we enabled an auto-decrufter in dak. Then after 3 months it had become the top 11th remover . Today, there are only 3 humans left that have removed more packages than the auto-decrufter impressively enough, one of them is not even an active FTP-master (anymore). The current score board:
 5371 Luca Falavigna
 5121 Alexander Reichle-Schmehl
 4401 Ansgar Burchardt
 3928 DAK's auto-decrufter
 3257 Scott Kitterman
 2225 Joerg Jaspert
 1983 James Troup
 1793 Torsten Werner
 1025 Jeroen van Wolffelaar
  763 Ryan Murray
For comparison, here is the number removals by year for the past 6 years:
 5103 2011
 2765 2012
 3342 2013
 3394 2014
 3766 2015  (1842 removed by auto-decrufter)
 2845 2016  (2086 removed by auto-decrufter)
Which tells us that in 2015, the FTP masters and the decrufter performed on average over 10 removals a day. And by the looks of it, 2016 will surpass that. Of course, the auto-decrufter has a tendency to increase the number of removed items since it is an advocate of remove early, remove often! .:) Data is from https://ftp-master.debian.org/removals-full.txt. Scoreboard computed as:
  grep ftpmaster: removals-full.txt   \
   perl -pe 's/.*ftpmaster:\s+//; s/\]$//;'   \
   sort   uniq -c   sort --numeric --reverse   head -n10
Removals by year computed as:
 grep ftpmaster: removals-full.txt   \
   perl -pe 's/.* (\d 4 ) \d 2 :\d 2 :\d 2 .*/$1/'   uniq -c   tail -n6
(yes, both could be done with fewer commands)
Filed under: Debian

23 April 2016

Scott Kitterman: Computer System Security Policy Debate (Follow-up)

As a follow-up to my recent post on the debate in the US over new encryption restrictions, I thought a short addition might be relevant. This continues. There was a recent Congressional hearing on the topic that featured mostly what you would expect. Police always want access to any possible source of evidence and the tech industry tries to explain that the risks associated with mandates to do so are excessive with grandstanding legislators sprinkled throughout. What I found interesting (and I use that word with some trepidation as it is still a multi-hour video of a Congressional hearing) is that there was rather less grandstanding and and less absolutism from some parties than I was expecting.
There is overwhelming consensus that these requirements [for exceptional access] are incompatible with good security engineering practice Dr. Matthew Blaze
The challenge is that political people see everything as a political/policy issue, but this isn t that kind of issue. I get particularly frustrated when I read ignorant ramblings like this that dismiss the overwhelming consensus of the people that actually understand what needs to be done as emotional, hysterical obstructionism. Contrary to what seems to be that author s point, constructive dialogue and understanding values does nothing to change the technical risks of mandating exceptional access. Of course the opponents of Feinstein-Burr decry it as technologically illiterate, it is technologically illiterate. This doesn t quite rise to the level of that time the Indiana state legislature considered legislating a new value (or in fact multiple values) for the mathematical constant Pi, but it is in the same legislative domain.

16 April 2016

Scott Kitterman: Future of secure systems in the US

As a rule, I avoid writing publicly on political topics, but I m making an exception. In case you haven t been following it, the senior Republican and the senior Democrat on the Senate Intelligence Committee recently announced a legislative proposal misleadingly called the Compliance with Court Orders Act of 2016. The full text of the draft can be found here. It would effectively ban devices and software in the United States that the manufacturer cannot retrieve data from. Here is a good analysis of the breadth of the proposal and a good analysis of the bill itself. While complying with court orders might sound great in theory, in practice this means these devices and software will be insecure by design. While that s probably reasonably obvious to most normal readers here, don t just take my word for it, take Bruce Schneier s. In my opinion, policy makers (and it s not just in the United States) are suffering from a perception gap about security and how technically hard it is to get right. It seems to me that they are convinced that technologists could just do security right while still allowing some level of extraordinary access for law enforcement if they only wanted to. We ve tried this before and the story never seems to end well. This isn t a complaint from wide eyed radicals that such extraordinary access is morally wrong or inappropriate. It s hard core technologists saying it can t be done. I don t know how to get the message across. Here s President Obama, in my opinion, completely missing the point when he equates a desire for security with fetishizing our phones above every other value. Here are some very smart people trying very hard to be reasonable about some mythical middle ground. As Riana Pfefferkorn s analysis that I linked in the first paragraph discusses, this middle ground doesn t exist and all the arm waving in the world by policy makers won t create it. Coincidentally, this same week, the White House announced a new Commission on Enhancing National Cybersecurity . Cybersecurity is certainly something we could use more of, unfortunately Congress seems to be heading off in the opposite direction and no one from the executive branch has spoken out against it. Security and privacy are important to many people. Given the personal and financial importance of data stored in computers (traditional or mobile), users don t want criminals to get a hold of it. Companies know this, which is why both Apple IOS and Google Android both encrypt their local file systems by default now. If a bill anything like what s been proposed becomes law, users that care about security are going to go elsewhere. That may end up being non-US companies products or US companies may shift operations to localities more friendly to secure design. Either way, the US tech sector loses. A more accurate title would have been Technology Jobs Off-Shoring Act of 2016. EDIT: Fixed a typo.

15 April 2016

Raphaël Hertzog: Freexian s report about Debian Long Term Support, March 2016

A Debian LTS logoLike each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In February, 111.75 work hours have been dispatched among 10 paid contributors. Their reports are available: Evolution of the situation The number of sponsored hours started to increase for April (116.75 hours, thanks to Sonus Networks) and should increase even further for May (with a new Gold sponsor currently joining us, Babiel GmbH). Hopefully the trend will continue so that we can reach our objective of funding the equivalent of a full-time position. At the end of the month the LTS team will be fully responsible of all Debian 7 Wheezy updates. For now paid contributors are still helping the security team by fixing packages that were fixed in squeeze already but that are still outstanding in wheezy. They are also looking for ways to ensure that some of the most complicated packages can be supported over the wheezy LTS timeframe. It is likely that we will seek external help (possibly from credativ which is already handling support of PostgreSQL) for the maintenance of Xen and that some other packages (like libav, vlc, maybe qemu?) will be upgraded to newer versions which are still maintained (either upstream or in Debian Jessie by the Debian maintainers). Thanks to our sponsors New sponsors are in bold.

No comment Liked this article? Click here. My blog is Flattr-enabled.

11 March 2016

Raphaël Hertzog: Freexian s report about Debian Long Term Support, February 2016

A Debian LTS logoLike each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In February, 112.50 work hours have been dispatched among 11 paid contributors. Their reports are available: Evolution of the situation The number of sponsored hours continued to decrease a little bit. It s not worrisome yet but we should try to get back to a positive slope if we want to be able to do an outstanding job for wheezy LTS. On the positive side, TOSHIBA renewed their platinum sponsorship for another 6 months at least and we have some contacts for new sponsors, though they are far from being concluded yet. We are now in transition between squeeze LTS and wheezy LTS. The paid contributors are helping the security team by fixing packages that were fixed in squeeze already but that are still outstanding in wheezy. They are also taking generic measures to prepare wheezy LTS (for example to ensure all packages work with OpenJDK 7.x since support for 6.x will be dropped in the LTS period). Thanks to our sponsors New sponsors are in bold (none this month).

No comment Liked this article? Click here. My blog is Flattr-enabled.

5 March 2016

Lunar: Reproducible builds: week 44 in Stretch cycle

What happened in the reproducible builds effort between February 21th and February 27th:

Toolchain fixes Didier Raboud uploaded pyppd/1.0.2-4 which makes PPD generation deterministic. Emmanuel Bourg uploaded plexus-maven-plugin/1.3.8-10 which sorts the components in the components.xml files generated by the plugin. Guillem Jover has implemented stable ordering for members of the control archives in .debs. Chris Lamb submitted another patch to improve reproducibility of files generated by cython.

Packages fixed The following packages have become reproducible due to changes in their build dependencies: dctrl-tools, debian-edu, dvdwizard, dymo-cups-drivers, ekg2, epson-inkjet-printer-escpr, expeyes, fades, foomatic-db, galternatives, gnuradio, gpodder, gutenprint icewm, invesalius, jodconverter-cli latex-mk, libiio, libimobiledevice, libmcrypt, libopendbx, lives, lttnganalyses, m2300w, microdc2, navit, po4a, ptouch-driver, pxljr, tasksel, tilda, vdr-plugin-infosatepg, xaos. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues, but not all of them:

tests.reproducible-builds.org The reproducibly tests for Debian now vary the provider of /bin/sh between bash and dash. (Reiner Herrmann)

diffoscope development diffoscope version 50 was released on February 27th. It adds a new comparator for PostScript files, makes the directory tests pass on slower hardware, and line ordering variations in .deb md5sums files will not be hidden anymore. Version 51 uploaded the next day re-added test data missing from the previous tarball. diffoscope is looking for a new primary maintainer.

Package reviews 87 reviews have been removed, 61 added and 43 updated in the previous week. New issues: captures_shell_variable_in_autofoo_script, varying_ordering_in_data_tar_gz_or_control_tar_gz. 30 new FTBFS have been reported by Chris Lamb, Antonio Terceiro, Aaron M. Ucko, Michael Tautschnig, and Tobias Frost.

Misc. The release team reported on their discussion about the topic of rebuilding all of Stretch to make it self-contained (in respect to reproducibility). Christian Boltz is hoping someone could talk about reproducible builds at the openSUSE conference happening June 22nd-26th in N rnberg, Germany.

29 February 2016

Scott Kitterman: Debian LTS Work February 2016

This was my tenth month as a Freexian sponsored LTS contributor. I was assigned 8 hours for the month of February. As I did last month, I worked on updating clamav in wheezy and squeeze-lts. As with previous updates to clamav, we updated it to the new upstream version[1]. As an added complexity, this version bumped soname, so it s now libclamav7 instead of libclamav6. This bump necessitated a small transition in jessie/wheezy-proposed-updates and squeeze-lts. The update for Jessie (included for completeness here) was done early in the month by other pkg-clamav team members. It and the rebuilt/update libclamav reverse-depends will be included in the next Jessie point release. For wheezy, I uploaded libclamunrar (which bumped soname as well) and worked with other pkg-clamav team members on getting clamav to build on sparc and preparing a fix for c-icap. It and the rebuilt/update libclamav reverse-depends will be included in the next Wheezy point release. As a result of the amount of time it took, the squeeze-lts update landed later than I hoped it would, but it is there. As documented in DLA 437-1, there are new packages for clamav, libclamunrar, python-clamav, and klamav. The last squeeze libclamav reverse-depend, dansguardian, took more work, but it too is updated, see DLA 440-1.
[1] The primary reason for this is that anti-virus is an arms race. Unlike other types of packages being stable with only fixes for severe bugs and security issues does not result in a stable capability. It will regress over time. In order to keep up, the new version is needed.

26 February 2016

Scott Kitterman: Postfix 3.0 woes

Postfix 3.0 recently hit Debian Unstable (and Ubuntu Xenial for those that care about that). It s been a bit of a bumpy road, but it seems to mostly be there for new installs. For package upgrades, there s still issues. We hope to have that sorted shortly, but in the meantime, all you should need to do to get an upgraded system working is add or adjust two parameters in your main.cf shlib_directory=/usr/lib/postfix
daemon_directory=/usr/lib/postfix/sbin You can either edit the file directly or use postconf: postconf -e shlib_directory=/usr/lib/postfix
postconf -e daemon_directory=/usr/lib/postfix/sbin No need to file more bugs and yes, we also know postfix 3.1 was just released. One thing at a time.

14 February 2016

Raphaël Hertzog: Freexian s report about Debian Long Term Support, January 2016

A Debian LTS logoLike each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In December, 113.50 work hours have been dispatched among 9 paid contributors. Their reports are available: Evolution of the situation As expected, we had a small drop in the amount of hours sponsored. New sponsors (re-)joined but others stopped too (Gree this time) mostly balancing the result. We only lost 2 hours of sponsored work. It would be nice if we could invert that curve and actually start again to get closer to our objective of funding the equivalent of a full time position. Let s hope that the switch to wheezy as the version supported by the LTS team will motivate many companies relying on Debian 7 in their IT system. In terms of security updates waiting to be handled, the situation is close to last month(17 packages in dla-needed.txt, 27 in the list of CVE). It looks like that having about 20 packages needing an update is the normal situation and that we can t really get further down given the time required to process some updates (sometimes we wait until the upstream authors provides a patch, and so on). Thanks to our sponsors New sponsors are in bold.

No comment Liked this article? Click here. My blog is Flattr-enabled.

13 February 2016

Scott Kitterman: Debian LTS Work January 2016

This was my ninth month as a Freexian sponsored LTS contributor. I was assigned 8 hours for the month of January. My time this month was spent preparing updates for clamav and the associated libclamunrar for squeeze and wheezy. For wheezy, I ve only helped a little, mostly I worked on squeeze. This update is more complex than usual because with clamav 0.99 upstream bumped soname and so in addition to the normal case of transitions in unstable, we ve needed transitions for stable, oldstable, and squeeze-lts. We also try to be careful and maintain higher versions in newer releases, so stable needed to wait for 0.99 in testing, oldstable needed to wait for stable, etc. Currently 0.99 is in stable proposed updates and I ve requested that the update for wheezy (oldstable) go forward. Once that s done, I ve got squeeze-lts ready to go.

20 January 2016

Scott Kitterman: Python Packaging Build-Depends

As a follow-up to my last post where I discussed common Python packaging related errors, I thought it would be worth to have a separate post on how to decide on build-depends for Python (and Python3) packages. The python ecosystem has a lot of packages built around supporting multiple versions of python (really python3 now) in parallel. I m going to limit this post to packages you might need to build-depend on directly.

Python (2) Since Jessie (Debian 8), python2.7 has been the only supported python version. For development of Stretch and backports to Jessie there is no need to worry about multiple python versions. As a result, several all packages are (and will continue to be) equivalent to their non- all counterparts. We well continue to provide the all packages for backward compatibility, but they aren t really needed any more. python (or python-all) This is the package to build-depend on if your package is pure Python (no C extensions) and does not for some other reason need access to the Python header files (there are a handful of packages this latter caveat applies to, if you don t know if it applies to your package, it almost certainly doesn t). You should also build-depend on dh-python. It was originally shipped as part of the python package (and there is still an old version provided), but to get the most current code with new bug fixes and features, build-depend on dh-python. python-dev (or python-all-dev) If your package contains compiled C or C++ extensions, this package either provides or depends on the packages that provide all the header files you need. Do not also build-depend on python. python-dev depends on it and it is just an unneeded redundancy. python-dbg (or python-all-dbg) Add this if you build a -dbg package (not needed for -dbgsym). Other python packages There is not, AFAICT, any reason to build-dep on any of the other packages provided (e.g. libpython-dev). It is common to see things like python-all, python, python-dev, libpython-dev in build-depends. This could be simplified just to python-all-dev since it will pull the rest in.

Python3 Build-depends selection for Python 3 is generally similar, except that we continue to want to be able to support multiple python3 versions (as we currently support python3.4 and python3.5). There are a few differences: All or not -all Python3 transitions are much easier when C extensions are compiled for all supported versions. In many cases all that s needed if you use pybuild is to build-depend on python3-all-dev. While this is preferred, in many cases this would be technically challenging and not worth the trouble. This is mostly true for python3 based applications. Python3-all is mostly useful for running test suites against all supported python3 versions. Transitions As mentioned in the python section above, build-depends on python3- all- dev is generally only needed for compiled C extensions. For python3 these are also the packages that need to be rebuilt for a transition. Please avoid -dev build-depends whenever possible for non-compiled packages. Please keep your packages that do need rebuilding binNMU safe. Transitions happen in three stages:
  1. A new python3 version is added to supported python3 versions and packages that need rebuilding due to compiled code and that support multiple versions are binNMUed to add support for the new version.
  2. The default python3 is changed to be the new version and packages that only support a single python3 version are rebuilt.
  3. The old python3 version is dropped from supported versions and packages will multiple-version support are binNMUed to remove support for the dropped version.
This may seem complex (OK, it is a bit), but it enables a seamless transition for packages with multi-version support since they always support the default version. For packages that only support a single version there is an inevitable period when they go uninstallable once the default version has changed and until they can be rebuilt with the new default. Specific version requirements Please don t build-depend against specific python3 versions. Those don t show up in the transition tracker. Use X-Python3-Version (see python policy for details) to specify the version you need.

Summary Please check your packages and only build-depend on the -dev packages when you need it. Check for redundancy and remove it. Try and build for all python3 versions. Don t build-depend on specific python3 versions.

13 January 2016

Raphaël Hertzog: Freexian s report about Debian Long Term Support, December 2015

A Debian LTS logoLike each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In December, 113.50 work hours have been dispatched among 9 paid contributors. Their reports are available: Evolution of the situation We lost our first silver sponsor (Gandi.net, they prefer to give the same amount of money to Debian directly) and another sponsor reduced his sponsorship level. While this won t show in the hours dispatched in January, we will do a small jump backwards in February (unless we get new sponsors replacing those in the next 3 weeks). This is a bit unfortunate as we are rather looking at reinforcing the amount of sponsorship we get as we approach Wheezy LTS and we will need more support to properly support virtualization related packages and other packages that were formerly excluded from Squeeze LTS. Can you convince your company and help us reach our second goal? In terms of security updates waiting to be handled, the situation is close to last month. It looks like that having about 20 packages needing an update is the normal situation and that we can t really get further down given the time required to process some updates (sometimes we wait until the upstream authors provides a patch, and so on). Thanks to our sponsors We got one new bronze sponsor but he s not listed (he did not fill the form where we request their permission to be listed).

2 comments Liked this article? Click here. My blog is Flattr-enabled.

11 January 2016

Scott Kitterman: 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

10 January 2016

Scott Kitterman: 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.

Next.