Launchpad itself

~jugmac00/launchpad:update-loggerhead

  1. Git
  2. lp:~jugmac00/launchpad
  3. update-loggerhead
Last commit made on 2022-04-04
Get this branch:
git clone -b update-loggerhead https://git.launchpad.net/~jugmac00/launchpad
Only Jürgen Gmach can upload to this branch. If you are Jürgen Gmach please log in for upload directions.

Branch merges

Branch information

Name:
update-loggerhead
Repository:
lp:~jugmac00/launchpad

Recent commits

f7746dd... by Jürgen Gmach

Update loggerhead to r522

3bc2133... by Jürgen Gmach

Update information about the location of navigation components

Merged from https://code.launchpad.net/~jugmac00/launchpad/+git/launchpad/+merge/418298

2827c82... by Jürgen Gmach

Update information about the location of navigation components

e4ed541... by Colin Watson

Work around Celery job failures on Python 3.6

Merged from https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/418279

3ae7c3f... by Colin Watson

Fix update-pkgcache crash with disabled archives

Merged from https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/418113

ecf1f03... by Colin Watson

Add some more assertions

We were mostly testing that the script doesn't crash, but assertions
make it a bit clearer what's going on.

90f2da0... by Colin Watson

Work around Celery job failures on Python 3.6

The slightly odd hack that we had to integrate historical class-based
tasks with Celery's modern preferences (see e.g.
https://docs.celeryq.dev/en/stable/history/whatsnew-4.0.html#the-task-base-class-no-longer-automatically-register-tasks)
no longer worked with Python 3.6.

`RunJob` and `CeleryRunJob` are partly "overriding general behaviour",
which makes sense to do in a subclass of `Task`, but they also implement
their own `run` methods. `celery_app.task` creates a new `Task`
instance using the decorated function as its `run` method, and so
persuading those to use `CeleryRunJob.run` instead took some effort.
However, with Python 3.6 this fails because the running task instance
doesn't seem to be an instance of `CeleryRunJob` according to `super()`.

Switching to `celery_app.register_task` avoids some unnecessary
complexity, but the core problem remains. For now, I've just switched
to the old-style way of calling the superclass using `RunJob.run(self,
job_id)`; inelegant though it is, it works on both Python 3.5 and 3.6.

I suspect that eventually we'll need to rethink how `lazr.jobrunner`'s
Celery integration works based on modern Celery best practices in order
to fix this properly.

81c636c... by Colin Watson

Fix wsgi-archive-auth.py for Ubuntu 18.04

Merged from https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/418180

5536af8... by Colin Watson

Merge db-stable 1c5e46616f (Artifactory publishing: new columns and constraints)

Merged from https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/418185

f7a141e... by Jürgen Gmach

Create `Preserving query count` how-to

Merged from https://code.launchpad.net/~jugmac00/launchpad/+git/launchpad/+merge/416670