Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft

[Steve McIntyre]

[ Please note the cross-post and respect the Reply-To... ]

Hi folks,

This has taken a while in coming, for which I apologise. There's a lot
of work involved in rebuilding the whole Debian archive, and many many
hours spent analysing the results. You learn quite a lot, too! :-)

I promised way back before DC18 that I'd publish the results of the
rebuilds that I'd just started. Here they are, after a few false
starts. I've been rebuilding the archive *specifically* to check if we
would have any problems building our 32-bit Arm ports (armel and
armhf) using 64-bit arm64 hardware. I might have found other issues
too, but that was my goal.

The logs for all my builds are online at

  https://www.einval.com/debian/arm/rebuild-logs/

for reference. See in particular

  https://www.einval.com/debian/arm/rebuild-logs/armel/FAIL/FAIL.html
  https://www.einval.com/debian/arm/rebuild-logs/armhf/FAIL/FAIL.html

for automated analysis of the build logs that I've used as the basis
for the stats below.

Executive summary
=

As far as I can see we're basically fine to use arm64 hosts for
building armel and armhf, *so long as* those hosts include hardware
support for the 32-bit A32 instruction set. As I've mentioned before
[1] that's not a given on *all* arm64 machines, but there are
sufficient machine types available that I think we should be
fine. There are a couple of things we need to do in terms of setup -
see "Machine configuration" below.

[1] https://lists.debian.org/debian-arm/2018/06/msg00062.html

Methodology
===

I (naïvely) just attempted to rebuild all the source packages in
unstable main, at first using pbuilder to control the build process
and then later using sbuild instead. I didn't think to check on the
stated architectures listed for the source packages, which was a
mistake - I would do it differently if redoing this test. That will
have contributed quite a large number of failures in the stats below,
but I believe I have accounted for them in my analysis.

I built lots of packages, using a range of machines in a small build
farm at home:

 * Macchiatobin
 * Seattle
 * Synquacer
 * Multiple Mustangs

using my local mirror for improved performance when fetching
build-deps etc. I started off with a fixed list of packages that were
in unstable when I started each rebuild, for the sake of
simplicity. That's one reason why I have two different numbers of
source packages attempted for each arch below. If packages failed due
to no longer being available, I simply requeued using the latest
version in unstable at that point.

I then developed a script to scan the logs of failed builds to pick up
on patterns that matched with obvious causes. Once that was done, I
worked through all the failures to (a) verify those patterns, and (b)
identify any other failures. I've classified many of the failures to
make sense of the results. I've also scanned the BTS for existing bugs
matching my failed builds (and linked to them), or filed new bugs
where I could not find matches.

I did *not* investigate fully every build failure. For example, where
a package has never been built before on armel or armhf and failed
here I simply noted that fact. Many of those are probably real bugs,
but beyond the scope of my testing.

For reference, all my scripts and config are in git at

  https://git.einval.com/cgi-bin/gitweb.cgi?p=buildd-scripts.git

armel results
=

Total source packages attempted: 28457
Successfully built:  25827
Failed:   2630

