Focal has the same version of php-parser, and we're seeing the same test failures there.
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal/focal/armhf/p/php- parser/20200929_080001_a32e2@/log.gz /tmp/autopkgtest.eZ6NuZ/build.Ar8/src/test/PhpParser/Lexer/EmulativeTest.php:110 ** Changed in: php-parser (Ubuntu Focal) Importance: Undecided => High ** Changed in: php-parser (Ubuntu Focal) Status: New => Triaged ** Changed in: php-parser (Ubuntu Focal) Assignee: (unassigned) => Bryce Harrington (bryce) ** Description changed: + [Impact] + + Other php SRUs end up blocked from migration due to a test case in php- + parser that fails due to an integer format mismatch. + + + [Test Case] + 1. Create lxc container for ubuntu-focal + 2. Install php-parser + 3. Run autopkgtest php-parser -- null + + The testsuite should pass but it does not, and fails with EmulativeTest + issues starting with (and similar to) this one: + + 1) PhpParser\Lexer\EmulativeTest::testErrorAfterEmulation with data set #0 ('??=', array(array(281, '??='))) + Failed asserting that actual size 0 matches expected size 1. + + /tmp/autopkgtest.eZ6NuZ/build.Ar8/src/test/PhpParser/Lexer/EmulativeTest.php:110 + + + [Regression Potential] + + Since this is a testsuite fix for integer parsing on armhf, the two + things to watch for would be a) issues relating to the testsuite, or b) + issues particular to armhf (especially traceable to integer parsing + behavior). However, in the first case, the testsuite's behavior would + crop up only during building / migrating in the archive and would not + produce user-visible effects. In the second case, integer parsing + issues already exist in released code so would not be a true regression, + the test case only exposes them - by preventing other php packages from + migrating. + + + [Discussion] + + php-parser's autopkgtest has been failing in focal on armhf for some + time: + + http://autopkgtest.ubuntu.com/packages/p/php-parser/focal/armhf + + The test failure is due to an integer format mismatch. We spotted this + issue on groovy and flagged it for upstream: + + https://github.com/nikic/PHP-Parser/issues/662 + + There doesn't appear to be a fix identified yet. We addressed it in + groovy by disabling the faulty tests (the one listed in this bug, and + the one in LP: #1895878), and that may be a low-risk way to address it + for focal, too. + + https://launchpad.net/ubuntu/+source/php-parser/4.4.0-1ubuntu2 + + php-parser: https://launchpad.net/ubuntu/+source/php-parser/4.2.2-2 php7.4: https://launchpad.net/ubuntu/+source/php7.4/7.4.3-4ubuntu2 Originally failing Log: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-groovy/groovy/armhf/p/php- parser/20200502_014803_a1f47@/log.gz - EmulativeTest::testErrorAfterEmulation with various data sets - EmulativeTest::testError with various data sets - LexerTest::testError with various data sets php7.4 is blocked from migration of three CVEs due to test failures with php-parser. Php-parser has a newer 4.4.0-1 stuck in proposed, but triggering the two together did not resolve the issue: Newly failing log: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-groovy/groovy/armhf/p/php- parser/20200501_165040_5a5c8@/log.gz - CodeParsingTest::testParse: Different integer syntaxes - Lexer\EmulativeTest::testLexNewFeatures: '0xCAFE_F00D' -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1878102 Title: php-parser autopkgtests fail with php7.4 7.4.3-4ubuntu2 on armhf To manage notifications about this bug go to: https://bugs.launchpad.net/php/+bug/1878102/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
