Failed to Build/Upload php

[github-actions[bot]]

Build and Upload workflow failed to run. Please take a look to ensure the version in the workflow is built and uploaded successfully. (cc @paketo-buildpacks/dependencies-maintainers)

[github-actions[bot]]

Another failure occurred: https://github.com/paketo-buildpacks/dep-server/actions/runs/2797033733

[sophiewigmore]

versions failed to build: 8.0.22 8.1.9

[github-actions[bot]]

Another failure occurred: https://github.com/paketo-buildpacks/dep-server/actions/runs/2795516119

[sophiewigmore]

Build failures here are due to the new bionic stacks not containing multiverse in the sources.list file: https://github.com/paketo-buildpacks/bionic-full-stack/blob/ff414b4d3b9a92b94d2d8883cd23980b0f0bb17f/stack/stack.toml#L16-L18. Because of this, some of the packages needed for PHP configuration and compilation are not available for installation, leading to the errors seen in the GHA logs.

• Option 1 is to add multiverse back into the sources.list file in the Bionic stacks. (I think this is the best option, since this is what the old stacks had, and we were aiming to have identical stacks)
• Option 2 is to modify the Dockerfile for compilation to include multiverse as a package source. @robdimsdale what do you think? Any preferences?

[robdimsdale]

Ah, I didn't realize some of the Php extensions have dependencies on multiverse. Firstly, I assume there's no way of enabling users to build their own Php extensions - we have to compile and bundle them all into the buildpack?

Assuming that is true, and assuming we have to support the current list of Php extensions - i.e. we can't drop support for any of them - then I don't think we have much of an option but to add multiverse back into the sources.list.

Can we make a list of the packages required by Php extensions from multiverse and ensure we're happy with each one? For example, it looks like the build is currently failing due to missing libdv-dev which is the header files for the "Quasar DV codec` (i.e. a video codec). It's fairly surprising to see that we have to ship a Php extension that requires this, but I'm willing to accept that someone wants to build a Php app that does video processing.

My general concern with multiverse is that we might be shipping libraries that have incompatible licensing or copyright restrictions.

[sophiewigmore]

@robdimsdale I'm pretty sure that is something our team had looked into in the past and it was a bit of a headache. For now, I'd say yes we should continue dealing with the extensions as we have them now with the PHP dependency.

I'm also not completely comfortable with changing any of the extensions we include, since the list comes from the CF compilation code base that is shared with other projects. I can definitely go through and make that list for our own understanding though.

Lastly, do you know if it would be possible to just make the change in the GHA Dockerfile rather than making the change to the stacks then?

[robdimsdale]

Sorry, I wasn't super clear about where to make the change. I think it should be in the stack.toml because I think the packages should be on the stack. Otherwise I worry that they would fail due to being compiled dynamically against a library in the GHA Docker image that isn't present during the build/run phase.

If we can't change the list of extensions, and we've already satisfied ourselves that the extensions (and hence dependent libraries) that we ship are 👍 then I don't think there's much value in doing that exercise again.

[sophiewigmore]

@ryanmoran @robdimsdale with a preliminary checking, it looks like the package snmp-mibs-downloader is the only package installed from multiverse from this line of code. I'll go back through tomorrow and double check, but it was the only package that showed up with an error while installing.

However, it seems like the presence of that package is needed for a number of other packages. I ran compilation on action Dockerfile twice, once as-is (no multiverse enabled), and once with the multiverse enabled. I docker commit the containers so I could diff the images, and it looks like a ton of apt packages from universe only showed up on the image with multiverse enabled.

Logs when multiverse enabled:

The following NEW packages will be installed:
  aspell aspell-en dictionaries-common emacsen-common enchant firebird-dev
  firebird3.0-common firebird3.0-common-doc geoip-bin hunspell-en-us
  libaspell-dev libaspell15 libassuan-dev libbsd-dev libc-client2007e
  libc-client2007e-dev libedit-dev libenchant-dev libenchant1c2a libfbclient2
  libgdbm-dev libgeoip-dev libgpgme-dev libgpgme11 libhashkit-dev libhashkit2
  libhunspell-1.6-0 libib-util libmaxminddb-dev libmaxminddb0 libmcrypt-dev
  libmcrypt4 libmemcached-dev libmemcached11 libmemcachedutil2 libonig-dev
  libpam0g-dev libpci-dev libpci3 libpspell-dev librecode-dev librecode0
  libsensors4-dev libsnmp-base libsnmp-dev libsnmp30 libssh2-1 libssh2-1-dev
  libtidy-dev libtidy5 libtommath1 libudev-dev libwebp-dev libwebpdemux2
  libzip-dev libzip4 libzookeeper-mt-dev libzookeeper-mt2 mlock smistrip
  snmp-mibs-downloader

[sophiewigmore]

The solution @robdimsdale and I have decided on as Stack maintainers is to re-add multiverse as a package source in the stacks. The stacks will never be shipped with packages from multiverse, but it will be allowed as a source for things like compilation to install needed packages.

This will be resolved by https://github.com/paketo-buildpacks/bionic-full-stack/pull/25 once merged and released.

[sophiewigmore]

Both workflows are now passing: https://github.com/paketo-buildpacks/dep-server/runs/7772660837?check_suite_focus=true https://github.com/paketo-buildpacks/dep-server/runs/7772665060?check_suite_focus=true Affected versions 8.0.22 and 8.1.9 are present in the dep-server as well.