Planet Debian

Subscribe to Planet Debian feed
Planet Debian -
Updated: 2 hours 8 min ago

Jonathan Carter: Free Software Activities for 2020-04

2 May, 2020 - 20:47

Debian project leader

This month contained the first week and a half or so of my term as Debian Project Leader. So far my focus has been getting up to speed and keeping the gears turning with day to day DPL tasks. The updates listed here will also be available on the DPL blog, where I aim to make more frequent updates.

During May, Debian Brazil will host Debian talks throughout the month which they will stream to their YouTube channel. You can find the schedule in this git repository, most of the talks will be in Portuguese, but on the 4th of May at 21:00 UTC, I’ll be covering some Debian project topics for an hour or so and take some questions if there’s time left.

2020-04-19: Handover session with Sam, our outgoing DPL. We covered a lot of questions I had and main areas that the DPL works in. Thanks to Sam for having taken the time to do this.

2020-04-21: First day of term! Thank you to everybody who showed support and have offered to help!

2020-04-21: Request feedback from the trademark team on an ongoing trademark dispute.

2020-04-21: Join the GNOME Advisory Board as a representative from Debian.

2020-04-21: Reply on an ongoing community conflict issue.

2020-04-21: Update Debian project summary for SPI annual report.

2020-04-21: Received a great e-mail introduction from Debian France and followed up on that.

2020-04-21: Posted “Bits from the new DPL” to debian-devel-announce.

2020-04-22: Became Debian’s OSI Affilliate representative.

2020-04-22: Reply to a bunch of media inquiries for interviews, will do them later when initial priorities are on track.

2020-04-23: Resign as Debian FTP team trainee and mailing list moderator. In both these areas there are enough people taking care of it and I intend to maximise available time for DPL and technical areas in the project.

2020-04-25: Review outgoing mail for trademark team.

2020-04-25: Answer some questions in preparation for DAM/Front Desk delegation updates.

2020-04-26: Initiated wiki documentation for delegation updates process.

2020-04-27: Update delegation for the Debian Front Desk team.

2020-04-29: Schedule video call with Debian treasurer team.

2020-04-29: OSI affiliate call. Learned about some Open Source projects including OpenDev, OpenSourceMatters, FOSS Responders and Democracy Labs.

Debian Social

Work on the Debian Social project is progressing, we plan to start a separate blog syndicated to Planet Debian that contains progress and status updates. I’ve been terrible at tracking the work we’ve been doing on this, so for now, here are some micro updates:

  • We currently have more than 30 beta testers using and testing the Debian Social services.
  • PeerTube seems to be working quite well for the kind of needs Debian has for a video platform, our instance currently hosts 1379 videos (most of it being from DebConf and other Debian meetings) with a video archive source size of 449.9GB (videos are also re-encoded to other resolutions which uses additional space) and with 2 093 170 total views. We currently follow 9 other instances and have 2 users who have added non-DebConf content.
  • We set up a Jitsi instance for testing. After a bunch of initial hick-ups it seems to be very stable now. By default videos are 720p, but we capped it down to 480p so that it works better for people who have weaker connections. Please avoid using FireFox with this service for now, since it doesn’t support some features that reduce bandwidth which leads to a drastically worse experience for other participants in the call. This should get better with some experimental new features in FireFox that should land in version 76 and that can be enabled in configuration flags. In the meantime, please use Chromium or another webkit(ish) based browser. We changed also changed from using Google’s STUN servers (which brokers P2P connections when there are just two participants in a call) to using upstream’s STUN servers which should result in some better privacy.
  • It’s now possible for Debian projects to authenticate against Salsa, as now does, although not all the sites we host yet supports that. We’ve filed some bugs with upstream too with promising results so far. In the meantime, Debian is also looking at other solutions for identity management, like Keycloak and LemonLDAP NG. It will probably be a significant amount of time before this problem is completely solved, so at some point we’re going to have to decide whether we want to keep authentication using Debian services as a must-have for our services in order to leave their beta state (otherwise they seem to be working fine).

MiniDebConf Online

In the DebConf video team, we’ve been wondering whether we have all the tools required to successfully host a DebConf (or even a mini DebConf) entirely online. There’s really just one way to know for sure, so we’re going to host MiniDebConf Online from 28 May to 31 May. The first two days will be an online MiniDebCamp, where we can try to hold online spints, meetings and general chit-chat. The last two days will be for talks and lightnight talks, with BoFs likely to take place throughout the 4 days (this will probably be decided once we have a content team). Announcements should go out within the next week, in the meantime, save the dates.

Debian package uploads

2020-04-07: Upload package flask-autoindex (0.6.6-1) to Debian unstable.

2020-04-07: Upload package gamemode (1.5.1-1) to Debian unstable.

2020-04-08: Accept MR#2 for live-tasks (add usbutils to live-task-standard).

