Planet Debian

Subscribe to Planet Debian feed
Planet Debian -
Updated: 1 hour 50 min ago

Olivier Berger: Mixing NRELab’s Antidote and Eclipse Che on the same k8s cluster

3 June, 2020 - 05:06

You may have heard of my search for Cloud solutions to run labs in an academic context, with a focus on free an open source solutions . You may read previous installments of this blog, or for a shorter, check the presentation I’ve recorded last week.

I’ve become quite interested, in the latest month, in 2 projects: NRELab’s Antidote and  Eclipse Che.

Antidote is the software that powers NRELabs, a labs platform for learning network automation, which runs on top of Kubernetes (k8s). The interesting thing is that for each learner, there can be a dedicated k8s namespace with multiple virtual nodes running on a separate network. This can be used in the context of virtual classes/labs where our students will perform network labs in parallel on the same cluster.

Eclipse Che powers Eclipse “on the Cloud”, making available software development environments, for developers, on a Kubernetes Cloud. Developers typically work from a Web page instead of installing local development tools.

Both projects seem quite complementary. For one, we both teach networks and software developments. So that would naturally appeal for many professors.

Furthermore, Eclipse Che provides a few features that Antidote is lacking : authenticating users (with keycloak), and persisting their work in workspaces, between work sessions. Typically what we need in our academic context where students will work on the same labs during scheduled classes, week after week, during or off-hours.

Thus it would be great to have more integration between the 2 environments.

I intend to work on that front, but that takes time, as running stuff on Kubernetes isn’t exactly trivial, at least when you’re like me and want to use a “vanilla” kubernetes.

I’ve mainly relied on running k8s inside VMs using Vagrant and/or minikube so far.

A first milestone I’ve achieved is making sure that Antidote and Eclipse Che aren’t incompatible. Antidote’s “selfmedicate” script was actually running inside a Vagrant VM, where I had difficulties installing Eclipse Che (probably because of old software, or particular networking setup details). I’ve overcome this hurdle, as I’m now able to install both environments on a single Kubernetes VM (using my own Vagrant setup).

Running Eclipse Che (alongsite Antidote) on a k8s Vagrant VM.

This proves only that there’s no show stopper there, but a lot of work remains.

Stay tuned.

Sylvestre Ledru: Debian rebuild with clang 10 + some patches

3 June, 2020 - 04:45

Because of the lock-down in France and thanks to Lucas, I have been able to make some progress rebuilding Debian with clang instead of gcc.


Instead of patching clang itself, I used a different approach this time: patching Debian tools or implementing some workaround to mitigate an issue.
The percentage of packages failing drop from 4.5% to 3.6% (1400 packages to 1110 - on a total of 31014).

I focused on two classes of issues:


As I have no intention to merge the patch upstream, I used a very dirty workaround. I overwrote the g++ qmake file by clang's:

I dropped the number of this failure to 0, making some packages build flawlessly (example: qtcreator, chessx, fwbuilder, etc).

However, some packages are still failing later and therefore increasing the number of failures in some other categories like link error. For example, qtads fails because of ordered comparison between pointer and zero or oscar fails on a -Werror,-Wdeprecated-copy error.

Breaking the build later also highlighted some new classes of issues which didn't occur with clang < 10.
For example, warnings related to C++ range loop or implicit int float conversion (I fixed a bunch of them in Firefox) .

Symbol differences  

Historically, symbol management for C++ in Debian has been a pain. Russ Allbery wrote a blog post in 2012 explaining the situation. AFAIK, it hasn't changed much.
Once more, I took the dirty approach: if there new or missing symbols, don't fail the build.
The rational is the following: Packages in the Debian archive are supposed to build without any issue. If there is new or missing symbols, it is probably clang generating a different library but this library is very likely working as expected (and usable by a program compiled with g++ or clang). It is purely a different approach taken by the compiler developer.

In order to mitigate this issue, before the build starts, I am modifying dpkg-gensymbols to transform the error into a warning.
So, the typical Debian error some new symbols appeared in the symbols file or some symbols or patterns disappeared in the symbols file will NOT fail the build.

Unsurprisingly, all but one package (libktorrent) build.

Even if I am pessimistic, I reported a bug on dpkg-dev to evaluate if we could improve dpkg-gensymbol not to fail on these cases.

Next steps  

The next offender is Imake.tmpl:2243:10: fatal error: ' X11 .rules' file not found with more than an hundred occurrences, reported upstream quite sometime ago.

Then, the big issues are going to be much harder to fix as they are real issues/warnings (with -Werror) in the code of the packages. Example: -Wc++11-narrowing & Wreserved-user-defined-literal... The list is long.
I will probably work on that when llvm/clang 11 are in RC phase.

For maintainers & upstream  

Maintainer of Debian/Ubuntu packages? I am providing a list of failing packages per maintainer:
For upstream, it is also easy to test with clang. Usually, apt install clang && CC=clang CXX=clang++ <build step> is good enough.


With these two changes, I have been able to fix about 290 packages. I think I will be able to get that down a bit more but we will soon reach a plateau as many warnings/issues will have to fix in the C/C++ code itself.

Lisandro Damián Nicanor Pérez Meyer: Simplified Monitoring of Patients in Situations of Mass Hospitalization (MoSimPa) - Fighting COVID-19

2 June, 2020 - 19:49
I have been quite absent from Debian stuff lately, but this increased since COVID-19 hits us. In this blog post I'll try to sketch what I have been doing to help fight COVID-19 this last few months.
In the beginningWhen the pandemic reached Argentina the government started a quarantine. We engineers (like engineers around the world) started to think on how to put our abilities in order to help with the situation. Some worked toward providing more protection elements to medical staff, some towards increasing the number of ventilation machines at disposal. Another group of people started thinking on another ways of helping. In Bahía Blanca arised the idea of monitoring some variables remotely and in masse.

Simplified Monitoring of Patients in Situations of Mass Hospitalization (MoSimPa)
This is where the idea of remotely monitored devices came in, and MoSimPa (from the spanish of "monitoreo simplificado de pacientes en situación de internación masiva") started to get form. The idea is simple: oximetry (SpO2), heart rate and body temperature will be recorded and, instead of being shown in a display in the device itself, they will be transmitted and monitored in one or more places. In this way medical staff doesn't has to reach a patient constantly and monitoring could be done by medical staff for more patients at the same time. In place monitoring can also happen using a cellphone or tablet.
The devices do not have a screen of their own and almost no buttons, making them more cheap to build and thus more in line with the current economic reality of Argentina.

