softwarefactory-project-zuul[bot]
commented
5 months ago Build failed. https://softwarefactory-project.io/zuul/t/local/buildset/2f138d5bb11b44728ee5993a6aa52a18
:heavy_check_mark: unit-test SUCCESS in 5m 09s :heavy_check_mark: unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 24s :heavy_check_mark: unit-test-restricted SUCCESS in 4m 08s :x: system-test-fedora-rawhide FAILURE in 33m 12s :x: system-test-fedora-39 FAILURE in 32m 10s :x: system-test-fedora-38 FAILURE in 28m 34s
debarshiray
This is meant to make the project more searchable on the Internet. More and more people have been pointing out that "toolbox" is terribly difficult to search for, and it's impossible to find any decent Internet real estate by that name.
Some exceptions:
The code repository is still https://github.com/containers/toolbox. It will be renamed after giving a heads-up to other contributors.
The name of the binary is still
toolbox. The name is embedded into existing Toolbx containers as their entry point, which is bind mounted from the host operating system when the containers are started. Trivially renaming the binary will prevent these containers from starting.For similar reasons, the
TOOLBOX_PATHenvironment variable is still the same.For similar reasons, the
profile.dfile to be read by the shell on start-up is still calledtoolbox.sh.The label used to identify Toolbx containers and images is still called
com.github.containers.toolbox. There are many existing Toolbx containers, and many Toolbx images beyond the control of the Toolbx project that use this label to identity themselves. Simply renaming the label will prevent these containers and images from being recognized.The names of the built-in Toolbx images still retain the word
toolbox. Images under the new name need to be published on the OCI registries and thetoolbox(1)binary needs to be taught to handle both old and new names, wherever necessary, for backwards compatibility.The stamp file used to identify Toolbx containers is still called
/run/.toolboxenvbecause it's used by various external programs and users to identify Toolbx containers.The OSC 777 escape sequence to track and preserve the user's current Toolbx container [1] still emits
toolboxas the name of the container runtime. Changing the escape sequence can break terminal emulation applications, like Prompt [2], that consume it. Hence, it needs to be done carefully.The runtime directories at
/run/toolbox, when used as root, and$XDG_RUNTIME_DIR/toolbox, when used rootless, weren't renamed.When used as root,
/run/toolboxis embedded into existing Toolbx containers as a bind mount from the host. Trivially renaming the path will prevent these containers from starting.Secondly, both these paths are used to synchronize container start-up. If the paths are trivially renamed, and the
toolbox(1)binary is updated and used without stopping all existing containers, then it won't be able to enter containers that were already started. Strictly speaking, this scenario isn't supported, since updates are always expected to be offline [3]. However, it's worth noting because solving the previous problem might also address this.The configuration file for RPM is still called
/usr/lib/rpm/macros.d/macros.toolbox.[1] https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/17
[2] https://gitlab.gnome.org/chergert/prompt
[3] https://www.freedesktop.org/software/systemd/man/latest/systemd.offline-updates.html
https://github.com/containers/toolbox/issues/1399