Build & Accessories The tablet is a fairly Pixel-style affair, in that the back has two components, one softer blue one housing the camera and a metal feeling gray one. Build quality is fairly good. The volume and power buttons are located on the right side of the tablet, and this is one of the main issues: You end up accidentally pressing the power button when you want to turn your volume lower, despite the power button having a different texture. Alongside the tablet, you also find a kickstand with a textile back, and a keyboard, both of which attach via magnets (and pogo pins for the keyboard). The keyboard is crammed, with punctuation keys being halfed in size, and it feels mushed compared to my usual experiences of ThinkPads and Model Ms, but it s on par with other Chromebooks, which is surprising, given it s a tablet attachment.

fully assembled chromebook duet

I mostly use the Duet as a tablet, and only attach the keyboard occasionally. Typing with the keyboard on your lap is suboptimal. My first Duet had a few bunches of dead pixels, so I returned it, as I had a second one I could not cancel ordered as well. Oh dear. That one was fine!

Hardware & Connectivity The Chromebook Duet is powered by a Mediatek Helio P60T SoC, 4GB of RAM, and a choice of 64 or 128 GB of main storage. The tablet provides one USB-C port for charging, audio output (a 3.5mm adapter is provided in the box), USB hub, and video output; though, sadly, the latter is restricted to a maximum of 1080p30, or 1440x900 at 60 Hz. It can be charged using the included 10W charger, or use up to I believe 18W from a higher powered USB-C PD charger. I ve successfully used the Chromebook with a USB-C monitor with attached keyboard, mouse, and DAC without any issues. On the wireless side, the tablet provides 2x2 Wifi AC and Bluetooth 4.2. WiFi reception seemed just fine, though I have not done any speed testing, missing a sensible connection at the moment. I used Bluetooth to connect to my smartphone for instant tethering, and my Sony WH1000XM2 headphones, both of which worked without any issues. The screen is a bright 400 nit display with excellent viewing angles, and the speakers do a decent job, meaning you can use easily use this for watching a movie when you re alone in a room and idling around. It has a resolution of 1920x1200. The device supports styluses following the USI standard. As of right now, the only such stylus I know about is an HP one, and it costs about 70 or so. Cameras are provided on the front and the rear, but produce terrible images.

Software: The tablet experience The Chromebook Duet runs Chrome OS, and comes with access to Android apps using the play store (and sideloading in dev mode) and access to full Linux environments powered by LXD inside VMs. The screen which has 1920x1200 is scaled to a ridiculous 1080x675 by default which is good for being able to tap buttons and stuff, but provides next to no content. Scaling it to 1350x844 makes things more balanced. The Linux integration is buggy. Touches register in different places than where they happened, and the screen is cut off in full screen extremetuxracer, making it hard to recommend for such uses. Android apps generally work fine. There are some issues with the back gesture not registering, but otherwise I have not found issues I can remember. One major drawback as a portable media consumption device is that Android apps only work in Widevine level 3, and hence do not have access to HD content, and the web apps of Netflix and co do not support downloading. Though one of the Duets actually said L1 in check apps at some point (reported in issue 1090330). It s also worth noting that Amazon Prime Video only renders in HD, unless you change your user agent to say you are Chrome on Windows - bad Amazon! The tablet experience also lags in some other ways, as the palm rejection is overly extreme, causing it to reject valid clicks close to the edge of the display (reported in issue 1090326). The on screen keyboard is terrible. It only does one language at a time, forcing me to switch between German and English all the time, and does not behave as you d expect it when editing existing words - it does not know about them and thinks you are starting a new one. It does provide a small keyboard that you can move around, as well as a draw your letters keyboard, which could come in handy for stylus users, I guess. In any case, it s miles away from gboard on Android. Stability is a mixed bag right now. As of Chrome OS 83, sites (well only Disney+ so far ) sometimes get killed with SIGILL or SIGTRAP, and the device rebooted on its own once or twice. Android apps that use the DRM sometimes do not start, and the Netflix Android app sometimes reports it cannot connect to the servers.

Performance Performance is decent to sluggish, with micro stuttering in a lot of places. The Mediatek CPU is comparable to Intel Atoms, and with only 4GB of RAM, and an entire Android container running, it s starting to show how weak it is. I found that Google Docs worked perfectly fine, as did websites such as Mastodon, Twitter, Facebook. Where the device really struggled was Reddit, where closing or opening a post, or getting a reply box could take 5 seconds or more. If you are looking for a Reddit browsing device, this is not for you. Performance in Netflix was fine, and Disney+ was fairly slow but still usable. All in all, it s acceptable, and given the price point and the build quality, probably the compromise you d expect.

Summary tl;dr:

• good: Build quality, bright screen, low price, included accessories
• bad: DRM issues, performance, limited USB-C video output, charging speed, on-screen keyboard, software bugs

The Chromebook Duet or IdeaPad Duet Chromebook is a decent tablet that is built well above its price point. It s lackluster performance and DRM woes make it hard to give a general recommendation, though. It s not a good laptop. I can see this as the perfect note taking device for students, and as a cheap tablet for couch surfing, or as your on-the-go laptop replacement, if you need it only occasionally. I cannot see anyone using this as their main laptop, although I guess some people only have phones these days, so: what do I know? I can see you getting this device if you want to tinker with Linux on ARM, as Chromebooks are quite nice to tinker with, and a tablet is super nice.

Changes in RcppArmadillo version 0.9.900.1.0 (2020-06-08)

• Upgraded to Armadillo release 9.900.1 (Nocturnal Misbehaviour)
  • faster solve() for under/over-determined systems
  • faster eig_gen() and eig_pair() for large matrices
  • expanded eig_gen() and eig_pair() to optionally provide left and right eigenvectors