This is where the project Para Ayudar was created. The project aims to produce the aforementioned non-invasive device to be used in health institutions, hospitals, intra hospital transports and homes.

It is worth to note that the system is designed as a complementary measure for continuous monitoring of a pacient. Care should be taken to check that symptomps and overall patient status don't mean an inmediate life threat. In other words, it is NOT designed for ICUs.
All the above done with Free/Libre/Open Source software and hardware designs. Any manufacturing company can then use them for mass production.
The importance of early pneumonia detection
We were already working in MoSimPa when an NYTimes article caught or attention: "The Infection That’s Silently Killing Coronavirus Patients". From the article:
A vast majority of Covid pneumonia patients I met had remarkably low oxygen saturations at triage — seemingly incompatible with life — but they were using their cellphones as we put them on monitors. Although breathing fast, they had relatively minimal apparent distress, despite dangerously low oxygen levels and terrible pneumonia on chest X-rays.
This greatly reinforced the idea we were on the right track.
The project from a technical standpoint
As the project is primarily designed for and by Argentinians the current system design and software documentation is written in spanish, but the source code (or at least most of it) is written in english. Should anyone need it in english please do not hesitate in asking me.General system description
The system is comprised of the devices, a main machine acting as a server (in our case for small setups a Raspberry Pi) and the possibility of accessing data trough cell phones, tablets or other PCs in the network.The hardware
As of today this is the only part in which I still can't provide schematics, but I'll update this blog post and technical doc with them as soon as I get my hands into them.
Again the design is due to be built in Argentina where getting our hands on hardware is not easy. Moreover it needs to be as cheap as possible, specially now that the Argentinian currency, the peso, is every day more depreciated. So we decided on using an ESP32 as the main microprocessor and a set of Maxim sensors devices. Again, more info when I have them at hand.
The software
Here we have many more components to describe. Firstly the ESP32 code is done with the Arduino SDK. This part of the stack will receive many updates soon, as soon as the first hardware prototypes are out.
For the rest of the stack I decided to go ahead with whatever is available in Debian stable. Why? Well, Raspbian provides a Debian stable-based image and I'm a Debian Developer, so things should go just natural for me in that front. Of course each component has its own packaging. I'm one of Debian's Qt maintainers then using Qt will also be quite natural for me. Plots? Qwt, of course. And with that I have most of my necessities fulfilled. I choose PostgreSql as database server and Mosquitto as MQTT broker.
Between the database and MQTT is mosimpa-datakeeper. The piece of software from which medical staff monitor patients is unsurprisingly called mosimpa-monitor.
MoSimPa's monitor main screen
Plots of a patient's data

Alarm thresholds setup

And for managing patients, devices, locations and internments (CRUD anyone?) there is currently a Qt-based application called mosimpa-abm.
ABM main screen

ABM internments view
The idea is to replace it with a web service so it doesn't needs to be confined to the RPi or require installations in other machines. I considered using webassembly but I would have to also build PostgreSql in order to compile Qt's plugin.
Translations? Of course! As I have already mentioned the code is written in English. Qt allows to easily translate applications, so I keep a Spanish one as the code changes (and we are primarily targeting spanish-speaking people). But of course this also means it can be easily translated to whichever language is necessary.
Even if I am a packager I still have some stuff to fix from the packaging itself, like letting datakeeper run with its own user. I just haven't got to it yet.

A video showing the software in action
We are working towards getting the system certified by ANMAT, which is the Argentinian equivalent for EEUU's FDA.
While all the people involved are working ad-honorem funding is still required in order to buy materials, create the prototypes, etc. The project created payments links with Mercado Pago (in spanish and argentinian pesos) and other bank methods (PDF, also in spanish).
I repeat the links here with an aproximation to US$.
- 500 AR$ (less than 8 US$) - 1000 AR$ (less than 15 US$)- 2000 AR$ (less than 30 US$) - 3000 AR$ (less than 45 US$) - 5000 AR$ (less than 75 US$)
You can check the actual convertion rate in
The project was also presented at a funding call of argentinian Agencia de Promoción de la Investigación, el Desarrollo Tecnológico y la Innovación (Agencia I+D+i). 900+ projects where presented and 64 funded, MoSimPa between them.

Olivier Berger: Experimenting on distant labs and labs on the Cloud

2 June, 2020 - 18:59

I have delivered a speech last week about some ideas and experiments I have about the use of remote access and Cloud technologies for labs.

The presentation was in french originaly, so I’ve quickly translated my slides and recorded an english version.

I mention tools like Guacamole, MeshCentral, NRELab’s Antidote, Eclipse Che and Labtainers, as well as k8s and Docker, as interesting tools that may allow us to continue teaching in labs while allowing more flexibility, distant learning, and hopefully improved quality.

You can find the slides here:, and the recording is here:

Experimenting on distant labs and labs on the Cloud.

Sylvain Beucler: Debian LTS and ELTS - May 2020

2 June, 2020 - 18:29

Here is my transparent report for my work on the Debian Long Term Support (LTS) and Debian Extended Long Term Support (ELTS), which extend the security support for past Debian releases, as a paid contributor.

In May, the monthly sponsored hours were split evenly among contributors depending on their max availability - I was assigned 17.25h for LTS (out of 30 max; all done) and 9.25h for ELTS (out of 20 max; all done).

A survey will be published very shortly to gather feedback from all parties involved in LTS (users, other Debian teams...) -- let us know what you think, so we start the forthcoming new (Stretch) LTS cycle in the best conditions

Discussion is progressing on funding & governance of larger LTS-related projects. Who should decide: contributors, Freexian, sponsors? Do we fund with a percentage or by capping resources allocated on security updates? I voiced concerns over funding these at the expense of smaller, more organic, more recurrent tasks that are less easy to specify but greatly contribute to the overall quality nevertheless.

