You are here

Planet Debian

Subscribe to Feed Planet Debian
Planet Debian -
Përditësimi: 8 months 17 orë më parë

Romain Perier: My work on Debian (April 2019)

Enj, 02/05/2019 - 8:21md

This is a summary of what I have done in April 2019 on Debian

  • I have uploaded raspi3-firmware 1.20190215-2 to sid
  • I have bumped raspi3-firmware to 1.20190401-1
  • I have bumped the preempt_rt kernel to 4.19.37-rt19 in sid
  • I have bumped the experimental kernel to 5.0.7
  • I have bumped the experimental preempt_rt kernel to 5.0.7-rt5
  • I have bumped the experimental kernel to 5.0.8
  • I have bumped the experimental kernel to 5.0.9
  • I have bumped the experimental kernel to 5.0.10
  • I have removed extra binary files from the orig tarball in raspi3-firmware, this closes #924315
  •  I have enabled support for the coreboot memconsole in kernel 5.0.x. It has been backported into sid and should be part of buster. This closes bug #872069

Joachim Breitner: Drawing foldl and foldr

Enj, 02/05/2019 - 8:10md

Often, someone wants to exhaling the difference between a left-fold and a right-fold, i.e. foldl and foldr in Haskell, you see a picture like the following

foldl and foldr

This is taken from the recently published and very nice “foldilocks” tutorial by Ayman Nadeem, but I have seen similar pictures before.

I always thought that something is not quite right about them, in particular the foldr. I mean, they are correct, and while the foldl one clearly conveys the right intuition, the foldr doesn’t quite: it looks as if the computer would fast forward to the end of the list, and then start processing it. But that does not capture the essence of foldr, which also starts at the beginning of the list, by applying its argument lazily.

And therefore, this is how I would draw this graph:

foldl and foldr

This way (at least to people from a left-to-right top-to-bottom culture), it becomes more intuitive that with foldr, you are first looking at an application of the combinator to the first element, and then possibly more.

Mike Gabriel: My Work on Debian LTS/ELTS (April 2019)

Enj, 02/05/2019 - 7:40md

In April 2019, I have worked on the Debian LTS project for 11.5 hours (of 17.25 hours planned, pulling over 5.75 hours to the next month) and on the Debian ELTS project for another 10 hours (of 10 hours planned) as a paid contributor.

LTS Work
  • Upload to jessie-security: libssh2 (DLA-1730-2 [1], regression fix)
  • Upload to jessie-security: poppler (DLA-1752-1 [2])
  • Upload to jessie-security: samba (DLA-1754-1 [3])
  • Upload to jessie-security: systemd (DLA-1762-1 [4])
  • Upload to jessie-security: systemd (DLA-1762-2 [5], regression fix)
  • Help fixing sbuild in Debian 10, so it still supports building packages for Debian wheezy. (See Debian bug #926161 [6])
  • Upload to wheezy-lts: cron (ELA-103-1 [7])
  • Upload to wheezy-lts: samba (ELA-104-1 [8])
  • Also build cron arch:i386 for wheezy-lts and update
  • Upload to wheezy-lts: systemd (ELA-115-1) [9]

Ben Hutchings: Debian LTS work, April 2019

Mër, 01/05/2019 - 3:14md

I was assigned 17.25 hours of work by Freexian's Debian LTS initiative and carried over 14 hours from March. I worked all 31.25 hours this month.

I uploaded firmware-nonfree with Emilio Pozuelo Monfort's changes, and issued DLA-1747-1.

I made a stable update to Linux 3.16 (3.16.65) and rebased the Debian package on top of this. I built and uploaded packages for testing, to reduce the risk of an uncaught regression in the next update to jessie. I prepared the next stable update (3.16.66), which is currently out for review.

I merged changes from stretch's linux package into linux-4.9, and from linux-latest into linux-latest-4.9. I built and uploaded these and prepared a DLA. However, linux-4.9 is currently waiting in the NEW queue because it includes an ABI bump.

Junichi Uekawa: Abdication and ascention to the Chrysanthemum Throne.

Mër, 01/05/2019 - 10:22pd
Abdication and ascention to the Chrysanthemum Throne. These words are not used that often in everyday life.

Jonathan Carter: Free Software Activities (2019-04)

Mër, 01/05/2019 - 9:55pd

April is over and winter is here and things are getting gloomy, but that doesn’t stop surfers from heading out into the ocean (photo taken at Muizenberg surfer’s corner, Cape Town).

Debian package work

2019-04-04: Work on gamemode (1.3.1-1) update.

2019-04-04: Upload new upstream version of tetzle (2.1.4+dfsg1-1) to debian unstable.

2019-04-04: Upload gnome-shell-extension-dashtodock (66-1~exp2) to debian experimental.

2019-04-04: Upload connectagram (1.2.9-5) to debian unstable.

2019-04-06: Upload kpmcore (3.3.0-5) to debian unstable.

2019-04-08: Non-maintainer upload of plymouth (0.9.4-1.1) to debian unstable.

2019-04-15: Upload desktop-base (10.0.2) to debian unstable.

2019-04-15: File unblock request for desktop-base (10.0.2).

2019-04-15: File unblock request for calamares-settings-debian (10.0.19-1).

2019-04-15: File unblock request for live-config (5.20190312).

2019-04-16: File bug against live media having a stale /etc/fstab file causing problems (#927216).

2019-04-16: File bug against live media having duplicate sources.list entries (#927216).

2019-04-16: File bug against amdgpu not working on debian live systems (#927219).

2019-04-24: Upload new upstream version of btfs (2.19~exp1) to debian experimental.

2019-04-24: Upload new upstream version of calamares (3.2.5-1~exp1) to debian experimental.

2019-04-25: Upload new upstream version of gnome-shell-extension-workspaces-to-dock (50-1~exp1) to debian experimental.

2019-04-29: Upload new upstream version of calamares (3.2.7-1~exp1) to debian experimental.

2019-04-29: Upload new upstream version of gnome-shell-extension-multi-monitors (18-1~exp1) to debian experimental.

Debian package review and sponsoring

2019-04-04: Comment on cuba (4.2-1) ( request).

2019-04-05: Quick review on siconos (4.2.0+git20181026.0ee5349+dfsg.2-1), forward request to debian-science team ( request).

2019-04-09: Review siconos (4.2.0+git20181026.0ee5349+dfsg.2-1), needs some work (ftbfs) ( request).

2019-04-10: Sponsor siconos (4.2.0+git20181026.0ee5349+dfsg.2-1) for debian unstable ( request).

Debian QA

2019-04-11: Build fresh Debian live ISOs for testing.

2019-04-11: Test Debian Live ISOs for full-disk encryption from calamares, bootsplash themes and plymouth themes.

2019-04-13: Build fresh Debian live ISOs for testing.

2019-04-13: Test Debian Live ISOs for recent fixes.

2019-04-13: Blog entry: Help test Debian Live.

Debian community

2019-04-21: Schedule a Debian town hall meeting “Meet the new DPL and ask him anything!“.


DebConf bursaries took out a whole lot of time towards the end of the month, I didn’t manage to log activity for this, but plan to write a lot of documentation for this process when all the essential (and time-critical) work has been completed.

Elana Hashman: PyCon 2019 Talk Resources

Mër, 01/05/2019 - 6:00pd

At PyCon US in 2019, I reprised my talk "The Black Magic of Python Wheels", originally presented at PyGotham 2018. I based this talk on my three years of work on auditwheel and the manylinux platform, hoping to share some dark details of how the proverbial sausage is made.

After this talk, I will be retiring from auditwheel maintainership.

The Black Magic of Python Wheels Follow-up readings All the PEPs referenced in the talk

In increasing numeric order.

  • PEP 376 "Database of Installed Python Distributions"
  • PEP 426 "Metadata for Python Software Packages 2.0"
  • PEP 427 "The Wheel Binary Package Format 1.0"
  • PEP 513 "A Platform Tag for Portable Linux Built Distributions" (aka manylinux1)
  • PEP 571 "The manylinux2010 Platform Tag"
Image licensing info

Russ Allbery: Haul post

Mër, 01/05/2019 - 5:54pd

I've not been posting much lately (or writing many book reviews) for a rather good reason: I got sucked into a bunch of open source programming work, including learning Selenium, a little bit of JavaScript, and a lot about web application internals. The project in question (currently called Merou, probably will be renamed) isn't that useful for anyone else quite yet, and is still kind of a mess, but we're slowly cleaning it up. It's nice to be working on open source for work again.

At some point I need to apply what I've learned to getting remctl's Python bindings off of Python 2 and make my web site not look like I haven't touched it since the early 2000s. It would be nice to have an extra 24 hours in each day.

Anyway, book purchasing has continued, of course.

Rachel Elise Barkow — Prisoners of Politics (nonfiction)
John Carreyrou — Bad Blood (nonfiction)
E.K. Johnston — The Afterward (sff)
Daniel Kahneman — Thinking, Fast and Slow (nonfiction)
Arkady Martine — A Memory Called Empire (sff)
Rebecca Roanhorse — Trail of Lightning (sff)

I'm currently significantly behind on writing reviews and need to take some time to catch up, but Minecraft keeps calling me....

Dirk Eddelbuettel: Where may Dirk show up: May to July 2019 edition

Mër, 01/05/2019 - 4:53pd
When Where May 2 STAT430 project presentations, U of Illinois, Urbana, IL, USA May 17 Rcpp pre-conference Tutorial, R/Finance 2019, Chicago, IL, USA May 22 Northwestern R Users Group, Kellog Global Hub, Evanston, IL, USA May 28-30 Invited keynote, ICORS/LASC, Guayaquil, EC June 11-12 Some R hacking, Snapcraft Summit, Montreal, CA July 9-12 Invited Rcpp Tutorial, useR! 2019, Toulouse, FR

Paul Wise: FLOSS Activities April 2019

Mër, 01/05/2019 - 2:36pd
Changes Issues Review Administration
  • Debian: restart postgresql for cert update
  • Debian mentors: workaround some issues
  • Debian wiki: whitelist email domains, whitelist email addresses, reset email addresses
  • Initiate discussions about various issues with several derivatives
  • Invite Donau OS, BlackWeb to the Debian derivatives census
  • Welcome Mentor Embedded Linux Omni OS, TTOS, BlackWeb to the Debian derivatives census
  • Respond to queries from Debian users and developers on the mailing lists and IRC

The librecaptcha issues were sponsored by my employer. All other work was done on a volunteer basis.

Benjamin Mako Hill: New Research on How Anonymity is Perceived in Open Collaboration

Mër, 01/05/2019 - 1:11pd

Online anonymity often gets a bad rap and complaints about antisocial behavior from anonymous Internet users are as old as the Internet itself. On the other hand, research has shown that many Internet users seek out anonymity to protect their privacy while contributing things of value. Should people seeking to contribute to open collaboration projects like open source software and citizen science projects be required to give up identifying information in order to participate?

I was part of a team led by Nora McDonald that conducted a two-part study to better understand how open collaboration projects balance the threats of bad behavior with the goal of respecting contributors’ expectations of privacy. First, we interviewed eleven people from five different open collaboration “service providers” to understand what threats they perceive to their projects’ mission and how these threats shape privacy and security decisions when it comes to anonymous contributions. Second, we analyzed discussions about anonymous contributors on publicly available logs of the English language Wikipedia mailing list from 2010 to 2017.

In the interview study, we identified three themes that pervaded discussions of perceived threats. These included threats to:

  1. community norms, such as harrassment;
  2. sustaining participation, such as loss of or failure to attract volunteers; and
  3. contribution quality, low-quality contributions drain community resources.

We found that open collaboration providers were most concerned with lowering barriers to participation to attract new contributors. This makes sense given that newbies are the lifeblood of open collaboration communities. We also found that service providers thought of allowing anonymous contributions as a way of offering low barriers to participation, not as a way of helping contributors manage their privacy. They imagined that anonymous contributors who wanted to remain in the community would eventually become full participants by registering for an account and creating an identity on the site. This assumption was evident in policies and technical features of collaboration platforms that barred anonymous contributors from participating in discussions, receiving customized suggestions, or from contributing at all in some circumstances. In our second study of the English language Wikipedia public email listserv, we discovered that the perspectives we encountered in interviews also dominated discussions of anonymity on Wikipedia. In both studies, we found that anonymous contributors were seen as “second-class citizens.

This is not the way anonymous contributors see themselves. In a study we published two years ago, we interviewed people who sought out privacy when contributing to open collaboration projects. Our subjects expressed fears like being doxed, shot at, losing their job, or harassed. Some were worried about doing or viewing things online that violated censorship laws in their home country. The difference between the way that anonymity seekers see themselves and the way they are seen by service providers was striking.

One cause of this divergence in perceptions around anonymous contributors uncovered by our new paper is that people who seek out anonymity are not able to participate fully in the process of discussing and articulating norms and policies around anonymous contribution. People whose anonymity needs means they cannot participate in general cannot participate in the discussions that determine who can participate.

We conclude our paper with the observation that, although social norms have played an important role in HCI research, relying on them as a yardstick for measuring privacy expectations may leave out important minority experiences whose privacy concerns keep them from participating in the first place. In online communities like open collaboration projects, social norms may best reflect the most privileged and central users of a system while ignoring the most vulnerable

This blog post was originally posted on the Community Data Science Collective blog. Both this blog post and the paper, Privacy, Anonymity, and Perceived Risk in Open Collaboration: A Study of Service Providers, was written by Nora McDonald, Benjamin Mako Hill, Rachel Greenstadt, and Andrea Forte and will be published in the Proceedings of the 2019 ACM CHI Conference on Human Factors in Computing Systems next week. The paper will be presented at the CHI conference in Glasgow, UK on Wednesday May 8, 2019. The work was supported by the National Science Foundation (awards CNS-1703736 and CNS-1703049).

Jonathan McDowell: Setting up SSH 2FA using TOTP

Mar, 30/04/2019 - 10:27md

I spend a lot of time connected to remote hosts. My email and IRC client live on a dedicated server with Bytemark, which makes it easy to access wherever I am in the world. I have a well connected VM for running Debian package builds on using sbuild. At home my Home Assistant setup lives in its own container. And of course that lives on a server which is in the comms room and doesn’t even have a video card installed. At work my test machines are all in the server room rather than noisily on my desk. I connect to all of these with SSH (and screen, though I keep meaning to investigate tmux more thoroughly) - I’ve been doing so since the days of dialup, I’m very happy with the command line and I generally don’t need the overhead of a remote GUI. I don’t think I’m unusual in this respect (especially among people likely to be reading this post).

One of the things I love about SSH is the ability to use SSH keys. That means I don’t have to remember passwords for hosts - they go in my password manager for emergencies, I login with them once to drop my .ssh/authorised_keys file in place, and I forget them. For my own machines, where possible, I disable password logins entirely. However there are some hosts I want to be able to get to even without having an SSH key available, but equally would like a bit more security on. A while back I had a conversation with some local folk about the various options and decided that some sort of two-factor authentication (2FA) was an appropriate compromise; I was happy to trust an SSH key on its own, but for a password based login I wanted an extra piece of verification. I ended up putting the Google Authenticator on my phone, which despite the name is actually a generic implementation of the TOTP and HTOP one-time password algorithms. It’s turned out useful for various websites as well (in particular at work I have no phone coverage and 2FA on O365. Having Authenticator installed makes that easier than having to wave my phone near the window to get an SMS login token).

For the server side I installed the Google Authenticator PAM module, conveniently available in Debian with a simple apt install libpam-google-authenticator. I added:

auth required nullok

to /etc/pam.d/sshd below the @include common-auth line, and changed

ChallengeResponseAuthentication no

in /etc/ssh/sshd_config to be yes instead. servicectl restart sshd restarts SSH and brings the new config into play. At this point password only logins are still ok (thanks to the nullok above). To enable 2FA you then run google-authenticator as your normal user. This asks a bunch of questions - I went for TOTP (i.e. time based), disabled multiple uses and turned on the rate-limiting. The tool will display an ASCII art QR code (make sure your terminal window is big enough) that can be scanned by the phone app. From this point on the account will require an authentication code after a successful password entry, but also allow SSH key only logins.

For the avoidance of doubt, this does not involve sending any information off to Google or any other network provider. TOTP/HOTP are self contained protocols, and it’s the scanning of the QR code/entering the secret key at setup time that binds the app to the server details. There are other app implementations which will work just fine.

(This post mostly serves to document the setup steps for my own reference; I set it up originally over a year ago and have just had to do so again for a new machine.)

Chris Lamb: Free software activities in April 2019

Mar, 30/04/2019 - 7:59md

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

  • It was my last month in my tenure as Debian Project Leader after two years in the post. Thank you so much for all the support and kind words that I received in the past few weeks and congratulations to Sam Hartman for being elected to the post for the upcoming year.

  • Attended the conference in Gothenburg, Sweden where I gave a talk entitled "What can free software learn from classical music?". As part of this, I also organised a Debian Bug Squashing Party as part of the conference's Community Day — thanks to Kuro Studio for their hospitality.

  • For the Tails privacy-oriented operating system, I attended an in-person sprint in France where I worked on countless issues, features and adjacent concerns regarding the move to Debian "buster".

  • As part of my duties of being on the board of directors of the Open Source Initiative I attended our monthy board meeting, participated in various licensing discussions occurring on the internet, etc.

  • Opened a pull request against the django-q task queue for projects using the Django web framework project in order to inline a Python import. This prevents circular imports under some toolchain combinations. [...]

  • Opened a pull request for the ADMS code generator for the Verilog-AMS hardware description language to make the build reproducible. [...]

  • More hacking on the Lintian static analysis tool for Debian packages, including:

    • Correct false-positives in the missing-systemd-timer-for-cron-script tag due to an incorrect regular expression. (#927970)
    • Don't check for the x86-specific "SafeSEH" hardening feature for code that is JIT-compiled by the Mono runtime. (#926334)
    • Triaged and accepted a huge number of patches and merge requests that had accumulated, adding a large number of new tags, updating systemd hardening flags [...], etc.
  • Created a quick-and-dirty script to obtain Max Temkin's highlights of Star Trek: The Next Generation. [...]

Reproducible builds

Whilst anyone can inspect the source code of free software for malicious flaws almost all software is distributed pre-compiled to end users.

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.

This month:

I also made the following changes to diffoscope, our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues:

  • Add support for semantic comparison of GnuPG "keybox" (.kbx) files. (#871244)
  • Treat missing tools as failures if a "magic" environment variable is detected in order to faciliate interpreting required tools on the Debian autopkgtests as actual test failures, rather than skipping them. The behaviour of the existing testsuite remains unchanged. (#905885)
  • Filed a "request for packaging" for the annocheck tool which can be used to "analyse an application's compilation". This is as part of an outstanding wishlist issue. (#926470)
  • Consolidated on a single alias as the exception value across the entire codebase. [...]

I spent a considerable amount of time our website this month too, including:

  • Using an explicit "draft" boolean flag for posts. Jekyll in Debian stable silently (!) does not support the where_exp filter. [...]
  • Moving more pages away from the old design with HTML to Markdown formatting and the new design template. [...]
  • Addding a simple Makefile to implicitly document how to build the site [...] and add a simple .gitlab-ci.yml to test branches/builds [...].
  • Adding as simple "lint" command so we can see how many pages are using the old style. [...]
  • Adding an explicit link to our "Who is involved?" page in the footer of the newer design [...] and add a link to donation page [...].
  • Moved various bits of infrastructure to support a monthly report structure. [...]

Finally, I made the following changes to strip-nondeterminism, our tool to remove specific non-deterministic results from a completed build:

  • Workaround Archive::Zip's incorrect handling of the localExtraField class member field by monkey-patching the accessor methods to always return normalised values. This fixes the normalisation of Unix ownership metadata within .zip and .epub files. (#858431)
  • Actually check the return status from Archive::Zip when writing file to disk. [...]
  • Catch an edge-case where we can't parse the length of a particular field within .zip files. [...]

Debian Debian LTS

This month I have worked 17 hours on Debian Long Term Support (LTS) and 12 hours on its sister Extended LTS project.


Finally, I also made the following non-maintainer uploads (NMUs) to fix release-critical bugs for "buster".

FTP Team

As a Debian FTP assistant I ACCEPTed 30 packages: easygen, faudio, golang-github-anmitsu-go-shlex, golang-github-apparentlymart-go-cidr, golang-github-apparentlymart-go-rundeck-api, golang-github-corpix-uarand, golang-github-cyberdelia-heroku-go, golang-github-emirpasic-gods, golang-github-facebookgo-inject, golang-github-fzambia-sentinel, golang-github-gliderlabs-ssh, golang-github-hashicorp-go-safetemp, golang-github-hmrc-vmware-govcd, golang-github-icrowley-fake, golang-github-jesseduffield-gocui, golang-github-jesseduffield-pty, golang-github-jesseduffield-termbox-go, golang-github-kevinburke-ssh-config, golang-github-michaeltjones-walk, golang-github-nozzle-throttler, golang-github-stvp-roll, golang-github-willf-bloom, golang-gopkg-src-d-go-billy.v4, libdmtx, openjdk-13, pmdk-convert, python-deprecated, python-django-debreach, qgis & redfishtool.

I additionally filed 3 RC bugs against packages that had potentially-incomplete debian/copyright files against faudio, libdmtx & python-deprecated.

Sergio Durigan Junior: Debian Bug Squashing Party, Toronto version

Mar, 30/04/2019 - 6:00pd


This past Saturday, April 27th, 2019, Samuel Vale, Alex Volkov and I organized the Toronto Bug Squashing Party here in the city. I was very happy with the outcome, especially the fact that we had more than 10 people attending, including a bunch of folks that came from Montréal!

The start

It was a cold day in Toronto, and we met at the Mozilla Toronto office at 9 in the morning. Right there at the door I met anarcat, who had just arrived from Montréal. Together with Alex, we waited for Will to arrive and open the door for us. Then, some more folks started showing up, and we waited until 10:30h to start the first presentation of the day.

Packaging 101

Anarcat kindly gave us his famous "Packaging 101" presentation, in which he explains the basics of Debian packaging. Here's a picture of the presentation:

And another one:

The presentation was great, and Alex recorded it! You can watch it here (sorry, youtube link...).

During the day, we've also taught a few tricks about the BTS, in order to help people file bugs, add/remove tags, comment on bugs, etc.

Then, we moved on to the actual hacking.

Bug fixing

This part took most of the day, as was expected. We started by looking at the RC bugs currently filed against Buster, and deciding which ones would be interesting for us. I won't go into details here, but I think we made great progress, considering this was the first BSP for many of us there (myself included).

You can look at the bugs we worked on, and you will see that we have actually fixed 6 of them! I even fixed a JavaScript bug, which is something totally out of my area of expertise ;-).

I also noticed something interesting. The way we look at bugs can vary wildly between one DD and another. I mean, this is something I always knew, especially when I was more involved with the debian-mentors effort, but it's really amazing to feel this in person. I tend to be more picky when it comes to defining what to do when I start to work on a bug; I try really hard to reproduce it (and spend a lot of time doing so), and will really dive deep into the code trying to understand why some test is failing. Other developer may be less "pedantic", and choose to (e.g.) disable certain test that is failing. In the end, I think everything is a balance and I tried to learn from this experience.

Anyway, given that we looked at 12 bugs and solved 6, I think we did great! And this also helped me to get my head "back in the Debian game"; I was too involved with GDB these past months (there's a post about one of the things I did which is coming soon, stay tunned).

Look at us hacking:

Wrap up

At 19h (or 7p.m.), we had to wrap up and prepare to go. Because we had a sizeable number of Brazilians in the group (5!), the logical thing to do was to go to a pub and resume the conversation there :-). If I say it was one of the first times I went to a pub to drink with newly made friends in Toronto, you probably wouldn't believe, so I won't say anything...

I know one thing for sure: we want to make this again, and soon! In fact, my idea is to do another one after Buster is released (and after the summer is gone, of course), so maybe October. We'll see.


I would like to thank Mozilla Toronto for hosting us; it was awesome to finally visit their office and enjoy their hospitality, personified by Will Hawkins. It is impossible not to thank anarcat, who came all the way from Montréal to give us his Debian Packaging 101 talk. Speaking of the French-Canadian (and Brazilian), it was super awesome meeting Tiago Vaz and Tássia Camões, and it was great seeing Valessio Brito again.

Let me also thank the "locals" who attended the party; it was great seeing everybody there! Hope I can see everybody again when we make the second edition of our BSP :-).

Dirk Eddelbuettel: RcppArmadillo 0.9.400.2.0

Mar, 30/04/2019 - 3:59pd

A new RcppArmadillo release based on the very recent Armadillo upstream release arrived on CRAN earlier today, and will get to Debian shortly.

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) 587 other packages on CRAN.

The (upstream-only again this time) changes are listed below:

  • Upgraded to Armadillo release 9.400.2 (Surrogate Miscreant)

    • faster cov() and cor()

    • added .as_col() and .as_row()

    • expanded .shed_rows() / .shed_cols() / .shed_slices() to remove rows/columns/slices specified in a vector

    • expanded vectorise() to handle sparse matrices

    • expanded element-wise versions of max() and min() to handle sparse matrices

    • optimised handling of sparse matrix expressions: sparse % (sparse +- scalar) and sparse / (sparse +- scalar)

    • expanded eig_sym(), chol(), expmat_sym(), logmat_sympd(), sqrtmat_sympd(), inv_sympd() to print a warning if the given matrix is not symmetric

    • more consistent detection of 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.

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: TeX Live 2019 released

Hën, 29/04/2019 - 11:00md

After a few days of testing of the gold images of the DVDs, we have now officially announced the release of TeX Live 2019.

The DVDs are already being burnt and will soon be sent to the various TeX User groups who ordered. The .iso image is available on CTAN, and the net installer will pull all the newest stuff. Currently we are working on getting those packages updated during the freeze to the newest level in TeX Live.

Before providing the full list of changes, here a ew things I would like to pick out:

  • New frontend based on Tcl/Tk for the installer: The tlshell did already provide a frontend for tlmgr, and Siep has now also provided a new GUI frontend for the installer, which is the default on Windows and Mac. Due to using Tcl/Tk we get better visual integration into the environment, and the installer has been also simplified and streamlined. Thanks a lot to Siep for her great work!
  • Selectable downloader program: If the default LWP module does not work, we have been using wget to download the necessary files. This stopped working on MacOS due to SSL problems. We have now added support for selectable downloader programs, and prefer curl over wget if available.
  • Speedup of the update procedure: During the last year we introduced selectable compressor program for the backups made during updates or manual backups. Till now we used xz which has excellent compression rates, thus we continue using it as main distribution format, but is computationally intensive. We now ship the lz4 compressor for supported architectures, and use it instead of xz when creating backups. lz4 is extremely fast, and the compression rates are still quite good, so this is an excellent compromise.

Most of the above features have been available already either via tlpretest or via regular updates, but are now fully released on the DVD version.

Finally, here are the changes as listed in the master TeX Live documentation:

  • Kpathsea: More consistent brace expansion and path splitting; new variable TEXMFDOTDIR instead of
    hard-coded . in paths allows for easily searching additional or sub-directories (see comments in
  • epTeX, eupTeX: New primitives \readpapersizespecial and \expanded.
  • LuaTEX: Lua 5.3 now used, with concomitant arithmetic and interface changes. The homegrown library pplib is used to read pdf files, thus eliminating the dependency on poppler (and the need for C++); Lua interface changed accordingly.
  • MetaPost: r-mpost command name recognized as an alias for invocation with the –restricted option, and added to the list of restricted commands available by default. Minimum precision now 2 for decimal and binary mode. Binary mode no longer available in MPlib but still available in standalone MetaPost.
  • pdfTEX: New primitive \expanded; if new primitive parameter \pdfomitcharset is set to 1, the /CharSet string omitted from the PDF output, since it cannot feasibly be guaranteed correct, as required by PDF/A-2 and PDF/A-3.
  • XeTEX: New primitives \expanded, \creationdate, \elapsedtime, \filedump, \filemoddate, \filesize, \resettimer, \normaldeviate, \uniformdeviate, \randomseed; extend \Ucharcat to produce active characters.
  • tlmgr: Support curl as a download program; use lz4 and gzip before xz for local backups, if available; prefer system-provided binaries over binaries provided with TeX Live for compressor and download programs, unless the environment variable TEXLIVE_PREFER_OWN is set.
  • install-tl: New option -gui (with no argument) is the default on Windows and Macs, and invokes a new Tcl/TK GUI (see sections 1.3 and 3.1.6).


  • cwebbin ( is now the CWEB implementation in TeX Live, with support for more language dialects, and including the ctwill program to make mini-indexes.
  • chkdvifont: report font information from DVI files, also from tfm/ofm, vf, gf, pk.
  • dvispc: make a DVI file page-independent with respect to specials.

MacTeX: x86_64-darwin now supports 10.12 and higher (Sierra, High Sierra, Mojave); x86_64-darwinlegacy still supports 10.6 and newer. The spell checker Excalibur is no longer included, since it requires 32-bit support.

Platforms: removed sparc-solaris.

That’s all, let the fun begin!

Rhonda D'Vine: Lesbian Visibility Day

Hën, 29/04/2019 - 2:32md

I was musing whether I should post something for the Lesbian Visibility Day on April 26th. After all, being part of the European Lesbian* Conference means a lot to me. I've never felt so much empowered and being part of an event that takes inclusivity to a next level.

And then ... there is still a lot of these internalized doubts. I fully stand behind EL*C and its inclusive agenda. I know that the L is accompanied by an asterisk for a reason. Among others, to make it clear that Bisexual peeps aren't left out. And that trans people are also included. And here I sit, thinking nevertheless, am I allowed to see myself in that spot? Am I enough to take up space in there?

And here I am again with my internalized transphobia. Speaking up, making yourself heard is hard enough for trans feminine people. Especially when you click for everyone and people's first instinct is to address you with he/him pronouns.

Because those are traits are often enough seen as male - and when you don't identify as such you start to try everything to avoid being put into that box. Which results in a self-silencing. Including on such important dates where visibility is what it's about.

So here I am ... Trying to fight these feelings. And as much as I see it needed to be visible in the bisexual community, I also see it very much needed to be visible in the lesbian* community, because I feel connected to both. A lot.

/personal | permanent link | Comments: 0 | Flattr this

Sylvain Beucler: Debian LTS - April 2019

Hën, 29/04/2019 - 1:31md

Here is my transparent report for my work on the Debian Long Term Support (LTS) project, which extends 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 declared max 30h and got 17.25h.

Most of my time was spent on frontdesk duties, in particular vulnerabilities (CVE) triaging, so other contributors quickly know what to work on.
In all honesty I spent more time than assigned, as I took upon myself to dig how things work. Fun facts:

  • The (stable, non-LTS) Debian Security Team has a dozen members but the vast majority of the work is done by 2 people - every single day.
  • The main workflow is: import a daily list of new (public) CVEs from MITRE, batch classify for-us/not-for-us, locate information (patches...), determine severity, and possibly fix. I'm not sure how we're notified of private (embargoed) issues, they are rare.
  • The CVE list grew to a 19MB text file, which Git is pathologically bad at handling. Be ready to git gc regularly and forget about git blame (which is annoying when tracking the evolution of a particular vulnerability).
  • We discussed how to justify whether to fix a vulnerability, with topics on funding and light justifications ("minor issue").
  • Dealing with MITRE is still difficult, I couldn't get CVE-2018-19211 properly marked as duplicate and we had to de-dup on our side; however they did right on not rejecting CVE-2018-19217 as I asked since we eventually tracked a totally different affected version.

Anyway, for a more formal report:

  • triage of new and past undetermined vulnerabilities for jessie: samba (dla-needed), evolution-ews (dla-needed + open bug), libpodofo (ignored), claws-mail (dla-needed + open bug), kgb-bot (refresh status), systemd (dla-needed), cacti (dla-needed), wireshark (5 dla-needed, 5 not-affected jessie, 3 not-affected stretch), android-platform-system-core (NFU/not for us), exiv2 (not-affected), spip (not-affected), twitter-bootstrap (no-dsa, minor), ncurses (undetermined to duplicate + already fixed, clarify with upstream and MITRE), xslt (still no info from Apple), wpa (2 ignored + dla-needed), webkit2gtk (unsupported), epiphany-browser (not affected), gradle (dla-needed + open bug), qt4-x11 (dla-needed), libxslt (dla-needed), axis (dla-needed + report wrong link), gpac (dla-needed)
  • ghostscript: jessie-security update, backporting stretch-security's
  • answer user request on debian-lts
  • workflow discussions: double-posting annoucements, justifying (non-)updates
  • doc updates (reference logos page, update mailing-lists URLs, clamav handling, triage process, www update rationale

If you'd like to know more about LTS security, I recommend you check:

Andreas Metzler: balance sheet snowboarding season 2018/19

Dje, 28/04/2019 - 2:23md

All in a very good season.

For pre-opening I again booked a carving fresh-up workshop with Pure Boarding in Pitztal (November 22 to November 25). As expected this was a great experience with friendly people, but obviously extremely exhausting. ;-)

I started the regular season on December 15 in Damüls on artificial snow, riding a series of bumps through artifical snowfall. We then got a little bit of snow around christmas, which Diedamskopf somehow managed to converted to high-quality slopes, allowing 5 snow days up to and including January 1.

Then this season's snowfall happened (The total amount was not unusual, but quite a bit fell in a very short time.) and I had three amazing days in mid of January. Which promptly was followed by me hurting myself (again) when luging. Did not look/feel too bad, but MRI showed a small tibial plateau fracture, resulting in a snowboarding break until February 23, missing a period of great weather and great snow. From that point on I tried to take a holiday from work whenever there was a sunny day (14 days on-piste in March). Diedamskopf closed early this year (April 7, with about 280 cm of snow left), and even Warth ended the season on easter monday. I had an amazing Easter week with loads of sunshine.

Well here is the balance-sheet, excluding pre-opening in Pitztal and our company outing in Brandnertal (on January 12):

  2018/19 2017/18 2016/17 2015/16 2014/15 2013/14 2012/13 2011/12 2010/11 2009/10 2008/09 2007/08 2006/07 2005/06 number of (partial) days 33 29 30 17 24 30 23 25 30 30 37 29 17 25 Damüls 2 8 4 4 9 29 4 10 23 16 10 5 10 10 Diedamskopf 26 19 23 12 13 1 19 14 4 13 23 24 4 15 Warth/Schröcken 5 2 3 1 2 0 0 1 3 1 4 0 3 0 total meters of altitude 296308 266158 269819 138037 224909 274706 203562 228588 203918 202089 226774 219936 74096 124634 highscore 10850 11116 12245 11015 13278 12848m 13885m 13076m 10976m 11888m 11272m 12108m 8321m 10247m # of runs 701 616 634 354 530 597 468 516 449 462 551 503 189 309

Steinar H. Gunderson: compo 4 writeup

Sht, 27/04/2019 - 10:45md

From time to time (well, actually, the last one before this was in 2003!), at EFNet holds C code golf competitions. We recently had another one, and even though I placed roughly in the middle of the pack, I thought it would be interesting with a writeup.

The task this time was to take two natural numbers (nonnegative integers) of up to 256 digits as arguments, add them and output them on stdout. An added complication is that the numbers may come in with leading zeros, but you are still not allowed to output them (except, of course, for the case 0+0). There are a number of written and unwritten rules on top of that, but basically the code has to be reasonably portable C (ie., no overflow tricks or relying on certain endianness) as accepted by GCC 8's default mode. Apart from that, the entry with the smallest source code (fewest bytes) wins.

Let's start off with my entry in itself:

r[99],*Z,a,b;main(int c,char**V){a=strlen(*++V);b=strlen(V[1]);for(char*R=Z=r+98;a+b+c;*R--=48+c%10)if(c=c/10+(*(a?*V+--a:R)+(b?V[1][--b]:0))%48)Z=R;puts(Z);exit(0);}

That's 166 pretty inscrutinible bytes. We'll reformat it a bit and then see what's going on, line by line:

r[99],*Z,a,b; main(int c,char**V) { a=strlen(*++V); b=strlen(V[1]); for(char*R=Z=r+98;a+b+c;*R--=48+c%10) if(c=c/10+(*(a?*V+--a:R)+(b?V[1][--b]:0))%48) Z=R; puts(Z); exit(0); }

Now we can attack it line by line to try to pry away its secrets. First up is:


These are four variable declarations. A little-known fact is that if you omit “int” from a declaration, GCC will automatically assume it's “int”. That's four bytes saved already. r will be our output buffer (to hold the result of the addition); even though we want it to be of type char, using int allows us to write “99” (giving a 396-byte buffer, as the rules specified you could assume sizeof(int) == 4) instead of “300” or similar. Note that since it's a global variable, it will be zero-initialized, which we'll use to our advantage (the rules also specified that you could rely on this).

We will be looking at *Z (eventually pointing into r), a and b later. For now, going on:

main(int c,char**V)

Again, the return type of a function is implicitly int. Not too much interesting here, besides renaming argc and argv to something shorter and using that you don't need spaces before pointer declarations. (Other entries used K&R prototypes here to save some space. I'll be sure to use that trick the next time!) Note that we'll be using c (argc) as a free variable; since we need to declare it anyway, we can just as well use it as we see fit.

{ a=strlen(*++V); b=strlen(V[1]);

Our algorithm, like almost any addition, works from the back of the two addends (which are in argv[1] and argv[2]) forward. We can choose to use pointer arithmetic or explicit indexes; I chose the latter, since it fit better with my overall structure. Note the use of *++V, which is the same length as V[1], but allows us to refer to V[0] as *V later, which is slightly shorter.

Also note that we're not including string.h here; strlen gets an implicit prototype upon first use, which works fine for our purposes. We get a warning, but warnings are just a sign of great code!


The for statement is great in C golf. for(;cond;); is the same number of bytes as while(cond); (since “for” is a short keyword), but it gives you two free semicolons you can put stuff before, so almost any nontrivial C golf entry will use for in some place. This statement is a handful, so we'll go through it piece by piece:

First of all, we declare a new variable R (for result pointer), pointing into (nearly) the end of the result buffer r; we'll be moving it backwards as we write our result. We also have a variable Z that initially points to the same place as R, but it will only be updated when we write a nonzero digit. This means that if someone asks for e.g. 00123 + 0123, we'll be writing 00246 to our buffer, but Z will point to the string 246. As a special case, 0+0 will be 0 (ie. the single zero will not be stripped), which is just what we want. Note that Z and r are of type int*; we get an implicit pointer conversion here when initializing R, and thus again a lovely warning. (And being able to write +98 instead of +255 or whatever, again saves us a precious byte. r[] being int just keeps on giving!)

Then, we have the condition. We want to keep going as long as we either have input digits left (a or b is nonzero) or we have some carry left to write (e.g. for 999+1, we'll write 000 from the back but still have 1 left to write, so we can't stop immediately. So a+b+c (or, equivalently, a|b|c) it is. Of course, after seeing the other entries, I realized one could just use the much shorter R>r; just write zeros all the way until the start of the buffer. Doh. :-)

Finally, the post-loop code *R--=48+c%10. 48 is a shorter way to write '0' (we assume ASCII). c is the computed digit (computed in the for loop itself, which we'll look at in a minute), including carry, so we need the %10. So if we e.g. have computed c to be 8+7=15, we write '5' (the 1 will carry over into the next iteration), write it to R, and then decrement the pointer.


Again, a mouthful! This reads two input digits in ASCII, add them and produce the output digit (not in ASCII, just as a 0..18 value). We'll look at it from the inside out:

b?V[1][--b]:0 uses the ternary operator, which is also a staple of C golf (and C obfuscation…). If b is zero (we've used up all the digits in b; we're deliberately off-by-one here), we return 0. If not, we look at the (b-1)th digit of argv[1] (the second addend), and decrement. This means we either have '0'..'9' (ASCII 48..57) or 0 (shorter to write than 48). We'll deal with that in a moment. Unfortunately, ?: has very low operator precedence, so we'll need parens around it.

*(a?*V+--a:R) is very similar. We could in write this as a?V[0][--a]:0, but *V is shorter than V[0]. However, we can not write a?*V[--a]:0, since * has the wrong operator precedence, so we'd need to write (*V), which isn't shorter. I very nearly managed to use the fact that x[y] == y[x] (everyone's favorite C trivia), but alas, predecrement also has the wrong precedence. However, the definition of x[y] is *(x+y), and we already have the parens in place due to the ternary operator! Thus, we rewrite the ternary to be over a pointer; R is ASCII 0 at this point (remember, r is a global variable), so *(a?*V+--a:R) gives us exactly what we want. A tricky rewrite to make use of those two bytes that *V save over V[0].

Now we have two things that are ASCII digits or zero. If we add two ASCII digits (where '0' is 48), we need to subtract 96 to get the actual value, ie., A+B-96, but equivalently, we can do (A+B)%48. This is longer due to the parens, but it also works with ASCII 0. So we give up two bytes here to be able to save three bytes in how we write the end-of-string fallbacks; overall, a win.

After this, we add c/10, which is the carry from the previous iteration. Simple enough. Now, we use two C idioms that I don't like, but used to be fairly common in C code (probably still is in certain circles): You can evaluate assignments (ie., a=b evaluates to b, or equivalently, a), and you have implicit cast-to-bool in conditionals. So if (c=foo) means assign foo to c, and then check whether it's nonzero. And this is precisely the check we wanted for whether the computed digit was zero or not:


So if it's a nonzero digit, we update Z (remember that Z points to the first nonzero digit). Right now, R isn't written to, but that is done in the post-iteration expression that we already looked at.

The last part is fairly pedestrian:

puts(Z); exit(0); }

puts(Z) is wonderfully few bytes, and outputs the string with a newline after it (a requiement by the rules). Unfortunately, its return value isn't particularly strictly defined (it just returns a nonnegative value on success); if it has been defined to be nonzero, e.g., the string length, we could have done exit(!puts(Z));. But do note that exit is a few bytes shorter than return.

Now, modern C variants actually specify that main returns 0 if you fall off the end of the last brace, but the rules specifically disallowed relying on this behavior (we'll remove that for the next iteration).

Simple when you look at it, perhaps? You can look at the other entries, including the 150-byte winner, at the compo directory; there's a lot of variation in the algorithm choice, which is fairly unusual for these compos. Do note that the rule set is written in Norwegian, though, so maybe that won't make you much wiser :-)