During a system install with the system helper enabled, the initial
network pull goes to a temporary repo and then via pull local from that
repo to the final system repo while during user install there is only
one pull from network to the final repo.
c672c55 set the logger to use the temporary repo path as installation
but the history command afc87ad since the same day filters the initial
pull out as the installation name will never match the temporary path.
This causes the initial pull operation to be never show up in flatpak
history when using system installs while they work for user installs as
`INSTALLATION=user`.
This is presumably also broken for custom installations as they
will similarly not match the temp repo path.
So don't pass the path at all to flatpak_dir_log and we can later
fall back via flatpak_dir_get_name_cached() which sets the correct
`INSTALLATION` for system installs ie. `INSTALLATION=system`.
This also allows us to remove the workaround of adding two different
expected history outputs from ad1ff6d as both branches log the pull.
Without system helper `flatpak install` needs to be executed as
priviledged to operate on system install so the initial pull was
always logged correctly for that branch.
The tests assumed that a system installation always uses the XDG cache
location unless running as root. However, Flatpak only uses that cache
location when the system helper is available at both compile and run
time. [1]
Builds configured with -Dsystem_helper=disabled instead use the
repo-local cache directory [2], causing the tests to look for cached
summaries in the wrong location and fail.
[1]: 96ad6825f3/common/flatpak-dir.c (L4853-L4862)
[2]: 96ad6825f3/common/flatpak-dir.c (L4942-L4943)
Add a regression test that installs from an auth-protected OCI registry.
The registry requires a bearer token for all /v2/ requests; the client
authenticates via the mock test authenticator and the installation
completes successfully. The test runs for both user and system install
paths.
Assisted-by: Cursor
Add infrastructure for testing OCI installations from auth-protected
registries. The mock server now supports requiring a bearer token on all
/v2/ requests, configurable via a new POST /testing-auth/configure admin
endpoint. The client gains a corresponding 'configure-auth' subcommand.
Assisted-by: Cursor
The warning seems to happen with GCC 11 but not with GCC 13 or newer.
A simple void cast still leaves the warning enabled due to a bug
or intentional choice in GCC [1], so it is assigned to a variable first
and then void-ed.
[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
If we convert fallback-x11 internally to a conditional x11 permission,
we cannot express current fallback-x11 stacking behavior:
lower: empty + upper: !fallback-x11 -> no x11 access
lower: fallback-x11 + upper: !fallback-x11 -> x11 access
The reason is that conditionals have no view of the lower level.
This changes things in a way that fallback-x11 stays its own socket
permission with two interactions with the x11 socket permission:
* If a upper level resets x11 (--socket=x11, --nosocket=x11), the lower
level fallback-x11 permission gets dropped
* When computing the allowed sockets, --socket=fallback-x11 gets
converted to --socket=if:x11:!has-wayland
Fixes: #6556
Instead of trying to read them into variables, which could fail if there
were null bytes in the key.
Fixes: 43642337 ("dir: Try to delete the remote if we failed to add it entirely")
I was convinced that the pattern `! command` with -e aborts when
`command` fails. This is not the case (the result of `false` is the same
as `! true` but somehow this doesn't matter).
Fix the tests and use the newly introduced `assert_not` function. One
could also use `command && assert_not_reached "message"` but who has
time to write error messages for all the cases.
Add an integration test that verifies the Flatpak-Upgrade-From HTTP
header is correctly sent during update operations but absent during
fresh installs. This header is used by Flathub to distinguish updates
from new installs in download statistics.
To support the test, extend web-server.py to optionally log Flatpak-*
request headers to a separate file.
Ideally, we would be able to atomically add and remove remotes, but
we're very far from that ideal state. The current behavior is really
suboptimal and leaves the remotes in a inconsistent state if
initialization failed. We can at least make it better by trying to clean
up the half-initialized mess we're currently in. It does however not
protect against SIGKILL-like aborts, as that would require it to be
atomic.
Closes: #6449
Co-authored-by: craftyguy "Clayton Craft" <clayton@craftyguy.net>
This gets rid of the test-matrix generation, and instead enumerates all
the tests in meson.
Some people (including me) constantly modified the generated meson
instead of the test-matrix generator file because they find it so
uncommon and unusual that a meson file is generated.
This looses the combinatorial combination of the generated system, but
in practice, six lines of enumeration is not bad, and it makes things
easier to understand.
test-run-custom.sh was only manually appended to test-matrix/meson.build
and would be lost on regeneration. Add it to update-test-matrix so it is
properly managed.
When repair (re)installs runtimes via a transaction, the transaction
auto-pins every runtime it touches. This causes repair --reinstall-all
to pin every installed runtime, cluttering the pin list with runtimes
that were never explicitly pinned by the user and preventing
flatpak remove --unused from cleaning them up.
Fix this by disabling auto-pinning on the repair transaction so that
the pin state is left exactly as it was before the repair.
Fixes https://github.com/flatpak/flatpak/issues/6565
flatpak-run takes a number of arguments which are file descriptor
numbers. Those file descriptors are supposed to set something up in the
way the instance gets spawned, but should never make it to the wrapper
command.
When we run `tests/test-run-custom.sh` as a build-time test,
we expect to already have the necessary runtimes, apps, etc. in
`${builddir}/tests/runtime-repo`. However, when running "as-installed"
tests, we're using a fresh temporary ostree repo for each test.
Merely having the repo exist is not enough: for some tests, and in
particular `tests/test-run-custom.sh`, it needs to have more than one
runtime available.
Resolves: https://github.com/flatpak/flatpak/issues/6591
Signed-off-by: Simon McVittie <smcv@collabora.com>
When an application or runtime is updated and its metadata requests a
new branch of an extension, Flatpak should automatically pull the new
branch if the user already has at least one branch of that extension
installed.
This ensures that "no-autodownload" extensions (like GIMP plugins)
stay functional after an update that requires a new branch, while still
respecting the user's explicit opt-in (the existing installation of
a previous branch).
Fixes: https://github.com/flatpak/flatpak/issues/4208
test-preinstall.sh was present in the generated test-matrix/meson.build
but missing from TEST_MATRIX_SOURCE in update-test-matrix, meaning it
would be dropped if the matrix were regenerated.
This was not a typo for "located": the daemon is systemd-localed,
or localed for short.
Fixes: bb549168 "fix: cross typos, detail below"
Signed-off-by: Simon McVittie <smcv@collabora.com>
What I did
Repository rules / “don’t edit” areas
From CONTRIBUTING.md and subprojects/README.md, subprojects/ contains vendored/submodule/copylib code (bubblewrap, libglnx, dbus-proxy, variant-schema-compiler). I treated subprojects/ as third-party and excluded it from typo fixing.
You already skip po/ (translations) and node_modules/, and I kept those exclusions.
Typos fixed (project-owned files only)
I ran codespell with write mode and exclusions, and fixed the reported typos across:
NEWS
app/…
common/…
doc/…
tests/…
session-helper/…
portal/…
data/…
Then I handled the remaining items individually:
NEWS: thse -> these
common/flatpak-utils-private.h: Thse -> These
app/flatpak-polkit-agent-text-listener.c: identies -> identities
tests/test-auth.sh: Propertly -> Properly
tests/testlibrary.c: remore -> remote
common/flatpak-transaction.c: improved wording to avoid the xwindows typo (X11 window ID)
Added .codespellrc
Created .codespellrc:
skip: node_modules,po,subprojects
ignore-regex: .*(ratatui|Affinitized|affinitized).*
ignore-words-list: nd,ot,THUR,IST,fo,hel,bu
(these were confirmed as legitimate tokens/abbreviations/namespace prefix/test strings in this repo, so they should not be “fixed”)
Verification:
codespell --config .codespellrc . now exits clean.
Signed-off-by: rezky_nightky <with.rezky@gmail.com>
Since commit d10e1148 "Add initial support for preinstalling flatpaks",
the test suite sets FLATPAK_DATA_DIR to a temporary directory, both
while running uninstalled and as-installed.
While running uninstalled we already set FLATPAK_TRIGGERSDIR to the
trigger scripts in the source tree, but when running "as-installed",
we need to run the triggers that the OS installs as part of the flatpak
package (or equivalent).
Not having this caused autopkgtests (automated as-installed tests) in
Debian to regress with 1.17.x.
Fixes: d10e1148 "Add initial support for preinstalling flatpaks"
Signed-off-by: Simon McVittie <smcv@debian.org>
This gives us conditionals for shares and features. So far we have no
use case for this, but the system already exists, it makes the code
simpler, and when we need this in the future, we don't have to wait for
it to roll out.
journalctl also prints something when the message didn't make it to
whatever journalctl connects to. Check for the specific message showing
up instead to make sure it all works as expected.
A few years ago there was a very painful attempt at porting from
libsoup2 to libsoup3. Flatpak libsoup3 support never landed and it seems
like a large amount of distros have switched over to libcurl instead.
This commit removes libsoup2 support completely instead of growing
libsoup3 support.
Closes#5915Closes#4582
We could previously just assume that the first enabled remote
(potentially matching the collection ID) contains the ref, but that
obviously is not always the case.
The change here looks up the remote state of the remotes to figure out
if they actually contain the ref, and adds the first matching remote to
the transaction.
Otherwise we try to call setfattr which fails and have_xattr reports
that there is no xattr support. This might then obviously be wrong and
the test can fail because of that.
If the binaries are not available in the environment, the trigger will
not do anything. The tests will not know about this and fail. So only
test for the results of the triggers if they have the dependencies they
require.
