Introduction NX is a software suite which implements very efficient compression of the X11 protocol. This increases performance when using X applications over a network, especially a slow one. NX (v3) has been originally developed by NoMachine and has been Free Software ever since. Since NoMachine obsoleted NX (v3) some time back in 2013/2014, the maintenance has been continued by a versatile group of developers. The work on NX (v3) is being continued under the project name "nx-libs". History Until January 2015, nx-libs was more mainly a redistribution approach of the original NX (v3) software. We (we as in mainly a group of X2Go developers) kept changes applied to the original NoMachine sources as minimal as possible. We also kept the original files and folders structure. Patches had been maintained via the quilt utility on top of a Git repository, the patches had always been kept separate. That was the 3.5.0.x series of nx-libs. In January 2015, the characteristics of nx-libs as maintained by the X2Go project between 2011 and 2015 changed. A decision was reached:

• Drop quilt patching approach
• Apply all already used patches to the code via Git
• Clean-up the complete source code tree
• Start backporting code from X.org
• Add new features, upgrade API/ABI and X11 extensions

This effort is now about to be released as "nx-libs 3.6.0.0". Contributors Since 2011, the nx-libs code base has to a great extent been maintained in the context of the X2Go Project [1]. Qindel Group joining in... In 2014, developers from the Qindel Group [2] joined the nx-libs maintenance. They found X2Go's work on nx-libs and suggested joining forces as best as possible on hacking nx-libs. The Arctica Project comming up... Starting in January 2015, the development on the 3.6.x branch of the project was moved into a new project called the Arctica Project [3]. Development Funding by Qindel In September 2015, a funding project was set up at Qindel. Since then, the Qindel group greatly supports the development of nx-libs 3.6.x monetarily and with provided man power. The funding project officially is a cooperation between Qindel and DAS-NETZWERKTEAM (business run by Mike Gabriel, long term maintainer of nx-libs). The funding is split into two subprojects and lasts until August 2017:

• Work on nx-libs (coordinated by DAS-NETZWERKTEAM, Mike Gabriel)
• Work on multimedia support in remote graphical sessions (coordinated by Guangzhou Nianguan Electronics Technology Co.,Ltd)

The current nx-libs development effort is coordinated in the context of the Arctica Project (by Mike Gabriel), with use cases in Arctica, X2Go and TheQVD (VDI product worked on at Qindel) in mind. People involved There are various people involved in nx-libs 3.6.x maintenance and development, some of them shall be explicitly named here (in alphabetical order of surnames):

• Mario Becroft (long term NX contributor)
• Nicolas Arenas Alonso (funding project coordinator at Qindel)
• Mike DePaulo (CVE hunter)
• Salvador Fandi o (developer, code reviewer, provided by Qindel)
• Mike Gabriel (development coordination, developer, packager)
• The GZNGET FLOSS Team (Arctica Project developer, advisory)
• Jordi Marqu s (Arctica Project infrastructure maintainer)
• Mihai Moldovan (developer, code reviewer)
• Ulrich Sibiller (developer, code reviewer)
• Vadim Troshchinskiy (developer, code reviewer, provided by Qindel)

Some other people have contributed, but have left the project already. Thanks for your work on nx-libs:

• Fernando Carvajal (contributor, provided by Qindel)
• Reinhard Tartler (contributor to X2Go)

A big thanks to everyone involved!!! Special thanks go to Stefan Baur for employing Mihai Moldovan and handling all the bureaucracy, so that Mihai can work on this project and get funded for his work. Achievements of nx-libs 3.5.99.0 We are very close to our self-defined release goal 3.6.0. The below tasks have already been (+/-) completed for version 3.5.99.0:

• CVE security audit (complete)
• remove unused code (+/- complete)
• no bundled non-X11 libraries anymore (complete)
• complete imake cleanup (+/- complete)
• replace as many libNX_X - libraries by X.org's libX - libraries (complete, only remaining library: libNX_X11)
• support for iOS (nxproxy, complete)
• Unix file socket communication for nxproxy -C <-> nxproxy -S connections (complete)
• allow Unix file sockets as channel endpoints (complete)
• new RandR based Xinerama extension (+/- complete, more QA needed)
• nxcomp protocol clean-up (complete)
• RandR Xserver extension upgrade to protocol version 1.5 (complete, from version 1.2)
• Composite Xserver extension upgrade to proto version 0.4 (complete, from version 0.2)
• various ABI/API updates (with respect to X.org), so that extension backporting should be easy now (+/- complete)

In a previous blog post [4], the code reduction in nx-libs has already been discussed. With this announcement, we want to give a status update about our effort of shrinking the nx-libs code base:

    [mike@minobo nx-libs (3.6.x)]$ cloc --match-f '.*\.(c cpp h)' .
        1896 text files.
        1896 unique files.                                          
        7430 files ignored.
    http://cloc.sourceforge.net v 1.60  T=5.88 s (307.3 files/s, 143310.5 lines/s)
    -------------------------------------------------------------------------------
    Language                     files          blank        comment           code
    -------------------------------------------------------------------------------
    C                              958          68574          74891         419638
    C/C++ Header                   730          25683          33957         130418
    C++                            120          17007          11721          61292
    -------------------------------------------------------------------------------
    SUM:                          1808         111264         120569         611348
    -------------------------------------------------------------------------------

The previous statistics had these sums in the last line. First the nx-libs 3.5.0.x code tree (where we came from):

    -------------------------------------------------------------------------------
    SUM:                          5614         329279         382337        1757743
    -------------------------------------------------------------------------------

Then the nx-libs 3.6.x status as it was on May 9th 2016:

    -------------------------------------------------------------------------------
    SUM:                          1922         118581         126783         662635
    -------------------------------------------------------------------------------

Another 50.000 lines of code have been removed over the past two months. Work pending for the final 3.6.0 release goal

• allow embedding of nxproxy into other windows (work pending)
• Fix the Composite extension in nx-X11 Xserver (work pending)
• nxcomp logging clean-up (work pending)
• optimizing documentation: how to tune NX connections (work pending)
• XServer extension upgrades:
  • XInput 1.3 -> 1.4 (work pending)
  • Xfixes 3.0 -> 5.0 (work in progress)
  • Damage 1.0 -> 1.1 (work pending)
  • Xres 1.0 -> 2.0 (work pending)
  • Sync 1.0 -> 3.0 (work pending)
  • Render 0.10 -> 0.11 (work pending)