Almost half of the failed builds were simply due to the lack of a
single desired build dependency (nodejs:armel, 1289). There were a
smattering of other notable causes:

 * 100 log(s) showing build failures (java/javadoc)

   Java build failures seem particularly opaque (to me!), and in many
   cases I couldn't ascertain if it was a real build problem or just
   maven being flaky. :-(

 * 15 log(s) showing Go 32-bit integer overflow

   Quite a number of go packages are blindly assuming sizes for 64-bit
   hosts. That's probably fair, but seems unfortunate.

 * 8 log(s) showing Sbuild build timeout

   I was using quite a generous timeout (12h) with sbuild, but still a
   very small number of packages failed. I'd earlier abandoned
   pbuilder for sbuild as I could not get it to behave sensibly with
   timeouts.

The stats that matter are the arch-specific failures for armel:

  * 13 log(s) showing Alignment problem
  * 5 log(s) showing Segmentation fault
  * 1 log showing Illegal instruction

and the new bugs I filed:

  * 3 bugs for arch misdetection
  * 8 bugs for alignment problems
  * 4 bugs for arch-specific test failures
  * 3 bugs for arch-specific misc failures

Considering the number of package builds here, I think these numbers
are basically noise. The vast majority of the failures I found were
either already known in the BTS (260), unrelated to what I was looking
for, or both.

See below for more details about 

Bug#918379: please decide: severity of "fails to purge" issues

[Andreas Beckmann]

>   h01ger: what does 'fails to purge' mean? the purge fails (gives
>  errors) or the purge 'succeeds', but files are left?

The failures intended to be raised to serious are all the cases where
maintainer scripts will fail - ususally in some corner cases depending
on (worst-case but dependency-wise valid) ordering of removal and purge
of the involved packages.
All known bugs of this kind (as of Dec.) are filed. New ones will either
be regressions or be newly introduced with new packages. The piuparts
failures of these already block migration, so filing the corresponding
bugs as serious seems to be justified.
In the old times, there were many packages using e.g. ucf incorrectly,
and would have caused a lot of RC bugs, but these have been fixed over
the years.

Leaving files around after purge is a separate that will continue to be
filed as important.


Andreas

Gerador de sistemas + 4 SISTEMAS COMPLETOS

[Envie 3 MILHÕES de emails ao dia]

Convidamos você a adquirir o melhor Gerador de Sistemas do mercado com PREÇO DE 
CUSTO.

Crie sistemas SEM PRECISAR SABER PROGRAMAR.

Você poderá adquirir o Logic Line por SOMENTE R$ 198 até Sexta-Feira, 
07/01/2019 e receber:

- Logic Line - Gerador de sistemas e ferramenta de desenvolvimento completa
- 4 sistemas completos, que você pode modificar a até comercializar.
. Sistema de vendas integrado com estoque e contas a pagar e a receber.
. Sistema de telemensagens.
. Sistema de imobiliária.
. Sistema com múltiplos exemplos de desenvolvimento.
- O Logic Line e os sistemas gerador rodam em todos os Windows (32-bit e 64-bit)
- Manuais e exemplos completos de utilização.
- Suporte gratuito por 1 ano.

Você pode fazer uma transferência Santander ou TED/DOC do seu banco:

Banco : Santander (033)
Agência : 3216
onta Corrente : 01005821-9
Titular : Ulisses Teixeira Corbett
CPF: 038.839.887-66
Valor: R$ 198 - Logic Line 1.9 completo + 4 sistemas


ALGUMAS CARACTERÍSTICAS DO LOGIC LINE:

- O Logic Line é uma linguagem visual e interativa, de forma
que você não utiliza nenhuma outra linguagem com ele. Basta
aprender os recursos do Logic Line para desenvolver qualquer
sistema. O Logic Line gera os .EXE(executáveis) dos sistemas
diretamente.
- O Logic Line roda em qualquer computador do mercado, em
qualquer Windows, do Windows 95 ao Windows 10, assim como
todos os sistemas criados com ele.
- Todos os sistemas feitos com o Logic Line rodam automaticamente
em rede, sendo que também existem comandos específicos no Logic Line
para a manipulação dos sistemas em rede.
- Os executáveis(.EXE) dos sistemas gerados pelo Logic Line
são de propriedade do usuário do Logic Line. Por isso, você pode
distribuir e comercializar livremente os sistemas desenvolvidos,
sem precisar pagar nada.
- Com o Logic Line, você pode se comunicar com qualquer outra
aplicação, através da importação e exportação de arquivos texto,
em qualquer formato.
- Cada sistema pode ter até 64.000 arquivos. Cada arquivo pode ter até
4 BILHÕES de registros, sem perda de performance.
- Qualquer combinação de relacionamento de arquivos pode ser feita
utilizando o Logic Line, sem limitações.
- O Logic Line possui dezenas de recursos multimídia para os sistemas,
como fotos, vídeos, músicas e outros, inclusive ligados aos bancos de dados.
- O Logic Line possui alteração automática de base de dados no cliente final
em caso de alteração de estrutura dos dados, sem precisar desenvolver programas
de conversão de dados.
- Não há necessidade de reindexação dos arquivos em caso de queda de luz ou
outros problemas, porque a tecnologia dos arquivos de dados mantém os índices
no mesmo arquivo físico dos dados, com total garantia de integridade.
- O Logic Line possui criação visual de janelas, inputs, botões, gráficos
estatísticos (linha, barra, pizza, área, etc), molduras, consultas por listas
(browses) e muitos outros objetos. Ele também possui criação rápida e visual
de relatórios e etiquetas, bem como de qualquer outro processamento no sistema.
- O Logic Line traz a possibilidade de criação de novos recursos, com
combinação infinita dos recursos existentes.
- O Logic Line permite a comunicação com qualquer hardware externo,
como impressoras fiscais, leitores e impressoras de código de barra, etc.
- O Logic Line permite a chamada de programas externos por dentro dos
sistemas desenvolvidos, tornando as aplicações ainda mais abrangentes.
- Muitos outros recursos.
Você terá a melhor ferramenta de criação de sistemas, com o melhor preço,
e o melhor atendimento.
facilitando o aprendizado rápido.


Após o depósito, envie-nos um email com os seguintes dados:

---
Nome ou Razão Social :
Endereço :
Bairro   :
Cidade   :
Estado(UF)   :
CEP  :
Telefone :
Telefone 2(opcional) :
Email:
Email 2(opcional):
Pessoa para contato  :
Data do depósito: __/__/2019
---

Conte sempre com a gente.

Abraços dos amigos da


Corbett Software
Os melhores programas desde 1998

WhatsApp/Telefone:
22-99788-1694
Skype:
corbettsoftware

Processed: retitle 918257 to RM: toggle-proxy -- RoQA; incompatible with newer firefox-esr versions ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 918257 RM: toggle-proxy -- RoQA; incompatible with newer firefox-esr 
> versions
Bug #918257 [release.debian.org] RM: toggle-proxy/1.9-2
Changed Bug title to 'RM: toggle-proxy -- RoQA; incompatible with newer 
firefox-esr versions' from 'RM: toggle-proxy/1.9-2'.
> tags 918257 + stretch pending
Bug #918257 [release.debian.org] RM: toggle-proxy -- RoQA; incompatible with 
newer firefox-esr versions
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
918257: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918257
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: retitle 918258 to RM: mozilla-password-editor -- RoQA; incompatible with newer firefox-esr versions ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 918258 RM: mozilla-password-editor -- RoQA; incompatible with newer 
> firefox-esr versions
Bug #918258 [release.debian.org] RM: mozilla-password-editor/2.10.3-1
Changed Bug title to 'RM: mozilla-password-editor -- RoQA; incompatible with 
newer firefox-esr versions' from 'RM: mozilla-password-editor/2.10.3-1'.
> tags 918258 + stretch pending
Bug #918258 [release.debian.org] RM: mozilla-password-editor -- RoQA; 
incompatible with newer firefox-esr versions
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
918258: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918258
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: retitle 918254 to RM: imap-acl-extension -- RoQA; incompatible with newer firefox-esr versions ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 918254 RM: imap-acl-extension -- RoQA; incompatible with newer 
> firefox-esr versions
Bug #918254 [release.debian.org] RM: imap-acl-extension/0.2.7-1
Changed Bug title to 'RM: imap-acl-extension -- RoQA; incompatible with newer 
firefox-esr versions' from 'RM: imap-acl-extension/0.2.7-1'.
> tags 918254 + stretch pending
Bug #918254 [release.debian.org] RM: imap-acl-extension -- RoQA; incompatible 
with newer firefox-esr versions
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
918254: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918254
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: retitle 918350 to RM: spice-xpi -- RoQA; incompatible with newer firefox-esr versions, tagging 918350

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 918350 RM: spice-xpi -- RoQA; incompatible with newer firefox-esr 
> versions
Bug #918350 [release.debian.org] RM: spice-xpi/2.8.90-5
Changed Bug title to 'RM: spice-xpi -- RoQA; incompatible with newer 
firefox-esr versions' from 'RM: spice-xpi/2.8.90-5'.
> tags 918350 + stretch pending
Bug #918350 [release.debian.org] RM: spice-xpi -- RoQA; incompatible with newer 
firefox-esr versions
Added tag(s) stretch and pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
918350: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918350
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: retitle 918346 to RM: firefox-kwallet5 -- RoQA; incompatible with newer firefox-esr versions ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 918346 RM: firefox-kwallet5 -- RoQA; incompatible with newer 
> firefox-esr versions
Bug #918346 [release.debian.org] RM: firefox-kwallet5/1.0-2
Changed Bug title to 'RM: firefox-kwallet5 -- RoQA; incompatible with newer 
firefox-esr versions' from 'RM: firefox-kwallet5/1.0-2'.
> tags 918346 + stretch pending
Bug #918346 [release.debian.org] RM: firefox-kwallet5 -- RoQA; incompatible 
with newer firefox-esr versions
Added tag(s) stretch and pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
918346: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918346
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: retitle 918347 to RM: adblock-plus -- RoQA; incompatible with newer firefox-esr versions ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 918347 RM: adblock-plus -- RoQA; incompatible with newer firefox-esr 
> versions
Bug #918347 [release.debian.org] RM: adblock-plus/2.7.3+dfsg-1
Changed Bug title to 'RM: adblock-plus -- RoQA; incompatible with newer 
firefox-esr versions' from 'RM: adblock-plus/2.7.3+dfsg-1'.
> tags 918347 + stretch pending
Bug #918347 [release.debian.org] RM: adblock-plus -- RoQA; incompatible with 
newer firefox-esr versions
Added tag(s) stretch and pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
918347: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918347
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: retitle 918349 to RM: mozilla-dom-inspector -- RoQA; incompatible with newer firefox-esr versions ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 918349 RM: mozilla-dom-inspector -- RoQA; incompatible with newer 
> firefox-esr versions
Bug #918349 [release.debian.org] RM: mozilla-dom-inspector/1:2.0.16-2
Changed Bug title to 'RM: mozilla-dom-inspector -- RoQA; incompatible with 
newer firefox-esr versions' from 'RM: mozilla-dom-inspector/1:2.0.16-2'.
> tags 918349 + stretch pending
Bug #918349 [release.debian.org] RM: mozilla-dom-inspector -- RoQA; 
incompatible with newer firefox-esr versions
Added tag(s) pending and stretch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
918349: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918349
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#918372: unblock: med-fichier/4.0.0+repack-6

[Adrian Bunk]

On Sun, Jan 06, 2019 at 08:28:33PM +0100, Paul Gevers wrote:
> Hi Adrian, Niels,

Hi Paul,

> On 06-01-2019 20:01, Adrian Bunk wrote:
> >> That is because gmsh from testing links to libmed1v5. Adding this
> >> *versioned* breaks to libmed11 (albeit being a bit ridiculous from the
> >> archive point of view) would do the right thing AFAICT.
> >> ...
> > 
> > despite libmed11 not being installed at all in the debci test?
> 
> britney reads this to determine which packages (based on SRC) need to
> come from unstable for testing in testing.
> 
> > You are saying that the (test) dependencies of gmsh/unstable matter when
> > testing gmsh/testing with med-fichier/unstable?
> 
> Yes, because they are processed by britney. So if gmsh/testing and
> med-fichier/unstable aren't a good match based on information that
> britney has available, it will request the test with both from unstable.
> britney looks at the regular Depends/Breaks/Conflicts fields as well as
> the test dependencies.
> 
> > That's unexpected compared to the normal dependency semantics.
> 
> I agree, but this is how it is done now until we change it. We're open
> for suggestions and I assume the release team is open for patches as well.

when there is a reason for a maintainer to declare that a new upload 
breaks the autopkgtest only of a reverse dependency, the logical
way would be someting like
  X-Breaks-Autopkgtest-Of: gmsh (<< 3.0.6+dfsg1-4+b1)

This would be a proper interface for maintainers that doesn't expose 
whatever black magic britney+debci are doing.

> >>> The root problem is that debci installs cruft packages from unstable.
> >>
> >> Care to elaborate what you mean here? debci doesn't install anything.
> >> It's apt that installs stuff. Based on a slightly odd configuration put
> >> in place by autopkgtest on request of debci which got its trigger from
> >> britney.
> > 
> > Britney says for med-fichier:
> > old binaries left on amd64: libmed1v5, libmedc1v5 (from 4.0.0+repack-1) 
> > (but ignoring cruft, so nevermind)
> > 
> > Installing one of these cruft packages that cannot ever migrate to 
> > testing is the problem.
> 
> Sure, but the root cause is that the combination to test isn't properly
> determined by britney. britney just doesn't know.

Britney says in excuses that the package is cruft.

> > Correct would be that this debci test does not pull in a single package
> > from unstable, since no non-cruft package depended on from gmsh/testing 
> > is being provided by med-fichier/unstable.
> 
> I don't agree. What we want to test is what happens if med-fichier has
> performed the transition from libmed5v1 to libmed11 and we try to move
> the set to testing.

Note that with smooth updates this is not a "set" - it does happen that 
a so-name changing library package migrates to testing before any of the 
reverse dependencies has been rebuilt.

With the new de facto default of 2 days for migrations it is not even rare.

The med-fichier binNMUs were 3 days after med-fichier was uploaded.
Without this debci issue med-fichier would have already migrated
before gmsh was binNMUed in unstable.

> Paul

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#918372: unblock: med-fichier/4.0.0+repack-6

[Paul Gevers]

Hi Adrian, Niels,

On 06-01-2019 20:01, Adrian Bunk wrote:
>> That is because gmsh from testing links to libmed1v5. Adding this
>> *versioned* breaks to libmed11 (albeit being a bit ridiculous from the
>> archive point of view) would do the right thing AFAICT.
>> ...
> 
> despite libmed11 not being installed at all in the debci test?

britney reads this to determine which packages (based on SRC) need to
come from unstable for testing in testing.

> You are saying that the (test) dependencies of gmsh/unstable matter when
> testing gmsh/testing with med-fichier/unstable?

Yes, because they are processed by britney. So if gmsh/testing and
med-fichier/unstable aren't a good match based on information that
britney has available, it will request the test with both from unstable.
britney looks at the regular Depends/Breaks/Conflicts fields as well as
the test dependencies.

> That's unexpected compared to the normal dependency semantics.

I agree, but this is how it is done now until we change it. We're open
for suggestions and I assume the release team is open for patches as well.

>>> The root problem is that debci installs cruft packages from unstable.
>>
>> Care to elaborate what you mean here? debci doesn't install anything.
>> It's apt that installs stuff. Based on a slightly odd configuration put
>> in place by autopkgtest on request of debci which got its trigger from
>> britney.
> 
> Britney says for med-fichier:
> old binaries left on amd64: libmed1v5, libmedc1v5 (from 4.0.0+repack-1) (but 
> ignoring cruft, so nevermind)
> 
> Installing one of these cruft packages that cannot ever migrate to 
> testing is the problem.

Sure, but the root cause is that the combination to test isn't properly
determined by britney. britney just doesn't know.

> Correct would be that this debci test does not pull in a single package
> from unstable, since no non-cruft package depended on from gmsh/testing 
> is being provided by med-fichier/unstable.

I don't agree. What we want to test is what happens if med-fichier has
performed the transition from libmed5v1 to libmed11 and we try to move
the set to testing.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#918501: transition: re2

[Stefano Rivera]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

re2 is a C++ regex library, requiring about a transition a year, for
various symbol changes.

Only 6 reverse dependencies in testing.
The automated ben file looks fine:
https://release.debian.org/transitions/html/auto-re2.html

I've uploaded to experimental and test-built all of the reverse-deps. No
regressions in amd64 buildability of them. Everything that's in testing
rebuilt without patching.

Still waiting for some MIPS*el builds, but those could take weeks... And
not expecting any new FTBFS - I've test-built them on the porterbox.

reportbug ben file:

title = "re3";
is_affected = .depends ~ "libre2-4" | .depends ~ "libre2-5";
is_good = .depends ~ "libre2-5";
is_bad = .depends ~ "libre2-4";

SR

Bug#918372: unblock: med-fichier/4.0.0+repack-6

[Adrian Bunk]

On Sun, Jan 06, 2019 at 07:34:15PM +0100, Paul Gevers wrote:
> Hi Adrian,

Hi Paul,

> On 06-01-2019 19:05, Adrian Bunk wrote:
> > On Sun, Jan 06, 2019 at 12:35:05PM +0100, Paul Gevers wrote:
> >> Hi Gilles,
> >>
> >> On Sat, 05 Jan 2019 17:04:05 +0100 Gilles Filippini  
> >> wrote:
> >>> Please unblock package med-fichier. Is has currently to wait for 43 days
> >>> because of an autopkgtest regression against the version of gmsh in 
> >>> testing
> >>> (3.0.6+dfsg1-4) [1]. But it succeeds against version 3.0.6+dfsg1-4.1 in
> >>> unstable [1] which waiting for med-fichier to migrate [2].
> >>
> >> You can also handle this yourself by one of the following solutions:
> >>
> >> - in med-fichier: in any of the binary packages add a *versioned* breaks
> >> on any of the binary packages from gmsh.
> > 
> > There is no package where you could place such a Breaks.
> > 
> > The only package the gmsh autopkgtest picks up from unstable is the 
> > broken cruft package libmed1v5.
> 
> That is because gmsh from testing links to libmed1v5. Adding this
> *versioned* breaks to libmed11 (albeit being a bit ridiculous from the
> archive point of view) would do the right thing AFAICT.
>...

despite libmed11 not being installed at all in the debci test?

> >> - in gmsh: add a *versioned* test dependency on any of the med-fichier
> >> binary packages
> > 
> > This won't help since gmsh/testing is being tested.
> 
> Sure, but by adding this, britney will request debci to use the
> autopkgtest of gmsh from unstable rather than from testing.
>...
> >> The result of any of the actions above is that the autopkgtests will be
> >> done with both packages from unstable and will be used for both
> >> migrations. I didn't spend the time on the relations to see which is
> >> most appropriate in your case.
> > 
> > I don't think any of the above would help.
> 
> We disagree than. However, as I wrote the code in britney, let's assume
> I am right then?

You are saying that the (test) dependencies of gmsh/unstable matter when
testing gmsh/testing with med-fichier/unstable?

That's unexpected compared to the normal dependency semantics.

> > The root problem is that debci installs cruft packages from unstable.
> 
> Care to elaborate what you mean here? debci doesn't install anything.
> It's apt that installs stuff. Based on a slightly odd configuration put
> in place by autopkgtest on request of debci which got its trigger from
> britney.

Britney says for med-fichier:
old binaries left on amd64: libmed1v5, libmedc1v5 (from 4.0.0+repack-1) (but 
ignoring cruft, so nevermind)

Installing one of these cruft packages that cannot ever migrate to 
testing is the problem.

Correct would be that this debci test does not pull in a single package
from unstable, since no non-cruft package depended on from gmsh/testing 
is being provided by med-fichier/unstable.

> Paul

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#918372: unblock: med-fichier/4.0.0+repack-6

[Gilles Filippini]

Paul Gevers a écrit le 06/01/2019 à 19:34 :
> Hi Adrian,
> 
> On 06-01-2019 19:05, Adrian Bunk wrote:
[...]
>> The root problem is that debci installs cruft packages from unstable.
> 
> Care to elaborate what you mean here? debci doesn't install anything.
> It's apt that installs stuff. Based on a slightly odd configuration put
> in place by autopkgtest on request of debci which got its trigger from
> britney.

See the log for the failing test [1]:
...
Get:78 http://deb.debian.org/debian unstable/main amd64 libmed1v5 amd64 
4.0.0+repack-1 [439 kB]
...

libmed1v5 4.0.0+repack-1 is a *broken*cruft* package picked up by apt
during autopkgtest. If I hadn't uploaded this broken package in the first
place apt would have picked up libmed1v5 3.3.1+repack-4 instead, and
autopkgtest would have been successful.

[1] https://ci.debian.net/data/autopkgtest/testing/amd64/g/gmsh/1651956/log.gz

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#918372: unblock: med-fichier/4.0.0+repack-6

[Paul Gevers]

Hi Adrian,

On 06-01-2019 19:05, Adrian Bunk wrote:
> On Sun, Jan 06, 2019 at 12:35:05PM +0100, Paul Gevers wrote:
>> Hi Gilles,
>>
>> On Sat, 05 Jan 2019 17:04:05 +0100 Gilles Filippini  wrote:
>>> Please unblock package med-fichier. Is has currently to wait for 43 days
>>> because of an autopkgtest regression against the version of gmsh in testing
>>> (3.0.6+dfsg1-4) [1]. But it succeeds against version 3.0.6+dfsg1-4.1 in
>>> unstable [1] which waiting for med-fichier to migrate [2].
>>
>> You can also handle this yourself by one of the following solutions:
>>
>> - in med-fichier: in any of the binary packages add a *versioned* breaks
>> on any of the binary packages from gmsh.
> 
> There is no package where you could place such a Breaks.
> 
> The only package the gmsh autopkgtest picks up from unstable is the 
> broken cruft package libmed1v5.

That is because gmsh from testing links to libmed1v5. Adding this
*versioned* breaks to libmed11 (albeit being a bit ridiculous from the
archive point of view) would do the right thing AFAICT.

> No package that is still built by med-fichier/unstable is installed
> in the relevant autopkgtest.

Sure, that is because not *both* gmsh and med-fichier come from
unstable, if they were (I'll trigger a test run to prove my point), gmsh
would install libmed11 AFAICT.

>> - in gmsh: add a *versioned* test dependency on any of the med-fichier
>> binary packages
> 
> This won't help since gmsh/testing is being tested.

Sure, but by adding this, britney will request debci to use the
autopkgtest of gmsh from unstable rather than from testing.

> And gmsh can't migrate before med-fichier.

But autopkgtests / apt don't care about that.

>> - in gmsh: in any of the binary packages add a *versioned* dependency on
>> any of the binary packages from med-fichier
> 
> This won't help since gmsh/testing is being tested.
> And gmsh can't migrate before med-fichier.

Same as above.

>> The result of any of the actions above is that the autopkgtests will be
>> done with both packages from unstable and will be used for both
>> migrations. I didn't spend the time on the relations to see which is
>> most appropriate in your case.
> 
> I don't think any of the above would help.

We disagree than. However, as I wrote the code in britney, let's assume
I am right then?

> The root problem is that debci installs cruft packages from unstable.

Care to elaborate what you mean here? debci doesn't install anything.
It's apt that installs stuff. Based on a slightly odd configuration put
in place by autopkgtest on request of debci which got its trigger from
britney.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#918372: unblock: med-fichier/4.0.0+repack-6

[Adrian Bunk]

On Sun, Jan 06, 2019 at 12:35:05PM +0100, Paul Gevers wrote:
> Hi Gilles,
> 
> On Sat, 05 Jan 2019 17:04:05 +0100 Gilles Filippini  wrote:
> > Please unblock package med-fichier. Is has currently to wait for 43 days
> > because of an autopkgtest regression against the version of gmsh in testing
> > (3.0.6+dfsg1-4) [1]. But it succeeds against version 3.0.6+dfsg1-4.1 in
> > unstable [1] which waiting for med-fichier to migrate [2].
> 
> You can also handle this yourself by one of the following solutions:
> 
> - in med-fichier: in any of the binary packages add a *versioned* breaks
> on any of the binary packages from gmsh.

There is no package where you could place such a Breaks.

The only package the gmsh autopkgtest picks up from unstable is the 
broken cruft package libmed1v5.

No package that is still built by med-fichier/unstable is installed
in the relevant autopkgtest.

> - in gmsh: add a *versioned* test dependency on any of the med-fichier
> binary packages

This won't help since gmsh/testing is being tested.
And gmsh can't migrate before med-fichier.

> - in gmsh: in any of the binary packages add a *versioned* dependency on
> any of the binary packages from med-fichier

This won't help since gmsh/testing is being tested.
And gmsh can't migrate before med-fichier.

> The result of any of the actions above is that the autopkgtests will be
> done with both packages from unstable and will be used for both
> migrations. I didn't spend the time on the relations to see which is
> most appropriate in your case.

I don't think any of the above would help.

With some luck the syrthes upload will result in automatic cruft removal.

The root problem is that debci installs cruft packages from unstable.

> Paul

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Heads up to release team about MariadB 10.3

[Otto Kekäläinen]

Hello!

I just realized that the upload of mariadb-10.3 into Debian includes
the following transitions:
- libmariadbd18 -> libmariadbd19
- libmariadbclient18 becomes deprecated and fully replaced by the
libmariadb3 library already in Debian for a longer time (source
package mariadb-connector-c)

Technically this can constitute a transition and I have not followed
the process desrcibed at:
https://wiki.debian.org/Teams/ReleaseTeam/Transitions

My priority has been in packaging mariadb-10.3 so we would not be
stuck with mariadb-10.1 in buster. It is a very large package and this
transition was just a smal part of it, and I realized it too late.

My focus was mostly on if I manage to pull this off at all in time,
and I overlooked planning this transition detail. Sorry!

Luckily there has not been any major problems so far. The Salsa-CI,
ci.debian.net etc are all looking good. There is maybe just one issue
that can be hard to tackle, details in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917303

Re: Bug#918388: fixed in nodejs 10.15.0~dfsg-8

[Pirate Praveen]

[asking -release]

On 1/6/19 5:31 PM, Pirate Praveen wrote:
> Control: reopen -1
> 
> On Sun, 06 Jan 2019 10:34:48 + =?utf-8?b?SsOpcsOpbXkgTGFs?=
>  wrote:
>>* Suggests npm - because nodejs must not be blocked by it.
>>  Closes: #918388.
> 
> I don't think this reasoning is correct. gitlab recommends gitaly with
> the expectation that gitaly andd gitlab could be on different machines.
> ruby-rails currently recommends packages not even in the archive
> currently and it is not marked for auto removals for that.
> 
> I'd be happy to be proven wrong.
> 

Hi Release team,

Can you confirm if an rc bug in a packaged listed in recommends will
block testing migration of a package? (in this specific case, the fear
is that rc bug in npm will block nodejs testing migration).

Thanks
Praveen



signature.asc
Description: OpenPGP digital signature

Build failed in Jenkins: debian-archive-keyring-tests_stretch #24

[jenkins]

See 


--
[...truncated 132.48 KB...]
Running hooks in /etc/ca-certificates/update.d...
done.
Source: debian-archive-keyring
Priority: important
Section: misc
Maintainer: Debian Release Team 
Build-Depends: debhelper (>= 10), jetring, gnupg
Rules-Requires-Root: no
Standards-Version: 4.1.2
Vcs-Browser: https://salsa.debian.org/release-team/debian-archive-keyring
Vcs-Git: https://salsa.debian.org/release-team/debian-archive-keyring.git

Package: debian-archive-keyring
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends}
Description: GnuPG archive keys of the Debian archive
 The Debian project digitally signs its Release files. This package
 contains the archive keys used for that.

Package: debian-archive-keyring-udeb
Package-Type: udeb
Priority: optional
Architecture: all
Section: debian-installer
Depends: ${misc:Depends}
Recommends: gpgv-udeb
Description: GnuPG keys of the Debian archive
 The Debian project digitally signs its Release files. This package
 contains the archive keys used for that, in a minimal form for use
 in the installer.
dh_testdir
dh_testroot
dh_prep
dh_testdir
dh_testroot
dh_install
dh_install: Compatibility levels before 9 are deprecated (level 7 in use)
dh_installdocs
dh_installdocs: Compatibility levels before 9 are deprecated (level 7 in use)
dh_installchangelogs
dh_compress
dh_fixperms
dh_installdeb
dh_installdeb: Compatibility levels before 9 are deprecated (level 7 in use)
dh_gencontrol
dh_md5sums
dh_builddeb
dpkg-deb: building package 'debian-archive-keyring-build-deps' in 
'../debian-archive-keyring-build-deps_2018.1_all.deb'.

The package has been created.
Attention, the package has been created in the current directory,
not in ".." as indicated by the message above!
Selecting previously unselected package debian-archive-keyring-build-deps.
(Reading database ... 28736 files and directories currently installed.)
Preparing to unpack debian-archive-keyring-build-deps_2018.1_all.deb ...
Unpacking debian-archive-keyring-build-deps (2018.1) ...
Reading package lists...
Building dependency tree...
Reading state information...
Correcting dependencies...Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
 Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following additional packages will be installed:
  jetring
The following NEW packages will be installed:
  jetring
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 171 kB of archives.
After this operation, 351 kB of additional disk space will be used.
Get:1 http://cdn-fastly.deb.debian.org/debian stretch/main amd64 jetring all 
0.25 [171 kB]
Fetched 171 kB in 0s (5293 kB/s)
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)
Selecting previously unselected package jetring.
(Reading database ... 28740 files and directories currently installed.)
Preparing to unpack .../archives/jetring_0.25_all.deb ...
Unpacking jetring (0.25) ...
Setting up jetring (0.25) ...
Setting up debian-archive-keyring-build-deps (2018.1) ...
Processing triggers for man-db (2.7.6.1-2) ...
Not building database; man-db/auto-update is not 'true'.
dpkg-buildpackage: info: source package debian-archive-keyring
dpkg-buildpackage: info: source version 2018.1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Niels Thykier 
 dpkg-source --before-build testrun
