Project

General

Profile

Actions

Issue #2199

open

repo 2.10 stops working in debian 9.13 (stretch)

Added by Denis 'GNUtoo' Carikli almost 2 years ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Category:
-
Target version:
Start date:
12/14/2020
Due date:
% Done:

0%

Estimated time:
Resolution:
fixed
Device:
Unknown
Grant:
Type of work:
Any programming languages (scripts, C, etc), System administration
Actions #1

Updated by Denis 'GNUtoo' Carikli almost 2 years ago

With that debian version, we have:

$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 9.13 (stretch)
Release:    9.13
Codename:    stretch
$ which python
/usr/bin/python
$ python --version
Python 2.7.13

repo 2.10 doesn't work with the python2 or python3 that are available in that distribution.

However repo 2.9 works.

TODO:
  • We need to check if downloading Replicant 6.0 ends up with repo 2.10 by default
  • If so we need to add workarounds or point to them directly in the build instructions.
  • We need to understand in which conditions repo is or is not updated
  • We probably need to confirm that there is no debian stretch package for repo (I've looked very rapidely and didn't find one but I may have missed it given the big number of packages with 'repo' in their names)
Actions #2

Updated by Denis 'GNUtoo' Carikli almost 2 years ago

We can use things like --repo-branch= to specify specific revisions, like that:

repo --repo-branch=refs/tags/v1.8.0 init -u https://git.replicant.us/replicant/manifest.git -b replicant-6.0-dev

However:
  • python2 seem to have been dropped since quite a while
  • python3.6 too

I've been trying tags but I didn't find one that works yet, so I'll try to add python3.6 in my debian stretch installation.

It doesn't seem to be available in buster backports, so I'll try packing it with Guix and just using that for repo.

Actions #3

Updated by Denis 'GNUtoo' Carikli almost 2 years ago

Guix has repo in the git-repo package.

So I can just pack it and reuse it in the git vm, it's probably easier than changing the python interpreter as it's also used during the Replicant build, and repo is used before that.

Actions #4

Updated by Denis 'GNUtoo' Carikli almost 2 years ago

I managed to find a more permanent workaround:

$ guix pack -RR -S /usr/local/bin/repo=bin/repo git-repo le-certs nss-certs git python-certifi

That created a tarball in /gnu/store/jpyahrpmdf20axi8llchpkm43plzay8c-tarball-pack.tar.gz

After extracting in Debian stretch and running the following:

$ export SSL_CERT_DIR="/gnu/store/siwap5n3sg2di3xlgdq9ryz7w81kkpdn-profile/etc/ssl/certs"
$ export SSL_CERT_FILE="/gnu/store/siwap5n3sg2di3xlgdq9ryz7w81kkpdn-profile/etc/ssl/certs/ca-certificates.crt"
$ export GIT_SSL_CAINFO="$SSL_CERT_FILE"

I could manage to use repo again in a transparent way:

$ repo init -u https://git.replicant.us/replicant/manifest.git -b replicant-6.0-dev

[some git username setup]

$ repo sync
Fetching projects: 0% (1/501) LineageOS-mirror/android_abi_cpp.gitServer does not provide clone.bundle; ignoring.
[...]

Actions #5

Updated by Denis 'GNUtoo' Carikli almost 2 years ago

Note that not all packages are needed as I added more packages to try to make it find the certificates. Shortly after I was pointed to the solution in #guix (which was to export the variables to make repo find the certificates).

Actions #6

Updated by Denis 'GNUtoo' Carikli almost 2 years ago

I've improved it a bit:
  • It now saves the all the infos necessary to recreate the tarball in a file named manifest. To find it find /gnu -name manifest can be used.
  • The variables are now set by an environment file that comes from within the tarball.
The missing part is probably the release process now, which means:
  • Writing a README
  • Making a process to sign and verify the image

We need to take into account downgrade attacks on the README and signed image.

Build command:

guix pack \
--compression=xz \
--save-provenance \
-RR \
--symlink=/usr/local/bin/repo=bin/repo \
--symlink=/usr/local/bin/repo-env.sh=etc/profile \
git-repo le-certs nss-certs git python-certifi

Deploy commands:

tar xf path/to/sz1lkq3ryr5iv6amy6f3d2pziks27g28-tarball-pack.tar.xz -C /

Usage:

source /usr/local/bin/repo-env.sh
repo sync

PS: Note that here we will only build an x86_64 image as only x86_64 is supported to build Replicant.

Actions #7

Updated by Denis 'GNUtoo' Carikli almost 2 years ago

This should now be fixed: https://ftp.osuosl.org/pub/replicant/build-tools/repo/28-01-2021/README.txt

I've not retested the source file but I had an equivalent one made by hand before.

Actions #8

Updated by Denis 'GNUtoo' Carikli almost 2 years ago

  • Assignee set to Denis 'GNUtoo' Carikli
  • Resolution set to fixed
Actions #9

Updated by _I3^ RELATIVISM over 1 year ago

  • Type of work Any programming languages (scripts, C, etc), System administration added
Actions

Also available in: Atom PDF