Re: Docker image not working
Hello Stephen,
Stephen Scheck writes:
> I don't think the docs are quite up to date, or perhaps refer to an older
> version of Docker. If I do:
>
> $ docker create system:0qjxd5ljsh316ki7wqkk2xz9b68lynh2
> Error response from daemon: No command specified
>
> Looks like `docker create` wants the entry point, hence why I tried to use
> `docker run` to fire up the container ... so what should it be to kick off
> the Shepherd service you referred to?
>
> Thanks.
The documentation works for me, with a minor hiccup: the docker load
doesn't return *just* the image ID: the first two words must be cut out
(by piping it to awk '{ print $3 }' for example).
--8<---cut here---start->8---
guix system docker-image some-system-with-python.scm
[...]
/gnu/store/5ddyv2m6kfjhm0fc3v181ahs35hkf6j6-guix-docker-image.tar.gz
image_id=`docker load <
/gnu/store/5ddyv2m6kfjhm0fc3v181ahs35hkf6j6-guix-docker-image.tar.gz`
$ echo $image_id
Loaded image: guix:latest
$ container_id=`docker create $image_id`
invalid reference format: repository name must be lowercase
$ image_id="guix:latest"
$ container_id=`docker create $image_id`
$ echo $container_id
9eabc3cae4bba25848c7f1ced15086232a5b19a2e5d775374e842855890d51f3
$ docker start $container_id
9eabc3cae4bba25848c7f1ced15086232a5b19a2e5d775374e842855890d51f3
$ docker exec -ti $container_id /run/current-system/profile/bin/bash --login
root@9eabc3cae4bb /# which python
which python
/run/current-system/profile/bin/python
root@9eabc3cae4bb /# python --version
python --version
Python 3.7.4
--8<---cut here---end--->8---
I also tested with your operating system declaration and it also worked:
--8<---cut here---start->8---
docker load <
/gnu/store/49cgpsq6978j7f9l7fk3pw8f1dldlyv3-guix-docker-image.tar.gz
c2cd1fc572fa: Loading layer
[==>]631MB/631MB
The image guix:latest already exists, renaming the old one with ID
sha256:fb0dc0872f71e5051f316b36f1f12ef71a7eb88a77b16fbf86fff66258cce885 to
empty string
Loaded image: guix:latest
$ ~/src/guix-master [env]$ docker create guix:latest
25c6b88a578270aec4bd20f7050f591b9f971397f77282ae826fe6f488b125c6
$ docker start 25c6b88a578270aec4bd20f7050f591b9f971397f77282ae826fe6f488b125c6
25c6b88a578270aec4bd20f7050f591b9f971397f77282ae826fe6f488b125c6
$ docker exec -ti
25c6b88a578270aec4bd20f7050f591b9f971397f77282ae826fe6f488b125c6
/run/current-system/profile/bin/bash --login
root@25c6b88a5782 /#
--8<---cut here---end--->8---
Sorry, I'm not sure what is wrong on your side. I've seen this error
before but can't remember what the solution was :-/. Perhaps something
doesn't work right with your Docker daemon?
HTH,
Maxim
Re: Java fontconfig issues
Hi Jonathan,
On Sat, 16 Nov 2019 11:57:24 -0500
Jonathan Frederickson wrote:
> I've been trying to run PCGen
> (https://github.com/PCGen/pcgen/releases) on my laptop running Guix
> System, so far without success. I know that ideally all software would
> be installed through Guix itself, but this thing is a Java app with
> several dependencies that aren't in Guix yet and... honestly, right at
> this moment, I'd be fine with running the jar directly for now.
>
> However, when attempting to run this Jar with openjdk installed, I get
> a null pointer exception related to some font configuration code. This
> seems related to an issue on the AdoptOpenJDK repos[0], which was
> solved in that case by installing the fontconfig package (on a Debian
> install in their case). However, installing fontconfig into my profile
> in Guix hasn't done the trick. There's a workaround mentioned
> involving creating a fontconfig.properties file in JAVA_HOME, but
> setting that as an environment variable didn't seem to do the trick
> either.
>
> While the specific application I'm focusing on is PCGen, this seems to
> affect graphical Java applications in general; I tested with a
> generic JAR build of Jitsi and ran into the same issue.
>
> Can anyone familiar with Java provide some assistance in tracking down
> this problem?
>
> https://github.com/AdoptOpenJDK/openjdk-build/issues/693
I found that error too in ProjectLibre and even in Tomcat, which is not
"graphical", but just uses fonts.
Here is a very small program to trigger the error:
import java.awt.*;
public class Main {
public static void main(String[] args)
{
String fonts[] =
GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames();
for ( int i = 0; i < fonts.length; i++ )
{
System.out.println(fonts[i]);
}
}
}
(I think I have that snipped from the AdoptOpenJDK-Bug, not 100% sure).
If I enter a Guix-Container with OpenJDK 12 or 11 (not tried 10,9),
compile and run it, it will fail (you need to compile new for each
version because of different target versions) with the
NullPointerException. As you mentioned, even adding fontconfig to that
environment does not help.
It works with JDK 8 though, provided through the icedtea@3 package. If
your Java program still works with Java 8, that might be a workaround
for you.
Here are the specific environments I tried:
guix environment -C --share=/tmp/.X11-unix --ad-hoc coreutils less grep
findutils ant which icedtea@3:jdk
guix environment -C --share=/tmp/.X11-unix --ad-hoc coreutils less grep
findutils ant which openjdk@12:jdk
guix environment -C --share=/tmp/.X11-unix --ad-hoc coreutils less grep
findutils ant which openjdk@11:jdk
In each, I called these commands:
$ javac Main.java
$ java -cp . Main
I see that fontconfig is a reference of both icedtea and openjdk:
$ guix gc --references
/gnu/store/05flqf4bqwwj4zwl2vqiqg0dlb1alzm8-icedtea-3.7.0-jdk | grep font
/gnu/store/rkq6ipys8hf5hw66jkzzw4nfr6ncq96a-fontconfig-2.13.1
$ guix gc --references
/gnu/store/wsl1wy131kgnvlyaiv4hz6a6ysavkcr8-openjdk-12.33-jdk/ | grep font
/gnu/store/rkq6ipys8hf5hw66jkzzw4nfr6ncq96a-fontconfig-2.13.1
It looks like having the reference is not enough.
Going from the AdoptOpenJDK bug to
https://github.com/docker-library/openjdk/issues/46
leads to a bug report at debian's site:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793210
They talked about different configure flags in there icedtea package
and they have a fix for their JDK package.
Here my time is out for now and my next free time slot might come only
in two weeks. So, if someone else wants to look into this any earlier,
I don't mind :-)
Björn
pgp4rXF9AThaM.pgp
Description: OpenPGP digital signature
Re: Docker image not working
I don't think the docs are quite up to date, or perhaps refer to an older version of Docker. If I do: $ docker create system:0qjxd5ljsh316ki7wqkk2xz9b68lynh2 Error response from daemon: No command specified Looks like `docker create` wants the entry point, hence why I tried to use `docker run` to fire up the container ... so what should it be to kick off the Shepherd service you referred to? Thanks. On Thu, Nov 28, 2019 at 11:09 AM Maxim Cournoyer wrote: > Hello Stephen, > > Stephen Scheck writes: > > > Hello, > > > > I'm trying to use the `guix system` command to create a Docker image as > > documented here: > > > > > > > https://guix.gnu.org/manual/en/html_node/Invoking-guix-system.html#Invoking-guix-system > > > > However, the created image does not work: > > > > $ docker run -it system:0qjxd5ljsh316ki7wqkk2xz9b68lynh2 > > /run/current-system/profile/bin/bash --login > > docker: Error response from daemon: OCI runtime create failed: > > container_linux.go:348: starting container process caused "exec: > > \"/run/current-system/profile/bin/bash\": stat > > /run/current-system/profile/bin/bash: no such file or directory": > unknown. > > > > This is the command I invoked to create the image: > > > > guix system init --no-bootloader --skip-checks --system=x86_64-linux > > guix-docker.scm /tmp/guix/docker-image > > > > And here is the system configuration I used: > > > > (use-modules (gnu)) > > (use-package-modules admin base bash less linux) > > > > (operating-system > > (host-name "guix") > > (timezone "UTC") > > (locale "en_US.utf8") > > > > (bootloader (bootloader-configuration > > (bootloader grub-bootloader) > > (target "/dev/null"))) > > (file-systems (cons (file-system > > (device (file-system-label > "guix-system-dummy")) > > (mount-point "/") > > (type "ext4")) > > %base-file-systems)) > > > > (packages (append (list bash coreutils-minimal inetutils less > procps > > which) %base-packages))) > > > > Am I missing something? > > Yes! The /run/current-system/profile/bin/bash symlink you are trying to > invoke is setup by one of the Shepherd services when the Guix system is > initialized. Here the system hasn't booted up yet. Currently the > system is initialized as part of the default entry point produced by > Guix, but such initialization only spawns Shepherd as PID 1 and leaves > you with a useless, non-interactive session that is not useful when > simply running 'docker run -it $your-image'. > > The only useful way to use a docker-image currently is to "start" the > container, using > > docker start $container_id > > And then attaching to it with docker exec > > docker exec -ti $container_id /run/current-system/profile/bin/bash > --login > > This is explained in the documentation. > > I don't find this really convenient, and intend to modify the default > entry point at some point to allow running commands directly from > 'docker run', but currently it is the way it works. > > What I can recommend for very simple use cases (starting a script, bash, > etc), is to use 'docker pack -f docker' instead to produce the Docker > image. > > This command allows you to produce symlinks in the generated image, for > example: > > --8<---cut here---start->8--- > guix pack --manifest=your-manifest.scm \ >-f docker \ >-S /etc/profile=etc/profile \ >-S /bin=bin > --8<---cut here---end--->8--- > > Will set the /etc/profile, /bin and /sbin links in the target to that of > the profile generated from your-manifest.scm. > > You could then override the default entry point of the docker image with > a command such as: > > docker run -it $your_image /bin/bash --login > > This bash session should source /etc/profile and make all of your > manifest installed software available to experiment with. > > HTH! > > Maxim >
error: failed to load 'gnu/tests/install.scm': No such file or directory
Hi Guix, Today I have again been blocked by an error that I get occasionally when trying to run Guix from source. I follow the usual steps: - ./bootstrap - ./configure –localstatedir=/var - make until I see [ 48%] LOAD gnu/tests/guix.scm [ 48%] LOAD gnu/tests/monitoring.scm [ 48%] LOAD gnu/tests/nfs.scm [ 49%] LOAD gnu/tests/install.scm error: failed to load 'gnu/tests/install.scm': No such file or directory It always happens at the same point, it's always 'gnu/tests/install.scm', and yet there is nothing obviously wrong with that file (which definitely exists). >From experience, I know that in a few days, after updating Guix, it will work again, and then one day I'll run into the same bug once more. Is this a known problem? Better yet, with known solutions or workarounds? Cheers, Konrad.
Fwd: Packaging a cmake C++ header only library requiring C++17
Hello, nckd and I have gone back and forth over a few days in IRC trying to help me out here. I am trying to package magic-enum ( https://github.com/Neargye/magic_enum ) which is a C++ header only library requiring at least C++ 17, and uses the cmake build system. The problem which we can't figure out is why the compiler being used is the default for `gcc` at 7.4 while there is explicit use and dependency on `gcc` 9.2 via `gcc-9`. We're stumped. Attached are the latest package definitions, build log, and cli invocation and output. 0545hcvyz4p07jc5xz4crak2cvpxpv-magic-enum-0.6.3.drv.bz2 Description: application/bzip2 magic-enum.scm Description: Binary data stdout Description: Binary data
Re: Docker image not working
BTW, I saw your comments in the Docker/Guix relationship thread about using `guix pack` as an alternative means to produce a Docker image. I tried this also, but I had a few issues: 1) You have to pass it `-S /bin=bin -S /sbin=sbin` flags so that command binaries can be conveniently located. This is not really an issue, but I think it does "lock" the resulting image to a particular snapshot of command binaries, which might be precisely what you want for an immutable container for a production application. But for other use cases, for example, for throw-away containers for development and testing, you might want the capability of being able to upgrade packages, and it's not clear to me if it's just as simple as replacing the symlinks to the `bin` and `sbin` directories of a new profile. And also, I guess `guix environment` addresses that use case. 2) In order to get a lot of basic functionality working, I had to install a Guix System into a VM from the distribution ISO, then copy various bits of its `/etc` (protocols, services, nsswitch.conf, pam.d, etc.) tree into an image to get network diagnostics (ping, etc.) and user management commands, among others, working. It seems like leveraging the `guix system` infrastructure to build a working, reproducible, and standard `/etc` tree is the way to go, but as already noted I'm not having any luck with the Docker images it produces. On Wed, Nov 27, 2019 at 11:40 PM Stephen Scheck wrote: > No, it does not: > > $ docker run -it system:0qjxd5ljsh316ki7wqkk2xz9b68lynh2 bash > docker: Error response from daemon: OCI runtime create failed: > container_linux.go:348: starting container process caused "exec: \"bash\": > executable file not found in $PATH": unknown. > > It seems like some things which get set up when creating a regular system > via `guix system` do not when specifying output as a Docker image. > Unfortunately, the documentation doesn't explain much about how the system > profile works, and I'm not knowledgeable enough about Guix to make an > informed guess. > > On Wed, Nov 27, 2019 at 9:39 AM zimoun wrote: > >> Hi, >> >> On Sun, 17 Nov 2019 at 18:17, Stephen Scheck >> wrote: >> >> > $ docker run -it system:0qjxd5ljsh316ki7wqkk2xz9b68lynh2 >> > /run/current-system/profile/bin/bash --login >> > docker: Error response from daemon: OCI runtime create failed: >> > container_linux.go:348: starting container process caused "exec: >> > \"/run/current-system/profile/bin/bash\": stat >> > /run/current-system/profile/bin/bash: no such file or directory": >> unknown. >> >> Does the command >> >> docker run -it system:0qjxd5ljsh316ki7wqkk2xz9b68lynh2 bash >> >> work? >> >> >> All the best, >> simon >> >
Re: Docker image not working
Hello Stephen, Stephen Scheck writes: > Hello, > > I'm trying to use the `guix system` command to create a Docker image as > documented here: > > > https://guix.gnu.org/manual/en/html_node/Invoking-guix-system.html#Invoking-guix-system > > However, the created image does not work: > > $ docker run -it system:0qjxd5ljsh316ki7wqkk2xz9b68lynh2 > /run/current-system/profile/bin/bash --login > docker: Error response from daemon: OCI runtime create failed: > container_linux.go:348: starting container process caused "exec: > \"/run/current-system/profile/bin/bash\": stat > /run/current-system/profile/bin/bash: no such file or directory": unknown. > > This is the command I invoked to create the image: > > guix system init --no-bootloader --skip-checks --system=x86_64-linux > guix-docker.scm /tmp/guix/docker-image > > And here is the system configuration I used: > > (use-modules (gnu)) > (use-package-modules admin base bash less linux) > > (operating-system > (host-name "guix") > (timezone "UTC") > (locale "en_US.utf8") > > (bootloader (bootloader-configuration > (bootloader grub-bootloader) > (target "/dev/null"))) > (file-systems (cons (file-system > (device (file-system-label "guix-system-dummy")) > (mount-point "/") > (type "ext4")) > %base-file-systems)) > > (packages (append (list bash coreutils-minimal inetutils less procps > which) %base-packages))) > > Am I missing something? Yes! The /run/current-system/profile/bin/bash symlink you are trying to invoke is setup by one of the Shepherd services when the Guix system is initialized. Here the system hasn't booted up yet. Currently the system is initialized as part of the default entry point produced by Guix, but such initialization only spawns Shepherd as PID 1 and leaves you with a useless, non-interactive session that is not useful when simply running 'docker run -it $your-image'. The only useful way to use a docker-image currently is to "start" the container, using docker start $container_id And then attaching to it with docker exec docker exec -ti $container_id /run/current-system/profile/bin/bash --login This is explained in the documentation. I don't find this really convenient, and intend to modify the default entry point at some point to allow running commands directly from 'docker run', but currently it is the way it works. What I can recommend for very simple use cases (starting a script, bash, etc), is to use 'docker pack -f docker' instead to produce the Docker image. This command allows you to produce symlinks in the generated image, for example: --8<---cut here---start->8--- guix pack --manifest=your-manifest.scm \ -f docker \ -S /etc/profile=etc/profile \ -S /bin=bin --8<---cut here---end--->8--- Will set the /etc/profile, /bin and /sbin links in the target to that of the profile generated from your-manifest.scm. You could then override the default entry point of the docker image with a command such as: docker run -it $your_image /bin/bash --login This bash session should source /etc/profile and make all of your manifest installed software available to experiment with. HTH! Maxim
Re: [X-POST] patchwork.sourceware.org refresh
On 11/28/19 12:47 AM, Siddhesh Poyarekar wrote: > On 28/11/19 10:55 am, Maciej W. Rozycki wrote: >> Well, I've been using it to track the state my own patches submitted (and >> during the period of my active MIPS GDB port maintenance also for other >> people's submissions). > > Can you please take a snapshot of your state? > >> Is it actually necessary to destroy all the recorded state (not only for >> patches, but also for e-mail accounts linked, which AFAIK cannot be >> restored once you've lost access to any) just for an engine upgrade? >> That would be an odd requirement and ISTR at least one of the patchworks >> I've had an account with to have been seamlessly upgraded at one point. > > Hmm, I will try to do an in-place upgrade without actually deleting > anything. I can't promise that it will go well because we'll be > upgrading from a very ancient version and I don't know right now if the > schema has changed incompatibly. > > I'll do a backup too FWIW. When I looked at this the upgrade was *very* complicated, and carrying over the data from a version that is so old was going to be hard. >> Or do you have something else, i.e. not just an upgrade, in mind? > > To begin with, I intend to add hooks to close patchwork patches on merge > so that that aspect is automated. It was the one problem we had with > patchwork and with ChangeLogs gone in glibc, we're definitely a lot more > likely to get close to that goal. Agreed! For me as a reviewer, knowing what's up-to-date and ready for review, having a tool (like pwclient) to pull the patch and build a local branch from it, and then being able to use local diff tooling is really the key things to accelerate patch review for patches that don't require complex consensus. -- Cheers, Carlos.
