Fix Build Dependency for Docker

[PatrickChenHZ]

Allow latest version/release to build in Docker.
Latest Revision require ffmpeg 7 to get libavcodec 61. Which means base image must be updated to ubuntu 24.10.

[MackBambu]

Allow latest version/release to build in Docker. Latest Revision require ffmpeg 7 to get libavcodec 61. Which means base image must be updated to ubuntu 24.10.

Isn't ffmpeg being built from source in docker?

[PatrickChenHZ]

Allow latest version/release to build in Docker. Latest Revision require ffmpeg 7 to get libavcodec 61. Which means base image must be updated to ubuntu 24.10.

Isn't ffmpeg being built from source in docker?

Apparently not, when not explicitly installing FFMPEG it would complain libavcodec61 not found at runtime(build linux and therfore docker build would finish and report success). And when running with old dockerfile with ubuntu 22.04 the installed FFMPEG would not allign with version 61, as libavcodec61 require FFPMEG7 which is not supported on ubuntu 22

[MackBambu]

#5252

[PatrickChenHZ]

Given the nature and purpose of docker containers, I personally think it makes more sense to workaround the issue through building stage then adding unnecessary and potentially confusing arguments for runtime.

[MackBambu]

Given the nature and purpose of docker containers, I personally think it makes more sense to workaround the issue through building stage then adding unnecessary and potentially confusing arguments for runtime.

Agree

@PatrickChenHZ Make the suggested changes, and then it can be merged. Thank you!

[PatrickChenHZ]

Updated accordingly, please review.
Thanks!

[MackBambu]

@PatrickChenHZ Did you review my improvement suggestions?
1.Remove the dependency on the bc command, as it is no longer needed.
2.Use libwebkit2gtk-4.1-dev, which is available by default in the Ubuntu 24 repository.

[PatrickChenHZ]

@MackBambu Sorry, maybe I missed something but I couldn't see the suggestions beyond what was mentioned in the linked issue in either file review section nor file comments.

Just made suggested changes. Please review!

Thanks!

[MackBambu]

@calh
hi calh，Could you please help review this PR? I tried building and running this container, and encountered the same issue as #1530 . Thank you!

[MackBambu]

@calh
hi calh，Could you please help review this PR? I tried building and running this container, and encountered the same issue as #1530 . Thank you!

[calh]

Other than a small nitpick, looks good

[PatrickChenHZ]

@MackBambu
Thanks for reviewing. The Issue in #1530 is not really Glib(At least I believe so, we might have different logging level enabled), I could replicate (I believe) the same behavior and got

./DockerRun.sh 
+ docker run --net=host --ipc host -u chen2465 -v /home/chen2465:/home/chen2465 -v /home/chen2465/.Xauthority:/root/.Xauthority -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=:1 --privileged=true -ti --rm bambustudio
[2024-12-31 04:23:43.922421] [0x00007052a5a5c480] [trace]   Initializing StaticPrintConfigs
add font of HarmonyOS_Sans_SC_Bold returns 1
add font of HarmonyOS_Sans_SC_Regular returns 1
[2024-12-31 04:23:44.136297] [0x00007052a5a5c480] [error]   boost::filesystem::create_directory: No such file or directory [system:2]: "/home/ubuntu/.config/BambuStudio"


(process:1): GLib-GObject-CRITICAL **: 04:23:44.136: invalid (NULL) pointer instance

(process:1): GLib-GObject-CRITICAL **: 04:23:44.136: g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

in which the actual error of interest is

[2024-12-31 04:23:44.136297] [0x00007052a5a5c480] [error]   boost::filesystem::create_directory: No such file or directory [system:2]: "/home/ubuntu/.config/BambuStudio"

I included some debugging suggestions in the DockerRun.sh File in the previous commits that should help navigate around this. I did not edit them directly as different environment would have different results(related to Docker Daemon UID and your user UID), so I left it in its simplest form. It will also depend on if there is BambuStudio already on the host OS as it tries to access the config from the host. Though thus far the most universal DockerRun.sh form(which forcefully overwrites the container UID) is as below