2020-04-08: Upload package live-tasks (11.0.2) to Debian unstable (Closes: #955526, #944578, #942837, #942834).

2020-04-08: Close live-config bug #655198 (Only affects squeeze which is no longer supported).

2020-04-08: Upload package live-config (11.0.1) to Debian unstable.

2020-04-08: Upload package calamares (3.2.22-1) to Debian unstable.

2020-04-15: Upload package xabacus (8.2.6-1) to Debian unstable.

2020-04-16: Merge MR#1 for gnome-shell-extension-dashtodock (new upstream release).

2020-04-16: Upload package gnome-shell-extension-dashtodock (67+git20200225-1) to Debian unstable.

2020-04-16: Merge MR#1 for gnome-shell-extension-hard-disk-led (fix some lintian issues).

2020-04-16: Merge MR#1 for gnome-shell-extension-system-monitor (fix some lintian issues).

2020-04-17: Upload package calamares (3.2.23-1) to Debian unstable.

2020-04-17: Upload package catimg (2.6.0-1) to Debian unstable (Closes: #956150).

2020-04-17: Upload package fabulous (0.3.0+dfsg1-7) to Debian unstable (Closes: #952242).

2020-04-17: Upload package gnome-shell-extension-system-monitor (38+git20200414-32cc79e-1) to Debian unstable (Closes: #956656, #956171).

2020-04-17: Upload package gnome-shell-extension-arc-menu (45-1) to Debian unstable (Closes: #956168).

2020-04-18: Upload package toot (0.26.0-1) to Debian unstable.

2020-04-23: Update packaging for gnome-shell-extension-tilix-shortcut, upstream section needs some additional work before release is possible.

2020-04-23: Upload package xabacus (8.2.7-1) to Debian unstable.

2020-04-27: Upload package gnome-shell-extension-dash-to-panel (37-1) to Debian unstable (Closes: #956162, #954978).

2020-04-27: Upload package gnome-shell-extension-dash-to-panel (37-2) to Debian unstable.

2020-04-27: Upload package gnome-shell-extension-dashtodock (68-1) to Debian unstable.

2020-04-30: Merge MR#8 for gamemode (add symbol files) (Closes: #952425).

2020-04-30: Merge MR#9 for gamemode (reduce number of -dev packages generated).

2020-04-30: Merge MR#10 for gamemode (deal better with upgrades on a buggy version).

2020-04-30: Manually merge changes from MR#11 for gamemode (packaging fixes).

2020-04-30: Upload package gamemode (1.5.1-2) to Debian unstable.

Sylvain Beucler: Debian LTS and ELTS - April 2020

2 May, 2020 - 18:25

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 April, the monthly sponsored hours were split evenly among contributors depending on their max availability - I was assigned 28.75h for LTS (out of 30 max; all done) and 7.75h for ELTS (out of 20 max; I did 2.75).

Escalation procedures were (internally) documented with a focus on discussing issues with team coordinator(s) first.

Debian LTS had its first team meeting through IRC and lots of workflow question were discussed. This should help discuss questions that are a bit hard to bring up, and ensure everybody participates. There were lots of topics and it was a bit rushed, but this is something we want to repeat monthly now, possibly with audio/video in a couple months.

Remarks from last month's report were discussed, strengthening the Front-Desk role.

10% of the global funding is now reserved for infrastructure work. What kind of work, and who (LTS or external) will do the work, will be discussed further.

A fellow DD suggested (in a private conversation) that LTS may be taking time from the Debian Security team, due to additional commits to review. Conversely, this is another opportunity to mention all the global, non-LTS-specific work that LTS provides, which I usually highlight in my reports, and maybe I should be even more

ELTS - Wheezy

  • CVE-2020-11612/netty: triage: ignored (deceptively hard to backport, OOM mitigation only)
  • mysql-connector-java: triage: in-progress (subscription-only update from Oracle, attempt to find more detail, waiting for public version)
  • CVE-2020-11868/ntp: global triage: identify and reference missing patch, coordinate with uploader

LTS - Jessie

  • netty, mysql-connector-java, ntp: common triage (see above)
  • CVE-2019-20637/varnish: global triage: attempt to reproduce, attempt to get PoC/vulnerable versions from upstream, update BTS
  • ansible: jessie triage: reset ignore->no-dsa old vulnerabilites after discussing with initial triager
  • ansible: global triage: identify more affected version ranges, locate more patches
  • ansible: prepare jessie upload (work-in-progress)
  • tiff: suites harmonization: offer to work on a tiff/stretch update, follow-up on maintainer's questions, who eventually did the update
  • dsa-needed.txt: identify stale entries from inactive LTS contributor, check for status
  • team meeting: see minutes


Steinar H. Gunderson: What's behind the STL containers?

2 May, 2020 - 16:00

Every C++ programmer will spend a fair amount of time interacting with the containers in the Standard Template Library (STL). But it's not always obvious exactly what data type is behind every container—I thought I knew most of them, but every now and then, some detail pops up. So I thought I'd summarize.

For the purposes of this discussion, I care about the data type and what it means for reference stability; ie., if you get a reference (or pointer, or iterator) to a key or value within the container and the modify the container, for how long can you expect your reference to be valid. (Obviously, if you delete an element, that reference always gets invalidated, so I'll never mention that. I'll also assume the standard std::allocator throughout, so when I say “heap”, it could in theory be memory from an arena or whatever.) All information is, to the best of my knowledge, correct as of GCC 10.

  • std::array: It's a fixed-size array on the heap. Duh. You can't do much with it, so you also can't mess up reference stability.
  • std::vector: An array on the heap. (Also duh.) Elements at the end may be unused. When you add more elements than there's room for (ie., no more unused elements), a new array that's 50% larger (not twice as large, as you'd expect) gets allocated, and the elements get moved (or copied) over. At that point, all references are obviously invalid. Erasing elements leaves elements before it in place, but (also fairly obvious) all later references are invalidated, since the elements are moved.
  • std::string (well, std::basic_string): In C++03, there was a bit of a Wild West here with reference counting and stuff, but since C++11 (forcing an ABI break at the time), this is pretty much an std::vector with a hidden last elements that's always the zero terminator. But if the string is less than 16 bytes (including the trailing zero), it's stored inline in the string with no heap allocation, the so-called short string optimization. I wish std::vector had an option for that. Reference stability as std::vector, generally.
  • std::map, std::set, std::multimap, std::multiset: It's a red-black binary tree, because every programmer must implement one of those themselves at some point in their life. (Rotations sound very advanced, and then you feel good about yourself even though your implementation is a buggy mess.) This is why elements are always ordered, typically by operator<. Interestingly, references are always stable, even in the face of rotations and deletions, so it must be implemented node-based, ie., one heap allocation per node.
  • std::unordered_map and the other std::unordered_*: It's a hash table! Whee! C++11 finally got those (std::hash_map was never standardized). But due to the legacy of std::map (I guess), reference stability is guaranteed, so it must also be implemented node-based; ie., the elements are not stored in the hash table, just pointers to them. This makes for a slower hash table than one could otherwise get. Note that there is no guarantee of iterator stability (only reference stability) that caused a rehash, because the iterator points to the hash table and not to the heap node.
  • std::list, std::forward_list: Doubly- and singly-linked lists, with each node allocated on the heap. You should nearly never use linked lists; they're space-inefficient, cache-inefficient and very slow to iterate through. Even in the cases where you want to insert elements in the middle, taking the hit of O(n) insertion in an std::vector is usually a better idea. But they're reference-stable.
  • std::deque: Much like an std::vector, except for two tweaks: First, there can be unused elements at the beginning in addition to the end (it starts off allocating from the middle), so that inserting at/deleting from the beginning is just as cheap as the end. Second, the deque does not contain elements, but pointers to 512-byte blocks of elements. (Obviously, if the element is larger than 512 bytes, the blocks need to be larger, and can hold only one element each.) This allows reference stability when adding or removing from the start or the end (but not the middle), due to the node allocation. Iterator stability is off if there's a reallocation of the block array, though, since the iterators point into said array.

Then there's also the adaptors:

  • std::stack: It sits on top of a std::deque by default (I don't honestly know why they didn't choose std::vector). You can choose std::vector or std::list instead. Not much more to say, it's all obvious.
  • std::queue: Also sits on top of a std::deque; you can choose std::list, but obviously not std::vector, since it does not have a pop_front. To be honest, I was a bit surprised this wasn't a circular buffer mapped on top of an std::vector, which would make more sense to me than all this heap allocation and deallocation. (I guess you could say that this goes for std::deque as well.)
  • std::priority_queue: It's a binary heap. It sits on top of an std::vector by default. Insertions and deletions rebalance the heap, so basically all bets are off for reference stability.

So, that's it, basically. (I'm going to ignore std::vector<bool> since everyone knows that was a mistake anyway. :-) ) There hasn't been a lot going on here since C++11, which is perhaps a bit sad, since there are useful data structures (in particular, lock-free circular buffers) that are nontrivial and often useful. But I guess there's always Boo… nevermind. You don't want to go there.

Junichi Uekawa: Already May.

1 May, 2020 - 14:35
Already May. Time flies during the Shelter in Place.

Paul Wise: FLOSS Activities April 2020

1 May, 2020 - 07:49
Changes Issues Review Administration
  • myrepos: fix the forum
  • Debian: restart non-responsive tor daemon, restart processes due to OOM, apply changes for DD with expired key
  • Debian wiki: approve accounts
  • Debian QA services: deploy changes, auto-disable oldoldstable pockets
Communication Sponsors

The purple-discord work was sponsored by my employer. All other work was done on a volunteer basis.

Utkarsh Gupta: FOSS Activites in April 2020

1 May, 2020 - 07:00

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


It’s been 14 months since I’ve started contributing to Debian. And 4 months since I’ve been a Debian Developer. And in this beautiful time, I had this opprotunity to do and learn lots of new and interesting things. And most importantly, meet and interact with lots of lovely people! 💖
Debian is $home.

Uploads: Other $things:
  • Attended Ruby team meeting. Logs here.
  • Attended Perl team LHF. Report here.
  • Sponsored a lot of uploads for William Desportes and Adam Cecile.
  • Mentoring for newcomers.
  • FTP Trainee reviewing.
  • Moderation of -project mailing list.
  • Applied for DUCI project for Google Summer of Code 2020.
Ruby2.7 Migration:

Ruby2.7 was recently released on 25th December, 2019. Santa’s gift. Believe it or not. We, the Debian Ruby team, have been trying hard to make it migrate to testing. And it finally happened. The default version in testing is ruby2.7. Here’s the news! \o/
Here’s what I worked on this month for this transition.


Opened several issues and proposed patches (in the form of PRs):

  • Issue #35 against encryptor for Ruby2.7 test failures.
  • Issue #28 against image_science for removing relative paths.
  • Issue #106 against ffi-yajl for Ruby2.7 test failures.
  • PR #5 against aggregate for simply using require.
  • PR #6 against aggregate for modernizing CI and adding Ruby 2.5 and 2.7 support.
  • Issue #13 against espeak-ruby for Ruby2.7 test failures.
  • Issue #4 against tty-which for test failures in general.
  • Issue #11 against packable for Ruby2.7 test failures. PR #12 has been proposed.
  • Issue #10 against growl for test failures and proposed an initial patch.

I fixed and uploaded the following packages in Debian:

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 seventh month as a Debian LTS paid contributor. I was assigned 24.00 hours and worked on the following things:

CVE Fixes and Announcements: Other LTS Work: Other(s)

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:

  • Most importantly, I finally migrated to a new website. Huge UI imporvement! \o/
    From Jekyll to Hugo, it was not easy. But it was worth it! Many thanks to Luiz for writing hugo-coder, Clement, and Samyak! 🔥
    If you find any flaws, issues and pull requests are welcomed at utkarsh2102/
  • Wrote battery-alert, a mini-project of my own to show battery alerts at <10% and >90%.
    Written in shell, it brings me all the satisfaction as it has saved my life on many occasions.
    And guess what? It has more users than just myself! 😉
    Reviews and patches are welcomed \o/
  • Mentored in HackOn Hackathon. Thanks to Manvi for reaching out! 🤗
    It was fun to see people developing some really nice projects.
  • Thanks to Ray and John, I became a GitLab Hero! 🥳
    (I am yet to figure out my role and responibility though)
  • Atteneded Intro Sec Con and had the most fun!
    Heard Ian’s keynote and attended other talks and learned how to use WireShark! 🦈
Open Source:

Again, this contains all the things that I couldn’t categorize earlier.
Opened several issues and pull requests:

  • Issue #297 against hugo-coder, asking to enable RSS feed for blogs.
  • PR #316 for hugo-coder for fixing the above issue myself.
  • Issue #173 against arbre for requesting a release.
  • Issue #104 against combustion, asking to relax dependency on rubocop. Fixed in this commit.
  • Issue #16 against ffi-compiler for requesting to fix homepage and license.
  • Issue #57 against gographviz for requesting a release.
  • Issue #14 against crb-blast, suggesting compatability with bio 2.0.x.
  • Issue #58 against uniform_notifier for asking to drop the use of ruby-growl.
  • PR #2072 for polybar, adding installation instructions on Debian systems.

Until next time.
:wq for today.

Chris Lamb: Free software activities in April 2020

1 May, 2020 - 04:53

Here is my monthly update covering what I have been doing in the free software world during April 2020 (previous month's report). Looking it over prior to publishing, I am surprised how much I got done this month — I felt that I was not only failing to do all the extra things I had planned, but I was doing far less than normal. But let us go easy on ourselves; nobody is nailing this.

  • Made some small changes to my tickle-me-email library which implements Gettings Things Done (GTD)-like behaviours in IMAP inboxes in order to decode various headers correctly [...] and correct the counting logic in the send-later command's message limit. [...]

  • Worked with @dormando with a architecture-specific problem in the Memcached caching system to fix grossly incorrect behaviour on big-endian architectures. [...]

  • As part of my duties of being on the board of directors of the Open Source Initiative and Software in the Public Interest I attended their respective monthly meetings and participated in various licensing and other discussions occurring on the internet, as well as the usual internal discussions regarding logistics, licensing, policy, liaising with the ClearlyDefined project and so on. In particular, I on-boarded the Ganeti project to SPI.

  • Reviewed and merged a contribution to my django-cache-toolbox caching library for Django web applications to fix a nested traceback issue. (#20)

In addition, I did more hacking on the Lintian static analysis tool for Debian packages:

  • New features and improvements:

    • Check for debian/rules files that specify -Wl,--as-needed as this is now the default from bullseye onwards. (#956146)
    • Warn about automatically-generated debug packages that ship files other than .debug. (#958945)
    • Warn about packages that specify --with=systemd with a Debhelper compatibility level of 10 or higher. (#949844)
    • Detect $* as using the Debhelper sequencer. (#930679)
    • Check for override dh_install (ie. with a space) in debian/rules; in 99% of cases this will be an omission of the underscore. [...]
  • Bug fixes:

    • Allow python3-all-dev and python3-all-dbg to satisfy the check for packages that use py3versions with the -s argument. (#955799, #956134)
    • Build-Depends-Arch and Build-Depends-Indep do not imply each other, so don't warn about "duplicate" dependencies in this case. (#956368)
    • Ignore build profiles when checking packages for py3versions -s without the corresponding Build-Depends. (#958794)
    • Remove the pre-depends-directly-on-multiarch-support tag; any package pre-depending on the multiarch-support will not be installable in the bullseye distribution. (#798762)
    • Mark mailing-list-obsolete-in-debian-infrastructure as being experimental. (#958182, #958666)
    • Do not warn about empty dh_dwz-generated "multi-files". (#955752)
    • Don't warn about package-relation-with-self if we have specified a required architecture. (#956227)
  • Misc:

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.

  • I submitted 14 patches to fix specific reproducibility issues in gmap, gpick, herbstluftwm, libcamera, libctl, libctl, minetest-mod-xdecor, netgen-lvs, nickle, nmrpflash, node-mqtt, sprai, xxhash & yaz.

  • Submitted the following patches to fix reproducibility-related toolchain issues within Debian:

    • dh-cargo: Please make the output reproducible. (#958301)

    • rspamd: Please make paths.lua files reproducible. (#956120)

  • Wrote a 20-page funding report to the Open Technology Fund -- whilst the Reproducible Builds project has submitted monthly reports to the otf-active mailing list this final report described in detail the status of each objective, our overall lessons and our future plans.

  • The Reproducible Builds project also operates a Jenkins-based testing framework that powers I made the following changes:

    • Print the build environment prior to executing a build. [...]
    • Drop a misleading disorderfs-debug prefix in log output when we change non-disorderfs things in the file and, as it happens, do not run disorderfs at all. [...]
    • The CSS for the package report pages added a margin to all a HTML elements under li ones, which was causing a comma/bullet spacing issue. [...]
    • Tidy the copy in the project links sidebar. [...]
  • Kept up to date. [...]

  • strip-nondeterminism is our tool to remove specific non-deterministic results from a completed build. In April, I made the following changes:

    • Add deprecation plans to all handlers documenting how (or if) they could be disabled and hopefully eventually removed, etc. (#3)
    • Normalise *.sym files as Java archives. (#15)
    • Add support for custom .zip filename filtering and exclude two patterns of files generated by Maven projects in "fork" mode. (#13)
  • disorderfs is our FUSE-based filesystem that deliberately introduces non-determinism into directory system calls in order to flush out reproducibility issues. This month I fixed a long-standing issue by not drop UNIX groups in FUSE multi-user mode when we are not root. (#1)

  • Categorised a large number of packages and issues in the Reproducible Builds "notes" repository.

  • Drafted, published and publicised our monthly report.

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 139, 140, 141 and 142 to Debian:

  • Comparison improvements:

    • Dalvik .dex files can also serve as APK containers so restrict the narrower identification of .dex files to files ending with this extension and widen the identification of APK files to when file(1) discovers a Dalvik file. (#28)
    • Add support for Hierarchical Data Format (HD5) files. (#95)
    • Add support for .p7c and .p7b certificates. (#94)
    • Strip paths from the output of zipinfo(1) warnings. (#97)
    • Don't uselessly include the JSON "similarity" percentage if it is "0.0%". [...]
    • Render multi-line difference comments in a way to show indentation. (#101)
  • Testsuite improvements:

    • Add pdftotext as a requirement to run the PDF test_metadata text. (#99)
    • apktool 2.5.0 changed the handling of output of XML schemas so update and restrict the corresponding test to match. (#96)
    • Explicitly list python3-h5py in debian/tests/ to ensure that we have this module installed during a test run to generate the fixtures in these tests. [...]
    • Correct parsing of ./ test --pytest-args arguments. [...]
  • Misc:

    • Capitalise "Ordering differences only" in text comparison comments. [...]
    • Improve documentation of FILE_TYPE_HEADER_PREFIX and FALLBACK_FILE_TYPE_HEADER_PREFIX to highlight that only the first 16 bytes are used. [...]

Lastly, I made a large number of changes to our website and documentation in the following categories:

  • Community engagement improvements:

    • Update instructions to register for Salsa on our Contribute page now that the signup process has been overhauled. [...]
    • Make it clearer that joining the rb-general mailing list is probably a first step for contributors to take. [...]
    • Make our full contact information easier to find in the footer (#19) and improve text layout using bullets to separate sections [...].
  • Accessibility:

    • To improve accessibility, make all links underlined. (#12)
    • Use an enhanced foreground/background contrast ratio of 7.04:1. (#11)
  • General improvements:

  • Internals:

    • Move to using jekyll-redirect-from over manual redirect pages [...][...] and add a redirect from /docs/buildinfo/ to /docs/recording/. (#23)
    • Limit the website self-check to not scan generated files [...] and remove the "old layout" checker now that I have migrated all them [...].
    • Move the news archive under the /news/ namespace [...] and improve formatting of archived news links [...].
    • Various improvements to the draft template generation. [...][...][...][...]

Debian LTS

This month I have contributed 18 hours to Debian Long Term Support (LTS) and 7¾ hours on its sister Extended LTS project.

  • Frontdesk duties, responding to user/developer questions, reviewing others' packages, participating in mailing list discussions, etc.

  • Issued DLA 2171-1 for the Ceph distributed storage and file system to prevent a header-splitting vulnerability (CVE-2020-1760).

  • It was discovered that there was a path-traversal issue in the Apache Shiro Java security framework (CVE-2020-1957) where a specially-crafted request could cause an authentication bypass. I therefore issued DLA 2181-1 to address this.

  • Issued ELA-224-1 for the ntp Network Time Protocol server to prevent a denial of service vulnerability (CVE-2020-11868).

  • Issued ELA-225-1 for dom4j, a library for working with various XML formats on the Java platform to address an XML external external entity vulnerability (CVE-2020-10683). This type of attack occurs when XML input containing a reference to an internet-faced entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server side request forgery as well as other system impacts.

  • Issued ELA-224-2 to update the fix to ntp in ELA-224-2 to add further protection that was not present in the previous update.

  • Investigated and triaged bluez [...], dom4 [...], inetutils [...], openldap [...], otrs2 [...], qemu [...][...][...], samba [...][...], varnish [...], xcftools [...], etc.

  • Attended our first regular IRC contributor meeting.

You can find out more about the project via the following video:


I only filed three bugs in April, including one against to report that a Content-Type HTTP header is missing when downloading .deb files (#956471) and to report build failures in the macs & ruby-enumerable-statistics packages:

  • Redis:

    • 6.0~rc3-1 — New upstream beta release.
    • 6.0~rc4-1 — New upstream beta release and use the newly-packaged liblzf-dev package over the local version. (#958321)
    • 5.0.7-3 — Fix build failures with GCC 10. (#957751)
    • 5.0.7-4 — Use the newly-packaged liblzf-dev package over the bundled version. (#958321)
    • 5.0.7-5 — Ensure that the daemon is running prior to running the autopkgtests.
    • 5.0.7-6 — Perform a "no change" sourceful upload to permit migration to the testing distribution.
    • 5.0.7-7 — Add a sleep to ensure that the server has started before running the tests.
  • Django:

  • Memcached:

    • 1.6.3-1 — New upstream release.
    • 1.6.5-1 — New upstream release.
    • 1.6.5-2 — Fix a failing autopkgtest that assumes a particular string is in the first kilobyte of the response which was no longer the case due to the addition of new configuration options.
  • Redisearch:

    • 1.2.2-1 — New upstream release.
    • 1.2.2-2 — Ensure that the server is started before running autopkgtests.
    • 1.2.2-3 — Sleep to ensure the server has really started before running the autopkgtests.
  • OnionShare (2.2-2) — Replace python-nautilus in the build-dependencies with python3-nautilus. (#943137)

  • installation-birthday (15) — Correct the (confusing) internal logic of --force from being visible to users. (#895686)

  • txtorcon (20.0.0-1) — New upstream release and refresh packaging.

  • python-hiredis (1.0.1-1) — New upstream release and refresh packaging.

  • onioncircuits (0.6-3) — Mark a non-deterministic autopkgtest as "flaky" for now to ease migration (#930448) and use DEB_VERSION_UPSTREAM_REVISION over manually parsing dpkg-parsechangelog in debian/rules.

Jonathan McDowell: Let's talk about work/life balance in lock down

1 May, 2020 - 03:21

A SYNCNI article passed by on my Twitter feed this morning, talking about balancing work life balance while working from home in these times of COVID-19 inspired lock down. The associated Twitter thread expressed an interest in some words of advice from men to other men (because of course the original article has the woman having to do all the balancing).

This post does not contain the words of advice searched for, but it hopefully at least offers some reassurance that if you’re finding all of this difficult you’re not alone. From talking to others I don’t think there’s anything particularly special we’re doing in this house; a colleague is taking roughly the same approach, and some of the other folk I’ve spoken to in the local tech scene seem to be doing likewise.

First, the situation. Like many households both my wife and I work full time. We have a small child (not even a year and a half old yet). I work for a software startup, my wife is an HR business partner for a large multinational, dealing with employees all over the UK and Ireland. We’re both luckily able to work from home easily - our day to day work machines are laptops, our employers were already setup with the appropriate VPN / video conferencing etc facilities. Neither of us has seen any decrease in workload since lock down; there are always more features and/or bugs to work on when it comes to a software product, and, as I’m sure you can imagine, there has been a lot more activity in the HR sphere over the past 6 weeks as companies try to work out what to do.

On top of this our childcare arrangements, like everyone else’s, are completely gone. Nursery understandably shut down around the same time as the schools (slightly later, but not by much) and contact with grandparents is obviously out (which they’re finding hard). So we’re left with trying to fit 2 full time jobs in with full time childcare, of a child who up until recently tried to go down stairs by continuing to crawl forward.

Make no mistake, this is hard. I know we are exceptionally lucky in our situation, but that doesn’t mean we’re finding it easy. We’ve adopted an approach of splitting the day up. I take the morning slot (previously I would have got up with our son anyway), getting him up and fed while my wife showers. She takes over for a bit while I shower and dress, then I take over again in time for her to take her daily 8am conference call.

My morning is mostly taken up with childcare until nap time; I try to check in first thing to make sure there’s nothing urgent, and get a handle on what I might have to work on later in the day. My local team mates know they’re more likely to get me late morning and it’s better to arrange meetings in the afternoon. Equally I work with a lot of folk on the US West coast, so shifting my hours to be a bit later is not a problem there.

After nap time (which, if we’re lucky, takes us to lunch) my wife takes over. As she deals with UK/Ireland folk she often ends up having to take calls even while looking after our son; generally important meetings can be moved to the morning and meetings with folk who understand there might be a lot of pot banging going on in the background can happen in the afternoon.

Having started late I generally work late - past the point where I’d normally get home; if I’m lucky I pop my head in for bath time, but sometimes it’s only for a couple of minutes. We alternate cooking; usually based on work load + meetings. For example tonight I’m cooking while my wife catches up on some work after having put our son to bed. Last night I had a few meetings so my wife cooked.

So what’s worked for us? Splitting the day means we can plan with our co-workers. We always make sure we eat together in the evening, and that generally is the cut-off point for either of us doing any work. I’m less likely to be online in the evening because my study has become the place I work. That means I’m not really doing any of my personal projects - this definitely isn’t a case of being at home during lock down and having lots of time to achieve new things. It’s much more of case of trying to find a sustainable way to get through the current situation, however long it might last.

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

30 April, 2020 - 17:07

Due to sickness I was not able to complete my 8 hours of work on Debian LTS as planned. I only worked 1.5 hours this month, moving the remaining 6.5 hours over to May.

  • Triage sqlite3, nginx, libsixel.
  • Drop EOL'ed libperlspeak-perl from dla-needed.txt.
  • Update security tracker's metadata (patch URLs) for ansible
Other security related work for Debian
  • Upload to buster: gosa 2.7.4+reloaded3-8+deb10u2 (1 CVE)
  • Upload to stretch: gosa 2.7.4+reloaded2-13+deb9u2 (1 CVE plus many bug fixes)
  • Upload to stretch: gosa 2.7.4+reloaded2-13+deb9u3 (1 more CVE)

Ian Jackson: subdirmk 1.0 - ergonomic preprocessing assistant for non-recursive make

29 April, 2020 - 23:40

I have made the 1.0 release of subdirmk.

subdirmk is a tool to help with writing build systems in make, without use of recursive make.


Peter Miller's 1997 essay Recursive Make Considered Harmful persuasively argues that it is better to arrange to have a single make invocation with the project's complete dependency tree, rather than the conventional $(MAKE) -C subdirectory approach.

This has become much more relevant with modern projects which tend to be large and have deep directory trees. Invoking make separately for each of these subdirectories can be very slow. Nowadays everyone needs to run a parallel build, but with the recursive make approach great discipline is needed to avoid introducing races which cause the build to sometimes fail.

There are various new systems which aim to replace make. My general impression of these is that they mostly threw away the good parts of make (often, they discard the flexibility, and the use of the shell command as the basic unit of execution, making them hard to extend), or make other unfortunate assumptions. And there are a lot of programming-language-specific systems - a very unsatisfactory development. Having said all that, I admit I haven't properly evaluated every make competitor. Other reasons for staying with make including that it is widely available, relatively widely understood, and has a model relatively free of high-level abstract concepts. (I like my languages with high-level concepts, but not my build systems.)

But, with make, I found that actually writing a project's build system in non-recursive make was not very ergonomic. So with some help and prompting from Mark Wooding, I have made a tool to help.


subdirmk is a makefile preprocessor and aggregator, typically run from autoconf. subdirmk provides convenience syntaxes for references to per-directory variables and pathnames. It also helps by providing a little syntactic sugar for GNU make's macro facilities, which are awkward to use in raw make.

subdirmk's features are triggered by the sigil &. The syntax is carefully designed to avoid getting in the way of makefile programming (and programming of shell commands in make rules).

subdirmk is fully documented in the README. There is a demo in the example directory (which also serves as part of the test suite).

What's new

The version number.

I have not felt the need to make any changes since releasing 0.4 in mid-February. The last non-docs change was a (backwards-compatible) extension, in late January, to pass through unaltered GNU make's new grouped multiple targets syntax.

Advantages and disadvantages of subdirmk

Compared to recursive make, subdirmk is easier and simpler, although you do have to decorate a lot of your variables and filenames with & to indicate that they are directory-local. It is much easier to avoid writing parallel make bugs. You naturally get properly working per-subdirectory targets. subdirmk-based nonrecursive make is much, much faster than recursive make.

Compared to many other recent build system tools, subdirmk retains all the flexibility and extensibility of make, and operates at a fairly low level of abstraction. subdirmk-based makefiles can easily invoke other build systems. make knows it's not the only thing in the universe. You can adopt subdirmk incrementally or partially, gradually bringing your recursive submakefiles into the unified build. The build system code in subdirmk's files will be readily navigable by most readers; much will be familiar.

Because subdirmk is a small collection of (fairly simple) scripting and makefile code, there is no need to build it; you can simply ship it with your project using git-subtree. For an autoconf-based project, there need be no change to how your users and downstreams invoke your build.

On the other hand the price you (continue to) pay is make's punctation soup, which subdirmk adds a new sigil to. subdirmk-based makefiles are terse and help you use make's facilities to abstract away repetition, but that can make them dense. The new & sigil will faze some readers.

Currently, the provided mechanism for incorporating subdirmk into your project assumes you are using autoconf but not automake. It would be possible to use subdirmk with autoconf-less projects, or with automake-based ones, but I haven't done the glue work to make that easy.

subdirmk does require GNU make and it assumes you have perl installed. But GNU make is very portable, and perl is very widely available. (The perl used is very conservative.) The make competitors are, themselves, even less standard build tools. I don't think a build-dependency on GNU make, or perl, is a significant barrier nowadays, for most projects.

Note about comment moderation

I have deliberately been vague about other build systems and avoided specific criticisms or references. I don't want the comments to become a build system advocacy debate. Comments may be screened and moderated accordingly. Pointers to other obscure build system tools are very welcome. If you want to write a survey of build tools, or a critique of subdirmk, please do so on your own blog; I would be happy to consider linking to it.


Craig Small: Sending data in a signal

29 April, 2020 - 18:54

The well-known kill system call has been around for decades and is used to send a signal to another process. The most common use is to terminate or kill another process by sending the KILL or TERM signal but it can be used for a form of IPC, usually around giving the other process a “kick” to do something.

One thing that isn’t as well known is besides sending a signal to a process, you can send some data to it. This can either be an integer or a pointer and uses similar semantics to the known kill and signal handler. I came across this when there was a merge request for procps. The main changes are using sigqueue instead of kill in the sender and using a signal action not a signal handler in the receiver.

To illustrate this feature, I have a small set of programs called sender and receiver that will pass an integer between them.

The Sender

The sender program is extremely simple, use a random(ish) from time masked to two bytes, put it in the required union and send the lot to sendqueue.

# include <signal.h>
# include <stdlib.h>
# include <stdio.h>
# include <time.h>

int main(int argc, char **argv)
    union sigval sigval;
    pid_t pid;

    if (argc < 2 || (pid = atoi(argv[1])) < 0)
    sigval.sival_int = time(NULL) &amp; 0xff;
    printf("sender: sending %d to PID %d\n",
        sigval.sival_int, pid);
    sigqueue(pid, SIGUSR1, sigval);
    return EXIT_SUCCESS;

The key lines are 13 and 16 where the random (ish) integer is stored in the sigval union and then sent to the other process with the sigqueue.

The receiver

The receiver just sets up the signal handler, sends its PID (so I know what to tell the sender) and sits in a sleeping loop.

# include <stdio.h>
# include <stdlib.h>
# include <sys/types.h>
# include <unistd.h>
# include <signal.h>

void signal_handler(int signum, siginfo_t *siginfo, void *ucontext)
    if (signum != SIGUSR1) return;
    if (siginfo->si_code != SI_QUEUE) return;

    printf("receiver: Got value %d\n",

int main(int argc, char **argv)
    pid_t pid = getpid();
    struct sigaction signal_action;

    printf("receiver: PID is %d\n", pid);

    signal_action.sa_sigaction = signal_handler;
    sigemptyset (&amp;signal_action.sa_mask);
    signal_action.sa_flags = SA_SIGINFO;
    sigaction(SIGUSR1, &amp;signal_action, NULL);

    while(1) sleep(100);
    return EXIT_SUCCESS;

Lines 16-26 setup the signal handler. The main difference here is SA_SIGINFO used for the signal flags and sigaction references a sa_sigaction function rather than sa_handler.

We need to use a different function because the sigaction only is passed the signal number but we need more information, including the integer that the sender process stored in sigval.

Lines 7-14 are the signal handler function itself. It first checks that the receiver process got the correct signal (SIGUSR1 in this case) and that we got this signal from sigqueue because the type is SI_QUEUE. Checking the type of signal is important because different signals give you different data. For example, if you signalled this process with kill then si_int is undefined.

The result

As a proof of concept, the results are not terribly exciting. We see the sender say what it will be sending and the receiver saying it got it. It was useful to get some results, especially when things went wrong.

$ ./receiver &amp;
[1] 370216
receiver: PID is 370216
$ ./sender 370216
sender: sending 133 to (gdPID 370216
receiver: Got value 133

While testing the two process there was two gotchas I encountered.

GDB and the siginfo structure

The sigaction manual page shows a simple siginfo_t structure, however when looking at what is passed to the signal handler, it’s much more complicated.

(gdb) p *siginfo
$2 = {si_signo = 10, si_errno = 0, si_code = -1, __pad0 = 0, _sifields = {_pad = {371539, 1000, 11, 32766, 0 <repeats 24 times>}, _kill = {si_pid = 371539, si_uid = 1000}, _timer = {si_tid = 371539, 
      si_overrun = 1000, si_sigval = {sival_int = 11, sival_ptr = 0x7ffe0000000b}}, _rt = {si_pid = 371539, si_uid = 1000, si_sigval = {sival_int = 11, sival_ptr = 0x7ffe0000000b}}, _sigchld = {
      si_pid = 371539, si_uid = 1000, si_status = 11, si_utime = 0, si_stime = 0}, _sigfault = {si_addr = 0x3e80005ab53, si_addr_lsb = 11, _bounds = {_addr_bnd = {_lower = 0x0, _upper = 0x0}, _pkey = 0}}, 
    _sigpoll = {si_band = 4294967667539, si_fd = 11}, _sigsys = {_call_addr = 0x3e80005ab53, _syscall = 11, _arch = 32766}}}
(gdb) p siginfo->_sifields._rt.si_sigval.sival_int
$3 = 11

So the integer is stored in a union in a structure in a structure. Much harder to find than just simply sival_int.

The pointer is just a pointer

So perhaps sending an integer is not enough. The sigval is a union with an integer and a pointer. Could a string be sent instead? I changed line 13 of the sender so it used a string instead of an integer.

    sigval.sival_ptr = "Hello, World!"

The receiver needed a minor adjustment to print out the string. I tried this and the receiver segmentation faulted. What was going on?

The issue is the set of system calls does a simple passing of the values. So if the sender sends a pointer to a string located at 0x1234567 then the receiver will have a pointer to the same location. When the receiver tries to dereference the sival_ptr, it is pointing to memory that is not owned by it but by another process (the sender) so it segmentation faults.

The solution would be to use shared memory between the processes. The signal queue would then use the pointer to the shared memory and, in theory, all would be well.

Petter Reinholdtsen: GnuCOBOL, a free platform to learn and use COBOL - nice free software

29 April, 2020 - 18:10

The curiosity got the better of me when Slashdot reported that New Jersey was desperately looking for COBOL programmers, and a few days later it was reported that IBM tried to locate COBOL programmers.

I thus decided to have a look at free software alternatives to learn COBOL, and had the pleasure to find GnuCOBOL was already in Debian. It used to be called Open Cobol, and is a "compiler" transforming COBOL code to C or C++ before giving it to GCC or Visual Studio to build binaries.

I managed to get in touch with upstream, and was impressed with the quick response, and also was happy to see a new Debian maintainer taking over when the original one recently asked to be replaced. A new Debian upload was done as recently as yesterday.

Using the Debian package, I was able to follow a simple COBOL introduction and make and run simple COBOL programs. It was fun to learn a new programming language. If you want to test for yourself, the GnuCOBOL Wikipedia page have a few simple examples to get you startet.

As I do not have much experience with COBOL, I do not know how standard compliant it is, but it claim to pass most tests from COBOL test suite, which sound good to me. It is nice to know it is possible to learn COBOL using software without any usage restrictions, and I am very happy such nice free software project as this is available. If you as me is curious about COBOL, check it out.

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Steve Kemp: I'm a contractor, available for work

29 April, 2020 - 02:00

For the foreseeable future I'm working for myself, as a contractor, here in sunny Helsinki, Finland.

My existing contract only requires me to work 1.5-2.0 days a week, meaning my week looks something like this:

  • Monday & Tuesday
    • I work for the client.
  • Wednesday - Friday
    • I act as a stay-at-home dad.

It does mean that I'm available for work Wednesday-Friday though, in the event I can find projects to work upon, or companies who would be willing to accept my invoices.

I think of myself as a sysadmin, but I know all about pipelines, automation, system administration, and coding in C, C++, Perl, Ruby, Golang, Lua, etc.

On the off-chance anybody reading this has a need for small projects, services, daemons, or APIs to be implemented then don't hesitate to get in touch.

I did manage to fill a few days over the past few weeks completing an online course from Helsinki Open University, Devops with Docker, it is possible I'll find some more courses to complete in the future. (There is an upcoming course Devops with Kubernetes which I'll definitely complete.)

Thomas Lange: FAI 5.9.4, Ubuntu 20.04 support, FAIme service

28 April, 2020 - 21:08

The new FAI version 5.9.4 adds support for the new Ubuntu LTS version 20.04 (focal). New FAI installation images (including a Ubuntu only ISO) are available from

I've added support for the Debian testing release (currently bullseye) to the FAIme service for building customized installation and cloud images. This service still supports the oldstable and stable release including variants with a backports kernel.

The build service is also using the newest FAI version and the customized ISO images can be booted in an UEFI or legacy BIOS environment.

Antoine Beaupré: Drowned my camera: dealing with liquid spills in electronics

28 April, 2020 - 20:46

Folks who acutely dig into this website might know that I have been taking more pictures recently, as I got a new camera since January 2018: a beautiful Fujifilm X-T2 that I really like. Recently, I went out on a photo shoot in the rain. It was intermittent, light rain when I left so I figured the "weather proofing" ( calls this "environmentally sealed") would keep the camera secure. After an hour of walking outside, however, rain intensified and I was just quickly becoming more and more soaked. Still trusting the camera would function, I carried on. But after about 90 minutes of dutiful work, the camera just turned off and wouldn't power back on.

It had drowned.

I couldn't believe it; "but this is supposed to be waterproof! This can't be happening!", I thought. I tried swapping out the battery for a fresh one, which was probably a bad idea (even if I was smart enough to do this under cover): still no luck, yet I could still not believe it was dead, so I figured I would look at it later when I was home. I still eventually removed the battery after a while, remembering that it mattered.

Turns out the camera was really dead. Even at home, it wouldn't power up, even with fresh batteries. After closer inspection, the camera was as soaked as I was...

...even the SD cards were wet!

I was filled with despair! My precious camera! I had been waiting for litterally decades to find the right digital camera that was as close to the good old film cameras I was used to. I was even working on black and white "film" to get back to basics, which turned into a project to witness the impact of the coronavirus on city life! All that was lost, or at least stopped: amazingly, the SD cards were just absolutely fine and survived the flooding without problem.

The last photo my camera took before it died

A good photographer friend told me that this was actually fairly common: "if you shoot outside, get used to this, it will happen". So I tried "the rice trick": plunge your camera in a pile of rice and let it rest there for a long time. It didn't work so well: I didn't have a big enough recipient to hold the camera and the rice. I was also worried about rice particles inserting themselves into the camera holes, as I had opened all the ports to let it dry.

I could also not keep myself from inserting a battery and trying it out again: amazingly, it powered up, only once, and died again. After shopping in desperation for dessicators (who would have thought you should keep those little bags from the stuff you order online!), I ended up buying silica gel dehumidifier from Lee Valley (13$, the small one!) which comes in a neat little metal box. But that never arrived in time so I had to find another solution.

My partner threw the idea out in jest, but the actual solution worked, and it was surprisingly simple!

Tada! Turns out you can dehydrate hardware too!

We have a food dehydrator at home (a Sedna Express if you really want to know) since we do a lot of backpacking and canot-camping, but I never thought I would put electronics in there. Turns out a food dehydrator is perfect: it has a per degree temperature control that can go very low and a timer. I set it to 30°C for 24 hours. (I originally set it to 40°C but it smelled like plastic after a while so my partner turned it off thinking it was melting the camera.)

And now the camera is back! I was so happy! There is probably some permanent damage to the delicate circuitry in the camera. And I will probably not go back out in heavy rain again with the camera, or at least not without a rainjacket (35$USD at B&H) on the camera. And I am now in a position to tell other people what to do if they suffer the same fate...

Tips for dealing with electronic liquid damage

So, lessons learned...

  1. when you have a liquid spill over your electronics: IMMEDIATELY REMOVE ALL ELECTRIC POWER, including the battery! (this is another reason why all batteries should be removable)

  2. if the spill is "sticky" (e.g. coffee, beer, maple syrup, etc) or "salty", do try to wash it with water, yet without flooding it any further (delicate balance, I know) some devices are especially well adapted to this: I have washed a keyboard with a shower head and drowned the thing completely, it worked fine after drying.

  3. do NOT power it back on until you are certain the equipment is dry

  4. let the electronics device dry for 24 to 48 hours with all ports open in a humidity-absorbing environment: a bag of rice works, but a food dehydrator is best. make sure the rice doesn't get stuck inside the machine: use a small mesh bag if necessary

  5. once you are confident the device has dried, fiddle with the controls and see if water comes out: it might not have dried because it was stuck inside a button or dial. if dry, try powering it back on and watch the symptoms. if it's still weird, try drying it for another day.

  6. if you get tired of waiting and the machine doesn't come back up, you will have to send it to the repair shop or open it up yourself to see if there is soldering damage you can fix.

I hope it might help careless people who dropped their coffee or ran out in the rain, believing the hype of waterproof cameras. Amateur tip: waterproof cameras are not waterproof...

Dirk Eddelbuettel: RcppArmadillo 0.9.870.2.0

28 April, 2020 - 07:04

Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. RcppArmadillo integrates this library with the R environment and language–and is widely used by (currently) 705 other packages on CRAN.

A new upstream release 9.870.2 of Armadillo was released a few days ago. We had tested two release candidates, and this caught one bug. The release was held up at CRAN for a few days as one package had an overly sensitive test depending on random input data; eventually we all convinced ourselves that there was no (Rcpp)Armadillo issue here. So morale: friends don’t let friends have tests depend on random behavior.

Changes in the new release are noted below.

Changes in RcppArmadillo version 0.9.870.2.0 (2020-04-24)
  • Upgraded to Armadillo release 9.870.2 (Roasted Mocha Retox)

    • faster handling of matrix multiplication expressions by diagvec() and diagmat()

    • added trimatu_ind() and trimatl_ind()

    • more consistent detection of sparse vector expressions

Courtesy of CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge 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.

Norbert Preining: KDE Apps 20.04 (and Plasma) for Debian

27 April, 2020 - 17:53

A few days ago KDE Apps 20.04 were released, and I am happy that thanks to the openSUSE Build Service (and a lot of scripting and some hand-work), packages for Debian Unstable and Testing are available in by repositories!

The previous location (debian-plasma at OBS) should be replaced by the following entries in /etc/apt/sources.list.d/obs-npreining-kde.list:

For Unstable:

deb ./
deb ./
deb ./
deb ./
deb ./

For Testing:

deb ./
deb ./
deb ./
deb ./
deb ./

The different repositories provide different package groups:

  • other-deps mostly backports from experimental that are necessary for building KDE Apps 20.04
  • frameworks the KDE frameworks, currently version 5.69
  • plasma the Plasma packages, currently
  • apps the KDE Apps, currently 20.04
  • other other apps that need rebuild, currently only digikam (but that in the latest beta3 released a few days ago)

To make these repositories work out of the box, you need to import my OBS gpg key: obs-npreining.asc, best to download it and put the file into /etc/apt/trusted.gpg.d/obs-npreining.asc.

I don’t provide an apt-gettable source archive anymore, in particular since one of the Debian KDE maintainers has rejected my help and told me “Go away”. So it seems that this convenience is not appreciated, and necessary. The source packages are available from the OBS web sites of the respective repositories. Well, if they are not doing the work, I cannot more than offer my help. Thanks Debian!

Currently there are two packages missing: kio-extras and kdeconnect, both of which need new (hitherto unavailable) packages which I will hopefully package in the next days. Two other, juk and okular, are already at version 20.04 in Debian and co-installable.


Dirk Eddelbuettel: #26: Upgrading to R 4.0.0

27 April, 2020 - 07:18

Welcome to the 26th post in the rationally regularized R revelations series, or R4 for short.

R 4.0.0 was released two days ago, and a casual glance at some social media conversations appears to suggest quite some confusion, almost certainly some misunderstandings, and possibly also a fair amount of fear, uncertainty, and doubt about the process. So I thought I could show how I upgrade my own main workstation, live and in colour without a safety net. (Almost: I did upgrade my laptop yesterday which went swimmingly, if more slowly.) So here is a fresh video about upgrading to R 4.0.0, with some support slides as usual:

The slides used in the video are at this link.

A few quick follow-ups to the ‘live’ nature of this. The pbdZMQ package did in fact install smoothly once the (Ubuntu) -dev packages for Zero MQ were (re-)installed; then IRkernel also followed. BioConductor completed once I realized that GOSemSim needed the annotation package GO.db to be updated, that allowed MNF to install. So the only bug, really, was the circular depdency between pkgload and testthat. Overall, not bad at all for a quick afternoon session!

And as mentioned, if you are interested and have questions concerning use of R on a .deb based system like Debain or Ubuntu (or Mint or …), the r-sig-debian list is a very good and friendly place to ask them.

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.

Enrico Zini: Some Italian women

27 April, 2020 - 06:00
Artemisia Gentileschi - Wikipedia art history people 2020-04-27 Artemisia Lomi or Artemisia Gentileschi (US: /ˌdʒɛntɪˈlɛski, -tiːˈ-/, Italian: [arteˈmiːzja dʒentiˈleski]; July 8, 1593 – c. 1656) was an Italian Baroque painter, now considered one of the most accomplished seventeenth-century artists working in the dramatic style of Caravaggio. In an era when women had few opportunities to pursue artistic training or work as professional artists, Artemisia was the first woman to become a member of the Accademia di Arte del Disegno in Florence and had an international clientele. Maria Pellegrina Amoretti - Wikipedia history people 2020-04-27 Maria Pellegrina Amoretti (1756—1787), was an Italian lawyer. She is referred to as the first woman to graduate in law in Italy, and the third woman to earn a degree. Laura Bassi - Wikipedia history people 2020-04-27 Laura Maria Caterina Bassi (October 1711 – 20 February 1778) was an Italian physicist and academic. She received a doctoral degree in Philosophy from the University of Bologna in May 1732. She was the first woman to earn a professorship in physics at a university. She is recognized as the first woman in the world to be appointed a university chair in a scientific field of studies. Bassi contributed immensely to the field of science while also helping to spread the study of Newtonian mechanics through Italy. Maria Gaetana Agnesi - Wikipedia history people 2020-04-27 Maria Gaetana Agnesi (UK: /ænˈjeɪzi/ an-YAY-zee,[1] US: /ɑːnˈ-/ ahn-,[2][3] Italian: [maˈriːa ɡaeˈtaːna aɲˈɲɛːzi, -ɲeːz-];[4] 16 May 1718 – 9 January 1799) was an Italian mathematician, philosopher, theologian, and humanitarian. She was the first woman to write a mathematics handbook and the first woman appointed as a mathematics professor at a university.[5] Elena Cornaro Piscopia - Wikipedia history people 2020-04-27 Elena Lucrezia Cornaro Piscopia (US: /kɔːrˌnɑːroʊ pɪˈskoʊpiə/,[4] Italian: [ˈɛːlena luˈkrɛttsja korˈnaːro piˈskɔːpja]) or Elena Lucrezia Corner (Italian: [korˈnɛr]; 5 June 1646 – 26 July 1684), also known in English as Helen Cornaro, was a Venetian philosopher of noble descent who in 1678 became one of the first women to receive an academic degree from a university, and the first to receive a Doctor of Philosophy degree. Maria Montessori - Wikipedia education history italy people 2020-04-27 Maria Tecla Artemisia Montessori (/ˌmɒntɪˈsɔːri/ MON-tiss-OR-ee, Italian: [maˈriːa montesˈsɔːri]; August 31, 1870 – May 6, 1952) was an Italian physician and educator best known for the philosophy of education that bears her name, and her writing on scientific pedagogy. At an early age, Montessori broke gender barriers and expectations when she enrolled in classes at an all-boys technical school, with hopes of becoming an engineer. She soon had a change of heart and began medical school at the Sapienza University of Rome, where she graduated – with honors – in 1896. Her educational method is still in use today in many public and private schools throughout the world. Rita Levi-Montalcini - Wikipedia history italy people science 2020-04-27 Rita Levi-Montalcini OMRI OMCA (US: /ˌleɪvi ˌmoʊntɑːlˈtʃiːni, ˌlɛv-, ˌliːvi ˌmɒntəlˈ-/, Italian: [ˈriːta ˈlɛːvi montalˈtʃiːni]; 22 April 1909 – 30 December 2012) was an Italian Nobel laureate, honored for her work in neurobiology. She was awarded the 1986 Nobel Prize in Physiology or Medicine jointly with colleague Stanley Cohen for the discovery of nerve growth factor (NGF). From 2001 until her death, she also served in the Italian Senate as a Senator for Life. This honor was given due to her significant scientific contributions. On 22 April 2009, she became the first Nobel laureate ever to reach the age of 100, and the event was feted with a party at Rome's City Hall. At the time of her death, she was the oldest living Nobel laureate. Margherita Hack - Wikipedia history italy people science 2020-04-27 Margherita Hack Knight Grand Cross OMRI (Italian: [marɡeˈriːta ˈ(h)ak]; 12 June 1922 – 29 June 2013) was an Italian astrophysicist and scientific disseminator. The asteroid 8558 Hack, discovered in 1995, was named in her honour. Samantha Cristoforetti - Wikipedia history italy people science 2020-04-27 Samantha Cristoforetti (Italian pronunciation: [saˈmanta kristofoˈretti]; born 26 April 1977, in Milan) is an Italian European Space Agency astronaut, former Italian Air Force pilot and engineer. She holds the record for the longest uninterrupted spaceflight by a European astronaut (199 days, 16 hours), and until June 2017 held the record for the longest single space flight by a woman until this was broken by Peggy Whitson and later by Christina Koch. She is also the first Italian woman in space. Samantha Cristoforetti is also known as the first person who brewed an espresso in space.

Russ Allbery: Review: The Last Goodbye

26 April, 2020 - 10:51

Review: The Last Goodbye, by Matt Potter

Publisher: Silvertail Copyright: 2014-2016 Printing: 2016 ISBN: 1-909269-42-5 Format: Kindle Pages: 308

In the contested space between the interested amateur and the trained expert lies the enthusiast. A topic has, for often inexplicable reasons, caught fire in their thoughts and become a mild obsession. They may not have formal training or systematic conceptual grounding beneath their interest, but they partly make up for that lack with sustained fascination. They research widely and obscurely about their particular focus, develop novel theories, see distinctions and classifications that few others would bother to investigate, and present their discoveries to anyone who will stand still long enough. And occasionally, when that interest happens to coincide with writing skill, they produce some surprisingly excellent essays or books.

Matt Potter's enthusiasm is resignation letters.

Every damaging resignation letter, every cornered truth attack, every out-of-control speech by a former friend, is more than just an inconvenience, to be countered with positive spin and internal memos: it's an open challenge to the official version of the story, the perfectly controlled brand. They are breaks in an otherwise perfectly planned, smoothly executed narrative of the powerful. Holes in the program code. A rare, irresistible chance to hack into history's shiny, unstoppable operation.

The Last Goodbye: A History of the World in Resignation Letters is not, in truth, a history of the world. It is, first and foremost, a taxonomy, because there are types of resignation letters. The opening chapter, the truth bomb, is the type that one would expect upon discovering that someone wrote a book on the topic (that wasn't advice on how to write a good one). But there are other types, less heavy on the fireworks but just as fascinating. The unquotable expert construction. The knife in the back. The incoherent scream of rage. But also the surprisingly gentle and graceful conclusion.

It is the question that the letters themselves try in vain to answer, over and over again — even as they explain, analyse, protest and bear witness to a million other details.

The question is: Why?

All the forces in the universe stack up against unburdening ourselves in a resignation letter. Professionally, it can be suicide. In practical terms, it is often self-defeating. Self-help books coach against unleashing its force; colleagues and confidantes urge caution, self-restraint. And yet we do it, and damn the consequences. We have no choice but to speak — in sorrow, love, grief, cold anger, thirst for revenge, wounded pride, the pain of injustice, loyalty, pangs of regret, throes of vengeful madness, deluded righteousness, panic, black distress, isolation, ecstasies of martyrdom, and a million other shades of human extremity — we need to say our piece even as we leave the stage.

The risk of the enthusiast's book is that the lack of structural grounding can leave the conclusions unsupported. A fair critique of this book is that it contains a lot of amateur sociology. Potter has a journalist's eye for motive and narrative, but some of his conclusions may not be warranted. But he compensates for the lack of rigor with, well, enthusiasm. Potter is fascinated by resignation letters and the insight they offer, and that fascination is irresistibly contagious.

It's probably obvious that the chapters on truth bombs, fuck yous, and knives in the back have visceral appeal. The resignation letter as a force of truth-telling, as the revenge of a disregarded peon, as a crack in the alliance between the powerful that may let some truth shine through, is what got me to buy this book. And Potter doesn't disappoint; he quotes from both famous and nearly unknown examples, dissects the writing and the intent, and gives us a ringside seat to a few effective acts of revenge.

That's not the best part of this book, though. The chapter that I will remember the longest is Potter's dissection of the constructed resignation letter. The carefully drafted public relations statement, the bland formality, the attempt to make a news story disappear. The conversation-ender.

It's a truism that any area of human endeavor involves more expertise than those who have only observed it from the outside will realize, but I had never thought to apply that principle to the ghost-written resignation letter. The careful non-apology, the declaration that one has "become a distraction," the tell-tale phrasing of "spending more time with my family" is offensive in its bland dishonesty. But Potter shows that the blandness is expertly constructed to destroy quotability. Those statements are nearly impossible to remember or report on because they have been built that way: nouns carefully separated from verbs, all force dissipated by circuities and modifiers, and subtle grammatical errors introduced to discourage written news from including direct quotes.

Potter's journalism background shines here because he can describe the effect on news reporting. He walks the reader through the construction to reveal that the writing is not incompetent but instead is skillfully bad in a way that causes one's attention to skitter off of it. The letter vanishes into its own vagueness. The goal is to smother the story in such mediocrity that it becomes forgettable. And it works.

I've written several resignation letters of my own. Somewhat unusually, I've even sent several of them, although (as Potter says is typical) fewer than I've written. I've even written (and sent) the sort of resignation letter that every career advisor will say to never send. Potter's discussion of the motives and thought process behind those letters rang true for me. It's a raw and very human moment, one is never in as much control of it as one wishes, the cracks and emotions break through in the writing, and often those letters are trying to do far too many things at the same time. But it's also a moment in which one can say something important and have others listen, which can be weirdly challenging to do in the normal course of a job.

Potter ends this book beautifully by looking at resignation letters that break or transcend the mold of most of the others he's examined: letters where the author seems to have found some peace and internal understanding and expresses that simply and straightforwardly. I found this surprisingly touching after the emotional roller-coaster of the rest of the book, and a lovely note on which to end.

This is a great book. Potter has a good eye for language and the emotion encoded in it, a bracing preference for the common worker or employee over the manager or politician, and the skill to produce some memorable turns of phrase. Most importantly, he has the enthusiast's love of the topic. Even if you don't care about resignation letters going in, it will be hard to avoid some fascination with them by the end of this book. Recommended.

This book was originally published as F*ck You and Goodbye in the UK.

Rating: 8 out of 10


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