Our Debian User Group met on December 22nd for our last meeting of
2024. I wasn't sure at first it was a good idea, but many people showed up and
it was great!
Here's what we did:
pollo:
fought with the Supersonic flatpak to fix build with latest
placebo (failed), but managed to update to the latest upstream
realized that keyring-pass does the inverse of what he needs, whereas
pass_secret_service, which does, is poorly maintained and depends on
the dead pypass library
uploaded new upstream versions of etckeeper, mdformat and
python-internetarchive
added basic salsa CI and some RFA for a bunch of packages
(python-midiutil, antimony, python-pyo, rakarrack, python-pyknon,
soundcraft-utils, cecilia, nasty, gnome-icon-theme-nuovo,
gnome-extra-iconsg, nome-subtitles, timgm6mb-soundfont)
mjeanson and joeDoe:
hanged out and did some stuff :)
Some of us ended up grabbing a drink after the event at l'Isle de Garde,
a pub right next to the venue.
Pictures
This time around, we were hosted by l'Espace des possibles, at their
new location (they moved since our last visit). It was great! People liked the
space so much we actually discussed going back there more often :)
Our Debian User Group met on November 2nd after a somewhat longer summer hiatus
than normal. It was lovely to see a bunch of people again and to be able to
dedicate a whole day to hacking :)
Here is what we did:
lavamind:
opened an RFS on the ruby team mailing list for the new upstream
version of ruby-necromancer
worked on packaging the new upstream version of ruby-pathspec
tvaz:
did AM (Application Manager) work
tassia:
explored the Debian Jr. project (website, wiki, mailing list, salsa
repositories)
played a few games for Nico's entertainment :-)
built and tested a Debian Jr. live image
Pictures
This time around, we went back to Foulab. Thanks for hosting us!
As always, the hacklab was full of interesting stuff and I took a few (bad)
pictures for this blog post:
Note: I've been awfully silent here for the past ... (checks notes)
oh dear, 3 months! But that's not because I've been idle, quite the
contrary, I've been very busy but just didn't have time to write
about anything. So I've taken it upon myself to write something
about my work this week, and published this post on the Tor
blog which I copy here for a broader audience. Let me know if
you like this or not.
Tor has finally completed a long migration from legacy Git
infrastructure (Gitolite and GitWeb) to our self-hosted
GitLab server.
Git repository addresses have therefore changed. Many of you probably
have made the switch already, but if not, you will need to change:
https://git.torproject.org/
to:
https://gitlab.torproject.org/
In your Git configuration.
The GitWeb front page is now an archived listing of all the
repositories before the migration. Inactive git repositories were
archived in GitLab legacy/gitolite namespace and the
gitweb.torproject.org and git.torproject.org web sites now
redirect to GitLab.
Best effort was made to reproduce the original gitolite repositories
faithfully and also avoid duplicating too much data in the
migration. But it's possible that some data present in Gitolite has
not migrated to GitLab.
User repositories are particularly at risk, because they were
massively migrated, and they were "re-forked" from their upstreams, to
avoid wasting disk space. If a user had a project with a matching name
it was assumed to have the right data, which might be inaccurate.
The two virtual machines responsible for the legacy service (cupani
for git-rw.torproject.org and vineale for git.torproject.org and
gitweb.torproject.org) have been shutdown. Their disks will remain
for 3 months (until the end of July 2024) and their backups for
another year after that (until the end of July 2025), after which
point all the data from those hosts will be destroyed, with only the
GitLab archives remaining.
The rest of this article expands on how this was done and what kind of
problems we faced during the migration.
Where is the code?
Normally, nothing should be lost. All repositories in gitolite have
been either explicitly migrated by their owners, forcibly migrated by
the sysadmin team (TPA), or explicitly destroyed at their owner's
request.
An exhaustive rewrite map translates gitolite projects to GitLab
projects. Some of those projects actually redirect to their parent
in cases of empty repositories that were obvious forks. Destroyed
repositories redirect to the GitLab front page.
Because the migration happened progressively, it's technically
possible that commits pushed to gitolite were lost after the
migration. We took great care to avoid that scenario. First, we
adopted a proposal (TPA-RFC-36) in June 2023 to announce the
transition. Then, in March 2024, we locked down all repositories
from any further changes. Around that time, only a handful of
repositories had changes made after the adoption date, and we
examined each repository carefully to make sure nothing was lost.
Still, we built a diff of all the changes in the git references
that archivists can peruse to check for data loss. It's large (6MiB+)
because a lot of repositories were migrated before the mass migration
and then kept evolving in GitLab. Many other repositories were rebuilt
in GitLab from parent to rebuild a fork relationship which added extra
references to those clones.
A note to amateur archivists out there, it's probably too late for one
last crawl now. The Git repositories now all redirect to GitLab and
are effectively unavailable in their original form.
That said, the GitWeb site was crawled into the Internet Archivein
February 2024, so at least some copy of it is available in the
Wayback Machine. At that point, however, many developers had already
migrated their projects to GitLab, so the copies there were already
possibly out of date compared with the repositories in GitLab.
Software Heritage also has a copy of all repositories hosted on
Gitolite since June 2023 and have continuously kept mirroring the
repositories, where they will be kept hopefully in eternity. There's
an issue where the main website can't find the repositories when
you search for gitweb.torproject.org, instead search for
git.torproject.org.
In any case, if you believe data is missing, please do let us know by
opening an issue with TPA.
Why?
This is an old project in the making. The first discussion about
migrating from gitolite to GitLab started in 2020 (almost 4 years
ago). But going further back, the first GitLab experiment was in
2016, almost a decade ago.
The current GitLab server dates from 2019, replacing Trac for issue
tracking in 2020. It was originally supposed to host only mirrors
for merge requests and issue trackers but, naturally, one thing led to
another and eventually, GitLab had grown a container registry,
continuous integration (CI) runners, GitLab Pages, and, of course,
hosted most Git repositories.
There were hesitations at moving to GitLab for code hosting. We had
discussions about the increased attack surface and ways to
mitigate that, but, ultimately, it seems the issues were not that
serious and the community embraced GitLab.
TPA actually migrated its most critical repositories out of shared
hosting entirely, into specific servers (e.g. the Puppet Git
repository is just on the Puppet server now), leveraging Git's
decentralized nature and removing an entire attack surface from our
infrastructure. Some of those repositories are mirrored back into
GitLab, but the authoritative copy is not on GitLab.
In any case, the proposal to migrate from Gitolite to GitLab was
effectively just formalizing a fait accompli.
How to migrate from Gitolite / cgit to GitLab
The progressive migration was a challenge. If you intend to migrate
between hosting platforms, we strongly recommend to make a "flag day"
during which you migrate all repositories at once. This ensures a
smoother transition and avoids elaborate rewrite rules.
When Gitolite access was shutdown, we had repositories on both GitLab
and Gitolite, without a clear relationship between the two. A priori,
the plan then was to import all the remaining Gitolite repositories
into the legacy/gitolite namespace, but that seemed wasteful,
particularly for large repositories like Tor Browser which uses
nearly a gigabyte of disk space. So we took special care to avoid
duplicating repositories.
When the mass migration started, only 71 of the 538 Gitolite
repositories were Migrated to GitLab in the gitolite.conf
file. So, given that we had hundreds of repositories to migrate:, we
developed some automation to "save time". We already automate
similar ad-hoc tasks with Fabric, so we used that framework here
as well. (Our normal configuration management tool is Puppet,
which is a poor fit here.)
So a relatively large amount of Python code was produced to
basically do the following:
check if all on-disk repositories are listed in gitolite.conf
(and vice versa) and either add missing repositories or delete
them from disk if garbage
for each repository in gitolite.conf, if its category is marked
Migrated to GitLab, skip, otherwise;
find a matching GitLab project by name, prompt the user for
multiple matches
if a match is found, redirect if the repository is non-empty
we have GitLab projects that look like the real thing, but are
only present to host migrated Trac issues
in such cases we cloned the Gitolite project locally and pushed
to the existing repository instead
otherwise, a new repository is created in the legacy/gitolite
namespace, using the "import" mechanism in GitLab to automatically
import the repository from Gitolite, creating redirections and
updating gitolite.conf to document the change
User repositories (those under the user/ directory in Gitolite) were
handled specially. First, the existing redirection map was checked to
see if a similarly named project was migrated (so that,
e.g. user/dgoulet/tor is properly treated as a fork of
tpo/core/tor). Then the parent project was forked in GitLab and the
Gitolite project force-pushed to the fork. This allows us to show the
fork relationship in GitLab and, more importantly, benefit from the
"pool" feature in GitLab which deduplicates disk usage between forks.
Sometimes, we found no such relationships. Then we simply imported
multiple repositories with similar names in the legacy/gitolite
namespace, sometimes creating forks between user repositories, on a
first-come-first-served basis from the gitolite.conf order.
The code used in this migration is now available publicly. We
encourage other groups planning to migrate from Gitolite/GitWeb to
GitLab to use (and contribute to) our fabric-tasks repository,
even though it does have its fair share of hard-coded assertions.
The main entry point is the gitolite.mass-repos-migration task. A
typical migration job looked like:
anarcat@angela:fabric-tasks$ fab -H cupani.torproject.org gitolite.mass-repos-migration
[...]
INFO: skipping project project/help/infra in category Migrated to GitLab
INFO: skipping project project/help/wiki in category Migrated to GitLab
INFO: skipping project project/jenkins/jobs in category Migrated to GitLab
INFO: skipping project project/jenkins/tools in category Migrated to GitLab
INFO: searching for projects matching fastlane
INFO: Successfully connected to https://gitlab.torproject.org
import gitolite project project/tor-browser/fastlane into gitlab legacy/gitolite/project/tor-browser/fastlane with desc 'Tor Browser app store and deployment configuration for Fastlane'? [Y/n]
INFO: importing gitolite project project/tor-browser/fastlane into gitlab legacy/gitolite/project/tor-browser/fastlane with desc 'Tor Browser app store and deployment configuration for Fastlane'
INFO: building a new connect to cupani
INFO: defaulting name to fastlane
INFO: importing project into GitLab
INFO: Successfully connected to https://gitlab.torproject.org
INFO: loading group legacy/gitolite/project/tor-browser
INFO: archiving project
INFO: creating repository fastlane (fastlane) in namespace legacy/gitolite/project/tor-browser from https://git.torproject.org/project/tor-browser/fastlane into https://gitlab.torproject.org/legacy/gitolite/project/tor-browser/fastlane
INFO: migrating Gitolite repository project/tor-browser/fastlane to GitLab project legacy/gitolite/project/tor-browser/fastlane
INFO: uploading 399 bytes to /srv/git.torproject.org/repositories/project/tor-browser/fastlane.git/hooks/pre-receive
INFO: making /srv/git.torproject.org/repositories/project/tor-browser/fastlane.git/hooks/pre-receive executable
INFO: adding entry to rewrite_map /home/anarcat/src/tor/tor-puppet/modules/profile/files/git/gitolite2gitlab.txt
INFO: modifying gitolite.conf to add: "config gitweb.category = Migrated to GitLab"
INFO: rewriting gitolite config /home/anarcat/src/tor/gitolite-admin/conf/gitolite.conf to change project project/tor-browser/fastlane to category Migrated to GitLab
INFO: skipping project project/bridges/bridgedb-admin in category Migrated to GitLab
[...]
In the above, you can see migrated repositories skipped then the
fastlane project being archived into GitLab. Another example with
a later version of the script, processing only user repositories and
showing the interactive prompt and a force-push into a fork:
$ fab -H cupani.torproject.org gitolite.mass-repos-migration --include 'user/.*' --exclude '.*tor-?browser.*'
INFO: skipping project user/aagbsn/bridgedb in category Migrated to GitLab
[...]
INFO: skipping project user/phw/atlas in category Migrated to GitLab
INFO: processing project user/phw/obfsproxy (Philipp's obfsproxy repository) in category Users' development repositories (Attic)
INFO: Successfully connected to https://gitlab.torproject.org
INFO: user repository detected, trying to find fork phw/obfsproxy
WARNING: no existing fork found, entering user fork subroutine
INFO: found 6 GitLab projects matching 'obfsproxy' (https://gitweb.torproject.org/user/phw/obfsproxy.git)
0 legacy/gitolite/debian/obfsproxy
1 legacy/gitolite/debian/obfsproxy-legacy
2 legacy/gitolite/user/asn/obfsproxy
3 legacy/gitolite/user/ioerror/obfsproxy
4 tpo/anti-censorship/pluggable-transports/obfsproxy
5 tpo/anti-censorship/pluggable-transports/obfsproxy-legacy
select parent to fork from, or enter to abort: ^G4
INFO: repository is not empty: in-pack: 2104, packs: 1, size-pack: 414
fork project tpo/anti-censorship/pluggable-transports/obfsproxy into legacy/gitolite/user/phw/obfsproxy^G [Y/n]
INFO: loading project tpo/anti-censorship/pluggable-transports/obfsproxy
INFO: forking project user/phw/obfsproxy into namespace legacy/gitolite/user/phw
INFO: waiting for fork to complete...
INFO: fork status: started, sleeping...
INFO: fork finished
INFO: cloning and force pushing from user/phw/obfsproxy to legacy/gitolite/user/phw/obfsproxy
INFO: deleting branch protection: <class 'gitlab.v4.objects.branches.ProjectProtectedBranch'> => 'id': 2723, 'name': 'master', 'push_access_levels': [ 'id': 2864, 'access_level': 40, 'access_level_description': 'Maintainers', 'deploy_key_id': None ], 'merge_access_levels': [ 'id': 2753, 'access_level': 40, 'access_level_description': 'Maintainers' ], 'allow_force_push': False
INFO: cloning repository git-rw.torproject.org:/srv/git.torproject.org/repositories/user/phw/obfsproxy.git in /tmp/tmp6orvjggy/user/phw/obfsproxy
Cloning into bare repository '/tmp/tmp6orvjggy/user/phw/obfsproxy'...
INFO: pushing to GitLab: https://gitlab.torproject.org/legacy/gitolite/user/phw/obfsproxy
remote:
remote: To create a merge request for bug_10887, visit:
remote: https://gitlab.torproject.org/legacy/gitolite/user/phw/obfsproxy/-/merge_requests/new?merge_request%5Bsource_branch%5D=bug_10887
remote:
[...]
To ssh://gitlab.torproject.org/legacy/gitolite/user/phw/obfsproxy
+ 2bf9d09...a8e54d5 master -> master (forced update)
* [new branch] bug_10887 -> bug_10887
[...]
INFO: migrating repo
INFO: migrating Gitolite repository https://gitweb.torproject.org/user/phw/obfsproxy.git to GitLab project https://gitlab.torproject.org/legacy/gitolite/user/phw/obfsproxy
INFO: adding entry to rewrite_map /home/anarcat/src/tor/tor-puppet/modules/profile/files/git/gitolite2gitlab.txt
INFO: modifying gitolite.conf to add: "config gitweb.category = Migrated to GitLab"
INFO: rewriting gitolite config /home/anarcat/src/tor/gitolite-admin/conf/gitolite.conf to change project user/phw/obfsproxy to category Migrated to GitLab
INFO: processing project user/phw/scramblesuit (Philipp's ScrambleSuit repository) in category Users' development repositories (Attic)
INFO: user repository detected, trying to find fork phw/scramblesuit
WARNING: no existing fork found, entering user fork subroutine
WARNING: no matching gitlab project found for user/phw/scramblesuit
INFO: user fork subroutine failed, resuming normal procedure
INFO: searching for projects matching scramblesuit
import gitolite project user/phw/scramblesuit into gitlab legacy/gitolite/user/phw/scramblesuit with desc 'Philipp's ScrambleSuit repository'?^G [Y/n]
INFO: checking if remote repo https://git.torproject.org/user/phw/scramblesuit exists
INFO: importing gitolite project user/phw/scramblesuit into gitlab legacy/gitolite/user/phw/scramblesuit with desc 'Philipp's ScrambleSuit repository'
INFO: importing project into GitLab
INFO: Successfully connected to https://gitlab.torproject.org
INFO: loading group legacy/gitolite/user/phw
INFO: creating repository scramblesuit (scramblesuit) in namespace legacy/gitolite/user/phw from https://git.torproject.org/user/phw/scramblesuit into https://gitlab.torproject.org/legacy/gitolite/user/phw/scramblesuit
INFO: archiving project
INFO: migrating Gitolite repository https://gitweb.torproject.org/user/phw/scramblesuit.git to GitLab project https://gitlab.torproject.org/legacy/gitolite/user/phw/scramblesuit
INFO: adding entry to rewrite_map /home/anarcat/src/tor/tor-puppet/modules/profile/files/git/gitolite2gitlab.txt
INFO: modifying gitolite.conf to add: "config gitweb.category = Migrated to GitLab"
INFO: rewriting gitolite config /home/anarcat/src/tor/gitolite-admin/conf/gitolite.conf to change project user/phw/scramblesuit to category Migrated to GitLab
[...]
Acute eyes will notice the bell used as a notification mechanism
as well in this transcript.
A lot of the code is now useless for us, but some, like "commit and
push" or is-repo-empty live on in the git module and, of
course, the gitlab module has grown some legs along the
way. We've also found fun bugs, like a file descriptor exhaustion in
bash, among other oddities. The retirement milestone and
issue 41215 has a detailed log of the migration, for those
curious.
This was a challenging project, but it feels nice to have this behind
us. This gets rid of 2 of the 4 remaining machines running Debian
"old-old-stable", which moves a bit further ahead in our late
bullseye upgrades milestone.
Full transparency: we tested GPT-3.5, GPT-4, and other large language
models to see if they could answer the question "write a set of
rewrite rules to redirect GitWeb to GitLab". This has become a
standard LLM test for your faithful writer to figure out how good a
LLM is at technical responses. None of them gave an accurate,
complete, and functional response, for the record.
The actual rewrite rules as of this writing follow, for humans that
actually like working answers provided by expert humans instead of
artificial intelligence which currently seem to be, glorified,
mansplaining interns.
git.torproject.org rewrite rules
Those rules are relatively simple in that they rewrite a single URL to
its equivalent GitLab counterpart in a 1:1 fashion. It relies on the
rewrite map mentioned above, of course.
RewriteEngine on
# this RewriteMap connects the gitweb projects to their GitLab
# equivalent
RewriteMap gitolite2gitlab "txt:/etc/apache2/gitolite2gitlab.txt"
# if this becomes a performance bottleneck, convert to a DBM map with:
#
# $ httxt2dbm -i mapfile.txt -o mapfile.map
#
# and:
#
# RewriteMap mapname "dbm:/etc/apache/mapfile.map"
#
# according to reports lavamind found online, we hit such a
# performance bottleneck only around millions of entries, which is not our case
# those two rules can go away once all the projects are
# migrated to GitLab
#
# this matches the request URI so we can check the RewriteMap
# for a match next
#
# WARNING: this won't match URLs without .git in them, which
# *do* work now. one possibility would be to match the request
# URI (without query string!) with:
#
# /git/(.*)(.git)?/(((branches hooks info objects/).*) git-.* upload-pack receive-pack HEAD config description)?.
#
# I haven't been able to figure out the actual structure of
# those URLs, so it's really hard to figure out the boundaries
# of the project name here. I stopped after pouring around the
# http-backend.c code in git
# itself. https://www.git-scm.com/docs/http-protocol is also
# kind of incomplete and unsatisfying.
RewriteCond % REQUEST_URI ^/(git/)?(.*).git/.*$
# this makes the RewriteRule match only if there's a match in
# the rewrite map
RewriteCond $ gitolite2gitlab:%2 NOT_FOUND !NOT_FOUND
RewriteRule ^/(git/)?(.*).git/(.*)$ https://gitlab.torproject.org/$ gitolite2gitlab:$2 .git/$3 [R=302,L]
# Fallback everything else to GitLab
RewriteRule (.*) https://gitlab.torproject.org [R=302,L]
gitweb.torproject.org rewrite rules
Those are the vastly more complicated GitWeb to GitLab rewrite
rules.
Note that we say "GitWeb" but we were actually not running
GitWeb but cgit, as the former didn't actually scale for us.
RewriteEngine on
# this RewriteMap connects the gitweb projects to their GitLab
# equivalent
RewriteMap gitolite2gitlab "txt:/etc/apache2/gitolite2gitlab.txt"
# special rule to process targets of the old spec.tpo site and
# bring them to the right redirect on the new spec.tpo site. that should turn, for example:
#
# https://gitweb.torproject.org/torspec.git/tree/address-spec.txt
#
# into:
#
# https://spec.torproject.org/address-spec
RewriteRule ^/torspec.git/tree/(.*).txt$ https://spec.torproject.org/$1 [R=302]
# list of endpoints taken from cgit's cmd.c
# those two RewriteCond are necessary because we don't move
# all repositories at once. once the migration is completed,
# they can be removed.
#
# and yes, they are copied all over the place below
#
# create a match for the project name to check if the project
# has been moved to GitLab
RewriteCond % REQUEST_URI ^/(.*).git(/.*)?$
# this makes the RewriteRule match only if there's a match in
# the rewrite map
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
# main project page, like summary below
RewriteRule ^/(.*).git/?$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 / [R=302,L]
# summary
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteRule ^/(.*).git/summary/?$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 / [R=302,L]
# about
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteRule ^/(.*).git/about/?$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 / [R=302,L]
# commit
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteCond "% QUERY_STRING " "(.*(?:^ &))id=([^&]*)(&.*)?$"
RewriteRule ^/(.*).git/commit/? https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/commit/%2 [R=302,L,QSD]
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteRule ^/(.*).git/commit/? https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/commits/HEAD [R=302,L]
# diff, incomplete because can diff arbitrary refs and files in cgit but not in GitLab, hard to parse
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteCond % QUERY_STRING id=([^&]*)
RewriteRule ^/(.*).git/diff/? https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/commit/%1 [R=302,L,QSD]
# patch
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteCond % QUERY_STRING id=([^&]*)
RewriteRule ^/(.*).git/patch/? https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/commit/%1.patch [R=302,L,QSD]
# rawdiff, incomplete because can show only one file diff, which GitLab cannot
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteCond % QUERY_STRING id=([^&]*)
RewriteRule ^/(.*).git/rawdiff/?$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/commit/%1.diff [R=302,L,QSD]
# log
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteCond % QUERY_STRING h=([^&]*)
RewriteRule ^/(.*).git/log/?$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/commits/%1 [R=302,L,QSD]
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteRule ^/(.*).git/log/?$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/commits/HEAD [R=302,L]
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteRule ^/(.*).git/log(/?.*)$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/commits/HEAD$2 [R=302,L]
# atom
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteCond % QUERY_STRING h=([^&]*)
RewriteRule ^/(.*).git/atom/?$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/commits/%1 [R=302,L,QSD]
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteRule ^/(.*).git/atom/?$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/commits/HEAD [R=302,L,QSD]
# refs, incomplete because two pages in GitLab, defaulting to "tags"
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteRule ^/(.*).git/refs/?$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/tags [R=302,L]
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteCond % QUERY_STRING h=([^&]*)
RewriteRule ^/(.*).git/tag/? https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/tags/%1 [R=302,L,QSD]
# tree
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteCond % QUERY_STRING id=([^&]*)
RewriteRule ^/(.*).git/tree(/?.*)$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/tree/%1$2 [R=302,L,QSD]
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteRule ^/(.*).git/tree(/?.*)$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/tree/HEAD$2 [R=302,L]
# /-/tree has no good default in GitLab, revert to HEAD which is a good
# approximation (we can't assume "master" here anymore)
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteRule ^/(.*).git/tree/?$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/tree/HEAD [R=302,L]
# plain
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteCond % QUERY_STRING h=([^&]*)
RewriteRule ^/(.*).git/plain(/?.*)$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/raw/%1$2 [R=302,L,QSD]
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteRule ^/(.*).git/plain(/?.*)$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/raw/HEAD$2 [R=302,L]
# blame: disabled
#RewriteCond % REQUEST_URI ^/(.*).git/.*$
#RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
#RewriteCond % QUERY_STRING h=([^&]*)
#RewriteRule ^/(.*).git/blame(/?.*)$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/blame/%1$2 [R=302,L,QSD]
# same default as tree above
#RewriteCond % REQUEST_URI ^/(.*).git/.*$
#RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
#RewriteRule ^/(.*).git/blame(/?.*)$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/blame/HEAD/$2 [R=302,L]
# stats
RewriteCond % REQUEST_URI ^/(.*).git/.*$
RewriteCond $ gitolite2gitlab:%1 NOT_FOUND !NOT_FOUND
RewriteRule ^/(.*).git/stats/?$ https://gitlab.torproject.org/$ gitolite2gitlab:$1 /-/graphs/HEAD [R=302,L]
# still TODO:
# repolist: once migration is complete
#
# cannot be done:
# atom: needs a feed token, user must be logged in
# blob: no direct equivalent
# info: not working on main cgit website?
# ls_cache: not working, irrelevant?
# objects: undocumented?
# snapshot: pattern too hard to match on cgit's side
# special case, we keep a copy of the main index on the archive
RewriteRule ^/?$ https://archive.torproject.org/websites/gitweb.torproject.org.html [R=302,L]
# Fallback: everything else to GitLab
RewriteRule .* https://gitlab.torproject.org [R=302,L]
The reference copy of those is available in our (currently private)
Puppet git repository.
Time really flies when you are really busy you have fun! Our Montr al
Debian User Group met on Sunday March 31st and I only just found the time to
write our report :)
This time around, 9 of us we met at EfficiOS's offices1 to
chat, hang out and work on Debian and other stuff!
Here is what we did:
pollo:
did some clerical work for the DebConf videoteam
tried to book a plane ticket for DC24
triaged #1067620 (dependency problem with whipper)
Pictures
Here are pictures of the event. Well, one picture (thanks Tassia!) of the event
itself and another one of the crisp Italian lager I drank at the bar after the
event :)
Maintainers, amongst other things, of the great LTTng.
New Year, Same Great People! Our Debian User Group met for the first of our
2024 bi-monthly meetings on February 4th and it was loads of fun. Around
twelve different people made it this time to Koumbit, where the meeting
happened.
As a reminder, our meetings are called "Debian & Stuff" because we want to be
as open as possible and welcome people that want to work on "other stuff" than
Debian.
Here is what we did:
pollo:
tested a laptop that had a defective battery with a known good one (the
problem was indeed with the battery :D)
renewed his expiring OpenPGP key
worked on removing trapperkeeper-scheduler-clojure from the DebCI
reject_list
helped anarcat with packaging sigal
managed to feed most of the people present :)
LeLutin:
worked with lavamind to upload new upstream release of smokeping
mjeanson:
migrated from lxd to incus on his servers
helped anarcat with flashing his AirGradient
lavamind:
submitted a bug report on r-cran-rserve (promptly
fixed/uploaded by maintainer!)
brought over a car full of old computer gear to donate
Pictures
I was pretty busy this time around and ended up not taking a lot of pictures.
Here's a bad one of the ceiling at Koumbit I took, and a picture by anarcat of
the content of his boxes of loot:
A few weeks ago, my friend and neighbor J r me (aka lavamind)
installed a weather station on his balcony and started collecting data from it.
It has been quite useful to measure the degrading air quality during the recent
forest fires plaguing northern Canada, but sadly, the hardware itself
isn't great.
Whereas some projects like airgradient offer open hardware devices running
free software, the station we got is from RevolvAir, some kind of local
air monitoring project that aims to be a one-stop solution for exterior air
monitoring.
Not only is their device pretty expensive1, but it also reboots
frequently by itself. Even worse, their online data map requires an
account to view the data and the interface is bad, unintuitive and only stores
data up to a month.
Having a good background in data visualisation and statistics thanks to my
master's degree in economics, I decided I could do better. Two days later, I
had built a series of tools to collect, analyse and graph the JSON time series
data provided by the device.
The result is a very simple website that works without any JavaScript,
leveraging static graphs built using R. Modern web libraries and projects
offer an incredible wealth of tools to graph and visualise data, but as for
most of my web projects, I wanted something static and simple.
The source code for the project can be found here, and although it is
somewhat specific to the data structure provided by the RevolvAir device, it
could easily be adapted to other devices, as they tend to have very similar
JSON dumps.
around 300 CAD, whereas a similar station from airgradient costs
around 90 CAD. Thankfully, this station was a gift from a local group
mobilising against an industrial project near our housing
cooperative and we didn't have to pay for it ourselves.
Our local Debian user group gathered on Sunday October 30th to chat, work on
Debian and do other, non-Debian related hacking :) This time around, we met at
EfficiOS's1 offices. As you can see from the following
picture, it's a great place and the view they have is pretty awesome. Many
thanks for hosting us!
This was our 4th meeting this year and once again, attendance was great: 10
people showed up to work on various things.
Following our bi-monthly schedule, our next meeting should be in December, but
I'm not sure it'll happen. December can be a busy month here and I will have to
poke our mailing list to see if people have the spoons for an event.
This time around, I was able to get a rough log of the Debian work people did:
pollo:
Our local Debian user group gathered on Sunday August 28th1 at the very
hackish Foulab for the August 2022 edition of our "Debian & Stuff"
meetings.
As always, the event was a success and we had lots of fun. Nine people showed
up, including some new faces and people I hadn't seen in a while:
On my side, although I was badly sleep-deprived 2, I still managed to be
somewhat productive!
One of the WiFi Access Points we use in our 4-apartment LAN had been
boot-looping for a few weeks, after a failed sysupgrade to the latest version
of OpenWRT. lavamind and I suspect the flash got corrupted in a way or another
during the upgrade process...
Lucky for us, this model has a serial port and runs U-Boot. After a
bit of tinkering, some electrical tape and two different serial
adapters3, we managed to identify the pin layout and got a shell on the
machine. The device has a reset button, but since the kernel panic was
happening too soon in the boot process, we weren't able to get into OpenWRT's
failsafe mode this way.
Once we had serial access, wiping the flash and re-installing OpenWRT fixed our
problem. A quick ansible-playbook run later, the device was back to being
usable and configured :)
I was too tired to keep track of what others did, but I took some nice pictures
of the pizza we got, and of this nice blow-up Tux wearing a Foulab t-shirt. Enjoy!
As always, thanks to the Debian project for granting us a budget to rent the
venue and to buy some food.
Please excuse the late blog post, it's Harvest Season here and I've been
quite busy.
A bad case of wry neck kept me from sleeping properly for a while in
August.
As it turns out, serial connections work better when you use the
right pins for TX and RX!
This is the report for the Debian Clojure Team remote sprint
that took place on May 13-14th.
Looking at my previous blog entries, this was my first Debian sprint since
July 2020! Crazy how fast time flies...
Many thanks to those who participated, namely:
Rob Browning (rlb)
Elana Hashman (ehashman)
J r me Charaoui (lavamind)
Leandro Doctors (allentiak)
Louis-Philippe V ronneau (pollo)
Sadly, Utkarsh Gupta although having planned on participating ended up not
being able to and worked on DebConf Bursary paperwork instead.
rlb
Rob mostly worked on creating a dh-clojure tool to help make packaging
Clojure libraries easier.
At the moment, most of the packaging is done manually, by invoking build
tools by hand. Having a tool to automate many of the steps required to build
Clojure packages would go a long way in making them more uniform.
His work (although still very much a WIP) can be found here:
https://salsa.debian.org/rlb/dh-clojure/
ehashman
Elana:
Finished the Java Team VCS migration to the Clojure Team namespace.
lavamind
It was J r me's first time working on Clojure packages, and things went great!
During the sprint, he:
Joined the Clojure Team on salsa.
Identified missing dependencies to update puppetdb to the 7.x release.
Learned how to package Clojure libraries in Debian.
Packaged murphy-clojure, truss-clojure and encore-clojure and uploaded
them to NEW.
Began to package nippy-clojure.
allentiak
Leandro joined us on Saturday, since he couldn't get off work on Friday. He
mostly continued working on replacing our in-house scripts for
/usr/bin/clojure by upstream's, a task he had already started during GSoC
2021.
Sadly, none of us were familiar with Debian's mechanism for alternatives. If you
(yes you, dear reader) are familiar with it, I'm sure he would warmly welcome
feedback on his development branch.
pollo
As for me, I:
Fixed a classpath bug in core-async-clojure that was breaking other
libraries.
Added meaningful autopkgtests to core-async-clojure.
Uploaded new versions of tools-analyzer-clojure and
trapperkeeper-clojure with autopkgtests.
Updated pomegranate-clojure and nrepl-clojure to the latest upstream
version and revamped the way they were packaged.
Assisted lavamind with Clojure packaging.
Overall, it was quite a productive sprint!
Thanks to Debian for sponsoring our food during the sprint. It was nice to be
able to concentrate on fixing things instead of making food :)
Here's a bonus picture of the nice sushi platter I ended up getting for dinner
on Saturday night:
I've been using sbuild for a while to build my Debian packages,
mainly because it's what is used by the Debian autobuilders, but
also because it's pretty powerful and efficient. Configuring it just
right, however, can be a challenge. In my quick Debian development
guide, I had a few pointers on how to
configure sbuild with the normal schroot setup, but today I finished
a qemu based configuration.
Why
I want to use qemu mainly because it provides better isolation than a
chroot. I sponsor packages sometimes and while I typically audit
the source code before building, it still feels like the extra
protection shouldn't hurt.
I also like the idea of unifying my existing virtual machine setup
with my build setup. My current VM is kind of all over the place:
libvirt, vagrant, GNOME Boxes, etc?). I've been slowly
converging over libvirt however, and most solutions I use right now
rely on qemu under the hood, certainly not chroots...
I could also have decided to go with containers like LXC, LXD, Docker
(with conbuilder, whalebuilder, docker-buildpackage),
systemd-nspawn (with debspawn), unshare (with schroot
--chroot-mode=unshare), or whatever: I didn't feel those offer the
level of isolation that is provided by qemu.
The main downside of this approach is that it is (obviously) slower
than native builds. But on modern hardware, that cost should be
minimal.
Then to make this used by default, add this to ~/.sbuildrc:
# run autopkgtest inside the schroot
$run_autopkgtest = 1;
# tell sbuild to use autopkgtest as a chroot
$chroot_mode = 'autopkgtest';
# tell autopkgtest to use qemu
$autopkgtest_virt_server = 'qemu';
# tell autopkgtest-virt-qemu the path to the image
# use --debug there to show what autopkgtest is doing
$autopkgtest_virt_server_options = [ '--', '/srv/sbuild/qemu/%r-%a.img' ];
# tell plain autopkgtest to use qemu, and the right image
$autopkgtest_opts = [ '--', 'qemu', '/srv/sbuild/qemu/%r-%a.img' ];
# no need to cleanup the chroot after build, we run in a completely clean VM
$purge_build_deps = 'never';
# no need for sudo
$autopkgtest_root_args = '';
Note that the above will use the default autopkgtest (1GB, one core)
and qemu (128MB, one core) configuration, which might be a little low
on resources. You probably want to be explicit about this, with
something like this:
# extra parameters to pass to qemu
# --enable-kvm is not necessary, detected on the fly by autopkgtest
my @_qemu_options = ['--ram-size=4096', '--cpus=2'];
# tell autopkgtest-virt-qemu the path to the image
# use --debug there to show what autopkgtest is doing
$autopkgtest_virt_server_options = [ @_qemu_options, '--', '/srv/sbuild/qemu/%r-%a.img' ];
$autopkgtest_opts = [ '--', 'qemu', @qemu_options, '/srv/sbuild/qemu/%r-%a.img'];
This configuration will:
create a virtual machine image in /srv/sbuild/qemu for
unstable
tell sbuild to use that image to create a temporary VM to build
the packages
tell sbuild to run autopkgtest (which should really be
default)
tell autopkgtest to use qemu for builds and for tests
Note that the VM created by sbuild-qemu-create have an unlocked root
account with an empty password.
Other useful tasks
enter the VM to make test, changes will be discarded (thanks Nick
Brown for the sbuild-qemu-boot tip!):
You might also need parameters like --ram-size if you customized
it above.
And yes, this is all quite complicated and could be streamlined a
little, but that's what you get when you have years of legacy and just
want to get stuff done. It seems to me autopkgtest-virt-qemu should
have a magic flag starts a shell for you, but it doesn't look like
that's a thing. When that program starts, it just
says ok and sits there.
Maybe because the authors consider the above to be simple enough (see
also bug #911977 for a discussion of this problem).
Live access to a running test
When autopkgtest starts a VM, it uses this funky qemu commandline:
... which is a typical qemu commandline, I'm sorry to say. That
gives us a VM with those settings (paths are relative to a temporary
directory, /tmp/autopkgtest-qemu.w1mlh54b/ in the above example):
the shared/ directory is, well, shared with the VM
port 10022 is forward to the VM's port 22, presumably for SSH,
but not SSH server is started by default
the ttyS1 and ttyS2 UNIX sockets are mapped to the first two
serial ports (use nc -U to talk with those)
the monitor UNIX socket is a qemu control socket (see the QEMU
monitor documentation, also nc -U)
In other words, it's possible to access the VM with:
nc -U /tmp/autopkgtest-qemu.w1mlh54b/ttyS2
The nc socket interface is ... not great, but it works well
enough. And you can probably fire up an SSHd to get a better shell if
you feel like it.
Nitty-gritty details no one cares about
Fixing hang in sbuild cleanup
I'm having a hard time making heads or tails of this, but please bear
with me.
In sbuild + schroot, there's this notion that we don't really need
to cleanup after ourselves inside the schroot, as the schroot will
just be delted anyways. This behavior seems to be handled by the
internal "Session Purged" parameter.
At least in lib/Sbuild/Build.pm, we can see this:
my $is_cloned_session = (defined ($session->get('Session Purged')) &&
$session->get('Session Purged') == 1) ? 1 : 0;
[...]
if ($is_cloned_session)
$self->log("Not cleaning session: cloned chroot in use\n");
else
if ($purge_build_deps)
# Removing dependencies
$resolver->uninstall_deps();
else
$self->log("Not removing build depends: as requested\n");
... which is ... a little confusing to me. $info is:
my $info = $self->get('Chroots')->get_info($schroot_session);
... so I presume that depends on whether the schroot was correctly
cleaned up? I stopped digging there...
ChrootUnshare.pm is way more explicit:
$self->set('Session Purged', 1);
I wonder if we should do something like this with the autopkgtest
backend. I guess people might technically use it with something else
than qemu, but qemu is the typical use case of the autopkgtest
backend, in my experience. Or at least certainly with things that
cleanup after themselves. Right?
For some reason, before I added this line to my configuration:
$purge_build_deps = 'never';
... the "Cleanup" step would just completely hang. It was quite
bizarre.
Disgression on the diversity of VM-like things
There are a lot of different virtualization solutions one can use
(e.g. Xen, KVM, Docker or Virtualbox). I have also
found libguestfs to be useful to operate on virtual images in
various ways. Libvirt and Vagrant are also useful wrappers on
top of the above systems.
There are particularly a lot of different tools which use Docker,
Virtual machines or some sort of isolation stronger than chroot to
build packages. Here are some of the alternatives I am aware of:
Take, for example, Whalebuilder, which uses Docker to build
packages instead of pbuilder or sbuild. Docker provides more
isolation than a simple chroot: in whalebuilder, packages are
built without network access and inside a virtualized
environment. Keep in mind there are limitations to Docker's security
and that pbuilder and sbuilddo build under a different user
which will limit the security issues with building untrusted
packages.
On the upside, some of things are being fixed: whalebuilder is now
an official Debian package (whalebuilder) and has added
the feature of passing custom arguments to dpkg-buildpackage.
None of those solutions (except the autopkgtest/qemu backend) are
implemented as a sbuild plugin, which would greatly reduce their
complexity.
I was previously using Qemu directly to run virtual machines, and
had to create VMs by hand with various tools. This didn't work so well
so I switched to using Vagrant as a de-facto standard to build
development environment machines, but I'm returning to Qemu because it
uses a similar backend as KVM and can be used to host longer-running
virtual machines through libvirt.
The great thing now is that autopkgtest has good support for qemuandsbuild has bridged the gap and can use it as a build
backend. I originally had found those bugs in that setup, but all of
them are now fixed:
#911977: sbuild: how do we correctly guess the VM name in autopkgtest?
#911979: sbuild: fails on chown in autopkgtest-qemu backend
#911963: autopkgtest qemu build fails with proxy_cmd: parameter not set
#911981: autopkgtest: qemu server warns about missing CPU features
So we have unification! It's possible to run your virtual machines
and Debian builds using a single VM image backend storage, which is
no small feat, in my humble opinion. See the sbuild-qemu blog post
for the annoucement
Now I just need to figure out how to merge Vagrant, GNOME Boxes, and
libvirt together, which should be a matter of placing images in the
right place... right? See also hosting.
pbuilder vs sbuild
I was previously using pbuilder and switched in 2017 to sbuild.
AskUbuntu.com has a good comparative between pbuilder and sbuild
that shows they are pretty similar. The big advantage of sbuild is
that it is the tool in use on the buildds and it's written in Perl
instead of shell.
My concerns about switching were POLA (I'm used to pbuilder), the fact
that pbuilder runs as a separate user (works with sbuild as well now,
if the _apt user is present), and setting up COW semantics in sbuild
(can't just plug cowbuilder there, need to configure overlayfs or
aufs, which was non-trivial in Debian jessie).
Ubuntu folks, again, have moredocumentation there. Debian
also has extensive documentation, especially about how to
configure overlays.
I was ultimately convinced by stapelberg's post on the topic which
shows how much simpler sbuild really is...
Who
Thanks lavamind for the introduction to the sbuild-qemu package.
Our Debian User Group met on December 22nd for our last meeting of
2024. I wasn't sure at first it was a good idea, but many people showed up and
it was great!
Here's what we did:
pollo:
This was our 4th meeting this year and once again, attendance was great: 10
people showed up to work on various things.
Following our bi-monthly schedule, our next meeting should be in December, but
I'm not sure it'll happen. December can be a busy month here and I will have to
poke our mailing list to see if people have the spoons for an event.
This time around, I was able to get a rough log of the Debian work people did:
pollo:
Once we had serial access, wiping the flash and re-installing OpenWRT fixed our
problem. A quick 
As always, thanks to the Debian project for granting us a budget to rent the
venue and to buy some food.
