Antonio Terceiro - Posts tagged with "debian"

Debian e o ECA Digital

2026-04-18T06:00:00Z

A Lei Nº 15.211, de 17 de setembro de 2025, popularmente conhecida como o ECA Digital (em referência ao ECA - Estatuto de Criança e do Adolescente, lei Nº 8.069, de 13 de julho de 1990), foi promulgada em março de 2026. A não ser que você tenha estado numa caverna no último mês, você sabe que essa lei declara o objetivo de "proteção de crianças e adolescentes em ambientes digitais".

Por um lado, é evidente que a distribuição de conteúdo em massa tem que ser regulada de alguma forma pra evitar a instrumentalização das redes sociais pra promover o vício em estar online, a divulgação de desinformação, incluindo pra influenciar eleições e articular tentativas de golpes de estado, e outras atividades que claramente criam problemas para a saúde pública e para a economia popular (apostas?). Crianças e adolescentes são particularmente suscetíveis a essa pororoca de chorume que é a internet comercial.

Por outro lado, existem várias partes da lei que não são específicas o suficiente, e que abrem brechas para tornar legais coisas que são absolutamente execráveis, como a coleta de dados biométricos em massa a fim de "proteger as criancinhas".

Eu acho que muitos aspectos desse lei merecem debate, mas aqui eu vou focar apenas na relação dessa nova legislação com o Debian e as suas consequências concretas para o projeto, porque a lei 15.211 menciona explicitamente "sistemas operacionais de terminal", que são sistemas operacionais destinados ao acesso à internet por usuários finais.

Problemas complexos possuem respostas fáceis que sempre estão erradas, e eu não pretendo aqui trazer conclusões definitivas.

A reação ao ECA Digital

A iminência da promulgação levou a uma reação de pânico na internet. Textos e mais textos foram escritos. Só no Tecmundo, que segundo algumas fontes parece ser "o maior site sobre tecnologia do Brasil", teve um texto do Thiago Ayub que ao menos na minha bolha pareceu ser o primeiro a viralizar sobre o tema, e aparentemente deu o tom da reação da maioria da comunidade.

Outra reação bastante negativa foi a do Alexandre Oliva, que vem escrevendo uma série de textos que aumenta cada vez que eu consulto. O Oliva é uma referência no Software Livre e eu tenho máximo respeito pelas reflexões dele. Ele questiona tudo que poderia dar errado, e passa um depurador no texto da lei. Vai um pouco longe em alguns possíveis casos que a lei poderia vir a se aplicar, eu acho, mas vale a leitura.

Uma certa bolha no Youtube viu uma explosão de vídeos apocalípticos decretando o fim do "Linux" no Brasil. Um vídeo razoável, de um canal que eu acompanho e cujas reflexões eu respeito e com as quais eu quase sempre concordo, foi o do Tecnologia e Classe.

Reflexões um pouco mais otimistas vêm do Paulo Rená, que tem publicado vários textos também no Tecmundo com uma visão mais positiva sobre a lei em si e sobre as suas consequências para o software livre, e sobre como os requisitos de aferição de idade podem ser implementados da uma forma que não contribua com um aumento da vigilância em massa.

O que de concreto nós (não) sabemos até agora

A lei foi sancionada em Março, e sua regulação foi delegada à Agência Nacional de Proteção de Dados (ANPD), o que a princípio parece ser um bom sinal. A ANPD divulgou um cronograma de ações relacionadas à regulação, onde é dito que a partir de março de 2026, "priorizará o monitoramento de lojas de aplicativos e sistemas operacionais proprietários".

Algo que me parece claro é que o a maior parte dos sistemas livres, usados como infraestrutura, servidores, desktops corporativos, estações de trabalho etc, não são alcançados pela lei, porque não são "direcionado a crianças e a adolescentes no País ou de acesso provável por eles". Também me parece claro que o objetivo é regular os fornecedores comerciais de hardware com sistema operacional pré-instalado, e que pais e responsáveis que instalam um sistema livre que eventualmente sejam usados por crianças ou adolescentes não estão em risco.