dpkg-buildpackage: info: host architecture amd64
dpkg-source: warning: unknown information field 'Rules-Requires-Root' in input 
data in general section of control info file
 debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
make -j23 clean
make[1]: Entering directory '/tmp/testrun'
rm -f keyrings/debian-archive-keyring.gpg \
keyrings/debian-archive-keyring.gpg~ \
keyrings/debian-archive-keyring.gpg.lastchangeset
rm -f keyrings/debian-archive-removed-keys.gpg \
keyrings/debian-archive-removed-keys.gpg~ \
keyrings/debian-archive-removed-keys.gpg.lastchangeset
rm -f keyrings/team-members.gpg \
keyrings/team-members.gpg~ \
keyrings/team-members.gpg.lastchangeset
rm -rf trusted.gpg/build-area trusted.gpg trustdb.gpg
rm -f keyrings/*.cache
make[1]: Leaving directory '/tmp/testrun'
   dh_autoreconf_clean
   dh_clean
 dpkg-source -b testrun
dpkg-source: warning: unknown information field 'Rules-Requires-Root' in input 
data in general section of control info file
dpkg-source: info: using source format '3.0 (native)'
dpkg-source: info: building debian-archive-keyring in 
debian-archive-keyring_2018.1.tar.xz
dpkg-source: info: building debian-archive-keyring in 
debian-archive-keyring_2018.1.dsc
 debian/rules build
dh build
   dh_testdir
   dh_update_autotools_config
   

Bug#918372: unblock: med-fichier/4.0.0+repack-6

[Paul Gevers]

Hi Gilles,

On Sat, 05 Jan 2019 17:04:05 +0100 Gilles Filippini  wrote:
> Please unblock package med-fichier. Is has currently to wait for 43 days
> because of an autopkgtest regression against the version of gmsh in testing
> (3.0.6+dfsg1-4) [1]. But it succeeds against version 3.0.6+dfsg1-4.1 in
> unstable [1] which waiting for med-fichier to migrate [2].

You can also handle this yourself by one of the following solutions:

- in med-fichier: in any of the binary packages add a *versioned* breaks
on any of the binary packages from gmsh.

- in gmsh: add a *versioned* test dependency on any of the med-fichier
binary packages

- in gmsh: in any of the binary packages add a *versioned* dependency on
any of the binary packages from med-fichier

The result of any of the actions above is that the autopkgtests will be
done with both packages from unstable and will be used for both
migrations. I didn't spend the time on the relations to see which is
most appropriate in your case.

Paul



signature.asc
Description: OpenPGP digital signature