Rebase on debian 2022.1-3

[dbnicholson]

This is a rebase on top of debian's 2022.1-3 package. Here's a list of our patches on top of our previous 2020.8-2 base:

• 80cbe1c Remove grub2 files from ostree-boot package

Ensures that our grub.cfg won't be updated if the deploy code gets to that point. In #186 I left some notes about reliably ensuring that the bootloader=none case is always taken. For now I think we should keep this.

• 2db10b2 Revert "Temporarily disable gjs tests"

Re-enabled in by debian 2021.3-1.

• d610232 Bring back trivial-httpd subcommand

Reverted later since eos-updater no longer relies on it.

• cd33889 debian: Document Endless packaging changes
• 3f1fc48 Remove debian/patches

Not much to say here. Updated the packaging changes to remove the gjs delta and mention the FUSE 2 v 3 delta (see below).

• 4c6f5c7 Release 2020.8-2endless1

Old changelog entry.

• 7376aed Revert "Bring back trivial-httpd subcommand"
• 1d7aaa6 d/README.Endless: Remove trivial-httpd delta

See above.

• 6102bb4 d/libostree-1-1.symbols: Add backported repo locking symbols
• 7e951c7 d/control: Bump glib build dep to 2.44.0

Upstream backports.

The only other change has to do with FUSE and flatpak-builder. flatpak-builder uses ostree's rofiles-fuse filesystem. Recently rofiles-fuse was changed to build using either FUSE 2 or FUSE 3 and debian changed their build to use FUSE 3. We're still using bullseye's flatpak-builder 1.0.12, which tries to use FUSE 2 only options with rofiles-fuse. So, for now I reverted the commits to build against FUSE 3 and declare Breaks: flatpak-builder (<< 1.2.1-2~).

I think when I go to update flatpak to 1.12 I'll likely pull in flatpak-builder from testing so they stay in sync. But I can't do it the other way around since flatpak-builder 1.2 depends on flatpak 1.12.

The post-rebase queue can be seen in Version_2022.1_debian...T32964-rebase-2022.1-debian. The master PR is in #186.

https://phabricator.endlessm.com/T32964

[pwithnall]

Assuming this hasn’t changed from #187 (I haven’t checked), this is still LGTM.

[dbnicholson]

Assuming this hasn’t changed from #187 (I haven’t checked), this is still LGTM.

Thanks! It's the same. I just renamed the branch locally and pushed it out again.