lp:~ubuntu-cdimage/ubuntu-cdimage/focal
- Get this branch:
- bzr branch lp:~ubuntu-cdimage/ubuntu-cdimage/focal
Branch merges
- Steve Langasek: Approve
-
Diff: 310 lines (+58/-53)6 files modifiedlib/cdimage/launchpad.py (+14/-1)
lib/cdimage/sign.py (+9/-9)
lib/cdimage/tests/test_checksums.py (+2/-1)
lib/cdimage/tests/test_sign.py (+14/-17)
lib/cdimage/tests/test_tree.py (+17/-17)
lib/cdimage/tree.py (+2/-8)
Branch information
Recent revisions
- 1878. By Iain Lane
-
tree: Switch to using mktorrent rather than btmakemetafile (bittornado)
bittornado is removed from the archive as of eoan.
- 1877. By Iain Lane
-
launchpad: Handle launchpadlib ≤ 1.10.13
This didn't have the fallback= kwarg to create a CredentialStore. We need this
on 1.10.13 and newer to continue working under sudo, but older versions didn't
have that problem, so we can omit including it completely. - 1875. By Iain Lane
-
sign: Work with gpg2
gpg2 doesn't use secring.gpg. On first launch it will import the keys from a
pre-existing secring.gpg to a new directory called private-keys-v1.d. This
doesn't respect the --secret-keyring parameter, though. But gpg (both xenial's
and focal's) have a `--homedir` option which allows you to override the
location for all files. This one does work. Switch to it, and remove the direct
setting of the various keyring paths. - 1874. By Iain Lane
-
launchpad: Create a KeyringCredenti
alStore to continue working under sudo After LP: #1862948 (focal or later), Launchpadlib always uses a memory-backed
(i.e. non-persistent) keyring backend when run under sudo. This defeats most
uses of cdimage on our shared host.The way to fix this is to explicitly create a credential store, and then
launchpadlib will use this backend rather than selecting a memory one.
Branch metadata
- Branch format:
- Branch format 7
- Repository format:
- Bazaar repository format 2a (needs bzr 1.16 or later)
- Stacked on:
- lp:ubuntu-cdimage