Rebase on debian 2022.1-3 #187
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The automake test harness[1] already dumps the contents of `test-suite.log` when `VERBOSE=1` is set, so we don't need to add special handling for it. 1. https://www.gnu.org/software/automake/manual/html_node/Parallel-Test-Harness.html
This refreshes the build dependencies installed for the GitHub Tests workflow based on the Build-Depends in the upstream packaging. The handling is now more explicit about any deviations and any release differences.
Rather than use the release codename tags, use the release stage tags. This way the configuration (theoretically) doesn't need to be updated when new Debian and Ubuntu releases are made. For Debian stable is used instead of buster and a testing (bullseye) build is added. For Ubuntu, latest is used instead of focal for the current LTS and rolling is used instead of groovy for the latest release. This actually changes the Ubuntu build from groovy to hirsute.
Since #2377 was merged, this is in libtest-core.sh, which is sourced by libtest.sh. Signed-off-by: Simon McVittie <smcv@collabora.com>
libtest.sh: Remove duplicate ERR trap and report_err()
This tweaks `ostree_repo_write_commit` so that it checks for the envinroment variable `SOURCE_DATE_EPOCH` as a way to override the current time, which is used as the commit timestamp. Ref: https://reproducible-builds.org/docs/source-date-epoch/ Ref: https://reproducible-builds.org/specs/source-date-epoch/
lib/commit: respect SOURCE_DATE_EPOCH for commit timestamp
The `systemd-rfkill.*` service falls in the category of early things that need write access to `/var`, so we need to make sure we run before or it might hit the read-only sysroot. The long-term fix for this is ostreedev/ostree#2115. Closes: coreos/fedora-coreos-tracker#746
ostree-remount: Order before systemd-rfkill.*
Prow is not managing merges on this repo.
OWNERS: remove
This fixes the ci-release-build.sh script to directly source and evaluate 'package_version' from its m4 definition, without requiring a fully configured source tree.
ci/release-build: evaluate package_version from m4 definition
Release 2021.3
A statoverride file written in the obvious way will produce incorrect results for two independent reasons. Document them.
man: improve statoverride description
Currently the verifier only imports all the GPG keys when verifying data, but it would also be useful for inspecting the trusted keys.
In order to use the GPG verifier, it needs to be seeded with GPG keys after instantation. Currently this is only used for verifying data, but it will also be used for getting a list of trusted GPG keys in a subsequent commit.
Currently the verifier decides whether to include the global keyrings based on whether the specified remote has its own keyring or not. Allow callers to exclude the global keyrings even when that's not the case. This will be used in a subsequent commit in order to get the GPG keys only associated with a remote.
This function enumerates the trusted GPG keys for a remote and returns an array of `GVariant`s describing them. This is useful to see which keys are collected by ostree for a particular remote. The same information can be gathered with `gpg`. However, since ostree allows multiple keyring locations, that's only really useful if you have knowledge of how ostree collects GPG keyrings. The format of the variants is documented in `OSTREE_GPG_KEY_GVARIANT_FORMAT`. This format is primarily a copy of selected fields within `gpgme_key_t` and its subtypes. The fields are placed within vardicts rather than using a more efficient tuple of concrete types. This will allow flexibility if more components of `gpgme_key_t` are desired in the future.
This provides a wrapper for the `ostree_repo_remote_get_gpg_keys` function to show the GPG keys associated with a remote. This is particularly useful for validating that GPG key updates have been applied. Tests are added, which checks the `ostree_repo_remote_get_gpg_keys` API by extension.
This will be used to implement the PGP Web Key Directory (WKD) URL generation. This is a slightly cleaned up implementation[1] taken from the zbase32 author's original implementation[2]. It provides a single zbase32_encode API to convert a set of bytes to the zbase32 encoding. I believe this should be acceptable for inclusion in ostree. The license in the source files is BSD style while the original repo LICENSE file claims the Creative Commons CC0 1.0 Universal license, which is public domain. 1. https://github.com/dbnicholson/libbase32/tree/for-ostree 2. https://github.com/zooko/libbase32
Calculate the advanced and direct update URLs for the key discovery portion[1] of the OpenPGP Web Key Directory specification, and include the URLs in the key listing in ostree_repo_remote_get_gpg_keys(). These URLs can be used to locate updated GPG keys for the remote. 1. https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service#section-3.1
If the key UID contains a valid email address, include the GPG WKD update URLs in GVariant returned by ostree_repo_remote_get_gpg_keys().
Update to upstream version '2022.1' with Debian dir 8a98c57b6bb7149bd55803c783f08a2e917525b8
Gbp-Dch: ignore
Previous versions relied on being able to use FUSE 2 options that are no longer supported by FUSE 3, so prepare a lockstep transition.
Since compat level 11, man pages installed by the upstream build system can be listed in d/*.manpages and will automatically be excluded under the nodoc build-profile.
Endless doesn't use the full GRUB integration (etc/grub.d/15_ostree), but instead we only use the Boot Loader Spec (BLS) configuration from GRUB to show new ostree entries. Rebase 2019.3 (T27607): replaced 4705bb8 "Restore ostree-boot files to main ostree package" Debian doesn't install the ostree-boot package since they don't have a way to confirm it works, but we install those pieces as part of the main ostree package. The only exception is the full GRUB integration (etc/grub.d/15_ostree), where we only use the Boot Loader Spec (BLS) configuration from GRUB to show new ostree entries. https://phabricator.endlessm.com/T17204 Rebase 2018.6 (T23138): Move the new systemd service lib/systemd/system/ostree-finalize-staged.service from ostree-boot to ostree Rebase 2019.1 (T25195): Move ostree-finalize-staged.path from ostree-boot to ostree Rebase 2019.3 (T27607): Re-integrate non-grub parts with ostree-boot package which is now built in debian.
This reverts commit 285a482. Our flatpak-builder doesn't support FUSE 3, so we'll continue to build `rofiles-fuse` with FUSE 2. https://phabricator.endlessm.com/T32964
This reverts commit 336f3b8. Our flatpak-builder is older than this and we've reverted the change to use FUSE 3 to maintain compatibility. https://phabricator.endlessm.com/T32964
Our packaging diverges from debian's because our package provides most of the booting bits that debian put in its placeholder ostree-boot package. See debian/README.Endless for details. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://phabricator.endlessm.com/T18836 Rebase 2019.1 (T25195): Changed usr/lib/libostree/grub2-15_ostree to usr/libexec/libostree/grub2-15_ostree Rebase 2019.3 (T27607): squashed with 3d90106 "Update README.Endless with pointer to debian's git" https://phabricator.endlessm.com/T22022 Rebase 2019.3 (T27607): Updated documentation Rebase 2020.8 (T31593): squashed with b1aff69 "d/README.Endless: Update downstream changes documentation" Rebase 2022.1 (T32964): squashed with 1d7aaa6 "d/README.Endless: Remove trivial-httpd delta". Updated documentation to remove `gjs` delta and mention FUSE 2 vs FUSE 3 delta.
This patch has been applied to the source branch. https://phabricator.endlessm.com/T32964
|
retest this please, Jenkins! |
pwithnall
approved these changes
Feb 7, 2022
There was a problem hiding this comment.
LGTM. CI is failing but that looks like a missing tag:
+ dch -v 2020.8+dev24.c6a1f7e-457 -D master --force-distribution 'Automatic release from git (2020.8+dev24.c6a1f7e-457)'
dch: fatal error at line 1220:
New version specified (2020.8+dev24.c6a1f7e-457) is less than
the current version number (2022.1-3endless1)! Use -b to force.
|
Looks like the |
|
retest this please |
Thanks. I tried to outsmart my own stupid system and lost. |
|
Argh. It's trying to use the |
|
Moved to #189 with the "correct" branch name. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
Ensures that our
grub.cfgwon't be updated if the deploy code gets to that point. In #186 I left some notes about reliably ensuring that thebootloader=nonecase is always taken. For now I think we should keep this.Re-enabled in by debian 2021.3-1.
Reverted later since eos-updater no longer relies on it.
Not much to say here. Updated the packaging changes to remove the
gjsdelta and mention the FUSE 2 v 3 delta (see below).Old changelog entry.
See above.
Upstream backports.
The only other change has to do with FUSE and flatpak-builder. flatpak-builder uses ostree's
rofiles-fusefilesystem. Recentlyrofiles-fusewas 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 withrofiles-fuse. So, for now I reverted the commits to build against FUSE 3 and declareBreaks: 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-3. The master PR is in #186.
https://phabricator.endlessm.com/T32964