Search Results: "ag"

1 April 2021

Russell Coker: Censoring Images

A client asked me to develop a system for censoring images from an automatic camera. The situation is that we have a camera taking regular photos from a fixed location which includes part of someone else s property. So my client made a JPEG with some black rectangles in the sections that need to be covered. The first thing I needed to do was convert the JPEG to a PNG with transparency for the sections that aren t to be covered. To convert it I loaded the JPEG in the GIMP and went to the Layer->Transparency->Add Alpha Channel menu to enabled the Alpha channel. Then I selected the Bucket Fill tool and used Mode Erase and Fill by Composite and then clicked on the background (the part of the JPEG that was white) to make it transparent. Then I exported it to PNG. If anyone knows of an easy way to convert the file then please let me know. It would be nice if there was a command-line program I could run to convert a specified color (default white) to transparent. I say this because I can imagine my client going through a dozen iterations of an overlay file that doesn t quite fit. To censor the image I ran the composite command from imagemagick. The command I used was composite -gravity center overlay.png in.jpg out.jpg . If anyone knows a better way of doing this then please let me know. The platform I m using is a ARM926EJ-S rev 5 (v5l) which takes 8 minutes of CPU time to convert a single JPEG at full DSLR resolution (4 megapixel). It also required enabling swap on a SD card to avoid running out of RAM and running systemctl disable tmp.mount to stop using tmpfs for /tmp as the system only has 256M of RAM.
Related posts:
  1. images for a web site When I first started putting pictures on my web site...
  2. Other Reasons for not Censoring the Net Currently there is a debate about censoring the Internet in...
  3. Sociological Images 2012 In 2011 I wrote a post that was inspired by...

Utkarsh Gupta: FOSS Activites in March 2021

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

Debian
This was my 27th month of active contributing to Debian. I became a DM in late March 2019 and a DD on Christmas 19! \o/ This month was a bit exhausting; lots of moving parts. With the financial year ending, it was even more crazy, with me running around to banks, CA, et al.
Anyway, with now working on Ubuntu full-time, I did little of Debian this month. Here are the following things I worked on:

Uploads and bug fixes:

Other $things:
  • Attended the Debian LTS team meeting.
  • Mentoring for newcomers.
  • Moderation of -project mailing list.

Debian (E)LTS
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. And Debian Extended LTS (ELTS) is its sister project, extending support to the Jessie release (+2 years after LTS support). This was my eighteenth month as a Debian LTS and ninth month as a Debian ELTS paid contributor.
I was assigned 60.00 hours for LTS and 39.00 hours for ELTS and worked on the following things:

LTS CVE Fixes and Announcements:

ELTS CVE Fixes and Announcements:

