jrottenberg / ffmpeg

Docker build for FFmpeg on Ubuntu / Alpine / Centos / Scratch / nvidia / vaapi
https://hub.docker.com/r/jrottenberg/ffmpeg/
Apache License 2.0
1.45k stars 461 forks source link

Libxml2 issue on 4.0/Ubuntu build #213

Open thedayofcondor opened 4 years ago

thedayofcondor commented 4 years ago

Building the docker image 4.0/Ubuntu https://github.com/jrottenberg/ffmpeg/tree/master/docker-images/4.0/ubuntu seems broken after https://github.com/jrottenberg/ffmpeg/commit/beb23fca04b8972dbbf744e019e4f3f8a33c49a4

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
hvindin commented 4 years ago

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 😖 #214 should fix it, I have actually run a build of a couple of containers to make sure it does build properly before just throwing the changes on up here this time... probably should have tested it after the version bump went up before last time as well....

thedayofcondor commented 4 years ago

Thanks for the quick fix - can't wait for this to be merged to test!

hvindin commented 4 years ago

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 😂 until then I'm stuck building my own images whenever I need them, which is a bit of a pain given how long it takes to build ffmpeg vs pulling a container...

thedayofcondor commented 4 years ago

I tried the commit against my pipeline and I am happy to confirm it now compile without issues

jrottenberg commented 4 years ago

ouch , I should have checked as well, not sure how come the piplien passed on azure devops for that commit...

hvindin commented 4 years ago

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 😕