• Switch Travis CI testing to R 4.0.0, use bionic as base distro and test R 3.6.3 and 4.0.0 in a matrix (Dirk in #298).
• Add two badges to README for indirect use and the CSDA paper.
• Adapt RcppArmadillo.package.skeleton() to a change in R 4.0.0 affecting what it exports in NAMESPACE.

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

• [1] https://engineering.fb.com/core-data/zstandard/

• [DLA 2196-2] pound regression update
• [DLA 2219-1] feh security update for one CVE
• [DLA 2218-1] transmission security update for one CVE
• [DLA 2220-1] cracklib2 security update for one CVE
• [DLA 2224-1] dosfstools security update for two CVEs
• [DLA 2225-1] gst-plugins-good0.10 security update for two CVEs
• [DLA 2226-1] gst-plugins-ugly0.10 security update for two CVEs
• [DLA 2227-1] bind9 security update for two CVEs

• ELA-230-1 for bind9 fixing two CVEs
• ELA-231-1 for php5 fixing one CVE

• dvbstream

• ulfius

• the keys on either side of the spacebar are control
• the keys just outside of those are alt/meta
• caps lock is Super, Windows or Command depending on OS
• move any window manager keybindings which now become one handed left hand chords such that they are not.

• left control is caps lock
• right control is the compose key.

• you can easily achieve this rebinding on GNU/Linux, Windows and macOS
• almost every keyboard has enough keys near the spacebar to make it work, and it s fine to have just one super key since it is not involved in any one handed chords
• does not involve relying on the difference between tapping and releasing and holding a modifier key, which I find fragile
• there are control and alt/meta keys available to both hands, so there is much less call for one-handed chording
• control and alt/meta are pressed by the thumb, the strongest finger, so when one-handed chording does come up (e.g. C-x C-n without having to switch between control keys) it s the least harmful form
  • my plan is to use the control/meta key available to the opposite hand for the first key of each sequence, and allow some one handed chording to complete the sequence.
  • there is some temptation to use a curled up little finger on the new alt/meta key, I m finding, but I m trying to stop myself from doing that.

How does Smokeping work Leaving those two aside for now, I'm left with Smokeping, which I used in my previous job to diagnose routing issues, using Smokeping as a decentralized looking glass, which was handy to debug long term issues. Smokeping is a strange animal: it's fundamentally similar to Munin, except it's harder to write plugins for it, so most people just use it for Ping, something for which it excels at. Its trick is this: instead of doing a single ping and returning this metrics, it does multiple ones and returns multiple metrics. Specifically, smokeping will send multiple ICMP packets (20 by default), with a low interval (500ms by default) and a single retry. It also pings multiple hosts at once which means it can quickly scan multiple hosts simultaneously. You therefore see network conditions affecting one host reflected in further hosts down (or up) the chain. The multiple metrics also mean you can draw graphs with "error bars" which Smokeping shows as "smoke" (hence the name). You also get per-metric packet loss. Basically, smokeping runs this command and collects the output in a RRD database:

fping -c $count -q -b $backoff -r $retry -4 -b $packetsize -t $timeout -i $mininterval -p $hostinterval $host [ $host ...]

... where those parameters are, by default:

• $count is 20 (packets)
• $backoff is 1 (avoid exponential backoff)
• $timeout is 1.5s
• $mininterval is 0.01s (minimum wait interval between any target)
• $hostinterval is 1.5s (minimum wait between probes on a single target)

It can also override stuff like the source address and TOS fields. This probe will complete between 30 and 60 seconds, if my math is right (0% and 100% packet loss).

How do draw Smokeping graphs in Grafana A naive implementation of Smokeping in Prometheus/Grafana would be to use the blackbox exporter and create a dashboard displaying those metrics. I've done this at home, and then I realized that I was missing something. Here's what I did.

1. install the blackbox exporter:

   apt install prometheus-blackbox-exporter
   

2. make sure to allow capabilities so it can ping:

   dpkg-reconfigure prometheus-blackbox-exporter
   

3. hook monitoring targets into prometheus.yml (the default blackbox exporter configuration is fine):

   scrape_configs:
     - job_name: blackbox
         metrics_path: /probe
         params:
           module: [icmp]
         scrape_interval: 5s
         static_configs:
           - targets:
             - octavia.anarc.at
             # hardcoded in DNS
             - nexthop.anarc.at
             - koumbit.net
             - dns.google
         relabel_configs:
           - source_labels: [__address__]
             target_label: __param_target
           - source_labels: [__param_target]
             target_label: instance
           - target_label: __address__
             replacement: 127.0.0.1:9115  # The blackbox exporter's real hostname:port.
   

   Notice how we lower the scrape_interval to 5 seconds to get more samples. nexthop.anarc.at was added into DNS to avoid hardcoding my upstream ISP's IP in my configuration.
4. use this Grafana panel to graph the results. It was created with this query:

   sum(probe_icmp_duration_seconds phase="rtt" ) by (instance)
   

   • Set the Legend field to instance RTT
   • Set Draw modes to lines and Mode options to staircase
   • Set the Left Y axis Unit to duration(s)
   • Show the Legend As table, with Min, Avg, Max and Current enabled
   Then this query, for packet loss:

   1-avg_over_time(probe_success[$__interval])!=0 or null
   

   • Set the Legend field to instance packet loss
   • Set a Add series override to Lines: false, Null point mode: null, Points: true, Points Radius: 1, Color: deep red, and, most importantly, Y-axis: 2
   • Set the Right Y axis Unit to percent (0.0-1.0) and set Y-max to 1
   Then set the entire thing to Repeat, on target, vertically. And you need to add a target variable like label_values(probe_success, instance).

The result looks something like this:

Not bad, but not Smokeping

This actually looks pretty good! The resulting dashboard is available in the Grafana dashboard repository.

What is missing? Now, that doesn't exactly look like Smokeping, does it. It's pretty good, but it's not quite what we want. What is missing is variance, the "smoke" in Smokeping. There's a good article about replacing Smokeping with Grafana. They wrote a custom script to write samples into InfluxDB so unfortunately we can't use it in this case, since we don't have InfluxDB's query language. I couldn't quite figure out how to do the same in PromQL. I tried:

stddev(probe_icmp_duration_seconds phase="rtt",instance=~"$instance" )
stddev_over_time(probe_icmp_duration_seconds phase="rtt",instance=~"$instance" [$__interval])
stddev_over_time(probe_icmp_duration_seconds phase="rtt",instance=~"$instance" [1m])

The first two give zero for all samples. The latter works, but doesn't look as good as Smokeping. So there might be something I'm missing. SuperQ wrote a special exporter for this called smokeping_prober that came out of this discussion in the blackbox exporter. Instead of delegating scheduling and target definition to Prometheus, the targets are set in the exporter. They also take a different approach than Smokeping: instead of recording the individual variations, they delegate that to Prometheus, through the use of "buckets". Then they use a query like this:

histogram_quantile(0.9 rate(smokeping_response_duration_seconds_bucket[$__interval]))

This is the rationale to SuperQ's implementation:

Yes, I know about smokeping's bursts of pings. IMO, smokeping's data model is flawed that way. This is where I intentionally deviated from the smokeping exact way of doing things. This prober sends a smooth, regular series of packets in order to be measuring at regular controlled intervals. Instead of 20 packets, over 10 seconds, every minute. You send one packet per second and scrape every 15. This has the same overall effect, but the measurement is, IMO, more accurate, as it's a continuous stream. There's no 50 second gap of no metrics about the ICMP stream. Also, you don't get back one metric for those 20 packets, you get several. Min, Max, Avg, StdDev. With the histogram data, you can calculate much more than just that using the raw data. For example, IMO, avg and max are not all that useful for continuous stream monitoring. What I really want to know is the 90th percentile or 99th percentile. This smokeping prober is not intended to be a one-to-one replacement for exactly smokeping's real implementation. But simply provide similar functionality, using the power of Prometheus and PromQL to make it better. [...] one of the reason I prefer the histogram datatype, is you can use the heatmap panel type in Grafana, which is superior to the individual min/max/avg/stddev metrics that come from smokeping. Say you had two routes, one slow and one fast. And some pings are sent over one and not the other. Rather than see a wide min/max equaling a wide stddev, the heatmap would show a "line" for both routes.

That's an interesting point. I have also ended up adding a heatmap graph to my dashboard, independently. And it is true it shows those "lines" much better... So maybe that, if we ignore legacy, we're actually happy with what we get, even with the plain blackbox exporter. So yes, we're missing pretty "fuzz" lines around the main lines, but maybe that's alright. It would be possible to do the equivalent to the InfluxDB hack, with queries like:

min_over_time(probe_icmp_duration_seconds phase="rtt",instance=~"$instance" [30s])
avg_over_time(probe_icmp_duration_seconds phase="rtt",instance=~"$instance" [5m])
max_over_time(probe_icmp_duration_seconds phase="rtt",instance=~"$instance" [30s])

The output looks something like this:

Looks more like Smokeping!

But there's a problem there: see how the middle graph "dips" sometimes below 20ms? That's the min_over_time function (incorrectly, IMHO) returning zero. I haven't quite figured out how to fix that, and I'm not sure it is better. But it does look more like Smokeping than the previous graph. Update: I forgot to mention one big thing that this setup is missing. Smokeping has this nice feature that you can order and group probe targets in a "folder"-like hierarchy. It is often used to group probes by location, which makes it easier to scan a lot of targets. This is harder to do in this setup. It might be possible to setup location-specific "jobs" and select based on that, but it's not exactly the same.

Credits Credits to Chris Siebenmann for his article about Prometheus and pings which gave me the avg_over_time query idea.

Welcome to the May 2020 report from the Reproducible Builds project. One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. Nonetheless, whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into seemingly secure software during the various compilation and distribution processes. In these reports we outline the most important things that we and the rest of the community have been up to over the past month.

News The Corona-Warn app that helps trace infection chains of SARS-CoV-2/COVID-19 in Germany had a feature request filed against it that it build reproducibly. A number of academics from Cornell University have published a paper titled Backstabber s Knife Collection which reviews various open source software supply chain attacks:

Recent years saw a number of supply chain attacks that leverage the increasing use of open source during software development, which is facilitated by dependency managers that automatically resolve, download and install hundreds of open source packages throughout the software life cycle.

In related news, the LineageOS Android distribution announced that a hacker had access to the infrastructure of their servers after exploiting an unpatched vulnerability. Marcin Jachymiak of the Sia decentralised cloud storage platform posted on their blog that their siac and siad utilities can now be built reproducibly:

This means that anyone can recreate the same binaries produced from our official release process. Now anyone can verify that the release binaries were created using the source code we say they were created from. No single person or computer needs to be trusted when producing the binaries now, which greatly reduces the attack surface for Sia users.

Synchronicity is a distributed build system for Rust build artifacts which have been published to crates.io. The goal of Synchronicity is to provide a distributed binary transparency system which is independent of any central operator. The Comparison of Linux distributions article on Wikipedia now features a Reproducible Builds column indicating whether distributions approach and progress towards achieving reproducible builds.

Distribution work In Debian this month:

• Paul Wise continued a discussion that was started in February regarding the storing and distribution of build logs and other related artifacts and their relationship to reproducible builds. For example, the binutils package ships its own, unreproducible, log files in its binary packages. It was followed-up by replies from Chris Lamb and Matthias Klose.
• 34 reviews of Debian packages were added, 20 were updated and 122 were removed this month adding to our knowledge about identified issues. Chris Lamb added and categorised a new ocaml_cmti_files toolchain issue.

In Alpine Linux, an issue was filed and closed regarding the reproducibility of .apk packages. Allan McRae of the ArchLinux project posted their third Reproducible builds progress report to the arch-dev-public mailing list which includes the following call for help:

We also need help to investigate and fix the packages that fail to reproduce that we have not investigated as of yet.

In openSUSE, Bernhard M. Wiedemann published his monthly Reproducible Builds status update.

Software development

diffoscope Chris Lamb made the changes listed below to diffoscope, our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. He also prepared and uploaded versions 142, 143, 144, 145 and 146 to Debian, PyPI, etc.

• Comparison improvements:
  • Improve fuzzy matching of JSON files as file now supports recognising JSON data. (#106)
  • Refactor .changes and .buildinfo handling to show all details (including the GnuPG header and footer components) even when referenced files are not present. (#122)
  • Use our BuildinfoFile comparator (etc.) regardless of whether the associated files (such as the orig.tar.gz and the .deb) are present. [ ]
  • Include GnuPG signature data when comparing .buildinfo, .changes, etc. [ ]
  • Add support for printing Android APK signatures via apksigner(1). (#121)
  • Identify iOS App Zip archive data as .zip files. (#116)
  • Add support for Apple Xcode .mobilepovision files. (#113)
• Bug fixes:
  • Don t print a traceback if we pass a single, missing argument to diffoscope (eg. a JSON diff to re-load). [ ]
  • Correct differences typo in the ApkFile handler. (#127)
• Output improvements:
  • Never emit the same id="foo" anchor reference twice in the HTML output, otherwise identically-named parts will not be able to linked to via a #foo anchor. (#120)
  • Never emit an empty id anchor either; it is not possible to link to #. [ ]
  • Don t pretty-print the output when using the --json presenter; it will usually be too complicated to be readable by the human anyway. [ ]
  • Use the SHA256 over MD5 hash when generating page names for the HTML directory-style presenter. (#124)
• Reporting improvements:
  • Clarify the message when we truncate the number of lines to standard error [ ] and reduce the number of maximum lines printed to 25 as usually the error is obvious by then [ ].
  • Print the amount of free space that we have available in our temporary directory as a debugging message. [ ]
  • Clarify Command [ ] failed with exit code messages to remove duplicate exited with exit but also to note that diffoscope is interpreting this as an error. [ ]
  • Don t leak the full path of the temporary directory in Command [ ] exited with 1 messages. (#126)
  • Clarify the warning message when we cannot import the debian Python module. [ ]
  • Don t repeat stderr from if both commands emit the same output. [ ]
  • Clarify that an external command emits for both files, otherwise it can look like we are repeating itself when, in reality, it is being run twice. [ ]
• Testsuite improvements:
  • Prevent apksigner test failures due to lack of binfmt_misc, eg. on Salsa CI and elsewhere. [ ]
  • Drop .travis.yml as we use Salsa instead. [ ]
• Dockerfile improvements:
  • Add a .dockerignore file to whitelist files we actually need in our container. (#105)
  • Use ARG instead of ENV when setting up the DEBIAN_FRONTEND environment variable at runtime. (#103)
  • Run as a non-root user in container. (#102)
  • Install/remove the build-essential during build so we can install the recommended packages from Git. [ ]
• Codebase improvements:
  • Bump the officially required version of Python from 3.5 to 3.6. (#117)
  • Drop the (default) shell=False keyword argument to subprocess.Popen so that the potentially-unsafe shell=True is more obvious. [ ]
  • Perform string normalisation in Black [ ] and include the Black output in the assertion failure too [ ].
  • Inline MissingFile s special handling of deb822 to prevent leaking through abstract layers. [ ][ ]
  • Allow a bare try/except block when cleaning up temporary files with respect to the flake8 quality assurance tool. [ ]
  • Rename in_dsc_path to dsc_in_same_dir to clarify the use of this variable. [ ]
  • Abstract out the duplicated parts of the debian_fallback class [ ] and add descriptions for the file types. [ ]
  • Various commenting and internal documentation improvements. [ ][ ]
  • Rename the Openssl command class to OpenSSLPKCS7 to accommodate other command names with this prefix. [ ]
• Misc:
  • Rename the --debugger command-line argument to --pdb. [ ]
  • Normalise filesystem stat(2) birth times (ie. st_birthtime) in the same way we do with the stat(1) command s Access: and Change: times to fix a nondeterministic build failure in GNU Guix. (#74)
  • Ignore case when ordering our file format descriptions. [ ]
  • Drop, add and tidy various module imports. [ ][ ][ ][ ]

In addition:

• Jean-Romain Garnier fixed a general issue where, for example, LibarchiveMember s has_same_content method was called regardless of the underlying type of file. [ ]
• Daniel Fullmer fixed an issue where some filesystems could only be mounted read-only. (!49)
• Emanuel Bronshtein provided a patch to prevent a build of the Docker image containing parts of the build s. (#123)
• Mattia Rizzolo added an entry to debian/py3dist-overrides to ensure the rpm-python module is used in package dependencies (#89) and moved to using the new execute_after_* and execute_before_* Debhelper rules [ ].

Chris Lamb also performed a huge overhaul of diffoscope s website:

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

Upstream patches The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:
  • golang-packaging (toolchain issue, affecting times in minikube)
  • jboss-logging-tools (toolchain issue, affecting date for resteasy)
  • linux_logo (sort find output to avoid inheriting filesystem order)
  • moonjit (generate reproducible output by default if SOURCE_DATE_EPOCH is set)
  • vala (report ASLR nondeterminism)
• Jelle van der Waa:
  • earlyoom (timestamps in Gzip files)
  • fmt (Don t install sphinx-build cached files as they are unneeded & unreproducible)
  • nvidia-settings (timestamp in Gzip files)
• Chris Lamb:
  • #959714 filed against ataqv.
  • #960313 filed against elinks.
  • #960386 filed against briquolo.
  • #960388 filed against cryptominisat.
  • #960590 filed against wolfssl.
  • #960591 filed against mistral.
  • #960607 filed against python-watcherclient.
  • #960669 filed against tree-puzzle.
  • #961009 filed against nulib2.
  • #961202 filed against process-cpp.
  • #961494 filed against bowtie2.
  • #961495 filed against properties-cpp.
  • #961582 filed against wand (forwarded upstream)
  • #961657 filed against vows.
• Vagrant Cascadian:
  • #961747 filed against libstatgrab.
  • #961764 filed against texi2html.
  • #961766 filed against grub.
  • #961830 filed against systemtap.
  • #961942 filed against mono.
  • mescc-tools: Inherit CFLAGS in a Makefile, allowing -ffile-prefix-map/-fdebug-prefix-map to sanitise build paths (merged upstream).

Other tools Elsewhere in our tooling: strip-nondeterminism is our tool to remove specific non-deterministic results from a completed build. In May, Chris Lamb uploaded version 1.8.1-1 to Debian unstable and Bernhard M. Wiedemann fixed an off-by-one error when parsing PNG image modification times. (#16) In disorderfs, our FUSE-based filesystem that deliberately introduces non-determinism into directory system calls in order to flush out reproducibility issues, Chris Lamb replaced the term dirents in place of directory entries in human-readable output/log messages [ ] and used the astyle source code formatter with the default settings to the main disorderfs.cpp source file [ ]. Holger Levsen bumped the debhelper-compat level to 13 in disorderfs [ ] and reprotest [ ], and for the GNU Guix distribution Vagrant Cascadian updated the versions of disorderfs to version 0.5.10 [ ] and diffoscope to version 145 [ ].

Project documentation & website

• Carl Dong:
  • Clarify some potential confusion around GCC libtool. [ ]
• Chris Lamb:
  • Rename the Who page to Projects . [ ]
  • Ensure that Jekyll enters the _docs subdirectory to find the _docs/index.md file after an internal move. (#27)
  • Wrap ltmain.sh etc. in preformatted quotes. [ ]
  • Wrap the SOURCE_DATE_EPOCH Python examples onto more lines to prevent visual overflow on the page. [ ]
  • Correct a preferred spelling error. [ ]
• Holger Levsen:
  • Sort our Academic publications page by publication year [ ] and add Trusting Trust and Fully Countering Trusting Trust through Diverse Double-Compiling [ ].
• Juri Dispan:
  • Update the URL for faketime to the project s Github page. (!57)

Testing framework We operate a large and many-featured Jenkins-based testing framework that powers tests.reproducible-builds.org that, amongst many other tasks, tracks the status of our reproducibility efforts as well as identifies any regressions that have been introduced. Holger Levsen made the following changes:

• System health status:
  • Improve page description. [ ]
  • Add more weight to proxy failures. [ ]
  • More verbose debug/failure messages. [ ][ ][ ]
  • Work around strangeness in the Bash shell let VARIABLE=0 exits with an error. [ ]
• Debian:
  • Fail loudly if there are more than three .buildinfo files with the same name. [ ]
  • Fix a typo which prevented /usr merge variation on Debian unstable. [ ]
  • Temporarily ignore PHP s horde](https://www.horde.org/) packages in Debian bullseye. [ ]
  • Document how to reboot all nodes in parallel, working around molly-guard. [ ]
• Further work on a Debian package rebuilder:
  • Workaround and document various issues in the debrebuild script. [ ][ ][ ][ ]
  • Improve output in the case of errors. [ ][ ][ ][ ]
  • Improve documentation and future goals [ ][ ][ ][ ], in particular documentiing two real world tests case for an impossible to recreate build environment [ ].
  • Find the right source package to rebuild. [ ]
  • Increase the frequency we run the script. [ ][ ][ ][ ]
  • Improve downloading and selection of the sources to build. [ ][ ][ ]
  • Improve version string handling.. [ ]
  • Handle build failures better. [ ]. [ ]. [ ]
  • Also consider architecture all .buildinfo files. [ ][ ]

In addition:

• kpcyrd, for Alpine Linux, updated the alpine_schroot.sh script now that a patch for abuild had been released upstream. [ ]
• Alexander Couzens of the OpenWrt project renamed the brcm47xx target to bcm47xx. [ ]
• Mattia Rizzolo fixed the printing of the build environment during the second build [ ][ ][ ] and made a number of improvements to the script that deploys Jenkins across our infrastructure [ ][ ][ ].

Lastly, Vagrant Cascadian clarified in the documentation that you need to be user jenkins to run the blacklist command [ ] and the usual build node maintenance was performed was performed by Holger Levsen [ ][ ][ ], Mattia Rizzolo [ ][ ] and Vagrant Cascadian [ ][ ][ ].

Mailing list: There were a number of discussions on our mailing list this month: Paul Spooren started a thread titled Reproducible Builds Verification Format which reopens the discussion around a schema for sharing the results from distributed rebuilders:

To make the results accessible, storable and create tools around them, they should all follow the same schema, a reproducible builds verification format. The format tries to be as generic as possible to cover all open source projects offering precompiled source code. It stores the rebuilder results of what is reproducible and what not.

Hans-Christoph Steiner of the Guardian Project also continued his previous discussion regarding making our website translatable. Lastly, Leo Wandersleb posted a detailed request for feedback on a question of supply chain security and other issues of software review; Leo is the founder of the Wallet Scrutiny project which aims to prove the security of Android Bitcoin Wallets:

Do you own your Bitcoins or do you trust that your app allows you to use your coins while they are actually controlled by them ? Do you have a backup? Do they have a copy they didn t tell you about? Did anybody check the wallet for deliberate backdoors or vulnerabilities? Could anybody check the wallet for those?

Elsewhere, Leo had posted instructions on his attempts to reproduce the binaries for the BlueWallet Bitcoin wallet for iOS and Android platforms.

---

If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.
• Twitter: @ReproBuilds
• Reddit: /r/ReproducibleBuilds
• Mailing list: rb-general@lists.reproducible-builds.org

This month s report was written by Bernhard M. Wiedemann, Chris Lamb, Holger Levsen, Jelle van der Waa and Vagrant Cascadian. It was subsequently reviewed by a bunch of Reproducible Builds folks on IRC and the mailing list.

In the beginningWhen the pandemic reached Argentina the government started a quarantine. We engineers (like engineers around the world) started to think on how to put our abilities in order to help with the situation. Some worked toward providing more protection elements to medical staff, some towards increasing the number of ventilation machines at disposal. Another group of people started thinking on another ways of helping. In Bah a Blanca arised the idea of monitoring some variables remotely and in masse.

Simplified Monitoring of Patients in Situations of Mass Hospitalization (MoSimPa)

This is where the idea of remotely monitored devices came in, and MoSimPa (from the spanish of "monitoreo simplificado de pacientes en situaci n de internaci n masiva") started to get form. The idea is simple: oximetry (SpO2), heart rate and body temperature will be recorded and, instead of being shown in a display in the device itself, they will be transmitted and monitored in one or more places. In this way medical staff doesn't has to reach a patient constantly and monitoring could be done by medical staff for more patients at the same time. In place monitoring can also happen using a cellphone or tablet.

The devices do not have a screen of their own and almost no buttons, making them more cheap to build and thus more in line with the current economic reality of Argentina.

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

It is worth to note that the system is designed as a complementary measure for continuous monitoring of a pacient. Care should be taken to check that symptomps and overall patient status don't mean an inmediate life threat. In other words, it is NOT designed for ICUs.

All the above done with Free/Libre/Open Source software and hardware designs. Any manufacturing company can then use them for mass production.

The importance of early pneumonia detection

We were already working in MoSimPa when an NYTimes article caught or attention: "The Infection That s Silently Killing Coronavirus Patients". From the article:

A vast majority of Covid pneumonia patients I met had remarkably low oxygen saturations at triage seemingly incompatible with life but they were using their cellphones as we put them on monitors. Although breathing fast, they had relatively minimal apparent distress, despite dangerously low oxygen levels and terrible pneumonia on chest X-rays.

This greatly reinforced the idea we were on the right track.

The project from a technical standpoint

As the project is primarily designed for and by Argentinians the current system design and software documentation is written in spanish, but the source code (or at least most of it) is written in english. Should anyone need it in english please do not hesitate in asking me.

General system description

The system is comprised of the devices, a main machine acting as a server (in our case for small setups a Raspberry Pi) and the possibility of accessing data trough cell phones, tablets or other PCs in the network.

The hardware

As of today this is the only part in which I still can't provide schematics, but I'll update this blog post and technical doc with them as soon as I get my hands into them.

Again the design is due to be built in Argentina where getting our hands on hardware is not easy. Moreover it needs to be as cheap as possible, specially now that the Argentinian currency, the peso, is every day more depreciated. So we decided on using an ESP32 as the main microprocessor and a set of Maxim sensors devices. Again, more info when I have them at hand.

The software

Here we have many more components to describe. Firstly the ESP32 code is done with the Arduino SDK. This part of the stack will receive many updates soon, as soon as the first hardware prototypes are out.

For the rest of the stack I decided to go ahead with whatever is available in Debian stable. Why? Well, Raspbian provides a Debian stable-based image and I'm a Debian Developer, so things should go just natural for me in that front. Of course each component has its own packaging. I'm one of Debian's Qt maintainers then using Qt will also be quite natural for me. Plots? Qwt, of course. And with that I have most of my necessities fulfilled. I choose PostgreSql as database server and Mosquitto as MQTT broker.

Between the database and MQTT is mosimpa-datakeeper. The piece of software from which medical staff monitor patients is unsurprisingly called mosimpa-monitor.

MoSimPa's monitor main screen

Plots of a patient's data

Alarm thresholds setup

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

ABM main screen

ABM internments view

The idea is to replace it with a web service so it doesn't needs to be confined to the RPi or require installations in other machines. I considered using webassembly but I would have to also build PostgreSql in order to compile Qt's plugin.

Translations? Of course! As I have already mentioned the code is written in English. Qt allows to easily translate applications, so I keep a Spanish one as the code changes (and we are primarily targeting spanish-speaking people). But of course this also means it can be easily translated to whichever language is necessary.

Even if I am a packager I still have some stuff to fix from the packaging itself, like letting datakeeper run with its own user. I just haven't got to it yet.

A video showing the software in action

Certifications

We are working towards getting the system certified by ANMAT, which is the Argentinian equivalent for EEUU's FDA.

Funding

While all the people involved are working ad-honorem funding is still required in order to buy materials, create the prototypes, etc. The project created payments links with Mercado Pago (in spanish and argentinian pesos) and other bank methods (PDF, also in spanish).

I repeat the links here with an aproximation to US$.

- 500 AR$ (less than 8 US$)

- 1000 AR$ (less than 15 US$)

- 2000 AR$ (less than 30 US$)

- 3000 AR$ (less than 45 US$)

- 5000 AR$ (less than 75 US$)

You can check the actual convertion rate in https://www.google.com/search?q=argentine+peso+to+us+dollars

The project was also presented at a funding call of argentinian Agencia de Promoci n de la Investigaci n, el Desarrollo Tecnol gico y la Innovaci n (Agencia I+D+i). 900+ projects where presented and 64 funded, MoSimPa between them.

• Frontdesk: CVE bug triaging for Debian jessie LTS: exim4, cups, log4net, apt, openconnect, libexif, json-c, tomcat8, and graphicsmagick.
• review and sponsor upload to jessie-security: libexif (DLA-2214-1 [1], 5 CVEs)
• review and sponsor upload to jessie-security: libexif (DLA-2222-1 [2], 4 CVEs)
• upload to jessie-security: json-c (DLA-2228-1 [3] and DLA-2228-2 [4], 1 CVE)
• upload to jessie-security: php-horde-gollem (DLA-2228-1 [5], 1 CVE)
• upload to jessie-security: php-horde (DLA-2280-1) [6], 1 CVE)
• start looking into the current FreeRDP (v1.1) and FreeRDP (v2) CVE hell...

• review and sponsor uploads of libexif to stretch, buster and unstable (8 CVE fixes for stretch, 5 CVE fixes for buster) [7]
• revisit long overdue uploads of ssvnc to stretch and buster (4 CVE fixes each) [8]
• upload php-horde-gollem to stretch and buster (1 CVE fix each) [9]
• upload php-horde to stretch and buster (1 CVE fix each) [10]

• Many thanks to Hugh McMaster for handling all the libexif security upload preparations himself. This was really good work. Hugh, please consider becoming a(n official) developer in the Debian project (at the very least you should aim at obtaining Debian Maintainer status).

• [1] https://lists.debian.org/debian-lts-announce/2020/05/msg00016.html
• [2] https://lists.debian.org/debian-lts-announce/2020/05/msg00025.html
• [3] https://lists.debian.org/debian-lts-announce/2020/05/msg00032.html
• [4] https://lists.debian.org/debian-lts-announce/2020/05/msg00034.html
• [5] https://lists.debian.org/debian-lts-announce/2020/05/msg00033.html
• [6] https://lists.debian.org/debian-lts-announce/2020/05/msg00035.html
• [7] Debian bugs #961019, #961803, #961020, and #961804
• [8] Debian bugs #961936 and #963917
• [9] Debian bugs #961921 and #961922
• [10] Debian bugs #961944 and #961945

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

Changes

• nsntrace: cleanups (1 2 3 4 5)
• Tails: cleanup (sent privately)
• apt-offline: cleanups (1 2 3 4 5 6 7 8 9 10 11), fix keyring filename handling, make keyring error more useful, fix apt lists files permissions, fix changelog line copying
• puppet-git-hooks: less generic script naming
• DUCK: fix source code link, orphan package, fix typos, packaging cleanup (1 2 3 4 5), add obsolete site and phrases indicating shutdown, redirects
• myrepos: cleanup (1 2 3 4 5 6)
• check-all-the-things: Python 3 porting (1 2 3)
• debian-goodies: cleanup, fix equivs-build usage, print dbgsym install command
• lintian: add tigris.org to obsolete sites
• spelling dictionaries: codespell (1 2 3 4), lintian (1 2 3 4 5 6)
• DSA puppet git hook: drop leading spaces check, ignore ruby warnings
• DSA puppet: cleanups (1 2)
• Debian build log scanner: update links, fix typos
• Debian QA services: update SSH IP addresses, add usertags typo fixes (1 2)
• Debian user database: fix lat/lon parsing
• Debian package uploads: libfile-libmagic-perl (1 2)
• Debian wiki pages: AutomaticBuildLogProcessing, Brasil/Traduzir/DDTP, DebianEvents/Internet/2020/MiniDebConfOnline/Videos, DebianLocations, es/Webcam/Viejas_camaras_WEB, Firmware/Open, IRC/DpkgBot, IRC/GivingBetterHelp, packages-schroot, PrivacyIssues, ReleaseGoals/VerboseBuilds, Services/DebianSources, SoundConfiguration, sway, SystemBuildTools, Teams (Publicity/ReleasePointAnnouncements, RTC), UnifiedCommunications/DebianDevelopers/UserGuide, WebcamPixart
• myrepos wiki pages: index
• ShellCheck wiki pages: Directive
• FOSSJobs wiki: resources

Issues

• Crashes in dbus/libnss-systemd (1 2), pavucontrol, vlc-plugin-bittorrent
• Permissions issue in update-alternatives (reported on IRC)
• Bogus output in dpkg-parsechangelog (reported on IRC)
• False positives in anorack
• Command name conflict in gitsome
• Python 3 support needed in git-imerge
• Incorrect dependencies in python3-lxml
• Wayland issues in ssh-agent
• Warnings in tweeper
• Features in shellcheck, browserpass, lintian (1 2), diffoscope
• Documentation needed in webext-browserpass
• Description update needed in vagrant
• Inflated severity in shellcheck
• Incorrect behaviour in dch

Review

• Spam: reported 193 Debian mailing list posts
• Debian packages: reviewed and sponsored acr, tudu, duck
• Debian wiki: RecentChanges for the month
• Debian screenshots:
  • approved amiwm dino-im elisa five-or-more fonts-cherrybomb fonts-terminus four-in-a-row gargoyle-free gnome gnome-chess gnome-games gnome-klotski gnome-mahjongg gnome-mines gnome-nibbles gnome-robots gnome-sudoku gnome-taquin gnome-tetravex gv hitori i3-wm iagno inxi lightsoff mate-utils neovim notcurses-bin pacvim quadrapassel radare2-cutter saga swell-foop systemd tali ubuntu-desktop vokoscreen-ng w9wm xfce4-panel xless xpdf
  • rejected saga (Windows screenshot), lightdm (upstream screenshot)
  • approved deletion of muttprint (not a screenshot), virt-manager (non-original, contains logo)
  • rejected deletion of tint/fonts-oflb-euterpe/acm (junk reason), jwm/xbubble (spam)

Administration

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

Communication

• Initiate discussions about reopening bugs for reintroduced packages, integration between apt-listchanges/apt-offline (sent privately)

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

• Opened a pull request against the kitty shell to set a default socket timeout when retrieving remote items via the icat command-line tool. (#659)
• Opened a pull request to make the documentation for the Wand Python/ImageMagick graphics library to build in reproducible manner. [...]
• Fixed an issue in my tickle-me-email library that implements Gettings Things Done (GTD)-like behaviours in IMAP inboxes to prevent a traceback when adding text attachments that were not valid UTF-8. ...]

• The Open Source Initiative held their twice-annual multi-day 'face-to-face' board meeting this time held virtually and participated in the accompanying conversations on strategy, tactical and governance issues, as well as the usual discussions regarding licensing and policy (minutes pending). I also attended the regular monthly meeting for Software in the Public Interest (minutes).
• For my django-slack library (which provides a convenient library between projects using the Django and the Slack chat platform) I reviewed and merged a pull request from Cleiton de Lima to fix an issue due to the force_text method was deprecated favour of force_str. [...]

• Attended more of OpenUK's Teabreak Tuesday and Future Leaders' Training events as well did more work as part of being on the judging panel of the OpenUK Awards. Nominations are open through 15th June in five different categories.
• Opened a pull request for the Redis key-value database to correct a "conflicts" spelling error. [...]

• New features:
  • Check for packages that use $ misc:Pre-Depends) in the Depends field. (#961290)
  • Check for packages installing icon cache files directly under /usr/share/icons/hicolor as they will invariably clash with other packages. (#959855)
  • Check for Homepage fields in debian/control that point to known directory listing pages. (#960366)
  • Update data/fields/perl-provides. [...]
• Bug fixes:
  • Mark that dh-sequence-gnome provides the services of dh_gnome and dh_gnome_clean. (#958500)
  • Accommodate commented-out lines when checking for no-dh-sequencer. (#960485)
• Reporting/output:
  • Clarify error message when the file to check does not exist. (#960970)
  • Mark the debian-rules-uses-as-needed-linker-flag tag as being pedantic & experimental until at least the release of Debian bullseye. (#959696)
• Code improvements:
  • Replace Copyright (C) with the Unicode copyright symbol for consistency [...] and update my copyright years [...].
  • Factor out matching Homepage fields to data/fields/bad-homepages. [...]
  • Various alterations for the continuous integration pipeline. [...][...]

• Opened a pull request to make the documentation for the Wand Python/ImageMagick graphics library to build in reproducible manner. [...]
• In Debian:
  • Submitted 16 patches to fix specific reproducibility issues in ataqv, bowtie2, briquolo, cryptominisat, elinks, mistral, nulib2, process-cpp, properties-cpp, python-watcherclient, tree-puzzle, tree-puzzle, tree-puzzle, vows, wand & wolfssl.
  • Kept isdebianreproducibleyet.com up to date. [...]
• Categorised a large number of packages and issues in the Reproducible Builds "notes" repository.
• In disorderfs, our FUSE-based filesystem that deliberately introduces non-determinism into directory system calls in order to flush out reproducibility issues, I replaced the term "dirents" in place of "directory entries" in human-readable output/log messages [...] and used the astyle source code formatter with the default settings to the main disorderfs.cpp file [...].
• Drafted, published and publicised our monthly report.

• Comparison improvements:
  • Improve fuzzy matching of JSON files as file now supports recognising JSON data. (#106)
  • Refactor .changes and .buildinfo handling to show all details (including the GnuPG header and footer components) even when referenced files are not present. (#122)
  • Use our BuildinfoFile comparator (etc.) regardless of whether the associated files (such as the orig.tar.gz and the .deb) are present. [...]
  • Include GnuPG signature data when comparing .buildinfo, .changes, etc. [...]
  • Add support for printing Android APK signatures via apksigner(1). (#121)
  • Identify "iOS App Zip archive data" as .zip files. (#116)
  • Add support for Apple Xcode .mobilepovision files. (#113)
• Bug fixes:
  • Don't print a traceback if we pass a single, missing argument to diffoscope (eg. a JSON diff to re-load). [...]
  • Correct differences typo in the ApkFile handler. (#127)
• Output improvements:
  • Never emit the same id="foo" anchor reference twice in the HTML output, otherwise identically-named parts will not be able to linked to via a #foo anchor. (#120)
  • Never emit an empty "id" anchor either; it is not possible to link to #. [...]
  • Don't pretty-print the output when using the --json presenter; it will usually be too complicated to be readable by the human anyway. [...]
  • Use the SHA256 over MD5 hash when generating page names for the HTML directory-style presenter. (#124)
• Reporting improvements:
  • Clarify the message when we truncate the number of lines to standard error [...] and reduce the number of maximum lines printed to 25 as usually the error is obvious by then [...].
  • Print the amount of free space that we have available in our temporary directory as a debugging message. [...]
  • Clarify Command [ ] failed with exit code messages to remove duplicate exited with exit but also to note that diffoscope is interpreting this as an error. [...]
  • Don't leak the full path of the temporary directory in Command [ ] exited with 1 messages. (#126)
  • Clarify the warning message when we cannot import the debian Python module. [...]
  • Don't repeat stderr from if both commands emit the same output. [...]
  • Clarify that an external command emits for both files, otherwise it can look like we are repeating itself when, in reality, it is being run twice. [...]
• Testsuite improvements:
  • Prevent apksigner test failures due to lack of binfmt_misc, eg. on Salsa CI and elsewhere. [...]
  • Drop .travis.yml as we use Salsa instead. [...]
• Dockerfile improvements:
  • Add a .dockerignore file to whitelist files we actually need in our container. (#105)
  • Use ARG instead of ENV when setting up the DEBIAN_FRONTEND environment variable at runtime. (#103)
  • Run as a non-root user in container. (#102)
  • Install/remove the build-essential during build so we can install the recommended packages from Git. [...]
• Codebase improvements:
  • Bump the officially required version of Python from 3.5 to 3.6. (#117)
  • Drop the (default) shell=False keyword argument to subprocess.Popen so that the potentially-unsafe shell=True is more obvious. [...]
  • Perform string normalisation in Black [...] and include the Black output in the assertion failure too [...].
  • Inline MissingFile's special handling of deb822 to prevent leaking through abstract layers. [...][...]
  • Allow a bare try/except block when cleaning up temporary files with respect to the flake8 quality assurance tool. [...]
  • Rename in_dsc_path to dsc_in_same_dir to clarify the use of this variable. [...]
  • Abstract out the duplicated parts of the debian_fallback class [...] and add descriptions for the file types. [...]
  • Various commenting and internal documentation improvements. [...][...]
  • Rename the Openssl command class to OpenSSLPKCS7 to accommodate other command names with this prefix. [...]
• Misc:
  • Rename the --debugger command-line argument to --pdb. [...]
  • Normalise filesystem stat(2) "birth times" (ie. st_birthtime) in the same way we do with the stat(1) command's Access: and Change: times to fix a nondeterministic build failure in GNU Guix. (#74)
  • Ignore case when ordering our file format descriptions. [...]
  • Drop, add and tidy various module imports. [...][...][...][...]

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

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

• Investigated and triaged freerdp, keystone, nginx, tcpreplay & thunderbird, as well as tended to the general upkeep of the dla-needed.txt and ela-needed.txt files, adding various notes, references, attributions and citations.
• Frontdesk duties including responding to user/developer questions, reviewing others' packages, participating in mailing list discussions as well as attending our second regular IRC contributor meeting.
• Issued DLA 2201-1 to prevent a Denial of Service (DoS) vulnerability the ntp network time protocol server/client. ntp allowed an "off-path" attacker to block unauthenticated synchronisation via a server mode packet with a spoofed source IP address because transmissions were rescheduled even if a packet lacked a valid "origin timestamp".
• Issued DLA 2203-1 for the SQLite database to prevent a denial of service attack. In the event of a semantic error in an aggregate query, SQLite did not return early from the resetAccumulator() function which would lead to a crash via a segmentation fault.
• Issued DLA 2204-1 for the Mailman mailing list manager to prevent an arbitrary content injection attack.
• Issued DLA 2211-1 in order to prevent an XML external entity vulnerability in log4net, a logging API for the ECMA Common Language Infrastructure (CLI), sometimes referred to as "Mono". This type of attack occurs when XML input containing a reference to an internet-faced entity is processed by a weakly configured XML parser.
• Prepared and issued ELA-229-1 and DLA 2217-1 for the Apache Tomcat Java server to prevent a remote code execution exploit.

• apksigner: Uses en-dashes (U+2013) in manpage over two hyphens. (#960778)
• devscripts: dd-list -nou results in "unknown option: [ ]". (#960891)
• node-redis: autopkgtest regressions against Redis 6.x. (#960105)

• python-django (3.0.6-1) New upstream bugfix release.
• redis:
  • 6.0.0-1 New upstream "General Availability" release.
  • 6.0.0-2 Mark an autopkgtest as being flaky for now.
  • 6.0.1-1, 6.0.1-2 & 6.0.1-2~bpo10+1 New upstream "General Availability" releases.
  • 6.0.3-1 & 6.0.3-1~bpo10+1 New upstream "General Availability" releases.
• memcached (1.6.6-1) New upstream release, fixing a build failure on s390x and similar architectures. (#960459)
• bfs (1.7-1) New upstream release & move to debhelper-compat level 13.

1. setting a mark just so you can jump back to it (i) is a distinct operation you have to think of separately; and (ii) requires two keypresses, C-SPC C-SPC, rather than just one keypress
2. using exchange-point-and-mark activates the region, so to use it for navigation you need to use either C-u C-x C-x or C-x C-x C-g, neither of which are convenient to type, or else it will be difficult to set regions at the place you ve just jumped to because you ll already have one active.

(defun spw/exchange-point-and-mark (arg)
  "Exchange point and mark, but reactivate mark a bit less often.

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

(setq transient-mark-mode nil)
(defun spw/remap-mark-command (command &optional map)
  "Remap a mark-* command to temporarily activate Transient Mark mode."
  (let* ((cmd (symbol-name command))
         (fun (intern (concat "spw/" cmd)))
         (doc (concat "Call  "
                      cmd
                      "&apos and temporarily activate Transient Mark mode.")))
    (fset fun  (lambda ()
                 ,doc
                 (interactive)
                 (call-interactively #&apos,command)
                 (activate-mark)))
    (if map
        (define-key map (vector &aposremap command) fun)
      (global-set-key (vector &aposremap command) fun))))
(dolist (command &apos(mark-word
                   mark-sexp
                   mark-paragraph
                   mark-defun
                   mark-page
                   mark-whole-buffer))
  (spw/remap-mark-command command))
(with-eval-after-load &aposorg
  (spw/remap-mark-command &aposorg-mark-element org-mode-map)
  (spw/remap-mark-command &aposorg-mark-subtree org-mode-map))
;; optional
(global-set-key "\M-=" (lambda () (interactive) (activate-mark)))
;; resettle the previous occupant
(global-set-key "\C-cw" &aposcount-words-region)

1. under the effects of mitigation #1, how much of a barrier to using marks for navigational purposes is it to have to press C-SPC C-SPC instead of having a single binding, C-SPC, for all manual mark setting²
2. under the effects of mitigation #2, how much of a barrier to taking advantage of commands which act differently when the region is active is it to have to temporarily enable Transient Mark mode with C-SPC C-SPC, M-= or one of the mark-* commands?