Por outro lado, empresas vão estar na mira, mais cedo ou mais tarde. A Canonical, que nem vende hardware, está listada entre as empresas às quais a ANPD solicitou informações sobre planos para adequação. Fornecedores de hardware com software livre para consumidor final certamente vão entrar no radar mais cedo ou mais tarde, assim como empresas que eventualmente vendam hardware com software livre para escolas. Não sei quantas dessas empresas existem, mas a gente com certeza quer que existam mais delas, e não menos!

Numa live organizada pela Safernet Brasil, mais de um dos representantes do governo, incluindo o representante da ANPD, disseram textualmente que não é o objetivo da lei prejudicar as comunidades de software livre. Nesta mesma live, eu postei 4 perguntas que a princípio ficarem sem resposta:

A nota inicial da ANPD menciona monitorar inicialmente "sistemas operacionais proprietários", mas mais pra frente fala apenas de "sistemas operacionais". Como exatamente ficam os sistemas operacionais livres?
Num contexto de regulação de sistemas operacionais, é suficiente que um sistema operacional forneça a possibilidade opcional de controle parental, com indicação da idade configurada localmente no sistema pelo responsável (administrador do sistema, i.e. "root"), e que responda apenas "sim" ou "não" a perguntas do tipo "o usuário tem mais do que X anos de idade?", ou apenas informe uma faixa etária para aplicações, sem nenhuma outra informação pessoal?
Projetos de sistema operacional livre, como o Debian, vão precisar ter alguma forma de representação formal no Brasil pra lidar com eventual monitoramento pela ANPD? O Debian não tem uma entidade formal central mesmo a nível internacional!
O grupo brasileiro de membros do Debian deveria procurar contratar uma orientação legal agora, ou num futuro próximo?

A ANPD deve iniciar uma consulta pública (Tomada de Subsídios) ainda em Abril sobre detalhes técnicos, o que até agora não aconteceu. A partir desse momento, espero que consigamos ter um melhor entendidmento do quê concretamente o projeto Debian precisa fazer, e também -- e principalmente -- o que o Debian não precisa fazer.

O papel de um Sistema Operacional livre na proteção de crianças e adolescentes

O sistema operacional está numa posição privilegiada, tanto pra proteger, quanto pra abusar do usuário. Um sistema operacional livre, mantido por uma comunidade ativa e com os mecanismos de transparência já tradicionais, sob o controle do dono do equipamento, deve ser capaz de proteger os usuários da indústica de vigilância, e não fornecer mais do que o mínimo necessário pra cumprir os objetivos da lei, que é a proteção de crianças e adolescentes: apenas uma resposta sim/não pra uma pergunta sobre a idade do usuário, ou no máximo informar a faixa de idade dele.

Problemas em aberto pra além do sistema operacional

Mesmo a maioria das pessoas que estão utilizando um sistema operacional livre estão consumindo serviços proprietários e/ou centralizados do centro do capitalismo, e esse é, na minha visão, um problema muito mais cabeludo do que o que nós enquanto desenvolvedores de sistemas operacionais vamos ter que lidar.

Existem vários problemas em aberto para as camadas acima do sistema operacional, e isso já começou a se manifestar com empresas querendo coletar selfies, documentos e etc. O ECA Digital não exige coleta de biometria, mas também não proíbe definitivamente.

Provas de conhecimento zero (ZKP - Zero Knowledge Proofs) são uma alternativa a ter que fornecer biometria ou outras formas de informações pessoais a um número incomensurável de provedores de serviço, mas ainda assim, exigem fornecer essas informações a pelo menos uma terceira parte que seja confiável tanto pela sociedade quando para as empresas.

No final das contas, o ideal seria que se o SO fornece uma atestação de idade verificada localmente, isso fosee o suficiente e nenhuma informação pessoal a mais fosse necessária. Mas o próprio texto da lei diz que as aplicações precisam "implementar mecanismos próprios para impedir o acesso indevido de crianças e de adolescentes a conteúdos inadequados para sua faixa etária", independente do que o SO faça, o que pode abrir as portas pra reforçar ainda mais o estado de vigilância em que estamos metidos.