Other (E)LTS Work:
  • Front-desk duty from 01-03 until 07-03 for ELTS and then from 29-03 until 04-04 for both LTS and ELTS.
  • Triaged wpa, python-aiohttp, spip, wpa, qemu, tomcat7, tomcat8, grub2, mupdf, openssh, tiff, spice, pillow, xmlgraphics-commons, batik, libupnp, ca-certificates, salt, squid3, shibboleth-sp2, courier-authlib, cloud-init, spamassassin, openssl, libcaca, and openjpeg2.
  • Marked CVE-2021-21330/python-aiohttp as not-affected for stretch.
  • Marked CVE-2021-20233, CVE-2021-20225, CVE-2020-27779, CVE-2020-27778, CVE-2020-27749, CVE-2020-27748, CVE-2020-25647, CVE-2020-25632, CVE-2020-25631, and CVE-2020-14372, affecting grub2, as ignored for stretch and jessie.
  • Marked CVE-2020-27842/openjpeg2 as no-dsa for jessie.
  • Marked CVE-2020-27843/openjpeg2 as no-dsa for jessie.
  • Marked CVE-2021-28041/openssh as not-affect for jessie.
  • Marked CVE-2020-3552 3,4 /tiff as no-dsa for jessie.
  • Marked CVE-2021-20201/spice as no-dsa for jessie.
  • Marked CVE-2020-11988/xmlgraphics-commons as postponed for jessie.
  • Marked CVE-2020-11987/batik as postponed for jessie.
  • Marked CVE-2020-12695/libupnp as no-dsa for stretch.
  • Marked CVE-2021-25122/tomcat7 as not-affected for stretch.
  • Marked CVE-2021-25329/tomcat7 as ignored for stretch.
  • Marked CVE-2021-28116/squid3 as postponed for stretch and jessie.
  • Marked CVE-2021-3449/openssl as not-affected for stretch.
  • Document extra notes for grub2 for LTS and co-ordinate with the sec-team.
  • Document extra notes for pillow about piled-up issues in jessie.
  • Issued DLA-2593-1 for ca-certificates on Microsoft s request; co-ordinating w/ them.
  • Co-ordinating w/ maintainer of courier-authlib for stretch and jessie update.
  • Fixing build failures of ELTS security tracker and re-ordering entries in data/CVE-EXTENDED-LTS/list file.
  • Answer queries of dupondje and mikap about openssl on IRC; and it being not-affected for stretch.
  • Help review the status of CVE-2021-3121/golang-github-gogo-protobuf-dev for Ola.
  • Co-ordinating w/ Noah for cloud-init and setuptools.
  • Auto EOL ed mongodb, linux, guacamole-client, node-xmlhttprequest, newlib, neutron, privoxy, glpi, and zabbix for jessie.
  • Attended monthly meeting for Debian LTS.
  • Answered questions (& discussions) on IRC (#debian-lts and #debian-elts).
  • General and other discussions on LTS private and public mailing list.
Until next time.
:wq for today.

Paul Wise: FLOSS Activities March 2021

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

Changes

Issues

Debugging

Review

Administration
  • Debian packages: migrate flower git repo from alioth-archive to salsa
  • Debian: restart bacula-director after PostgreSQL restart
  • Debian wiki: block spammer, clean up spam, approve accounts

Communication

Sponsors The librecaptcha/libpst/flower/marco work was sponsored by my employers. All other work was done on a volunteer basis.

Dirk Eddelbuettel: Rcpp now used by 2250 CRAN packages!

2250 Rcpp packages As of today, Rcpp stands at 2255 reverse-dependencies on CRAN. The graph on the left depicts the growth of Rcpp usage (as measured by Depends, Imports and LinkingTo, but excluding Suggests) over time. We actually crossed 2250 once a week ago, but what CRAN giveth, CRAN also taketh and counts can fluctuate. It had dropped back to 2248 a few days later. Rcpp was first released in November 2008. It probably cleared 50 packages around three years later in December 2011, 100 packages in January 2013, 200 packages in April 2014, and 300 packages in November 2014. It passed 400 packages in June 2015 (when I tweeted about it), 500 packages in late October 2015, 600 packages in March 2016, 700 packages last July 2016, 800 packages last October 2016, 900 packages early January 2017, 1000 packages in April 2017, 1250 packages in November 2017, 1500 packages in November 2018, 1750 packages in August 2019, and then the big 2000 packages (as well as one in eight) in July 2020. The chart extends to the very beginning via manually compiled data from CRANberries and checked with crandb. The next part uses manually saved entries. The core (and by far largest) part of the data set was generated semi-automatically via a short script appending updates to a small file-based backend. A list of packages using Rcpp is available too. Also displayed in the graph is the relative proportion of CRAN packages using Rcpp. The four per-cent hurdle was cleared just before useR! 2014 where I showed a similar graph (as two distinct graphs) in my invited keynote. We passed five percent in December of 2014, six percent July of 2015, seven percent just before Christmas 2015, eight percent in the summer of 2016, nine percent mid-December 2016, cracked ten percent in the summer of 2017 and eleven percent in 2018. Last year, along with passing 2000 package, we also passed 12.5 percent so one more than in every eight CRAN packages depends on Rcpp. Stunning. There is more detail in the chart: how CRAN seems to be pushing back more and removing more aggressively (which my CRANberries tracks but not in as much detail as it could), how the growth of Rcpp seems to be slowing somewhat outright and even more so as a proportion of CRAN as one would expect a growth curve to. 2250 user packages, and the continued growth, is truly mind-boggling. We can use the progression of CRAN itself compiled by Henrik in a series of posts and emails to the main development mailing list. Not that long ago CRAN itself did have only 1000 packages, then 5000, 10000, and here we are at over 17300 with Rcpp now at nearly 13.0% and still growing. Amazeballs. The Rcpp team, recently grown in strength with the addition of I aki, continues to aim for keeping Rcpp as performant and reliable as it has been. A really big shoutout and Thank You! to all users and contributors of Rcpp for help, suggestions, bug reports, documentation or, of course, code. 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.

31 March 2021

Mike Hommey: Announcing git-cinnabar 0.5.7

Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git. Get it on github. These release notes are also available on the git-cinnabar wiki. What s new since 0.5.6?

Gunnar Wolf: And what does the FSF have, anyway?

Following up with my previous post, it seems the FSF s board is taking good care of undermining the FSF itself. Over few days, it has: Now Many people have pointed to the fact that the FSF has been a sort of a moral leader pushing free software awareness But if they lose their moral statre, what s in there? What power do they bear? Why do we care? And the answer, at least one of them, is simple and strong. The General Public License (GPL), both in its v2 and v3 revisions, read: 
Each version is given a distinguishing version number.  If the
Program specifies that a certain numbered version of the GNU General
Public License "or any later version" applies to it, you have the
option of following the terms and conditions either of that numbered
version or of any later version published by the Free Software
Foundation.  If the Program does not specify a version number of the
GNU General Public License, you may choose any version ever published
by the Free Software Foundation.
Years ago there was a huge argument on why Linux was licensed as GPLv2 only, without the option to relicense under GPLv3. Of course, by then, Linux had had thousands of authors, and they would all have to agree to change license so it would have been impossible even if it were wanted. But yes, some people decried several terms of GPLv3 not being aligned with their views of freedom. Well, so if the FSF board manages to have it their way, and get everybody mark them as irrelevant, they will still be the stewards of the GPL. Thousands of projects are licensed under the GPL v2 or v3 or later . Will we continue to trust the FSF s stewardship, if it just becomes a board of big egos, with no respect of what happens in the free software ecosystem? My suggestion is, for all project copyright holders that are in a position to do so, to drop the or-later terms and stick to a single, known GPL version.

Chris Lamb: Free software activities in March 2021

Here is my monthly update covering what I have been doing in the free software world during March 2021 (previous month): Reproducible Builds One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. However, whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into ostensibly secure software during the various compilation and distribution processes. The motivation behind the Reproducible Builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised. The project is proud to be a member project of the Software Freedom Conservancy. Conservancy acts as a corporate umbrella allowing projects to operate as non-profit initiatives without managing their own corporate structure. If you like the work of the Conservancy or the Reproducible Builds project, please consider becoming an official supporter. This month, I:
I also made the following changes to diffoscope, including uploading versions 169, 170 and 171 to Debian: Debian Uploads
Debian LTS This month I worked 18 hours on Debian Long Term Support (LTS) and 12 hours on its sister Extended LTS project. You can find out more about the Debian LTS via the following video:

Raphaël Hertzog: Challenging times for Freexian (2/4)

Note: This is the continuation of part 1 where I presented Freexian and its purpose. Going forward: growing Freexian Part 1: From Debian LTS to Debian for the Enterprise Freexian s Debian LTS service has so far been entirely successful, with a steady growth over the years. Thanks to this, and even if there are always new challenges, it is fair to say that the Debian LTS team has met its goal in the last few years. While this started from the desire to make LTS a reality, many sponsors are only looking for a way to give back to Debian through their company, and to make sure that Debian fits their needs. But if you look at the bigger picture outside of this small LTS area, you will easily find many issues that need to be addressed if we want Debian to meet the needs of corporate users. Those issues can have widely different types and complexity. They can be as simple as missing the latest upstream version for an important package because the maintainer disappeared and nobody noticed before it was too late (i.e. the release was frozen); or a somewhat basic piece of software not yet packaged at all; or a release critical bug that was left unattended. On the other end of the spectrum, some corporate requirements will prove tougher to solve, for instance for large software suites that are complex to package, or could potentially have an impact elsewhere in Debian. Bringing those facts together, we would like to have Freexian s Debian LTS/ELTS offering evolve into a more general Debian Software Assurance offering, where you commit to a yearly budget for Debian sponsorship in the larger sense. That budget would fund different projects and the allocation between those projects would vary over time depending on the desires and needs of the sponsors/customers: This major shift in our offering would also be an ideal opportunity to build a professional, free-software based infrastructure aimed at sustaining this business, making it easier to administer the various aspects of this work, and easily allowing many more sponsors to join (individuals included!). On a more pragmatic/operational note, this shift will bring a lot of challenges to the table, and those can hardly be handled with the current resources of Freexian: if we hope to properly implement this new strategy, we ll need some additional help. This article is to be continued in an upcoming post. Stay tuned!

Ben Hutchings: Debian LTS work, March 2021

In March I was assigned 16 hours of work by Freexian's Debian LTS initiative and carried over 12.25 hours from earlier months. I worked 25.75 hours and will carry over the remainder. I eventually settled on an apparently working patch series to fix the futex security issue in Linux 4.9. This went through upstream stable review and was included in 4.9.260. I applied the same fixes to the Debian package, along with some other security and regression fixes. I uploaded it and issued DLA-2586-1. Unfortunately the futex changes for Linux 4.9 still caused a regression (kernel WARNING in some circumstances). I worked to backport and test a further set of fixes that had already been applied to later kernel branches. These were included in upstream stable release 4.9.264 and should go into an updated Debian package soon. Following the Debian 10.9 point release, I also backported the updated Linux 4.19 package. I uploaded it and issued DLA-2610-1.

Bastian Venthur: Writing Makefiles for Python Projects

I'm a big fan of Makefiles. Almost all my side projects are using them, and I've been advocating their usage at work too. Makefiles give your contributors an entry point on how to do certain things like, building, testing, deploying. And if done correctly, they can massively simplify your CI/CD pipeline scripts as they can often just stupidly call the respective make targets. Most importantly, they are a very convenient shortcut for you as a developer as well. For Python projects, where I'm almost always using virtual environments, I've been using two different strategies for Makefiles:
  1. assuming that make is executed inside the virtual environment
  2. wrapping all virtual environment calls inside make
Both strategies have their pros and cons. Assuming make is executed inside the venv Let's have a look at a very simple Makefile that allows for building, testing and releasing a Python project: 
all: lint test
.PHONY: test
test:
    pytest
.PHONY: lint
lint:
    flake8
.PHONY: release
release:
    python3 setup.py sdist bdist_wheel upload
clean:
    find . -type f -name *.pyc -delete
    find . -type d -name __pycache__ -delete
This is straightforward and a potential contributor immediately knows the entry points to your project. Assuming there is a venv installed already, you have to activate it first and run the make commands afterwards: 
$ . venv/bin/activate
$ make test
The downside is of course, that you have to activate the venv for every new shell. Which can get a bit annoying when you spawn a new terminal in tmux or put vim into the background to run make. Activating the venv inside make will not work, as each recipe runs in its own shell, moreover each command in each recipe runs in its own shell too. There are workarounds for the latter, i.e. using the .ONESHELL flag, but that does not solve the issue of a new shell in each recipe. Wrapping the venv calls inside make The second approach mitigates for the issue of activating the venv altogether. I've borrowed this idea mostly from makefile.venv and simplified it a lot for my needs. 
# system python interpreter. used only to create virtual environment
PY = python3
VENV = venv
BIN=$(VENV)/bin
# make it work on windows too
ifeq ($(OS), Windows_NT)
    BIN=$(VENV)/Scripts
    PY=python
endif
all: lint test
$(VENV): requirements.txt requirements-dev.txt setup.py
    $(PY) -m venv $(VENV)
    $(BIN)/pip install --upgrade -r requirements.txt
    $(BIN)/pip install --upgrade -r requirements-dev.txt
    $(BIN)/pip install -e .
    touch $(VENV)
.PHONY: test
test: $(VENV)
    $(BIN)/pytest
.PHONY: lint
lint: $(VENV)
    $(BIN)/flake8
.PHONY: release
release: $(VENV)
    $(BIN)/python setup.py sdist bdist_wheel upload
clean:
    rm -rf $(VENV)
    find . -type f -name *.pyc -delete
    find . -type d -name __pycache__ -delete
The equivalent Makefile now looks immediately more complicated. So let's break it down. Instead of calling just calling pytest, flake8 and python assuming the venv is already activated or all dependencies are installed on the system directly, we explicitly call the ones from the venv by prefixing the command with the path to the venv's bin directory. To ensure the venv exists, each of the recipes is depending on the $(VENV) target, which ensures we always have an up-to-date venv installed. This works, because the . venv/bin/activate-script basically just does the same: it puts the venv before anything else in your PATH, therefore each call to python, etc. will find the one installed in the venv first. While the Makefile is a bit more complicated, we now can just call 
$ make test
and don't deal with venvs directly any more (well, for those simple cases at least...). If you don't need to support Windows, you can remove the appropriate block and the Makefile looks relatively tame, even for people that don't use make very often. Which one is better? I think the second approach is more convenient. I've used the first approach happily for years and only learned quite recently about the second one. I haven't really noticed any downsides yet, but I do realize that almost all Python projects with Makefiles I've checked out, seem to prefer the first approach. I wonder why that is?

Timo Jyrinki: MotionPhoto / MicroVideo File Formats on Pixel Phones

Google Pixel phones support what they call Motion Photo which is essentially a photo with a short video clip attached to it. They are quite nice since they bring the moment alive, especially as the capturing of the video starts a small moment before the shutter button is pressed. For most viewing programs they simply show as static JPEG photos, but there is more to the files.
I d really love proper Shotwell support for these file formats, so I posted a longish explanation with many of the details in this blog post to a ticket there too. Examples of the newer format are linked there too.
Info posted to Shotwell ticket

There are actually two different formats, an old one that is already obsolete, and a newer current format. The older ones are those that your Pixel phone recorded as MVIMG_[datetime].jpg", and they have the following meta-data:
Xmp.GCamera.MicroVideo                       XmpText     1  1
Xmp.GCamera.MicroVideoVersion                XmpText     1  1
Xmp.GCamera.MicroVideoOffset                 XmpText     7  4022143
Xmp.GCamera.MicroVideoPresentationTimestampUs XmpText     7  1331607
The offset is actually from the end of the file, so one needs to calculate accordingly. But it is exact otherwise, so one simply extract a file with that meta-data information:
#!/bin/bash
#
# Extracts the microvideo from a MVIMG_*.jpg file

# The offset is from the ending of the file, so calculate accordingly
offset=$(exiv2 -p X "$1"   grep MicroVideoOffset   sed 's/.*\"\(.*\)"/\1/')
filesize=$(du --apparent-size --block=1 "$1"   sed 's/^\([0-9]*\).*/\1/')
extractposition=$(expr $filesize - $offset)
echo offset: $offset
echo filesize: $filesize
echo extractposition=$extractposition
dd if="$1" skip=1 bs=$extractposition of="$(basename -s .jpg $1).mp4"
The newer format is recorded in filenames called PXL_[datetime].MP.jpg , and they have a _lot_ of additional metadata:
Xmp.GCamera.MotionPhoto                      XmpText     1  1
Xmp.GCamera.MotionPhotoVersion               XmpText     1  1
Xmp.GCamera.MotionPhotoPresentationTimestampUs XmpText     6  233320
Xmp.xmpNote.HasExtendedXMP                   XmpText    32  E1F7505D2DD64EA6948D2047449F0FFA
Xmp.Container.Directory                      XmpText     0  type="Seq"
Xmp.Container.Directory[1]                   XmpText     0  type="Struct"
Xmp.Container.Directory[1]/Container:Item    XmpText     0  type="Struct"
Xmp.Container.Directory[1]/Container:Item/Item:Mime XmpText    10  image/jpeg
Xmp.Container.Directory[1]/Container:Item/Item:Semantic XmpText     7  Primary
Xmp.Container.Directory[1]/Container:Item/Item:Length XmpText     1  0
Xmp.Container.Directory[1]/Container:Item/Item:Padding XmpText     1  0
Xmp.Container.Directory[2]                   XmpText     0  type="Struct"
Xmp.Container.Directory[2]/Container:Item    XmpText     0  type="Struct"
Xmp.Container.Directory[2]/Container:Item/Item:Mime XmpText     9  video/mp4
Xmp.Container.Directory[2]/Container:Item/Item:Semantic XmpText    11  MotionPhoto
Xmp.Container.Directory[2]/Container:Item/Item:Length XmpText     7  1679555
Xmp.Container.Directory[2]/Container:Item/Item:Padding XmpText     1  0
Sounds like fun and lots of information. However I didn t see why the length in first item is 0 and I didn t see how to use the latter Length info. But I can use the mp4 headers to extract it:
#!/bin/bash
#
# Extracts the motion part of a MotionPhoto file PXL_*.MP.mp4

extractposition=$(grep --binary --byte-offset --only-matching --text \
-P "\x00\x00\x00\x18\x66\x74\x79\x70\x6d\x70\x34\x32" $1   sed 's/^\([0-9]*\).*/\1/')

dd if="$1" skip=1 bs=$extractposition of="$(basename -s .jpg $1).mp4"
UPDATE: I wrote most of this blog post earlier. When now actually getting to publishing it a week later, I see the obvious ie the Length is again simply the offset from the end of the file so one could do the same less brute force approach as for MVIMG. I ll leave the above as is however for the of binary grepping.(cross-posted to my other blog)

Russ Allbery: Review: Paladin's Strength

Review: Paladin's Strength, by T. Kingfisher
Series: The Saint of Steel #2
Publisher: Red Wombat Studio
Copyright: 2021
ASIN: B08WWKXXVY
Format: Kindle
Pages: 474
Paladin's Strength is a sequel of sorts to Paladin's Grace, but it has different protagonists. It picks up a subplot from that novel with another former follower of the Saint of Steel. You can safely read the books in any order; there are some minor spoilers for the Paladin's Grace subplot in this book, but nothing that would matter for the enjoyment of the story. Istvhan and his fellow brother Galen are acting as the head of a mercenary band, which has hired on to escort Master Distiller Brant and his collection of Emperor Oak barrels. In truth, they have another mission from the Temple of the White Rat: to track down a disturbing monster that leaves a trail of beheaded bodies. Clara is a lay sister of St. Ursa, a convent that was raided by slavers who hauled away the nuns. She was left for dead in Arral territory when she fell sick, and was taken as a house slave after they nursed her back to life. The story opens with her holding a sword in front of Istvhan's tent, part of the fallout of Istvhan killing a young Arral in self-defense. The politics of that fallout are not at all what Istvhan expects. They end with Clara traveling with Istvhan's company, at least for a while. Both Istvhan and Clara are telling the truth: Istvhan is escorting a merchant, and Clara is hoping to rescue her sisters. Both of them are also hiding a great deal. Istvhan's quiet investigation of the trail of a monster is easy enough to reveal once he knows Clara well enough. That he's a berserker who no longer has a god in control of his battle rage is another matter; the reader knows that, and of course so does Galen, but Istvhan has no intention of telling anyone else. Clara has her own secrets about herself and the sisters of St. Ursa, ones that neither the reader nor Istvhan knows. This is a T. Kingfisher novel about paladins, so of course it's also a romance. If you've read Kingfisher's other books, you know she writes slow burn romances, but Paladin's Strength is next level. Istvhan and Clara have good reasons to not want to get involved and to doubt the other person's attraction or willingness, but this goes far beyond the obvious to become faintly absurd. If you like the sort of romance where both leads generate endless reasons to not pursue the relationship (some legitimate, some not) while steadfastly refusing to talk to each other about them and endlessly rehashing hints and interpretations, you're in for a treat. For me, it was too much and crossed over into irritation. By the two-thirds point, Kingfisher was gleefully throwing obstacles in their way to drag out the suspense, and I just wanted everyone to shut up about having sex and get on with the rest of the story. That's unfortunate because I really liked Clara. She isn't the same type as Grace, Halla from Swordheart, or even Slate from Clockwork Boys and The Wonder Engine, the other novels set in this universe. She's self-contained, physically intimidating, cautious, deliberate, and very good at keeping her own counsel. I won't spoil her secret, since it's fun to work it out at the start of the book, but it's a lovely bit of characterization and world-building that Kingfisher handles with a thoughtful eye for its ramifications and effect on Clara's psychology. I would happily read more books about Clara. I liked Istvhan well enough when he was doing anything other than mooning over Clara. As with all of Kingfisher's paladins, he's not a very subtle person, but he's a good straight man for Clara's quiet bemusement. He fills the paladin slot in this story, which is all he needs to do. There's enough else going on with Clara and with the plot two separate major plotlines, plus a few subplots that Paladin's Strength can use a protagonist who heads straight forward and hits things until they fall down. The mooning, though... this is going to be a matter of personal taste. I think the intent was to contrast Istvhan's rather straightforward lustful appreciation with Clara's nuanced and trauma-laced reservations, and to play Istvhan's reactions in part for humor. I'm sure it works for some people, but I found Istvhan juvenile and puerile (albeit, to be clear, in a respectful and entirely consensual way), which didn't help me invest in a romance plot that I already thought dragged on too long. Thankfully the characters finally get past this in time for a dramatic and satisfying conclusion to the plot. The joy of Paladin's Grace (and Swordheart for that matter) was the character dynamics and quirky female lead, which made the romance work even when Stephen was being dense. The joy of Paladin's Strength for me was primarily Clara's matter-of-fact calm bemusement and secondarily the plot and the world-building. (Kingfisher's gnoles continue to be the best thing about this setting.) None of that helps the romance as much, and the slow burn was far, far too slow for me, which lowers this one a notch. Still, this was fun, and I'll keep reading books about the Temple of the White Rat and their various friends and encounters for as long as Kingfisher keeps writing them. Rating: 7 out of 10

30 March 2021

Dirk Eddelbuettel: x13binary 1.1.39-3 on CRAN: (Imperfect) Package Updates

A new release 1.1.39-3 of x13binary, of the X-13ARIMA-SEATS program by the US Census Bureau (with upstream release 1.1.39) is now on CRAN. The x13binary package takes the pain out of installing X-13ARIMA-SEATS by making it a fully resolved CRAN dependency. For example, when installing the excellent seasonal package by Christoph, then X-13ARIMA-SEATS will get pulled in via the x13binary package and things just work. Just depend on x13binary and on all major OSs supported by R you should have an X-13ARIMA-SEATS binary installed which will be called seamlessly by the higher-level packages such as seasonal or gunsales. With this the full power of the what is likely the world s most sophisticated deseasonalization and forecasting package is now at your fingertips and the R prompt, just like any other of the 17350+ CRAN packages. You can read more about this (and the seasonal package) in the Journal of Statistical Software paper by Christoph and myself. This release was needed because the recent M1mac build was reporting leftover detritus in the temporary directory, which we addressed with an explicit removal at end. We also addressed another CRAN Policy change since the last release, namely a conversion of the configure script from bash to sh. Now, sadly, that second aspect blew up on Solaris, and the detritus issue appears to be persist. By now Christoph and a colleague have installed R(-devel) on such an M1 machine, but still cannot reproduce. We will reach out to CRAN to learn more. A follow-up release 1.1.39-4 is likely. The good news is that the standard macOS binary works on M1 as do other binaries thanks to the translation layer. We do however lack a genuine binary for Solaris so if any of the esteemed readers of this post happens to have access to R on Solaris along with a basic Fortran compiler, we would love to hear from you. Building X-13ARIMA-SEATS from source on Solaris should be straightforward, it is on the other OSs. Courtesy of my CRANberries, there is also a diffstat report for this release showing changes to the previous release. 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.

Raphaël Hertzog: Challenging times for Freexian (1/4)

TLDR: Freexian s success means that we have resources to invest into Debian projects. Plainly offering money has not worked so far, so I am looking to hire a project manager whose work would be to help spend that money in useful ways. At the same time, Freexian needs to adapt to cope with the growth: with new employees, with new infrastructure and a new offering. I want to give an idea of where we are headed, to try to inspire persons that share our values and our desire to improve Debian. Read on if you are interested. Note: The original text has been split into 4 blog posts that will be published over a few days. Introduction
Freexian is an IT service company specialized in Debian. We provide technical support by email on Debian, we create and maintain Debian packages requested by our customers, we also help organizations run an entire Debian derivative (Kali Linux being the most notable one).
On top of this, it runs the commercial part of the Debian LTS service : Freexian invoices many sponsors that need long term support, and uses the money to pay Debian contributors (about 12 currently) to make sure that Debian releases are supported for 5 years instead of 3. With the Extended LTS service, we push that further to 7 years, however only for a smaller subset of packages and in a repository that is hosted outside of debian.org. Freexian s purpose When I created Freexian, it was out of a desire to be paid to work on Debian, and to be able to contribute during work time to the project that was so important to me. That goal has been met a long time ago. But ultimately what I strive to achieve for Debian is not entirely aligned with the work that Freexian s customers are requesting. That s why, in the long term projects of Freexian, I always kept find a business model that can fund the Debian projects that I would like to do , as well as if that model works for me, build something so that other can benefit from it too . The first occasion to experiment something appeared when Debian discussed Long Term Support and when I stepped up to setup a commercial offer to pay Debian contributors. Step 1: Paying Debian contributors for LTS work When we started the Debian LTS service, I voluntarily opted to use an hourly rate that was rather high so that any Debian developer regardless of their geographical location, could participate and not earn (much) less than what they would have from working on other tasks. This choice did imply paying a very high rate for some countries, but I didn t see that as a problem, quite the contrary: if a Debian developer can earn enough money to cover their cost of living with 15h of Debian LTS, and then spend the rest of their month contributing on Debian, all the better! I m not sure if anyone made this choice, but that was a dream of my younger self From a personal standpoint, the launch of Debian LTS has meant less free time, more administrative work, new duties to coordinate a team of paid contributors, more communication with many Debian-using companies, and many new opportunities too! This ultimately resulted in the launch of Extended LTS and PHP LTS, both of which have been rather successful so far. Step 2: Funding Debian projects With the growth of the Debian LTS service, and given that we have reached the required funding level, we decided to put a small share of the revenues aside and use that to fund useful Debian projects, typically in areas that were affected by our Debian LTS work. This effort was fully formalized in the project-funding git repository. We announced this process in November 2020, and we have kept mentioning it in our monthly LTS reports ever since, but so far only a single project has benefited from this. This is really the dream offer that I wish had existed when I was younger and was still struggling to get enough customers: hence I don t really understand this lack of interest. You can find some discussions over the reasons why this offer has not (yet) found its target audience in this debian-vote thread. I was hoping that spending money would be easy, but I now realize I was wrong! I m positive that I could find dozens of useful projects to fund, but I just don t have the time for this extra effort on top of my regular Freexian duties. I still really want to put this money to good use, which is why I m looking into some solutions. This article is to be continued in another upcoming post, stay tuned!

Emmanuel Kasper: Playing with cri-o, a container runtime built for Kubernetes

Kubernetes is moving aways from docker to alternative container engines presenting a smaller core having just the functionality needed. The two most populars alternatives are:These alternatives are meant to be used programatically via a unix domain socket, and therefore have a limited command line interface.Let's play around in a VM.Install a throwaway VM with Vagrant
apt install vagrant vagrant-libvirt
vagrant init debian/testing64
Start the VM, install dependencies
vagrant up
vagrant ssh
sudo apt update
sudo apt install --yes curl gnupg jq
Install cri-o the container engine
sudo bash
export OS=Debian_Testing VERSION=1.20

echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/libcontainers.list
echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/cri-o:$VERSION.list
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key   apt-key add -
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key   apt-key add -
apt install cri-o cri-o-runc containernetworking-plugins conntrack
Verify it is running properly
systemctl restart cri-o
systemctl status cri-o
...
Started Container Runtime Interface for OCI (CRI-O).
Say hello to cri-o via its unix domain socket
curl --silent  --unix-socket /var/run/crio/crio.sock http://localhost/info   jq 
 
  "storage_driver": "overlay",
  "storage_root": "/var/lib/containers/storage",
  "cgroup_driver": "systemd",
  "default_id_mappings":  
    "uids": [
       
        "container_id": 0,
        "host_id": 0,
        "size": 4294967295
       
    ],
    "gids": [
       
        "container_id": 0,
        "host_id": 0,
        "size": 4294967295
       
    ]
Install crictl, a Kubernetes debugging tool for containers
wget --directory-prefix=/tmp https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.20.0/crictl-v1.20.0-linux-amd64.tar.gz
tar -xaf /tmp/crictl-v1.20.0-linux-amd64.tar.gz -C /usr/local/sbin/
chmod +x /usr/local/sbin/crictl

crictl info
 
  "status":  
    "conditions": [
       
        "type": "RuntimeReady",
        "status": true,
        "reason": "",
        "message": ""
       ,
       
        "type": "NetworkReady",
        "status": true,
        "reason": "",
        "message": ""
       
    ]

From there on you can create a container following the examples in https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md

Molly de Blanc: Helping

How can you help free software? Aside from donating to the excellent free software nonprofits out there, and contributing to a project by building software or other resources, there are things you can do to help the free software cause. The two biggest things I think are providing mentorship and gently normalizing free software.

Providing Mentorship Allison Randal introduced me to the idea that mentorship doesn t have to be an ongoing process. This is to say, you don t have to sign up to be someone s best friend and advisor for life (though you certainly can). Providing short term, project or skill based, or one off mentorship is useful for building community because it makes people feel welcome and cared for and helps build skills that benefit free software. I do a lot of proofreading and editing of people s writing especially people with minimal writing experience and/or non-native English speakers who are writing important documents in English. If the person is interested, I try to talk to them about their writing and why I m making these particular suggestions. I hope this helps them with their writing in the future. Other examples are working on a particular project or skill, this can be helping them develop a particular skill (e.g. git outside of the command line), or giving advice on a project with a level of specificity and detail you re both comfortable with. These can, again, be one off things or things that require minimal effort/occasional conversation. I have some friends who I consider my Debian mentors who just answer functional questions whenever I have trouble doing something. I also love love love talking with people about their free software trajectories, their goals and desires and dreams for their involvement in free software, whether that s finding a place in a community, developing a skill set, or other things about their future (like job hopes, schooling, etc). These conversations have been so helpful for me personally, and I like to think they help others.

Gently Normalizing Free Software I think normalizing free software is very important to its success and adoption. It s not helpful to insist someone who has never done so before to create a Debian boot disk and install it. It is helpful to suggest using Big Blue Button or jitsi. If a friend wants help finding audio editing software, suggest they try audacity. I d go as far as to suggest doing this without explaining that it s free software, and instead focus on why it ll work and that it s available at no cost. If they like it, then it s a great time to talk about rights and freedoms. Of course if they already care about these sorts of things, if you re discussing privacy software, if anti-surveillance is an issue, or any number of other things, software freedom is a great thing to bring up!

Above all, just be nice. Be nice. It s basically the best thing you can do for free software.

29 March 2021

Benjamin Mako Hill: Identifying Underproduced Software

I wrote this blog post with Kaylea Champion and a version of this post was originally posted on the Community Data Science Collective blog. Critical software we all rely on can silently crumble away beneath us. Unfortunately, we often don t find out software infrastructure is in poor condition until it is too late. Over the last year or so, I have been supporting Kaylea Champion on a project my group announced earlier to measure software underproduction a term we use to describe software that is low in quality but high in importance. Underproduction reflects an important type of risk in widely used free/libre open source software (FLOSS) because participants often choose their own projects and tasks. Because FLOSS contributors work as volunteers and choose what they work on, important projects aren t always the ones to which FLOSS developers devote the most attention. Even when developers want to work on important projects, relative neglect among important projects is often difficult for FLOSS contributors to see. Given all this, what can we do to detect problems in FLOSS infrastructure before major failures occur? Kaylea Champion and I recently published a paper laying out our new method for measuring underproduction at the IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER) 2021 that we believe provides one important answer to this question.

A conceptual diagram of underproduction. The x-axis shows relative importance, the y-axis relative quality. The top left area of the graph described by these axes is 'overproduction' -- high quality, low importance. The diagonal is Alignment: quality and importance are approximately the same. The lower right depicts underproduction -- high importance, low quality -- the area of potential risk.Conceptual diagram showing how our conception of underproduction relates to quality and importance of software.
In the paper, we describe a general approach for detecting underproduced software infrastructure that consists of five steps: (1) identifying a body of digital infrastructure (like a code repository); (2) identifying a measure of quality (like the time to takes to fix bugs); (3) identifying a measure of importance (like install base); (4) specifying a hypothesized relationship linking quality and importance if quality and importance are in perfect alignment; and (5) quantifying deviation from this theoretical baseline to find relative underproduction. To show how our method works in practice, we applied the technique to an important collection of FLOSS infrastructure: 21,902 packages in the Debian GNU/Linux distribution. Although there are many ways to measure quality, we used a measure of how quickly Debian maintainers have historically dealt with 461,656 bugs that have been filed over the last three decades. To measure importance, we used data from Debian s Popularity Contest opt-in survey. After some statistical machinations that are documented in our paper, the result was an estimate of relative underproduction for the 21,902 packages in Debian we looked at. One of our key findings is that underproduction is very common in Debian. By our estimates, at least 4,327 packages in Debian are underproduced. As you can see in the list of the most underproduced packages again, as estimated using just one more measure many of the most at risk packages are associated with the desktop and windowing environments where there are many users but also many extremely tricky integration-related bugs.
This table shows the 30 packages with the most severe underproduction problem in Debian, shown as a series of boxplots.These 30 packages have the highest level of underproduction in Debian according to our analysis.
We hope these results are useful to folks at Debian and the Debian QA team. We also hope that the basic method we ve laid out is something that others will build off in other contexts and apply to other software repositories.
In addition to the paper itself and the video of the conference presentation on Youtube by Kaylea, we ve put a repository with all our code and data in an archival repository Harvard Dataverse and we d love to work with others interested in applying our approach in other software ecosytems.

For more details, check out the full paper which is available as a freely accessible preprint.

This project was supported by the Ford/Sloan Digital Infrastructure Initiative. Wm Salt Hale of the Community Data Science Collective and Debian Developers Paul Wise and Don Armstrong provided valuable assistance in accessing and interpreting Debian bug data. Ren Just generously provided insight and feedback on the manuscript.

Paper Citation: Kaylea Champion and Benjamin Mako Hill. 2021. Underproduction: An Approach for Measuring Risk in Open Source Software. In Proceedings of the IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER 2021). IEEE.

