| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Effectively abandoned upstream (no git activity in testsuite/ since late
2015 apart from the merging of two arm64-related Fedora patches) and not
run by their CI. EXTREMELY fragile.
Upstream appears to have got a bit more alive in 2022 so let's hope they
will sort this out before ltrace stops working altogether.
Bug: https://bugs.gentoo.org/894386
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|
|
|
|
|
|
| |
In case they either add the third component or go back to a single one.
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
| |
Package-Manager: Portage-3.0.20, Repoman-3.0.2
RepoMan-Options: --include-arches="amd64"
Signed-off-by: Agostino Sarubbo <ago@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On modern kernels with the Yama security module enabled the default
ptrace behaviour is that a process must have a predefined relationship
with the inferior it wants to call ``PTRACE_ATTACH`` on, with two
additional modes restricting process tracing even more; for details see
[1]. As a result, unless Yama is explicitly reset to classic ptrace
permissions the ltrace attach-process test fails due to
insufficient permissions - regardless of the sandbox, or even when the
test suite is run manually with no involvement of a Gentoo package
manager.
We could in principle modify the test in question to be compatible with
restricted-ptrace mode, however it would still fail on systems with
Yama in admin-attach and no-attach mode. Between that and requiring the
user to reconfigure Yama prior to running this test being IMHO a Bad
Idea, just don't bother with this test at all.
[1] https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html
Closes: https://bugs.gentoo.org/729046
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|
|
Debian now uses two-part version numbers for their changes in this
package, which is not allowed with _p in Gentoo - so just extend the
standard version number by two more parts, it's unlikely this will
conflict with the upstream scheme even if they even do release a new
version.
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|