Uma proposta de agenda para a comunidade de Software Livre

Sou pai de um adolescente que hoje tem 16 anos, e desde que ele tinha 13 eu tive que prestar muita atenção no que ele fazia online. Teve bastante conversa, mas qualquer adulto que já precisou convencer uma adolescente de algo com o quê ele discorda a princípio sabe que existem limites pra esse diálogo. Dessa forma, foi inevitável adotar soluções técnicas pra um problema social, pra evitar tanto o excesso de uso, quanto o consumo de conteúdo que não é adequado pra nenhum ser humano, muito menos pra alguém cuja percepção do mundo ainda está em formação.

Na minha opinião, o que sistemas operacionais livres como o Debian devem fazer é fornecer uma ou mais soluções razoáveis de controle parental que sejam capazes de indicar a idade ou faixa etária do usuário atual sem vazar nenhuma outra informação e sem comunicar isso pra além da aplicação que está usando a API disponível para isso. Eu gostaria de ter essa funcionalidade pra quando minha sobrinha de 8 anos vier na minha casa e eu precisar emprestar um sistema pra ela usar.

Eu acredito que o controle parental do GNOME é um ótimo começo, e aparentemente ele está ainda melhor no GNOME 50, que deve chegar no Debian testing Logo™.

Pra mim, os nossos próximos passos devem ser:

Incidir em todos os espaços possíveis pra garantir que o processo de regulação pela ANPD explicite como exatamente projetos de software livre serão tratados com relação ao ECA Digital. Por exemplo, se a ANPD não pretende aplicar a lei a projetos de software livre, precisamos que isso esteja formalizado por escrito.
Monitorar, e quando possível colaborar como o processo de implementação dos mecanismos de aferição de idade pra que as soluções adotadas maximizem a privacidade dos usuários, tanto na camada de sistema operacional quanto para aplicações.
Mostrar como é possível ter soluções livres e auditáveis das eventuais ferramentas que serão necessárias. Por exemplo, pra mim seria fundamental que existisse uma implementação de referência de um serviço de Provas de conhecimento zero que seja empacotável no Debian e que não dependa de instalar um caminhão de dependências de um lugar aleatório na internet e que possa beneficiar seus usuários com o processo de atualizações de segurança da comunidade de software livre.

Pro futuro, acho que o principal aprendizado é que não podemos deixar esse tipo de regulação ser discutida à nossa revelia, e temos que estar preparados pra participar mais ativamente do processo de discussão junto a organizações que fazem esses debates. Nossa capacidade de interferir no processo legislativo em si provavelmente vai ser limitada, mas vamos ter que dar um jeito de depurar leis como essa antes delas serem aprovadas.

No próximo sábado estaremos discutindo este tema na MiniDebConf 2026, que vai acontecer entre 23 e 25 na UNICAMP.

autopkgtest support in Debian: a more optimistic view

2025-09-06T09:19:00Z

Yesterday I posted about the history, in numbers, of the support for autopkgtest in the Debian archive. I had analyzed the presence of a Testsuite: field in source packages, from wheezy to trixie, and noticed a slowdown in the growth rate of autopkgtest support, in proportional terms. In each new release, the percentage of packages declaring a test suite grew less than in the previous release, for the last 4 releases.

A night of sleep and a rainy morning later, I come back with a more optimistic view, and present to you the following data, expanded from the raw data:

Release year	Release	Yes	No	Total	Δ Yes	Δ No	Δ Total
2013	wheezy	5	17170	17175	--	--	--
2015	jessie	1112	19484	20596	1107	2314	3421
2017	stretch	5110	19735	24845	3998	251	4249
2019	buster	9966	18535	28501	4856	-1200	3656
2021	bullseye	13949	16994	30943	3983	-1541	2442
2023	bookworm	17868	16473	34341	3919	-521	3398
2025	trixie	21527	16143	37670	3659	-330	3329

A few observations:

Since stretch, we have been consistently adding autopkgtest support to close to 4,000 packages on each release, on average.
Since buster, the number of packages without autopkgtest support has decreased in the hundreds.
On average, each release has 3,400 packages more than the previous, while also bringing 4,000 extra packages with autopkgtest support. I have the following hypotheses for this:
1. a large part of new packages are added already with autopkgtests;
2. a smaller but reasonably large number of existing packages get autopkgtests added on each release.

All in all, I think this data show that Debian maintainers recognize the usefulness of automated testing and are engaged in improving our QA process.

Past halfway there: history of autopkgtest support in Debian

2025-09-05T20:22:00Z

The Release of Debian 13 ("Trixie") last month marked another milestone on the effort to provide automated test support for Debian packages in their installed form. We have achieved the mark of 57% of the source packages in the archive declaring support for autopkgtest.

Release	Packages with tests	Total number of packages	% of packages with tests
wheezy	5	17175	0%
jessie	1112	20596	5%
stretch	5110	24845	20%
buster	9966	28501	34%
bullseye	13949	30943	45%
bookworm	17868	34341	52%
trixie	21527	37670	57%

The code that generated this table is provided at the bottom.

The growth rate has been consistently decreasing at each release after stretch. That probably means that the low hanging fruit -- adding support en masse for large numbers of similar packages, such as team-maintained packages for a given programming language -- has been picked, and from now on the work gets slightly harder. Perhaps there is a significant long tail of packages that will never get autopkgtest support.

Looking for common prefixes among the packages missing a Testsuite: field gives me us the largest groups of packages missing autopkgtest support:

$ grep-dctrl -v -F Testsuite --regex -s Package -n . trixie | cut -d - -f 1 | uniq -c | sort -n| tail -20
     50 apertium
     50 kodi
     51 lomiri
     53 maven
     55 libjs
     57 globus
     66 cl
     67 pd
     72 lua
     79 php
     88 puppet
     91 r
    111 gnome
    124 ruby
    140 ocaml
    152 rust
    178 golang
    341 fonts
    557 python
   1072 haskell

There seems to be a fair amount of Haskell and Python. If someone could figure out a way of testing installed fonts in a meaningful way, this would a be a good niche where we can cover 300+ packages.

There is a another analysis that can be made, which I didn't: which percentage of new packages introduced in a given release have declared autopkgtest support, compared with the total of new packages in that release? My data only counts the totals, so we start with the technical debt of the almost all of the 17,000 packages with no tests in wheezy, which was the stable at the time I started Debian CI. How many of those got tests since then?

Note that not supporting autopkgtest does not mean that a package is not tested at all: it can run build-time tests, which are also useful. Not supporting autopkgtest, though, means that their binaries in the archive can't be automatically tested in their installed, but then there is a entire horde of volunteers running testing and unstable on a daily basis who test Debian and report bugs.

This is the script that produced the table in the beginning of this post:

#!/bin/sh

set -eu

extract() {
  local release
  local url
  release="$1"
  url="$2"

  if [ ! -f "${release}" ]; then
    rm -f "${release}.gz"
    curl --silent -o ${release}.gz "${url}"
    gunzip "${release}.gz"
  fi

  local with_tests
  local total
  with_tests="$(grep-dctrl -c -F Testsuite --regex . $release)"
  total="$(grep-dctrl -c -F Package --regex . $release)"

  echo "| ${release} | ${with_tests} | ${total} | $((100*with_tests/total))% |"
}

echo "| **Release** | **Packages with tests** | **Total number of packages** | **% of packages with tests** |"
echo "|-------------|-------------------------|------------------------------|------------------------------|"
for release in wheezy jessie stretch buster; do
  extract "${release}" "http://archive.debian.org/debian/dists/${release}/main/source/Sources.gz"
done
for release in bullseye bookworm trixie; do
  extract "${release}" "http://ftp.br.debian.org/debian/dists/${release}/main/source/Sources.gz"
done

gotcha: using ccache in Debian package builds

2024-09-08T12:18:00Z

Before I upload packages to Debian, I always do a full build from source under sbuild. This ensures that the package can build from source on a clean environment, implying that the set of build dependencies is complete.