Contact Kaylea Champion (kaylea@uw.edu) with any questions or if you are interested in following up.

Anton Gladky: 2021/03, FLOSS activity

LTS This is my first (beside test time last year) official month of working for LTS. I was assigned 12 hrs and worked all of them. I could relatively easy set up the development environment for Debian Stretch and managed to release several DLAs.

Released DLAs
  1. DLA-2588-1 zeromq3_4.2.1-4+deb9u4
    • CVE-2021-20234
    • CVE-2021-20235
  2. DLA-2594-1 tomcat8_8.5.54-0+deb9u6
    • CVE-2021-24122
    • CVE-2021-25122
    • CVE-2021-25329.
  3. DLA-2605-1 mariadb-10.1_10.1.48-0+deb9u2
    • CVE-2021-27928

CVE-2020-119977 I investigated CVE-2020-119977, which was marked as guacamole-server issue. There were not so much information about this CVE. I was trying to analyze git log and git diff between affected and fixed versions without any visible success. After that I contacted upstream and they were very responsive! This CVE affects guacamole-client only and the ancient versions in the archive is very difficult to fix. So I decided to mark this CVE as NOT-FOR-US.

Repositories with pipelines For most of packages, which I touched due to LTS work the new repositories were created in LTS packages group on salsa.d.o with enabled CI-pipelines. It really helps to test updates though some tests needs to be disabled for passing pipelines.

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

