The Faithless is the second book in a political fantasy series that
seems likely to be a trilogy. It is a direct sequel to
The Unbroken, which you should read
first. As usual, Orbit made it unnecessarily hard to get re-immersed in
the world by refusing to provide memory aids for readers who read books as
they come out instead of only when the series is complete, but this is not
the fault of Clark or the book and you've heard me rant about this before.
The Unbroken was set in Qaz l (not-Algeria). The Faithless,
as readers of the first book might guess from the title, is set in
Balladaire (not-France). This is the palace intrigue book. Princess Luca
is fighting for her throne against her uncle, the regent. Touraine is
trying to represent her people. Whether and to what extent those
interests are aligned is much of the meat of this book.
Normally I enjoy palace intrigue novels for the competence porn: watching
someone navigate a complex political situation with skill and cunning, or
upend the entire system by building unlikely coalitions or using
unexpected routes to power. If you are similar, be warned that this is
not what you're going to get. Touraine is a fish out of water with no
idea how to navigate the Balladairan court, and does not magically become
an expert in the course of this novel. Luca has the knowledge, but she's
unsure, conflicted, and largely out-maneuvered. That means you will have
to brace for some painful scenes of some of the worst people apparently
getting what they want.
Despite that, I could not put this down. It was infuriating, frustrating,
and a much slower burn than I prefer, but the layers of complex
motivations that Clark builds up provided a different sort of payoff.
Two books in, the shape of this series is becoming clearer. This series
is about empire and colonialism, but with considerably more complexity
than fantasy normally brings to that topic. Power does not loosen its
grasp easily, and it has numerous tools for subtle punishment after
apparent upstart victories. Righteous causes rarely call banners to your
side; instead, they create opportunities for other people to maneuver to
their own advantage. Touraine has some amount of power now, but it's far
from obvious how to use it. Her life's training tells her that exercising
power will only cause trouble, and her enemies are more than happy to
reinforce that message at every opportunity.
Most notable to me is Clark's bitingly honest portrayal of the supposed
allies within the colonial power. It is clear that Luca is attempting to
take the most ethical actions as she defines them, but it's remarkable how
those efforts inevitably imply that Touraine should help Luca now in
exchange for Luca's tenuous and less-defined possible future aid. This is
not even a lie; it may be an accurate summary of Balladairan politics.
And yet, somehow what Balladaire needs always matters more than the needs
of their abused colony.
Underscoring this, Clark introduces another faction in the form of a
populist movement against the Balladairan monarchy. The details of that
setup in another fantasy novel would make them allies of the Qaz l. Here,
as is so often the case in real life, a substantial portion of the
populists are even more xenophobic and racist than the nobility. There
are no easy alliances.
The trump card that Qaz l holds is magic. They have it, and (for reasons
explored in The Unbroken) Balladaire needs it, although that is a
position held by Luca's faction and not by her uncle. But even Luca wants
to reduce that magic to a manageable technology, like any other element of
the Balladairan state. She wants to understand it, harness it, and bring
it under local control. Touraine, trained by Balladaire and facing
Balladairan political problems, has the same tendency. The magic, at
least in this book, refuses not in the flashy, rebellious way that it
would in most fantasy, but in a frustrating and incomprehensible lack of
predictable or convenient rules. I think this will feel like a plot
device to some readers, and that is to some extent true, but I think I see
glimmers of Clark setting up a conflict of world views that will play out
in the third book.
I think some people are going to bounce off this book. It's frustrating,
enraging, at times melodramatic, and does not offer the cathartic payoff
typically offered in fantasy novels of this type. Usually these are
things I would be complaining about as well. And yet, I found it
satisfyingly challenging, engrossing, and memorable. I spent a lot of the
book yelling "just kill him already" at the characters, but I think one of
Clark's points is that overcoming colonial relationships requires a lot
more than just killing one evil man. The characters profoundly fail to
execute some clever and victorious strategy. Instead, as in the first
book, they muddle through, making the best choice that they can see in
each moment, making lots of mistakes, and paying heavy prices. It's
realistic in a way that has nothing to do with blood or violence or
grittiness. (Although I did appreciate having the thin thread of Pruett's
story and its highly satisfying conclusion.)
This is also a slow-burn romance, and there too I think opinions will
differ. Touraine and Luca keep circling back to the same arguments and
the same frustrations, and there were times that this felt repetitive. It
also adds a lot of personal drama to the politics in a way that
occasionally made me dubious. But here too, I think Clark is partly using
the romance to illustrate the deeper political points.
Luca is often insufferable, cruel and ambitious in ways she doesn't
realize, and only vaguely able to understand the Qaz l perspective; in
short, she's the pragmatic centrist reformer. I am dubious that her
ethics would lead her to anything other than endless compromise without
Touraine to push her. To Luca's credit, she also realizes that and wants
to be a better person, but struggles to have the courage to act on it.
Touraine both does and does not want to manipulate her; she wants Luca's
help (and more), but it's not clear Luca will give it under acceptable
terms, or even understand how much she's demanding. It's that
foundational conflict that turns the romance into a slow burn by pushing
them apart. Apparently I have more patience for this type of on-again,
off-again relationship than one based on artificial miscommunication.
The more I noticed the political subtext, the more engaging I found the
romance on the surface.
I picked this up because I'd read several books about black characters
written by white authors, and while there was nothing that wrong with
those books, the politics felt a little too reductionist and simplified.
I wanted a book that was going to force me out of comfortable political
assumptions. The Faithless did exactly what I was looking for, and
I am definitely here for the rest of the series. In that sense,
recommended, although do not go into this book hoping for adroit court
maneuvering and competence porn.
Followed by The Sovereign, which does not yet have a release date.
Content warnings: Child death, attempted cultural genocide.
Rating: 7 out of 10
It was 2013, and I was on a break from work between Christmas and New Year of
2013. I had been working at Linaro for well over a year, on the LAVA
project. I was living and breathing automated testing infrastructure,
mostly for testing low-level components such as kernels and bootloaders, on
real hardware.
At this point I was also a Debian contributor for quite some years, and had
become an official project members two years prior. Most of my involvement was
in the Ruby team, where we were already consistently running upstream test
suites during package builds.
During that break, I put these two contexts together, and came to the
conclusion that Debian needed a dedicated service that would test the contents
of the Debian archive. I was aware of the existance of
autopkgtest, and started working on a very simple service that
would later become Debian CI.
In January 2014, debci was initially announced on that month's Misc
Developer News, and later uploaded to Debian. It's been
continuously developed for the last 10 years, evolved from a single shell
script running tests in a loop into a distributed system with 47
geographically-distributed machines as of writing this piece, became part of
the official Debian release process gating migrations to testing, had 5 Summer
of Code and Outrechy interns working on it, and processed beyond 40 million
test runs.
In there years, Debian CI has received contributions from a lot of people, but
I would like to give special credits to the following:
Ian Jackson - created autopkgtest.
Martin Pitt - was the maintainer of autopkgtest when Debian CI launched and
helped a lot for some time.
Paul Gevers - decided that he wanted Debian CI test runs to control testing
migration. While at it, became a member of the Debian Release Team and the
other half of the permanent Debian CI team together with me.
Lucas Kanashiro - Google Summer of Code intern, 2014.
Brandon Fairchild - Google Summer of Code intern, 2014.
Candy Tsai - Outreachy intern, 2019.
Pavit Kaur - Google Summer of Code intern, 2021
Abiola Ajadi - Outreachy intern, December 2021-2022.
Em 2023 o tradicional Debian Day est
sendo celebrado de forma especial, afinal no dia 16 de agostoo Debian completou
30 anos!
Para comemorar este marco especial na vida do Debian, a
comunidade Debian Brasil organizou uma semana
de palestras online de 14 a 18 de agosto. O evento foi chamado de
Debian 30 anos.
Foram realizadas 2 palestras por noite, das 19h s 22h, transmitidas pelo canal
Debian Brasil no YouTube
totalizando 10 palestras. As grava es j est o dispon veis tamb m no canal
Debian Brasil no Peertube.
Nas 10 atividades tivemos as participa es de 9 DDs, 1 DM, 3 contribuidores(as).
A audi ncia ao vivo variou bastante, e o pico foi na palestra sobre preseed com
o Eriberto Mota quando tivemos 47 pessoas assistindo.
Obrigado a todos(as) participantes pela contribui o que voc s deram para o
sucesso do nosso evento.
Antonio Terceiro
Aquila Macedo
Charles Melara
Daniel Lenharo de Souza
David Polverari
Eriberto Mota
Giovani Ferreira
Jefferson Maier
Lucas Kanashiro
Paulo Henrique de Lima Santana
Sergio Durigan Junior
Thais Araujo
Thiago Andrade
Veja abaixo as fotos de cada atividade:
Nova gera o: uma entrevista com iniciantes no projeto Debian
Instala o personalizada e automatizada do Debian com preseed
Manipulando patches com git-buildpackage
debian.social: Socializando Debian do jeito Debian
Proxy reverso com WireGuard
Celebra o dos 30 anos do Debian!
Instalando o Debian em disco criptografado com LUKS
O que a equipe de localiza o j conquistou nesses 30 anos
Debian - Projeto e Comunidade!
Design Gr fico e Software livre, o que fazer e por onde come ar
In 2023 the traditional Debian Day is
being celebrated in a special way, after all on August 16th Debian turned 30
years old!
To celebrate this special milestone in the Debian's life, the
Debian Brasil community organized a week with
talks online from August 14th to 18th. The event was named
Debian 30 years.
Two talks were held per night, from 7:00 pm to 10:00 pm, streamed on the
Debian Brasil channel on YouTube
totaling 10 talks. The recordings are also available on the
Debian Brazil channel on Peertube.
We had the participation of 9 DDs, 1 DM, 3 contributors in 10 activities.
The live audience varied a lot, and the peak was on the preseed talk with
Eriberto Mota when we had 47 people watching.
Thank you to all participants for the contribution you made to the success of
our event.
Antonio Terceiro
Aquila Macedo
Charles Melara
Daniel Lenharo de Souza
David Polverari
Eriberto Mota
Giovani Ferreira
Jefferson Maier
Lucas Kanashiro
Paulo Henrique de Lima Santana
Sergio Durigan Junior
Thais Araujo
Thiago Andrade
Veja abaixo as fotos de cada atividade:
Nova gera o: uma entrevista com iniciantes no projeto Debian
Instala o personalizada e automatizada do Debian com preseed
Manipulando patches com git-buildpackage
debian.social: Socializando Debian do jeito Debian
Proxy reverso com WireGuard
Celebra o dos 30 anos do Debian!
Instalando o Debian em disco criptografado com LUKS
O que a equipe de localiza o j conquistou nesses 30 anos
Debian - Projeto e Comunidade!
Design Gr fico e Software livre, o que fazer e por onde come ar
DEP-17 progress, by Helmut and Emilio
We posted a proposal for modifying dpkg to better cope with directory aliasing.
After an initial period of silence, the discussion took off, but was mostly
diverted to a competing proposal by Luca Boccassi: Do not change dpkg at all,
but still move all files affected by aliasing to their canonical location and
thus removing the bad effects of aliasing. We facilitated this discussion and
performed extensive analysis of this and competing proposals highlighting
resulting problems and proposing solutions or workarounds. We performed a
detailed analysis of how aliasing affects usage of dpkg-divert,
dpkg-statoverride and update-alternatives. Details are available on the
debian-dpkg mailinglist thread.
Debian Reimbursements Web App Progress, by Stefano Rivera
In a project funded by
Freexian s Project Funding initiative,
Stefano made some more progress on the
Debian Reimbursements Web App.
The full workflow can now be exercised, completing the first milestone of the
project, the Working Prototype.
Stefano attended several DebConf planning meetings, and did some work on the
DebConf 23 website.
Stefano updated distro-info-data to include the release date of Debian
bullseye, and added the next Ubuntu release, Mantic Minotour. This required a
round of updates to all the stable releases, LTS, and ELTS.
Helmut sent patches for 13 cross build failures and filed 104 RC bugs for
missing Breaks and Replaces.
Core Python Packages, by Stefano Rivera
Just before the freeze, pip added support for PEP-668.
This is a scheme devised by Debian with other distributions and the Python
Packaging Authority, to allow distributors to mark Python installations as
being managed by a distribution package manager. When this EXTERNALLY-MANAGED
flag is present, installers like pip will refuse to install packages outside
a virtual environment. This protects users from breaking unrelated software
on their systems, when installing packages with pip or similar tools. Stefano
quickly got this version of pip into the archive, marked Debian s Python
interpreters as EXTERNALLY-MANAGED, and worked with the upstream to add a
mechanism to allow users to override the restriction. Debian bookworm will
likely be the first distro release to implement this change.
The transition from Python 3.10 to 3.11 was one of the last to complete before
the bookworm freeze (as 3.11 only released at the end of October 2022). Stefano
helped port some Python packages to 3.11, in January, and also kicked off the
final transition to remove Python 3.10 support.
Stefano did a big round of bug triage in the cPython interpreter (and related)
packages, applying some provided patches, and fixing some long-standing minor
bugs in the packaging.
To allow Debian packages to more accurately reflect upstream-specified
dependencies that only apply under specific Python interpreter versions, in the
future, Stefano
added more metadata
to the python3 binary package.
Python s unittest runner would successfully exit with 0 passed tests, if it
couldn t find any tests. This means that configuration / layout changes can
cause test failures to go unnoticed, because the tests aren t being run any
more in Debian packages. Stefano
proposed a change to Python
3.12 to change this behavior and treat 0 tests as a kind of failure.
debvm, by Helmut Grohne
With support from Johannes Schauer Marin Rodrigues, and Jochen Sprickerhof,
Helmut Grohne wrote debvm, a tool for
quickly creating and running Debian virtual machine images for various
architectures and Debian and Ubuntu releases. This is meant for development
and testing purposes and has already identified a number of bugs in e.g.
fakechroot (#1029490), Linux
(#1029270), and runit
(#1028181).
Rails 6 and Redmine 5 available in bullseye-backports, by Utkarsh Gupta
Bullseye users can now upgrade to the latest 6.1 branch of Rails, v6.1.7, and
the latest Redmine version, v5.0.4. The Ruby team received numerous requests
to backport the latest version of Rails and Redmine, especially since there was
no redmine shipped in the bullseye release itself. So this is big news for all
users as we ve not only successfully backported both the packages, but also
fixed all the CVEs and RC bugs in the process!
This work was sponsored by Entrouvert.
Patches metadata in the Package Tracker, by Rapha l Hertzog
Building on the great Ultimate Debian Database work of Lucas Nussbaum and on
his suggestion, Rapha l enhanced the
Debian Package Tracker to display action items
when the patches metadata indicate that some patches were not forwarded
upstream, or when the metadata were invalid. One can now also browse the
patches metadata from the Links panel on the right.
Fixed kernel bug that broke debian-installer on computers with Mediatek wifi devices, by Helmut Grohne
As part of our regular work on Kali Linux for OffSec,
they funded Helmut s work to fix the MT7921e driver. When being loaded without
firmware available, it would not register itself, but upon module release it
would unregister itself causing a kernel oops.
This was commonly observed in Kali Linux when reloading the module to add
firmware. Helmut Grohne identified the cause and
sent a patch, a
different variant of which is now
heading into Linux
and available from Kali Linux.
Printing in Debian, by Thorsten Alteholz
There are about 40 packages in Debian that take care of sending output to
printers, scan documents, or even send documents to fax machines. In the light
of the upcoming/already ongoing freeze, these packages had to be updated to
the latest version and bugs had to be fixed. Basically this applies to large
packages like cups, cups-filters, hplip but also the smaller ones that
shouldn t be neglected. All in all Thorsten uploaded 13 packages with new
upstream versions or improved packaging and could resolve 14 bugs. Further
triaging led to 35 bugs that could be closed, either because they were already
fixed and not closed in an earlier upload or they could not be reproduced with
current software versions.
There is also work to do to prepare for the future. Historically, printing on
Linux required finding a PPD file for your printer and finding some software
that is able to render your documents with this PPD. These days, driverless
printing is becoming more common and the use of PPD files has decreased.
In the upcoming version 3.0 of cups, PPD files are no longer supported and so
called printer applications need to be used. In order not to lose the ability
to print documents, this big transition needs to be carefully planned. This
started in the beginning of 2023 and will hopefully be finished with the
release of Debian Trixie. More information can be found in
this Debian Printing Wiki article.
In preparation for this transition Thorsten created three new packages.
Yade update, by Anton Gladky
Last month, Anton updated the yade package to the newest 2023.02a version,
which includes new features.
Yade is a software package for discrete element method (DEM) simulations, which
are widely used in scientific and engineering fields for the simulation of
granular systems. Yade is an open-source project that is being used worldwide
for different tasks, such as geomechanics, civil engineering, mining, and
materials science.
The Yade package in Debian supports different precision levels for its
simulations. This means that researchers and engineers can select the needed
precision level without recompiling the package, saving time and effort.
Miscellaneous contributions
Helmut Grohne continues to improve cross building (mostly Qt) and
architecture bootstrap (mostly loong64 and musl).
With the end of the year approaching fast, I thought putting my year in
retrospective via music would be a fun thing to do.
Albums
In 2022, I added 51 new albums to my collection nearly one a week! I listed
them below in the order in which I acquired them.
I purchased most of these albums when I could and borrowed the rest at
libraries. If you want to browse though, I added links to the album covers
pointing either to websites where you can buy them or to Discogs when digital
copies weren't available1.
Browsing through the albums, I can see my tastes really shifted a lot in the
last few years. I used to listen to a lot of Hip-Hop, but the recent trends in
this genre2 really turn me off. In fact, it seems I didn't add a single
Hip-Hop album to my collection this year...
Metal also continues to dominate the list. Many thanks to Angry Metal
Guy for being the best metal reviewing website out there.
Concerts
2022 was also a big change for me, as I started going to much more concerts than
I previously did. metalfinder has been working great and I'm really happy
with it.
Here are the concerts I went to in 2022:
April 26th: Arch Enemy, Unto Others, Behemoth, Napalm Death
September 16th: NOFX
November 4th: Aeternam
November 7th: Jordi Savall & Hesp rion XXI
November 13th: VOLA
November 19th: Vulgaires Machins, Anti-Flag
November 26th: Soen
December 12h: Oddisee
December 16th: Jail, B ton Arm , Reckless Upstarts, Union Thugs, La Gachette
I'm looking forward continuing to go to a lot of concerts in 2023!
Some of the albums especially the O ! ones are pretty
underground. For most of those, I actually have physical copies I bought
and ripped.
Mostly mumble rap, beats than are less and less sample-based,
extreme commercialisation and lyrics that are less and less political and
engaged.
The Unbroken is the first book of a projected fantasy trilogy. It
is C.L. Clark's first novel.
Lieutenant Touraine is one of the Sands, the derogatory name for the
Balladairan Colonial Brigade. She, like the others of her squad, are
conscript soldiers, kidnapped by the Balladairan Empire from their
colonies as children and beaten into "civilized" behavior by Balladairan
training. They fought in the Balladairan war against the Taargens. Now,
they've been reassigned to El-Wast, capital city of Qaz l, the foremost of
the southern colonies. The place where Touraine was born, from which she
was taken at the age of five.
Balladaire is not France and Qaz l is not Algeria, but the parallels are
obvious and strongly implied by the map and the climates.
Touraine and her squad are part of the forces accompanying Princess Luca,
the crown princess of the Balladairan Empire, who has been sent to take
charge of Qaz l and quell a rebellion. Luca's parents died in the
Withering, the latest round of a recurrent plague that haunts Balladaire.
She is the rightful heir, but her uncle rules as regent and is reluctant
to give her the throne. Qaz l is where she is to prove herself. If she
can bring the colony in line, she can prove that she's ready to rule: her
birthright and her destiny.
The Qaz li are uninterested in being part of Luca's grand plan of personal
accomplishment. She steps off her ship into an assassination attempt,
foiled by Touraine's sharp eyes and quick reactions, which brings the Sand
to the princess's attention. Touraine's reward is to be assigned the
execution of the captured rebels, one of whom recognizes her and names her
mother before he dies. This sets up the core of the plot: Qaz li
rebellion against an oppressive colonial empire, Luca's attempt to use the
colony as a political stepping stone, and Touraine caught in between.
One of the reasons why I am happy to see increased diversity in SFF
authors is that the way we tell stories is shaped by our cultural
upbringing. I was taught to tell stories about colonialism and rebellion
in a specific ideological shape. It's hard to describe briefly, but the
core idea is that being under the rule of someone else is unnatural as
well as being an injustice. It's a deviation from the way the world
should work, something unexpected that is inherently unstable. Once
people unite to overthrow their oppressors, eventual success is
inevitable; it's not only right or moral, it's the natural path of
history. This is what you get when you try to peel the supremacy part
away from white supremacy but leave the unshakable self-confidence and
bedrock assumption that the universe cares what we think.
We were also taught that rebellion is primarily ideological. One may be
motivated by personal injustice, but the correct use of that injustice is
to subsume it into concepts such as freedom and democracy. Those concepts
are more "real" in some foundational sense, more central to the right
functioning of the world, than individual circumstance. When the
now-dominant group tells stories of long-ago revolution, there is no
personal experience of oppression and survival in which to ground the
story; instead, it's linked to anticipatory fear in the reader, to the
idea that one's privileges could be taken away by a foreign oppressor and
that the counter to this threat is ideological unity.
Obviously, not every white fantasy author uses this story shape, but the
tendency runs deep because we're taught it young. You can see it
everywhere in fantasy, from Lord of the Rings to
Tigana. The Unbroken uses a much
different story shape, and I don't think it's a coincidence that the
author is Black.
Touraine is not sympathetic to the Qaz li. These are not her people and
this is not her life. She went through hell in Balladairan schools, but
she won a place, however tenuous. Her personal role model is General
Cantic, the Balladairan Blood General who was also one of her instructors.
Cantic is hard as nails, unforgiving, unbending, and probably a war
criminal, but also the embodiment of a military ethic. She is tough but
fair with the conscript soldiers. She doesn't put a stop to their
harassment by the regular Balladairan troops, but neither does she let it
go too far. Cantic has power, she knows how to keep it, and there is a
place for Touraine in Cantic's world.
And, critically, that place is not just hers: it's one she shares with her
squad. Touraine's primary loyalty is not to Balladaire or to Qaz l. It's
to the Sands. Her soldiers are neither one thing nor the other, and they
disagree vehemently among themselves about what Qaz l and their other
colonial homes should be to them, but they learned together, fought
together, and died together. That theme is woven throughout The
Unbroken: personal bonds, third and fourth loyalties, and practical
ethics of survival that complicate and contradict simple dichotomies of
oppressor and oppressed.
Touraine is repeatedly offered ideological motives that the protagonist in
the typical story shape would adopt. And she repeatedly rejects them for
personal bonds: trying to keep her people safe, in a world that is not
looking out for them.
The consequence is that this book tears Touraine apart. She tries to walk
a precarious path between Luca, the Qaz li, Cantic, and the Sands, and she
falls off that path a lot. Each time I thought I knew where this book was
going, there's another reversal, often brutal. I tend to be a
happily-ever-after reader who wants the protagonist to get everything they
need, so this isn't my normal fare. The amount of hell that Touraine goes
through made for difficult reading, worse because much of it is due to her
own mistakes or betrayals. But Clark makes those decisions believable
given the impossible position Touraine is in and the lack of role models
she has for making other choices. She's set up to fail, and the price of
small victories is to have no one understand the decisions that she makes,
or to believe her motives.
Luca is the other viewpoint character of the book (and yes, this is also a
love affair, which complicates both of their loyalties). She is the
heroine of a more typical genre fantasy novel: the outsider princess with
a physical disability and a razor-sharp mind, ambitious but fair (at least
in her own mind), with a trusted bodyguard advisor who also knew her
father and a sincere desire to be kinder and more even-handed in her
governance of the colony. All of this is real; Luca is a protagonist, and
the reader is not being set up to dislike her. But compared to Touraine's
grappling with identity, loyalty, and ethics, Luca is never in any real
danger, and her concerns start to feel too calculated and superficial.
It's hard to be seriously invested in whether Luca proves herself or gets
her throne when people are being slaughtered and abused.
This, I think, is the best part of this book. Clark tells a traditional
ideological fantasy of learning to be a good ruler, but she puts it
alongside a much deeper and more complex story of multi-faceted
oppression. She has the two protagonists fall in love with each other and
challenges them to understand each other, and Luca does not come off well
in this comparison. Touraine is frustrated, impulsive, physical, and
sometimes has catastrophically poor judgment. Luca is analytical and
calculating, and in most ways understands the political dynamics far
better than Touraine. We know how this story usually goes: Luca sees
Touraine's brilliance and lifts her out of the ranks into a role of
importance and influence, which Touraine should reward with loyalty. But
Touraine's world is more real, more grounded, and more authentic, and both
Touraine and the reader know what Luca could offer is contingent and comes
with a higher price than Luca understands.
(Incidentally, the cover of The Unbroken, designed by Lauren
Panepinto with art by Tommy Arnold, is astonishingly good at capturing
both Touraine's character and the overall feeling of the book. Here's a
larger version.)
The writing is good but uneven. Clark loves reversals, and they did keep
me reading, but I think there were too many of them. By the end of the
book, the escalation of betrayals and setbacks was more exhausting than
exciting, and I'd stopped trusting anything good would last. (Admittedly,
this is an accurate reflection of how Touraine felt.) Touraine's inner
monologue also gets a bit repetitive when she's thrashing in the jaws of
an emotional trap. I think some of this is first-novel problems of
over-explaining emotional states and character reasoning, but these
problems combine to make the book feel a bit over-long.
I'm also not in love with the ending. It's perhaps the one place in the
book where I am more cynical about the politics than Clark is, although
she does lay the groundwork for it.
But this book is also full of places small and large where it goes a
different direction than most fantasy and is better for it. I think my
favorite small moment is Touraine's quiet refusal to defend herself
against certain insinuations. This is such a beautiful bit of
characterization; she knows she won't be believed anyway, and refuses to
demean herself by trying.
I'm not sure I can recommend this book unconditionally, since I think you
have to be in the mood for it, but it's one of the most thoughtful and
nuanced looks at colonialism and rebellion I can remember seeing in
fantasy. I found it frustrating in places, but I'm also still thinking
about it. If you're looking for a political fantasy with teeth, you could
do a lot worse, although expect to come out the other side a bit battered
and bruised.
Followed by The Faithless, and I have no idea where Clark is going
to go with the second book. I suppose I'll have to read and find out.
Content note: In addition to a lot of violence, gore, and death, including
significant character death, there's also a major plague. If you're not
feeling up to reading about panic caused by contageous illness, proceed
with caution.
Rating: 7 out of 10
Welcome to the Reproducible Builds report for October 2022! In these reports we attempt to outline the most important things that we have been up to over the past month.
As ever, if you are interested in contributing to the project, please visit our Contribute page on our website.
Our in-person summit this year was held in the past few days in Venice, Italy. Activity and news from the summit will therefore be covered in next month s report!
A new article related to reproducible builds was recently published in the 2023 IEEE Symposium on Security and Privacy. Titled Taxonomy of Attacks on Open-Source Software Supply Chains and authored by Piergiorgio Ladisa, Henrik Plate, Matias Martinez and Olivier Barais, their paper:
[ ] proposes a general taxonomy for attacks on opensource supply chains, independent of specific programming languages or ecosystems, and covering all supply chain stages from code contributions to package distribution.
Taking the form of an attack tree, the paper covers 107 unique vectors linked to 94 real world supply-chain incidents which is then mapped to 33 mitigating safeguards including, of course, reproducible builds:
Reproducible Builds received a very high utility rating (5) from 10 participants (58.8%), but also a high-cost rating (4 or 5) from 12 (70.6%). One expert commented that a reproducible build like used by Solarwinds now, is a good measure against tampering with a single build system and another claimed this is going to be the single, biggest barrier .
[ ] illustrate a concerning new reality for the software industry and illuminates the increasingly sophisticated threats made by outside nation-states to the supply chains and infrastructure on which we all rely.
The 12-month anniversary of the 2020 Solarwinds attack (which SolarWinds Worldwide LLC itself calls the SUNBURST attack) was, of course, the likely impetus for publication.
Whilst collaborating on making the Cyrus IMAP server reproducible, Ellie Timoney asked why the Reproducible Builds testing framework uses two remarkably distinctive build paths when attempting to flush out builds that vary on the absolute system path in which they were built. In the case of the Cyrus IMAP server, these happened to be:
Arch Linux contributor kpcyrd wrote to our list this month with the news that multiple people in Arch Linux noticed the output of our git archive command doesn t match the tarball served by GitHub anymore. In his post, kpcyrd narrows the change to a specific commit in Git. []
Akihiro Suda wrote to a share a new tool called repro-get. According to Akihiro s post, repro-get is a tool to install a specific snapshot of apt/dnf/apk/pacman packages using SHA256SUMS files . This is needed in order to install specific (or pinned ) dependencies needed to validate a build.
Finally, Janneke Nieuwenhuizen announced the release of GNU Mes 0.24.1, which represents 23 commits over five months by four people. GNU Mes is a Scheme interpreter and C compiler for bootstrapping the GNU System. []
The Reproducible Builds project is delighted to welcome openEuler to the Involved projects page []. openEuler is Linux distribution developed by Huawei, a counterpart to it s more commercially-oriented EulerOS.
Debian
Colin Watson wrote about his experience towards making the databases generated by the man-db UNIX manual page indexing tool:
One of the people working on [reproducible builds] noticed that man-db s database files were an obstacle to [reproducibility]: in particular, the exact contents of the database seemed to depend on the order in which files were scanned when building it. The reporter proposed solving this by processing files in sorted order, but I wasn t keen on that approach: firstly because it would mean we could no longer process files in an order that makes it more efficient to read them all from disk (still valuable on rotational disks), but mostly because the differences seemed to point to other bugs.
Colin goes on to describe his approach to solving the problem, including fixing various fits of internal caching, and he ends his post with None of this is particularly glamorous work, but it paid off .
Vagrant Cascadian announced on our mailing list another online sprint to help clear the huge backlog of reproducible builds patches submitted by performing NMUs (Non-Maintainer Uploads). The first such sprint took place on September 22nd, but another was held on October 6th, and another small one on October 20th. This resulted in the following progress:
41 reviews of Debian packages were added, 62 were updated and 12 were removed this month adding to our knowledge about identified issues. A number of issue types were updated too. [1][]
Lastly, Luca Boccassi submitted a patch to debhelper, a set of tools used in the packaging of the majority of Debian packages. The patch addressed an issue in the dh_installsysusers utility so that the postinst post-installation script that debhelper generates the same data regardless of the underlying filesystem ordering.
Upstream patches
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:
diffoscopediffoscope is our in-depth and content-aware diff utility. Not only can it locate and diagnose reproducibility issues, it can provide human-readable diffs from many kinds of binary formats. This month, Chris Lamb prepared and uploaded versions 224 and 225 to Debian:
Add support for comparing the text content of HTML files using html2text. []
Add support for detecting ordering-only differences in XML files. []
Fix an issue with detecting ordering differences. []
Use the capitalised version of Ordering consistently everywhere in output. []
Add support for displaying font metadata using ttx(1) from the fonttools suite. []
Testsuite improvements:
Temporarily allow the stable-po pipeline to fail in the CI. []
Rename the order1.diff test fixture to json_expected_ordering_diff. []
Tidy the JSON tests. []
Use assert_diff over get_data and an manual assert within the XML tests. []
Drop the ALLOWED_TEST_FILES test; it was mostly just annoying. []
Tidy the tests/test_source.py file. []
Chris Lamb also added a link to diffoscope s OpenBSD packaging on the diffoscope.org homepage [] and Mattia Rizzolo fix an test failure that was occurring under with LLVM 15 [].
Testing framework
The Reproducible Builds project operates a comprehensive testing framework at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In October, the following changes were made by Holger Levsen:
Run the logparse tool to analyse results on the Debian Edu build logs. []
Install btop(1) on all nodes running Debian. []
Switch Arch Linux from using SHA1 to SHA256. []
When checking Debian debstrap jobs, correctly log the tool usage. []
Cleanup more task-related temporary directory names when testing Debian packages. [][]
Use the cdebootstrap-static binary for the 2nd runs of the cdebootstrap tests. []
Drop a workaround when testing OpenWrt and coreboot as the issue in diffoscope has now been fixed. []
Turn on an rm(1) warning into an info -level message. []
Special case the osuosl168 node for running Debian bookworm already. [][]
Use the new non-free-firmware suite on the o168 node. []
In addition, Mattia Rizzolo made the following changes:
Ensure that 2nd build has a merged /usr. []
Only reconfigure the usrmerge package on Debian bookworm and above. []
Fix bc(1) syntax in the computation of the percentage of unreproducible packages in the dashboard. [][][]
In the index_suite_ pages, order the package status to be the same order of the menu. []
Pass the --distribution parameter to the pbuilder utility. []
Finally, Roland Clobus continued his work on testing Live Debian images. In particular, he extended the maintenance script to warn when workspace directories cannot be deleted. []
If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
Desde de setembro de 2015, o
time de publicidade
do Projeto Debian passou a publicar a cada dois meses
listas com os nomes dos(as) novos(as)
Desenvolvedores(as) Debian (DD - do
ingl s Debian Developer) e
Mantenedores(as) Debian
(DM - do ingl s Debian Maintainer).
Estamos aproveitando estas listas para publicar abaixo os nomes dos(as)
brasileiros(as) que se tornaram Desenvolvedores(as) e Mantenedores(as) Debian a
partir de julho de 2015.
Desenvolvedores(as) Debian / Debian Developers / DDs:
Marcos Talau
Esta lista ser atualizada quando o time de publicidade do Debian publicar
novas listas com DMs e DDs e tiver brasileiros.
Para ver a lista completa de Mantenedores(as) e Desenvolvedores(as) Debian,
inclusive outros(as) brasileiros(as) antes de julho de 2015 acesse:
https://nm.debian.org/public/people
Desde de setembro de 2015, o
time de publicidade
do Projeto Debian passou a publicar a cada dois meses
listas com os nomes dos(as) novos(as)
Desenvolvedores(as) Debian (DD - do
ingl s Debian Developer) e
Mantenedores(as) Debian
(DM - do ingl s Debian Maintainer).
Estamos aproveitando estas listas para publicar abaixo os nomes dos(as)
brasileiros(as) que se tornaram Desenvolvedores(as) e Mantenedores(as) Debian a
partir de julho de 2015.
Desenvolvedores(as) Debian / Debian Developers / DDs:
Marcos Talau
Esta lista ser atualizada quando o time de publicidade do Debian publicar
novas listas com DMs e DDs e tiver brasileiros.
Para ver a lista completa de Mantenedores(as) e Desenvolvedores(as) Debian,
inclusive outros(as) brasileiros(as) antes de julho de 2015 acesse:
https://nm.debian.org/public/people
Welcome to the May 2022 report from the Reproducible Builds project. In our reports we outline the most important things that we have been up to over the past month. As ever, if you are interested in contributing to the project, please visit our Contribute page on our website.
Repfix paper
Zhilei Ren, Shiwei Sun, Jifeng Xuan, Xiaochen Li, Zhide Zhou and He Jiang have published an academic paper titled Automated Patching for Unreproducible Builds:
[..] fixing unreproducible build issues poses a set of challenges [..], among which we consider the localization granularity and the historical knowledge utilization as the most significant ones. To tackle these challenges, we propose a novel approach [called] RepFix that combines tracing-based fine-grained localization with history-based patch generation mechanisms.
The paper (PDF, 3.5MB) uses the Debian mylvmbackup package as an example to show how RepFix can automatically generate patches to make software build reproducibly. As it happens, Reiner Herrmann submitted a patch for the mylvmbackup package which has remained unapplied by the Debian package maintainer for over seven years, thus this paper inadvertently underscores that achieving reproducible builds will require both technical and social solutions.
Python variables
Johannes Schauer discovered a fascinating bug where simply naming your Python variable _m led to unreproducible .pyc files. In particular, the types module in Python 3.10 requires the following patch to make it reproducible:
Simply renaming the dummy method from _m to _b was enough to workaround the problem. Johannes bug report first led to a number of improvements in diffoscope to aid in dissecting .pyc files, but upstream identified this as caused by an issue surrounding interned strings and is being tracked in CPython bug #78274.
New SPDX team to incorporate build metadata in Software Bill of Materials
SPDX, the open standard for Software Bill of Materials (SBOM), is continuously developed by a number of teams and committees. However, SPDX has welcomed a new addition; a team dedicated to enhancing metadata about software builds, complementing reproducible builds in creating a more secure software supply chain. The SPDX Builds Team has been working throughout May to define the universal primitives shared by all build systems, including the who, what, where and how of builds:
Who: the identity of the person or organisation that controls the build infrastructure.
What: the inputs and outputs of a given build, combining metadata about the build s configuration with an SBOM describing source code and dependencies.
Where: the software packages making up the build system, from build orchestration tools such as Woodpecker CI and Tekton to language-specific tools.
How: the invocation of a build, linking metadata of a build to the identity of the person or automation tool that initiated it.
The SPDX Builds Team expects to have a usable data model by September, ready for inclusion in the SPDX 3.0 standard. The team welcomes new contributors, inviting those interested in joining to introduce themselves on the SPDX-Tech mailing list.
Supply-chain security attacks
This was another bumper month for supply-chain attacks in package repositories. Early in the month, Lance R. Vick noticed that the maintainer of the NPM foreach package let their personal email domain expire, so they bought it and now controls foreach on NPM and the 36,826 projects that depend on it . Shortly afterwards, Drew DeVault published a related blog post titled When will we learn? that offers a brief timeline of major incidents in this area and, not uncontroversially, suggests that the correct way to ship packages is with your distribution s package manager .
Bootstrapping
Bootstrapping is a process for building software tools progressively from a primitive compiler tool and source language up to a full Linux development environment with GCC, etc. This is important given the amount of trust we put in existing compiler binaries. This month, a bootstrappable mini-kernel was announced. Called boot2now, it comprises a series of compilers in the form of bootable machine images.
Google s new Assured Open Source Software service
Google Cloud (the division responsible for the Google Compute Engine) announced a new Assured Open Source Software service. Noting the considerable 650% year-over-year increase in cyberattacks aimed at open source suppliers, the new service claims to enable enterprise and public sector users of open source software to easily incorporate the same OSS packages that Google uses into their own developer workflows . The announcement goes on to enumerate that packages curated by the new service would be:
Regularly scanned, analyzed, and fuzz-tested for vulnerabilities.
Have corresponding enriched metadata incorporating Container/Artifact Analysis data.
Are built with Cloud Build including evidence of verifiable SLSA-compliance
Are verifiably signed by Google.
Are distributed from an Artifact Registry secured and protected by Google.
A retrospective on the Rust programming language
Andrew bunnie Huang published a long blog post this month promising a critical retrospective on the Rust programming language. Amongst many acute observations about the evolution of the language s syntax (etc.), the post beings to critique the languages approach to supply chain security ( Rust Has A Limited View of Supply Chain Security ) and reproducibility ( You Can t Reproduce Someone Else s Rust Build ):
There s some bugs open with the Rust maintainers to address reproducible builds, but with the number of issues they have to deal with in the language, I am not optimistic that this problem will be resolved anytime soon. Assuming the only driver of the unreproducibility is the inclusion of OS paths in the binary, one fix to this would be to re-configure our build system to run in some sort of a chroot environment or a virtual machine that fixes the paths in a way that almost anyone else could reproduce. I say almost anyone else because this fix would be OS-dependent, so we d be able to get reproducible builds under, for example, Linux, but it would not help Windows users where chroot environments are not a thing.
Reproducible Builds IRC meeting
The minutes and logs from our May 2022 IRC meeting have been published. In case you missed this one, our next IRC meeting will take place on Tuesday 28th June at 15:00 UTC on #reproducible-builds on the OFTC network.
A new tool to improve supply-chain security in Arch Linux
kpcyrd published yet another interesting tool related to reproducibility. Writing about the tool in a recent blog post, kpcyrd mentions that although many PKGBUILDs provide authentication in the context of signed Git tags (i.e. the ability to verify the Git tag was signed by one of the two trusted keys ), they do not support pinning, ie. that upstream could create a new signed Git tag with an identical name, and arbitrarily change the source code without the [maintainer] noticing . Conversely, other PKGBUILDs support pinning but not authentication. The new tool, auth-tarball-from-git, fixes both problems, as nearly outlined in kpcyrd s original blog post.
diffoscopediffoscope is our in-depth and content-aware diff utility. Not only can it locate and diagnose reproducibility issues, it can provide human-readable diffs from many kinds of binary formats. This month, Chris Lamb prepared and uploaded versions 212, 213 and 214 to Debian unstable.
Chris also made the following changes:
New features:
Add support for extracting vmlinuz Linux kernel images. []
Support both python-argcomplete 1.x and 2.x. []
Strip sticky etc. from x.deb: sticky Debian binary package [ ]. []
Integrate test coverage with GitLab s concept of artifacts. [][][]
Bug fixes:
Don t mask differences in .zip or .jar central directory extra fields. []
Don t show a binary comparison of .zip or .jar files if we have observed at least one nested difference. []
Codebase improvements:
Substantially update comment for our calls to zipinfo and zipinfo -v. []
Use assert_diff in test_zip over calling get_data with a separate assert. []
Don t call re.compile and then call .sub on the result; just call re.sub directly. []
Clarify the comment around the difference between --usage and --help. []
Testsuite improvements:
Test --help and --usage. []
Test that --help includes the file formats. []
Vagrant Cascadian added an external tool reference xb-tool for GNU Guix [] as well as updated the diffoscope package in GNU Guix itself [][][].
Distribution work
In Debian, 41 reviews of Debian packages were added, 85 were updated and 13 were removed this month adding to our knowledge about identified issues. A number of issue types have been updated, including adding a new nondeterministic_ordering_in_deprecated_items_collected_by_doxygen toolchain issue [] as well as ones for mono_mastersummary_xml_files_inherit_filesystem_ordering [], extended_attributes_in_jar_file_created_without_manifest [] and apxs_captures_build_path [].
Vagrant Cascadian performed a rough check of the reproducibility of core package sets in GNU Guix, and in openSUSE, Bernhard M. Wiedemann posted his usual monthly reproducible builds status report.
Upstream patches
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:
Testing framework
The Reproducible Builds project runs a significant testing framework at tests.reproducible-builds.org, to check packages and other artifacts for reproducibility. This month, the following changes were made:
Holger Levsen:
Add support for detecting running kernels that require attention. []
Temporarily configure a host to support performing Debian builds for packages that lack .buildinfo files. []
Update generated webpages to clarify wishes for feedback. []
Update copyright years on various scripts. []
Mattia Rizzolo:
Provide a facility so that Debian Live image generation can copy a file remotely. [][][][]
Roland Clobus:
Add initial support for testing generated images with OpenQA. []
And finally, as usual, node maintenance was also performed by Holger Levsen [][].
Contact
If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
The Ruby team is working now on transitioning to ruby 3.0. Even though most
packages will work just fine, there is substantial amount of packages that
require some work to adapt. We have been doing test rebuilds for a while during
transitions, but usually triaged the problems manually.
This time I decided to try
collab-qa-tools, a set of
scripts Lucas Nussbaum uses when he does archive-wide rebuilds. I'm really glad
that I did, because those tols save a lot of time when processing a large
number of build failures. In this post, I will go through how to triage a set
of build logs using collab-qa-tools.
I have
somesomeimprovements
to the code. Given my last merge request is very new and was not merged yet,
a few of the things I mention here may apply only to
my own ruby3.0 branch.
collab-qa-tools also contains a few tools do perform the builds in the
cloud, but since we already had the builds done, I will not be mentioning that
part and will write exclusively about the triaging tools.
Installing collab-qa-tools
The first step is to clone the git repository. Make sure you have the
dependencies from debian/control installed (a few Ruby libraries).
One of the patches I sent, and was already accepted, is the ability to run it
without the need to install:
source /path/to/collab-qa-tools/activate.sh
This will add the tools to your $PATH.
Preparation
The first think you need to do is getting all your build logs in a directory.
The tools assume .log file extension, and they can be named
$ PACKAGE _*.log or just $ PACKAGE .log.
Creating a TODO file
cqa-scanlogs grep -v OK > todo
todo will contain one line for each log with a summary of the failure, if
it's able to find one. collab-qa-tools has a large set of regular expressions
for finding errors in the build logs
It's a good idea to split the TODO file in multiple ones. This can easily be
done with split(1), and can be used to delimit triaging sessions, and/or to
split the triaging between multiple people. For example this will create
todo into todo00, todo01, ..., each containing 30 lines:
split --lines=30 --numeric-suffixes todo todo
Triaging
You can now do the triaging. Let's say we split the TODO files, and will start
with todo01.
The first step is calling cqa-fetchbugs (it does what it says on the tin):
cqa-fetchbugs --TODO=todo01
Then, cqa-annotate will guide you through the logs and allow you to report
bugs:
cqa-annotate --TODO=todo01
I wrote myself a process.sh wrapper script for cqa-fetchbugs and
cqa-annotate that looks like this:
#!/bin/shset-eufor todo in$@;do# force downloading bugsawk' print(".bugs." $1) '"$ todo" xargs rm-f
cqa-fetchbugs --TODO="$ todo"
cqa-annotate \--template=template.txt.jinja2 \--TODO="$ todo"done
The --template option is a recent contribution of mine. This is a template
for the bug reports you will be sending. It uses
Liquid templates,
which is very similar to Jinja2 for Python. You will notice that I am even
pretending it is Jinja2 to trick vim into doing syntax highlighting
for me. The template I'm using looks like this:
From: fullname<email>
To: submit@bugs.debian.org
Subject: package: FTBFS with ruby3.0: summary
Source: package
Version: versionsplit:'+rebuild'first
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-ruby@lists.debian.org
Usertags: ruby3.0
Hi,
We are about to enable building against ruby3.0 on unstable. During a test
rebuild, package was found to fail to build in that situation.
To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.
Relevant part (hopefully):
%forlineinextract% > line %endfor%
The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/package/filenamereplace:".log",".build.txt"
The cqa-annotate loop
cqa-annotate will parse each log file, display an extract of what it found as
possibly being the relevant part, and wait for your input:
######## ruby-cocaine_0.5.8-1.1+rebuild1633376733_amd64.log ########
--------- Error:
Failure/Error: undef_method :exitstatus
FrozenError:
can't modify frozen object: pid 2351759 exit 0
# ./spec/support/unsetting_exitstatus.rb:4:in undef_method'
# ./spec/support/unsetting_exitstatus.rb:4:in singleton class'
# ./spec/support/unsetting_exitstatus.rb:3:in assuming_no_processes_have_been_run'
# ./spec/cocaine/errors_spec.rb:55:in block (2 levels) in <top (required)>'
Deprecation Warnings:
Using should from rspec-expectations' old :should syntax without explicitly enabling the syntax is deprecated. Use the new :expect syntax or explicitly enable :should with config.expect_with(:rspec) c c.syntax = :should instead. Called from /<<PKGBUILDDIR>>/spec/cocaine/command_line/runners/backticks_runner_spec.rb:19:in block (2 levels) in <top (required)>'.
If you need more of the backtrace for any of these deprecations to
identify where to make the necessary changes, you can configure
config.raise_errors_for_deprecations! , and it will turn the
deprecation warnings into errors, giving you the full backtrace.
1 deprecation warning total
Finished in 6.87 seconds (files took 2.68 seconds to load)
67 examples, 1 failure
Failed examples:
rspec ./spec/cocaine/errors_spec.rb:54 # When an error happens does not blow up if running the command errored before execution
/usr/bin/ruby3.0 -I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
ERROR: Test "ruby3.0" failed:
----------------
ERROR: Test "ruby3.0" failed: Failure/Error: undef_method :exitstatus
----------------
package: ruby-cocaine
lines: 30
------------------------------------------------------------------------
s: skip
i: ignore this package permanently
r: report new bug
f: view full log
------------------------------------------------------------------------
Action [s i r f]:
You can then choose one of the options:
s - skip this package and do nothing. You can run cqa-annotate again
later and come back to it.
i - ignore this package completely. New runs of cqa-annotate won't ask
about it again.
This is useful if the package only fails in your rebuilds due to another
package, and would just work when that other package gets fixes. In the Ruby
transition this happens when A depends on B, while B builds a C extension and
failed to build against the new Ruby. So once B is fixed, A should
just work (in principle). But even if A would even have problems of its own,
we can't really know before B is fixed so we can retry A.
r - report a bug. cqa-annotate will expand the template with the data
from the current log, and feed it to mutt. This is currently a limitation:
you have to use mutt to report bugs.
After you report the bug, cqa-annotate will ask if it should edit the TODO
file. In my opinion it's best to not do this, and annotate the package with a
bug number when you have one (see below).
f - view the full log. This is useful when the extract displayed doesn't
have enough info, or you want to inspect something that happened earlier (or
later) during the build.
When there are existing bugs in the package, cqa-annotate will list them
among the options. If you choose a bug number, the TODO file will be annotated
with that bug number and new runs of cqa-annotate will not ask about that
package anymore. For example after I reported a bug for ruby-cocaine for the
issue listed above, I aborted with a ctrl-c, and when I run my process.sh
script again I then get this prompt:
----------------
ERROR: Test "ruby3.0" failed: Failure/Error: undef_method :exitstatus
----------------
package: ruby-cocaine
lines: 30
------------------------------------------------------------------------
s: skip
i: ignore this package permanently
1: 996206 serious ruby-cocaine: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: Failure/Error: undef_method :exitstatus
r: report new bug
f: view full log
------------------------------------------------------------------------
Action [s i 1 r f]:
Chosing 1 will annotate the TODO file with the bug number, and I'm done with
this package. Only a few other hundreds to go.
"Again, we see there is nothing you can possess which I cannot take away."
The cinema was a rare and expensive treat in my youth, so I first came across Raiders of the Lost Ark by recording it from television onto a poor quality VHS. I only mention this as it meant I watched a slightly different film to the one intended, as my copy somehow missed off the first 10 minutes. For those not as intimately familiar with the film as me, this is just in time to see a Belloq demand Dr. Jones hand over the Peruvian head (see above), just in time to learn that Indy loathes snakes, and just in time to see the inadvertent reproduction of two Europeans squabbling over the spoils of a foreign land.
What this truncation did to my interpretation of the film (released thirty years ago today on June 19th 1981) is interesting to explore. Without Jones' physical and moral traits being demonstrated on-screen (as well as missing the weighing the gold head and the rollercoaster boulder scene), it actually made the idea of 'Indiana Jones' even more of a mythical archetype. The film wisely withholds Jones' backstory, but my directors cut deprived him of even more, and counterintuitively imbued him with even more of a legendary hue as the elision made his qualities an assumption beyond question. Indiana Jones, if you can excuse the clich , needed no introduction at all.
Good artists copy, great artists steal. And oh boy, does Raiders steal. I've watched this film about twenty times over the past two decades and it's now firmly entered into my personal canon. But watching it on its thirtieth anniversary was different not least because I could situate it in a broader cinematic context. For example, I now see the Gestapo officer in Major Strasser from Casablanca (1942), in fact just as I can with many of Raiders' other orientalist tendencies: not only in its breezy depictions of backwards sand people, but also of North Africa as an entrep t and playground for a certain kind of Western gangster. The opening as well, set in an equally reductionist pseudo-Peru, now feels like Werner Herzog's Aguirre, the Wrath of God (1972) but without, of course, any self-conscious colonial critique.
The imagery of the ark appears to be borrowed from James Tissot's The Ark Passes Over the Jordan, part of the fin de siecle fascination with the occult and (ironically enough given the background of Raiders' director), a French Catholic revival.
I can now also appreciate some of the finer edges that make this film just so much damn fun to watch. For instance, the comic book conceit that Jones and Belloq are a 'shadowy reflection' of one other and that they need 'only a nudge' to make one like the other. As is the idea that Belloq seems to be actually enjoying being evil. I also spotted Jones rejecting the martini on the plane. This feels less like a comment on corrupting effect of alcohol (he drinks rather heavily elsewhere in the film), but rather a subtle distancing from James Bond. This feels especially important given that the action-packed cold open is, let us be honest for a second, ripped straight from the 007 franchise.
John William's soundtracks are always worth mentioning. The corny Raiders March does almost nothing for me, but the highly-underrated 'Ark theme' certainly does. I delight in its allusions to Gregorian chant, the diabolus in musica and the Hungarian minor scale, fusing the Christian doctrine of the Holy Trinity (the stacked thirds, get it?), the ars antiqua of the Middle Ages with an 'exotic' twist that the Russian Five associated with central European Judaism.
The best use of the ark leitmotif is, of course, when it is opened. Here, Indy and Marion are saved by not opening their eyes whilst the 'High Priest' Belloq and the rest of the Nazis are all melted away. I'm no Biblical scholar, but I'm almost certain they were alluding to Leviticus 16:2 here:
The Lord said to Moses: Tell your brother Aaron that he is not to come whenever he chooses into the Most Holy Place behind the curtain in front of the atonement cover on the ark, or else he will die, for I will appear in the cloud above the mercy seat.
But would it be too much of a stretch to also see the myth of Orpheus and Eurydices too? Orpheus's wife would only be saved from the underworld if he did not turn around until he came to his own house. But he turned round to look at his wife, and she instantly slipped back into the depths:
For he who overcome should turn back his gaze
Towards the Tartarean cave,
Whatever excellence he takes with him
He loses when he looks on those below.
Perhaps not, given that Marion and the ark are not lost in quite the same way. But whilst touching on gender, it was interesting to update my view of archaeologist Ren Belloq. To countermand his slight queer coding (a trope of Disney villains such as Scar, Jafar, Cruella, etc.), there is a rather clumsy subplot involving Belloq repeatedly (and half-heartedly) failing to seduce Marion. This disavows any idea that Belloq isn't firmly heterosexual, essential for the film's mainstream audience, but it is especially important in Raiders because, if we recall the relationship between Belloq and Jones: 'it would take only a nudge to make you like me'. (This would definitely put a new slant on 'Top men'.)
However, my favourite moment is where the Nazis place the ark in a crate in order to transport it to the deserted island. On route, the swastikas on the side of the crate spontaneously burn away, and a disturbing noise is heard in the background. This short scene has always fascinated me, partly because it's the first time in the film that the power of the ark is demonstrated first-hand but also because gives the object an other-worldly nature that, to the best of my knowledge, has no parallel in the rest of cinema.
Still, I had always assumed that the Aak disfigured the swastikas because of their association with the Nazis, interpreting the act as God's condemnation of the Third Reich. But now I catch myself wondering whether the ark would have disfigured any iconography as a matter of principle or whether their treatment was specific to the swastika. We later get a partial answer to this question, as the 'US Army' inscriptions in the Citizen Kane warehouse remain untouched.
Far from being an insignificant concern, the filmmakers appear to have wandered into a highly-contested theological debate. As in, if the burning of the swastika is God's moral judgement of the Nazi regime, then God is clearly both willing and able to intervene in human affairs. So why did he not, to put it mildly, prevent Auschwitz? From this perspective, Spielberg appears to be limbering up for some of the academic critiques surrounding Holocaust representations that will follow Schindler's List (1993).
Given my nostalgic and somewhat ironic attachment to Raiders, it will always be difficult for me to objectively appraise the film. Even so, it feels like it is underpinned by an earnest attempt to entertain the viewer, largely absent in the affected cynicism of contemporary cinema. And when considered in the totality of Hollywood's output, its tonal and technical flaws are not actually that bad or at least Marion's muddled characterisation and its breezy chauvinism (for example) clearly have far worse examples.
Perhaps the most remarkable thing about the film in 2021 is that it hasn't changed that much at all. It spawned one good sequel (The Last Crusade), one bad one (The Temple of Doom), and one hardly worth mentioning at all, yet these adventures haven't affected the original Raiders in any meaningful way. In fact, if anything has affected the original text it is, once again, George Lucas himself, as knowing the impending backlash around the Star Wars prequels adds an inadvertent paratext to all his earlier works.
Yet in a 1978 discussion prior to the creation of Raiders, you can get a keen sense of how Lucas' childlike enthusiasm will always result in something either extremely good or something extremely bad somehow no middle ground is quite possible. Yes, it's easy to rubbish his initial ideas 'We'll call him Indiana Smith! but hasn't Lucas actually captured the essence of a heroic 'Americana' here, and that the final result is simply a difference of degree, not kind?
"Again, we see there is nothing you can possess which I cannot take away."
The cinema was a rare and expensive treat in my youth, so I first came across Raiders of the Lost Ark by recording it from television onto a poor quality VHS. I only mention this as it meant I watched a slightly different film to the one intended, as my copy somehow missed off the first 10 minutes. For those not as intimately familiar with the film as me, this is just in time to see a Belloq demand Dr. Jones hand over the Peruvian head (see above), just in time to learn that Indy loathes snakes, and just in time to see the inadvertent reproduction of two Europeans squabbling over the spoils of a foreign land.
What this truncation did to my interpretation of the film (released thirty years ago today on June 19th 1981) is interesting to explore. Without Jones' physical and moral traits being demonstrated on-screen (as well as missing the weighing the gold head and the rollercoaster boulder scene), it actually made the idea of 'Indiana Jones' even more of a mythical archetype. The film wisely withholds Jones' backstory, but my directors cut deprived him of even more, and counterintuitively imbued him with even more of a legendary hue as the elision made his qualities an assumption beyond question. Indiana Jones, if you can excuse the clich , needed no introduction at all.
Good artists copy, great artists steal. And oh boy, does Raiders steal. I've watched this film about twenty times over the past two decades and it's now firmly entered into my personal canon. But watching it on its thirtieth anniversary was different not least because I could situate it in a broader cinematic context. For example, I now see the Gestapo officer in Major Strasser from Casablanca (1942), in fact just as I can with many of Raiders' other orientalist tendencies: not only in its breezy depictions of backwards sand people, but also of North Africa as an entrep t and playground for a certain kind of Western gangster. The opening as well, set in an equally reductionist pseudo-Peru, now feels like Werner Herzog's Aguirre, the Wrath of God (1972) but without, of course, any self-conscious colonial critique.
The imagery of the ark appears to be borrowed from James Tissot's The Ark Passes Over the Jordan, part of the fin de siecle fascination with the occult and (ironically enough given the background of Raiders' director), a French Catholic revival.
I can now also appreciate some of the finer edges that make this film just so much damn fun to watch. For instance, the comic book conceit that Jones and Belloq are a 'shadowy reflection' of one other and that they need 'only a nudge' to make one like the other. As is the idea that Belloq seems to be actually enjoying being evil. I also spotted Jones rejecting the martini on the plane. This feels less like a comment on corrupting effect of alcohol (he drinks rather heavily elsewhere in the film), but rather a subtle distancing from James Bond. This feels especially important given that the action-packed cold open is, let us be honest for a second, ripped straight from the 007 franchise.
John William's soundtracks are always worth mentioning. The corny Raiders March does almost nothing for me, but the highly-underrated 'Ark theme' certainly does. I delight in its allusions to Gregorian chant, the diabolus in musica and the Hungarian minor scale, fusing the Christian doctrine of the Holy Trinity (the stacked thirds, get it?), the ars antiqua of the Middle Ages with an 'exotic' twist that the Russian Five associated with central European Judaism.
The best use of the ark leitmotif is, of course, when it is opened. Here, Indy and Marion are saved by not opening their eyes whilst the 'High Priest' Belloq and the rest of the Nazis are all melted away. I'm no Biblical scholar, but I'm almost certain they were alluding to Leviticus 16:2 here:
The Lord said to Moses: Tell your brother Aaron that he is not to come whenever he chooses into the Most Holy Place behind the curtain in front of the atonement cover on the ark, or else he will die, for I will appear in the cloud above the mercy seat.
But would it be too much of a stretch to also see the myth of Orpheus and Eurydices too? Orpheus's wife would only be saved from the underworld if he did not turn around until he came to his own house. But he turned round to look at his wife, and she instantly slipped back into the depths:
For he who overcome should turn back his gaze
Towards the Tartarean cave,
Whatever excellence he takes with him
He loses when he looks on those below.
Perhaps not, given that Marion and the ark are not lost in quite the same way. But whilst touching on gender, it was interesting to update my view of archaeologist Ren Belloq. To countermand his slight queer coding (a trope of Disney villains such as Scar, Jafar, Cruella, etc.), there is a rather clumsy subplot involving Belloq repeatedly (and half-heartedly) failing to seduce Marion. This disavows any idea that Belloq isn't firmly heterosexual, essential for the film's mainstream audience, but it is especially important in Raiders because, if we recall the relationship between Belloq and Jones: 'it would take only a nudge to make you like me'. (This would definitely put a new slant on 'Top men'.)
However, my favourite moment is where the Nazis place the ark in a crate in order to transport it to the deserted island. On route, the swastikas on the side of the crate spontaneously burn away, and a disturbing noise is heard in the background. This short scene has always fascinated me, partly because it's the first time in the film that the power of the ark is demonstrated first-hand but also because gives the object an other-worldly nature that, to the best of my knowledge, has no parallel in the rest of cinema.
Still, I had always assumed that the Aak disfigured the swastikas because of their association with the Nazis, interpreting the act as God's condemnation of the Third Reich. But now I catch myself wondering whether the ark would have disfigured any iconography as a matter of principle or whether their treatment was specific to the swastika. We later get a partial answer to this question, as the 'US Army' inscriptions in the Citizen Kane warehouse remain untouched.
Far from being an insignificant concern, the filmmakers appear to have wandered into a highly-contested theological debate. As in, if the burning of the swastika is God's moral judgement of the Nazi regime, then God is clearly both willing and able to intervene in human affairs. So why did he not, to put it mildly, prevent Auschwitz? From this perspective, Spielberg appears to be limbering up for some of the academic critiques surrounding Holocaust representations that will follow Schindler's List (1993).
Given my nostalgic and somewhat ironic attachment to Raiders, it will always be difficult for me to objectively appraise the film. Even so, it feels like it is underpinned by an earnest attempt to entertain the viewer, largely absent in the affected cynicism of contemporary cinema. And when considered in the totality of Hollywood's output, its tonal and technical flaws are not actually that bad or at least Marion's muddled characterisation and its breezy chauvinism (for example) clearly have far worse examples.
Perhaps the most remarkable thing about the film in 2021 is that it hasn't changed that much at all. It spawned one good sequel (The Last Crusade), one bad one (The Temple of Doom), and one hardly worth mentioning at all, yet these adventures haven't affected the original Raiders in any meaningful way. In fact, if anything has affected the original text it is, once again, George Lucas himself, as knowing the impending backlash around the Star Wars prequels adds an inadvertent paratext to all his earlier works.
Yet in a 1978 discussion prior to the creation of Raiders, you can get a keen sense of how Lucas' childlike enthusiasm will always result in something either extremely good or something extremely bad somehow no middle ground is quite possible. Yes, it's easy to rubbish his initial ideas 'We'll call him Indiana Smith! but hasn't Lucas actually captured the essence of a heroic 'Americana' here, and that the final result is simply a difference of degree, not kind?
Today marks the 90th day of me joining Canonical to work on Ubuntu full-time! So since
it s been a while already, this blog post is long due. :)
The News
I joined Canonical, this February, to work on Ubuntu full-time! \o/
Those who know, they know that this is really very exciting for me because Canonical has
been a dream company for me, for real (more about this below!). And hey, this is my first
job, ever, so all the more reason to be psyched about, isn t it? ^_^
P.S. Keep reading and we ll meet my squad really sooon!
The Story
Being an undergrad student (batch 2017-2021), I ve been slightly worried during my last
two semesters, naturally, thinking about how s it all gonna pan out and what will I be doing,
et al, because I ve been seeing all my friends and batchmates getting placed in companies
or going for masters or at least having some sort of plans for their future and I, on the
other hand, was hopelessly clueless. :D
Well, to be fair, I did Google Summer of Code twice,
in 2019 and
2020, became a
Debian Developer in 2019, been a part of
GCI and Outreachy, contributed
to over dozens of open-source projects, et al, et al. So I wasn t all completely hopeless
but for sure was completely clueless , heh.
And for full disclosure, I was only slightly panicking because firstly, I did get placed
in several companies and secondly, I didn t really need a job immediately since I was already
getting paid to work on Debian stuff by Freexian, which was good enough. :)
(and honestly, Freexian has my whole heart! - more on that later sometime.)
But that s not the point. I was still confused and worried and my mom & dad, more so than
anyone. Ugh. We were all figuring out and she asked me places that I was interested to work
in. And whilst I wasn t clear about things I wanted to do (and still am!) but I was (very)
clear about this and so I told her about Canonical and also did tell her that it s a bit too
ambitious for me to think about it now so I ll probably apply after some experience or something.
and as they say, the world works in mysterious ways and well, it did for me! So back during
the Ruby sprints (Feb 20), Kanashiro, the guy ( ), mentioned that his team was hiring and
has a vacant position but I won t be eligible since I was still in my junior year. It was
since then I ve been actively praying for Cronus, the god of time, to wave his magic wand and
align it in such a way that the next opening should be somewhere near my graduation. And guess
what? IT HAPPENED!
9 months later, in November 20, Kanashiro told me his team is hiring yet again and that I
could apply this time! Without much (since there was some ) delay, I applied and started
asking all sorts of questions to Kanashiro. No words are enough for him, he literally helped
me throughout the process; from referring me to answering all sorts of doubts I had!
And roughly after 2 months of interviewing, et al, my ambitious dream did come true and I
finalyyyy signed my contract! \o/
(the interview process and what went on during those 10 weeks is a story for later ;))
The Server Team! \o
This position, which I didn t mention earlier, was for the Server Team which is a team of
15 people, working to make Ubuntu server the best! And as I
tweeted sometime back, the team
is absolutely lovely, super kind, and consists of the best of teammates one could possibly
ask for!
Here s a quick sneak peek into our weekly team meeting. Thanks to
Rafael for taking such a lovely picture. And yes,
the cat Luna is a part of our squad!
And oh, did I mention that we re completely remote and distributed?
FUN FACT: Our team covers all the TZs, that is, at any point of time (during weekdays),
you ll find someone or the other from the team around! \o/
Anyway, our squad, managed by Rick is divided into two halves: Squeaky Wheels and
Table Flip. Cool names, right?
Squeaky Wheels does the distro side of stuff and consists of Christian, Andreas, Rafael, Robie,
Bryce, Sergio, Kanashiro, Athos, and now myself as well! And OTOH, Table Flip consists of Dan,
Chad, Paride, Lucas, James, and Grant.
Even though I interact w/ Squeaky Wheels more (basically daily), each of my teammates is
absolutely lovely and equally awesome!
Whilst I ll talk more about things here in the upcoming months, this is it for now! If there s
anything, in particular, you d like to know more about, let me know!
And lastly, here s us vibing our way through, making Ubuntu server better, cause that s how
we roll!
Until next time. :wq for today.
Welcome to the October 2020 report from the Reproducible Builds project.
In our monthly reports, we outline the major things that we have been up to over the past month. As a brief reminder, the motivation behind the Reproducible Builds effort is to ensure flaws have not been introduced in the binaries we install on our systems. If you are interested in contributing to the project, please visit our main website.
The previous year has seen great progress in Arch Linux to get reproducible builds in the hands of the users and developers. In this talk we will explore the current tooling that allows users to reproduce packages, the rebuilder software that has been written to check packages and the current issues in this space.
GNU Mes rebuild is definitely an application of [Diverse Double-Compiling]. [..] This is an awesome application of DDC, and I believe it s the first publicly acknowledged use of DDC on a binary
Debian-related work
In August, Lucas Nussbaum performed an archive-wide rebuild of packages to test enabling the reproducible=+fixfilepath Debian build flag by default. Enabling this fixfilepath feature will likely fix reproducibility issues in an estimated 500-700 packages. However, this month Vagrant Cascadian posted to the debian-devel mailing list:
It would be great to see the reproducible=+fixfilepath feature enabled by default in dpkg-buildflags, and we would like to proceed forward with this soon unless we hear any major concerns or other outstanding issues. [ ] We would like to move forward with this change soon, so please raise any concerns or issues not covered already.
Debian Developer Stuart Prescott has been improving python-debian, a Python library that is used to parse Debian-specific files such as changelogs, .dscs, etc. In particular, Stuart is working on adding support for .buildinfo files used for recording reproducibility-related build metadata:
This can mostly be a very thin layer around the existing Deb822 types, using the existing Changes code for the file listings, the existing PkgRelations code for the package listing and gpg_* functions for signature handling.
Bernhard M. Wiedemann also reported three issues against bison, ibus and postgresql12.
Tools
diffoscope is our in-depth and content-aware diff utility. Not only could you locate and diagnose reproducibility issues, it provides human-readable diffs of all kinds too. This month, Chris Lamb uploaded version 161 to Debian (later backported by Mattia Rizzolo), as well as made the following changes:
Move test_ocaml to the assert_diff helper. []
Update tests to support OCaml version 4.11.1. Thanks to Sebastian Ramacher for the report. (#972518)
Bump minimum version of the Black source code formatter to 20.8b1. (#972518)
In addition, Jean-Romain Garnier temporarily updated the dependency on radare2 to ensure our test pipelines continue to work [], and for the GNU Guix distribution Vagrant Cascadian diffoscope to version 161 [].
In related development, trydiffoscope is the web-based version of diffoscope. This month, Chris Lamb made the following changes:
Mark a --help-only test as being a superficial test. (#971506)
Add a real, albeit flaky, test that interacts with the try.diffoscope.org service. []
Bump debhelper compatibility level to 13 [] and bump Standards-Version to 4.5.0 [].
Lastly, disorderfs version 0.5.10-2 was uploaded to Debian unstable by Holger Levsen, which enabled security hardening via DEB_BUILD_MAINT_OPTIONS [] and dropped debian/disorderfs.lintian-overrides [].
Add a citation link to the academic article regarding dettrace [], and added yet another supply-chain security attack publication [].
Reformatted the Jekyll s Liquid templating language and CSS formatting to be consistent [] as well as expand a number of tab characters [].
Used relative_url to fix missing translation icon on various pages. []
Published two announcement blog posts regarding the restarting of our IRC meetings. [][]
Added an explicit note regarding the lack of an in-person summit in 2020 to our events page. []
Testing framework
The Reproducible Builds project operates a Jenkins-based testing framework that powers tests.reproducible-builds.org. This month, Holger Levsen made the following changes:
Make a number of updates to reflect that our sponsor Profitbricks has renamed itself to IONOS. [][][][]
Run a F-Droid maintenance routine twice a month to utilise its cleanup features. []
Fix the target name in OpenWrt builds to ath79 from ath97. []
Add a missing Postfix configuration for a node. []
Temporarily disable Arch Linux builds until a core node is back. []
Make a number of changes to our thanks page. [][][]
Build node maintenance was performed by both Holger Levsen [][] and Vagrant Cascadian [][][], Vagrant Cascadian also updated the page listing the variations made when testing to reflect changes for in build paths [] and Hans-Christoph Steiner made a number of changes for F-Droid, the free software app repository for Android devices, including:
Do not fail reproducibility jobs when their cleanup tasks fail. []
Skip libvirt-related sudo command if we are not actually running libvirt. []
Use direct URLs in order to eliminate a useless HTTP redirect. []
If you are interested in contributing to the Reproducible Builds project, please visit the Contribute page on our website. However, you can also get in touch with us via:
A couple of years ago, I moved into a new flat that comes with RJ45 sockets wired for 10 Gigabit (but currently offering 1 Gigabit) Ethernet.This also meant changing the settings on my router box for my new ISP.I took this opportunity to review my router's other settings too. I'll be blogging about these over the next few posts.
Migrating to Predictable Network Interface Names
Ever since Linus decided to flip the network interface enumeration order in the Linux kernel, I had been relying on udev's persistent network interface rules to maintain some semblance of consistency in the NIC naming scheme of my hosts. It has never been a totally satisfactory method, since it required manually editing the file to list the MAC addresses of all Ethernet cards and WiFi dongles likely to appear on that host to consistently use an easy-to-remember name that I could adopt for ifupdown configuration files.
Enter predictable interface names. What started as a Linux kernel module project at Dell was eventually re-implemented in systemd. However, clear documentation on the naming scheme had been difficult to find and udev's persistent network interface rules gave me what I needed, so I postponed the transition for years. Relocating to a new flat and rethinking my home network to match gave me an opportunity to revisit the topic.
The naming scheme is surprisingly simple and logical, once proper explanations have been found. The short version:
Ethernet interfaces are called en i.e. Ether Net.
Wireless interfaces are called wl i.e. Wire Less. (yes, the official documentation call this Wireless Local but, in everyday usage, remembering Wire Less is simpler)
The rest of the name specifies on which PCI bus and which slot the interface is found. On my old Dell laptop, it looks like this:
enp9s0: Ethernet interface at PCI bus 9 slot 0.
wlp12s0: Wireless interface at PCI bus 12 slot 0.
An added bonus of the naming scheme is that it makes replacing hardware a breeze, since the naming scheme is bus and slot specific, not MAC address specific. No need to edit any configuration file. I saw this first-hand when I got around upgrading my router's network cards to Gigabit-capable ones to take advantage of my new home's broadband LAN. All it took was to power off the host, swap the Ethernet cards and power on the host. That's it. systemd took care of everything else.
Still, migrating looked like a daunting task. Debian's wiki page gave me some answers, but didn't provide a systematic approach. I came up with the following shell script:
This combined ideas found on the Debian wiki with a few of my own. Running the script before and after the migration ensured that I hadn't missed any configuration file. Once I was satisfied with that, I commented out the old udev persistent network interface rules, ran dpkg-reconfigure on all my Linux kernel images to purge the rules from the initrd images, and called it a day.
... well, not quite. It turns out that with bridge-utils, bridge_ports all no longer works. One must manually list all interfaces to be bridged. Debian bug report filed.
PS: Luca Capello pointed out that Debian 10/Buster's Release Notes include migration instructions.
Welcome to the September 2020 report from the Reproducible Builds project. In our monthly reports, we attempt to summarise the things that we have been up to over the past month, but if you are interested in contributing to the project, please visit our main website.
This month, the Reproducible Builds project was pleased to announce a donation from Amateur Radio Digital Communications (ARDC) in support of its goals. ARDC s contribution will propel the Reproducible Builds project s efforts in ensuring the future health, security and sustainability of our increasingly digital society. Amateur Radio Digital Communications (ARDC) is a non-profit which was formed to further research and experimentation with digital communications using radio, with a goal of advancing the state of the art of amateur radio and to educate radio operators in these techniques. You can view the full announcement as well as more information about ARDC on their website.
In August s report, we announced that Jennifer Helsby (redshiftzero) launched a new reproduciblewheels.com website to address the lack of reproducibility of Python wheels . This month, Kushal Das posted a brief follow-up to provide an update on reproducible sources as well.
The Threema privacy and security-oriented messaging application announced that within the next months , their apps will become fully open source, supporting reproducible builds :
This is to say that anyone will be able to independently review Threema s security and verify that the published source code corresponds to the downloaded app.
The previous year has seen great progress in Arch Linux to get reproducible builds in the hands of the users and developers. In this talk we will explore the current tooling that allows users to reproduce packages, the rebuilder software that has been written to check packages and the current issues in this space.
During the Reproducible Builds summit in Marrakesh, GNU Guix, NixOS and Debian were able to produce a bit-for-bit identical binary when building GNU Mes, despite using three different major versions of GCC. Since the summit, additional work resulted in a bit-for-bit identical Mes binary using tcc and this month, a fuller update was posted by the individuals involved.
diffoscopediffoscope is our in-depth and content-aware diff utility that can not only locate and diagnose reproducibility issues, it provides human-readable diffs of all kinds too.
In September, Chris Lamb made the following changes to diffoscope, including preparing and uploading versions 159 and 160 to Debian:
New features:
Show ordering differences only in strings(1) output by applying the ordering check to all differences across the codebase. []
Bug fixes:
Mark some PGP tests that they require pgpdump, and check that the associated binary is actually installed before attempting to run it. (#969753)
Don t raise exceptions when cleaning up after guestfs cleanup failure. []
Ensure we check FALLBACK_FILE_EXTENSION_SUFFIX, otherwise we run pgpdump against all files that are recognised by file(1) as data. []
Codebase improvements:
Add some documentation for the EXTERNAL_TOOLS dictionary. []
Abstract out a variable we use a couple of times. []
Improve the documentation on how to signup to Salsa. []
Add some more links to academic papers. []
Also include the general news in our RSS feed [] and drop including weekly reports from the RSS feed (they are never shown now that we have over 10 items) [].
Update ordering and location of various news and links to tarballs, etc. [][][]
In addition, Holger Levsen re-added the documentation link to the top-level navigation [] and documented that the jekyll-polyglot package is required []. Lastly, diffoscope.org and reproducible-builds.org were transferred to Software Freedom Conservancy. Many thanks to Brett Smith from Conservancy, J r my Bobbio (lunar) and Holger Levsen for their help with transferring and to Mattia Rizzolo for initiating this.
Upstream patches
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of these patches, including:
Testing framework
The Reproducible Builds project operates a Jenkins-based testing framework to power tests.reproducible-builds.org. This month, Holger Levsen made the following changes:
Highlight important bad conditions in colour. [][]
Add support for detecting more problems, including Jenkins shutdown issues [], failure to upgrade Arch Linux packages [], kernels with wrong permissions [], etc.
Misc:
Delete old schroot sessions after 2 days, not 3. []
In addition, stefan0xC fixed a query for unknown results in the handling of Arch Linux packages [] and Mattia Rizzolo updated the template that notifies maintainers by email of their newly-unreproducible packages to ensure that it did not get caught in junk/spam folders []. Finally, build node maintenance was performed by Holger Levsen [][][][], Mattia Rizzolo [][] and Vagrant Cascadian [][][].
If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
Because of the lock-down in France and thanks to Lucas, I have been able to make some progress rebuilding Debian with clang instead of gcc.
TLDR
Instead of patching clang itself, I used a different approach this time: patching Debian tools or implementing some workaround to mitigate an issue.
The percentage of packages failing drop from 4.5% to 3.6% (1400 packages to 1110 - on a total of 31014).
I focused on two classes of issues:
Symbol differences
Historically, symbol management for C++ in Debian has been a pain. Russ Allbery wrote a blog post in 2012 explaining the situation. AFAIK, it hasn't changed much.
Once more, I took the dirty approach: if there new or missing symbols, don't fail the build.
The rational is the following: Packages in the Debian archive are supposed to build without any issue. If there is new or missing symbols, it is probably clang generating a different library but this library is very likely working as expected (and usable by a program compiled with g++ or clang). It is purely a different approach taken by the compiler developer.
In order to mitigate this issue, before the build starts, I am modifying dpkg-gensymbols to transform the error into a warning.
So, the typical Debian error some new symbols appeared in the symbols file or some symbols or patterns disappeared in the symbols file will NOT fail the build.
Unsurprisingly, all but one package (libktorrent) build.
Even if I am pessimistic, I reported a bug on dpkg-dev to evaluate if we could improve dpkg-gensymbol not to fail on these cases.
For maintainers & upstream
Maintainer of Debian/Ubuntu packages? I am providing a list of failing packages per maintainer: https://clang.debian.net/maintainers.php
For upstream, it is also easy to test with clang. Usually, apt install clang && CC=clang CXX=clang++ <build step> is good enough.
Conclusion
With these two changes, I have been able to fix about 290 packages. I think I will be able to get that down a bit more but we will soon reach a plateau as many warnings/issues will have to fix in the C/C++ code itself.
Em 2023 o tradicional 
With the end of the year approaching fast, I thought putting my year in
retrospective via music would be a fun thing to do.
Albums
In 2022, I added 51 new albums to my collection nearly one a week! I listed
them below in the order in which I acquired them.
I purchased most of these albums when I could and borrowed the rest at
libraries. If you want to browse though, I added links to the album covers
pointing either to websites where you can buy them or to Discogs when digital
copies weren't available
"Again, we see there is nothing you can possess which I cannot take away."
The imagery of the ark appears to be borrowed from James Tissot's The Ark Passes Over the Jordan, part of the fin de siecle fascination with the occult and (ironically enough given the background of Raiders' director), a French Catholic revival.
And oh, did I mention that we re completely remote and distributed?
This month, the Reproducible Builds project restarted our IRC meetings, managing to convene twice: the first time on October 12th (
A couple of years ago, I moved into a new flat that comes with RJ45 sockets wired for 10 Gigabit (but currently offering 1 Gigabit) Ethernet.This also meant changing the settings on my router box for my new ISP.I took this opportunity to review my router's other settings too. I'll be blogging about these over the next few posts.
Migrating to Predictable Network Interface Names
Ever since Linus decided to flip the network interface enumeration order in the Linux kernel, I had been relying on udev's persistent network interface rules to maintain some semblance of consistency in the NIC naming scheme of my hosts. It has never been a totally satisfactory method, since it required manually editing the file to list the MAC addresses of all Ethernet cards and WiFi dongles likely to appear on that host to consistently use an easy-to-remember name that I could adopt for ifupdown configuration files.
Enter predictable interface names. What started as a Linux kernel module project at Dell was eventually re-implemented in systemd. However, clear documentation on the naming scheme had been difficult to find and udev's persistent network interface rules gave me what I needed, so I postponed the transition for years. Relocating to a new flat and rethinking my home network to match gave me an opportunity to revisit the topic.
The naming scheme is surprisingly simple and logical, once 
