On Mon, 2018-11-19 at 01:02 +0100, Philippe Mathieu-Daudé wrote: > Hi Dario, > Hi,
> On Sun, Nov 18, 2018 at 10:54 PM Dario Faggioli <dfaggi...@suse.com> > wrote: > > On Sun, 2018-11-18 at 19:47 +0000, Alex Bennée wrote: > > > This hasn't been tested because the docker image fails to build > > > due > > > to > > > continuation breakage. > > > > > It is indeed broken. > > > > Basically, I tested it thoroughly, and I'm quite sure it works ok > > (although, I'm no docker expert). > > I quickly fixed/tried it. > Cool, thanks for having a look. :-) > First this package list pulls many unuseful system packages. > I added '--no-recommends' to reduce a bit: > > RUN zypper ref && \ > zypper up -y && \ > zypper install -y --no-recommends $PACKAGES > Right, that makes sense. I'll add it. > This still install a bunch of unnecessary stuffs: > > Creating group systemd-journal with gid 485. > Creating group systemd-network with gid 484. > Creating user systemd-network (systemd Network Management) with uid > 484 and gid 484. > Creating group systemd-coredump with gid 483. > Creating user systemd-coredump (systemd Core Dumper) with uid 483 and > gid 483. > Creating group systemd-timesync with gid 482. > Creating user systemd-timesync (systemd Time Synchronization) with > uid > 482 and gid 482. > Failed to connect to bus: No such file or directory > > Then the resulting image takes the same than without --no-recommends: > 1.1GB. No idea why. > So, my "model" was the fedora.docker dockerfile, where quite a few package are also installed, much more than the bare minimum necessary for a build to succeed (AFAICT, at least). The idea would be to enable and include support for as many features/backends/integrations/etc as possible, in order to test them. Basically, I did this by trial-and-error, i.e., adding packages related to entries in `./configure' which looked like 'no', and keeping them (only) if they turned such entry to 'yes'. Now, this is what I see on my system, and that's why size did not concerned me: :-) REPOSITORY TAG IMAGE ID CREATED SIZE qemu opensuse-leap 6bd6bc2ac139 4 hours ago 1.09GB qemu fedora 1b05e254d0d9 5 hours ago 2.02GB If this is not ok, I'm happy to try to shrink the image size a bit (e.g., I'll double check if there are useless packages left in place), and/or to put together another dockerfile (something like opensuse- leap_minimal), with just what is necessary for the build (and the tests) to succeed. > At some point some package tried to talk to the network manager via > DBus to start sshd... > Ah, interesting. :-P So, from where did you see this (as well as the logs above) logs? Running `make docker-***' with 'V=1', I'm guessing? > Second, while this works on x86_64, it fails on aarch64: > > Problem: libcurl-devel-7.59.0-lp150.1.2.aarch64 requires libcurl4 = > 7.59.0, but this requirement cannot be provided > not installable providers: libcurl4-7.59.0-lp150.1.2.aarch64[repo- > oss] > Solution 1: downgrade of libcurl4-7.60.0-lp150.2.15.1.aarch64 to > libcurl4-7.59.0-lp150.1.2.aarch64 > Solution 2: do not install libcurl-devel-7.59.0-lp150.1.2.aarch64 > Solution 3: break libcurl-devel-7.59.0-lp150.1.2.aarch64 by ignoring > some of its dependencies > Ok, I see. > Not your fault. So I suppose you are planning to use this image to > compile QEMU for openSUSE/x86_64 only, is this correct? > Yes, basically, x86_64 is my main usecase, and the (only) setup I can test quickly and easily enough. However, I'm certainly up for trying to improve this, and make this dockerfile useful for other arches as well. I'll try to look into this. How did you test this on aarch64? On a native ARM host, or using QEMU? Thanks again and Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/
signature.asc
Description: This is a digitally signed message part