Debian Science Team I have prepared and uploaded following packages, which are maintained under the umbrella of Debian Science Team:
  • gmsh_4.7.1+ds1-5
  • vtk7_7.1.1+dfsg2-10
  • gl2ps_1.4.2+dfsg1-1~bpo10+1
  • vtk9_9.0.1+dfsg1-8~bpo10+2
  • sundials_5.7.0+dfsg-1~exp1

Jamie McClelland: The problem with Richard Stallman is not about free speech

Free speech and censorship are critically important issues. And, using them to defend Richard Stallman's return to the Free Software Foundation (FSF) board is just plain wrong. Richard Stallman resigned from the Board in 2019 after he sent an email in defense of Marvin Minsky (Minsky is accused of raping one of Jeffreys Epstein's victims). Stallman's fateful email, however, is just one piece of the reason for why he should not be on the board. The full story is about his history of abuse toward women and is extensive. On March 21st, 2021, Stallman announced he is back on the board. There are profound reasons why any movement interested in equitable and open participation would want to publicly distance themselves from Stallman. However, the long form defenses of Stallman, including a note from Nadine Strossen, the former executive director of the ACLU, quoted in this defense, persist. Many of the arguments defending Richard Stallman (including the one from Strossen) are grounded in a belief that Stallman is being punished for his unpopular political views, which deserve to be defended on the grounds of freedom of expression. That's wrong. Stallman should be kicked off the board because he has a long history of abusing his position to hit on women, which, when combined with his public opinions on under-age sex and his defense of Minsky, send a strong signal that the FSF does not care about the participation of women. Being on a board of directors is a privilege, not a right. Being removed from a board is not a punnishment. And being criticized and removed from a board because your behavior and public statements are an obstacle to building an inclusive and equitable movement is what every board should strive to do. If we are going to make this an issue about free expression, it should be about all the political expression lost to the free software movement because Stallman's unequal behavior toward women excluded an enormous number of talented individuals.