#!/bin/bash
set -x
# Just in case, here's some other things that might help:
#  Force the container's hostname to be the same as your workstation
#  -h $HOSTNAME \
#  If there's problems with the X display, try this
#  -v /tmp/.X11-unix:/tmp/.X11-unix \
#  or 
#  -v $HOME/.Xauthority:/root/.Xauthority \
#  You also need to run "xhost +" on your host system
# Bambu Studio also require the parent directory for the configuration directory to be present to start
#  which means it is important to make sure user is passed to container correctly
#  if the following configuration does not work with error: "boost::filesystem::create_directory: No such file or directory"
#  try replacing -u line with 
#  -u $(id -u ${USER}):$(id -g ${USER}) \
#  and add 
#  -e HOME=/home/$USER \
docker run \
  `# Use the hosts networking.  Printer wifi and also dbus communication` \
  --net=host \
  `# Some X installs will not have permissions to talk to sockets for shared memory` \
  --ipc host \
  `# Run as your workstations username to keep permissions the same` \
  -u $USER \
  `# Bind mount your home directory into the container for loading/saving files` \
  -v $HOME:/home/$USER \
  -v $HOME/.Xauthority:/root/.Xauthority \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e HOME=/home/$USER \
  -u $(id -u ${USER}):$(id -g ${USER}) \
  `# Pass the X display number to the container` \
  -e DISPLAY=$DISPLAY \
  `# It seems that libGL and dbus things need privileged mode` \
  --privileged=true \
  `# Attach tty for running bambu with command line things` \
  -ti \
  `# Remove container when it is finished` \
  --rm \
  `# Pass all parameters from this script to the bambu ENTRYPOINT binary` \
  bambustudio $* 

I've tested this in a fresh Ubuntu VM and it works fine. You do have to run

xhost +

outside the container for GUI to work, else CLI commands works perfectly.

Please let me know if the above DockerRun.sh helps addressing the problem and if I should just make this the default.

Thank you @calh I did make another commit that removed Bash from DockerFile and also addressed another potential building issue.

[MackBambu]

@PatrickChenHZ
When building the image, the UID and GID conflicted, and I had to modify USER=ubuntu in Dockerbuild.sh.

------
 > [12/12] RUN if [ "1000" != "0" ]; then       groupadd -f -g 1000 muck &&       useradd -u 1000 -g 1000 muck;     fi:
0.293 useradd: UID 1000 is not unique
------

 1 warning found (use --debug to expand):
 - WorkdirRelativePath: Relative workdir "BambuStudio" can have unexpected results if the base image changes (line 64)
Dockerfile:91
--------------------
  90 |     ARG GID=0
  91 | >>> RUN if [ "$UID" != "0" ]; then \
  92 | >>>       groupadd -f -g $GID $USER && \
  93 | >>>       useradd -u $UID -g $GID $USER; \
  94 | >>>     fi
  95 |     
--------------------
ERROR: failed to solve: process "/bin/bash -l -c if [ \"$UID\" != \"0\" ]; then       groupadd -f -g $GID $USER &&       useradd -u $UID -g $GID $USER;     fi" did not complete successfully: exit code: 4

Please let me know if the above DockerRun.sh helps addressing the problem and if I should just make this the default.

These parameters are very effective, and now I can run normally on the VM ! Do they only apply in VM environments? Can they work properly in non-VM environments?

[PatrickChenHZ]

@MackBambu

These parameters apply outside a VM as well, it works perfectly on my ubuntu and Arch workstations and all other non-VM machines I've tested on(something around 30 machines). I mentioned VM only because I wanted to test in a clean environment to make sure it is not working just because some configs on my workstations.

The user ID issue is known and yet also entirely environment-dependant. Please try to pull the latest commit from my fork, the bug fix I mentioned in the last comment is to fix this building issue. Though its more of a omit warning than a fix. It just adds the -o/--non-unique to line 93 to ignore the error. It will work in certain environment but not others(out of the box with provided DockerRun.sh) in my fork. In all other cases by using the DockerRun.sh I attached above(aka just adding all the suggested arguments in the DockerRun.sh comment section) it will just bypass all possible problems.

I am working on an actual fix to this problem as opposed to just omitting the errors. I expect to make a push today. I will leave a comment once that's done. I make extensive use of containerized Bambu Studio in our production environment so I do see this error showing up quite often, and I believe I found the fix for it.

Thanks!