But when iterating on a non-trivial package locally, I will usually build the package directly on my Debian testing system, and I want to take advantage of ccache to cache native (C/C++) code compilation to speed things up. In Debian, the easiest way to enable ccache is to add /usr/lib/ccache to your $PATH. I do this by doing something similar to the following in my ~/.bashrc:

export PATH=/usr/lib/ccache:$PATH

I noticed, however, that my Debian package builds were not using the cache. When building the same small package manually using make, the cache was used, but not when the build was wrapped with dpkg-buildpackage.

I tracked it down to the fact that in compatibility level 13+, debhelper will set $HOME to a temporary directory. For what's it worth, I think that's a good thing: you don't want package builds reaching for your home directory as that makes it harder to make builds reproducible, among other things.

This behavior, however, breaks ccache. The default cache directory is $HOME/.ccache, but that only gets resolved when ccache is actually used. So we end up starting with an empty cache on each build, get a 100% cache miss rate, and still pay for the overhead of populating the cache.

The fix is to explicitly set $CCACHE_DIR upfront, so that by the time $HOME gets overriden, it doesn't matter anymore for ccache. I did this in my ~/.bashrc:

export CCACHE_DIR=$HOME/.ccache

This way, $HOME will be expanded right there when the shell starts, and by the time ccache is called, it will use the persistent cache in my home directory even though $HOME will, at that point, refer to a temporary directory.

Debian CI: 10 years later

2023-12-28T15:00:00Z

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.

Triaging Debian build failure logs with collab-qa-tools

2021-10-12T08:30:00Z

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 made some improvements 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  | sed -e 's/$/ -- TODO/' > 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/sh

set -eu

for todo in $@; do
  # force downloading bugs
  awk '{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: {{ version | split:'+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):
{% for line in extract %}> {{ line }}
{% endfor %}

