Here s my (twenty-third) monthly but brief update about the activities I ve done in the F/L/OSS world.
Debian
This was my 32nd month of actively contributing to Debian.
I became a DM in late March 2019 and a DD on Christmas 19! \o/
Tough month but I mostly spent on it churning through the immense backlog. But that
somewhat backfired and I have even more backlog than ever. :D
Anyway, I did the following stuff in Debian:
Ubuntu
This was my 7th month of actively contributing to Ubuntu.
Now that I ve joined Canonical to work on Ubuntu full-time, there s a bunch of things I do! \o/
I mostly worked on different things, I guess. But mostly on packaging keylime and some Google Agents upload(s) and SRU(s). Also did a lot of reviewing, et al.
I was too lazy to maintain a list of things I worked on so there s no concrete list atm. Maybe I ll get back to this section later or will start to list stuff from next month onward, as I ve been doing before. :D
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 twenty-third month as a Debian LTS and eleventh month as a Debian ELTS paid contributor.
I was assigned 23.75 hours for LTS and 40.00 hours for ELTS and worked on the following things:
(however, I only worked for 23.75h on ELTS work, thereby, carrying the rest to next month)
Noticed that there s a fallout of CVE-2021-3185, where an update was issued for gst-plugins-bad1.0, however, not for gst-plugins-bad0.10.
Thanks to Sylvain s script, this came up and I prepped an update for that.
Started to work on libjdom1-java s regression.
Other (E)LTS Work:
Front-desk duty from 26-07 until 01-08 and from 30-08 until 05-09 for both LTS and ELTS.
Mark CVE-2021-39240/haproxy as not-affected for stretch and jessie.
Mark CVE-2021-39241/haproxy as not-affected for stretch and jessie.
Mark CVE-2021-39242/haproxy as not-affected for stretch and jessie.
Mark CVE-2021-33582/cyrus-imapd as no-dsa for stretch.
Mark CVE-2020-18771/exiv2 as no-dsa for exiv2 for stretch.
Mark CVE-2020-18899/exiv2 as no-dsa for exiv2 for stretch.
Mark CVE-2021-38171/ffmpeg as postponed for stretch.
Mark CVE-2021-40330/git as no-dsa for stretch and jessie.
Mark CVE-2020-19481/gpac as ignored for stretch.
Mark CVE-2021-40491/inetutils as no-dsa for stretch.
Mark CVE-2021-36370/mc as no-dsa for stretch and jessie.
Mark CVE-2021-35368/modsecurity-crs as no-dsa for stretch.
Mark CVE-2021-23434/node-object-path as end-of-life for stretch.
Mark CVE-2021-32610/php-pear as no-dsa for stretch.
Mark CVE-2017-9525/systemd-cron as no-dsa for stretch.
Mark CVE-2021-37701/node-tar as end-of-life for stretch.
Mark CVE-2021-37712/node-tar as end-of-life in stretch.
Mark CVE-2021-3750/qemu as postponsed for jessie.
Mark CVE-2021-27511/prototypejs as postponsed for jessie.
Mark CVE-2021-23437/pillow as postponed for stretch and jessie.
Auto EOL ed gpac, cacti, openscad, cgal, cyrus-imapd-2.4, libsolv, mosquitto, atomicparsley, gtkpod, node-tar, libapache2-mod-auth-openidc, neutron, inetutils and linux for jessie.
Drop cpio from ela-needed; open issues don t warrant an ELA.
Attended monthly Debian LTS meeting.
Answered questions (& discussions) on IRC (#debian-lts and #debian-elts).
kstart provides the programs k5start and krenew, which are similar to the
Kerberos kinit program with some extra support for running programs with
separate credentials and running as a daemon.
This is the first full release in nearly six years. The major change is
new support for the Linux kafs module, which is a native Linux
implementation of the AFS protocol that David Howells and others have been
working on for years. It has an entirely different way of thinking about
tokens and credential isolation built on Linux keyrings rather than the
AFS token concept (which sometimes uses keyrings, but in a different way,
and sometimes uses other hacks).
k5start and krenew, when run with the -t option to get AFS tokens, would
fail if AFS was not available. That meant -t would fail with kafs even if
the AKLOG environment variable were set properly to aklog-kafs. This
release fixes that. The programs also optionally link with libkeyutils
and use it when used to run a command to isolate the AFS credentials from
the calling process. This is done by creating a new session keyring and
linking it to the user keyring before running the aklog program.
Thanks to Bill MacAllister, David Howells, and Jeffrey Altman for the help
with this feature. I'm not sure that I have it right, so please let me
know if it doesn't work for you.
Also in this release is a fix from Aasif Versi to use a smarter exit
status if k5start or krenew is running another program and that program is
killed with a signal. Previously, that would cause k5start or krenew to
exit with a status of 0, which was not helpful. Now it exits with a
status formed by adding 128 to the signal number, which matches the
behavior of bash.
Since this is the first release in a while, it also contains some other
minor fixes and portability updates.
You can get the latest release from the kstart distribution page.
I first started using Debian sometime in the mid 90s and started contributing as a developer and package maintainer more than two decades years ago. My first very first scholarly publication, collaborative work led by Martin Michlmayr that I did when I was still an undergrad at Hampshire College, was about quality and the reliance on individuals in Debian. To this day, many of my closest friends are people I first met through Debian. I met many of them at Debian s annual conference DebConf.
Given my strong connections to Debian, I find it somewhat surprising that although all of my academic research has focused on peer production, free culture, and free software, I haven t actually published any Debian related research since that first paper with Martin in 2003!
So it felt like coming full circle when, several days ago, I was able to sit in the virtual DebConf audience and watch two of my graduate student advisees Kaylea Champion and Wm Salt Hale present their research about Debian at DebConf21.
Salt presented his masters thesis work which tried to understand the social dynamics behind organizational resilience among free software projects. Kaylea presented her work on a new technique she developed to identifying at risk software packages that are lower quality than we might hope given their popularity (you can read more about Kaylea s project in our blog post from earlier this year).
If you missed either presentation, check out the blog post my research collective put up or watch the videos below. If you want to hear about new work we re doing including work on Debian you should follow our research group blog, and/or follow or engage with us in the Fediverse (@communitydata@social.coop), or on Twitter (@comdatasci).
And if you re interested in joining us perhaps to do more research on FLOSS and/or Debian and/or a graduate degree of your own? please be in touch with me directly!
One of the technologies that was created by DFINITY as we built the Internet Computer is Candid. Candid is
a language to describe the interface of a service, with named methods, arguments and results,
a type system for these arguments and results that maps to many possible implementation languages, thus enabling interoperability between these languages,
a wire format (encoding) of values of these types,
a notion of safe upgrade that allows service developers to evolve their interface with the assurance that no clients break, even in the presence of higher-order composition,
a meta-theory of safe interface description languages and a formal proof that Candid has these properties, and
a bunch of tools and libraries.
In this in-depth blog post series I want to shed some light onto these aspects of Candid. The target audience is mainly anyone who wants to deeply understand Candid, e.g. researchers, implementors of Candid tools, anyone who wants to builds a better alternative, but no particular prior Candid knowledge is expected. Also, much of what is discussed here is independent of the Internet Computer. Some posts may be more theoretical or technical than others; if you are lost in one I hope you ll rejoin for the subsequent post
Much in these posts is not relevant for developers who just want to use Candid in their projects, and also much that they want to know is missing. The Internet Computer dev docs will hopefully cater to that audience.
Blog post series overview
The rough idea (this post)
Announcing the blog post series, and very briefly outlining what an Interface Description Language even is.
Safe higher-order upgrades
Every can do first-order interface description languages. What makes Candid special is its support for higher-order service composition. This post also contains some general meta-theory and a Coq proof!
Opt is special
Extending records in argument position is surprisingly tricky. Lean why, and how we solved it.
Language integration
The point of Candid is inter-op, so let s look the various patterns of connecting Candid to your favorite programming language.
Quirks
The maybe most interesting post in this series: Candid has a bunch of quirks (hashed field names, no tuples but sequnces, references that nobody used, and more). I ll explain some of them, why they are there, and what else we could have done. Beware: This post will be opinionated.
The rough idea
The idea of an interface description language is easy to begin with. Something like
service A :
add : (int) -> ();
get : () -> (int);
clearly communicates that a service called A provides two methods add and get, that add takes an integer as an argument, and that get returns such a number. Of course, this only captures the outer shape of the service, but not what it actually does we might assume it implements a counter of sorts, but that is not part of the Candid interface description.
In order to now use the service, we also need a (low-level) transport mechanism. Candid itself does not specify that, but merely assumes that it exists, and is able to transport the name of the invoked method and a raw sequence of bytes to the service, and a response (again a raw sequence of bytes) back.
Already on the Internet Computer we have two distinct transport mechanisms used are external calls via an HTTP-based RPC interface and on-chain inter-canister calls. Both are handled by the service in the same way. Here we can see that Candid succeeds in abstracting over differences in the low-level transport mechanism. Because of this abstraction, it is possible to use Candid over other transportation mechanisms as well (conventional HTTPS, E-Mail, avian carrier). I think Candid has potential there as well, so even if you are not interested in the Internet Computer, this post may be interesting to you.
The translation of argument and result values (e.g. numbers of type int) to the raw sequence of bytes is specified by Candid, defining a wire format. For example, the type int denotes whole numbers of arbitrary size, and they are encoded using the LEB128 scheme. The Candid wire format also contains a magic number (DIDL, which is 0x4449444c in hex) and a type description (more on that later). So when passing the value 2342 to the add, the raw bytes transported will be 0x4449444c00017da612.
Of course we want to transfer more data than just integers, and thus Candid supports a fairly complete set of common basic types (nat, int, nat8, nat16, nat32, nat64, int8, int16, int32, int64, float32, float64, bool, text, blob) and composite types (vectors, optional values , records and variants). The design goal is to provide a canonical set of types enough to express most data that you might want to pass, but no more than needed, so that different host languages can support these types easily.
The Candid type system is structural. This means that two types are the same when they are defined the same way. Imagine two different services defining the same
type User = record name : text; user_id : nat
then although User is defined in two places, it s still the same type. In other words, these name type definitions are always just simple aliases, and what matters is their right-hand side.
Because Candid types can be recursive (e.g. type Peano = opt Peano), this means we have an equirecursive type system, which makes some things relatively hard.
So far, nothing too special about Candid compared to other interface definition languages (although a structural equirecursive type system is already something). In the next post we look at reference types, and how such higher order features make Candid an interesting technology.
Aug 28, 2021, I gave a short talk about "Latest topics about fabre.debian.net" at DebConf21.
You can see the presentation slide here:
slide.rabbit-shocker.org
Short talk explanation is here:
debconf21.debconf.org
In this talk, I've explained mainly 3 topics
Domain migration to debian.net subdomain - fabre.debian.net
I've sent a pre-recorded video in advance, it is ok, but there is trouble with the mic during the session. :-(
The recorded video will be available on the talk detail page soon.
CVE-2020-22036: A heap-based Buffer Overflow vulnerability in filter_intra at libavfilter/vf_bwdif.c, which might lead
to memory corruption and other potential consequences.
CVE-2020-22032: A heap-based Buffer Overflow vulnerability in
gaussian_blur, which might lead to memory corruption and other
potential consequences.
CVE-2020-22031: A Heap-based Buffer Overflow vulnerability in
filter16_complex_low, which might lead to memory corruption and
other potential consequences.
CVE-2020-22028: Buffer Overflow vulnerability
in filter_vertically_8 at libavfilter/vf_avgblur.c, which could cause a remote
Denial of Service.
CVE-2020-22026: Buffer Overflow vulnerability exists in the config_input function at libavfilter/af_tremolo.c, which could let a remote malicious
user cause a Denial of Service.
CVE-2020-22025: A heap-based Buffer Overflow vulnerability
exists in gaussian_blur at libavfilter/vf_edgedetect.c, which might lead to memory
corruption and other potential consequences.
CVE-2020-22023: A heap-based Buffer Overflow vulnerabililty
exists in filter_frame at libavfilter/vf_bitplanenoise.c, which might lead to
memory corruption and other potential consequences.
CVE-2020-22022: A heap-based Buffer Overflow vulnerability exists in
filter_frame at libavfilter/vf_fieldorder.c, which might lead to memory
corruption and other potential consequences.
CVE-2020-22021: Buffer Overflow vulnerability at filter_edges function in libavfilter/vf_yadif.c, which could let a remote malicious user cause a
Denial of Service.
CVE-2020-22020: Buffer Overflow vulnerability in the build_diff_map function
in libavfilter/vf_fieldmatch.c, which could let a remote malicious user
cause a Denial of Service.
CVE-2020-22016: A heap-based Buffer Overflow vulnerability
at libavcodec/get_bits.h when writing .mov files, which might lead to memory corruption and other potential consequences.
CVE-2020-22015: Buffer Overflow vulnerability in mov_write_video_tag due to the out of bounds in libavformat/movenc.c, which could let a remote
malicious user obtain sensitive information, cause a Denial of Service, or
execute arbitrary code.
CVE-2020-21041: Buffer Overflow vulnerability exists via
apng_do_inverse_blend in libavcodec/pngenc.c, which could let a remote
malicious user cause a Denial of Service
CVE-2021-3566: The tty demuxer did not have a read_probe function
assigned to it. By crafting a legitimate ffconcat file that references an
image, followed by a file the triggers the tty demuxer, the contents of the
second file will be copied into the output file verbatim (as long as the
-vcodec copy option is passed to ffmpeg).
CVE-2021-38114: libavcodec/dnxhddec.c does not check the return value of the init_vlc function. Crafted DNxHD data can cause unspecified impact.
DLA 2742-2 ffmpeg_7:3.2.15-0+deb9u4
During the backporting of one of patches in CVE-2020-22021 one line was wrongly
interpreted and it caused the regression during the deinterlacing process.
Thanks to Jari Ruusu for the reporting the issue and for the testing of
prepared update.
Other LTS-related work
Analyzed CVE-2020-22027 and
marked as ignored for stretch. Original patch is not appliable. The issue is reproducible though.
The diffoscope maintainers are pleased to announce the release of diffoscope
version 182. This version includes the following changes:
[ Chris Lamb ]
* Also ignore, for example, spurious "fwGCC: (Debian ... )" lines in output
from strings(1).
* Only use "java -jar /path/to/apksigner.jar" if we have a .jar as newer
versions of apksigner use a shell wrapper script which will obviously be
rejected by the JVM. Also mention in the diff if apksigner is missing.
* Pass "-f" to apktool to avoid creating a strangely-named subdirectory and
to simplify code.
* If we specify a suffix for temporary file or directory, ensure it starts
with a "_" to make the generated filenames more human-readable.
* Drop an unused File import.
* Update the minimum version of the Black source code formatter.
[ Santiago Torres Arias ]
* Support parsing the return value of squashfs versions which discriminate
between fatal and non-fatal errors.
The Debian Janitor is an automated
system that commits fixes for (minor) issues in Debian packages that can be
fixed by software. It gradually started proposing merges in early
December. The first set of changes sent out ran lintian-brush on sid packages maintained in
Git. This post is part of a series about the progress of the Janitor.
Linux distributions like Debian fulfill an important function in the FOSS ecosystem - they are system integrators that take existing free and open source software projects and adapt them where necessary to work well together. They also make it possible for users to install more software in an easy and consistent way and with some degree of quality control and review.
One of the consequences of this model is that the distribution package often lags behind upstream releases. This is especially true for distributions that have tighter integration and standardization (such as Debian), and often new upstream code is only imported irregularly because it is a manual process - both updating the package, but also making sure that it still works together well with the rest of the system.
The process of importing a new upstream used to be (well, back when I started working on
Debian packages) fairly manual and something like this:
Go to the upstream s homepage, find the tarball and signature and verify the tarball
Make modifications so the tarball matches Debian s format
Diff the original and new upstream tarballs and figure out whether changes
are reasonable and which require packaging changes
Update the packaging, changelog, build and manually test the package
Upload
Ecosystem Improvements
However, there have been developments over the last decade that make it easier to import new upstream releases into Debian packages.
Uscan and debian QA watch
Uscan and
debian/watch have been around for a
while and make it possible to find upstream tarballs.
A debian watch file usually looks something like this:
The QA watch service regularly polls
all watch locations in the archive and makes the information available, so it s
possible to know which packages have changed without downloading each one of them.
Git
Git is fairly ubiquitous nowadays, and most upstream projects and packages in Debian use it. There are still exceptions that do not use any version control system or that use a different control system, but they are becoming increasingly rare. [1]
debian/upstream/metadata
DEP-12 specifies a file format with metadata about the upstream project that a package was based on. In particular relevant for our case is the fact it has fields for the location of the upstream version control location.
debian/upstream/metadata files look something like this:
While DEP-12 is still a draft, it has already been widely adopted - there are about 10000 packages in Debian that ship a debian/upstream/metadata file with Repository information.
Autopkgtest
The Autopkgtest
standard and associated tooling provide a way to run a defined set of tests
against an installed package. This makes it possible to verify that a package
is working correctly as part of the system as a whole. ci.debian.net regularly runs these tests against Debian packages to
detect regressions.
Vcs-Git headers
The Vcs-Git headers in debian/control are the equivalent of the Repository field in debian/upstream/metadata, but for the packaging repositories (as opposed to the upstream ones).
They ve been around for a while and are widely adopted, as can be seen from zack s stats:
The vcswatch service that regularly
polls packaging repositories to see whether they have changed makes it a lot
easier to consume this information in usable way.
Debhelper adoption
Over the last couple of years, Debian has slowly been converging on a single
build tool - debhelper s dh interface.
Being able to rely on a single build tool makes it easier to write code to
update packaging when upstream changes require it.
Debhelper DWIM
Debhelper (and its helpers) increasingly can figure out how to do the Right
Thing in many cases without being explicitly configured. This makes packaging
less effort, but also means that it s less likely that importing a new upstream
version will require updates to the packaging.
With all of these improvements in place, it actually becomes feasible in a lot
of situations to update a Debian package to a new upstream version
automatically. Of course, this requires that all of this information is
available, so it won t work for all packages. In some cases, the packaging for
the older upstream version might not apply to the newer upstream version.
The Janitor has attempted to import a new upstream Git snapshot and a new
upstream release for every package in the archive where a debian/watch file or
debian/upstream/metadata file are present.
These are the steps it uses:
Find new upstream version
If release, use debian/watch - or maybe tagged in upstream repository
If snapshot, use debian/upstream/metadata s Repository field
If neither is available, use guess-upstream-metadata from upstream-ontologist to guess the upstream Repository
Merge upstream version into packaging repository, possibly importing tarballs using pristine-tar
Update the changelog file to mention the new upstream version
Run some checks to ensure there are no unintentional changes, e.g.:
Scan diff between old and new for surprising license changes
Today, abort if there are any - in the future, maybe update debian/copyright
Check for obvious compatibility breaks - e.g. sonames changing
Attempt to update the packaging to reflect upstream changes
Refresh patches
Attempt to build the package with deb-fix-build, to deal with any missing dependencies
Run the autopkgtests with deb-fix-build to deal with missing dependencies, and abort if any tests fail
Results
When run over all packages in unstable (sid), this process works for a surprising number of them.
Fresh Releases
For fresh-releases (aka imports of upstream releases), processing all packages maintained in Git for which QA watch reports new releases (about 11,000):
That means about 2300 packages updated, and about 4000 unchanged.
Fresh Snapshots
For fresh-snapshots (aka imports of latest Git commit from upstream), processing all packages maintained in Git (about 26,000):
Or 5100 packages updated and 2100 for which there was nothing to do, i.e. no upstream commits since the last Debian upload.
As can be seen, this works for a surprising fraction of packages. It s possible to get the numbers up even higher, by both improving the tooling, the autopkgtests and the metadata that is provided by packages.
Using these packages
All the packages that have been built can be accessed from the Janitor APT repository. More information can be found at https://janitor.debian.net/fresh, but in short - run:
1
2
3
4
5
6
echo deb "[arch=amd64 signed-by=/usr/share/keyrings/debian-janitor-archive-keyring.gpg]" \ https://janitor.debian.net/ fresh-snapshots main sudo tee /etc/apt/sources.list.d/fresh-snapshots.listecho deb "[arch=amd64 signed-by=/usr/share/keyrings/debian-janitor-archive-keyring.gpg]" \ https://janitor.debian.net/ fresh-releases main sudo tee /etc/apt/sources.list.d/fresh-releases.listsudo curl -o /usr/share/keyrings/debian-janitor-archive-keyring.gpg https://janitor.debian.net/pgp_keysapt update
And then you can install packages from the fresh-snapshots (upstream git snapshots) or fresh-releases suites on a case-by-case basis by running something like:
1
apt install -t fresh-snapshots r-cran-roxygen2
Most packages are updated based on information provided by vcswatch and qa watch, but it s also possible for upstream repositories to call a web hook to trigger a refresh of a package.
These packages were built against unstable, but should in almost all cases also work for testing.
Caveats
Of course, since these packages are built automatically without human supervision it s likely that some of them will have bugs in them that would otherwise have been caught by the maintainer.
DebConf21 is taking place online, from 24 August to 28 August 2021.
It is the 22nd Debian conference, and organizers and participants are working hard
together at creating interesting and fruitful events.
We would like to warmly welcome the 19 sponsors of DebConf21, and introduce them to you.
We have five Platinum sponsors.
Our first Platinum sponsor is Lenovo.
As a global technology leader manufacturing a wide portfolio of connected products,
including smartphones, tablets, PCs and workstations as well as AR/VR devices,
smart home/office and data center solutions, Lenovo
understands how critical open systems and platforms are to a connected world.
Our next Platinum sponsor is Infomaniak.
Infomaniak is Switzerland's largest web-hosting company,
also offering backup and storage services, solutions for event organizers,
live-streaming and video on demand services.
It wholly owns its datacenters and all elements critical
to the functioning of the services and products provided by the company
(both software and hardware).
Roche is our third Platinum sponsor.
Roche is a major international pharmaceutical provider and research company
dedicated to personalized healthcare. More than 100,000 employees worldwide
work towards solving some of the greatest challenges for humanity using
science and technology. Roche is strongly involved in publicly funded
collaborative research projects with other industrial and academic partners
and has supported DebConf since 2017.
Amazon Web Services (AWS) is our fourth Platinum
sponsor.
Amazon Web Services is one of the world's
most comprehensive and broadly adopted cloud platform,
offering over 175 fully featured services from data centers globally
(in 77 Availability Zones within 24 geographic regions).
AWS customers include the fastest-growing startups, largest enterprises
and leading government agencies.
Google is our fifth Platinum sponsor.
Google is one of the largest technology companies in the
world, providing a wide range of Internet-related services and products such
as online advertising technologies, search, cloud computing, software, and hardware.
Google has been supporting Debian by sponsoring DebConf for more than
ten years, and is also a Debian partner sponsoring parts
of Salsa's continuous integration infrastructure
within Google Cloud Platform.
Our Gold sponsor is the Matanel Foundation.
The Matanel Foundation operates in Israel,
as its first concern is to preserve the cohesion of a society and a nation
plagued by divisions. The Matanel Foundation also works in Europe, in Africa
and in South America.
Our Silver sponsors are:
arm: the World s Best SoC Design Portfolio,
Arm powered solutions have been supporting innovation for more than 30 years
and are deployed in over 160 billion chips to date,
Hudson-Trading,
a company researching and developing automated trading algorithms
using advanced mathematical techniques,
Ubuntu
the Operating System delivered by Canonical,
Globo,
the largest media conglomerate in Brazil, founded in Rio de Janeiro in 1925
and distributing high-quality content across multiple platforms,
Two Sigma,
rigorous inquiry, data analysis, and invention to help solve the toughest
challenges across financial services
and
GitLab,
an open source end-to-end software development platform with built-in version
control, issue tracking, code review, CI/CD, and more.
Bronze sponsors:
Univention,
Gandi.net,
daskeyboard,
InterFace AG and
credativ.
And finally, our Supporter level sponsor, ISG.EE.
Thanks to all our sponsors for their support!
Their contributions make it possible for a large number
of Debian contributors from all over the globe to work together,
help and learn from each other in DebConf21.
Participating in DebConf21 online
The 22nd Debian Conference is being held online, due to COVID-19,
from August 24 to 28, 2021. Talks, discussions, panels and other activities run from 12:00 to 02:00 UTC.
Visit the DebConf21 website at https://debconf21.debconf.org
to learn about the complete schedule, watch the live streaming and join the different
communication channels for participating in the conference.
We are very pleased to announce that Lenovo,
Infomaniak,
Roche,
Amazon Web Services (AWS)
and Google,
have committed to supporting DebConf21 as Platinum sponsors.
As a global technology leader manufacturing a wide portfolio of connected products,
including smartphones, tablets, PCs and workstations as well as AR/VR devices,
smart home/office and data center solutions, Lenovo
understands how critical open systems and platforms are to a connected world.
Infomaniak is Switzerland's largest web-hosting company,
also offering backup and storage services, solutions for event organizers,
live-streaming and video on demand services.
It wholly owns its datacenters and all elements critical
to the functioning of the services and products provided by the company
(both software and hardware).
Roche
Roche is a major international pharmaceutical provider and research company
dedicated to personalized healthcare. More than 100.000 employees worldwide
work towards solving some of the greatest challenges for humanity using
science and technology. Roche is strongly involved in publicly funded
collaborative research projects with other industrial and academic partners
and have supported DebConf since 2017.
Amazon Web Services (AWS) is one of the world's
most comprehensive and broadly adopted cloud platform,
offering over 175 fully featured services from data centers globally
(in 77 Availability Zones within 24 geographic regions).
AWS customers include the fastest-growing startups, largest enterprises
and leading government agencies.
Google is one of the largest technology companies in the
world, providing a wide range of Internet-related services and products such
as online advertising technologies, search, cloud computing, software, and hardware.
Google has been supporting Debian by sponsoring DebConf for more than
ten years, and is also a Debian partner sponsoring parts
of Salsa's continuous integration infrastructure
within Google Cloud Platform.
With these commitments as Platinum Sponsors,
Lenovo, Infomaniak, Roche, Amazon Web Services and Google are contributing
to make possible our annual conference,
and directly supporting the progress of Debian and Free Software,
helping to strengthen the community that continues to collaborate on
Debian projects throughout the rest of the year.
Thank you very much for your support of DebConf21!
Participating in DebConf21 online
The 22nd Debian Conference is being held Online, due to COVID-19,
from August 22nd to 28th, 2021. There are 8 days of activities, running from 10:00 to 01:00 UTC.
Visit the DebConf21 website at https://debconf21.debconf.org
to learn about the complete schedule, watch the live streaming and join the different
communication channels for participating in the conference.
IntroMy name is Leandro Doctors ( allentiak on IRC), and I ve been the GSoC
intern working with the Debian Clojure Team during 2021. This is my
final report. You can also check my original
proposal
and my first
report.
SummaryWhereas the raw data may not sound by itself very positive, my personal
conclusion is. This is, whereas I didn t fully finish the required
deliverables envisioned in my original proposal, I do feel I am much
closer to, eventually, becoming a Debian Developer. So, by all means, I
consider this project has had a positive outcome.
ProjectThe goal of the Clojure Build Tools in Debian project was to provide
Clojure Debian users with some of the latest advanced build tools and
libraries the upstream Clojure developers have been lately working on.
These include tools.deps.alpha, a library for dependency graph
resolution and classpath building, and the CLI tool clj, for REPL
interaction. If time permitted, I was also to improve the quality of
both new and existing Clojure packages, and the overall Debian Clojure
packaging process. My mentor was Louis-Louis-Philippe V ronneau, and my
co-mentor was Utkarsh Gupta.
MotivationWhy this project? On the one side, if you re a Clojure lover like me,
you may have noticed that the Clojure experience in Debian is, as of mid
2021, well... still quiet limited. Additionally, this project aligned
with my own background in Free Software community building and my
research interest in Peer Production.When I mention how limited today s Clojure experience in Debian is, I
can see two reasons for this, deeply intertwined. The first one is that
there currently aren t many Clojure-specific packaging tools in Debian
(such as a clojure-debian-helper). The second reason for which we only
currently have a suboptimal Clojure experience in Debian, and probably
the root of the previous one, is that many core build tools and
libraries for the language have not simply been packaged yet. My project
aimed to attack that seemingly root cause.As I said, another reason for me choosing this project is my own
experience as the Co-founder and Leader of, probably, the first Free
Software Community experience in my hometown of San Juan, Argentina.
That interest in Free Software evolved in a first PhD attempt in what is
now known as the field of Peer Production. A subject that has lived
within me as a research interest during my day job at a University.Being a Clojure fan, it felt only logical combining all those interests
somehow. And this project seemed like the ideal combination.
The Debian Clojure TeamI ve been working with a small, yet very warm team. The current
incarnation of the Debian Clojure Team exists thanks to the hard work of
three people.Elana Hashman (aka the Clojure necromancer ), revived the team around
three years ago. Later on, the team gained the invaluable presence of
Louis-Philippe V ronneau and Utkarsh Gupta (my mentor and co-mentor,
respectively).Together, these Three Musketeers have maintained the team alive,
allowing us, Debian users, to enjoy Clojure.
StatusDuring the first part of my project, I mainly worked on learning the
basics of Debian packaging, and got my first package uploaded. I have to
thank Louis-Philippe, Utkarsh, and Elana for their immense patience and
support during that part, as it took me quite some effort grasping the
basics of Debian packaging.During the second part of my project, I worked on my last packages, and
almost completed the originally required scope of the project. I only
have to finish working on the transition from the currently provided set
of packages (based on a Debian-specific clojure runner) to the newly
provided upstream clojure and clj runners.Unfortunately, I didn t have much time left to start working on the
opportunities for improvement already identified by the Debian Clojure
Team originally outlined in my proposal. Whereas I did update one older
Clojure package not built using leiningen (tools-data-xml-clojure), I
didn t write any Lintian tags to make Clojure packaging in Debian more
robust, nor worked towards the automation of Clojure unit tests in
autopkgtests via autodep8.
Deliverables: Data vs. ConclusionsIf we are to talk about deliverables, we should start with the data.
According to my original proposal, I was required to provide both new
and updated Clojure packages accepted into Debian unstable , and
updated Clojure packaging documentation. Additionally, if time
permitted, I was to also provide new Clojure Lintian tags merged by the
Lintian maintainers, and new Clojure autodep8 scripts merged by the
autodep8 maintainers. Whereas I partially accomplished both required
tasks, I didn t manage to start working on any of the optional
deliverables.When looked in isolation, those numbers may look somewhat disappointing
for some people. However, I can draw a much more positive conclusion.
Why?Firstly, GSoC is supposed to be a learning experience. Moreover, as I
said in my original proposal, I
approach[ed] this project as a great
opportunity to, finally, start my journey towards becoming a Debian
Developer . In that sense, I consider the time invested into this
project fruitful. In this way, I have learned the basics of packaging,
how to interact with the Debian Clojure Team, and and already got my
first packages accepted. Plus, I m looking forward to continuing to work
with the Debian Clojure Team so I can attain the original scope of the
project. Therefore, all things considered, I can consider this
experience as a moderate success.
Lessons LearnedTechnically speaking, if I have learned one thing during these weeks, is
that packaging, although easy to be underestimated, is by no means a
trivial process. As any Debian Developer surely knows, the onboarding
process can take some time. Plus, what is easy for some people, can be
difficult for others. In my case, this was quite evident. Whereas I can
speak several languages and learning new ones takes me little effort,
grasping the basics of packaging took me (literally!) blood, sweat and
tears. Indeed, the packaging learning curve was quite steep for me.That being said, I did learn a thing or two about packaging. So, if I
managed to get here, I m sure many others can. It may take them more or
less time than what it took me, but learning (at least the basics) of
packaging is an achievable goal.Technical skill learning aside, I value very highly the non-technical
skills I have so far improved during this project.For instance, I also learned that it can take some time to adapt to
real-time online communication. Before this project, remote working
meant either exchanging emails or getting into video or audio calls,
with a low emphasis on chat-based interaction. Early on, I realized that
the Debian Clojure Team interacts almost exclusively via, well... chat!
And those two approaches are very different indeed. It has taken me some
time to adjust, but I ve improved greatly in this aspect as well.Finally, improving my time management skills has been also a key part of
this process. Whereas I had already been working remotely for over a
year and a half already, my day job is not so interaction-dependent as
this project (specially in the beginning). So it took me some time to
adapt to this way of working, and to plan my workload so I could use
those waiting moments to advance in other parts of the project. Still a
lot to improve here, but improving nevertheless.
AcknowledgmentsI first have to thank upstream. More specifically, one of the upstream
developers of the clojure-tools, Alex Miller. Everytime I needed
specific information on what do specific parts of the Clojure CLI
tools s codebase do, tools.deps.alpha do, he popped up a reply in a
matter of hours. He has shown genuine interest in the success of is
project during by carefully replying to my emails with detailed
explanations of code intent and form, both in private and in public
conversations. Thank you for all that, Alex!Let s move on to the Debian Clojure Team.First, Elana. I thank Elana for her initial openness when I first
contacted her about this idea. It was *her*
who initially contacted Louis-Philippe so he would become my mentor. I
wouldn t have started to work on this project if it wasn t for her.
Plus, she provided quite a piece of advise in more that one ocassion.
So, thank you very much for all that, Elana!I also thank Utkarsh, my co-mentor, for his overall technical advise.
And a special mention to his initial help to setup my Matrix client for
OFTC chat. At that moment, it was *him* who
took the time to help me in real time so I could solve that problem. So,
thank you very much for all that, Utkarsh!I finally have to thank Louis-Philippe, my mentor, for his patient
guidance during the whole process. His dedication and hard work has been
*instrumental* for my progress. And a
special mention for his tolerance with respect to some unforeseen
personal circumstances I had to endure during the first weeks. When one
is playing the newbie, times abound when one depends on other people s
feedback. And Debian is made of volunteers, who have a life outside it.
Every time I asked, Louis-Philippe was there. I wouldn t have gotten
here if it wasn t for him. So, thank you
*so* much for all that, Louis-Philippe!
Final WordsI would like to close this report with a reflection.I have been using Debian for many, many years now, and I had been
looking for a way to contribute back to the project for some time
already. I even did some work on a non-packaging Debian project. That
being said, I never managed to deliver much, really.So, the very existence of outreach programs as this one is, in my humble
opinion, crucial. In my case, the funding I got through the GSoC program
was instrumental in being able to allocate time for this endeavor, and
to finally get started contributing to Debian. Plus, it has had a very
positive impact on me; in many ways, some of which I am only starting to
discover now that the project is ending.When I put things into perspective, this project is very important for
me. Actually, it is nothing but the first step within a long-term
journey: becoming a Debian member. Hopefully, I would like to be able to
apply for Debian membership by the end of this year.
Questions?Thank you very much for your time reading this! I look forward to
hearing (or reading) your feedback. Please come and meet with the Debian
Clojure Team Moreover, I will be in the Clojure BoF on DebConf2021.
Moreover, do not hesitate to send me an email.
Data
Task Status
Required Tasks:
T1: Setting up a full Debian packaging development environment
and learning the basics of Debian packaging.
Successfully completed the first part during the Application
period.
Successfully completed the second part during the Coding
periods.
T2: Identifying and packaging the missing dependencies to
package clojure-cli.
Successfully completed as of the end of Coding II.
T3: Packaging clojure-cli.
90% done as of the end of Coding II.
T4: Updating clojure to use clojure-cli.
To be completed after GSoC.
T5: Updating the Clojure Packaging Guide with information on how
to use the new clojure-cli scripts.
Improved existing documentation. To be completed after GSoC.
Optional Tasks:
T6: Writing Lintian tags to make Clojure packaging in Debian
more robust.
To be completed after GSoC.
T7: Working to automate Clojure unit testing in autopkgtests
using autodep8.
To be completed after GSoC.
T8: Updating older Clojure packages not built using leiningen or
clojure-cli.
tools-gitlibs-clojure -- Clojure API for programatically
accessing git libraries. ITP:
#905543in
NEW.
ITP: tools-deps-alpha-clojure -- functional API for dependency
management and classpath creation
https://bugs.debian.org/891136 Needs to be uploaded by
Louis-Philippe.
In-Progress packages:
ITP: clojure-cli -- upstream CLI entrypoints for Clojure
https://bugs.debian.org/891141 90% done - Package completed.
I only need to finish implementing the transition from existing
clojure scripts. To be completed after GSoC.
About the Project
Debian Continuous Integration is Debian s CI platform. It runs tests on the packages published in the Debian archive, and today is used to control migration of packages from unstable, Debian s development area, to testing, the area of the archive where the next Debian release is being prepared. This makes it a crucial part of Debian s infrastructure.
The web platform shows the results of all the tests executed. Debian CI provides developers both API and a GUI Self-Service section to request tests for the packages and get information on test history.
This project involves implementing incremental improvements to the platform, making it easier to use and maintain.
Deliverables of the project:
Migrating Logins to Salsa
Adding support for testing security uploads and Debian LTS
Work done
Migrating Logins to Salsa
Originally, Debian CI used Debian SSO client certificates for logging in, but since that was deprecated logins are migrated to Salsa, Debian s Gitlab instance and this is implemented with the help of OmniAuth, the ruby authentication framework.
Another thing fixed as part of this task was that there exists a limitation in the existing database structure, where usernames were directly stored as the test requestor field, so that relationship was normalized with a proper foreign key to the users table.
Adding support for testing security uploads and Debian LTS
In this task, work was done to enable private tests in Debian CI for adding support for testing security uploads and Debian LTS. It includes tasks from adding the private field in the API and Self-Service section in requesting tests to adding an option to publish them when ready through both interfaces.
Merge Requests:
Learning Takeaways
I learned a lot throughout the entire journey. Some of the things to mention are:
Writing tests: I learned about using Rspec for writing tests in ruby and understood how writing tests is an integral part of coding any project.
Using good coding practices: By my merge requests reviews done by my mentor Antonio, I came to know about good coding practices which help in keeping the code both clean and concise.
Acknowledgement
I owe huge thanks to my mentors Antonio Terceiro and Paul Gevers for their constant support and guidance throughout the entire duration. It is for them that I was able to get started with the code-base of the project in the first place. And while working on the project, they were extremely responsive to all my queries. My merge requests were all thoroughly reviewed which enables me to learn more and work more efficiently. It was a complete pleasure interacting with them on weekly meet calls.
To sum up, my GSoC journey was awesome and I had a fun and productive summer with Debian
What s next?
As part of a continuation of my project task Adding support for testing security uploads and Debian LTS, I would be working on Debian CI to facilitate the process of connecting the embargoed archive.
It s the end of my GSoC journey but certainly not the end of my journey with Debian or Open-Source. I plan to stay an active contributor to Debian and get involve with more Open Source projects as well
Extras
The link to my Salsa Profile for all my work activities can be found here.
To know more about my journey, my other GSoC blog posts can be found below:
I have been using the GIMP since about 20 years or so, but recently started to also work with Krita since I found it quite nice to work with (besides the text module, which is a pain).
As there came out the first beta of Krita 5, I decided to throw it into my KDE/Plasma OBS builds to try it out. To get it working, add my OBS key say in /usr/local/share/keyrings/obs-npreining.asc and add a file /etc/apt/sources.lists.d/obs-npreining-krita-beta.list, containing the following line:
deb [signed-by=/usr/local/share/keyrings/obs-npreining.asc] https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/krita-beta/Debian_Unstable/ ./
Warning: Krita will also warn you, but files saved with version 5 might not be openable with version 4 of Krita, so be sure to have a backup of your files in case you need to go back to Krita 4.
Enjoy.
Thanks to the good folk who put the hard work into building a UEFI implementation for the Raspberry Pi 4 which "just works", allowing you to install Debian straightforwardly, and especially to Pete Batard who has written up the process and collected a zip file together.
Not quite so straightforward ...
I have an early model Raspberry Pi 4. I wanted to install Debian on an SSD connected via a cable to a USB3 port. It turned out that the version of the software in the EEPROM would not boot reliably so the first task was to update this with the latest stable EEPROM available from the Raspberry Pi downloads.
The easiest way to do this was to boot an SD card with Raspbian on. Once that was done, I had a Pi that would boot from an SSD.
Plugging in the SSD to another machine to format the drive: msdos format, one ESP partition in FAT32 and marked bootable and the rest of the drive blank.
Untar the UEFI tarball into the ESP partition you've just made
Plug the SSD into a USB3 port on the RPi using a USB -> SATA cable
Write the aarch image to a USB stick using dd and place that into one of the other USB ports. Add a keyboard.
Install
Power up the RPi4, hit Esc and work your way through UEFI to select a boot device and go, save the settings and go.
The install is almost identical to any Debian d-i install.
There is a setting in UEFI to reclaim the 1G of memory that was masked out, there's a setting for control of the fan shim if you have that style of fan.
End result - happiness
Done the other day and sitting next to me on the desktop.
Bullseye has been released, and we are in the post-release rush with lots of changes going on. On the KDE/Plasma side we are trying to move all our accumulated changes to unstable. On the OSC side, frameworks 5.85 and KDE Gears 21.08.0 have been released.
Debian Bullseye
As mentioned previously, the now released Debian/Bullseye contains KDE Frameworks 5.78, including several backports of fixes from 5.79 to get smooth operation. Plasma 5.20.5, again with several cherry picks for bugs will be in Bullseye, too. The KDE/Apps are mostly at 20.12 level, and the KDE PIM group packages (akonadi, kmail, etc) are at 20.08.
Debian unstable (and in time also testing)
Frameworks 5.83 and Plasma 5.21.5 have been uploaded to unstable. This is a temporary measure until several necessary packages have cleared the NEW queue. After that we will upload frameworks 5.85 and Plasma 5.22.N.
KDE Gears is still at 20.08, but we have 21.04 in experimental, and I am currently preparing to upload 21.08.0, should be done soon.
OBS packages
The OBS packages as usual follow the latest release, and currently ship KDE Frameworks 5.85, KDE Gears 21.08.0, and Plasma 5.22.4. The package sources are as usual (note the different path for the Plasma packages and the apps packages, containing the release version!), for Debian/unstable:
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/frameworks/Debian_Unstable/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/plasma522/Debian_Unstable/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/apps2108/Debian_Unstable/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/other/Debian_Unstable/ ./
and the same with Testing instead of Unstable for Debian/testing.
OBS for bullseye
For now, use the Testing packages with the addition dependencies:
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/other-deps/Debian_Testing/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/frameworks/Debian_Testing/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/plasma522/Debian_Testing/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/apps2108/Debian_Testing/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/other/Debian_Testing/ ./
Sooner or later OBS will offer Debian Bullseye as proper target, and then I will prepare releases for it and write another blog post.
Closing
Expect continued breakage of the next weeks until the upload storm subsides a bit.
Make it easier to work in Rust without giving the Rust environment
(and every author of every one of your dependencies!) control
of your main account. (Privsep, with linkfarming where needed.)
Tweak a few defaults.
Background and history
It's not really possible to make a nontrivial Rust project without
using cargo.
But the build process automatically downloads and executes code from
crates.io, which is a minimally-curated repository.
I didn't want to expose my main account to that.
And, at the time, I was working on a project which for which I was
also writing a library as a dependency, and I found that cargo
couldn't cope with this unless I were to commit (to my git repository)
the path (on my local laptop) of my dependency.
I filed some bugs, including about the unpublished crate problem.
But also, I was stubborn enough to try to find
a workaround that didn't involve committing junk to my git history.
The result was a
short but horrific shell script.
I wrote about this
at the time (March 2019).
Over the last few years the difficulties I have with cargo have
remained un-resolved. I found my
interactionswithupstream
rather discouraging.
It didn't seem like I would get anywhere by trying to help
improve cargo to better support my needs.
So instead I have gradually improved nailing-cargo. It is now a Perl
script. It is rather less horrific, and has
proper documentation
(sorry, JS needed because GitLab).
Why Perl ?
Rust would have been my language of choice. But I wanted to avoid a
chicken-and-egg situation. When you're doing privsep, nailing-cargo
has to run in your more privileged environment. I wanted something
easy to get going with.
nailing-cargo has to contain a TOML parser; and I found a small one,
TOML-Tiny, which was good enough as a starting point, and small enough
I could bundle it as a git subtree. Perl is nicely fast to start up
(nailing-cargo --- true runs in about 170ms on my
laptop), and it is easy to write a Perl script that will work on
pretty much any Perl installation.
Still unsolved: embedding cargo in another build system
A number of my projects contain a mixture of Rust code with other
languages. Unfortunately, nailing-cargo doesn't help with the
problems which arise trying to integrate cargo into another build
system.
I generally resort to find runes for finding Rust source
files that might influence cargo, and stamp files for seeing if I have
run it recently enough; and I simply live with the fact that cargo
sometimes builds more stuff than I needed it to.
Future
There are a number of ways nailing-cargo could be improved.
Notably, the need to overwrite your actual Cargo.toml is
very annoying, even if nailing-cargo puts it back afterwards.
A big problem with this is that it means that
nailing-cargo has to take a lock, while your cargo rune runs.
This effectively prevents using nailing-cargo with long-running
processes. Notably, editor integrations like rls and racer.
I could perhaps solve this with more linkfarm-juggling, but that
wouldn't help in-tree builds and it's hard to keep things up to date.
I am considering using
LD_PRELOAD trickery or maybe bwrap(1) to "implement"
the alternative Cargo.toml feature which was
rejected by cargo upstream in 2019
(and
again in April
when someone else asked).
Currently there is no support for using sudo for
out-of-tree privsep. This should be easy to add but it needs someone
who uses sudo to want it (and to test it!)
The documentation has some other
dicusssion of limitations, some of
which aren't too hard to improve.
Patches welcome!
Serapio has been crafted and trained to be the vessel for a god. He grew
up in Obregi land, far from his ancestral home, but he will return to Tova
at the appropriate time and carry the hopes of the Carrion Crow clan with
him.
Xiala is a ship captain, a woman, and a Teek. That means she's a target.
Teek have magic, which makes them uncanny and dangerous. They're also
said to carry that magic in their bones, which makes them valuable in ways
that are not pleasant for the Teek. Running afoul of the moral codes of
Cuecola is therefore even more dangerous to her than it would be to
others, which is why she accepts a bargain to run errands for a local lord
for twelve years, paid at the end of that time with ownership of a ship
and crew. The first task: ferry a strange man to the city of Tova.
Meanwhile, in Tova, the priestess Naranpa has clawed her way to the top of
the Sky Made hierarchy from an inauspicious beginning in the poor district
of Coyote's Maw. She's ruthlessly separated herself from her despised
beginnings and focused her attention on calming Tova in advance of the
convergence, a rare astronomical alignment at the same time as the winter
solstice. But Carrion Crow holds a deep-seated grudge at their slaughter
by the priesthood during the Night of Knives, and Naranpa's position atop
the religious order that partly rules Tova's fractious politics is more
precarious than she thinks.
I am delighted that more fantasy is drawing on mythologies and histories
other than the genre default of western European. It's long overdue for
numerous reasons and a trend to be rewarded. But do authors writing
fantasy in English who reach for Mesoamerican cultures have to gleefully
embrace the excuse to add more torture? I'm developing an aversion to
this setting (which I do not want to do!) because every book seems to
feature human sacrifice, dismemberment, or some other horror show.
Roanhorse at least does not fill the book with that (there's lingering
child abuse but nothing as sickening as the first chapter), but that makes
the authorial choice to make the torture one's first impression of this
book even odder. Our introduction to Serapio is a scene that I would have
preferred to have never read, and I don't think it even adds much to the
plot. Huge warnings for people who don't want to read about a mother
torturing her son, or about eyes in that context.
Once past that introduction, Black Sun settles into a two-thread
fantasy, one following Xiala and Serapio's sea voyage and the other
following Naranpa and the political machinations in Tova. Both the magic
systems and the political systems are different enough to be refreshing,
and there are a few bits of world-building I enjoyed (a city built on top
of rocks separated by deep canyons and connected with bridges, giant
intelligent riding crows, everything about the Teek). My problem was that
I didn't care what happened to any of the characters. Naranpa spends most
of the book dithering and whining despite a backstory that should have
promised more dynamic and decisive responses. The other character from
Tova introduced somewhat later in the book is clearly "character whose
story will appear in the next volume"; here, he's just station-keeping and
representing the status quo. And while it's realistic given the plot that
Serapio is an abused sociopath, that didn't mean I enjoyed reading his
viewpoint or his childhood abuse.
Xiala is the best character in the book by far and I was warming to the
careful work she has to do to win over an unknown crew, but apparently
Roanhorse was not interested in that. Instead, the focus of Xiala's
characterization turns to a bad-boy romance that did absolutely nothing
for me. This will be a matter of personal taste; I know this is a plot
feature for many readers. But it had me rolling my eyes and turning the
pages to get to something more interesting (which, sadly, was not
forthcoming). It also plays heavily on magical disabled person cliches,
like the blind man being the best fighter anyone has met.
I did not enjoy this book very much, but there were some neat bits of
world-building and I could see why other people might disagree. What
pushed me into actively recommending against it (at least for now) is the
publishing structure.
This is the first book of a trilogy, so one can expect the major plot to
not be resolved by the end of the book. But part of the contract with the
reader when publishing a book series is that each volume should reach some
sense of closure and catharsis. There will be cliffhangers and unanswered
questions, but there should also be enough plot lines that are
satisfactorily resolved to warrant publishing a book as a separate novel.
There is none of that here. This is the first half (or third) of a novel.
It introduces a bunch of plot lines, pulls them together, describes an
intermediate crisis, and then simply stops. Not a single plot line is
resolved. This is made worse by the fact this series (presumably, as I
have only seen the first book) has a U-shaped plot: everything gets worse
and worse until some point of crisis, and then presumably the protagonists
will get their shit together and things will start to improve. I have
soured on U-shaped plots since the first half of the story often feels
like a tedious grind (eat your vegetables and then you can have dessert),
but it's made much worse by cutting the book off at the bottom of the U.
You get a volume, like Black Sun, that's all setup and horror and
collapse, with no payoff or optimism.
After two tries, I have concluded that Roanhorse is not for me. This is
clearly a me problem rather than a Roanhorse problem, given how many other
people love both Black Sun and her Sixth
World series, but this is the second book of hers where I mildly enjoyed
the world building but didn't care about any of the characters. Ah well,
tastes will differ. Even if you get along with Roanhorse, though, I
recommend against starting this book until the second half of it is
published (currently scheduled for 2022). As it stands, it's a wholly
unsatisfying reading experience.
Followed by the not-yet-published Fevered Star.
Rating: 4 out of 10
28 today. In a video call for Debian day earlier on, I was reminiscing about the earliest distributions: MCC Interim Linux gave instructions to turn it's final version into Debian. Debian is the second oldest Linux distribution, just behind Slackware.Debian 1.2 was my first Debian: my latest is, obviously, Debian Bullseye. Debian is like a family - often discordant, sometimes dysfunctional but always full of people that care and are cared for. I wish that some of my friends and colleagues no longer with us could be here to see just how well we're doing.This is something that's been with me for so long that I can't imagine life without it: software, obscure hardware but above all friends closer than family. The biggest software project anywhere, potentially, and it's all for free - and 95.7% independently reproducible. Thanks to all my colleagues and co-workers who've become friends over the years without whom none of this would be possible. Oh, and thanks to Ian Murdock - I never got to meet him but I did get to email him when he was in charge of Progeny. Without him, none of this would even have started.
I first started using 
One of the technologies that was created by DFINITY as we built the Internet Computer is Candid. Candid is
Aug 28, 2021, I gave a short 
The 
That means about 2300 packages updated, and about 4000 unchanged.
Or 5100 packages updated and 2100 for which there was nothing to do, i.e. no upstream commits since the last Debian upload.
As can be seen, this works for a surprising fraction of packages. It s possible to get the numbers up even higher, by both improving the tooling, the autopkgtests and the metadata that is provided by packages.
DebConf21 is taking place online, from 24 August to 28 August 2021.
It is the 22nd Debian conference, and organizers and participants are working hard
together at creating interesting and fruitful events.
We would like to warmly welcome the 19 sponsors of DebConf21, and introduce them to you.
We have five Platinum sponsors.
Our first Platinum sponsor is 
I have been using the GIMP since about 20 years or so, but recently started to also work with Krita since I found it quite nice to work with (besides the text module, which is a pain).
As there came out the first beta of Krita 5, I decided to throw it into my 
Debian Bullseye
As mentioned previously, the now released Debian/Bullseye contains KDE Frameworks 5.78, including several backports of fixes from 5.79 to get smooth operation. Plasma 5.20.5, again with several cherry picks for bugs will be in Bullseye, too. The KDE/Apps are mostly at 20.12 level, and the KDE PIM group packages (akonadi, kmail, etc) are at 20.08.
Debian unstable (and in time also testing)
Frameworks 5.83 and Plasma 5.21.5 have been uploaded to unstable. This is a temporary measure until several necessary packages have cleared the NEW queue. After that we will upload frameworks 5.85 and Plasma 5.22.N.
KDE Gears is still at 20.08, but we have 21.04 in experimental, and I am currently preparing to upload 21.08.0, should be done soon.
OBS packages
The OBS packages as usual follow the latest release, and currently ship KDE Frameworks 5.85, KDE Gears 21.08.0, and Plasma 5.22.4. The package sources are as usual (note the different path for the Plasma packages and the apps packages, containing the release version!), for Debian/unstable: