https://bugs.kde.org/show_bug.cgi?id=397837

            Bug ID: 397837
           Summary: Dockerfile has wrong permissions in container and
                    unset variable in script.
           Product: rust-qt-binding-generator
           Version: unspecified
          Platform: Other
                OS: Linux
            Status: UNCONFIRMED
          Severity: minor
          Priority: NOR
         Component: general
          Assignee: j...@vandenoever.info
          Reporter: der.andreas.pf...@googlemail.com
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to