@Multichill poked me about it.

The job is made to use Debian unstable:

$ echo "deb http://ftp.us.debian.org/debian unstable main contrib non-free" \
      | sudo tee -a /etc/apt/sources.list > /dev/null

Which is well, unstable :]

The package locales fails completely:

Preparing to replace locales 2.13+git20120306-3 (using .../locales_2.24-2_all.deb) ...
Unpacking replacement locales ...
dpkg: error processing /var/cache/apt/archives/locales_2.24-2_all.deb (--unpack):
 trying to overwrite '/usr/sbin/update-locale', which is also in package libc-bin 2.15-0ubuntu10.15
dpkg-deb (subprocess): subprocess data was killed by signal (Broken pipe)
dpkg-deb: error: subprocess <decompress> returned error exit status 2
Selecting previously unselected package libc-l10n.
dpkg: considering deconfiguration of locales, which would be broken by installation of libc-l10n ...
dpkg: yes, will deconfigure locales (broken by libc-l10n).
Unpacking libc-l10n (from .../libc-l10n_2.24-2_all.deb) ...
De-configuring locales ...
Errors were encountered while processing:
 /var/cache/apt/archives/locales_2.24-2_all.deb

No clue why update-locale would be in two packages. Looks like a chicken and egg problem as something is being transitioned in the Debian project. The source package is glibc: https://packages.qa.debian.org/g/glibc.html

I highly recommend to NOT use unstable for anything. Ideally you should aim at jessie which is the stable version, and eventually testing (which breaks often though).

If jessie does not work for some reaso, that is surely fixable :]

Looks like this problem is upstream since it was introduced between build 3574 an 3574:

3574
https://travis-ci.org/wikimedia/pywikibot-core/builds/153181059
https://travis-ci.org/wikimedia/pywikibot-core/jobs/153181060

3575
https://travis-ci.org/wikimedia/pywikibot-core/builds/153479464
https://travis-ci.org/wikimedia/pywikibot-core/jobs/153479465

@hashar, we have used the precise sudo-less Travis images because they are much quicker to boot than the precise sudo and trusty images, and it is common for 6 job on these images to run concurrently, whereas all other images are typically restricted to 3 jobs running concurrently. Faster boot up and more concurrency = quicker elapsed build times.

However, the precise TLSv2 situation was borked on those sudo-less images (T134647: site detection test fails for proofwiki on Travis precise images before May 2015), so I pull in the sid libssl1.0.0 as of e87b9cae . It is that hack which has stopped working now.

The problem with update-locale is not new. There are many packages I would like to update on the precise images, but could not because they would drag in extra dependencies and eventually the gcc is included in the update and it fails due to locales.

Like you say, this is a chicken-egg problem *within* Debian - I havent analysed it, because I am quite sure that they are very unlikely to revise their packaging structure. The result is current sid packages often cant be installed into precise, and I expect they also can't be installed into wheezy. As wheezy is now in LTS, it is no longer part of the core Debian team's responsibilities, and so sid does not need to support wheezy/precise and it would be silly to ask the team supporting sid to fix this problem. It would be immediate "wont fix". And the LTS team also probably doesnt care about people wanting to run sid packages.

The possible paths forward:

1. T132138: Perform full test suite using Wikimedia CI
2. retest the Travis precise sudo-less images. The current image might not have the same problems.
3. switch to Travis precise sudo images.
4. switch to Travis trusty images (they are always sudo-enabled boxes; sudo-less is not possible)
5. create a more targetted solution for TLSv2 on Travis, using the sudo-less wherever possible, skipping tests that need TLSv2 when on those precise images, and moving those tests that need a TLSv2 capable image to a trusty job.
6. like option 5, but using Circle CI builds to do the TLSv2 testing, as Circle CI start up modern images very quickly.

Over the next 24 hrs I can investigate options 2-6, in order to find what I believe is the ideal Travis solution. This will help identify if there is an Upstream solution possible with Travis. I suspect not.

In T145484#2682032, @jayvdb wrote:

@hashar, we have used the precise sudo-less Travis images because they are much quicker to boot than the precise sudo and trusty images, and it is common for 6 job on these images to run concurrently, whereas all other images are typically restricted to 3 jobs running concurrently. Faster boot up and more concurrency = quicker elapsed build times.

Quick example: using trusty instead of precise sudoless: https://travis-ci.org/jayvdb/pywikibot-core/builds/164342725 has elapsed time of 1 hr 20 min 15 sec (and that was with many tests disabled)

The last good build was Elapsed time 54 min 55 sec

However, the precise TLSv2 situation was borked on those sudo-less images (T134647: site detection test fails for proofwiki on Travis precise images before May 2015), so I pull in the sid libssl1.0.0 as of e87b9cae . It is that hack which has stopped working now.

This is incorrect. If I remove djvulibre-bin from the apt-get install, this problem is fixed.
https://travis-ci.org/jayvdb/pywikibot-core/builds/164353673
(but everything is still red for other reasons.)

It might be worth finding out why djvulibre-bin has changed its dependencies lately. It may be an unnecessary change specifying a higher minimum version, when a lower one would also work just as well.

djvulibre-bin is used by our Wikisource support (largely written by @Mpaa), so we could move those tests to trusty/precise-sudo jobs.

Note, the sudoless image is still
Build image provisioning date and time: Thu Feb 5 15:09:33 UTC 2015

The sudo precise images are now:
Build image provisioning date and time: Sun Aug 21 21:35:17 UTC 2016

http://metadata.ftp-master.debian.org/changelogs//main/d/djvulibre/djvulibre_3.5.27.1-6_changelog leads with

djvulibre (3.5.27.1-6) unstable; urgency=medium

  * track upstream fixes and updates, including to djvudigital
  * bump standards version
  * enable hardening

 -- Barak A. Pearlmutter <bap@debian.org>  Wed, 17 Aug 2016 22:35:47 +0200

So that is who to talk to, but it looks like the gcc requirement is quite intentional, so it would be a fruitless discussion.

If we switch to use precise-sudo images, the elapsed time jumps up to 1 hr 14 min 28 sec , from 54 min 55 sec .
(These timings are not particularly accurate, as the Travis logs show the tests are failing so badly that tty activity writing out error messages should be slowing down the tests significantly, before and after.)

Change 313832 had a related patch set uploaded (by John Vandenberg):
Replace debian-sid with lucid

https://gerrit.wikimedia.org/r/313832

Note build at https://travis-ci.org/jayvdb/pywikibot-core/builds/164673812
( Elapsed time 59 min 24 sec)

The djvulibre package in debian-sid will probably appear in lucid soon, so this problem may re-appear.

But it is a one-line temporary change, that allows the other travis build errors to be explored.

Change 313832 merged by jenkins-bot:
Replace debian-sid with lucid

https://gerrit.wikimedia.org/r/313832