Thanks for looking into this!
We do have access to some porterboxes within Canonical, but they're not
reachable from outside. I don't have time to look into this right now,
but I think you're right about a possible kernel regression, so I'll tag
those folks in.
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2123824
Title:
mksh: autopkgtest regression on questing/arm64
Status in linux package in Ubuntu:
New
Status in mksh package in Ubuntu:
New
Bug description:
The autopkgtests for mksh have started regressing recently on arm64,
with multiple errors in the testsuite.
Full logs:
https://autopkgtest.ubuntu.com/results/autopkgtest-questing/questing/arm64/m/mksh/20250915_083458_098bd@/log.gz
First failure:
356s N: FAIL check.t:read-ext-1
356s N: Description:
356s N: Check read with number of bytes specified, and -A
356s N: unexpected exit status 65280 (exit-code 255), expected 0
356s N: unexpected stdout - got too little output
356s N: wanted:
356s N: x1a=<foo>
356s N: x1b=<foo
356s N: bar>
356s N: x2a=1<x>
356s N: x2b=1<u>
356s N: x2c=0<x>
356s N: x3a=<foo bar|baz|>
356s N: got nothing
356s N: unexpected stderr - got too much output
356s N: wanted nothing
356s N: got:
356s N: internal error: can't allocate 9 data bytes: Out of
memory
IMHO the suspects for this are gcc/binutils or the kernel. glibc
looked like a likely culprit as it was the trigger on the first
instance of failure, but it appears to be a coincidence, as a
migration-reference/0 also showed the failure.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2123824/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp