I realised this week that my recent efforts to improve how Consfigurator makes the fork(2) system call have also created a way to install executables to remote systems which will execute arbitrary Common Lisp code. Distributing precompiled programs using free software implementations of the Common Lisp standard tends to be more of a hassle than with a lot of other high level programming languages. Executables will often be hundreds of megabytes in size even if your codebase is just a few megabytes, because the whole interactive Common Lisp environment gets bundled along with your program s code. Commercial Common Lisp implementations manage to do better, as I understand it, by knowing how to shake out unused code paths. Consfigurator s new mechanism uploads only changed source code, which might only be kilobytes in size, and updates the executable on the remote system. So it should be useful for deploying Common Lisp-powered web services, and the like. Here s how it works. When you use Consfigurator you define an ASDF system analagous to a Python package or Perl distribution called your consfig . This defines HOST objects to represent the machines that you ll use Consfigurator to manage, and any custom properties, functions those properties call, etc.. An ASDF system can depend upon other systems; for example, every consfig depends upon Consfigurator itself. When you execute Consfigurator deployments, Consfigurator uploads the source code of any ASDF systems that have changed since you last deployed this host, starts up Lisp on the remote machine, and loads up all the systems. Now the remote Lisp image is in a similarly clean state to when you ve just started up Lisp on your laptop and loaded up the libraries you re going to use. Only then are the actual deployment instructions are sent on stdin. What I ve done this week is insert an extra step for the remote Lisp image in between loading up all the ASDF systems and reading the deployment from stdin: the image calls fork(2) and establishes a pipe to communicate with the child process. The child process can be sent Lisp forms to evaluate, but for each Lisp form it receives it will actually fork again, and have its child process evaluate the form. Thus, going into the deployment, the original remote Lisp image has the capability to have arbitrary Lisp forms evaluated in a context in which all that has happened is that a statically defined set of ASDF systems has been loaded the child processes never see the full deployment instructions sent on stdin. Further, the child process responsible for actually evaluating the Lisp form received from the first process first forks off another child process and sets up its own control pipe, such that it too has the capacbility to have arbitrary Lisp forms evaluated in a cleanly loaded context, no matter what else it might put in its memory in the meantime. (Things are set up such that the child processes responsible for actually evaluating the Lisp forms never see the Lisp forms received for evaluation by other child processes, either.) So suppose now we have an ASDF system :com.silentflame.cool-web-service, and there is a function (start-server PORT) which we should call to start listening for connections. Then we can make our consfig depend upon that ASDF system, and do something like this:

CONSFIG> (deploy-these ((:ssh :user "root") :sbcl) server.example.org
           ;; Set up Apache to proxy requests to our service.
           (apache:https-vhost ...)
           ;; Now apply a property to dump the image.
           (image-dumped "/usr/local/bin/cool-web-service"
                         '(cool-web-service:start-server 1234)))

Consfigurator will: SSH to server.example.org; upload all the ASDF source for your consfig and its dependencies; compile and load that code into a remote SBCL process; call fork(2) and set up the control pipe; receive the applications of APACHE:HTTPS-VHOST and IMAGE-DUMPED shown above from your laptop, on stdin; apply the APACHE:HTTPS-VHOST property to ensure that Apache is proxying connections to port 1234; send a request into the control pipe to have the child process fork again and dump an executable which, when started, will evaluate the form (cool-web-service:start-server 1234). And that form will get evaluated in a pristine Lisp image, where the only meaningful things that have happened is that some ASDF systems have been loaded and a single fork(2) has taken place. You d probably need to add some other properties to add some mechanism for actually invoking /usr/local/bin/cool-web-service and restarting it when the executable is updated. (Background: The primary reason why Consfigurator s remote Lisp images need to call fork(2) is that they need to do things like setuid from root to other accounts and enter chroots without getting stuck in those contexts. Previously we forked right before entering such contexts, but that meant that Consfigurator deployments could never be multithreaded, because it might later be necessary to fork, and you can t usually do that once you ve got more than one thread running. So now we fork before doing anything else, so that the parent can then go multithreaded if desired, but can still execute subdeployments in contexts like chroots by sending Lisp forms to evaluate in those contexts into the control pipe.)

I just got a new Kobo ebook reader, a Kobo Clara HD. It's pretty similar to the Glo HD I had but which has unfortunately died after 5 years, even after trying to replace the battery.

Quick hardware review This is a neat little device. It's very similar to the Glo HD, which is a bit disappointing: you'd think they would have improved on the design in the 5+ years since the Glo HD has come out.. It does have an "amber" night light which is nice, but the bezel is still not level with the display, and the device is still kind of on the thick side. A USB-C (instead of micro-USB) port would have been nice too. But otherwise, it's pretty slick, and just works. And because the hardware design didn't change, I can still hack at it like a madman, which is really why I bought this thing in the first place. Hopefully it will last longer than 5 years. Ebook readers should really last for decades, not years, but I guess that's too much to expect from our consumerist, suicidal, extinctionist society.

Configuration hacks Here are the hacks I done on the device. I had done many more hacks on the Kobo Glo HD, but I decided to take a more streamlined, minimalist and, hopefully, easier for new users than the pile of hacks I was doing before (which I expand on at the end of the article).

SD card replacement I replaced the SD card. The original card shipped with the Clara HD was 8GB which meant all my books actually fitted on the original, but just barely. The new card is 16GB. Unfortunately, I did this procedure almost at the end of this guide (right before writing the syncthing scripts, below). Next time, that should be the first thing done so the original SD card acts as a pristine copy of the upstream firmware. So even though this seems like an invasive and difficult procedure, I actually do recommend you do it first. The process is basically to:

1. crack open the Kobo case (don't worry, it sounds awful but I've done it often)
2. take the SD card out
3. copy it over to a new, larger card (say on your computer)
4. put the larger card in

This guide has all the details.

Registration bypass hack This guide (from the same author!) has this awesome trick to bypass the annoying registration step. Basically:

1. pretend you do not have wifi
2. mount the device
3. sqlite3 /media/.../KOBOeReader/.kobo/KoboReader.sqlite
4. INSERT INTO user(UserID,UserKey) VALUES('1','');
5. unmount the device

More details in the above guide, again.

Install koreader My e-reader of choise is Koreader. It's just that great. I still don't find the general user interface (ie. the "file browswer") as intuitive as the builtin one, but the book reading just feels better. And anyways it's the easier way to get a shell on the device. Follow those instructions, particularly the NickelMenu instructions (see also the NickelMenu home page). Yes, you need to install some other thing to start koreader, which doesn't start on its own. NickelMenu is the simplest and better integrated I have found. You might also want to install some dictionnaries and configure SSH:

1. mount USB
2. drop your SSH public key in .../KOBOeReader/.adds/koreader/settings/SSH/authorized_keys
3. unmount USB
4. enable SSH in koreader (Gear -> Network -> SSH -> start SSH)

Note that ed25519 keys do not work: try an RSA key. This might be because koreader ships with dropbear (or an older version), but I haven't verified this.

Install syncthing I use Syncthing to copy all my books into the device now. I was previously using Koreader's OPDS support with Calibre's web interface, but that was clunky and annoying, and I'd constantly have to copy books around. Now the entire collection is synchronized. As a bonus, I can actually synchronise (and backup!) the koreader metadata, since it's stored next to the files. So in theory, this means I could use koreader from multiple devices and have my reading progress sync'd, but I haven't tested that feature just yet. I chose Syncthing because it's simple, lightweight, supported on Linux and Android, and statically compiles by default which means it's easy to deploy on the Kobo. Here is how I installed and started Syncthing at first:

1. Download the latest version for ARM
2. extract the archive
3. copy the syncthing binary into .../KOBOeReader/.adds/
4. login over SSH (see above on how to enable) with -p 2222 -l root
5. create the following directory: ~/.config/syncthing/
6. create the following configuration file, named config.xml:

   <configuration version="18">
       <gui enabled="true" tls="false" debugging="false">
           <address>0.0.0.0:8384</address>
       </gui>
   </configuration>
   

7. copy a valid ca-certificates.crt file (say from your Linux desktop) into /etc/ssl/certs/ on the Kobo (otherwise syncthing cannot bootstrap discovery servers)
8. launch syncthing over SSH: /mnt/onboard/.adds/syncthing

You should now be able to connect to the syncthing GUI through your web browser. Immediately change the GUI admin user and password on the Settings: GUI tab. Then, figure out how to start it. Here are your options:

1. on boot (inittab or whatever). downside: power usage.
2. on wifi (udev hacks). downside: unreliable (see wallabako).
3. on demand (e.g. nickel menu, koreader terminal shortcuts). downside: kind of clunky in koreader, did not work in nickel menu.
4. manually, through shell. downside: requires a shell, but then again we already have one through koreader?

What I have done is to write trivial shell scripts (in .../KOBOeReader/scripts) to start syncthing. The first is syncthing-start.sh:

#!/bin/sh
/mnt/onboard/.adds/syncthing serve &

Then syncthing-stop.sh:

#!/bin/sh
/usr/bin/pkill syncthing

This makes those scripts usable from the koreader file browser. Then the folder can be added to the folder shortcuts and a long-hold on the script will allow you to execute it. Still have to figure out why the Nickel Menu script is not working, but it could simply reuse the above to simplify debugging. This is the script I ended up with, in .../KOBOeReader/.adds/nm/syncthing:

menu_item :main    :Syncthing (toggle)    :cmd_spawn         :exec /mnt/onboard/scripts/syncthing-stop.sh
  chain_success:skip:4
    chain_success                      :cmd_spawn          :exec /mnt/onboard/scripts/syncthing-start.sh
    chain_success                      :dbg_toast          :Started Syncthing server
    chain_failure                      :dbg_toast          :Error starting Syncthing server
    chain_always:skip:-1
  chain_success                        :dbg_toast          :Stopped Syncthing server
menu_item :main    :Syncthing (start)    :cmd_output         :exec /mnt/onboard/scripts/syncthing-start.sh
menu_item :main    :Syncthing (stop)    :cmd_output         :exec /mnt/onboard/scripts/syncthing-stop.sh

It's unclear why this doesn't work: I only get "Error starting Syncthing server" for the toggle, and no output for the (start) action. In either case, syncthing doesn't actually start.

Avoided tasks This list wouldn't be complete without listing more explicitly the stuff I have done before on the Kobo Glo HD and which I have deliberately decided not to do here because my time is precious:

• plato install: beautiful project, but koreader is good enough
• wallabako setup: too much work to maintain, Wallabag articles are too distracting and available on my phone anyways
• using calibre to transfer books: not working half the time, different file layout than the source, one less Calibre dependency
• using calibre to generate e-books based on RSS feeds (yes, I did that, and yes, it was pretty bad and almost useless)
• SSH support: builtin to koreader

Now maybe I'll have time to actually read a book...

A new release 0.2.2 of pkgKitten is now on CRAN, and will be uploaded to Debian. pkgKitten makes it simple to create new R packages via a simple function invocation. A wrapper kitten.r exists in the littler package to make it even easier. This release simply corrects on minor aspect in the optional roxygen2 use, and updates the DESCRIPTION file.

Changes in version 0.2.2 (2021-07-19)

• Small update to DESCRIPTION
• Document hello2() argument

More details about the package are at the pkgKitten webpage, the pkgKitten docs site, and the pkgKitten GitHub repo. Courtesy of my CRANberries site, there is also a diffstat report for this release. If you like this or other open-source work I do, you can now sponsor me at GitHub.

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

Like each month, have a look at the work funded by Freexian s Debian LTS offering. Debian project funding In June, we put aside 5775 EUR to fund Debian projects for which we re looking forward to receive more projects from various
Debian teams! Learn more about the rationale behind this initiative in this article. Debian LTS contributors In June, 12 contributors have been paid to work on Debian LTS, their reports are available:

• Abhijith PA did 18.0h (out of 14h assigned and 19h from May), thus carrying over 15h to July.
• Anton Gladky did 12h (out of 12h assigned).
• Ben Hutchings did 13.25h (out of 14h assigned and 2h from May), thus carrying over 2.75h to July.
• Chris Lamb did 18h (out of 18h assigned).
• Emilio Pozuelo Monfort did 29h (out of 40h assigned), thus carrying over 11h to July.
• Holger Levsen s work was coordinating/managing the LTS team, he did 3.5h (out of 12h assigned) and gave back 8.5h to the pool.
• Markus Koschany did 29.75h (out of 30h assigned plus 29.75h from May), thus carrying over 30h for July.
• Ola Lundqvist did 10h (out of 12h assigned and 4.5h from May), thus carrying over 6.5h to July.
• Roberto C. S nchez did 12h (out of 32h assigned), thus carrying over 20h to July.
• Sylvain Beucler did 30h (out of 30h assigned).
• Thorsten Alteholz did 30h (out of 30h assigned).
• Utkarsh Gupta did not report back about their work so we assume they did nothing (out of 40h assigned), thus is carrying over 40h for July.

Evolution of the situation In June we released 30 DLAs. As already written last month we are looking for a Debian LTS project manager and team coordinator.
Finally, we would like to remark once again that we are constantly looking for new contributors. Please contact Holger if you are interested! The security tracker currently lists 41 packages with a known CVE and the dla-needed.txt file has 23 packages needing an update. Thanks to our sponsors Sponsors that joined recently are in bold.

• Platinum sponsors:
  • TOSHIBA (for 70 months)
  • GitHub (for 60 months)
  • Civil Infrastructure Platform (CIP) (for 38 months)
• Gold sponsors:
  • Roche Diagnostics International AG (for 81 months)
  • Linode (for 75 months)
  • Babiel GmbH (for 64 months)
  • Plat Home (for 63 months)
  • University of Oxford (for 20 months)
  • Deveryware (for 7 months)
  • VyOS
• Silver sponsors:
  • The Positive Internet Company (for 86 months)
  • Domeneshop AS (for 85 months)
  • Nantes M tropole (for 79 months)
  • Univention GmbH (for 71 months)
  • Universit Jean Monnet de St Etienne (for 71 months)
  • Ribbon Communications, Inc. (for 65 months)
  • Exonet B.V. (for 54 months)
  • Leibniz Rechenzentrum (for 48 months)
  • CINECA (for 38 months)
  • Minist re de l Europe et des Affaires trang res (for 32 months)
  • Cloudways Ltd (for 21 months)
  • Dinahosting SL (for 19 months)
  • Platform.sh (for 14 months)
  • Bauer Xcel Media Deutschland KG (for 13 months)
  • Moxa Intelligence Co., Ltd. (for 7 months)
  • sipgate GmbH (for 5 months)
  • OVH US LLC (for 3 months)
  • Tilburg University (for 3 months)
• Bronze sponsors:
  • Seznam.cz, a.s. (for 86 months)
  • Evolix (for 85 months)
  • Linuxhotel GmbH (for 83 months)
  • Intevation GmbH (for 82 months)
  • Daevel SARL (for 81 months)
  • Bitfolk LTD (for 80 months)
  • Megaspace Internet Services GmbH (for 80 months)
  • Greenbone Networks GmbH (for 79 months)
  • NUMLOG (for 79 months)
  • WinGo AG (for 78 months)
  • Ecole Centrale de Nantes LHEEA (for 75 months)
  • Entr ouvert (for 70 months)
  • Adfinis AG (for 67 months)
  • Laboratoire LEGI UMR 5519 / CNRS (for 62 months)
  • Tesorion (for 62 months)
  • GNI MEDIA (for 61 months)
  • Bearstech (for 53 months)
  • LiHAS (for 53 months)
  • People Doc (for 49 months)
  • Catalyst IT Ltd (for 47 months)
  • Demarcq SAS (for 41 months)
  • Universit Grenoble Alpes (for 28 months)
  • TouchWeb SAS (for 20 months)
  • SPiN AG (for 16 months)
  • CoreFiling (for 12 months)
  • Institut des sciences cognitives Marc Jeannerod (for 7 months)
  • Observatoire des Sciences de l Univers de Grenoble (for 3 months)

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) 882 other packages on CRAN. This new release gets us Armadillo 10.6.0 which was released yesterday. We did the usual reverse dependency checks (which came out spotless and clean), and had also just done even fuller checks for Rcpp 1.0.7. Since the previous RcppArmadillo 0.10.5.0.0 release we made a few interim releases to the drat repo. In general, Conrad is a little more active than we want to be with (montly or less frequent) CRAN updates so keep and eye on the drat repo (or follow the GitHub repo) for a higher-frequence cadence. To use the drat repo, use install.packages("RcppArmadillo", repos="https://RcppCore.github.io/drat") or update.packages() with a similar repos argument. The full set of changes follows. We include the last interim release as well.

Changes in RcppArmadillo version 0.10.6.0.0 (2021-07-16)

• Upgraded to Armadillo release 10.6.0 (Keep Calm)
  • expanded chol() to optionally use pivoted decomposition
  • expanded vector, matrix and cube constructors to allow element initialisation via fill::value(scalar), eg. mat X(4,5,fill::value(123))
  • faster loading of CSV files when using OpenMP
  • added csv_opts::semicolon option to allow saving/loading of CSV files with semicolon (;) instead of comma (,) as the separator

Changes in RcppArmadillo version 0.10.5.3.0 (2021-07-01)

• Upgraded to Armadillo release 10.5.3 (Antipodean Fortress)
• GitHub-only release
• Extended test coverage with several new tests, added a coverage badge.

Courtesy of my 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 sponsor me at GitHub.

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

My first Linux system in 1992 was a 386 with 4MB of RAM and a 120MB hard drive which (for some reason I forgot) only was supported by Linux for about 90MB. My first hard drive was 70MB and could do 500KB/s for contiguous IO, my first Linux hard drive was probably a bit faster, maybe 1MB/s. My current Linux workstation has 64G of RAM and 2*1TB NVMe devices that can sustain about 1.1GB/s. The laptop I m using right now has 8GB of RAM and a 180GB SSD that can do 380MB/s. My laptop has 2000* the RAM of my first Linux system and maybe 400* the contiguous IO speed. Currently I don t even run a VM with less than 4GB of RAM, NB I m not saying that smaller VMs aren t useful merely that I don t happen to be using them now. Modern AMD64 CPUs support 2MB huge pages . As a proportion of system RAM if I used 2MB pages everywhere they would be a smaller portion of system RAM than the 4KB pages on my first Linux system! I am not suggesting using 2MB pages for general systems. For my workstations the majority of processes are using less than 10MB of resident memory and given the different uses for memory mapped shared objects, memory mapped file IO, malloc(), stack, heap, etc there would be a lot of inefficiency having 2MB the limit for all allocation. But as systems worked with 4MB of RAM or less and 4K pages it would surely work to have only 2MB pages with 64GB or more of RAM. Back in the 90s it seemed ridiculous to me to have 256 byte pages on a 68030 CPU, but 4K pages on a modern AMD64 system is even more ridiculous. Apparently AMD64 supports 1GB pages on some CPUs, that seems ridiculously large but when run on a system with 1TB of RAM that s comparable to 4K pages on my first Linux system. Currently AWS offers 24TB EC2 instances and the Google Cloud Project offers 12TB virtual machines. It might even make sense to have the entire OS using 1GB pages for some usage scenarios on such systems, wasting tens of GB of RAM to save TLB thrashing might be a good trade-off. My personal laptop has 200* the RAM of my first Linux system and maybe 400* the contiguous IO speed. An employer recently assigned me a Thinkpad Carbon X1 Gen6 with an NVMe device that could sustain 5GB/s until the CPU overheated, that s 5000* the contiguous IO speed of my first Linux hard drive. My Linux hard drive had a 28ms average access time and my first Linux hard drive probably was a little better, let s call it 20ms for the sake of discussion. It s generally quoted that access times for NVMe are at best 10us, that s 2000* better than my first Linux hard drive. As seek times are the main factor for swap performance a laptop with 8GB of RAM and a fast NVMe device could be expected to give adequate performance with 2000* the swap of my first Linux system. For the work laptop in question I had 8G of swap and my personal laptop has 6G of swap which is somewhat comparable to the 4MB of swap on my first Linux system in that swap is about equal to RAM size, so I guess my personal laptop is performing better than it can be expected to. These are just some idle thoughts about hardware changes over the years. Don t take it as advice for purchasing hardware and don t take it too seriously in general. Also when writing comments don t restrict yourself to being overly serious, feel free to run the numbers on what systems with petabytes of Optane might be like, speculate on what NUMA systems in laptops might be like, etc. Go wild.

Back in the days of Etch, I converted this blog from Drupal to ikiwiki. I remember being very excited about this brand new concept of static web sites derived from content stored in a version control system. And now over a decade later I ve moved to hugo. I feel some loyalty to ikiwiki and Joey Hess for opening my eyes to the static web site concept. But ultimately I grew tired of splitting my time and energy between learning ikiwiki and hugo, which has been my tool of choice for new projects. When I started getting strange emails that I suspect had something to do with spammers filling out ikiwiki s commenting registration system, I choose to invest my time in switching to hugo over debugging and really understanding how ikiwiki handles user registration. I carefully reviewed anarcat s blog on converting from ikiwiki to hugo and learned about a lot of ikiwiki features I am not using. Wow, it s times like these that I m glad I keep it really simple. Based on the various ikiwiki2hugo python scripts I studied, I eventually wrote a far simpler one tailored to my needs. Also, in what could only be called a desperate act of procrastination combined with a touch of self-hatred (it s been a rough week) I rejected all the commenting options available to me and choose to implement my own in PHP. What?!?! Why would anyone do such a thing? I refer you to my previous sentence about desperate procrastination. And also I know it s fashionable to hate PHP, but honestly as the first programming language I learned, there is something comforting and familiar about it. And, on a more objective level, I can deploy it easily to just about any hosting provider in the world. I don t have to maintain a unicorn service or a nodejs service and make special configuration entries in my web configuration. All I have to do is upload the php files and I m done. Well, I m sure I ll regret this decision. Special thanks to Alexander Bilz for the anatole hugo theme. I choose it via a nearly random click to avoid the rabbit hole of choosing a theme. And, by luck, it has turned out quite well. I only had to override the commento partial theme page to hijack it for my own commenting system s use.

Github recently announced Copilot, a machine learning system that makes suggestions for you when you're writing code. It's apparently trained on all public code hosted on Github, which means there's a lot of free software in its training set. Github assert that the output of Copilot belongs to the user, although they admit that it may occasionally produce output that is identical to content from the training set.

Unsurprisingly, this has led to a number of questions along the lines of "If Copilot embeds code that is identical to GPLed training data, is my code now GPLed?". This is extremely understandable, but the underlying issue is actually more general than that. Even code under permissive licenses like BSD requires retention of copyright notices and disclaimers, and failing to include them is just as much a copyright violation as incorporating GPLed code into a work and not abiding by the terms of the GPL is.

But free software licenses only have power to the extent that copyright permits them to. If your code isn't a derived work of GPLed material, you have no obligation to follow the terms of the GPL. Github clearly believe that Copilot's output doesn't count as a derived work as far as US copyright law goes, and as a result the licenses on the training data don't apply to the output. Some people have interpreted this as an attack on free software - Copilot may insert code that's either identical or extremely similar to GPLed code, and claim that there are no license obligations created as a result, effectively allowing the laundering of GPLed code into proprietary software.

I'm completely unqualified to hold a strong opinion on whether Github's legal position is justifiable or not, and right now I'm also not interested in thinking about it too much. What I think is more interesting is what the impact of either position has on free software. Do we benefit more from a future where the output of Copilot (or similar projects) is considered a derived work of the training data, or one where it isn't? Having been involved in a bunch of GPL enforcement activities, it's very easy to think of this as something that weakens the GPL and, as a result, weakens free software. That was my initial reaction, but that's shifted over the past few days.

Let's look at the GNU manifesto, specifically this section:

The fact that the easiest way to copy a program is from one neighbor to another, the fact that a program has both source code and object code which are distinct, and the fact that a program is used rather than read and enjoyed, combine to create a situation in which a person who enforces a copyright is harming society as a whole both materially and spiritually; in which a person should not do so regardless of whether the law enables him to.

The GPL makes use of copyright law to ensure that GPLed work can't be taken from the commons. Anyone who produces a derived work of GPLed code is obliged to provide that work under the same terms. If software weren't copyrightable, the GPL would have no power. But this is the outcome Stallman wanted! The GPL doesn't exist because copyright is good, it exists because software being copyrightable is what enables the concept of proprietary software in the first place.

The powers that the GPL uses to enforce sharing of code are used by the authors of proprietary software to reduce that sharing. They attempt to forbid us from examining their code to determine how it works - they argue that anyone who does so is tainted, unable to contribute similar code to free software projects in case they produce a derived work of the original. Broadly speaking, the further the definition of a derived work reaches, the greater the power of proprietary software authors. If Oracle's argument that APIs are copyrightable had prevailed, it would have been disastrous for free software. If the Apple look and feel suit had established that Microsoft infringed Apple's copyright, we might be living in a future where we had no free software desktop environments.

When we argue for an interpretation of copyright law that enhances the power of the GPL, we're also enhancing the power of giant corporations with a lot of lawyers on hand. So let's look at this another way. If Github's interpretation of copyright law holds, we can train a model on proprietary code and extract concepts without having to worry about being tainted. The proprietary code itself won't enter the commons, but the ideas it embodies will. No more worries about whether you're literally copying the code that implements an algorithm you want to duplicate - simply start typing and let the model remove the risk for you.

There's a reasonable counter argument about equality here. How much GPL-influenced code is going to end up in proprietary projects when compared to the reverse? It's not an easy question to answer, but we should bear in mind that the majority of public repositories on Github aren't under an open source license. Copilot is already claiming to give us access to the concepts embodied in those repositories. Do these provide more value than is given up? I honestly don't know how to measure that. But what I do know is that free software was founded in a belief that software shouldn't be constrained by copyright, and our default stance shouldn't be to argue against the idea that copyright is weaker than we imagined.

(Edit: this post by Julia Reda makes some of the same arguments, but spends some more time focusing on a legal analysis of why having copyright cover the output of Copilot would be a problem)

comments

This is not only the Year of the Ox, but also the year of Debian 11, code-named bullseye. The release lies ahead, full freeze starts this week. A good opportunity to take a look at what is new in bullseye. In this post new programs and new software versions related to XMPP, also known as Jabber are presented. XMPP exists since 1999, and has a diverse and active developers community. It is a universal communication protocol, used for instant messaging, IoT, WebRTC, and social applications. You probably will encounter some oxen in this post.

• biboumi, XMPP gateway to connect to IRC servers: 8.3 9.0
  The biggest change for users is SASL support: A new field in the Configure ad-hoc command lets you set a password that will be used to authenticate to the nick service, instead of using the cumbersome NickServ method.
  Many more changes are listed in the changelog.
• Dino, modern XMPP client: 0.0.git20181129 0.2.0
  Dino in Debian 10 was practically a technology preview. In Debian 11 it is already a fully usable client, supporting OMEMO encryption, file upload, image preview, message correction and many more features in a clean and beautiful user interface.
• ejabberd, the extensible realtime platform: 18.12.1 21.01.
  Probably the most important improvement for end-users is XEP-0215 support to facilitate modern WebRTC-style audio/video calls. ejabberd also integrates more nicely with systemd (e.g., the watchdog feature if supported, now). Apart from that, a new configuration validator was introduced, which brings a more flexible (but mostly backwards-compatible) syntax. Also, error reporting in case of misconfiguration should be way more helpful, now. As a new authentication backend, JSON Web Tokens (JWT) can be used. In addition to the XMPP and SIP support, ejabberd now includes a full-blown MQTT server. A large number of smaller features has been added, performance was improved in many ways, and several bugs were fixed. See the long list of changes.
• Gajim, a GTK+-based Jabber client: 1.1.2 1.3.1
  The new Debian release brings many improvements. Gajim s network code has been completely rewritten, which leads to faster connections, better recovery from network loss, and less network related hiccups. Customizing Gajim is now easier than ever. Thanks to the new settings backend and a completely reworked Preferences window, you can adapt Gajim to your needs in just a few seconds.
  Good for newcomers: account creation is now a lot easier with Gajim s new assistant. The new Profile window gives you many options to tell people more about yourself. You can now easily crop your own profile picture before updating it.
  Group chats actions have been reorganized. It s now easier to send invitations or change your nickname for example. Gajim also received support for chat markers, which enables you to see how far your contact followed the conversation. But this is by far not everything the new release brings. There are many new and helpful features, such as pasting images from your clipboard directly into the chat or playing voice messages directly from the chat window.
  Read more about the new Gajim release in Debian 11 here.
  Furthermore, three more Gajim plugins are now in Debian: gajim-lengthnotifier, gajim-openpgp for OX (XEP-0373: OpenPGP for XMPP) and gajim-syntaxhighlight.
• NEW Kaidan Simple and user-friendly Jabber/XMPP client 0.7.0
  Kaidan is a simple, user-friendly and modern XMPP chat client. The user interface makes use of Kirigami and QtQuick, while the back-end of Kaidan is entirely written in C++ using Qt and the Qt-based XMPP library QXmpp. Kaidan runs on mobile and desktop systems including Linux, Windows, macOS, Android, Plasma Mobile and Ubuntu Touch.
• mcabber, small Jabber (XMPP) console client: 1.1.0 1.1.2
  A theme for 256 color terminals is now included, the handling of carbon message copies has been improved, and various minor issues have been fixed.
• Poezio, Console-based XMPP client: 0.12.1 0.13.1
  This new release brings many improvements, such as Message Archive (XEP-0313) support, initial support for OMEMO (XEP-0384) through a plugin, HTTP File Upload support, Consitent Color Generation (XEP-0392), and plenty of internal changes and bug fixes. Not all changes in 0.13 and 0.13.1 can be listed, see the CHANGELOG for a more extensive summary.
• Profanity, the console based XMPP client: 0.6.0 0.10.0
  We can not list all changes which have been done, but here are some highlights.
  Support of OMEMO Encryption (XEP-0384). Consistent Color Generation (XEP-0392), be aware of the changes in the command to standardize the names of commands. A clipboard feature has been added. Highlight unread messages with a different color in /wins. Keyboard switch to select the next window with unread messages with alt + a. Support for Last Message Correction (XEP-0308), Allow UTF-8 symbols as OMEMO/OTR/PGP indicator char. Add option to open avatars directly (XEP-0084). Add option to define a theme at startup and some changes to improve themes. Add possibility to easily open URLs. Add experimental OX (XEP-0373, XEP-0374) support. Add OMEMO media sharing support, ...
  There is also a Profanity light package in Debian now, the best option for systems with tight limits on resources.
• Prosody, the lightweight extensible XMPP server: 0.11.2 0.11.9
  Upgrading to the latest stable release of Prosody brings a whole load of improvements in the stability, usability and performance departments. It especially improves the performance of websockets, and PEP performance for users with many contacts. It includes interoperability improvements for a range of clients.
• prosody-modules, community modules and extensions for Prosody: 0.0~hg20190203 0.0~hg20210130
  The ever-growing collection of goodies to plug into Prosody has a number of exciting additions, including a suite of modules to handle invite-based account registration, and others for moderating messages in group chats (e.g. for removal of spam/abuse), server-to-server federation over Tor and client authentication using certificates. Many existing community modules received updates as well.
• Psi, Qt-based XMPP client: 1.3 1.5
  The new version contains important bug fixes.
• salutatoi, multi-frontends, multi-purposes communication tool: 0.7.0a4 0.8.0~hg3453
  This version is now fully running on Python 3, and has full OMEMO support (one2one, groups and files). The CLI frontend (jp) has among new commands a "jp file get" one which is comparable to wget with OMEMO support. A file sharing component is included, with HTTP Upload and Jingle support. For a list of other improvements, please consult the changelog.
  Note, that the upstream project has been renamed to "Libervia".
• NEW sms4you, Personal gateway connecting SMS to XMPP or email 0.0.7
  It runs with a GSM device over ModemManager and uses a lightweight XMPP server or a single email account to handle communication in both directions.
• NEW xmppc, XMPP Command Line Client 0.1.0
  xmppc is a new command line tool for XMPP. It supports some basic features of XMPP (request your roster, bookmarks, OMEMO Devices and fingerprints). You can send messages with both legacy PGP (XEP-0027) and the new OX (XEP-0373: OpenPGP for XMPP).

That's all for now. Enjoy Debian 11 bullseye and Happy Chatting!

This weekend we (Lars and I) finished our first public alpha release of Subplot. Subplot is a tool for helping you to document your acceptance criteria for a project in such a way that you can also produce a programmatic test suite for the verification criteria. We centre this around the concept of writing a Markdown document about your project, with the option to write Gherkin-like given/when/then scenarios inside which detail the automated verification of the acceptance criteria. This may sound very similar to Yarn, a similar concept which Lars, Richard, and I came up with in 2013. Critically back then we were very 'software engineer' focussed and so Yarn was a testing tool which happened to also produce reasonable documentation outputs if you squinted sideways and tried not to think too critically about them. Subplot on the other hand considers the documentation output to be just as important, if not more important, than the test suite output. Yarn was a tool which ran tests embedded in Markdown files, where Subplot is a documentation tool capable of extracting tests from an acceptance document for use in testing your project. The release we made is the first time we're actively asking other people to try Subplot and see whether the concept is useful to them. Obviously we expect there to be plenty of sharp corners and there's a good amount of functionality yet to implement to make Subplot as useful as we want it to be, but if you find yourself looking at a project and thinking "How do I make sure this is acceptable to the stakeholders without first teaching them how to read my unit tests?" then Subplot may be the tool for you. While Subplot can be used to produce test suites with functions written in Bash, Python, or Rust, the only language we're supporting as first-class in this release is Python. However I am personally most interested in the Rust opportunity as I see a lot of Rust programs very badly tested from the perspective of 'acceptance' as there is a tendency in Rust projects to focus on unit-type tests. If you are writing something in Rust and want to look at producing some high level acceptance criteria and yet still test in Rust, then please take a look at Subplot, particularly how we test subplotlib itself. Issues, feature requests, and perhaps most relevantly, code patches, gratefully received. A desire to be actively involved in shaping the second goal of Subplot even more so.

The Rcpp team is pleased to announce release 1.0.7 of Rcpp which arrived at CRAN earlier today, and will be uploaded to Debian shortly. Windows and macOS builds should appear at CRAN in the next few days. This release continues with the six-months cycle started with release 1.0.5 last July. As a reminder, interim dev or rc releases will alwasys be available in the Rcpp drat repo; this cycle there were seven (!!). These rolling release tend to work just as well, and are also fully tested against all reverse-dependencies. Rcpp has become the most popular way of enhancing R with C or C++ code. As of today, 2323 packages on CRAN depend on Rcpp for making analytical code go faster and further, along with 227 in BioConductor. This release contains a change which Luke Tierney urged us to make a good year ago in #1081) (and which we had looked at earlier in #382). Implementing the change in a regular update proved a little tricky, and my initial branch lay dormant until I aki revived it, and finished the transition (which we then did in two PRs). The change concerns how Rcpp grows internal objects, and the new approach (thanks to the hint by Luke) closer to what R does guaranteeing linear behaviour. It turns out that we overlooked one aspect (of coping with Modules built under earlier Rcpp releases) so the initial upload to CRAN on Saturday revealed that we needed a small adjustment that we made for the final release. This version should now be more performant, and rest on a stable API. Based on the reverse depends checks by both us and CRAN (using the updated version), we expect no issues with existing code. However, it something does act up a fresh compilation of the packages using Rcpp may help. We also made a few other minor changes in the API such as silencing a silly compiler warning, ensuring global Rcout and Rcerr objects, adding support for a new Rcpp::message() call, completing a switch to uint32_t instead of unsigned int and including the cfloat header (which relates to STRICT_R_HEADERS discussed below). Similarly, the Rcpp Attributes feature was enhanced by coping better with packages with a dot in their name and their for per-package include files, along with support for more quiet compilation if desired. As some Rcpp users may have seen, we plan to enable STRICT_R_HEADERS by the next release (expected in January 2022). A long issue tick #1158 is laying the ground work. Maintainers of 81 packages which are affected and need a small change (such as for example switching from PI to M_PI); of these 56 have already responded. We plan to be in touch in the fall. Adding the cfloat header is one help in this transition (as the corresponding C header was pulled in when STRICT_R_HEADERS is not defined) as it ensures DBL_EPSILON and alike are defined. Last but not least this is also the first relase in which we welcome I aki as a new member of the Rcpp Core team. Yay! The NEWS file entries follow summarizing the nine key PRs in this release.

Changes in Rcpp release version 1.0.7 (2021-07-06)

• Changes in Rcpp API:
  • Refactored Rcpp_PreserveObject and Rcpp_ReleaseObject which are now O(1) (Dirk and I aki in #1133 and #1135 fixing #382 and #1081).
  • A spuriously assigned variable was removed (Dirk in #1138 fixing #1137).
  • Global Rcout and Rcerr objects are supported via a compiler directive (I aki in #1139 fixing #928)
  • Add support for Rcpp::message (Dirk in #1146 fixing #1145).
  • The uint32_t type is used throughout instead of unsigned int (Dirk in #1153 fixing #1152).
  • The cfloat header for floating point limits is now included (Dirk in #1162 fixing #1161).
• Changes in Rcpp Attributes:
  • Packages with dots in their name can now have per-package include files (Dirk in #1132 fixing #1129).
  • New argument echo to quieten optional evaluation in sourceCpp (Dirk in #1138 fixing #1126).
• Forthcoming Changes in Rcpp API:
  • Starting with Rcpp 1.0.8 anticipated in January 2022, STRICT_R_HEADERS will be enabled by default, see #1126.

Thanks to my CRANberries, you can also look at a diff to the previous release. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page. Bugs reports are welcome at the GitHub issue tracker as well (where one can also search among open or closed issues); questions are also welcome under rcpp tag at StackOverflow which also allows searching among the (currently) 2616 previous questions. If you like this or other open-source work I do, you can sponsor me at GitHub.

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

For the past years, most of the development has happened behind the scene in a private repository, and the code has appeared in the public repository only a couple of months before the release, in the release branch. I have now decided to publish the current code of QSoas in the github repository (in the public branch). This way, you can follow and use all the good things that were developed since the last release, and also verify whether any bug you have is still present in the currently developed version !

Upcoming features
This is the occasion to write a bit about the some of the features that have been added since the publication of the 3.0 release. Not all of them are polished nor documented yet, but here are a few teasers. The current version in github has:

• a comprehensive handling of column/row names, which makes it much easier to work with files with named columns (like the output files QSoas produces !);
• better handling of lists of meta-data, when there is one value of the meta for each segment or each Y column;
• handling of complex numbers in apply-formula;
• defining fits using external python code;
• a command for linear least squares (which has the huge advantage of being exact and not needing any initial parameters);
• commands to pause in a script or sort datasets in the stack;
• improvements over previous commands, in particular with eval;
• ... and more...

Check out the github repository if you want to know more about the new features !

As of now, no official date is planned for the 3.1 release, but this could happen during fall.

About QSoas
QSoas is a powerful open source data analysis program that focuses on flexibility and powerful fitting capacities. It is released under the GNU General Public License. It is described in Fourmond, Anal. Chem., 2016, 88 (10), pp 5050 5052. Current version is 3.0. You can download its source code there (or clone from the GitHub repository) and compile it yourself, or buy precompiled versions for MacOS and Windows there.

I am happy observe that the The Debian Administrator's Handbook is available in six languages now. I am not sure which one of these are completely proof read, but the complete book is available in these languages:

• English
• Norwegian Bokm l
• German
• Indonesian
• Brazil Portuguese
• Spanish

This is the list of languages more than 70% complete, in other words with not too much left to do:

• Chinese (Simplified) - 90%
• French - 79%
• Italian - 79%
• Japanese - 77%
• Arabic (Morocco) - 75%
• Persian - 71%

I wonder how long it will take to bring these to 100%. Then there is the list of languages about halfway done:

• Russian - 63%
• Swedish - 53%
• Chinese (Traditional) - 46%
• Catalan - 45%

Several are on to a good start:

• Dutch - 26%
• Vietnamese - 25%
• Polish - 23%
• Czech - 22%
• Turkish - 18%

Finally, there are the ones just getting started:

• Korean - 4%
• Croatian - 2%
• Greek - 2%
• Danish - 1%
• Romanian - 1%

If you want to help provide a Debian instruction book in your own language, visit Weblate to contribute to the translations. As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

I woke up this morning to a lovely little gallery of pictures of our children that my wife had sent me via WhatsApp. This has become the most common way we interact with family photos. We regularly send and receive photos to and from our families via WhatsApp, which re-compresses them for transit and temporary storage across their network. The original photos, wherever they are, will be in a very high quality (as you get on most modern cameras) and will be backed up in perfect fidelity to either Apple or Google s photo storage solutions. But all of that seems moot, when the most frequent way we engage with the pictures is via a method which compresses so aggressively that you can clearly see the artefacts, even thumbnailed on a phone screen. I still don t feel particularly happy with the solution in place for backing up the photos (or even: getting them off the phone). Both Apple and Google make it less than convenient to get them out of their respective walled gardens. I ve been evaluating the nextCloud app and a Nextcloud instance on my home NAS as a possible alternative.

OS security features and server class systems are things that surely belong together. If a program is important enough to buy expensive servers to run it then it s important enough that you want to have all the OS security features enabled. For such an important program you will also want to have all possible monitoring systems running so you can predict hardware failures etc. Therefore you would expect that you could buy a server, setup the vendor s management software, configure your Linux kernel with security features such as lockdown (a LSM that restricts access to /dev/mem, the iopl() system call, and other dangerous things [1]), and have it run nicely! You will be disappointed if you try doing that on a HP or Dell server though. HP Problems

[370742.622525] Lockdown: hpasmlited: raw io port access is restricted; see man kernel_lockdown.7

The above message is logged when trying to INSTALL (not even run) the hp-health package from the official HP repository (as documented in my previous blog post about the HP ML-110 Gen9 [2]) with lockdown=integrity (the less restrictive lockdown option). Now the HP package in question is in their repository for Debian/Stretch (released in 2017) and the Lockdown LSM was documented by LWN as being released in 2019, so not supporting a Debian/Bullseye feature in Debian/Stretch packages isn t inherently a bad thing apart from the fact that they haven t released a new version of that package since. The Stretch package that I am testing now was released in 2019. Also it s been regarded as best practice to have device drivers for this sort of thing since long before 2017.

# hplog -v
ERROR: Could not open /dev/cpqhealth/cdt.
Please make sure the Health Monitor is started.

Attempting to run the hplog -v command (to view the HP hardware log) gives the above error. Strace reveals that it could and did open /dev/cpqhealth/cdt but had problems talking to something (presumably the Health Monitor daemon) over a Unix domain socket. It would be nice if they could at least get the error message right! Dell Problems

[   13.811165] Lockdown: smbios-sys-info: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
[   13.820935] Lockdown: smbios-sys-info: raw io port access is restricted; see man kernel_lockdown.7
[   18.118118] Lockdown: dchcfg: raw io port access is restricted; see man kernel_lockdown.7
[   18.127621] Lockdown: dchcfg: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
[   19.371391] Lockdown: dsm_sa_datamgrd: raw io port access is restricted; see man kernel_lockdown.7
[   19.382147] Lockdown: dsm_sa_datamgrd: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7

Above is a sample of the messages when booting a Dell PowerEdge R710 with lockdown=integrity with the srvadmin-omacore package installed from the official Dell repository I describe in my blog post about the Dell PowerEdge R710 [3]. Now that repository is for Ubuntu/Xenial which was released in 2015, but again it was best practice to have device drivers for this many years ago. Also the newest Debian based releases that Dell apparently supports are Ubuntu/Xenial and Debian/Jessie which were both released in 2015.

# omreport system esmlog
Error! No Embedded System Management (ESM) log found on this system.

Above is the result when I try to view the ESM log (the Dell hardware log). How Long Should Server Support Last? The Wikipedia List of Dell PowerEdge Servers shows that the R710 is a Generation 11 system. Generation 11 was first released in 2010 and Generation 12 was first released in 2012. Generation 13 was the latest hardware Dell sold in 2015 when they apparently ceased providing newer OS support for Generation 11. Dell currently sells Generation 15 systems and provides more recent support for Generation 14 and Generation 15. I think it s reasonable to debate whether Dell should support servers for 4 generations. But given that a major selling point of server class systems is that they have long term support I think it would make sense to give better support for this and not drop support when it s only 2 versions from the latest release! The support for Dell Generation 11 hardware only seems to have lasted for 3 years after Generation 12 was first released. Also it appears that software support for Dell Generation 13 ceased before Generation 14 was released, that sucks for the people who bought Generation 13 when they were new! HP is currently selling Gen 10 servers which were first released at the end of 2017. So it appears that HP stopped properly supporting Gen 9 servers as soon as Gen 10 servers were released! One thing to note about these support times, when the new generation of hardware was officially released the previous generation was still on sale. So while HP Gen 10 servers officially came out in 2017 that doesn t necessarily mean that someone who wanted to buy a ML-110 Gen10 could actually have done so. For comparison Red Hat Enterprise Linux has been supported for 4-6 years for every release they made since 2005 and Ubuntu has always had a 5 year LTS support for servers. How To Do It Properly The correct way of interfacing with hardware is via a device driver that is supported in the kernel.org tree. That means it goes through the usual kernel source code quality checks which are really good at finding bugs and gives users an assurance that the code won t cause security problems. Generally nothing about the code from Dell or HP gives me confidence that it should be directly accessing /dev/kmem or raw IO ports without risk of problems. Once a driver is in the kernel.org tree it will usually stay there forever and not require further effort from the people who submit it. Then it just works for everyone and tends to work with any other kernel features that people use, like LSMs. If they released the source code to the management programs then it would save them even more effort as they could be maintained by the community.

• [1] https://lwn.net/Articles/791863/
• [2] https://etbe.coker.com.au/2021/05/30/hp-ml110-gen9/
• [3] https://etbe.coker.com.au/2020/09/13/dell-t710-idrac6/

Most people connect to Zoom via a proprietary client which has been on the receiving end of a number of security and privacy issues over the past year, with some experts even describing it as malware. It's not widely known however that Zoom offers a half-decent WebRTC client which means cross-platform one-click access to a Zoom room or webinar without needing to install any software. Given a Zoom link such as https://companyname.zoom.us/j/123456789?pwd=letmein, you can use https://zoom.us/wc/join/123456789?pwd=letmein to connect in your browser. Notice that the pool of Zoom room IDs is global and you can just drop the companyname from the URL. In my experience however, Jitsi has much better performance than Zoom's WebRTC client. For instance, I've never been able to use Zoom successfully on a Raspberry Pi 4 (8GB), but Jitsi works quite well. If you have a say in the choice of conference platform, go with Jitsi instead.

I built my current desktop PC in 2014. A second SSD was added in 2015. The motherboard and the power supply were replaced after a fault¹ in 2016. The memory was upgraded in 2018. A discrete AMD GPU was installed in 2019 to drive two 4K screens. An NVMe disk was added earlier this year to further increase storage performance. This is a testament to the durability of a desktop PC compared to a laptop: it s evolutive and you can keep it a long time. While fine for most usage, the CPU started to become a bottleneck during video conferences.² So, it was set for an upgrade. The table below summarizes the change. This update cost me about 800 . According to some benchmark, the new CPU should be 4 faster when all cores are used and 1.5 faster for a single-threaded workload. Compiling an arbitrary³ kernel provides a 3 speedup. Before: After: Here we go for another seven years!

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

Changes

• flower: fix load test
• kms-jsonrpc: version agnostic cmake dir
• kms-cmake-utils: version agnostic cmake dir
• kurento-module-creator: version agnostic cmake dir
• wayback-machine-downloader: fix crash, fix URI.open usage
• colord: drop abandoned domain
• ptp-gadget: gitignore, fix make dist, drop tar.bz2, document option
• duck: indicators phrases
• check-all-the-things: many TODO items, lists
• Debian usertags QA: refactor, automove ftcbfs, fix noise, support comments
• Debian website: drop freenode
• Debian package uploads: purple-discord experimental/backports
• Debian wiki pages: Bind9, Brave, DebConf/21/Volunteering, DebianKernel/GitBisect, DebianServiceForDD, Derivatives/Census/HandyLinux, Hardware/Wanted, InterWikiMap, MemberBenefits, NewInBullseye, Packaging/debspawn, PaulWise, PortsDocs/New (1 2), QemuUserEmulation, Scanner, Teams/Dpkg/Spec/InstallBootstrap, UnifiedCommunications/DebianDevelopers/UserGuide, Wayland, ZNC_IRC_bouncer
• Bootstrappable Builds wiki pages: Projects List
• FOSSjobs wiki pages: Resources
• Wikipedia: Message-ID

Issues

• Crashes in evolution
• Cross-build failure in ppp
• Migration needed for apparmor-profiles-extra
• Dependency changes for sane-backends, parl-desktop, education-common, hollywood
• Broken URLs in colord
• Features in ognibuild, Debian firefox-esr, diffoscope, fossjobs, evolution
• Warnings in kalgebra
• Usability in ognibuild
• Documentation needed in purple-lurch
• Outdated forks in Kurento jsoncpp
• Typos in abilint
• Security issue in a module of a programming language (sent privately)
• Unhandled message type in purple-discord

Review

• Spam: reported 3 Debian bug reports and 135 Debian mailing list posts
• Debian wiki: RecentChanges for the month
• Debian BTS usertags: changes for the month
• Debian screenshots:
  • approved php-horde endless-sky claws-mail memtester
  • rejected python-gdal/weboob-qt (unrelated software)

Administration

• Debian: restart bacula director
• Debian wiki: approve accounts

Communication

• This month I left freenode, an IRC network I had been on for at least 16 years, for reasons that you probably all read about. I think the biggest lesson I take from this situation and ones happening around the same time is that proper governance in peer production projects is absolutely critical.
• Respond to queries from Debian users and contributors on the mailing lists and IRC

Sponsors The purple-discord/flower work was sponsored by my employers. All other work was done on a volunteer basis.

LTS This is my fourth month of working for LTS. I was assigned 12 hrs and worked all of them.

Released DLAs

1. DLA 2672-1 imagemagick_6.9.7.4+dfsg-11+deb9u13
   • CVE-2020-27751 A flaw was found in MagickCore/quantum-export.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type unsigned long long as well as a shift exponent that is too large for 64-bit type. This would most likely lead to an impact to application availability, but could potentially cause other problems related to undefined behavior.
   • CVE-2021-20243 A flaw was found in MagickCore/resize.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of math division by zero.
   • CVE-2021-20245 A flaw was found in coders/webp.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of math division by zero.
   • CVE-2021-20309 A division by zero in WaveImage() of MagickCore/visual-effects.c may trigger undefined behavior via a crafted image file submitted to an application using ImageMagick.
   • CVE-2021-20312 An integer overflow in WriteTHUMBNAILImage of coders/thumbnail.c may trigger undefined behavior via a crafted image file that is submitted by an attacker and processed by an application using ImageMagick.
   • CVE-2021-20313 A potential cipher leak when the calculate signatures in TransformSignature is possible.
2. DLA 2677-1 libwebp_0.5.2-1+deb9u1
   • CVE-2018-25009 An out-of-bounds read was found in function WebPMuxCreateInternal. The highest threat from this vulnerability is to data confidentiality and to the service availability.
   • CVE-2018-25010 An out-of-bounds read was found in function ApplyFilter. The highest threat from this vulnerability is to data confidentiality and to the service availability.
   • CVE-2018-25011 A heap-based buffer overflow was found in PutLE16(). The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
   • CVE-2018-25012 An out-of-bounds read was found in function WebPMuxCreateInternal. The highest threat from this vulnerability is to data confidentiality and to the service availability.
   • CVE-2018-25013 An out-of-bounds read was found in function ShiftBytes. The highest threat from this vulnerability is to data confidentiality and to the service availability.
   • CVE-2018-25014 An unitialized variable is used in function ReadSymbol. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
   • CVE-2020-36328 A heap-based buffer overflow in function WebPDecodeRGBInto is possible due to an invalid check for buffer size. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
   • CVE-2020-36329 A use-after-free was found due to a thread being killed too early. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
   • CVE-2020-36330 An out-of-bounds read was found in function ChunkVerifyAndAssign. The highest threat from this vulnerability is to data confidentiality and to the service availability.
   • CVE-2020-36331 An out-of-bounds read was found in function ChunkAssignData. The highest threat from this vulnerability is to data confidentiality and to the service availability.
   CVE-2020-36332 was marked as ignored for stretch due to too disruptive patch for older versions of libwebp.
3. DLA-2687-1 prosody_0.9.12-2+deb9u3
   • CVE-2021-32917 The proxy65 component allows open access by default, even if neither of the users has an XMPP account on the local server, allowing unrestricted use of the server s bandwidth.
   • CVE-2021-32921 Authentication module does not use a constant-time algorithm for comparing certain secret strings when running under Lua 5.2 or later. This can potentially be used in a timing attack to reveal the contents of secret strings to an attacker.
4. DLA-2687-2 prosody_0.9.12-2+deb9u4 Upload prosody_0.9.12-2+deb9u3 introduced a regression in the mod_auth_internal_hashed module. Big thanks to Andre Bianchi for the reporting an issue and for testing the update. CVE-2021-32918, CVE-2021-32920, were marked as ignored for stretch: the affected code is not existing in that version of prosody.

LTS-Meeting I attended the Debian LTS team Jitsi-meeting.

Debian Science Team

openpiv-python I started to package python-openpiv. The software implements PIV (Particle Image Velocimetry) method to compare two images and obtain velocity field.

Other FLOSS activities

Admesh Admesh is the first package which I adopted over 10 years ago! Upstream is not active for a very long time, so I created a github-repo back in 2013. The software helps to manipulate STL-files. STL is the file format for meshes, mostly developed for CAD programs. This month I decided to clean the build system. It was switched to cmake. CI was updated, now it compiles the sources under Linux/Windows environment, runs tests, AddressSanitizer and UndefinedBehaviourSanitizer were employed. Work is ongoing.

MIT Technology Review has an interesting article about Google Project Zero shutting down a western intelligence operation [1]. There s an Internet trend of people eating rotten meat they call high meat (rotten meat) [2]. This is up there with people setting themselves on fire and nut shot videos. A young female who was making popular Twitter posts about motorbikes turned out to be a 50yo man using deep fake technology [3]. He has long hair IRL and just needed to replace his face. After coming out of the closet he has continued making such videos and remains popular. FYHTECH has an informative blog post about using sgdisk to backup and restore GPT partition tables [4]. This is in the Debian package gdisk along with several other tools for managing partition tables. One interesting thing to note is that you can backup a partition table and restore to a smaller device (with a bunch of warnings that you can ignore if you know what you are doing). This is the only way I ve discovered to cleanly truncate a GPT partitioned disk, which is sometimes necessary when running VMs. Insightful blog post about PCIe bifurcation and how PCIe lanes are assigned to sockets [5]. This explains why many motherboards have sockets with unused PCIe lanes, EG *8 sockets that are wired for *4. The PCIe slots all go back to the CPU which has a limited number of *16 PCIe connections that are bifurcated to make the larger number of PCIe slots on the motherboard. New Republic has an interesting article on the infamous transphobe Jordan Peterson s battle with tranquiliser dependency [6]. Wired has an interesting article about the hack of RSA infrastructure related to the SecureID keys 10 years ago [7]. Apparently some 10 year NDAs had delayed it. There are many posts about the situation with Freenode, I think that this one best captures the problems in the shortest amount of text [8]. You could spend a few hours reading about it as I have just done, but just reading this gives you the basics that you need to know to avoid Freenode. That blog post has links to articles about Andrew Lee s involvement with Mt Gox and claims to be the heir to the throne of Korea (which is not a monarchy). Nicholas Wade wrote an insightful and informative article about the origin of Covid19, which leads to the conclusion that it was made in a Chinese laboratory [9]. I first saw this in David Brin s Facebook feed. I would be hesitant to share this sort of thing if it wasn t reviewed by a reliable source, I think David Brin has the skill to analyse this sort of article and the contacts to allow him to seek verification of any scientific issues that are outside his field. I believe that this article is reliable and it s conclusion is most likely to be correct. Interesting Wired article about an art project using display computers at Apple stores to photograph people [10]. Ends with a visit from the FBI.

• [1] https://tinyurl.com/yhoxy6lf
• [2] https://tinyurl.com/ydtssdtx
• [3] https://tinyurl.com/ygwwyrww
• [4] https://tech.feedyourhead.at/content/copy-partition-table-one-disk-another
• [5] https://tinyurl.com/yzf2kw4y
• [6] https://newrepublic.com/article/156829/happened-jordan-peterson
• [7] https://tinyurl.com/yfydxb9r
• [8] https://tinyurl.com/ydl9lajf
• [9] https://tinyurl.com/ygfhdjj9
• [10] https://www.wired.com/2012/07/people-staring-at-computers/