Guess we submitted around same time - yeah I found it was added about an hour ago, with same stack as you.

#798

See here for add of -psr: shivammathur/php-ubuntu@83d1155

Confirmed, tests running within the last hour are mass failing due to a conflict with the Symfony service-contracts extension.

Error: ] Your system is not ready to run the application.                       
                                                                                

Fix the following mandatory requirements:
=========================================

 * The package "symfony/service-contracts" conflicts with the extension "psr".
   You need to disable it in order to run this application.

I think this probably breaking a lot of CI builds right now 😬

Impacting our builds because of the Maatwebsite\Excel package:

PHP Fatal error:  Declaration of Maatwebsite\Excel\Cache\MemoryCache::get(string $key, mixed $default = null): mixed must be compatible with PsrExt\SimpleCache\CacheInterface::get($key, $default = <default>) in /home/runner/work/code/vendor/maatwebsite/excel/src/Cache/MemoryCache.php on line 62
PHP Fatal error:  Declaration of Monolog\Logger::emergency(Stringable|string $message, array $context = []): void must be compatible with PsrExt\Log\LoggerInterface::emergency($message, array $context = []) in /home/runner/work/code/vendor/monolog/monolog/src/Monolog/Logger.php on line 669
Error: Process completed with exit code 255.

I can confirm here from Drupal unit test builds as well.

PHP Fatal error:  Declaration of Drupal\Core\Logger\LoggerChannel::log($level, Stringable|string $message, array $context = []): void must be compatible with PsrExt\Log\LoggerTrait::log($level, $message, array $context = []) in /home/runner/work/xxx/xxx/docroot/core/lib/Drupal/Core/Logger/LoggerChannel.php on line 94

Same here; Laravel 10 with PHP 8.2 failing...

PHP Fatal error:  Declaration of Monolog\Logger::emergency(Stringable|string $message, array $context = []): void must be compatible with PsrExt\Log\LoggerInterface::emergency($message, array $context = []) in /home/runner/work/dir/dir/vendor/monolog/monolog/src/Monolog/Logger.php on line 681

Confirming that adding extensions: :php-psr fixes the problem for now:

    - name: Set PHP version
      uses: shivammathur/setup-php@v2
      with:
        php-version: '8.2'
        extensions: :php-psr <-- this line here
        tools: cs2pr
        coverage: none

Confirming that adding extensions: :php-psr fixes the problem for now:

    - name: Set PHP version
      uses: shivammathur/setup-php@v2
      with:
        php-version: '8.2'
        extensions: :php-psr <-- this line here
        tools: cs2pr
        coverage: none

Confirmed 2x FOSS 💪. I also want to call out how long this project has worked without fail so far -- almost forgot it was even there!

If you have extensions specified, you can append :php-psr to the existing list:

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          extensions: foo, bar, :php-psr

@jhoff you just saved us a bunch of time. Solution worked for me. Thanks for posting!

Confirmed it broke our CI too
Hopefully it will be fixed soon, don't want to do new version of our CI framework just to handle this

Broken on our builds as well, workaround works for emergencies, but a fix that avoids us having to touch every single build file across projects would be ideal.

It happened to me too and it broke all of our builds. I couldn't solve it with the suggestions above.

PHP Fatal error: Declaration of Symfony\Component\Cache\CacheItem::expiresAt(?DateTimeInterface $expiration): PHP_CodeSniffer\Autoload must be compatible with PsrExt\Cache\CacheItemInterface::expiresAt($expiration) in /vendor/symfony/cache/CacheItem.php on line 65

Edit: In fact, the suggestions above corrected the problem.

Broke our CI as well

I don't think it's helpful to anyone who has subscribed to this issue to keep seeing messages from people saying how much this broke their CI.

This got enough visibility already and I'm sure it'll get a fix in a reasonable amount of time after the 0$ we pay for it. Let's give maintainer(s) some time.

My bad, adding :php-psr to my extensions fixed my issue

I don't think it's helpful to anyone who has subscribed to this issue to keep seeing messages from people saying how much this broke their CI.

This got enough visibility already and I'm sure it'll get a fix in a reasonable amount of time after the 0$ we pay for it. Let's give maintainer(s) some time.

Agreed. Initially it's useful to know that an issue is not an isolated event, but it quickly hits a point of diminishing returns. A rollback PR (shivammathur/php-ubuntu#3) is made and is awaiting review from the maintainer, hopefully it is merged soon. Until then, we have a patch that works for now.

It has been reverted.

Apologies for this, The change was a bug fix for #796, but I guess I created a bigger issue.

@shivammathur thanks for reverting and maintaining the package! It's a thankless job but makes a whole lot of peoples lives way easier and much appreciated.

Thank you for resolving this so quickly! Would it be safe to assume that we won't be seeing any re-introduction of the PECL PSR extension anytime? IJust want to know for confidence going forward.

@davereid Yes, no new extensions that are enabled by default will be added to the cache moving forward.