Commits on Source (26)
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We don't enforce a specific error message, but we do assert that there's no output on stdout, and an error message prefixed with the program name on one of the lines of stderr. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will let us change the behaviour of all diagnostic messages at once, by changing only capsule_logv(). For now, the syslog-style severity is accepted but ignored. Subsequent commits will make use of this. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This allows them to be distinguished from messages logged by some other executable invoked around the same time, and makes `capsule_log( LOG_WARNING, ... )` a drop-in substitute for `warnx()`. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These mimic the behaviour of errx() and warnx(), but will benefit from future enhancements to capsule_log(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In a couple of places this requires explicitly emitting the stringified value of errno, because we have equivalents of warnx() and errx(), but not warn() and err(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will allow the output of capsule-capture-libs (and in principle other tools) to be piped to a log handler such as `logger --prio-prefix`, `systemd-cat --level-prefix=true` or `srt-logger --parse-level-prefix` which will filter or format the messages according to their severity. As currently implemented, fatal errors are emitted as LOG_ERR, warnings are LOG_WARNING, and all debug messages are LOG_DEBUG. A facility such as LOG_USER is not included: this is optional for logger(1), and not allowed for systemd-cat(1) and srt-logger. steamrt/tasks#444 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Repeat the test-case where we produced an error message about a library having the wrong ABI, but this time, use --level-prefix and assert that we add the <3> prefix for a fatal error. steamrt/tasks#444 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously we said "warning:" for about half the warnings, and didn't annotate fatal errors at all. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ryan Gonzalez authored
`self->file_stat` was only initialized if an fd was *not* given, which would lead it to always re-create the log file once. steamrt/tasks#487 Signed-off-by:
Ryan Gonzalez <ryan.gonzalez@collabora.com>
-
Ryan Gonzalez authored
I wasn't aware that simple assignment worked here. steamrt/tasks#487 Signed-off-by:
Ryan Gonzalez <ryan.gonzalez@collabora.com>
-
Simon McVittie authored
Sometimes we find ourselves capturing a library for which the dependencies can legitimately be missing, for example `libnvidia-pkcs11.so.*` on Ubuntu 24.04 (which depends on OpenSSL 1.1, which Ubuntu no longer provides). This is really an OS bug (providing a library without its dependencies), and ideally Ubuntu should stop providing `libnvidia-pkcs11.so.*` (like Debian did), but it results in confusing messages that could make a user wrongly believe that it's the root cause of a genuine problem. steamrt/tasks#488 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In a test that already emits a warning message, prepending "quiet:" to the pattern should de-escalate the warning to a debug message. In a test that emits a fatal error, prepending "quiet:" to the pattern has no effect: it's still an error. steamrt/tasks#488 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Otherwise, after reopening a deleted or replaced file, we would reopen it once per line, because its inode number constantly differs from the original inode number. After commit 1f502cb4 "logger: Fix always re-opening files when --log-fd is used", this was the only remaining place where we assign to self->file_fd without also assigning to self->file_stat. Fixes: 8f65507d "logger: Recreate output log files if they get deleted" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This would have made it considerably easier to spot that commit 8f65507d "logger: Recreate output log files if they get deleted" was reopening the log file more often than it should have been. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In older Steam releases this was distributed broken up into pieces (`steam-runtime.tar.xz.part*`), but since beta 1705630720 (2024-01-19) and GA 1714854927 (2024-05-04) it's a single large file. Adjust our fallback code path to take this into account. steamrt/tasks#490 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously, if we were using --remap-link-prefix but not --link-target (as in pressure-vessel), and if the path at which we found the library in the provider (`needed_path_in_provider`) was such that after resolving symlinks, the canonicalized result (`path`) did not match any of the --remap-link-prefix options, then we would reset to using the `needed_path_in_provider` as the symlink target. However, this was wrong, because it did not take into account the possibility that the original path might have matched one of the --remap-link-prefix options even though its canonicalized version didn't. For example, consider the NixOS "FHS environment", a bwrap-based container that has been populated with symlinks of the form /lib/libGL.so.1 -> /nix/store/something. Depending on the precise behaviour of libc and libdl (the exact trigger for the differing behaviour is unknown), when we open that library, we might find that the `needed_path_in_provider` is either /lib/libGL.so.1 or a path below /nix/store. If the `needed_path_in_provider` is /lib/libGL.so.1, we would canonicalize it to /nix/store/something, then decide that /nix/store/something didn't match any of the remapping rules such as `/lib*` → `/run/host/lib*`, and go back to using /lib/libGL.so.1 as the symlink target. But, inside pressure-vessel's container, `/lib` is from the container runtime and not the provider - which is precisely why we need to rewrite /lib paths to /run/host/lib in order to be able to find the library we want. Instead, we must limit the situation where we keep the `needed_path_in_provider` as-is to the situation where there is no symlink target rewriting: no --link-target, and no --remap-link-prefix. In this situation, we are expecting the meaning of a symlink in the container environment to be identical to the meaning of a symlink in the environment from which we are running capsule-capture-libs, therefore it's slightly preferable to use a non-canonicalized symlink if we have one: that way, if the target of a symlink changes during the container's lifetime (perhaps as a result of an OS upgrade), it will still work. Conversely, if we are using either --link-target or --remap-link-prefix, we want to stick to using only the canonicalized paths of libraries, because that's the only way we can avoid a symlink being interpreted differently outside and inside the container, for example as a result of its parent directory being mounted in a different place, or as a result of something different being mounted at its target. This means that we have to relax one of our test assertions slightly. Helps: https://github.com/ValveSoftware/steam-runtime/issues/684 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
logger: Fix always re-opening files when --log-fd is used See merge request !743
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
SLR 1.0: Assume that steam-runtime.tar.xz is a monolithic tarball See merge request !744
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
Showing
- debian/changelog 21 additions, 2 deletionsdebian/changelog
- meson.build 2 additions, 2 deletionsmeson.build
- steam-runtime-tools/logger.c 44 additions, 13 deletionssteam-runtime-tools/logger.c
- subprojects/container-runtime/runtimes/scout-on-soldier/scout-on-soldier-entry-point-v2 2 additions, 2 deletions...runtimes/scout-on-soldier/scout-on-soldier-entry-point-v2
- subprojects/libcapsule/CONTRIBUTING.md 1 addition, 1 deletionsubprojects/libcapsule/CONTRIBUTING.md
- subprojects/libcapsule/debian/changelog 15 additions, 0 deletionssubprojects/libcapsule/debian/changelog
- subprojects/libcapsule/tests/CapsuleTest.pm 10 additions, 0 deletionssubprojects/libcapsule/tests/CapsuleTest.pm
- subprojects/libcapsule/tests/capture-libs.pl 70 additions, 32 deletionssubprojects/libcapsule/tests/capture-libs.pl
- subprojects/libcapsule/utils/capture-libs.c 73 additions, 32 deletionssubprojects/libcapsule/utils/capture-libs.c
- subprojects/libcapsule/utils/debug.h 18 additions, 2 deletionssubprojects/libcapsule/utils/debug.h
- subprojects/libcapsule/utils/library-cmp.c 14 additions, 15 deletionssubprojects/libcapsule/utils/library-cmp.c
- subprojects/libcapsule/utils/utils.c 60 additions, 0 deletionssubprojects/libcapsule/utils/utils.c