ELTS - Wheezy

  • mysql-connector-java: upgrade to 5.1.49, refresh patches, document/run test suite, prepare upload, prepare upgrade path (+ see LTS)
  • CVE-2020-3810/apt: triage (affected), enquire about failing test, run testsuite, security upload ELA 228-1

LTS - Jessie

  • ansible: global triage: finish last month's triage, fix affected versions, provide reproducer
  • ansible: backport patches to early version, security upload DLA 2202-1
  • mysql-connector-java: propose 5.1.49 update to all dists (+ see ELTS)
  • CVE-2019-20637/varnish: global triage: ping upstream, get PoC, determine status for all Debian dists, jessie not-affected
  • public IRC team meeting


Wouter Verhelst: SReview 0.6

2 June, 2020 - 17:40

... isn't ready yet, but it's getting there.

I had planned to release a new version of SReview, my online video review and transcoding system that I wrote originally for FOSDEM but is being used for DebConf, too, after it was set up and running properly for FOSDEM 2020. However, things got a bit busy (both in my personal life and in the world at large), so it fell a bit by the wayside.

I've now also been working on things a bit more, in preparation for an improved administrator's interface, and have started implementing a REST API to deal with talks etc through HTTP calls. This seems to be coming along nicely, thanks to OpenAPI and the Mojolicious plugin for parsing that. I can now design the API nicely, and autogenerate client side libraries to call them.

While at it, because libmojolicious-plugin-openapi-perl isn't available in Debian 10 "buster", I moved the docker containers over from stable to testing. This revealed that both bs1770gain and inkscape changed their command line incompatibly, resulting in me having to work around those incompatibilities. The good news is that I managed to do so in a way that keeps running SReview on Debian 10 viable, provided one installs Mojolicious::Plugin::OpenAPI from CPAN rather than from a Debian package. Or installs a backport of that package, of course. Or, heck, uses the Docker containers in a kubernetes environment or some such -- I'd love to see someone use that in production.

Anyway, I'm still finishing the API, and the implementation of that API and the test suite that ensures the API works correctly, but progress is happening; and as soon as things seem to be working properly, I'll do a release of SReview 0.6, and will upload that to Debian.

Hopefully that'll be soon.

Steinar H. Gunderson: Nageru 2.0.0 released

2 June, 2020 - 17:00

I've released version 2.0.0 of Nageru, my live video mixer. Obviously, version 2 of anything is a major milestone; in this case, it wasn't so much this specific release being so big, but the combined work that has gone on through the 1.x versions. (Also, if you go from 1.9.0 to 1.10.0, you can be pretty sure 2.0 is never coming!) There were several major features where I could probably have justified a 2.0 bump alone (e.g., the multichannel audio processing support, HTML5 graphics, slow motion through Futatabi, or the large reworking of the themes in 1.9.0), and now, it was time. Interestingly enough, despite growing by 40,000 lines or so since the 1.0.0 release four and a half years ago, the basic design has proved fairly robust; there are always things I would like to do different, but I'm fairly happy about how flexible and reliable things have turned out to be, even though my own use cases have shifted from simple conference video to complex sports productions.

The poster feature this time around is SRT support; SRT is a video transport protocol designed for running over the public Internet, with all its loss and such. I'm always a bit skeptical at people who try to reinvent TCP without TCP (often, the gains tend to be more about having worse congestion control, so that you push everyone else out), but SRT has a reasonable story in that if things really go wrong, it's better to drop packets/frames and go on with it instead of running forever. SRT is based around inserting controlled latency in the stream (by default 120 ms), so that there's room for some retransmits, and some FEC (forward error correction). Nageru 2.0.0 supports SRT cameras as inputs, so you can take e.g. your phone running Larix, point it to port 9710 on Nageru, and a new camera just instantly appears. (I've had to report a few bugs with the Larix people, but they've been very responsive.) SRT has huge momentum right now, and I believe it's only a question of time before it replaces RTMP as the de facto contribution protocol on the Internet, too.

As always, you can get the new version from the Nageru home page. Normally, I'd also make an upload to Debian, but the libsrt package is built against OpenSSL, which has license issues. So I'm waiting for bug #933180 to be fixed, and then we can run with it :-)

Jonathan Carter: Free Software Activities for 2020-05

1 June, 2020 - 23:57

I would say that this was a crazy month, but with everything ever escalating, does that even mean anything anymore?

I lost track of tracking my activities in the second half of the month, and I’m still not very good at logging the “soft stuff”, that is, things like non-technical work but that also takes up a lot of time, but will continue to work on it.

Towards the end of the month I spent a huge amount of time on MiniDebConf Online, I’m glad it all worked out, and will write a seperate blog entry on that. Thank you again to everyone for making it a success!

I’m also moving DPL activities to the DPL blog, so even though it’s been a busy month in the free software world… my activity log here will look somewhat deceptively short this month…

MiniDebConf Online

2020-05-06: Help prepare initial CfP mail.

2020-05-06: Process some feedback regarding accessibility on Jitsi.

Debian Packaging

2020-05-02: Upload package gnome-shell-extension-workspaces-to-dock (53-1) to Debian unstable.

2020-05-02: Upload package tetzle (2.1.6-1) to Debian unstable.

2020-05-06: Upload package bundlewrap (3.9.0-1) to Debian unstable.

2020-05-06: Accept MR#1 for connectagram.

2020-05-06: Upload package connectagram (1.2.11-1) to Debian unstable.

2020-05-07: Upload package gnome-shell-extension-multi-monitors (20-1) to Debian unstable (Closes: #956169).

2020-05-07: Upload package tanglet (1.5.6-1) to Debian unstable.

2020-05-16: Upload package calamares (3.2.24-1) to Debian unstable.

2020-05-16: Accept MR#1 for tuxpaint-config.

2020-05-16: Accept MR#7 for debian-live.

2020-05-18: Upload package bundlewrap (3.10.0) to Debian unstable.

Debian Mentoring

2020-05-02: Sponsor package gamemode (1.5.1-3) (Games team request).

2020-05-16: Sponsor package gamemode (1.5.1-4) (Games team request).

Mike Gabriel: My Work on Debian LTS (May 2020)

1 June, 2020 - 19:02

In May 2020, I have worked on the Debian LTS project for 14.5 hours (of 14.5 hours planned).

LTS Work
  • Frontdesk: CVE bug triaging for Debian jessie LTS: exim4, cups, log4net, apt, openconnect, libexif, json-c, tomcat8, and graphicsmagick.
  • review and sponsor upload to jessie-security: libexif (DLA-2214-1 [1], 5 CVEs)
  • review and sponsor upload to jessie-security: libexif (DLA-2222-1 [2], 4 CVEs)
  • upload to jessie-security: json-c (DLA-2228-1 [3] and DLA-2228-2 [4], 1 CVE)
  • upload to jessie-security: php-horde-gollem (DLA-2228-1 [5], 1 CVE)
  • upload to jessie-security: php-horde (DLA-2280-1) [6], 1 CVE)
  • start looking into the current FreeRDP (v1.1) and FreeRDP (v2) CVE hell...