Russ Allbery: Review: JavaScript: The Definitive Guide

Review: JavaScript: The Definitive Guide, by David Flanagan
Publisher: O'Reilly
Copyright: May 2020
ISBN: 1-4919-5202-4
Format: Trade paperback
Pages: 665
JavaScript: The Definitive Guide has been frequently revised for new versions of JavaScript and therefore has multiple editions. This review is of the seventh edition, first published in May of 2020. Reviews of programming language books are challenging since people learn languages in different ways. A short calibration for my preferences may therefore be useful. I'm both an experienced programmer in multiple languages (C, Perl, Python, and some Java and Ruby professionally; Rust, some PHP, and a few minor languages as a hobby) and I specialized in software theory in college. I therefore like to learn languages comparatively and am comfortable with a lot of up-front syntax and discussion of the unique properties of the language. Introductory programs and practical exercises doesn't matter as much to me; I'm happy to hold the syntax in my head until enough of the language has been introduced to write simple programs. For me, this book is excellent. It's one of the best language manuals that I've read, and that requires some work because JavaScript is a sprawling mess with odd corners, deprecated features, and alternate implementations of core constructs. Flanagan takes the syntax-first, comprehensive approach that I prefer, working methodically through the language (defining your own functions aren't introduced until chapter eight) and discussing all of the quirks as he goes. I felt like I thoroughly understood each portion of the language before moving on. And this book is tight. Some comprehensive language introductions sprawl, but the benefit of seven editions of iteration is a book that has been honed to the most direct and effective explanation of each concept. The section on type conversions with operators, for example, was so good that I was able to immediately understand the unintuitive result of [1] + 2 (the string '12'), despite this being one of the most confusing parts of the language. The sections on JavaScript's prototype-based object type system and its three concurrency models (callbacks, promises, and async/await) were equally good. I came away feeling like I not only understood promises and callback chains but had a feel for how the same code would look when written in the different systems. The drawback in this approach is that if you instead want a language reference that only tells you the parts of the language that you should use and leaves out the legacy weirdness and obscure corners for later (or never), this may not be the book for you. Flanagan labels the obsolete constructs, but he's meticulous about explaining the entire language, including such things as new Boolean or var variables that no one should use. This is what I wanted; I prefer to have a thorough grounding in language primitives so that it doesn't surprise me. But it can be a lot to juggle and prune in your head. JavaScript is a language used in some very different domains. The approach Flanagan takes to that is to spend as long as possible on the core language that's usable both in the browser and on the server (while marking the pieces, such as the module system, that are markedly different between Node and browsers). He then puts two monster chapters at the back of the book that cover JavaScript in web browsers and JavaScript as implemented by Node. Both are more of overviews than orientations, since a comprehensive manual for either is probably as long again as this book, but they were more than adequate for my purposes. (I bogged down a bit in the web browser chapter, in part because I didn't have an immediate use for most of the material.) Flanagan wisely defers to MDN as the reference manual for the JavaScript APIs available in web browsers. I thought Flanagan also hit the right balance of explanation to examples, and did a good job controlling the length of the examples. Most of the code excerpts are short and to the point. The longer ones have a high level of explanatory power per line, since Flanagan uses them to pull together multiple concepts and show how they interact. I was particularly impressed with the example that closes the chapter on web browsers, which uses <canvas>, ImageData, generators, promises, web workers, and other areas of the language Flanagan previously explained to implement a Mandelbrot set explorer in eleven pages of code. I think that's the longest example in the book, and it's well worth it. This sort of introduction will always have limitations. Flanagan provides a brief orientation to the ecosystem surrounding JavaScript in the last chapter, but most JavaScript programmers will be working with packaging tools and frameworks that could themselves be the topic of another book and that he doesn't have room to cover. JavaScript, even more than most languages, is commonly used via a heavy layer of supporting libraries and abstractions, so you will probably not be able to tackle a practical JavaScript project using solely the material in this book. But if you're the sort of programmer who wants to start with a solid syntactical and conceptual understanding of the language core before starting on more applied topics, I've rarely seen it done better than this book. If you want a quick-start guide that will get you writing code quickly and is opinionated about what parts of the language you should learn, this may not be the book for you. But if you're comfortable with comprehensive detail in your language guides, this was exactly what I was looking for. Recommended. Rating: 9 out of 10

Next.

Previous.