The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/{{ package }}/{{ filename | replace:".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.

Getting help with autopkgtest for your package

2021-07-19T21:00:00Z

If you have been involved in Debian packaging at all in the last few years, you are probably aware that autopkgtest is now an important piece of the Debian release process. Back in 2018, the automated testing migration process started considering autopkgtest test results as part of its decision making.

Since them, this process has received several improvements. For example, during the bullseye freeze, non-key packages with a non-trivial autopkgtest test suite could migrate automatically to testing without their maintainers needing to open unblock requests, provided there was no regression in theirs autopkgtest (or those from their reverse dependencies).

Since 2014 when ci.debian.net was first introduced, we have seen an amazing increase in the number of packages in Debian that can be automatically tested. We went from around 100 to 15,000 today. This means not only happier maintainers because their packages get to testing faster, but also improved quality assurance for Debian as a whole.

However, the growth rate seems to be decreasing. Maybe the low hanging fruit have all been picked, or maybe we just need to help more people jump in the automated testing bandwagon.

With that said, we would like to encourage and help more maintainers to add autopkgtest to their packages. To that effect, I just created the autopkgtest-help repository on salsa, where we will take help requests from maintainers working on autopkgtest for their packages.

If you want help, please go ahead and create an issue in there. To quote the repository README:

Valid requests:

"I want to add autopkgtest to package X. X is a tool that [...] and it works by [...]. How should I approach testing it?"

It's OK if you have no idea where to start. But at least try to describe your package, what it does and how it works so we can try to help you.

"I started writing autopkgtest for X, here is my current work in progress [link]. But I encountered problem Y. How to I move forward?"

If you already have an autopkgtest but is having trouble making it work as you think it should, you can also ask here.

Invalid requests:

"Please write autopkgtest for my package X for me".

As with anything else in free software, please show appreciation for other people's time, and do your own research first. If you pose your question with enough details (see above) and make it interesting, it may be that whoever answers will write at least a basic structure for you, but as the maintainer you are still the expert in the package and what tests are relevant.

If you ask your question soon, you might get your answer recorded in video: we are going to have a DebConf21 talk next month, where we I and Paul Gevers (elbrus) will answer a few autopkgtest questions in video for posterity.

Now, if you have experience enabling autopkgtest for you own packages, please consider watching that repository there to help us help our fellow maintainers.

Debian Continuous Integration now using Salsa logins

2021-06-27T13:00:00Z

I have just updated the Debian Continuous Integration platform with debci 3.1.

This update brings a few database performance improvements, courtesy of adding indexes to very important columns that were missing them. And boy, querying a table with 13 million rows without the proper indexes is bad! :-)

Now, the most user visible change in this update is the change from Debian SSO to Salsa Logins, which is part of Pavit Kaur's GSoC work. She has been working with me and Paul Gevers for a few weeks, and this was the first official task in the internship.

For users, this means that you now can only log in via Salsa. If you have an existing session where you logged in with an SSO certificate, it will still be valid. When you log in with Salsa, your username will be changed to match the one in Salsa. This means that if your account on salsa gets renamed, it will automatically be renamed on Debian CI when you log in the next time. Unfortunately we don't have a logout feature yet, but in the meantime you can use the developer toolbar to delete any existing cookies you might have for ci.debian.net.

Migrating to Salsa logins was in my TODO list for a while. I had the impression that it could do it pretty quick to do by using pre-existing libraries that provide gitlab authentication integration for Rack (Ruby's de facto standard web application interface, like uwsgi for Python). But in reality, the devil was in the details.

We went through several rounds of reviews to get it right. During the entire process, Pavit demonstrated an excelent capacity for responding to feedback, and overall I'm very happy with her performance in the internship so far.

While we were discussing the Salsa logins, we noted a limitation in the existing database structure, where we stored usernames directly as the test requestor field, and decided it was better to normalize that relationship with a proper foreign key to the users table, which she also worked on.

This update also include the very first (and non-user visible) step of her next task, which is adding support for having private tests. Those will be useful for implementing testing for embargoed security updates, and other use cases. This was broken up into 7 or 8 seperate steps, so there is still some work to do there. I'm looking forward to the continuation of this work.

pristine-tar updates

2017-10-09T15:06:00Z

Introduction

pristine-tar is a tool that is present in the workflow of a lot of Debian people. I adopted it last year after it has been orphaned by its creator Joey Hess. A little after that Tomasz Buchert joined me and we are now a functional two-person team.

pristine-tar goals are to import the content of a pristine upstream tarball into a VCS repository, and being able to later reconstruct that exact same tarball, bit by bit, based on the contents in the VCS, so we don’t have to store a full copy of that tarball. This is done by storing a binary delta files which can be used to reconstruct the original tarball from a tarball produced with the contents of the VCS. Ultimately, we want to make sure that the tarball that is uploaded to Debian is exactly the same as the one that has been downloaded from upstream, without having to keep a full copy of it around if all of its contents is already extracted in the VCS anyway.

The current state of the art, and perspectives for the future

pristine-tar solves a wicked problem, because our ability to reconstruct the original tarball is affected by changes in the behavior of tar and of all of the compression tools (gzip, bzip2, xz) and by what exact options were used when creating the original tarballs. Because of this, pristine-tar currently has a few embedded copies of old versions of compressors to be able to reconstruct tarballs produced by them, and also rely on a ever-evolving patch to tar that is been carried in Debian for a while.

So basically keeping pristine-tar working is a game of Whac-A-Mole. Joey provided a good summary of the situation when he orphaned pristine-tar.

Going forward, we may need to rely on other ways of ensuring integrity of upstream source code. That could take the form of signed git tags, signed uncompressed tarballs (so that the compression doesn’t matter), or maybe even a different system for storing actual tarballs. Debian bug #871806 contains an interesting discussion on this topic.

Recent improvements

Even if keeping pristine-tar useful in the long term will be hard, too much of Debian work currently relies on it, so we can’t just abandon it. Instead, we keep figuring out ways to improve. And I have good news: pristine-tar has recently received updates that improve the situation quite a bit.

In order to be able to understand how better we are getting at it, I created a "visualization of the regression test suite results. With the help of data from there, let’s look at the improvements made since pristine-tar 1.38, which was the version included in stretch.

pristine-tar 1.39: xdelta3 by default.

This was the first release made after the stretch release, and made xdelta3 the default delta generator for newly-imported tarballs. Existing tarballs with deltas produced by xdelta are still supported, this only affects new imports.

The support for having multiple delta generator was written by Tomasz, and was already there since 1.35, but we decided to only flip the switch after using xdelta3 was supported in a stable release.

pristine-tar 1.40: improved compression heuristics

pristine-tar uses a few heuristics to produce the smaller delta possible, and this includes trying different compression options. In the release Tomasz included a contribution by Lennart Sorensen to also try --gnu, which greatly improved the support for rsyncable gzip compressed files. We can see an example of the type of improvement we got in the regression test suite data for delta sizes for faad2_2.6.1.orig.tar.gz:

pristine-tar 1.41: support for signatures

This release saw the addition of support for storage and retrieval of upstream signatures, contributed by Chris Lamb.

pristine-tar 1.42: optionally recompressing tarballs

I had this idea and wanted to try it out: most of our problems reproducing tarballs come from tarballs produced with old compressors, or from changes in compressor behavior, or from uncommon compression options being used. What if we could just recompress the tarballs before importing then? Yes, this kind of breaks the “pristine” bit of the whole business, but on the other hand, 1) the contents of the tarball are not affected, and 2) even if the initial tarball is not bit by bit the same that upstream release, at least future uploads of that same upstream version with Debian revisions can be regenerated just fine.

