[opensuse-factory] openSUSE:Factory - Build fail notification
Dear Package maintainers and hackers. Below package(s) in openSUSE:Factory have been failing to build for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted. - perl-Math-BigInt-GMP - pocl - python-python-prctl - python-sphinx-autodoc-typehints Unless somebody is stepping up and submitting fixes, the listed package(s) are going to be removed from openSUSE:Factory. Kind regards, DimStar / Dominique Leuenberger <dimstar@opensuse.org>
24. 10. 2020 v 0:02, DimStar / Dominique Leuenberger <dimstar@opensuse.org>:
Dear Package maintainers and hackers.
Below package(s) in openSUSE:Factory have been failing to build for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted.
- perl-Math-BigInt-GMP - pocl
Fix for poct build -> https://build.opensuse.org/request/show/843703 Kind regards, Ondřej Súkup-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 23 Oct 2020 22:02:05 +0000 DimStar / Dominique Leuenberger <dimstar@opensuse.org> wrote:
Dear Package maintainers and hackers.
Below package(s) in openSUSE:Factory have been failing to build for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted.
- perl-Math-BigInt-GMP - pocl - python-python-prctl - python-sphinx-autodoc-typehints
There is something wrong with the build process in Factory for perl-Math-BigInt-GMP: https://build.opensuse.org/package/live_build_log/openSUSE:Factory/perl-Math... ... [ 13s] [105/136] cumulate perl-Math-BigInt-1.999818-1.4 [ 16s] Warning: prerequisite Math::BigInt 1.999817 not found. We have 1.999816. Everywhere else it works.
Am 24.10.20 um 07:20 schrieb Carsten Ziepke:
... [ 13s] [105/136] cumulate perl-Math-BigInt-1.999818-1.4 [ 16s] Warning: prerequisite Math::BigInt 1.999817 not found. We have 1.999816.
perl-Math-BigInt is built against perl 5.30.1 and ignored in 5.30.3 - can perl-Math-BigInt please be rebuilt to fix BigInt-GMP? Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 2020-10-24 at 09:05 +0200, Stephan Kulow wrote:
Am 24.10.20 um 07:20 schrieb Carsten Ziepke:
... [ 13s] [105/136] cumulate perl-Math-BigInt-1.999818-1.4 [ 16s] Warning: prerequisite Math::BigInt 1.999817 not found. We have 1.999816.
perl-Math-BigInt is built against perl 5.30.1 and ignored in 5.30.3 - can perl-Math-BigInt please be rebuilt to fix BigInt-GMP?
Done, but that implies that perl is lying: the package had before:
zypper info --requires perl-Math-BigInt perl(:MODULE_COMPAT_5.30.1)
And perl 5.30.3 is providing this - but apparently without meaning it. Cheers, Dominique
Am 24.10.20 um 13:28 schrieb Dominique Leuenberger / DimStar:
On Sat, 2020-10-24 at 09:05 +0200, Stephan Kulow wrote:
Am 24.10.20 um 07:20 schrieb Carsten Ziepke:
... [ 13s] [105/136] cumulate perl-Math-BigInt-1.999818-1.4 [ 16s] Warning: prerequisite Math::BigInt 1.999817 not found. We have 1.999816.
perl-Math-BigInt is built against perl 5.30.1 and ignored in 5.30.3 - can perl-Math-BigInt please be rebuilt to fix BigInt-GMP?
Done, but that implies that perl is lying:
the package had before:
zypper info --requires perl-Math-BigInt perl(:MODULE_COMPAT_5.30.1)
And perl 5.30.3 is providing this - but apparently without meaning it.
Jein - it looks there *if* it doesn't find anything in 5.30.3. Problem is that the version in 5.30.3 is outdated. Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 2020-10-24 at 15:49 +0200, Stephan Kulow wrote:
Am 24.10.20 um 13:28 schrieb Dominique Leuenberger / DimStar:
On Sat, 2020-10-24 at 09:05 +0200, Stephan Kulow wrote:
Am 24.10.20 um 07:20 schrieb Carsten Ziepke:
... [ 13s] [105/136] cumulate perl-Math-BigInt-1.999818-1.4 [ 16s] Warning: prerequisite Math::BigInt 1.999817 not found. We have 1.999816.
perl-Math-BigInt is built against perl 5.30.1 and ignored in 5.30.3 - can perl-Math-BigInt please be rebuilt to fix BigInt-GMP?
Done, but that implies that perl is lying:
the package had before:
zypper info --requires perl-Math-BigInt perl(:MODULE_COMPAT_5.30.1)
And perl 5.30.3 is providing this - but apparently without meaning it.
Jein - it looks there *if* it doesn't find anything in 5.30.3. Problem is that the version in 5.30.3 is outdated.
I see; thanks for the explanation; seems to be an evil corner case which our bot does not detect. Cheers, Dominique
Am Samstag, 24. Oktober 2020, 00:02:05 CEST schrieb DimStar / Dominique Leuenberger:
Dear Package maintainers and hackers.
Below package(s) in openSUSE:Factory have been failing to build for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted.
- python-python-prctl
Okay, here's my current state diving into this issue: The PR_{GET,SET}_NO_NEW_PRIVS capability test fails for TW, because limiting the caps in order to disallow ping fails for some reason. Could it be, that TW handles capabilities differently? Here's a strace excerpt: 27605 prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0) = 0 27605 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID| SIGCHLD, child_tidptr=0x7fa5ed092a10) = 27606 27606 set_robust_list(0x7fa5ed092a20, 24) = 0 27605 write(1</dev/pts/52>, "pid: 27606\n", 11) = 11 27605 wait4(27606, <unfinished ...> 27606 write(1</dev/pts/52>, "pid: 0\n", 7) = 7 27606 write(1</dev/pts/52>, "fork..\n", 7) = 7 27606 prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) = 0 27606 prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0) = 1 Obviously, PR_SET_NO_NEW_PRIVS succeeds. 27606 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID| SIGCHLD, child_tidptr=0x7fa5ed092a10) = 27607 [...] but ping succeeds, even if it should not: 27607 prctl(PR_CAPBSET_READ, CAP_MAC_OVERRIDE) = 1 27607 prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Das Argument ist ungültig) 27607 prctl(PR_CAPBSET_READ, CAP_CHECKPOINT_RESTORE) = 1 27607 prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Das Argument ist ungültig) 27607 prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Das Argument ist ungültig) 27607 prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Das Argument ist ungültig) 27607 brk(NULL) = 0x55b43b2b0000 27607 brk(0x55b43b2d1000) = 0x55b43b2d1000 27607 capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0 27607 capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0, inheritable=0}) = 0 27607 capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0 27607 capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0, inheritable=0}) = 0 27607 prctl(PR_SET_KEEPCAPS, 1) = 0 27607 getuid() = 1000 27607 setuid(1000) = 0 27607 prctl(PR_SET_KEEPCAPS, 0) = 0 27607 getuid() = 1000 [...] 27607 write(1</dev/pts/52>, "64 Bytes von localhost (::1): icmp_seq=1 ttl=64 Zeit=0.042 ms\n", 62) = 62 Ideas? Just disable the test for TW might be feasible, but I would like to understand, what's going wrong here.. If somebody want to play with this, here's some debug code applied: home:frispete:python/python-python-prctl Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Samstag, 24. Oktober 2020, 19:41:20 CET schrieb Hans-Peter Jansen:
Okay, here's my current state diving into this issue:
The PR_{GET,SET}_NO_NEW_PRIVS capability test fails for TW, because limiting the caps in order to disallow ping fails for some reason. Could it be, that TW handles capabilities differently?
Here's a strace excerpt:
27605 prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0) = 0 27605 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID| SIGCHLD, child_tidptr=0x7fa5ed092a10) = 27606 27606 set_robust_list(0x7fa5ed092a20, 24) = 0 27605 write(1</dev/pts/52>, "pid: 27606\n", 11) = 11 27605 wait4(27606, <unfinished ...> 27606 write(1</dev/pts/52>, "pid: 0\n", 7) = 7 27606 write(1</dev/pts/52>, "fork..\n", 7) = 7 27606 prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) = 0 27606 prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0) = 1
Obviously, PR_SET_NO_NEW_PRIVS succeeds.
27606 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID| SIGCHLD, child_tidptr=0x7fa5ed092a10) = 27607
[...]
but ping succeeds, even if it should not:
27607 prctl(PR_CAPBSET_READ, CAP_MAC_OVERRIDE) = 1 27607 prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Das Argument ist ungültig) 27607 prctl(PR_CAPBSET_READ, CAP_CHECKPOINT_RESTORE) = 1 27607 prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Das Argument ist ungültig) 27607 prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Das Argument ist ungültig) 27607 prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Das Argument ist ungültig) 27607 brk(NULL) = 0x55b43b2b0000 27607 brk(0x55b43b2d1000) = 0x55b43b2d1000 27607 capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0 27607 capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0, inheritable=0}) = 0 27607 capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0 27607 capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0, inheritable=0}) = 0 27607 prctl(PR_SET_KEEPCAPS, 1) = 0 27607 getuid() = 1000 27607 setuid(1000) = 0 27607 prctl(PR_SET_KEEPCAPS, 0) = 0 27607 getuid() = 1000
[...]
27607 write(1</dev/pts/52>, "64 Bytes von localhost (::1): icmp_seq=1 ttl=64 Zeit=0.042 ms\n", 62) = 62
Ideas? Just disable the test for TW might be feasible, but I would like to understand, what's going wrong here..
If somebody want to play with this, here's some debug code applied:
home:frispete:python/python-python-prctl
Anybody with capability know how around here? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/10/2020 21.10, Hans-Peter Jansen wrote:
Am Samstag, 24. Oktober 2020, 19:41:20 CET schrieb Hans-Peter Jansen:
Okay, here's my current state diving into this issue:
The PR_{GET,SET}_NO_NEW_PRIVS capability test fails for TW, because limiting the caps in order to disallow ping fails for some reason. Could it be, that TW handles capabilities differently?
Here's a strace excerpt:
27605 prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0) = 0 27605 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID| SIGCHLD, child_tidptr=0x7fa5ed092a10) = 27606 27606 set_robust_list(0x7fa5ed092a20, 24) = 0 27605 write(1</dev/pts/52>, "pid: 27606\n", 11) = 11 27605 wait4(27606, <unfinished ...> 27606 write(1</dev/pts/52>, "pid: 0\n", 7) = 7 27606 write(1</dev/pts/52>, "fork..\n", 7) = 7 27606 prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) = 0 27606 prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0) = 1
Obviously, PR_SET_NO_NEW_PRIVS succeeds.
27606 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID| SIGCHLD, child_tidptr=0x7fa5ed092a10) = 27607
[...]
but ping succeeds, even if it should not:
27607 prctl(PR_CAPBSET_READ, CAP_MAC_OVERRIDE) = 1 27607 prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Das Argument ist ungültig) 27607 prctl(PR_CAPBSET_READ, CAP_CHECKPOINT_RESTORE) = 1 27607 prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Das Argument ist ungültig) 27607 prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Das Argument ist ungültig) 27607 prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Das Argument ist ungültig) 27607 brk(NULL) = 0x55b43b2b0000 27607 brk(0x55b43b2d1000) = 0x55b43b2d1000 27607 capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0 27607 capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0, inheritable=0}) = 0 27607 capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0 27607 capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0, inheritable=0}) = 0 27607 prctl(PR_SET_KEEPCAPS, 1) = 0 27607 getuid() = 1000 27607 setuid(1000) = 0 27607 prctl(PR_SET_KEEPCAPS, 0) = 0 27607 getuid() = 1000
[...]
27607 write(1</dev/pts/52>, "64 Bytes von localhost (::1): icmp_seq=1 ttl=64 Zeit=0.042 ms\n", 62) = 62
ping probably works, because filesystem flags tell the kernel to give it caps when the binary gets executed: grep -2 bin/ping /etc/permissions.easy /usr/bin/ping root:root 0755 +capabilities cap_net_raw=ep # attr -l /usr/bin/ping Attribute "capability" has a 20 byte value for /usr/bin/ping in our build env, these permissions were not always consistently applied. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 2020-10-24 at 19:41 +0200, Hans-Peter Jansen wrote:
The PR_{GET,SET}_NO_NEW_PRIVS capability test fails for TW, because limiting the caps in order to disallow ping fails for some reason. Could it be, that TW handles capabilities differently?
Ping was recently changed so that it doesn't require capabilities anymore (boo#1174504). Best, Malte -- Malte Kraus <malte.kraus@suse.com> Security Engineer PGP Key: 8AFC 3C58 6880 2DDD 4792 C3C2 FDBD 2984 D4C3 C2F0 SUSE Software Solutions Germany GmbH / Maxfeldstr. 5 / 90409 Nürnberg / Germany / (HRB 36809, AG Nürnberg) / Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Dienstag, 27. Oktober 2020, 10:00:04 CET schrieb Malte Kraus:
On Sat, 2020-10-24 at 19:41 +0200, Hans-Peter Jansen wrote:
The PR_{GET,SET}_NO_NEW_PRIVS capability test fails for TW, because limiting the caps in order to disallow ping fails for some reason. Could it be, that TW handles capabilities differently?
Ping was recently changed so that it doesn't require capabilities anymore (boo#1174504).
Duh, obviously, I'm dancing on too many parties. Sorry. https://build.opensuse.org/request/show/844242 Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Bernhard M. Wiedemann -
Carsten Ziepke -
DimStar / Dominique Leuenberger -
Dominique Leuenberger / DimStar
-
Hans-Peter Jansen -
Malte Kraus -
Ondřej Súkup -
Stephan Kulow