docker-library / buildpack-deps Goto Github PK
View Code? Open in Web Editor NEWLicense: MIT License
License: MIT License
It seems that only buildpack-deps:sid
has the latest version of git - 2.28.0
.
buildpack-deps:jessie
- git version 2.1.4
buildpack-deps:buster
- git version 2.20.1
buildpack-deps:stretch
- git version 2.11.0
buildpack-deps:bullseye
- git version 2.27.0
I attempted to bring the Elixir 10.3 image into our internal repo. Our mechanism does a scan for vulnerabilities and my request was rejected because of the version of Python 3 that appears to originate from the buildpack-deps:buster image. The CVE that caused the rejection was CVE-2020-8492 with the description:
Python 2.7 through 2.7.17, 3.5 through 3.5.9, 3.6 through 3.6.10, 3.7 through 3.7.6, and 3.8 through 3.8.1 allows an HTTP server to conduct Regular Expression Denial of Service (ReDoS) attacks against a client because of urllib.request.AbstractBasicAuthHandler catastrophic backtracking.. Impacted Image File(s): /usr/lib/python3.7/urllib/request.py
I note the image includes Python 3.7.3
I frequently run into projects that require nasm and/or yasm assemblers to build, so this could be a useful addition, plus it only weighs about 20MB on the Debian image.
We should have a micro version with just source control, curl, and wget for java and golang to use. (and buildpacks itself to inherit from).
Since build-essential is really for building debian packages, we should whittle it down (#15 (comment)).
Here is the list of packages when installing build-essential
from fresh buildpack-deps:jessie-scm
:
The following NEW packages will be installed:
binutils build-essential bzip2 cpp cpp-4.9 dpkg-dev fakeroot g++ g++-4.9 gcc gcc-4.9
libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl libasan1
libatomic1 libc-dev-bin libc6-dev libcilkrts5 libcloog-isl4 libdpkg-perl libfakeroot
libfile-fcntllock-perl libgcc-4.9-dev libgomp1 libisl10 libitm1 liblsan0 libmpc3
libmpfr4 libquadmath0 libstdc++-4.9-dev libtimedate-perl libtsan0 libubsan0
linux-libc-dev make manpages manpages-dev patch xz-utils
We will want tests on the images that inherit from this to be sure we don't break any of them. (I am pretty sure a debian developer might know which packages are specifically for debian packaging and not compiling/linking in general... ๐ ๐ @tianon, and @paultag)
I have the file with mime type audio/ogg, then I put this file into docker-container with python3:latest, where is using buildpack-deps:jessie and in debian file system file has mime type application/octet-stream. Seems, that system just can't recognize the mime type and sets default type( application/octet-stream). I have tried to update the mime types lib, but it didn't give any results. Really need your help.
https://lists.debian.org/debian-security-announce/2015/msg00120.html
Most recent Debian images are vulnerable. This should probably be built together with #23.
I'm not sure what the issue is, but the following all work:
docker run -it debian:jessie /bin/sh -c "apt-get update && apt-get install -y nginx && nginx"
docker run -it buildpack-deps:jessie-curl /bin/sh -c "apt-get update && apt-get install -y nginx && nginx"
docker run -it buildpack-deps:jessie-scm /bin/sh -c "apt-get update && apt-get install -y nginx && nginx"
But this one:
docker run -it buildpack-deps:jessie /bin/sh -c "apt-get update && apt-get install -y nginx && nginx"
Displays this error at the end when trying to run nginx:
nginx: error while loading shared libraries: /usr/lib/x86_64-linux-gnu/libxml2.so.2: invalid ELF header
Any ideas? It seems like it might need a rebuild, but I'm not sure?
As of today, I expect git-lfs to be working wherever git is installed. Sadly it is missing in the scm-tags.
buildpack-deps/stretch/scm/Dockerfile
Lines 4 to 12 in 99a1c33
Now image buildpack-deps:stretch-scm does not contains fossil-scm.
Is there any plan to support this scm.
root@7df1b43b2150:/# apt search fossil
Sorting... Done
Full Text Search... Done
fossil/xenial 1:1.33-3 amd64
DSCM with built-in wiki, http interface and server, tickets database
What do y'all think about adding fortran into this. It looks like python official is using buildpack-deps:jessie and the philosophy of this project is to make it so that doing pip install $PROJECT
works for most things. Right now pip install scipy==0.15.1
does not work, but does work if I run
apt-get install --no-install-recommends -y gfortran gfortran-4.9 libgfortran-4.9-dev
curl is configured to make http/2 requests
Unsupported protocol error
I've used the python:2.7
image which is based on buildpack-deps:jessie
. The binaries for libdb5.3
are contained in the image, but the headers are not. That leads to Python not building dbm support, yielding ImportError: No module named dbm
.
Since the library is already contained in the image, let's allow to compile against it. I suggest adding the libdb-dev
package. It only adds a few kilobytes.
Affects buildpack-debs wily, sid, wily-scm, wily-curl, sid-scm, wily-curl images.
The MongoDB package for NPM depends on libkrb5-dev
. I'm using the node:0.12.7 image (based on buildpack-deps:jessie
). Would it be possible to have this library added to the list of installed dependencies?
Hi!
I try to use image buildpack-deps:stretch with this sources list:
deb http://ftp.us.debian.org/debian/ stretch main contrib non-free
deb-src http://ftp.us.debian.org/debian/ stretch main contrib non-free
deb http://ftp.us.debian.org/debian/ stretch-updates main contrib non-free
deb-src http://ftp.us.debian.org/debian/ stretch-updates main contrib non-free
deb http://security.debian.org/ stretch/updates main contrib non-free
deb-src http://security.debian.org/ stretch/updates main contrib non-free
After apt-get update I got this error:
Reading package lists...
W: The repository 'http://security.debian.org stretch/updates Release' does not have a Release file.
W: The repository 'http://ftp.us.debian.org/debian stretch Release' does not have a Release file.
W: The repository 'http://ftp.us.debian.org/debian stretch-updates Release' does not have a Release file.
E: Failed to fetch http://security.debian.org/dists/stretch/updates/main/source/Sources 403 Forbidden
E: Failed to fetch http://ftp.us.debian.org/debian/dists/stretch/non-free/source/Sources 403 Forbidden
E: Failed to fetch http://ftp.us.debian.org/debian/dists/stretch-updates/contrib/source/Sources 403 Forbidden
E: Some index files failed to download. They have been ignored, or old ones used instead.
Cross compiling for arm takes several extra minutes because gcc-arm-linux-gnueabihf and binutils-arm-linux-gnueabihfneed to be installed first during a build. For some images relying on buildpack-deps like the official rust image, cross compiling C bindings requires the C cross compilers.
The fix would be to add gcc-arm-linux-gnueabihf and binutils-arm-linux-gnueabihf to the list of installed packages for the image.
buildpack-deps already includes libgeoip-dev
, and this library is deprecated from Maxmind. The replacement is libmaxminddb-dev
. It's not even possible (ok, it's possible, but it's very hard) to get the database files that are read by libgeoip
since Maxmind doesn't distribute them anymore.
Any opposition to bringing in the newer version?
https://github.com/maxmind/geoip-api-c/blob/master/README.md
vs
https://github.com/maxmind/libmaxminddb/blob/master/README.md
An argument can even be made to remove libgeoip-dev
since this isn't really a supported library anymore, but I image ripping things out would cause more heartache. ๐
Problem description:
docker run --rm -it --name temp buildpack-deps:jessie-scm bash
ls -la /core
-rw------- 1 root root 8646656 Jun 9 21:37 core
file /core
core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'auplink /mnt/scratch/var-lib-docker/aufs/mnt/fa1be5c3210b4a5444e6601bc92e1e7726'
has anybody researched why is this? I see majority of downstream images are still based on buildpack-deps:jessie
I believe this larger size hinders adoption of buildpack-deps:stretch
$ docker image ls buildpack-deps
REPOSITORY TAG IMAGE ID CREATED SIZE
buildpack-deps latest 223c9ecff8eb 4 weeks ago 826MB
buildpack-deps stretch 223c9ecff8eb 4 weeks ago 826MB
buildpack-deps stretch-scm 8b8559aff3a2 4 weeks ago 273MB
buildpack-deps stretch-curl 6b9f0849e499 4 weeks ago 131MB
buildpack-deps jessie a00998d35d0b 4 weeks ago 610MB
buildpack-deps jessie-scm 3f8223a87be8 4 weeks ago 291MB
buildpack-deps jessie-curl 6eff593c35dd 4 weeks ago 168MB
Using this simple Dockerfile:
FROM buildpack-deps:stretch
RUN ldconfig
I see the following output:
Step 1/2 : FROM buildpack-deps:stretch
stretch: Pulling from library/buildpack-deps
c73ab1c6897b: Already exists
1ab373b3deae: Already exists
b542772b4177: Already exists
57c8de432dbe: Already exists
1785850988c5: Already exists
Digest: sha256:889af006b4464deb95e123a47b014b68a0566bf4c21def0d0d137166d6892834
Status: Downloaded newer image for buildpack-deps:stretch
---> d63e05ca3eba
Step 2/2 : RUN ldconfig
---> Running in 92e4fef4f202
ldconfig: /usr/lib/x86_64-linux-gnu/libmpc.so.3.0.0 is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libmagic.so.1 is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libmagic.so.1.0.0 is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libpthread.so is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libmpfr.so.4.1.5 is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libsigsegv.so.2.0.3 is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libopenjp2.so.7 is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libmpc.so.3 is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libxml2.so is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.4 is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libopenjp2.so is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libmpfr.so.4 is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libxml2.so.2 is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libsigsegv.so.2 is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/lib/x86_64-linux-gnu/libopenjp2.so.2.1.2 is not an ELF file - it has the wrong magic bytes at the start.
Removing intermediate container 92e4fef4f202
---> 69cf2f0a27c7
Successfully built 69cf2f0a27c7
Successfully tagged huh:latest
I ran into this problem when trying to build a C extension for bcrypt_elixir that relies upon this image. Here's it error output:
Step 8/8 : RUN cd deps/bcrypt_elixir && make clean && make
---> Running in 6ac9610fb466
rm -f priv/bcrypt_nif.so
mkdir -p priv
cc -g -O3 -Wall -I/usr/local/lib/erlang/erts-9.3/include -Ic_src -fPIC -shared c_src/bcrypt_nif.c c_src/blowfish.c -o priv/bcrypt_nif.so
/usr/lib/gcc/x86_64-linux-gnu/6/cc1: error while loading shared libraries: /usr/lib/x86_64-linux-gnu/libmpc.so.3: invalid ELF header
/usr/lib/gcc/x86_64-linux-gnu/6/cc1: error while loading shared libraries: /usr/lib/x86_64-linux-gnu/libmpc.so.3: invalid ELF header
Makefile:29: recipe for target 'priv/bcrypt_nif.so' failed
make: *** [priv/bcrypt_nif.so] Error 1
The command '/bin/sh -c cd deps/bcrypt_elixir && make clean && make' returned a non-zero code: 2
Here are some details about my system:
I've used graphicsmagick-imagemagick-compat
instead of imagemagick
in my images, as it seems to be the goto option these days. GraphicsMagick is a fork is concentrating on better performance and stability, see https://en.wikipedia.org/wiki/GraphicsMagick.
I suggest to add aria2c to the image and use it in the dependent images instead of curl
and wget
. aria2c is a multistream downloader which downloads files faster and deals better with connections instabilities.
https://www.debian.org/security/2015/dsa-3231
Debian *-scm images should be upgraded with the latest subversion package.
Hi,
The upstream debian packages have tags for unstable/stable/testing/oldstable/oldoldstable. Is there any possibility that some of these could be translated into buildpack-deps too?
Specifically we have an internal docker image which gets regularly built against the "stable" scm variant and I only just noticed that we're still using jessie when stable has moved onto stretch. Would be great if we could just reference "stable-scm" and have that pull down whatever is current!
To be clear, I've only got a desire for stable but thought others might want the other variants.
I'm really liking using these images as the base for Dockerizing software packages which need the dev tools like libxml2-dev
, but I'm wondering why wget
or curl
don't make an appearance?
As a simple example, those tools would make it easy to grab the source for a piece of software I'm trying to wrap in a Docker image.
I'm happy to submit a patch if I'm not barking up the wrong tree here.
In containers based on the bionic-curl
and bionic-scm
images, for some new packages installed with apt, not all files in the package are present after installation. In particular, some files under /usr/share/doc
and /usr/share/man
are missing.
Steps to reproduce:
$ docker run --rm -it buildpack-deps:bionic-curl /bin/bash -l
root@73b619bd6c3e:/# apt update > /dev/null 2> /dev/null
root@73b619bd6c3e:/# apt install hello
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
hello
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 27.2 kB of archives.
After this operation, 111 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu bionic/main amd64 hello amd64 2.10-1build1 [27.2 kB]
Fetched 27.2 kB in 0s (85.1 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package hello.
(Reading database ... 4763 files and directories currently installed.)
Preparing to unpack .../hello_2.10-1build1_amd64.deb ...
Unpacking hello (2.10-1build1) ...
Setting up hello (2.10-1build1) ...
root@73b619bd6c3e:/# dpkg --verify hello
??5?????? /usr/share/doc/hello/NEWS.gz
??5?????? /usr/share/man/man1/hello.1.gz
root@73b619bd6c3e:/# ls /usr/share/doc/hello/NEWS.gz
ls: cannot access '/usr/share/doc/hello/NEWS.gz': No such file or directory
root@73b619bd6c3e:/# ls /usr/share/man/man1/hello.1.gz
ls: cannot access '/usr/share/man/man1/hello.1.gz': No such file or directory
The output of dpkg --verify
and ls
shows that the files are missing.
This behavior is not exhibited on xenial-curl
or buster-curl
.
Any idea what could be causing this or how to address it?
Hi guys,
looks like jessie images don't contain apt-get command, which can brake building images based on jessie (in case of using apt-get command in dockerfile).
I believe that because of this error most of microsoft/dotnet images based on jessie-scm aren't working at the moment (Failed to initialize CoreCLR, HRESULT: 0x80131500). Probably they were built with non-working apt-get and libicu52 wasn't installed, which is the root of problem with CoreCLR.
Command lsb_release
not found. This is required for some installations, e.g. MongoDB via their official guides. What would be the output of lsb_release -sc
?
Related issue: nodejs/docker-node#1062.
Firstly, I saw issue #78 and the reason to close it, however, the success of this library has preceded itself and other contributers are using it as a base template for their images. Like https://github.com/docker-library/golang.
At this point Golang is using the SCM variant of this set for their Debian builds and Alpine for their slim builds but it would be really nice to have a Debian slim build to be able to utilize the pro's of Debian with the reduced size of Alpine in, at least, that specific branch of the SCM tree.
Please reconsider adding a slim branch in this repository for a buster-(slim-)curl and a buster-(slim-)scm image.
I volunteer contribution by the way if it is required.
Could we get a -sudo
variant?
The base Ubuntu images don't come with sudo. While this isn't really a problem when writing a Dockerfile, it can be a problem when using images on some CI/CD services that follow the best-practice of not running container processes as root.
This seems to vary by CI/CD service. Some (like GitLab) run the CI script as root in the container, while Azure Pipelines don't.
I attempted to bring the Elixir 10.3 image into our internal repo. Our mechanism does a scan for vulnerabilities and my request was rejected because of the version of Python 2 that appears to originate from the buildpack-deps:buster-scm image. The CVE that caused the rejection was CVE-2020-8492 with the description:
Python 2.7 through 2.7.17, 3.5 through 3.5.9, 3.6 through 3.6.10, 3.7 through 3.7.6, and 3.8 through 3.8.1 allows an HTTP server to conduct Regular Expression Denial of Service (ReDoS) attacks against a client because of urllib.request.AbstractBasicAuthHandler catastrophic backtracking.. Impacted Image File(s): /usr/lib/python3.7/urllib/request.py
I note the image includes Python 2.7.16
Have you any plan to bring this image to Alpine for example ?
There's a serious bug in debian that I'm really surprised hasn't been urgently fixed.
Debian recently (incorrectly) removed trust for GeoTrust Global CA:
GeoTrust Global CA is used by Apple, among others. E.g, try to run the following:
docker run --rm -it buildpack-deps:latest openssl s_client -verify_return_error -showcerts -connect imap.mail.me.com:993
My result:
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=19:self signed certificate in certificate chain
139924179555456:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915:
---
no peer certificate available
---
No client certificate CA names sent
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 6095 bytes and written 315 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self signed certificate in certificate chain)
---
I can workaround it for Apple and other GeoTrust-signed certs by placing the following into my Dockerfile:
RUN curl --max-time 300 --retry 5 --retry-delay 1 --retry-max-time 900 --silent -o /usr/local/share/ca-certificates/geotrust.crt https://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Global_CA.pem
RUN update-ca-certificates
But I don't know if other certs are incorrectly removed (it seems likely from the bugreport and changelog).
It is quite common that packages are distributed in .zip
instead of tar.gz
.
I suggest to add unzip
package to buildpack-deps
.
ubuntu unzip
package size is around 600KB which is small.
Takes 243 kiB.
It would appear that the buildpack-deps:stretch-curl
base image contains a version of curl
(7.52.1-5+deb9u7
) that has a few vulnerabilities (CVE-2018-16839). More discussion on this vulnerability is available here.
This base image is used by a number of other images (including openjdk:8-jdk
) that we rely on at work.
A patched version of curl (7.52.1-5+deb9u8
) appears to be available. Would it be possible to rebuild the buildpack-deps:stretch-curl
image so this update could be picked up?
$ docker run --rm -it buildpack-deps:stretch-curl sh -c "dpkg -s curl | grep '^Version'"
Version: 7.52.1-5+deb9u7
$
skopeo
to figure out the most recent sha256 hash for the image:$ skopeo -override-os linux inspect docker://buildpack-deps:stretch-curl | jq '.Digest'
"sha256:dd5963b4735c6702455e790b301ce267d744336444088e4a827bae6fd11b5d01"
$
$ docker run --rm -it buildpack-deps:stretch-curl@sha256:dd5963b4735c6702455e790b301ce267d744336444088e4a827bae6fd11b5d01 sh -c "dpkg -s curl | grep '^Version'"
Version: 7.52.1-5+deb9u7
$
apt-get update && apt-get install -y curl
to prove a new version is available$ docker run --rm -it buildpack-deps:stretch-curl@sha256:dd5963b4735c6702455e790b301ce267d744336444088e4a827bae6fd11b5d01 sh -c "apt-get update && apt-get install -y --no-install-recommends curl && dpkg -s curl | grep '^Version'"
[...]
Setting up curl (7.52.1-5+deb9u8) ...
Version: 7.52.1-5+deb9u8
$
Readme at main site on docker hub states that npm is included in this image with other build tools, but when I run simple Dockerfile with it, I get npm not found error.
FROM buildpack-deps
RUN git clone https://github.com/screeps/screeps.git
WORKDIR ./screeps
EXPOSE 21025 21026
RUN npm install screeps # error here!
RUN npx screeps init
CMD ["npx", "screeps", "start"]
Given this information: https://en.wikipedia.org/wiki/Debian_version_history#Release_table
Will you be dropping Wheezy from support in May?
Hi, these issues have all been previously reported and have CVE's. Docker Cloud's "Docker Security Scanning" listed them as relevant to the jessie Docker image.
Is there any way to mitigate them in the jessie image?
Some of them are not so relevant, but curious if it's possible to include the fixes.
The report output is all HTMLy, but if you push the jessie image to docker cloud and enable "Security Scanning", you'll see a report. Thanks!
curl 7.38.0-4+deb8u5
MIT: Permissive License
CVE-2016-4802
CVE-2016-3739
Major
Minor
wget 1.16-1+deb8u1
GPLv3: Copyleft License
CVE-2016-7098
Major
libxml2 2.9.1+dfsg1-5+deb8u3
MIT: Permissive License
CVE-2016-4614
CVE-2016-4615
CVE-2016-4616
CVE-2016-4619
CVE-2016-5131
CVE-2015-6837
CVE-2015-6838
Critical
Critical
Critical
Critical
Major
Major
Major
pcre
BSD: Permissive License
CVE-2016-3191
CVE-2014-9769
Critical
Critical
gdlib
BSD: Permissive License
CVE-2016-3074
CVE-2016-7568
CVE-2016-5766
CVE-2016-5767
CVE-2013-7456
CVE-2016-5116
CVE-2016-6128
CVE-2015-8877
CVE-2016-6905
CVE-2016-6161
CVE-2016-6214
CVE-2016-6132
CVE-2016-6207
Critical
Critical
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
libxslt 1.1.28-2+deb8u1
MIT: Permissive License
CVE-2016-4612
CVE-2016-4607
CVE-2016-4609
CVE-2016-4608
CVE-2016-4610
Critical
Critical
Critical
Critical
Critical
gdkpixbuf
LGPL: Lgpl License
CVE-2015-8875
CVE-2016-6352
Major
Major
The build images don't seem to have socat installed, which is incredibly handy for doing network routing between containers. I propose that socat be added to the images.
So approximately one in every eight of my automated builds on docker hub will fail on trying to install packages with apt-get install
. The error I get Error reading from server. Remote end closed connection [IP: 128.31.0.66 80]
makes it seem like either docker hub is dropping the connections to debian's apt servers or the apt cache of the container is in a weird state.
Build logs: http://pastebin.com/FXxe6XH5
Source image: FROM node:4.2.4-slim
Run line: RUN apt-get update && apt-get install -y python python-dev python-pip python-virtualenv && apt-get clean && rm -rf /var/lib/apt/lists/*
Yesterday I added a pre-install clean making that run line: RUN apt-get clean && apt-get update && apt-get install -y python python-dev python-pip python-virtualenv && apt-get clean && rm -rf /var/lib/apt/lists/*
I am at 20 builds without issue so far after adding that to my Dockerfile.
I checked the node dockerfile, they don't install anything through apt-get
so that leaves the build packs. Is there any reason to not add apt-get clean
to the end of each apt-get install? PR is coming
Hallo,
using debian slim baseimages should bring the size down by a few MBs, without really compromising features. The con is the missing documentation.
I am confused at why the base layers of the arm32v7/buildpack-deps:bionic-*
images are different than the arm32v7/ubuntu:bionic
images.
docker history --no-trunc arm32v7/buildpack-deps:bionic-curl
IMAGE CREATED CREATED BY SIZE COMMENT
sha256:20754fee7abf041e9fd7fbbe677447d84ec5bdc015c6ea8e0c883a1c9e34997f 44 hours ago /bin/sh -c set -ex; if ! command -v gpg > /dev/null; then apt-get update; apt-get install -y --no-install-recommends gnupg dirmngr ; rm -rf /var/lib/apt/lists/*; fi 0B
<missing> 44 hours ago /bin/sh -c apt-get update && apt-get install -y --no-install-recommends ca-certificates curl wget && rm -rf /var/lib/apt/lists/* 13MB
<missing> 2 weeks ago /bin/sh -c #(nop) CMD ["bash"] 0B
<missing> 2 weeks ago /bin/sh -c #(nop) ADD file:1fdf1946f816fc31d9b70835fe5cc0346daccdfa3c06a8420b30437b9df12c84 in / 80.6MB
docker history --no-trunc arm32v7/ubuntu:bionic
IMAGE CREATED CREATED BY SIZE COMMENT
sha256:b47afe3525fa5431d9adb152197e2c0156303b7c7d6f5a4769b41ef29dbb05ac 3 weeks ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B
<missing> 3 weeks ago /bin/sh -c mkdir -p /run/systemd && echo 'docker' > /run/systemd/container 7B
<missing> 3 weeks ago /bin/sh -c sed -i 's/^#\s*\(deb.*universe\)$/\1/g' /etc/apt/sources.list 2.83kB
<missing> 3 weeks ago /bin/sh -c rm -rf /var/lib/apt/lists/* 0B
<missing> 3 weeks ago /bin/sh -c set -xe && echo '#!/bin/sh' > /usr/sbin/policy-rc.d && echo 'exit 101' >> /usr/sbin/policy-rc.d && chmod +x /usr/sbin/policy-rc.d && dpkg-divert --local --rename --add /sbin/initctl && cp -a /usr/sbin/policy-rc.d /sbin/initctl && sed -i 's/^exit.*/exit 0/' /sbin/initctl && echo 'force-unsafe-io' > /etc/dpkg/dpkg.cfg.d/docker-apt-speedup && echo 'DPkg::Post-Invoke { "rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true"; };' > /etc/apt/apt.conf.d/docker-clean && echo 'APT::Update::Post-Invoke { "rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true"; };' >> /etc/apt/apt.conf.d/docker-clean && echo 'Dir::Cache::pkgcache ""; Dir::Cache::srcpkgcache "";' >> /etc/apt/apt.conf.d/docker-clean && echo 'Acquire::Languages "none";' > /etc/apt/apt.conf.d/docker-no-languages && echo 'Acquire::GzipIndexes "true"; Acquire::CompressionTypes::Order:: "gz";' > /etc/apt/apt.conf.d/docker-gzip-indexes && echo 'Apt::AutoRemove::SuggestsImportant "false";' > /etc/apt/apt.conf.d/docker-autoremove-suggests 745B
<missing> 3 weeks ago /bin/sh -c #(nop) ADD file:886ddcd1b8d1c90b4eb406530752924e28c90f8252af281e708532d67def3c2c in / 68MB
I am running into things that appear to be missing from the buildpack-deps image for example apt
is missing, the registered package feeds are different therefore packages available on arm32v7/ubuntu:bionic
are unavailable "out of the box" on arm32v7/buildpack-deps:bionic-*
docker run -it --rm arm32v7/buildpack-deps:bionic-scm grep -h ^deb /etc/apt/sources.list /etc/apt/sources.list.d/*
deb http://deb.debian.org/debian wheezy main
deb http://deb.debian.org/debian wheezy-updates main
deb http://security.debian.org wheezy/updates main
docker run -it --rm arm32v7/ubuntu:bionic grep -h ^deb /etc/apt/sources.list /etc/apt/sources.list.d/*
deb http://ports.ubuntu.com/ubuntu-ports/ bionic main restricted
deb http://ports.ubuntu.com/ubuntu-ports/ bionic-updates main restricted
deb http://ports.ubuntu.com/ubuntu-ports/ bionic universe
deb-src http://ports.ubuntu.com/ubuntu-ports/ bionic universe
deb http://ports.ubuntu.com/ubuntu-ports/ bionic-updates universe
deb-src http://ports.ubuntu.com/ubuntu-ports/ bionic-updates universe
deb http://ports.ubuntu.com/ubuntu-ports/ bionic multiverse
deb http://ports.ubuntu.com/ubuntu-ports/ bionic-updates multiverse
deb http://ports.ubuntu.com/ubuntu-ports/ bionic-backports main restricted universe multiverse
deb http://ports.ubuntu.com/ubuntu-ports/ bionic-security main restricted
deb http://ports.ubuntu.com/ubuntu-ports/ bionic-security universe
deb-src http://ports.ubuntu.com/ubuntu-ports/ bionic-security universe
deb http://ports.ubuntu.com/ubuntu-ports/ bionic-security multiverse
Client:
Version: 18.02.0-ce
API version: 1.29 (downgraded from 1.36)
Go version: go1.9.3
Git commit: fc4de44
Built: Wed Feb 7 21:16:33 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm
Server:
Engine:
Version: 17.05.0-ce
API version: 1.29 (minimum version 1.12)
Go version: go1.7.5
Git commit: 89658be
Built: Thu May 4 22:30:54 2017
OS/Arch: linux/arm
Experimental: false
Containers: 9
Running: 0
Paused: 0
Stopped: 9
Images: 60
Server Version: 17.05.0-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log:
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Kernel Version: 4.9.35-v7+
Operating System: Raspbian GNU/Linux 8 (jessie)
OSType: linux
Architecture: armv7l
CPUs: 4
Total Memory: 923.4MiB
Name: raspberrypi
ID: 3UO3:FS2Q:BZB2:GFD5:5AVY:R4FH:OCFJ:IQ4C:7MCH:TGAH:RCFG:CAWQ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
WARNING: No cpuset support
I'm encountering a failure when trying to build an image that installs google-chrome. This is the smallest Dockerfile I could make that reliably reproduces the error:
FROM buildpack-deps:buster
RUN wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - && \
sh -c 'echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' && \
apt-get update && apt-get install -y default-mysql-server google-chrome-stable --no-install-recommends
This produces:
E: Failed to fetch http://deb.debian.org/debian/pool/main/g/gtk+3.0/libgtk-3-0_3.24.5-1_amd64.deb 400 Bad Request [IP: 151.101.200.204 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
I'm able to build this image fine when using buildpack-deps:buster-scm
.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.