conan-io / conan-docker-tools Goto Github PK

Hi!

@pvicente Reported about the absence of pkg-config in Conan docker images. As we know, this is a very important package to build Linux projects and we don't have an installer package for that.

So, we could include pkg-config when build the docker image.

Regards!

Related to this:
conan-io/conan#2552

Apparently, we could modify the entry point of the images to fix it, but I didn't try it:

ioft/dockerhub#1 (comment)

Maybe we could add a test in this repository to check that the detected arch is x86 instead of x86_64.

WDYT @uilianries ?

See, e.g https://travis-ci.org/inexorgame/entity-system/jobs/480331511#L487

Hi!

When I try to build conangcc49 some errors are printed:

conan@a97b28f9f9fd:~$ sudo apt-get update
Ign http://archive.ubuntu.com vivid InRelease
Ign http://archive.ubuntu.com vivid-updates InRelease
Ign http://archive.ubuntu.com vivid-security InRelease
Ign http://archive.ubuntu.com vivid Release.gpg
Ign http://archive.ubuntu.com vivid-updates Release.gpg
Ign http://archive.ubuntu.com vivid-security Release.gpg
Ign http://archive.ubuntu.com vivid Release
Ign http://archive.ubuntu.com vivid-updates Release
Ign http://archive.ubuntu.com vivid-security Release
Err http://archive.ubuntu.com vivid/main Sources
  404  Not Found [IP: 91.189.88.149 80]
Err http://archive.ubuntu.com vivid/restricted Sources
  404  Not Found [IP: 91.189.88.149 80]
....

The point is, vivid is EOL.
Also, if you check http://archive.ubuntu.com/ubuntu/dists, vivid is not listed.

We could make some workaround, as update apt source list, but IMHO I prefer update the distro version.

Regards!

there is no help2man on CentOS images, as result configure projects fail to build with the following error:

Updating man page m4.1
../build-aux/missing: line 81: help2man: command not found
WARNING: 'help2man' is missing on your system.
         You should only need it if you modified a dependency of a man page.
         You may want to install the GNU Help2man package:
         <http://www.gnu.org/software/help2man/>

unfortunately, there is no easy way to bypass/disable man generation for certain projects, without patching sources.
so I'd prefer to have help2man installed.

clang 7 already in release state. Have you plans to add it to your docker tools?

Hi!

Conan 0.26 is out, but all images were created in version 0.25 (I guess). We can update conan by pip, but would be nice if the image brings the latest version ever, as lasote/conangcc63:latest. Also, would be nice to use a tag per version:

REPOSITORY                      TAG
lasote/conangcc63               latest
lasote/conangcc63               0.26.0
lasote/conangcc63               0.25.0
...

Regards.

Clang 8 is available: https://apt.llvm.org/bionic/dists/llvm-toolchain-bionic-8/

Hi!

Would be nice to provide support for new GCC version:

https://gcc.gnu.org/gcc-8/changes.html

I didn't check yet, but maybe Ubuntu 18.04 supports it. If not, we could build this version on latest Ubuntu image.

Regards.

currently provided docker images are pretty heavyweight. for instance, conanio/gcc8 currently takes 1,03Gb. as docker images are pulled on each build, it introduces additional delay on build job, which scales linearly based on number of travis jobs. I think it makes a priority to keep our docker images as small as possible. I have reviewed conanio/gcc8 image a bit (via ncdu program - sudo ncdu / command) and spot the following:

• valgrind - /usr/lib/valgrind takes 63,7 Mb. I believe valgrind is usually used only for memory profiling, is it really necessary to include it into build images?
• vim - /usr/share/vim takes 31 Mb. also, do we need text editor, especially such a heavy-weight as part of build images?
• cmake - obviously, CMake itself is required, no doubts here. however, /usr/bin/cmake-gui is 24,7 Mb, plus /doc/cmake is 24,2 Mb, plus /usr/share/cmake-3.12/Help is 6,3 Mb. I don't think we need GUI and documentation for CI builds, right?
• python - first off, we install python 3.7, but there is python 3.6 installation (seems like it's dependency of some other package) - not sure if we can avoid having two pythons? second, /opt/pyenv/versions/3.7.1/lib/python3.7/test/__pycache__ takes 32Mb - I doubt we need it at all. there are few other __pycache__ directories around.

from approximate calculation, removing the above may easily save ~200Mb per image (which is 20% of size).

NOTE: docker pull time on travis is currently around 30-40 seconds.

/cc @lasote @uilianries @danimtb @jgsogo @memsharded

What?
Clang 5 would be a nice new target for this project. I can help to develop such image.
My suggestion is: Ubuntu 17.04 (zesty) + Clang-5

Why?
Clang 5 was released a month ago and brought a great support for C++17.

How?
docker pull lasote/conanclang50 should work as done for previous versions of clang.

Regards!

Installing system requirements using the tools.SystemPackageTool fails in the gcc7-centos docker
The error is:

Running: sudo -A yum update -y
/var/tmp/sclH4Ekle: line 8: -A: command not found

travis: https://travis-ci.com/madebr/conan-ps2_toolchain_installer/jobs/180446149#L596

This can be reproduced in interactive mode:

$ docker run -t -i --rm -v /tmp:/home/conan/project:Z conanio/gcc7-centos6 /bin/bash
[conan@e5b2b8cb2901 ~]$ sudo -A ls
/var/tmp/sclvoMvA6: line 8: -A: command not found

we're having some issues with Boost.Python related to python paths in the containers. We get this error:

/usr/include/python2.7/pyconfig.h:7:49: fatal error: i386-linux-gnu/python2.7/pyconfig.h: No such file or directory

do you have any guesses as to the cause?

I do see python-devel getting installed, and i don't see anything else fancy that might make it behave in a non-standard way.

Title pretty much says it all

This looks like a side effect of enforcing Python 3. If a system_requirements() call pulls in Python 2 in the dependency chain, the installation will fail with the output...

Traceback (most recent call last):
  File "/usr/bin/pycompile", line 35, in <module>
    from debpython.version import SUPPORTED, debsorted, vrepr, \
  File "/usr/share/python/debpython/version.py", line 24, in <module>
    from ConfigParser import SafeConfigParser
ModuleNotFoundError: No module named 'ConfigParser'
dpkg: error processing package python2.7-minimal (--configure):

The problem is clear, but I'm not certain about the solution. Maybe pre-installing pycompile and patch it like lsb_release? The idea of doing that makes me wince a bit. Maybe it's sufficient to just install python2.7-minimal beforehand?

Hi!

It would be interesting to add a docker-componer file to give support for building and running any image.

For now, we are only using python scripts, this works, but by docker convention, the best option is to use docker compose.

I can provide the file to create and execute all our images. The main script build.py will be used as before, a trigger to build and test all images.

Regards!

A fair number of Conan users I talk to are using the Docker images internally to push to Artifactory. The Artifactory "build info" is one of the things that conan upload does not support, but which developers fairly regularly want to do. With Jenkins, the Artifactory plugin helps with that. However, for all the other CI's that do not have Artifactory plugins, the JFrog CLI is the next best way to push metadata (slightly preferable to using curl).

On the next refactor in which you touch all the docker images, consider installing JFrog Cli.

Hi, it might be useful to add autoconf-archive to the docker images, in order to handle configure.ac files that utilise AX_ macros from autoconf-archive. I've just struck this while packaging libgpiod. I'm happy to put together a PR if this would be of interest.

We are using xenial (native gcc 5.3, with glibc 2.23) to build gcc 4.9 libraries.
The problem is, the typical gcc 4.9 distro, like debian 9 or ubuntu trusty comes with glibc 2.19 and it fails reusing the binaries: https://github.com/conan-community/conan-zlib/issues/28

We have to downgrade the image to trusty or debian 9 for example.

Hi!

@solvingj found a new bug for us when trying to build Boost Python:

[100%] Linking CXX executable bin/test_package
/usr/bin/cmake -E cmake_link_script CMakeFiles/test_package.dir/link.txt --verbose=1
/usr/bin/c++   -m64 -O3 -DNDEBUG  -rdynamic CMakeFiles/test_package.dir/test_package.cpp.o  -o bin/test_package -Wl,-rpath,/home/conan/.conan/data/boost_python/1.67.0/bincrafters/testing/package/c00e6f478fb50434fa1eb8d86315bb0c75328630/python/lib:/home/conan/.conan/data/boost_regex/1.67.0/bincrafters/testing/package/1330a66c0e4edc9db6029496a124348cf390b470/regex/lib:/home/conan/.conan/data/boost_atomic/1.67.0/bincrafters/testing/package/4a96e7e05a79063e37dd8712b642c8bfbc9c5c2a/atomic/lib:/home/conan/.conan/data/boost_container/1.67.0/bincrafters/testing/package/a8798c1fcc23b0181b4ae3d896cddcc2ef74cfd1/container/lib /home/conan/.conan/data/boost_python/1.67.0/bincrafters/testing/package/c00e6f478fb50434fa1eb8d86315bb0c75328630/python/lib/libboost_python36.so -lpthread -ldl -lrt /home/conan/.conan/data/boost_regex/1.67.0/bincrafters/testing/package/1330a66c0e4edc9db6029496a124348cf390b470/regex/lib/libboost_regex.so /home/conan/.conan/data/boost_atomic/1.67.0/bincrafters/testing/package/4a96e7e05a79063e37dd8712b642c8bfbc9c5c2a/atomic/lib/libboost_atomic.so /home/conan/.conan/data/boost_container/1.67.0/bincrafters/testing/package/a8798c1fcc23b0181b4ae3d896cddcc2ef74cfd1/container/lib/libboost_container.so /opt/pyenv/versions/3.6.7/lib/libpython3.6m.a 
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(dynload_shlib.o): In function `_PyImport_FindSharedFuncptr':
/tmp/python-build.20181108120343.14719/Python-3.6.7/./Python/dynload_shlib.c:82: undefined reference to `dlsym'
/tmp/python-build.20181108120343.14719/Python-3.6.7/./Python/dynload_shlib.c:95: undefined reference to `dlopen'
/tmp/python-build.20181108120343.14719/Python-3.6.7/./Python/dynload_shlib.c:126: undefined reference to `dlsym'
/tmp/python-build.20181108120343.14719/Python-3.6.7/./Python/dynload_shlib.c:95: undefined reference to `dlopen'
/tmp/python-build.20181108120343.14719/Python-3.6.7/./Python/dynload_shlib.c:101: undefined reference to `dlerror'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(thread.o): In function `PyThread_start_new_thread':
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:221: undefined reference to `pthread_create'
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:237: undefined reference to `pthread_detach'
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:211: undefined reference to `pthread_attr_setstacksize'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(thread.o): In function `PyThread_allocate_lock':
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:290: undefined reference to `sem_init'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(thread.o): In function `PyThread_free_lock':
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:315: undefined reference to `sem_destroy'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(thread.o): In function `PyThread_acquire_lock_timed':
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:350: undefined reference to `sem_timedwait'
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:354: undefined reference to `sem_wait'
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:352: undefined reference to `sem_trywait'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(thread.o): In function `PyThread_release_lock':
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:396: undefined reference to `sem_post'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(thread.o): In function `PyThread_create_key':
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:617: undefined reference to `pthread_key_create'
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:622: undefined reference to `pthread_key_delete'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(thread.o): In function `PyThread_set_key_value':
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:645: undefined reference to `pthread_setspecific'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(thread.o): In function `_pythread_pthread_set_stacksize':
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:595: undefined reference to `pthread_attr_setstacksize'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(thread.o): In function `PyThread_delete_key':
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:632: undefined reference to `pthread_key_delete'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(thread.o): In function `PyThread_delete_key_value':
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:638: undefined reference to `pthread_setspecific'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(thread.o): In function `PyThread_get_key_value':
/tmp/python-build.20181108120343.14719/Python-3.6.7/Python/thread_pthread.h:652: undefined reference to `pthread_getspecific'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(posixmodule.o): In function `os_forkpty_impl':
/tmp/python-build.20181108120343.14719/Python-3.6.7/./Modules/posixmodule.c:5916: undefined reference to `forkpty'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(posixmodule.o): In function `os_openpty_impl':
/tmp/python-build.20181108120343.14719/Python-3.6.7/./Modules/posixmodule.c:5822: undefined reference to `openpty'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(signalmodule.o): In function `signal_pthread_sigmask_impl':
/tmp/python-build.20181108120343.14719/Python-3.6.7/./Modules/signalmodule.c:855: undefined reference to `pthread_sigmask'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(signalmodule.o): In function `signal_pthread_kill_impl':
/tmp/python-build.20181108120343.14719/Python-3.6.7/./Modules/signalmodule.c:1119: undefined reference to `pthread_kill'
/opt/pyenv/versions/3.6.7/lib/libpython3.6m.a(faulthandler.o): In function `faulthandler_thread':
/tmp/python-build.20181108120343.14719/Python-3.6.7/./Modules/faulthandler.c:577: undefined reference to `pthread_sigmask'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/test_package] Error 1
make[2]: Leaving directory `/home/conan/project/test_package/build/4ae454930d93b03d2594018f89de984e9a356e5a'
make[1]: *** [CMakeFiles/test_package.dir/all] Error 2
make[1]: Leaving directory `/home/conan/project/test_package/build/4ae454930d93b03d2594018f89de984e9a356e5a'
make: *** [all] Error 2

The complete log is available here:
https://travis-ci.org/bincrafters/conan-boost_python/jobs/453581254#L1879

As you can see, libpython is not finding pthread, dl and rt. To fix it, we need to pass and new flag when building python:

PYTHON_CONFIGURE_OPTS="--enable-shared"

That flag will make pyenv build python as shared library instead of static.

More information here:
openai/go-vncdriver#16 (comment)

When building Qt on travis on gcc6/gcc7/gcc8/clang39/clang40/clang50/clang60 x86 and x64 docker images, we systematically have an early fail, which seems to be linked to the following issue https://bugreports.qt.io/browse/QTBUG-64490
I'm not very familiar with containers internals, but it happens when combining kernel >= 4.12 and docker < 18.04
I identified the following solutions

1. upgrade gcc and clang images to cosmic, which has docker 18.06
2. use use --security-opt seccomp=/path/to/seccomp/profile.json to specify a different profile when running docker, where profile.json whitelists statx

I did not have a chance to test these solutions . Is there a simple way to reproduce a travis build locally ?

As Travis blog mentioned here, sudo: required rule will be update soon.
Conan docker image for gcc-4.8 uses Trusty image and sudo option.

Hi!

My intention is clean all docker images and apply Best practices for writing Dockerfiles.
If we remove the cache after to install all packages, for example, I'll have a smaller image.

Also, would be nice to include a linter, as hadolint.

Regards!

Intro

Recently I pushed several PRs to fix/support conan-community/conan-opencv#12 cross-compilation for Android

I did all test locally and then push it to review, before merge CI must be passed, for now CI covers linux & windows compilation only

Suggestion

I would like to cover cross-compilation for Android too

What I have tried

I have tried to run on https://github.com/dockcross/dockcross/tree/master/android-arm but it fails with /bin/sh: 1: cd: can't cd to project error

Initially I thought that problem that user conan don't eixists in dockcross/android-arm, so I changed CONAN_DOCKER_HOME to /root but it doesn't help, issue remains the same

Full evn list: ANDROID_NDK_HOME=/build/android-ndk-r16b CONAN_CLANG_VERSIONS=6.0 CONAN_DOCKER_IMAGE=dockcross/android-arm CONAN_DOCKER_IMAGE_SKIP_UPDATE=True CONAN_DOCKER_HOME=/root CONAN_ARCHS=armv7hf CONAN_BUILD_TYPES=Debug

I will continue debugging locally

Don't know exactly why. Check latests travis builds.

I tried to build ninja_installer with CONAN_DOCKER_IMAGE_SKIP_UPDATE=1 as documentation suggests.
currently, there is no point wasting time on conan update, as CDT rebuilt after conan or CPT releases.
unfortunately, it fails with the following error message:

/bin/sh: run_create_in_docker: command not found

full log at https://travis-ci.com/bincrafters/conan-ninja_installer/jobs/165005420

/cc @uilianries

Related with conan-io/conan#3963

I'm using your docker image for building my clion projects. It would be nice to get new cmake in it :)

Conan docker images use python 2.7 as a default interpreter. Python 2 is going to be deprecated soon by conan, maybe it's time to switch to 3.6?

After to update our images with python3 only, @ericLemanissier reported some error involving tar.xz file when building conan-qt package.

Seems pyenv didn't install lzma support.

Logs:
https://dev.azure.com/bincrafters/packages/_build/results?buildId=30&view=logs
https://travis-ci.org/bincrafters/conan-qt/jobs/448257590#L1328

I was playing around with conanio/gcc7-armv7 and found, that the compiler variables such as CC are set in the Dockerfile. In the docs, section cross building, it is advocated to use the [env]section of the profile for this. What do you think about copying these variables to the profile? That would make the images more conformant with the docs (and thus less confusing). Alternatively, one could leave a note in the docs, that there are alternative approaches, and one of them is used in the official images.

we have a bunch of issues related to the ARMv8 builds, for instance:
https://github.com/conan-community/community/issues/157
https://github.com/conan-community/community/issues/155
it make sense to add them as well to simplify debugging and reproducing of such issues

I'm using the conan_server from this repository for testing purposes. As far as I could see there is no user set up for uploading any packages onto it. That means a user needs to alter the server.conf manually after starting the container.
In order to support a fully automated toolchain it would be good to have a different way of setting this up. I'm not that much into docker and conan_server from the perspective of the image-creator, so there's probably already a mechanism in place that could be used?

• Is there already a way to upload packages without touching the conan_server?
• If not: What mechanism to provide this functionality would best practice?

Could you please include subversion into docker images so we could use them unchanged?
Same for mercurial.

I tried building this example but it fails almost immediately with this error. I'm not sure if this image is built by CI or not. Can anyone else build and see if they can reproduce?

Apply same rules from Conan Package Tools:

• CONAN_STABLE_BRANCH_PATTERN
• CONAN_UPLOAD_ONLY_WHEN_STABLE

Is it possible to upgrade gcc 4.9 x86 and x86_64 images to use ubuntu:xenial as base image ?
The problem I have is that I need to have xkbcommon lib >= 0.5.0 to build Qt package, but trusty provides 0.4.1

Hi!

CDT is not supporting sudo pip and sudo python because of pyenv.

When CPT runs, it invokes sudo command install update conan package, resulting in failure.

we have to update autoconf & automake versions on our gcc7-centos6 images
currently, gettext_installer fails with the following error:

aclocal.m4:17: warning: this file was generated for autoconf 2.69.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically 'autoreconf'.
configure.ac:26: error: Autoconf version 2.65 or higher is required
aclocal.m4:156: AM_INIT_AUTOMAKE is expanded from...
configure.ac:26: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
WARNING: 'autoconf' is probably too old.
         You should only need it if you modified 'configure.ac',
         or m4 files included by it.
         The 'autoconf' program is part of the GNU Autoconf package:
         <http://www.gnu.org/software/autoconf/>
         It also requires GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
make: *** [Makefile:402: configure] Error 63

running autoreconf -fiv doesn't cure this issue, as project uses macro from newer automake version.
this might not be easy to do, EPEL release has autoconf268 package, but no recent automake. this may end up into building autoconf/automake from source, or building RPM packages.

/cc @uilianries

Hi!

As we know, all images support both x86 and x86_64 builds. However, when we need to install some system package that is not a Conan package yet or is very distro dependent, we need to run SystemPackageTools.

Unfortunately, many packages are not prepared to be installed on same system using arch variation. For example, when I need to install some amd64 deb package on Ubuntu, the same header directories are used by i386 version. As result, we have a conflict during install.

As workaround, we append the target on package name, please check our SDL2 recipe to understand better. This works well when we have only one arch build by job.

Would be nice to provide recipes without this workaround, including their package. But, to have such situation, we need to create new Docker images, based on 32-bits arch. Fortunately, we have official docker images for Ubuntu 32-bits on hub.docker

My suggestion to solve such problem, is implement 32 bits version of Conan docker images. I know that this will increase (duplicate) the number of images, but will provide a way to build our recipes with no workarounds to solve multi-arch limitations. As done before, I could help to implement such images.

Regards!

/cc @solvingj

Create a Conan Docker Hub account and share the Docker containers over this account.

Obviously, this is nothing personal against lasote, but if the container references would look something like conanio/gcc8 instead of lasote/conangcc8 then it would look much more official and trustworthy (without knowing who lasote is).

I was trying to build a package using CPT with CONAN_CLANG_VERSIONS="7.0" and failed:

Exception: Error pulling the image: conanio/clang70

According to #54 (comment) the image is now conanio/clang7, so I changed the env to CONAN_CLANG_VERSIONS="7" and ended up with another error:

conans.errors.ConanException: Invalid setting '7' is not a valid 'settings.compiler.version' value.
Possible values are ['3.3', '3.4', '3.5', '3.6', '3.7', '3.8', '3.9', '4.0', '5.0', '6.0', '7.0', '8']

Seems conan use major-only for Clang >= 8.0, but not for 7.0: conan-io/conan#3643.

Environment Details

• Conan Docker Tools image: conanio/clang7
• Operating System: macOS
• Operation System Version: macOS Mojave 10.14.3
• Python version (If you are building some image): N/A

Build logs

# export CONAN_CLANG_VERSIONS="7.0"
...
____________________________________________________________________________________________________

 >> sudo -E docker pull conanio/clang70

____________________________________________________________________________________________________
Using default tag: latest
Error response from daemon: pull access denied for conanio/clang70, repository does not exist or may require 'docker login'
Traceback (most recent call last):
  File "build.py", line 8, in <module>
    docker_builder.run()
  File "/usr/local/lib/python2.7/site-packages/cpt/packager.py", line 449, in run
    self.run_builds(base_profile_name=base_profile_name)
  File "/usr/local/lib/python2.7/site-packages/cpt/packager.py", line 554, in run_builds
    docker_entry_script=self.docker_entry_script)
  File "/usr/local/lib/python2.7/site-packages/cpt/runner.py", line 184, in run
    self.pull_image()
  File "/usr/local/lib/python2.7/site-packages/cpt/runner.py", line 244, in pull_image
    raise Exception("Error pulling the image: %s" % self._docker_image)
Exception: Error pulling the image: conanio/clang70

The clang dockers still contain a gcc toolchain, which may lead to wrong/unexpected packages.

Example issue: bincrafters/community#669

Is it possible to remove the gcc toolchain from them?

Hello,

I have been unable to resolve non-Conan dependencies using the package manager with the Ubuntu images. This is due to these images' /etc/apt/sources.list files missing the entries for their respective build architectures. Each entry varies according to distro release, build architecture, and end-of-life status. This is a lot of logic to put in a Conan recipe, and the effort will be multiplied by each person who needs to solve this problem.

I propose that each Ubuntu Docker image meant for cross-compiling contains the entries for its build architecture. I also propose that all the needed dpkg commands are issued.

The motivation behind this is that when creating a new Conan recipe for an existing library, it is prudent to temporarily resolve library dependencies with the package manager until a recipe can be created for the dependency.

Let me know if this is a good/bad idea. I would be willing to do the work and submit a PR.

@lasote

Since we use build.py to build, test and upload our images, I think both build.sh and run.sh could be removed from this project. Docker Compose is able to do the same tasks.

Hi!

@solvingj reported about an error during Boost Python build. As you can see, we have distribution support error.

After that, I read Ubuntu EOF page. Well, zesty (17.04) is dead.

We need to update all images to prevent EOF. IMO, would be nice to use Ubuntu 18.04 as base.

Regards!

Hi everyone,

An error started surfacing today on the travis-ci OSX builds with xcode 8.x images:

Incorrect 'apple-clang' version 'compiler.version=8.0' is not the one detected by CMake: 'Clang=8.1'

Here's one of them:

https://travis-ci.org/dimi309/small3d/jobs/309858717

The build corresponds to this entry in my .travis.yml matrix:

- <<: *osx
        osx_image: xcode8.2
        env: CONAN_APPLE_CLANG_VERSIONS=8.0

Of course I can try to change clang versions but I wanted to ask you first, is this the way to go? Are there any changes in the image? In general, what is the best way forward?

Thanks!

What?
Develop a new docker image based on Ubuntu 17.04 + clang-3.9

Why?
Conan project support many compilers, including clang on Linux.

How?
Provide lasote/conanclang39 image by hub.docker

Xenial now uses gcc 5.4 by default, so rebuilding these Dockerfiles causes gcc_5.3 to include gcc 5.4.

Once we have a visual studio image working well on travis and azure pipelines, if someone has time, it would be good to have a docker image with mingw installed. i know there is already a conan-mingw_installer package, however a docker image has the distinction of being usable by people who aren't using conan directly.

Dockcross project already has some mingw images that probably show the way pretty well:

https://github.com/dockcross/dockcross

Apparently though, this only has 64 bit MinGW. a 32 bit MinGW image would also be required by some.