Please stabilize.
x86 done
Test failures on sparc got worse, see bug 636252. Is this considered a blocker?
arm64 done
amd64, arm, hppa, ppc64, ppc: ping, please test so we know if the sparc failure is unique to that (which is possible as a kernel issue)
tested on ppc64 and ppc64le fine. on ppc32 it fails right away with /dev/watch_queue(size): Inappropriate ioctl for device but that's probably because we run 32bit chroot on 64bit kernel. I'll try to run it in a VM.
hppa done
Created attachment 768645 [details] build.log (ppc, 1.6.3) (In reply to Georgy Yakovlev from comment #5) > on ppc32 it fails right away with > /dev/watch_queue(size): Inappropriate ioctl for device > > but that's probably because we run 32bit chroot on 64bit kernel. > I'll try to run it in a VM. Ran the test on my G4 and the testsuite failed too though not the way as on sparc. Apart from that I don't get "/dev/watch_queue(size): Inappropriate ioctl for device" on the G4.
ppc done
Both 1.6.1 and 1.6.3 are failing pretty nasty on sparc for me. My log for 1.6.1 is identical to Rolf's but 1.6.3 is different, not sure why. But it implodes just as hard. IMO 1.6.1 should be de-stabilized on sparc. >>> Test phase: sys-apps/keyutils-1.6.3 * .sparc64: running multilib-minimal_abi_src_test make -j56 test /bin/sh: line 1: rpmspec: command not found make -C tests run make[1]: Entering directory '/var/tmp/portage/sys-apps/keyutils-1.6.3/work/keyutils-1.6.3-.sparc64/tests' bash runtest.sh features/limits features/builtin_trusted bugzillas/bz1033467 bugzillas/bz1031154 bugzillas/bz1071346 keyctl/listing/bad-args keyctl/listing/noargs keyctl/listing/valid keyctl/ invalidate/bad-args keyctl/invalidate/noargs keyctl/invalidate/valid keyctl/revoke/bad-args keyctl/revoke/noargs keyctl/revoke/valid keyctl/clear/bad-args keyctl/clear/noargs keyctl/clear/vali d keyctl/watch/bad-args keyctl/watch/noargs keyctl/timeout/bad-args keyctl/timeout/noargs keyctl/timeout/valid keyctl/id/bad-args keyctl/id/noargs keyctl/id/valid keyctl/reading/bad-args keyct l/reading/noargs keyctl/reading/valid keyctl/newring/bad-args keyctl/newring/noargs keyctl/newring/valid keyctl/dh_compute/bad-args keyctl/dh_compute/noargs keyctl/dh_compute/valid keyctl/upda te/bad-args keyctl/update/userupdate keyctl/update/noargs keyctl/describing/bad-args keyctl/describing/noargs keyctl/describing/valid keyctl/instantiating/bad-args keyctl/instantiating/noargs keyctl/noargs keyctl/add/useradd keyctl/add/bad-args keyctl/add/noargs keyctl/supports/bad-args keyctl/supports/valid keyctl/session/bad-args keyctl/session/valid2 keyctl/session/valid keyctl/ padd/useradd keyctl/padd/bad-args keyctl/padd/noargs keyctl/search/bad-args keyctl/search/noargs keyctl/search/valid keyctl/pupdate/bad-args keyctl/pupdate/userupdate keyctl/pupdate/noargs key ctl/requesting/noargs keyctl/link/bad-args keyctl/link/noargs keyctl/link/recursion keyctl/link/valid keyctl/move/bad-args keyctl/move/noargs keyctl/move/recursion keyctl/move/valid keyctl/unl ink/bad-args keyctl/unlink/noargs keyctl/unlink/all keyctl/unlink/valid keyctl/permitting/bad-args keyctl/permitting/noargs keyctl/permitting/valid keyctl/show/noargs keyctl/show/valid keyctl/ restrict/bad-args keyctl/restrict/valid #### Some tests require root privileges. #### It is recommended that this be run as root. ### RUNNING TEST features/limits Running with session keyring RHTS/keyctl/63 Joined session keyring: 481132242 keyutils version: keyctl from keyutils-1.6.3 (Built 2022-04-28) === /var/tmp/portage/sys-apps/keyutils-1.6.3/work/keyutils-1.6.3-.sparc64/tests/features/limits/test.out === +++ TEST TYPE AND DESC LIMITS TEST SIZE 0._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ TEST SIZE 32._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ TEST SIZE 64._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ TEST SIZE 96._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ TEST SIZE 128._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ TEST SIZE 160._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ TEST SIZE 192._._._._._._ 197 desc wrong error: Disk quota exceeded ._ 198 desc wrong error: Disk quota exceeded ._ 199 desc wrong error: Disk quota exceeded ._ 200 desc wrong error: Disk quota exceeded ._ 201 desc wrong error: Disk quota exceeded ._ 202 desc wrong error: Disk quota exceeded ._ 203 desc wrong error: Disk quota exceeded ._ 204 desc wrong error: Disk quota exceeded ._ 205 desc wrong error: Disk quota exceeded ._ 206 desc wrong error: Disk quota exceeded ._ 207 desc wrong error: Disk quota exceeded ._ 208 desc wrong error: Disk quota exceeded ._ 209 desc wrong error: Disk quota exceeded ._ 210 desc wrong error: Disk quota exceeded ._ 211 desc wrong error: Disk quota exceeded ._ 212 desc wrong error: Disk quota exceeded ._ 213 desc wrong error: Disk quota exceeded ._ 214 desc wrong error: Disk quota exceeded ._ 215 desc wrong error: Disk quota exceeded ._ 216 desc wrong error: Disk quota exceeded ._ 217 desc wrong error: Disk quota exceeded Aborting with too many failures FAILED
amd64 stable
sparc stable
(In reply to Agostino Sarubbo from comment #11) > sparc stable Were you able to get this to pass tests?
(In reply to Agostino Sarubbo from comment #11) > sparc stable Did it really pass tests? It looks like we should try drop it on sparc.
(In reply to Sam James from comment #13) > Did it really pass tests? It looks like we should try drop it on sparc. When there is an open stablereq and there is an open test-failure and the stablereq is not blocked by any bug, I'm running it without test because I'm assuming that the maintainer know about the failure but he doesn't want to block the stablereq. I just changed to this workflow yesterday because I was only hitting known test-failure on open stablereqs. This is a particular case so if you want I can revert. Please block the stablereq for future cases.
(In reply to Agostino Sarubbo from comment #14) > (In reply to Sam James from comment #13) > > Did it really pass tests? It looks like we should try drop it on sparc. > > When there is an open stablereq and there is an open test-failure and the > stablereq is not blocked by any bug, I'm running it without test because I'm > assuming that the maintainer know about the failure but he doesn't want to > block the stablereq. > > I just changed to this workflow yesterday because I was only hitting known > test-failure on open stablereqs. > > This is a particular case so if you want I can revert. > > Please block the stablereq for future cases. Please do. I don't have a problem with the new workflow necessarily but you didn't announce it - so no opportunity to go through and check open bugs.
I'm not actually sure how this is supposed to work though. What if there's a failure for an older version reported and the newer version fails in the same way but we didn't expect it to?
(In reply to Sam James from comment #15) > Please do. Reverted. (In reply to Sam James from comment #16) > I'm not actually sure how this is supposed to work though. What if there's a > failure for an older version reported and the newer version fails in the > same way but we didn't expect it to? If we didn't expect it to..I suppose that it is fixed and there are no more open bugs. If you think that it does not work, I can change hte workflow, but I just realized that I was compiling always the same packages and blocked by the same test-failures bugs
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad328cf93cda113885b8b21135e29c5909a71350 commit ad328cf93cda113885b8b21135e29c5909a71350 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-05-10 17:01:57 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-05-11 00:49:06 +0000 sys-apps/keyutils: drop to ~ppc Too many test failures. Unclear if it truly works at runtime. Bug: https://bugs.gentoo.org/789837 Bug: https://bugs.gentoo.org/636252 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/keyutils/keyutils-1.6.1.ebuild | 2 +- sys-apps/keyutils/keyutils-1.6.3.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=59a3d3369a55f48c4ec3ceba101c1aab499d447f commit 59a3d3369a55f48c4ec3ceba101c1aab499d447f Author: Sam James <sam@gentoo.org> AuthorDate: 2022-05-10 17:01:19 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-05-11 00:49:05 +0000 sys-apps/keyutils: drop to ~sparc Too many test failures. Unclear if it truly works at runtime. Bug: https://bugs.gentoo.org/789837 Bug: https://bugs.gentoo.org/636252 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/keyutils/keyutils-1.6.1.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
(In reply to Agostino Sarubbo from comment #17) > (In reply to Sam James from comment #15) > > Please do. > > Reverted. > > > (In reply to Sam James from comment #16) > > I'm not actually sure how this is supposed to work though. What if there's a > > failure for an older version reported and the newer version fails in the > > same way but we didn't expect it to? > > If we didn't expect it to..I suppose that it is fixed and there are no more > open bugs. > > If you think that it does not work, I can change hte workflow, but I just > realized that I was compiling always the same packages and blocked by the > same test-failures bugs There isn't a way to tell a difference between "failed for an older version and still fails" and "fails for an older version but should be fine now" from your method. I don't think this approach works. I think we need to handle the problem somehow though, agreed.
arm done all arches done