Other security related work for Debian
  • review and sponsor uploads of libexif to stretch, buster and unstable (8 CVE fixes for stretch, 5 CVE fixes for buster) [7]
  • revisit long overdue uploads of ssvnc to stretch and buster (4 CVE fixes each) [8]
  • upload php-horde-gollem to stretch and buster (1 CVE fix each) [9]
  • upload php-horde to stretch and buster (1 CVE fix each) [10]
  • Many thanks to Hugh McMaster for handling all the libexif security upload preparations himself. This was really good work. Hugh, please consider becoming a(n official) developer in the Debian project (at the very least for Debian Maintainer status).

Debian GSoC Kotlin project blog: Kotlin Update

1 June, 2020 - 17:38
A Quick Recap from last year:

Kotlin is being packaged under the Google Summer of Code within the Debian organization itself. The major reason behind bringing Kotlin in Debian is to update all the Android packages which are now heavily dependent upon the Kotlin libraries.

The major work to bring Kotlin into Debian is done for the version 1.3.30, by Saif Abdul Cassim (goes by m36 on IRC) as a part of his GSoC'2019. All his contributions to the team can be found in his blog posts.

So, for now, we have a bootstrap package and a Kotlin package for the version with 1.3.30. There were still changes needed as we lacked some of the dependencies for Kotlin, and the source package lacked copyright information and didn’t comply with Debian standards.

What's the present year brought for Kotlin?

To be specific the following were mainly left dependencies for Kotlin:

  • JLine3
  • intellij-community-idea
  • kotlin-bootstrap

And, we lack documentation for the newbies in order to get them started :(

Most importantly the crucial part was and still is, to figure out how to upload the package?

For GSoC'20, three students are selected as a part of project Android SDK tools in Debian.

What's the work done/left?

Work Done

  • A couple of dependencies were completed and reside in NEW Queue, those include Jline3 (done by @samyak-jn, myself), and intellij-community-idea (finished by @The_LoudSpeaker, Raman Sarda).

  • The kotlin package residing in m36’s repository had a couple of issues that were needed to be fixed to meet Debian standards, but Kotlin was building fine locally with the mentioned dependencies. :D

  • I (Samyak Jain) took the work for converting all the commits to the patches as all the changes were made directly to the source, and henceforth fixed rules and control files to meet Debian Standards. Debian is very particular about its license policies. The copyright was a pending task that was completed for Good. The newer package exists at Samyak's repo.

  • I set up an initial wiki page for Kotlin as well, so everyone can follow. Thanks, Hans (@_hc) for the help with that. The wiki page for Kotlin exists here.

What's Blocking?

  • The most uncertain thing is to decide, how Kotlin will be uploaded to the Debian Archive?

What is the problem being faced?

The Kotlin-Bootstrap package consists of JAR files for various dependencies of kotlin such as Gradle, kotlin compiler, and kotlinx. The package is added to the build-depends of the main package so that the JAR files can be provided. Since the kotlin-bootstrap consists of binaries (JAR files), it is not feasible to upload the package as free software.

The other workaround was the Gradle 6.4 version, which consists of Kotlin files and generates a suitable JAR. But since the package needed Kotlin language itself, it was never updated, as it created a cyclic dependency.

Final workaround came, which proposed Kotlin to build from itself, that was a pretty impressive suggestion. But, we still have to look if the solution is feasible? Because, as far as I last checked and conversed with ebourg on the mailing list here, Emmanuel Bbourg mentioned very clearly that the rebuilt package is our interest. So, this is under WIP.

But, I fail to acknowledge the fact if we can drop the kotlin-bootstrap package totally, Kotlin will not be able to be built because each and every JAR file present in the bootstrap is needed.

That pretty much is the ongoing work and the update on the kotlin package. We intend to bring Kotlin to the Debian Archive as soon as possible :)

Have any queries or suggestions for Kotlin?

Please feel to drop a message at #debian-mobile channel on OFTC.

Utkarsh Gupta: FOSS Activites in May 2020

1 June, 2020 - 11:00

Here’s my (eighth) monthly update about the activities I’ve done in the F/L/OSS world.


This month marks my 15 months of contributing to Debian. And 6th month as a DD! \o/

Whilst I love doing Debian stuff, I have started spending more time on the programming side now. And I hope to keep it this for some time now.
Of course, I’ll keep doing the Debian stuff, but just lesser in amount.

Anyway, the following are the things I did in May.

Uploads: Other $things:
  • Hosted Ruby team meeting. Logs here.
  • Attended Debian Perl Sprints. Report here.
  • Sponsored git-repo-updater and mplcursors for Sudip.
  • Mentoring for newcomers.
  • FTP Trainee reviewing.
  • Moderation of -project mailing list.
  • Got selected for GSoC’20 for Debian!
Experimenting and improving Ruby libraries FTW!

I have been very heavily involved with the Debian Ruby team for over an year now.
Thanks to Antonio Terceiro (and GSoC), I’ve started experimenting and taking more interest in upstream development and improvement of these libraries.

This has the sole purpose of learning. It has gotten fun since I’ve started doing Ruby.
And I hope it stays this way.