In some cases, as the case for the test tarball util-linux_2.30.1.orig.tar.xz, recompressing is what makes it possible to reproduce the tarball (and thus import it with pristine-tar) possible at all:

In other cases, if the current heuristics can’t produce a reasonably small delta, recompressing makes a huge difference. It’s the case for mumble_1.1.8.orig.tar.gz:

Recompressing is not enabled by default, and can be enabled by passing the --recompress option. If you are using pristine-tar via a wrapper tool like gbp-buildpackage, you can use the $PRISTINE_TAR environment variable to set options that will affect any pristine-tar invocations.

Also, even if you enable recompression, pristine-tar will only try it if the delta generations fails completely, of if the delta produced from the original tarball is too large. You can control what “too large” means by using the --recompress-threshold-bytes and --recompress-threshold-percent options. See the pristine-tar(1) manual page for details.

Debian CI: new data retention policy

2017-05-28T21:20:00Z

When I started debci for Debian CI, I went for the simplest thing that could possibly work. One of the design decisions was to use the filesystem directly for file storage. A large part of the Debian CI data is log files and test artifacts (which are just files), and using the filesystem directly for storage makes it a lot easier to handle it. The rest of the data which is structured (test history and status of packages) is stored as JSON files.

Another nice benefit of using the filesystem like this is that I get a sort of REST API for free by just exposing the file storage to the web. For example, getting the latest test status of debci itself on unstable/amd64 is as easy as:

$ curl https://ci.debian.net/data/packages/unstable/amd64/d/debci/latest.json
{
  "run_id": "20170528_173652",
  "package": "debci",
  "version": "1.5.1",
  "date": "2017-05-28 17:43:05",
  "status": "pass",
  "blame": [],
  "previous_status": "pass",
  "duration_seconds": "373",
  "duration_human": "0h 6m 13s",
  "message": "Tests passed, but at least one test skipped",
  "last_pass_version": "1.5.1",
  "last_pass_date": "2017-05-28 17:43:05"
}

Now, nothing in life is without compromises. One big disadvantage of the way debci stored its data is that there were a lot of files, which ends up using a large number of inodes in the filesystem. The current Debian CI master has more than 10 million inodes in its filesystem, and almost all of them were being used. This is clearly unsustainable.

You will notice that I said stored, because as of version 1.6, debci now implements a data retention policy: log files and test artifacts will now only be kept for a configurable amount of days (default: 180).

So there you have it: effective immediately, Debian CI will not provide logs and test artifacts older than 180 days.

If you are reporting bugs based on logs from Debian CI, please don’t hotlink the log files. Instead, make sure you download the logs in question and attach them to the bug report, because in 6 months they will be gone.