• Drop as many X11 related proto headers as possible

Known Issues There are several open issues on the nx-libs Github project space, see https://github.com/ArcticaProject/nx-libs/issues. Testing the nx-libs 3.5.99.0 We are currently working on provisioning release builds and nightly builds of nx-libs for various recent Linux distributions. Please stay tuned and watch Mike Gabriel's blog [5]. We already have nightly builds of nx-libs for Debian and Ubuntu [6], but there are more to come soon. Until now, please use the build recipes provided in the README.md file of the nx-libs source tree [7]. References

• [1] http://wiki.x2go.org
• [2] http://www.qindel.com
• [3] https://arctica-project.org
• [4] https://sunweavers.net/blog/node/39
• [5] https://sunweavers.net
• [6] https://sunweavers.net/blog/node/20
• [7] https://github.com/ArcticaProject/nx-libs/blob/3.6.x/README.md

I had my strong doubts as to whether the shipment would be allowed through customs, and was happily surprised by a smiling Graham today before noon. He handed me a smallish box that arrived to his office, containing... Our fifty C.H.I.P. computers, those I offered to give away at DebConf! The little machines are quite neat. They are beautiful little devices, including even a plastic back (so you can safely work with it over a conductive surface or things like that). Quite smaller than the usual Raspberry-like format. It has more than enough GPIO to make several of my friends around here drool about the possibilities. So, what's to this machine besides a nice small ARM CPU, 512MB RAM, wireless connectivity (Wifi and bluetooth)? Although I have not yet looked into them (but intend to do so very soon!), it promises to have the freest available hardware around, and is meant for high hackability! And not that it matters But we managed to import them all, legally and completely hassle-free, into South Africa! That's right We are all used to the declaring commercial value as one dollar mindset. But... The C.H.I.P.s are actually priced at US$9 a piece. The declared commercial value is US$450. South Africans said all their customs are very hard to clear But we were able receive 50 legally shipped computers, declared at their commercial value, without any hassles! (yes, we might have been extremely lucky as well) Anyway, stay tuned By Thursday I will announce the list of people that get to take one home. I still have some left, so feel free to mail me at gwolf+chip@gwolf.org.

At least a little much more time lst month for helping to improve the operating system we're working on. I've worked on a couple of package updates, mostly they are for PAPT, DPMT, Debian Science, or pkg-go (in order of completion):

• ocrodjvu/0.9.2-1
• ocrodjvu/0.10-1
• python-djvulibre/0.7.2-1
• golang-github-masterzen-simplexml/0.0~git20140219.95ba304-2
• golang-github-tent-http-link-go/0.0~git20130702.0.ac974c6-2 (team upload)
• golang-github-masterzen-xmlpath/0.0~git20140218.13f4951-2 (all these fixed to test with golang-gopkg-check.v1)
• afl-cov/0.6-1
• afl/2.14b-1
• afl/2.16b-1
• pylint-django/0.7.2-1 (team upload)
• prospector/0.12-1
• pyuca/1.1.2-1 (team upload)
• python-jstontest/1.2-2
• python-svg.path/2.1.1-1 [RFA]
• python-xmp-toolkit/2.0.1+git20140309.5437b0a-3 [RFA] (closed #815305)
• sphinx-argparse/0.1.15-2 (closed #827813)
• vcr.py/1.7.3-2 [RFA]
• pyinfra/0.1~dev26-1
• pyomo/4.3.11388-1
• pyomo/4.3.11388+git20160622.d3e3f0a-1 (closed #823306)
• python-bcrypt/3.0.0-1 (gladly closed #824952)
• pydocstyle/1.0.0-3 (ship transition script /usr/bin/pep257)
• pep8-naming/0.4.1-1
• afl/2.17b-1
• pep8-naming/0.4.1-2
• manuel/1.8.0-5 (team upload)
• theano/0.7-1 (upload to unstable)
• theano/0.7-2 (closed #824116)
• theano/0.7-3

New packages:

• python-jsontest/1.2-1 (needed for the Pyinfra tests)

Sponsored Uploads:

• dwarfutils/20160507+git20160523.9086738-1 (new shared library and several CVE fixes)
• dwarfutils/20160507+git20160523.9086738-2
• dwarfutils/20160613-1 (closed #827382, patched for reproducible builds)
• dwarfutils/20160613-2 (closed #827921, now co-installable with libdw-dev)
• dwarfutils/20160613-3 (upload to unstable)
• squirrel3/3.1-3 (closed #828963)

Again some further ahead with these ones. My "new package of the month" is going to be Theano. I'm still working on the introduction, it'll come hereafter very soon.

What happened in the Reproducible Builds effort between June 19th and June 25th 2016. Media coverage

• Holger Levsen gave a talk at openSUSE Conference 2016 explaining the general idea and status of Reproducible Builds. This talk is available as video recording.
• This was followed by Bernhard Wiedemannn, detailing his work on Reproducible Builds for openSUSE which is also available as video recording:
  • openSUSE uses SOURCE_DATE_EPOCH now too
  • How to create bit-for-bit identical RPMs
  • How strip-nondeterminism is Python and thus unsuitable for the openSUSE base system
• Mozilla awarded $77k to work on reproducible builds for Tails. The goal is to enable anyone (given sufficient technical skills and hardware resources) to rebuild from source a given Tails release, in order to independently verify that it matches the ISO image that was published. A substantial part of this work will be done in Debian: for example, to make the side-effects of some packages' post-installation scripts deterministic. On the longer term, this work should benefit other projects that want to make their own builds reproducible (e.g. operating system images for the cloud and embedded systems, operating system installation media, other Live systems).

GSoC and Outreachy updates

• Valerie Young published a report detailing what she did the last week regarding improving tests.reproducible-builds.org/debian.
• Ceridwen announced reprotest's arrival in the NEW queue and discussed autopkgtest's layout.

Toolchain fixes

• Anton Gladky uploaded an NMU of python-setuptools, which sorts entries in native_libs.txt files (#825857).

Other upstream fixes Emil Velikov searched on IRC for hints on how to guarantee unique values during build to invalidate shader caches in Mesa, when also no VCS information is available. A possible solution is a timestamp, which is unique enough for local builds, but can still be reproducible by allowing it to be overwritten with SOURCE_DATE_EPOCH. Packages fixed The following 9 packages have become reproducible due to changes in their build dependencies: cclib librun-parts-perl llvm-toolchain-snapshot python-crypto python-openid r-bioc-shortread r-bioc-variantannotation ruby-hdfeos5 sqlparse The following packages have become reproducible after being fixed:

• allegro4.4/2:4.4.2-9 by Tobias Hansen, original patch by Reiner Herrmann.
• atomicparsley/0.9.6-1 by Jonas Smedegaard.
• dwarfutils/20160613-1 by Fabian Wolff, original patch by Reiner Herrmann.
• dwm/6.1-3 by Hugo Lefeuvre, original patch by Reiner Herrmann.
• funtools/1.4.6+git150811-3 by Ole Streicher, original patch by Alexis Bienven e.
• golang-github-appc-spec/0.8.4+dfsg-1 by Dmitry Smirnov.
• golang-github-appc-docker2aci/0.11.1+dfsg-1 Dmitry Smirnov.
• hdf-eos5/5.1.15.dfsg.1-7 by Alastair McKinstry.
• hmmer2/2.3.2-11 by Sascha Steinbiss, original patch by Chris Lamb.
• jpy/0.8-2 by Alastair McKinstry.
• lazarus/1.6+dfsg-4 by Paul Gevers.
• pgbackrest/1.02-2 by Adrian Vondendriesch.
• siege/4.0.2-1 by Josue Abarca.
• starlink-pal/0.5.0-4 by Ole Streicher, original patch by Chris Lamb.
• stylish-haskell/0.5.17.0-2 by Sean Whitton.
• xprobe/0.3-3 by Sophie Brun, original patch by Reiner Herrmann.

Some uploads have fixed some reproducibility issues, but not all of them:

• hdfeos4/2.19v1.00+dfsg.1-5 by Alastair McKinstry.
• icu4j/57.1-2 by Tony Mancill, original patch by Chris Lamb.
• pari/2.7.6-1 by Bill Allombert,

Patches submitted that have not made their way to the archive yet:

• #827684 against cgoban by Chris Lamb: set SHELL to static value.
• #827731 against tin by Alexis Bienven e: drop patch which overwrites __DATE__/__TIME__ macros, since gcc can handle it now
• #827863 against swedish by Alexis Bienven e: use C locale for sorting.
• #827987 against glances by Chris Lamb: Use SOURCE_DATE_EPOCH for embedded timestamp.
• #827994 against cmtk by Chris Lamb: use C locale for sorting.
• #828008 against aghermann by Chris Lamb: honour SOURCE_DATE_EPOCH for timestamps embedded into manpages.
• #828012 against bind9 by Chris Lamb: honour SOURCE_DATE_EPOCH for embedded timestamp.
• #828017 against frog by Chris Lamb: don't include pyc/pyo files in the package.
• #828021 against extra-cmake-modules by Scarlett Clark: normalize permission and file order in tarballs.
• #828060 against libffado by Chris Lamb: exclude file with test output from package.
• #828066 against gsmlib by Chris Lamb: honour SOURCE_DATE_EPOCH for timestamps embedded into manpages.
• #828067 against grib-api by Chris Lamb: exclude pyc files from package.
• #828122 against libxmlbird by Chris Lamb: sort list of globbed files.
• #828123 against magnum by Chris Lamb: use static value for embedded hostname.
• #828131 against pyjwt by Chris Lamb: exclude coverage data from package.
• #828145 against mkdocs by Chris Lamb: honour SOURCE_DATE_EPOCH for embedded timestamp.
• #828164 against zeal by Chris Lamb: use UTC for embedded timestamp.
• #828168 against x42-plugins by Daniel Shahaf: use printf instead of non-portable echo.

Package reviews 139 reviews have been added, 20 have been updated and 21 have been removed in this week. New issues found:

• timestamps_in_pdf_generated_by_reportlab
• r_base_appends_built_header_to_description_files
• timestamps_in_documentation_generated_by_mkdocs

53 FTBFS bugs have been reported by Chris Lamb, Santiago Vila and Mateusz ukasik. diffoscope development

• Satyam Zode added argument completion.
• Chris Lamb made the confusing "No differences found inside, yet data differs" message less confusing.

Quote of the week "My builds are so reproducible, they fail exactly every second time." Johannes Ziemke (@discordianfish) Misc. This week's edition was written by Chris Lamb (lamby), Reiner Herrmann and Holger Levsen and reviewed by a bunch of Reproducible builds folks on IRC.

On recent posts, I mentioned that I have a Chromebook, and that I would like to run Debian on devices that ship with old Linux versions. The Samsung ARM Chromebook is such a device, it has Linux 3.4, and that's still what I am running on it most of the time. After an upgrade of Debian, systemd stopped working, and it took me some time before I could look into it. In order to boot, I had to temporarily use System V init. The bug involves the use of new interfaces, bugs in such interfaces, and how versioning would not be a solution to such cases. Cases like this are not common, so it's no excuse to doing the right thing when developing software, like considering portability, API and ABI maintenance and not bundle. But they expose some of the challenges when trying to support different OSes on top of old versions of Linux, or maybe even new versions. The new version of systemd included in Debian Jessie uses a feature of Linux of checking the mount ID of a file by inspecting the mnt_id line in the fdinfo files. fdinfo files are not that new, they have been present since 2007, Linux 2.6.22. The mnt_id line, however, is from Linux 3.15, from 2014. So, a fairly new feature. But systemd falls back to other methods if the feature is not present. However, during the last few weeks of development of Linux 3.4, a bug was introduced to fdinfo handling, which will cause its access to fail in a way that will cause systemd to halt. It simply will refuse to mount the most basic filesystems and not proceed. The bug was fixed not much longer than two weeks after that, but that window of time was enough to have it on a shipped product, one that was not using systemd, let alone one that required a feature not yet present on Linux. But now I wanted to run this new systemd on this old Linux version. Being too early in the boot process, systemd even ignored some of the debug options and I had to resort to other methods of debugging. As I am running a kernel I built by myself, it wasn't hard for me to have a fixed kernel up and running after I found out the problem. Unfortunately, not everyone will be able to do it by themselves. And the point of getting different OSes working on these many varied devices is scaling. If every device needs to be tested, we lose this scalability. The other problem I found was that this old Linux version didn't load firmware files by itself, and requested help from userspace, which used to be the job of udev. Well, udev now does not support loading firmware, and the kernel must do it by itself. I managed to backport that feature too. But now, it sounds like I should get upstream support for this device. Unfortunately, this means not working on the scalability problem, but going back to get upstream support for a lot of devices out there, which is very hard to scale without the necessary people to do the work. I am certainly going to do that, because it's the right thing to do. But not as many people will benefit from that. But I think it has been interesting to look into the possible problems we might find when trying to make Debian and other OSes working on old Linux versions. I know even older Debian versions won't boot fine on Linux 2.6.32, one of the LTS versions of Linux. I have one other device which runs on it, and I am also working on getting better upstream support for it. Let's see if I can get some news on that soon.

For those who care about kdepim (kmail, kontact, korganizer, etc)

Currently the latest version of kdepim is available in experimental. According to our limited tests it's working way better than kdepim 4.14 (more stable, more performant, less bugs). However migrating from one to the other is not a trivial process (distribution wise, hopefully not for our users).

Among the drawbacks in the new kdepim: knode, ktimetracker and kjots were dropped from the official kdepim components. kjots is now an independent project, not tied to the kdepim release cycle. But more importantly, knode and ktimetracker are not maintained upstream any more, we are temporarily still shipping the old KDE 4 versions, but we will drop them after stretch unless they get new upstream maintainers.

To iron out the wrinkles that are surely still there, we are now planning to start a transition for kdepim, effectively blocking all kdepim related packages in unstable until the transition is complete. This will allow us to keep the current kdepim in testing unchanged until kdepim 16.04 is ready to migrate fully to testing.

If you want to test the new kdepim versions right now, please use the version in experimental, as uploading all the packages to unstable will take some time until there is a working kdepim in unstable (mixing experimental and the unstable uploads should be fine).

If you depend on having a working kdepim, please avoid installing the new kdepim packages that will be landing in unstable in the following days, until all the components are available. We expect this will take a couple of weeks, we will post another entry when the packages are ready in unstable.

A list of the binary packages involved in the transition can be found [here].

If you find issues in the new packages, please let us know either via irc in #debian-kde, the kde mailing list debian-kde@lists.debian.org, or send us a bug report (please make sure that it wasn't reported before).

We'll send an updated note when kdepim is fully uploaded to unstable.

Happy hacking,

I recently joined Linnovate, and while working on one of the open source projects the company produces, we needed to process video content according to NATO s standard agreement (STANAG) 4609: NATO Digital Motion Imagery Standard. Obviously we started with trying to find code already done, but we only found some implementation in Java, while our project is written in JavaScript. We decided to just implement the standard in the way most convenient to us, and later refactoring the project when more standards (STANAGs) will get implemented. So I m happy to introduce our new project: STANAG at https://github.com/linnovate/stanag , also available with NPM (see https://www.npmjs.com/package/stanag).
Filed under: Linnovate

Here is my monthly update covering a large part of what I have been doing in the free software world (previously):

• Updates to tickle-me-email, my Getting Things Done-inspired email toolbox:
  • Added the ability to inject arbitrary headers into draft messages. (#5)
  • Merged a documentation fix from Will Thompson. (#5)
• Improved my Chrome extension for the FastMail web interface:
  • Support appending arbitrary text in the Compose textarea to the subject via a context menu. (#4)
  • Avoid brittle parsing of the page and use the Javascript API instead. (diff)
• Updated my Strava Enhancement Suite, a Chrome extension that improves and fixes annoyances in the web interface of the Strava cycling and running tracker:
  • Merge support from Jeff Schuler to support "Flyby" activity defaults. (#50)
  • Correctly fallback to the default value after introducing a new value. (diff)
• Made a quick and dirty Kindle version of Derek Siver's book reviews. (repo)
• Improved my stravabot IRC bot to be more resilient on service failure. (diff)

---

In Australia we are about to have a federal election, so we inevitably have a lot of stupid commentary and propaganda about politics. One thing that always annoys me is the claim that we shouldn t have small parties. We have two large parties, Liberal (right-wing, somewhat between the Democrats and Republicans in the US) and Labor which is somewhat similar to Democrats in the US. In the US the first past the post voting system means that votes for smaller parties usually don t affect the outcome. In Australia we have Instant Runoff Voting (sometimes known as The Australian Ballot ) which has the side effect of encouraging votes for small parties. The Liberal party almost never wins enough seats to make government on it s own, it forms a coalition with the National party. Election campaigns are often based on the term The Coalition being used to describe a Liberal-National coalition and the expected result if The Coalition wins the election is that the leader of the Liberal party will be Prime Minister and the leader of the National party will be the Deputy Prime Minister. Liberal party representatives and supporters often try to convince people that they shouldn t vote for small parties and that small parties are somehow undemocratic , seemingly unaware of the irony of advocating for The Coalition but opposing the idea of a coalition. If the Liberal and Labor parties wanted to form a coalition they could do so in any election where no party has a clear majority, and do it without even needing the National party. Some people claim that it s best to have the major parties take turns in having full control of the government without having to make a deal with smaller parties and independent candidates but that s obviously a bogus claim. The reason we have Labor allying with the Greens and independents is that the Liberal party opposes them at every turn and the Liberal party has a lot of unpalatable policies that make alliances difficult. One thing that would be a good development in Australian politics is to have the National party actually represent rural voters rather than big corporations. Liberal policies on mining are always opposed to the best interests of farmers and the Liberal policies on trade aren t much better. If The Coalition wins the election then the National party could insist on a better deal for farmers in exchange for their continued support of Liberal policies. If Labor wins more seats than The Coalition but not enough to win government directly then a National-Labor coalition is something that could work. I think that the traditional interest of Labor in representing workers and the National party in representing farmers have significant overlap. The people who whinge about a possible Green-Labor alliance should explain why they aren t advocating a National-Labor alliance. I think that the Labor party would rather make a deal with the National party, it s just a question of whether the National party is going to do what it takes to help farmers. They could make the position of Deputy Prime Minister part of the deal so the leader of the National party won t miss out.

Hello world! I'm very happy to inform that the Next Thing Co. has shipped us a pack of 50 C.H.I.P. computers to be given away at DebConf! What is the C.H.I.P.? As their tagline says, it's the world's first US$9 computer. Further details:

https://nextthing.co/pages/chip

All in all, it's a nice small ARM single-board computer; I won't bore you on this mail with tons of specs; suffice to say they are probably the most open ARM system I've seen to date. So, I agreed with Richard, our contact at the company, I would distribute the machines among the DebConf speakers interested in one. Of course, not every DebConf speaker wants to fiddle with an adorable tiny piece of beautiful engineering, so I'm sure I'll have some spare computers to give out to other interested DebConf attendees. We are supposed to receive the C.H.I.P.s by Monday 4; if you want to track the package shipment, the DHL tracking number is 1209937606. Don't DDoS them too hard! So, please do mail me telling why do you want one, what your projects are with it. My conditions for this giveaway are:

• I will hand out the computers by Thursday 7.
• Preference goes to people giving a talk. I will "line up" requests on two queues, "speaker" and "attendee", and will announce who gets one in a mail+post to this list on the said date.
• With this in mind, I'll follow a strict "first come, first served".

To sign up for yours, please mail gwolf+chip@gwolf.org - I will capture mail sent to that alias ONLY.

Since quite a long time phpMyAdmin had embedded the bfShapeFiles library for import of geospatial data. Over the time we had to apply fixes to it to stay compatible with newer PHP versions, but there was really no development. Unfortunately, as it seems to be only usable PHP library which can read and write ESRI shapefiles. With recent switch of phpMyAdmin to dependency handling using Composer I wondered if we should get rid of the last embedded PHP library, which was this one - bfShapeFiles. As I couldn't find alive library which would work well for us, I resisted that for quite long, until pull request to improve it came in. At that point I've realized that it's probably better to separate it and start to improve it outside our codebase. That's when phpmyadmin/shapefile was started. The code is based on bfShapeFiles, applies all fixes which were used in phpMyAdmin and adds improvements from the pull request. On top of that it has brand new testsuite (the coverage is still much lower than I'd like to have) and while writing the tests several parsing issues have been discovered and fixed. Anyway you can now get the source from GitHub or install using Composer from Packagist. PS: While fixing parser bugs I've looked at other parsers as well to see how they handle some situations unclear in the specs and I had to fix Python pyshp on the way as well :-).

Filed under: Debian English phpMyAdmin 0 comments

There once was a Kingdom strongly United, built on the honours of the people of Wessex, of Mercia, Northumbria and East Anglia who knew how to deal with the invasion of the Vikings from the east and of Normans from the south, to come to unify the territory under an umbrella of common intents. Today, however, 48% of them, while keeping solid traditions, still know how to look forward to the future, joining horizons and commercial developments along with the rest of Europe. The remaining 52%, however, look back and can not see anything in front of them if not a desire of isolation, breaking the European dream born on the shores of Ventotene island in 1944 by Altiero Spinelli, Ernesto Rossi and Ursula Hirschmann through the Manifesto for a free and united Europe . An incurable fracture in the country was born in a referendum on 23 June, in which just over half of the population asked to terminate his marriage to the great European family, bringing the UK back by 43 years of history. <Read More [by Fabio Marzocca]>

DebConf16 will be held this and next week in Cape Town, South Africa, and we're happy to announce that the schedule is already available. Of course, it is still possible for some minor changes to happen! The DebCamp Sprints already started on 23 June 2016. DebConf will open on Saturday, 2 July 2016 with the Open Festival, where events of interest to a wider audience are offered, ranging from topics specific to Debian to a wider appreciation of the open and maker movements (and not just IT-related). Hackers, makers, hobbyists and other interested parties are invited to share their activities with DebConf attendees and the public at the University of Cape Town, whether in form of workshops, lightning talks, install parties, art exhibition or posters. Additionally, a Job Fair will take place on Saturday, and its job wall will be available throughout DebConf. The full schedule of the Debian Conference thorough the week is published. After the Open Festival, the conference will continue with more than 85 talks and BoFs (informal gatherings and discussions within Debian teams), including not only software development and packaging but also areas like translation, documentation, artwork, testing, specialized derivatives, maintenance of the community infrastructure, and other. There will also be also a plethora of social events, such as our traditional cheese and wine party, our group photo and our day trip. DebConf talks will be broadcast live on the Internet when possible, and videos of the talks will be published on the web along with the presentation slides. DebConf is committed to a safe and welcome environment for all participants. See the DebConf Code of Conduct and the Debian Code of Conduct for more details on this. Debian thanks the commitment of numerous sponsors to support DebConf16, particularly our Platinum Sponsor Hewlett Packard Enterprise. About Hewlett Packard Enterprise Hewlett Packard Enterprise actively participates in open source. Thousands of developers across the company are focused on open source projects, and HPE sponsors and supports the open source community in a number of ways, including: contributing code, sponsoring foundations and projects, providing active leadership, and participating in various committees.

In a prior post, I gave an overview of the OpenStack CI system and how jobs were started. In that I said

(It is a gross oversimplification, but for the purposes of OpenStack CI, Jenkins is pretty much used as a glorified ssh/scp wrapper. Zuul Version 3, under development, is working to remove the need for Jenkins to be involved at all).

Well some recent security issues with Jenkins and other changes has led to a roll-out of what is being called Zuul 2.5, which has indeed removed Jenkins and makes extensive use of Ansible as the basis for running CI tests in OpenStack. Since I already had the diagram, it seems worth updating it for the new reality.

What happened in the Reproducible Builds effort between June 12th and June 18th 2016: Media coverage

• Sune Vuorela blogged about making Qt documentation reproducible while spending good times in the Alps.

GSoC and Outreachy updates Weekly reports by our participants:

• Scarlett Clark
• Satyam Zode

Toolchain fixes

• texlive-bin/2016.20160513.41080-3 has been uploaded to unstable, featuring support for FORCE_SOURCE_DATE. See the last post for details on it.
• doxygen/1.4.4-1 has been uploaded to unstable, fixing #822197 (upstream bug), which caused some generated html file to contain unreproducible memory addresses of Python objects used at build time.
• debhelper/9.20160618 has been uploaded to unstable, fixing #824490, which instructs ant to not save the username of the build user in the generated files. Original patch by Emmanuel Bourg.
• HW42 reported a long-known (although only internally) bug in our dpkg-buildinfo. this particular bug doesn't affect our current infrastructure, but it's a blocker for having .buildinfo support merged upstream.
• epydoc/3.0.1+dfsg-13 and 3.0.1+dfsg-14 have been uploaded by Kenneth J. Pronovici which fixes nondeterministic ordering issues in generated documentation and removes memory addresses. Original patches (#825968 and #827416) by Sascha Steinbiss.

With this upload of texlive-bin we decided to stop keeping our patched fork of as most of the patches for SOURCE_DATE_EPOCH support had been integrated upstream already, and the last one (making FORCE_SOURCE_DATE default to 1) had been refused. So, we are now going to let the archive be rebuilt against unstable's texlive-bin and see how many packages will become unreproducible with this change; once enough data will be collected we will ponder whether FORCE_SOURCE_DATE should be exported by helper tools (such as debhelper) or manually exported by every package that needs it. (For those wondering: we still recommend to follow SOURCE_DATE_EPOCH always and don't recommend other projects to implement FORCE_SOURCE_DATE ) With the drop of texlive-bin we now have only three modified packages in our experimental repository. Reproducible work in other projects

• Ed Maste sent a patch to have ELF Tool Chain's elfcopy support SOURCE_DATE_EPOCH.
• Ed Maste changed FreeBSD's ar(1) to have a reproducible output by default when invoked with -s.
• Ed Maste merged changes from NetBSD's makefs to FreeBSD's to add a command line option for setting the timestamp.
• Ed Maste reported on FreeBSD package reproducibility details from the investigation for his BSDCan talk, including diffoscope results for the non-reproducible packages.
• Holger Levsen spent some time thinking and documenting how to store package notes and issues in a multi-distribution friendly manner, so that we can share these issues and notes between reproducible efforts across different projects. Thoughts we had about this topic during the Athens meeting last December are included in the updated README.

Packages fixed The following 12 packages have become reproducible due to changes in their build dependencies: django-floppyforms flask-restful hy jets3t kombu llvm-toolchain-3.8 moap python-bottle python-debtcollector python-django-debug-toolbar python-osprofiler stevedore The following packages have become reproducible after being fixed:

• adios/1.9.0-10 by Alastair McKinstry.
• airstrike/0.99+1.0pre6a-8 by Markus Koschany, original patch by Reiner Herrmann.
• apt-dater/1.0.3-1 by Patrick Matth i, original patch by Chris Lamb.
• bitlbee/3.4.2-1 by Jelmer Vernoo .
• dar/2.5.5-1 by Laszlo Boszormenyi.
• fastjet/3.0.6+dfsg-2 by Mattia Rizzolo, original patch by Maria Valentina Marin.
• libretro-beetle-pce-fast/0.9.38.7+git20160609-1 by S rgio Benjamim, original patch by Reiner Herrmann.
• libretro-beetle-psx/0.9.38.6+git20151019-2 by S rgio Benjamim, original patch by Reiner Herrmann.
• mx/1.99.4-1 by Ying-Chun Liu.
• python-coverage/4.1+dfsg.1-1 by Ben Finney.
• shiro/1.2.5-1 by Tony Mancill, original patch by Chris Lamb.
• splix/2.0.0+svn315-5 by Didier Raboud.
• u-boot/2016.07~rc1+dfsg1-3 by Vagrant Cascadian, debugging and patch by HW42, patches submitted upstream.

Some uploads have fixed some reproducibility issues, but not all of them:

• gcc-mingw-w64/18 by Stephen Kitt.
• gnuplot/5.0.3+dfsg3-6 by Anton Gladky, original patch by Alexis Bienven e.

Uploads with reproducibility fixes that currently fail to build:

• ruby2.3/2.3.1-3 by Christian Hofstaedtler, avoids unreproducible rbconfig.rb files by always using bash for building.

Patches submitted that have not made their way to the archive yet:

• #827109 against asciijump by Reiner Herrmann: sort source files for deterministic linking order.
• #827112 against boswars by Reiner Herrmann: sort source files for deterministic linking order.
• #827114 against overgod by Reiner Herrmann: use C locale for sorting source files.
• #827115 against netpbm by Alexis Bienven e: honour SOURCE_DATE_EPOCH while generating output.
• #827124 against funguloids by Reiner Herrmann: use C locale for sorting files.
• #827145 against scummvm by Reiner Herrmann: don't embed extra fields in zip archive and build with proper host architecture.
• #827150 against netpanzer by Reiner Herrmann: sort source files for deterministic linking order.
• #827172 against reaver by Alexis Bienven e: sort object files for deterministic linking order.
• #827187 against latex2html by Alexis Bienven e: iterate deterministic over Perl hashes; honour SOURCE_DATE_EPOCH for output; strip username from output; sort index keys.
• #827313 against cherrypy3 by Sascha Steinbiss: prevent memory addresses in output.
• #827361 against matplotlib by Alexis Bienven e: honour SOURCE_DATE_EPOCH in output and sort keys while iterating over dict.
• #827382 against dwarfutils by Reiner Herrmann: fix array size, which caused memory from outside a table to be embedded into output.
• #827384 against skytools3 by Sascha Steinbiss: use stable sorting order and remove timestamps from documentation.
• #827419 against ldaptor by Sascha Steinbiss: sort list of input files and prevent home directory from leaking into documentation.
• #827546 against git-buildpackage by Sascha Steinbiss: replace timestamps in documentation with changelog date; prevent temporary paths in documentation.
• #827572 against xprobe by Reiner Herrmann: sort list of object files in static library archives.

Package reviews 36 reviews have been added, 12 have been updated and 31 have been removed in this week. 17 FTBFS bugs have been reported by Chris Lamb, Santiago Vila and Dominic Hargreaves. diffoscope development Satyam worked on argument completion (#826711) for diffoscope. strip-nondeterminism development Mattia Rizzolo uploaded strip-nondeterminism 0.019-1~bpo8+1 to jessie-backports. reprotest development Ceridwen filed an Intent To Package (ITP) bug for reprotest as #827293. tests.reproducible-builds.org

• Mattia Rizzolo uploaded pbuilder 0.225 to unstable, providing built-in support for eatmydata. We're planning to use it in armhf and i386 builders where we don't build in tmpfs, to increase the build speed some more.
• Valery Young reworked the appearance of the package page, hopefully making them more intuitive and usable. In the process she changed the script generating them to use a real templating system, thus improving maintenance for the future.
• Holger adjusted the scheduler to reschedule packages in state 'depwait' after two days instead of three.
• Mattia added the bug title next to the bug numbers in the notes.

Misc. This week's edition was written by Mattia Rizzolo, Reiner Herrmann, Ed Maste and Holger Levsen and reviewed by a bunch of Reproducible builds folks on IRC.

I'm back from the GTK hackfest in Toronto, Canada and mostly recovered from jetlag, so it's time to write up my notes on what we discussed there. Despite the hackfest's title, I was mainly there to talk about non-GUI parts of the stack, and technologies that fit more closely in what could be seen as the freedesktop.org platform than they do in GNOME. In particular, I'm interested in Flatpak as a way to deploy self-contained "apps" in a freedesktop-based, sandboxed runtime environment layered over the Universal Operating System and its many derivatives, with both binary and source compatibility with other GNU/Linux distributions. I'm mainly only writing about discussions I was directly involved in: lots of what sounded like good discussion about the actual graphics toolkit went over my head completely :-) More notes, mostly from Matthias Clasen, are available on the GNOME wiki. In no particular order: Thinking with portals We spent some time discussing Flatpak's portals, mostly on Tuesday. These are the components that expose a subset of desktop functionality as D-Bus services that can be used by contained applications: they are part of the security boundary between a contained app and the rest of the desktop session. Android's intents are a similar concept seen elsewhere. While the portals are primarily designed for Flatpak, there's no real reason why they couldn't be used by other app-containment solutions such as Canonical's Snap. One major topic of discussion was their overall design and layout. Most portals will consist of a UX-independent part in Flatpak itself, together with a UX-specific implementation of any user interaction the portal needs. For example, the portal for file selection has a D-Bus service in Flatpak, which interacts with some UX-specific service that will pop up a standard UX-specific "Open" dialog for GNOME and probably other GTK environments, that dialog is in (a branch of) GTK. A design principle that was reiterated in this discussion is that the UX-independent part should do as much as possible, with the UX-specific part only carrying out the user interactions that need to comply with a particular UX design (in the GTK case, GNOME's design). This minimizes the amount of work that needs to be redone for other desktop or embedded environments, while still ensuring that the other environments can have their chosen UX design. In particular, it's important that, as much as possible, the security- and performance-sensitive work (such as data transport and authentication) is shared between all environments. The aim is for portals to get the user's permission to carry out actions, while keeping it as implicit as possible, avoiding an "are you sure?" step where feasible. For example, if an application asks to open a file, the user's permission is implicitly given by them selecting the file in the file-chooser dialog and pressing OK: if they do not want this application to open a file at all, they can deny permission by cancelling. Similarly, if an application asks to stream webcam data, the UX we expect is for GNOME's Cheese app (or a similar non-GNOME app) to appear, open the webcam to provide a preview window so they can see what they are about to send, but not actually start sending the stream to the requesting app until the user has pressed a "Start" button. When defining the API "contracts" to be provided by applications in that situation, we will need to be clear about whether the provider is expected to obtain confirmation like this: in most cases I would anticipate that it is. One security trade-off here is that we have to have a small amount of trust in the providing app. For example, continuing the example of Cheese as a webcam provider, Cheese could (and perhaps should) be a contained app itself, whether via something like Flatpak, an LSM like AppArmor or both. If Cheese is compromised somehow, then whenever it is running, it would be technically possible for it to open the webcam, stream video and send it to a hostile third-party application. We concluded that this is an acceptable trade-off: each application needs to be trusted with the privileges that it needs to do its job, and we should not put up barriers that are easy to circumvent or otherwise serve no purpose. The main (only?) portal so far is the file chooser, in which the contained application asks the wider system to show an "Open..." dialog, and if the user selects a file, it is returned to the contained application through a FUSE filesystem, the document portal. The reference implementation of the UX for this is in GTK, and is basically a GtkFileChooserDialog. The intention is that other environments such as KDE will substitute their own equivalent. Other planned portals include:

• image capture (scanner/camera)
• opening a specified URI
  • this needs design feedback on how it should work for non-http(s)
• sharing content, for example on social networks (like Android's Sharing menu)
• proxying joystick/gamepad input (perhaps via Wayland or FUSE, or perhaps by modifying libraries like SDL with a new input source)
• network proxies (GProxyResolver) and availability (GNetworkMonitor)
• contacts/address book, probably vCard-based
• notifications, probably based on freedesktop.org Notifications
• video streaming (perhaps using Pinot, analogous to PulseAudio but for video)

Environment variables GNOME on Wayland currently has a problem with environment variables: there are some traditional ways to set environment variables for X11 sessions or login shells using shell script fragments (/etc/X11/Xsession.d, /etc/X11/xinit/xinitrc.d, /etc/profile.d), but these do not apply to Wayland, or to noninteractive login environments like cron and systemd --user. We are also keen to avoid requiring a Turing-complete shell language during session startup, because it's difficult to reason about and potentially rather inefficient. Some uses of environment variables can be dismissed as unnecessary or even unwanted, similar to the statement in Debian Policy 9.9: "A program must not depend on environment variables to get reasonable defaults." However, there are two common situations where environment variables can be necessary for proper OS integration: search-paths like $PATH, $XDG_DATA_DIRS and $PYTHONPATH (particularly necessary for things like Flatpak), and optionally-loaded modules like $GTK_MODULES and $QT_ACCESSIBILITY where a package influences the configuration of another package. There is a stopgap solution in GNOME's gdm display manager, /usr/share/gdm/env.d, but this is gdm-specific and insufficiently expressive to provide the functionality needed by Flatpak: "set XDG_DATA_DIRS to its specified default value if unset, then add a couple of extra paths". pam_env comes closer PAM is run at every transition from "no user logged in" to "user can execute arbitrary code as themselves" but it doesn't support .d fragments, which are required if we want distribution packages to be able to extend search paths. pam_env also turns off per-user configuration by default, citing security concerns. I'll write more about this when I have a concrete proposal for how to solve it. I think the best solution is probably a PAM module similar to pam_env but supporting .d directories, either by modifying pam_env directly or out-of-tree, combined with clarifying what the security concerns for per-user configuration are and how they can be avoided. Relocatable binary packages On Windows and OS X, various GLib APIs automatically discover where the application binary is located and use search paths relative to that; for example, if C:\myprefix\bin\app.exe is running, GLib might put C:\myprefix\share into the result of g_get_system_data_dirs(), so that the application can ask to load app/data.xml from the data directories and get C:\myprefix\share\app\data.xml. We would like to be able to do the same on Linux, for example so that the apps in a Flatpak or Snap package can be constructed from RPM or dpkg packages without needing to be recompiled for a different --prefix, and so that other third-party software packages like the games on Steam and gog.com can easily locate their own resources. Relatedly, there are currently no well-defined semantics for what happens when a .desktop file or a D-Bus .service file has Exec=./bin/foo. The meaning of Exec=foo is well-defined (it searches $PATH) and the meaning of Exec=/opt/whatever/bin/foo is obvious. When this came up in D-Bus previously, my assertion was that the meaning should be the same as in .desktop files, whatever that is. We agreed to propose that the meaning of a non-absolute path in a .desktop or .service file should be interpreted relative to the directory where the .desktop or .service file was found: for example, if /opt/whatever/share/applications/foo.desktop says Exec=../../bin/foo, then /opt/whatever/bin/foo would be the right thing to execute. While preparing a mail to the freedesktop and D-Bus mailing lists proposing this, I found that I had proposed the same thing almost 2 years ago... this time I hope I can actually make it happen! Flatpak and OSTree bug fixing On the way to the hackfest, and while the discussion moved to topics that I didn't have useful input on, I spent some time fixing up the Debian packaging for Flatpak and its dependencies. In particular, I did my first upload as a co-maintainer of bubblewrap, uploaded ostree to unstable (with the known limitation that the grub, dracut and systemd integration is missing for now since I haven't been able to test it yet), got most of the way through packaging Flatpak 0.6.5 (which I'll upload soon), cherry-picked the right patches to make ostree compile on Debian 8 in an effort to make backports trivial, and spent some time disentangling a flatpak test failure which was breaking the Debian package's installed-tests. I'm still looking into ostree test failures on little-endian MIPS, which I was able to reproduce on a Debian porterbox just before the end of the hackfest. OSTree + Debian I also had some useful conversations with developers from Endless, who recently opened up a version of their OSTree build scripts for public access. Hopefully that information brings me a bit closer to being able to publish a walkthrough for how to deploy a simple Debian derivative using OSTree (help with that is very welcome of course!). GTK life-cycle and versioning The life-cycle of GTK releases has already been mentioned here and elsewhere, and there are some interesting responses in the comments on my earlier blog post. It's important to note that what we discussed at the hackfest is only a proposal: a hackfest discussion between a subset of the GTK maintainers and a small number of other GTK users (I am in the latter category) doesn't, and shouldn't, set policy for all of GTK or for all of GNOME. I believe the intention is that the GTK maintainers will discuss the proposals further at GUADEC, and make a decision after that. As I said before, I hope that being more realistic about API and ABI guarantees can avoid GTK going too far towards either of the possible extremes: either becoming unable to advance because it's too constrained by compatibility, or breaking applications because it isn't constrained enough. The current situation, where it is meant to be compatible within the GTK 3 branch but in practice applications still sometimes break, doesn't seem ideal for anyone, and I hope we can do better in future. Acknowledgements Thanks to everyone involved, particularly:

• Matthias Clasen, who organised the hackfest and took a lot of notes
• Allison Lortie, who provided on-site cat-herding and led us to some excellent restaurants
• Red Hat Inc., who provided the venue (a conference room in their Toronto office), snacks, a lot of coffee, and several participants
• my employers Collabora Ltd., who sponsored my travel and accomodation

Wheezy's LTS period started a few weeks ago and the LTS team had to make an early support decision concerning the Java eco-system since Wheezy ships two Java runtime environments OpenJDK 6 and OpenJDK 7. (To be fair, there are actually three but gcj has been superseded by OpenJDK a long time ago and the latter should be preferred whenever possible.) OpenJDK 6 is currently maintained by Red Hat and we mostly rely on their upstream work as well as on package updates from Debian's maintainer Matthias Klose and Tiago St rmer Daitx from Ubuntu. We already knew that both intend to support OpenJDK 6 until April 2017 when Ubuntu 12.04 will reach its end-of-life. Thus we had basically two options, supporting OpenJDK 6 for another twelve months or dropping support right from the start. One of my first steps was to ask for feedback and advice on debian-java since supporting only one JDK seemed to be the more reasonable solution. We agreed on warning users via various channels about the intended change, especially about possible incompatibilities with OpenJDK 7. Even Andrew Haley, OpenJDK 6 project lead, participated in the discussion and confirmed that, while still supported, OpenJDK 6 security releases are "always the last in the queue when there is urgent work to be done". I informed debian-lts about my findings and issued a call for tests later. Eventually we decided to concentrate our efforts on OpenJDK 7 because we are confident that for the majority of our users one Java implementation is sufficient during a stable release cycle. An immediate positive effect in making OpenJDK 7 the default is that resources can be relocated to more pressing issues. On the other hand we were also forced to make compromises. The switch to a newer default implementation usually triggers a major transition with dozens of FTBFS bugs and the OpenJDK 7 transition was no exception. I pondered about the usefulness of fixing all these bugs for Wheezy LTS again and focussing on runtime issues instead and finally decided that the latter was both more reasonable and more economic. Different from regular default Java changes, users will still be able to use OpenJDK 6 to compile their packages and the security impact for development systems is in general neglectable. More important was to avoid runtime installations of OpenJDK 6. I identified eighteen packages that strictly depended on the now obsolete JRE and fixed those issues on 4 May 2016 together with an update of java-common and announced the switch to OpenJDK 7 with a Debian NEWS file. If you are not a regular reader of Debian news and also not subscribed to debian-lts, debian-lts-announce or debian-java, remember 26 June 2016 is the day when OpenJDK 7 will be made the default Java implementation in Wheezy LTS. Of course there is no need to wait. You can switch right now: