Libxml2 issue on 4.0/Ubuntu build
thedayofcondor opened this issue Β· comments
Building the docker image 4.0/Ubuntu https://github.com/jrottenberg/ffmpeg/tree/master/docker-images/4.0/ubuntu seems broken after beb23fc
6609 /bin/sh: 1: ./configure: not found
6610 The command '/bin/sh -c DIR=/tmp/libxml2 && mkdir -p ${DIR} && cd ${DIR} && curl -sLO https://gitlab.gnome.org/GNOME/libxml2/-/archive/v${LIBXML2_VERSION}/libxml2-v${LIBXML2_VERSION}.tar.gz && echo ${LIBXML2_SHA256SUM} | sha256sum --check && tar -xz --strip-components=1 -f libxml2-v${LIBXML2_VERSION}.tar.gz && PKG_CONFIG_PATH="${PREFIX}/lib/pkgconfig" ./configure --prefix="${PREFIX}" --with-ftp=no --with-http=no --with-python=no && make && make install && rm -rf ${DIR}' returned a non-zero code: 127
6613 ERROR: Job failed: exit status 1
Ah, that's what I get for not actually testing the suggested version bump after confirming that the older libxml2 tarball was working fine... Definitely my mistake there
Thanks for the quick fix - can't wait for this to be merged to test!
All the builds seem to be passing ok, I went through a bunch of the build logs and they aren't erroring silently anywhere I can see, so if it's all merged up then I imagine it shouldn't be to long before the images are available.
I'm particularly keen to get the base images all updated and happy again because there are a few PR's relating to bumping up the versions on a few libs but they are stuck due to the old cmake version installed in the centos:7 container by default, the PR to just bump to centos:8 I didn't realise how the build system worked and hadn't updated all the template files and the actual Dockerfiles, then I figured I'd fix up one issue open about including libbluray while I was making changes (now armed with "how to actually get a change to build properly" knowledge) but that seems to have stumbled a couple of times on libxml2 being available/not available/outdated and now having the build process for it change without me noticing and breaking the builds for the containers.... but once centos:8 is in those library version bumps can be merged and the ffmpeg version in the container will be up to date with the version I'm using whenever I need ffmpeg installed on a box that doesn't have all the libs packaged up
But the build kind of has to work for that to happen
I tried the commit against my pipeline and I am happy to confirm it now compile without issues
ouch , I should have checked as well, not sure how come the piplien passed on azure devops for that commit...
It does looks like the azure pipelines, when they fail, they end up passing based on previous successful builds?
I'm not familiar with azure pipelines at all, havinf never used them, so I'm not entirely sure