| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| test-pull-summary-sigs-Set-timestamps-to-serve-expected-f.patch | test-pull-summary-sigs: Set timestamps to serve expected files If this is not done, the test can fail when the temporary directory is a tmpfs: for example this happens during build-time testing with /var/tmp on tmpfs or TEST_TMPDIR pointing to a tmpfs, or installed-tests with gnome-desktop-testing-runner allocating the test directory on a tmpfs. In particular, many of Debian's official autobuilders now do the entire build and test procedure in a chroot hosted on a tmpfs, to improve build performance and prevent fsync overhead. In this situation, it appears that overwriting summary.sig with a copy of summary.sig.2 is not sufficient for the web server to tell the libostree client that it needs to be re-downloaded. I'm not completely sure why, because tmpfs does appear to have sub-second-resolution timestamps, but forcing a distinct mtime is certainly enough to resolve it. |
Simon McVittie <smcv@collabora.com> | yes | debian | 2020-11-22 | |
| Fall-back-if-copy_file_range-fails-with-EINVAL.patch | Fall back if copy_file_range fails with EINVAL Although EINVAL usually indicates a programming error, ecryptfs (and possibly other stacked filesystems) returns EINVAL for attempts to copy_file_range() or sendfile() between files on that filesystem. |
Olaf Leidinger <oleid@mescharet.de> | yes | debian upstream | 2022-01-24 | |
| libotutil-Avoid-infinite-recursion-during-error-unwinding.patch | libotutil: Avoid infinite recursion during error unwinding When we clean up from an error, for example copy_file_range() failing while we generate a static delta (perhaps caused by https://gitlab.gnome.org/GNOME/libglnx/-/issues/3 or by a genuine write error), we might free a variant builder that has a non-null parent. Previously, this caused infinite recursion and a stack overflow, repeatedly freeing the same object, but Luca Bruno suggested that the intention here appears to have been to free the parent object. Partially resolves https://github.com/ostreedev/ostree/issues/2525 (the other bug reported in that issue needs to be resolved by updating libglnx to a version where libglnx#3 has been fixed). |
Simon McVittie <smcv@collabora.com> | yes | upstream | 2022-01-28 | |
| Fix-marking-static-delta-commits-as-partial.patch | Fix marking static delta commits as partial This patch makes it so that we mark the .commit file from a static delta as partial before writing the commit to the staging directory. This exactly mirrors what we do in meta_fetch_on_complete() when writing the commit on that codepath, which should lend some credibility to the correctness of this patch. I have checked that this fixes an issue Flatpak users have been encountering (https://github.com/flatpak/flatpak/issues/3479) which results in error messages like "error: Failed to install org.freedesktop.Sdk.Extension.texlive: Failed to read commit c7958d966cfa8b80a42877d1d6124831d7807f93c89461a2a586956aa28d438a: No such metadata object 8bdaa943b957f3cf14d19301c59c7eec076e57389e0fbb3ef5d30082e47a178f.dirtree" Here's the sequence of events that lead to the error: 1. An install operation is started that fetches static deltas. 2. The fetch is interrupted for some reason such as network connectivity dropping. 3. The .commit and .commitmeta files for the commit being pulled are left in the staging dir, e.g. "~/.local/share/flatpak/repo/tmp/staging-dfe862b2-13fc-49a2-ac92-5a59cc0d8e18-RURckd" 4. There is no `.commitpartial` file for the commit in "~/.local/share/flatpak/repo/state/" 5. The next time the user attempts the install, libostree reuses the existing staging dir, pulls the commit and commitmeta objects into the repo from the staging dir on the assumption that it's a complete commit. 6. Flatpak then tries to deploy the commit but fails in ostree_repo_read_commit() in flatpak_dir_deploy(), leading to the error message "Failed to read commit ..." 7. This happens again any subsequent time the user attempts the install, until the incomplete commit is removed with "flatpak repair --user". I will try to also add a workaround in Flatpak so this is fixed even when Flatpak links against affected versions of libostree. |
Phaedrus Leeds <mwleeds@protonmail.com> | yes | upstream | upstream, 2022.2, commit:5d3b1ca37a508e9f80702b7ef7383fe95253ec6a | 2022-02-19 |
| lib-Fix-a-bad-call-to-g_file_get_child.patch | lib: Fix a bad call to g_file_get_child In Glib, since commit 3a6e8bc8876e149c36b6b14c6a25a718edb581ed, `g_file_get_child` does not accept absolute path as paramater anymore. The broken assertion was encountered during `ostree admin deploy` command for the checkout of subpath `etc`. Example of error log: ``` (ostree admin deploy:1640): GLib-GIO-CRITICAL **: 03:42:00.570: g_file_get_child: assertion '!g_path_is_absolute (name)' failed (ostree admin deploy:1640): GLib-GIO-CRITICAL **: 03:42:00.570: g_file_query_info: assertion 'G_IS_FILE (file)' failed ** OSTree:ERROR:src/ostree/ot-main.c:232:ostree_run: assertion failed: (success || error) Bail out! OSTree:ERROR:src/ostree/ot-main.c:232:ostree_run: assertion failed: (success || error) ``` |
Valentin David <me@valentindavid.com> | yes | upstream | upstream, 2021.6, commit:adc097a2edb1b7aaf5604043b4b1d5bd6ef8a308 | 2021-11-02 |
| Fix-translation-of-file-URIs-into-paths.patch | Fix translation of file:// URIs into paths Currently if a file path contains a special character such as '\', and that character is encoded into a file:// URI that is passed to ostree_repo_pull_with_options(), the percent encoding will remain in the path passed to g_file_new() (in the case of backslash %5C) and the pull will then fail with a file not found error. This is an important edge case to handle because by default on many Linux distributions a filesystem with no label is mounted at a path based on its UUID, and this is then passed to systemd-escape by Flatpak (when --enable-auto-sideloading was used at compile time) to create a symbolic link such as this which contains backslashes: $ ls -l /run/flatpak/sideload-repos/ total 0 lrwxrwxrwx 1 mwleeds mwleeds 55 Mar 9 14:21 'automount-run-media-mwleeds-29419e8f\x2dc680\x2d4e95\x2d9a31\x2d2cc907d421cb' -> /run/media/mwleeds/29419e8f-c680-4e95-9a31-2cc907d421cb And Flatpak then passes libostree a file:// URI containing that path, to implement sideloading (pulling content from the USB drive). This results in an error like: flathub: /run/flatpak/sideload-repos/automount-run-media-mwleeds-29419e8f%5Cx2dc680%5Cx2d4e95%5Cx2d9a31%5Cx2d2cc907d421cb/.ostree/repo: opendir(/run/flatpak/sideload-repos/automount-run-media-mwleeds-29419e8f%5Cx2dc680%5Cx2d4e95%5Cx2d9a31%5Cx2d2cc907d421cb/.ostree/repo): No such file or directory This patch avoids such errors by using g_file_new_for_uri() instead of g_file_new_for_path(), so that GLib handles the %-decoding for us. |
Phaedrus Leeds <mwleeds@endlessos.org> | yes | upstream | upstream, 2021.1, commit:19577522f8eacd868cf25d53e1ac0e7f424e952b | 2021-03-10 |
| debian/Skip-test-pull-repeated-during-CI.patch | Skip test-pull-repeated during CI This test is expected to fail a small proportion of the time. During the build of ostree 2018.7-1 in Debian, it seems we were unlucky on s390x. Non-deterministic tests are also problematic for autopkgtest, where they can gate migration of our dependencies like GLib, so skip this test unless the caller has opted-in to non-deterministic tests. It would be appropriate to enable this test in environments where failures can easily be retried and are not disruptive to other packages. |
Simon McVittie <smcv@debian.org> | no | 2018-07-30 |