This month, I opened some issues and proposed a few pull requests. They are:

  • Issue #802 against whenever for Ruby2.7 test failures.
  • Issue #8 against aggregate asking upstream for a release on rubygems.
  • Issue #104 against irb for asking more about Array.join("\n").
  • Issue #1391 against mail asking upstream to cut a new release.
  • Issue #1655 against rack reporting test failures in the CVE fix.
  • Issue #84 against ruby-dbus for help with Debian bug #836296.
  • Issue #85 against ruby-dbus asking if they still use rDoc for doc generation.
  • PR #9 against aggregate for dropping git from gemspec.
  • PR #804 against whenever for dropping git from gemspec.
  • Packaged ruby-cmath as it was split from Ruby2.7; cf: (#961213).
Debian LTS

Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success.

This was my eighth month as a Debian LTS paid contributor. I was assigned 17.25 hours and worked on the following things:

CVE Fixes and Announcements: Other LTS Work:
  • Triaged tika, freerdp, and apache2.
  • Mark CVE-2020-12105/openconnect as no-dsa not-affected for Jessie.
  • Mark CVE-2020-9489/tika as no-dsa ignored for Jessie.
  • Mark CVE-2020-11025/wordpres as not-affected for Jessie.
  • Add fix for Add fix for CVE-2019-18823/condor.
  • Requested CVE for bug#60251 against apache2.
  • Raised issue #947 against sympa reporting an incomplete patch for CVE-2020-10936.
  • Created the LTS Survey on the self-hosted LimeSurvey instance.
  • Attended the second LTS meeting. Logs here.
  • General discussion on LTS private and public mailing list.

Sometimes it gets hard to categorize work/things into a particular category.
That’s why I am writing all of those things inside this category.
This includes two sub-categories and they are as follows.


This month I could get the following things done:

  • Wrote and published my first Ruby gem/library/tool on RubyGems! 💯
    It’s open-sourced and the repository is here.
    Bug reports and pull requests are welcomed! 😉
  • Wrote a small Ruby script (available here) to install Ruby gems from Gemfile(.lock).
    Needed this when I hit a bug while using ruby-standalone, which Antonio fixed pretty quickly! 🚀
  • Had a coffee chat with John Coghlan! 🤗
    Tweet here.
Open Source:

Again, this contains all the things that I couldn’t categorize earlier.
Opened several issues and did a PR review:

  • Issue #15434 against phantomjs, asking to look into CVE-2019-17221. Still no action :/
  • Issue #947 against sympa, reporting an incomplete patch for CVE-2020-10936.
  • Issue #2102 against polybar, mentioning that the build is not reproducible.
  • Issue #5521 against libgit2, mentioning that the build is not reproducible.
  • Reviewed PR #5523 for polybar, which was a fix for the above issue.

Until next time.
:wq for today.

Paul Wise: FLOSS Activities May 2020

1 June, 2020 - 08:44

This month I didn't have any particular focus. I just worked on issues in my info bubble.

Changes Issues Review Administration
  • nsntrace: talk to upstream about collaborative maintenance
  • Debian: deploy changes, debug issue with GPS markers file generation, migrate bls/DUCK from alioth-archive to salsa
  • Debian website: ran map cron job, synced mirrors
  • Debian wiki: approve accounts, ping folks with bouncing email
Communication Sponsors

The apt-offline work and the libfile-libmagic-perl backports were sponsored. All other work was done on a volunteer basis.

Junichi Uekawa: Tired of staying inside in Tokyo.

1 June, 2020 - 07:13
Tired of staying inside in Tokyo.

Enrico Zini: Controversial inventors

1 June, 2020 - 06:00
Paul-Félix Armand-Delille - Wikipedia history people 2020-06-01 Paul-Félix Armand-Delille (3 July 1874 in Fourchambault, Nièvre – 4 September 1963) was a physician, bacteriologist, professor, and member of the French Academy of Medicine who accidentally brought about the collapse of rabbit populations throughout much of Europe and beyond in the 1950s by infecting them with myxomatosis. Charles F. Kettering - Wikipedia history people 2020-06-01 Charles Franklin Kettering (August 29, 1876 – November 25, 1958) sometimes known as Charles "Boss" Kettering[1] was an American inventor, engineer, businessman, and the holder of 186 patents.[2] He was a founder of Delco, and was head of research at General Motors from 1920 to 1947. Among his most widely used automotive developments were the electrical starting motor[3] and leaded gasoline.[4][5] In association with the DuPont Chemical Company, he was also responsible for the invention of Freon refrigerant for refrigeration and air conditioning systems. At DuPont he also was responsible for the development of Duco lacquers and enamels, the first practical colored paints for mass-produced automobiles. While working with the Dayton-Wright Company he developed the "Bug" aerial torpedo, considered the world's first aerial missile.[6] He led the advancement of practical, lightweight two-stroke diesel engines, revolutionizing the locomotive and heavy equipment industries. In 1927, he founded the Kettering Foundation, a non-partisan research foundation. He was featured on the cover of Time magazine on January 9, 1933. John Charles Cutler - Wikipedia history people 2020-06-01 John Charles Cutler (June 29, 1915 – February 8, 2003) was a senior surgeon, and the acting chief of the venereal disease program in the United States Public Health Service. After his death, his involvement in several controversial and unethical medical studies of syphilis was revealed, including the Guatemala and the Tuskegee syphilis experiments. Ivy Lee - Wikipedia history people 2020-06-01 Ivy Ledbetter Lee (July 16, 1877 – November 9, 1934) was an American publicity expert and a founder of modern public relations. Lee is best known for his public relations work with the Rockefeller family. His first major client was the Pennsylvania Railroad, followed by numerous major railroads such as the New York Central, the Baltimore and Ohio, and the Harriman lines such as the Union Pacific. He established the Association of Railroad Executives, which included providing public relations services to the industry. Lee advised major industrial corporations, including steel, automobile, tobacco, meat packing, and rubber, as well as public utilities, banks, and even foreign governments. Lee pioneered the use of internal magazines to maintain employee morale, as well as management newsletters, stockholder reports, and news releases to the media. He did a great deal of pro bono work, which he knew was important to his own public image, and during World War I, he became the publicity director for the American Red Cross.[1]

Chris Lamb: Free software activities in May 2020

1 June, 2020 - 05:22

Here is my monthly update covering what I have been doing in the free software world during May 2020 (previous month):

  • Opened a pull request against the kitty shell to set a default socket timeout when retrieving remote items via the icat command-line tool. (#659)

  • Opened a pull request to make the documentation for the Wand Python/ImageMagick graphics library to build in reproducible manner. [...]

  • Fixed an issue in my tickle-me-email library that implements Gettings Things Done (GTD)-like behaviours in IMAP inboxes to prevent a traceback when adding text attachments that were not valid UTF-8. ...]

In Lintian, the static analysis tool for Debian packages:

  • New features:

    • Check for packages that use ${misc:Pre-Depends) in the Depends field. (#961290)
    • Check for packages installing icon cache files directly under /usr/share/icons/hicolor as they will invariably clash with other packages. (#959855)
    • Check for Homepage fields in debian/control that point to known directory listing pages. (#960366)
    • Update data/fields/perl-provides. [...]
  • Bug fixes:

  • Reporting/output:

  • Code improvements:

    • Replace Copyright (C) with the Unicode copyright symbol for consistency [...] and update my copyright years [...].
    • Factor out matching Homepage fields to data/fields/bad-homepages. [...]
    • Various alterations for the continuous integration pipeline. [...][...]

Reproducible builds

One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. However, whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into ostensibly secure software during the various compilation and distribution processes.

The motivation behind the Reproducible Builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised.

The initiative is proud to be a member project of the Software Freedom Conservancy, a not-for-profit 501(c)(3) charity focused on ethical technology and user freedom.

Conservancy acts as a corporate umbrella allowing projects to operate as non-profit initiatives without managing their own corporate structure. If you like the work of the Conservancy or the Reproducible Builds project, please consider becoming an official supporter.

Elsewhere in our tooling, I made the following changes to diffoscope, our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues, including preparing and uploading versions 142, 143, 144, 145 and 146 to Debian:

  • Comparison improvements:

    • Improve fuzzy matching of JSON files as file now supports recognising JSON data. (#106)
    • Refactor .changes and .buildinfo handling to show all details (including the GnuPG header and footer components) even when referenced files are not present. (#122)
    • Use our BuildinfoFile comparator (etc.) regardless of whether the associated files (such as the orig.tar.gz and the .deb) are present. [...]
    • Include GnuPG signature data when comparing .buildinfo, .changes, etc. [...]
    • Add support for printing Android APK signatures via apksigner(1). (#121)
    • Identify "iOS App Zip archive data" as .zip files. (#116)
    • Add support for Apple Xcode .mobilepovision files. (#113)
  • Bug fixes:

    • Don't print a traceback if we pass a single, missing argument to diffoscope (eg. a JSON diff to re-load). [...]
    • Correct differences typo in the ApkFile handler. (#127)
  • Output improvements:

    • Never emit the same id="foo" anchor reference twice in the HTML output, otherwise identically-named parts will not be able to linked to via a #foo anchor. (#120)
    • Never emit an empty "id" anchor either; it is not possible to link to #. [...]
    • Don't pretty-print the output when using the --json presenter; it will usually be too complicated to be readable by the human anyway. [...]
    • Use the SHA256 over MD5 hash when generating page names for the HTML directory-style presenter. (#124)
  • Reporting improvements:

    • Clarify the message when we truncate the number of lines to standard error [...] and reduce the number of maximum lines printed to 25 as usually the error is obvious by then [...].
    • Print the amount of free space that we have available in our temporary directory as a debugging message. [...]
    • Clarify Command […] failed with exit code messages to remove duplicate exited with exit but also to note that diffoscope is interpreting this as an error. [...]
    • Don't leak the full path of the temporary directory in Command […] exited with 1 messages. (#126)
    • Clarify the warning message when we cannot import the debian Python module. [...]
    • Don't repeat stderr from {} if both commands emit the same output. [...]
    • Clarify that an external command emits for both files, otherwise it can look like we are repeating itself when, in reality, it is being run twice. [...]
  • Testsuite improvements:

    • Prevent apksigner test failures due to lack of binfmt_misc, eg. on Salsa CI and elsewhere. [...]
    • Drop .travis.yml as we use Salsa instead. [...]
  • Dockerfile improvements:

    • Add a .dockerignore file to whitelist files we actually need in our container. (#105)
    • Use ARG instead of ENV when setting up the DEBIAN_FRONTEND environment variable at runtime. (#103)
    • Run as a non-root user in container. (#102)
    • Install/remove the build-essential during build so we can install the recommended packages from Git. [...]
  • Codebase improvements:

    • Bump the officially required version of Python from 3.5 to 3.6. (#117)
    • Drop the (default) shell=False keyword argument to subprocess.Popen so that the potentially-unsafe shell=True is more obvious. [...]
    • Perform string normalisation in Black [...] and include the Black output in the assertion failure too [...].
    • Inline MissingFile's special handling of deb822 to prevent leaking through abstract layers. [...][...]
    • Allow a bare try/except block when cleaning up temporary files with respect to the flake8 quality assurance tool. [...]
    • Rename in_dsc_path to dsc_in_same_dir to clarify the use of this variable. [...]
    • Abstract out the duplicated parts of the debian_fallback class [...] and add descriptions for the file types. [...]
    • Various commenting and internal documentation improvements. [...][...]
    • Rename the Openssl command class to OpenSSLPKCS7 to accommodate other command names with this prefix. [...]
  • Misc:

    • Rename the --debugger command-line argument to --pdb. [...]
    • Normalise filesystem stat(2) "birth times" (ie. st_birthtime) in the same way we do with the stat(1) command's Access: and Change: times to fix a nondeterministic build failure in GNU Guix. (#74)
    • Ignore case when ordering our file format descriptions. [...]
    • Drop, add and tidy various module imports. [...][...][...][...]

I also performed a huge overhaul of diffoscope's website:

  • Add a completely new design. [...][...]
  • Add a separate, canonical page for every new release. [...][...][...]
  • Generate a 'latest release' section and display that with the corresponding date on the homepage. [...]
  • Add an RSS feed of our releases [...][...][...][...][...][...] and add to Planet Debian [...].
  • Dynamically generate our contributor list [...] and supported file formats [...] from the main Git repository.
  • Use Jekyll's absolute_url and relative_url where possible [...][...] and move a number of configuration variables to _config.yml [...][...].

Lastly, I made a large number of changes to the main Reproducible Builds website and documentation:

  • Rename the "Who" page to "Projects". [...]
  • Ensure that Jekyll enters the _docs subdirectory to find the _docs/ file after an internal move. (#27)
  • Wrap etc. in preformatted quotes. [...]
  • Wrap the SOURCE_DATE_EPOCH Python examples onto more lines to prevent visual overflow on the page. [...]
  • Correct a "preferred" spelling error. [...]

Debian LTS

This month I contributed 17¼ hours to Debian Long Term Support (LTS) and 9¼ hours on its sister Extended LTS project.

  • Investigated and triaged freerdp, keystone, nginx, tcpreplay & thunderbird, as well as tended to the general upkeep of the dla-needed.txt and ela-needed.txt files, adding various notes, references, attributions and citations.

  • Frontdesk duties including responding to user/developer questions, reviewing others' packages, participating in mailing list discussions as well as attending our second regular IRC contributor meeting.

  • Issued DLA 2201-1 to prevent a Denial of Service (DoS) vulnerability the ntp network time protocol server/client. ntp allowed an "off-path" attacker to block unauthenticated synchronisation via a server mode packet with a spoofed source IP address because transmissions were rescheduled even if a packet lacked a valid "origin timestamp".

  • Issued DLA 2203-1 for the SQLite database to prevent a denial of service attack. In the event of a semantic error in an aggregate query, SQLite did not return early from the resetAccumulator() function which would lead to a crash via a segmentation fault.

  • Issued DLA 2204-1 for the Mailman mailing list manager to prevent an arbitrary content injection attack.

  • Issued DLA 2211-1 in order to prevent an XML external entity vulnerability in log4net, a logging API for the ECMA Common Language Infrastructure (CLI), sometimes referred to as "Mono". This type of attack occurs when XML input containing a reference to an internet-faced entity is processed by a weakly configured XML parser.

  • Prepared and issued ELA-229-1 and DLA 2217-1 for the Apache Tomcat Java server to prevent a remote code execution exploit.

You can find out more about the two projects via the following video:


I filed the following bug reports in Debian this month:

  • apksigner: Uses en-dashes (U+2013) in manpage over two hyphens. (#960778)

  • devscripts: dd-list -nou results in "unknown option: […]". (#960891)

  • node-redis: autopkgtest regressions against Redis 6.x. (#960105)

I also filed a number of bugs against packages that are not compatible with Django 3.x, (organised around a single master bug) including django-taggit, sorl-thumbnail, django-simple-captcha, django-cas-server, django-cors-headers, python-django-csp, django-pipeline, python-django-jsonfield, python-django-contact-form, django-model-utils, django-fsm, django-modeltranslation, django-oauth-toolkit, libthumbor, python-django-extensions, python-django-imagekit, python-django-navtag, python-django-tagging, djangorestframework, django-haystack, django-taggit, django-simple-captcha, python-django-registration, python-django-pyscss, python-django-compressor, python-django-crispy-forms & python-django-mptt,

Lastly, I made the following uploads to Debian:

I also sponsored an upload for adminer (4.7.7-1), also uploading it to buster-backports.

Dirk Eddelbuettel: T^4 #4: Introducing Byobu

1 June, 2020 - 04:28

The next video (following the announcement, and shells sessions one, two, and three) is up in the T^4 series of video lightning talks with tips, tricks, tools, and toys. This time we introduce the wonderful byobu tool which is called both a ‘text-based window manager’ and a ‘terminal multiplexer’:

The slides are here.

This repo at GitHub support the series: use it to open issues for comments, criticism, suggestions, or feedback.

If you like this or other open-source work I do, you can now sponsor me at GitHub. For the first year, GitHub will match your contributions.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Jonathan Dowland: Golf Peaks

31 May, 2020 - 20:17


This one was a bit of a surprise hit. Golf Peaks is a Golf-themed puzzle game. The objective is to get the golf ball into the hole, obviously, but how you do that is by choosing from a set of fixed moves (e.g., move one square; jump one square; etc.) and a direction.

This works well with my eldest daughter. She takes one joy-con and I take the other. I typically am responsible for direction, and she hits 'A' to move the ball. We discuss which move to make, which has been a good test of her numeracy.

Jonathan McDowell: OpenOCD snapshot uploaded to Debian experimental

31 May, 2020 - 17:34

One of the things I maintain in Debian is OpenOCD. I say maintain, but it’s so far required very little work, as it’s been 3 years since a release (0.10.0). I’ve talked about doing a git snapshot package for some time (I have an email from last DebConf in my inbox about it, and that wasn’t the first time someone had asked), but never got around to it. Spurred on by some moves towards a 0.11.0 release I’ve built a recent snapshot and uploaded it to the experimental suite in Debian.

Of particular interest is the support for more recent architectures that this brings - ARMv8/aarch64 and RISC-V being the big ones, but also MIPS64 and various other ARM improvements. I no longer have access to Xilinx Zynq or Mellanox Bluefield platforms to test against so I’ve just done some some basic tests with a Sheevaplug and BusPirate/STM32F103, but those worked just fine.

Builds should hopefully happen shortly. Enjoy!

Sean Whitton: GNU Emacs' Transient Mark mode

31 May, 2020 - 05:55

Something I’ve found myself doing as the pandemic rolls on is picking out and (re-)reading through sections of the GNU Emacs manual and the GNU Emacs Lisp reference manual. This has got me (too) interested in some of the recent history of Emacs development, and I did some digging into archives of emacs-devel from 2008 (15M mbox) regarding the change to turn Transient Mark mode on by default and set mark-even-if-inactive to true by default in Emacs 23.1.

It’s not always clear which objections to turning on Transient Mark mode by default take into account the mark-even-if-inactive change. I think that turning on Transient Mark mode along with mark-even-if-inactive is a good default. The question that remains is whether the disadvantages of Transient Mark mode are significant enough that experienced Emacs users should consider altering Emacs’ default behaviour to mitigate them. Here’s one popular blog arguing for some mitigations.

How might Transient Mark mode be disadvantageous?

The suggestion is that it makes using the mark for navigation rather than for acting on regions less convenient:

  1. setting a mark just so you can jump back to it (i) is a distinct operation you have to think of separately; and (ii) requires two keypresses, C-SPC C-SPC, rather than just one keypress

  2. using exchange-point-and-mark activates the region, so to use it for navigation you need to use either C-u C-x C-x or C-x C-x C-g, neither of which are convenient to type, or else it will be difficult to set regions at the place you’ve just jumped to because you’ll already have one active.

There are two other disadvantages that people bring up which I am disregarding. The first is that it makes it harder for new users to learn useful ways in which to use the mark when it’s deactivated. This happened to me, but it can be mitigated without making any behavioural changes to Emacs. The second is that the visual highlighting of the region can be distracting. So far as I can tell, this is only a problem with exchange-point-and-mark, and it’s subsumed by the problem of that command actually activating the region. The rest of the time Emacs’ automatic deactivation of the region seems sufficient.

How might disabling Transient Mark mode be disadvantageous?

When Transient Mark mode is on, many commands will do something usefully different when the mark is active. The number of commands in Emacs which work this way is only going to increase now that Transient Mark mode is the default.

If you disable Transient Mark mode, then to use those features you need to temporarily activate Transient Mark mode. This can be fiddly and/or require a lot of keypresses, depending on exactly where you want to put the region.

Without being able to see the region, it might be harder to know where it is. Indeed, this is one of the main reasons for wanting Transient Mark mode to be the default, to avoid confusing new users. I don’t think this is likely to affect experienced Emacs users often, however, and on occasions when more precision is really needed, C-u C-x C-x will make the region visible. So I’m not counting this as a disadvantage.

How might we mitigate these two sets of disadvantages?

Here are the two middle grounds I’m considering.

Mitigation #1: Transient Mark mode, but hack C-x C-x behaviour
(defun spw/exchange-point-and-mark (arg)
  "Exchange point and mark, but reactivate mark a bit less often.

Specifically, invert the meaning of ARG in the case where
Transient Mark mode is on but the region is inactive."
  (interactive "P")
   (if (and transient-mark-mode (not mark-active))
       (not arg)
(global-set-key [remap exchange-point-and-mark] &aposspw/exchange-point-and-mark)

We avoid turning Transient Mark mode off, but mitigate the second of the two disadvantages given above.

I can’t figure out why it was thought to be a good idea to make C-x C-x reactivate the mark and require C-u C-x C-x to use the action of exchanging point and mark as a means of navigation. There needs to a binding to reactivate the mark, but in roughly ten years of having Transient Mark mode turned on, I’ve found that the need to reactivate the mark doesn’t come up often, so the shorter and longer bindings seem the wrong way around. Not sure what I’m missing here.

Mitigation #2: disable Transient Mark mode, but enable it temporarily more often
(setq transient-mark-mode nil)
(defun spw/activate-mark (&rest ignore)
  "Temporarily activate Transient Mark mode.

Wrapper suitable for use as advice and to be bound to a key."
(dolist (command &apos(mark-word
  (advice-add `,command :after #&aposspw/activate-mark))

;; optional
(global-set-key "\M-=" &aposspw/activate-mark)
;; resettle the previous occupant
(global-set-key "\C-cw" &aposcount-words-region)

Here we remove both of the disadvantages of Transient Mark mode given above, and mitigate the main disadvantage of not activating Transient Mark mode by making it more convenient to activate it temporarily.

For example, this enables using C-M-SPC C-M-SPC M-( to wrap the following two function arguments in parentheses. And you can hit M-h a few times to mark some blocks of text or code, then operate on them with commands like M-% and C-/ which behave differently when the region is active.1

Comparing these mitigations

Both of these mitigations handle the second of the two disadvantages of Transient Mark mode given above. What remains, then, is

  1. under the effects of mitigation #1, how much of a barrier to using marks for navigational purposes is it to have to press C-SPC C-SPC instead of having a single binding, C-SPC, for all manual mark setting2

  2. under the effects of mitigation #2, how much of a barrier to taking advantage of commands which act differently when the region is active is it to have to temporarily enable Transient Mark mode with C-SPC C-SPC, M-= or one of the mark-* commands?

These are unknowns.3 So I’m going to have to experiment, I think, to determine which mitigation to use, if either. In particular, I don’t know whether it’s really significant that setting a mark for navigational purposes and for region marking purposes are distinct operations under mitigation #1.

My plan is to start with mitigation #2 because that has the additional advantage of allowing me to confirm or disconfirm my belief that not being able to see where the region is will only rarely get in my way.

  1. The idea of making the mark-* commands activate the mark comes from an emacs-devel post by Stefan Monnier in the archives linked above.
  2. One remaining possibility I’m not considering is mitigation #1 plus binding something else to do the same as C-SPC C-SPC. I don’t believe there are any easily rebindable keys which are easier to type than typing C-SPC twice. And this does not deal with the two distinct mark-setting operations problem.
  3. Another way to look at this is the question of which of setting a mark for navigational purposes and activating a mark should get C-SPC and which should get C-SPC C-SPC.

Dirk Eddelbuettel: drat 0.1.6: Rewritten macOS binary

31 May, 2020 - 01:24

A new version of drat arrived on CRAN overnight, once again taking advantage of the fully automated process available for such packages with few reverse depends and no open issues. As we remarked at the last release fourteen months ago when we scored the same nice outcome: Being a simple package can have its upsides…

This release is mostly the work of Felix Ernst who took on what became a rewrite of how binary macOS packages are handled. If you need to distribute binary packages for macOS users, this may help. Two more small updates were made, see below for full details.

drat stands for drat R Archive Template, and helps with easy-to-create and easy-to-use repositories for R packages. Since its inception in early 2015 it has found reasonably widespread adoption among R users because repositories with marked releases is the better way to distribute code.

As your mother told you: Friends don’t let friends install random git commit snapshots. Rolled-up releases it is. drat is easy to use, documented by five vignettes and just works.

The NEWS file summarises the release as follows:

Changes in drat version 0.1.6 (2020-05-29)
  • Changes in drat functionality

    • Support for the various (current) macOS binary formats was rewritten (Felix Ernst in #89 fixing #88).

    • Travis CI use was updated to R 4.0.0 and bionic (Dirk).

    • A drat repo was added to the README (Thomas Fuller in #86)

Courtesy of CRANberries, there is a comparison to the previous release. More detailed information is on the drat page.

If you like this or other open-source work I do, you can now sponsor me at GitHub. For the first year, GitHub will match your contributions.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.


Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้