Bug 397837 - Dockerfile has wrong permissions in container and unset variable in script.
Summary: Dockerfile has wrong permissions in container and unset variable in script.
Status: RESOLVED WORKSFORME
Alias: None
Product: rust-qt-binding-generator
Classification: Unmaintained
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Other Linux
: NOR minor
Target Milestone: ---
Assignee: Jos van den Oever
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-24 13:59 UTC by Andreas Pfeil
Modified: 2018-09-18 17:54 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Pfeil 2018-08-24 13:59:43 UTC
I'm new with docker but took the opportunity of compiling the binding generator ant it's templates according to your blog post, to finally use docker. I encountered two problems. I fixed both for me, but I'm not sure if it is the proper way.

First thing is that the mounted directories and the `WORKDIR /home/neon` in the container belonged to root. This is why neon was unable to compile since cargo could not access it's lock files. Instead of making neon a sudoer or something, I decided to modify the Dockerfile to set the permissions of the Working-directory recursively:

```
...
# extras
...
RUN useradd neon

WORKDIR /home/neon

RUN chown --recursive neon:neon ../neon

USER neon

CMD ["/bin/bash", "-l"]
```

As I said I have no Idea whether this is good practice. The second problem I encountered is that the environment variable XDG_CURRENT_DESKTOP was not set inside the script. I could not find out why, so I fixed it dirty by setting it in the script to ubuntu:GNOME (which is the content of the variable on my system).

After those two fixes, I was able to compile everything properly using the container. Note that I might have used the script different than intended:

1. I started the script with sudo, since this is the way I currently use docker (I read that it's also possible to add my user to the docker group). I didn't try that because `sudo echo $XDG_CURRENT_DESKTOP` was set up properly.

2. I use fish as my default/login shell, not bash. The variable is correctly set in /usr/bin/env bash, though. So I'm not sure if this could have been a problem. But still, it's an "unusual" anomaly that may have influence on how things work out for me.
Comment 1 Andreas Pfeil 2018-08-24 19:30:55 UTC
I seems my fix does not work. I first tried it with using USER root, which worked, I assume that I ran into a caching issue or so... I can't really explain it. Nevertheless, while my fix may be garbage, the problem exists.
Comment 2 Andreas Pfeil 2018-08-24 19:46:59 UTC
Okay so, I can't reproduce the error. When I used the container first, everything was belonging to root (everything that was mounted). But now it's not. I'm pretty confused and hope you can still take something out of my problem. I switched back to the way it was and was able to compile the binding generator and the qt_quick template. I still get the error on the todo example, though:

neon@b51d670d6440:~/rust_qt_binding_generator/examples/todos/build$ make
[ 10%] Generating ../rust/target/release/librust.a
error: failed to load source for a dependency on `libc`

Caused by:
  Unable to update registry `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to open: /home/neon/.cargo/registry/index/github.com-1ecc6299db9ec823/.cargo-index-lock

Caused by:
  Permission denied (os error 13)
CMakeFiles/rust_target.dir/build.make:62: recipe for target '../rust/target/release/librust.a' failed
make[2]: *** [../rust/target/release/librust.a] Error 101
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/rust_target.dir/all' failed
make[1]: *** [CMakeFiles/rust_target.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
neon@b51d670d6440:~/rust_qt_binding_generator/examples/todos/build$
Comment 3 Andreas Pfeil 2018-08-25 19:51:28 UTC
Okay, so, a fix is to add the user to the docker group [1]. I can't really say why, though.

[1]: https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user
Comment 4 Jos van den Oever 2018-09-18 17:54:38 UTC
Did you try running the docker container via docker-bash-session.sh
That script sets XDG_CURRENT_DESKTOP