Quoting Carsten Schoenert (2021-10-06 14:32:00)
I've looked at localechooser as it's mentioned currently in the synchronization issues for landing.
https://master.pureos.net/sync/landing
Last time the package was touched was in 2018 by Matthias and shortly later by Chris [1]. As Matthias choose to start with a standalone branch back in 2018 I now merged the Debian tag 2.93 from the upstream repository on Salsa into a derived branch pureos/latest based on the standalone branch named master within the Purism tree. That's how I see future work will be manageable, merging the required Debian tag into the derived PureOS tree as done in other forked repos. I managed to get the merge conflicts solved so far.
I also added a configuration for gbp and also a CI controlling file.
So why I'm posting here? Simply because there is no target branch on the destination tree I can create a MR for and also because I'm currently not know much about the background for this forked package.
So please have a look at the current state I prepared [2] for further discussion. The CI pipeline succeeded so far. But as for python-apt, other things might be needed to check before pushing my work to the main repo.
[1] https://source.puri.sm/pureos/core/localechooser [2] https://source.puri.sm/carsten.schoenert/localechooser/-/commits/pureos/late...
Interesting case, Carsten. Thanks for bringing it up here!
Purism work can be tricky because it intermixes upstream and downstream work - i.e. Purism is sometimes upstream of e.g. Debian and GNOME, and sometimes Purism is downstream to them, even for same code projects.
Purism has an "upstream first" mantra. To me that translates generally as "commit upstream work directly to upstream repos (don't wait for upstream to cherry-pick from some downstream repo)".
Purism customers have higher priority than the "upstream first" mantra, however: In cases where pushing urgent changes upstream would delay getting them into Purism products, Purism customers take precedence.
(sorry if above is obvious to you - took some time for me to align it)
The previous PureOS packaging of localechooser seems weakly aligned with upstream: It tracked upstream _tarball_ source but not upstream _git_ development.
Maybe the reason was to quickly serve Purism customers back then. Assuming we are not in a similar hurry now, this seems a good time to switch to use the "upstream first" mantra for this packaging work.
Personally¹ I do "upstream first" package maintenance by treating upstream packaging branch as the _only_ baseline, rebasing PureOS commits on top of that when needing to realign with Debian.
I would therefore start over from scratch, starting from upstream Debian git repo. Something like this:
1. fetch upstream Debian packaging project:
debcheckout localechooser
...or if that fails then locate git and do it manually:
git clone https://salsa.debian.org/installer-team/localechooser.git
2. include previous work as remote branch _without_ merging:
git remote add pureos_old https://source.puri.sm/pureos/core/localechooser.git git fetch pureos_old
3. rewind to closest possible upstream commit before or at their latest release:
git reset --hard 2.93
4. auto-generate² boilerplate forking commits:
~/projects/PURISM/FEATURE/package/bin/fork_at_pureos_for_byzantium.sh
5. cherry-pick non-boilerplate commit from previous work:
git cherry-pick 87c1922826060102a2d5a9abe968dc657630fab9
6. finalize¹ and release:
dch --local ~pureos . gbp dch -a DEBEMAIL="jonas.smedegaard@puri.sm" dch --vendor pureos --distribution byzantium --release git commit -m "prepare for release: update changelog" -a
¹ Others in Purism do differently, treating _both_ Debian and PureOS timelines as parallel "baselines", merging them when needing to realign with Debian, but I find that such "multiverse" of multiple timelines has higher risk of breaking in subtle maybe unnoticed ways and therefore less reliably tracks atomic commits to pass upstream, and find it cumbersome to compose a meaningful changelog for our users from such multiverse structure. See https://tracker.pureos.net/T1049 for discussion on changelog style (which often reflects underlying git structure as well).
² My approach is also documented - with details on steps 4 and 6 - at https://source.puri.sm/-/snippets/1165#fork-for-pureos
- Jonas