{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":146918141,"defaultBranch":"main","name":"toolbox","ownerLogin":"containers","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2018-08-31T16:39:29.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/5874934?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1726064773.0","currentOid":""},"activityList":{"items":[{"before":"d7bafb82ed9b3814ccaba5788501f429aa154278","after":"1d6b0b9136036c4fe4c11d5c171170cf983b8c2e","ref":"refs/heads/main","pushedAt":"2024-09-29T17:05:09.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"profile.d: Add whitespace padding to the PS1\n\nAdd an extra space after the ⬢ so things are less smooshed together.\n\nhttps://github.com/containers/toolbox/pull/1542","shortMessageHtmlLink":"profile.d: Add whitespace padding to the PS1"}},{"before":"fb9e2e7adec624ab172c2ede4ec7d4c4823147b5","after":"d7bafb82ed9b3814ccaba5788501f429aa154278","ref":"refs/heads/main","pushedAt":"2024-09-29T11:22:25.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"build: Make it build on loongarch64\n\nGo 1.19 added support for 64-bit LoongArch on Linux (GOOS=linux,\nGOARCH=loong64) [1], and the path of the dynamic linker (ie., PT_INTERP)\nwas taken from the ABI specification [2].\n\nTested by the Debian loong64 port [3].\n\n[1] https://tip.golang.org/doc/go1.19#loong64\n\n[2] https://sourceware.org/glibc/wiki/ABIList\n\n[3] https://buildd.debian.org/status/fetch.php?pkg=golang-github-containers-toolbox&arch=loong64&ver=0.0.99.3%2Bgit20230118%2B446d7bfdef6a-2.1&stamp=1722443115\n\nhttps://github.com/containers/toolbox/pull/1523","shortMessageHtmlLink":"build: Make it build on loongarch64"}},{"before":"987f5e259289b4b32609f91e8fef1e8379de399b","after":"fb9e2e7adec624ab172c2ede4ec7d4c4823147b5","ref":"refs/heads/main","pushedAt":"2024-09-29T11:21:09.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"test/system: Optimize the resource limits tests\n\nThe system tests can be very I/O intensive, because many of them copy\nOCI images from the test suite's image cache directory to its local\ncontainer/storage store, create containers, and then delete everything\nto run the next test with a clean slate.  This makes them slow.\n\nThe runtime environment tests, which includes the resource limit tests,\nare particularly slow because they don't skip the I/O even when testing\nerror handling.  This makes them a good target for optimizations.\n\nThe resource limit tests query the values for different resources from\nthe same default container without changing its state.  Therefore, a lot\nof disk I/O can be avoided by creating the default container only once\nfor all the tests.\n\nThis can save even 30 minutes.\n\nhttps://github.com/containers/toolbox/pull/1552","shortMessageHtmlLink":"test/system: Optimize the resource limits tests"}},{"before":"679bf87eb90a404deb32557b4617ab7431843513","after":"987f5e259289b4b32609f91e8fef1e8379de399b","ref":"refs/heads/main","pushedAt":"2024-09-28T11:04:35.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":".zuul, playbooks, test/system: Optimize the CI on Fedora nodes\n\nThe test suite has expanded to 415 system tests.  These tests can be\nvery I/O intensive, because many of them copy OCI images from the test\nsuite's image cache directory to its local container/storage store,\ncreate containers, and then delete everything to run the next test with\na clean slate.  This makes the system tests slow.\n\nUnfortunately, Zuul's max-job-timeout setting defaults to an upper limit\nof 3 hours or 10800 seconds for jobs [1], and this is what Software\nFactory uses [2].  So, there comes a point beyond which the CI can't be\nprevented from timing out by increasing the timeout.\n\nOne way of scaling past this maximum time limit is to run the tests in\nparallel across multiple nodes.  This has been implemented by splitting\nthe system tests into different groups, which are run separately by\ndifferent nodes.\n\nFirst, the tests were grouped into those that test commands and options\naccepted by the toolbox(1) binary, and those that test the runtime\nenvironment within the Toolbx containers.  The first group has more\ntests, but runs faster, because many of them test error handling and\ndon't do much I/O.\n\nThe runtime environment tests take especially long on Fedora Rawhide\nnodes, which are often slower than the stable Fedora nodes.  Possibly\nbecause Rawhide uses Linux kernels that are built with debugging\nenabled, which makes it slower.  Therefore, this group of tests were\nfurther split for Rawhide nodes by the Toolbx images they use.  Apart\nfrom reducing the number of tests in each group, this should also reduce\nthe amount of time spent in downloading the images.\n\nThe split has been implemented with Bats' tagging system that is\navailable from Bats 1.8.0 [3].  Fortunately, commit 87eaeea6f0c2b245\nalready added a dependency on Bats >= 1.10.0.  So, there's nothing to\nworry about.\n\nAt the moment, Bats doesn't expose the tags being used to run the test\nsuite to setup_suite() and teardown_suite() [4].  Therefore, the\nTOOLBX_TEST_SYSTEM_TAGS environment variable was used to optimize the\ncontents of setup_suite().\n\n[1] https://zuul-ci.org/docs/zuul/latest/tenants.html\n\n[2] Commit 83f28c52e47c2d44\n    https://github.com/containers/toolbox/commit/83f28c52e47c2d44\n    https://github.com/containers/toolbox/pull/1548\n\n[3] https://bats-core.readthedocs.io/en/stable/writing-tests.html\n\n[4] https://github.com/bats-core/bats-core/issues/1006\n\nhttps://github.com/containers/toolbox/pull/1551","shortMessageHtmlLink":".zuul, playbooks, test/system: Optimize the CI on Fedora nodes"}},{"before":"861cf8546e73bb2f92d888860148647dc98f6481","after":"679bf87eb90a404deb32557b4617ab7431843513","ref":"refs/heads/main","pushedAt":"2024-09-27T21:59:16.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":".zuul: Enable testing on Fedora 41\n\nhttps://github.com/containers/toolbox/pull/1550","shortMessageHtmlLink":".zuul: Enable testing on Fedora 41"}},{"before":"66280a617ae7eaa29113aeb8e76cbcee6ac04feb","after":"861cf8546e73bb2f92d888860148647dc98f6481","ref":"refs/heads/main","pushedAt":"2024-09-27T16:44:36.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"doc/toolbox: Clarify that Toolbx isn't a security mechanism\n\nUsing the word 'containerized' gives the false impression of heightened\nsecurity.  As if it's a mechanism to run untrusted software in a\nsandboxed environment without access to the user's private data (such as\n$HOME), hardware peripherals (such as cameras and microphones), etc..\nThat's not what Toolbx is for.\n\nToolbx aims to offer an interactive command line environment for\ndevelopment and troubleshooting the host operating system, without\nhaving to install software on the host.  That's all.  It makes no\npromise about security beyond what's already available in the usual\ncommand line environment on the host that everybody is familiar with.\n\nhttps://github.com/containers/toolbox/issues/1020","shortMessageHtmlLink":"doc/toolbox: Clarify that Toolbx isn't a security mechanism"}},{"before":"dd23baa29ac5ea58dba962ca48c38b35ee63808e","after":"66280a617ae7eaa29113aeb8e76cbcee6ac04feb","ref":"refs/heads/main","pushedAt":"2024-09-26T19:58:40.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"build: Use the same linker flags as NVIDIA Container Toolkit\n\nThe previous commit explains how the NVIDIA Container Toolkit is\nsensitive to some linker flags.  Therefore, use the same linker flags\nthat are used by NVIDIA Container Toolkit to build the nvidia-cdi-hook,\nnvidia-ctk, etc. binaries, because they use the same Go APIs that\ntoolbox(1) does [1].  It's better to use the same build configuration to\nprevent subtle bugs from creeping in.\n\n[1] NVIDIA Container Toolkit commit 772cf77dcc2347ce\n    https://github.com/NVIDIA/nvidia-container-toolkit/commit/772cf77dcc2347ce\n    https://github.com/NVIDIA/nvidia-container-toolkit/pull/333\n\nhttps://github.com/containers/toolbox/pull/1548","shortMessageHtmlLink":"build: Use the same linker flags as NVIDIA Container Toolkit"}},{"before":"f2dc3b8f63c00f7698d91183600435509c945baa","after":"dd23baa29ac5ea58dba962ca48c38b35ee63808e","ref":"refs/heads/main","pushedAt":"2024-09-20T20:01:09.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"cmd/initContainer, test/system: Handle NVIDIA's create-symlinks CDI hook\n\nNVIDIA Container Toolkit 0.16.0 started using create-symlinks hooks in\nthe Container Device Interface specification generated by it [1].  For\nexample:\n  \"hookName\": \"createContainer\",\n  \"path\": \"/usr/bin/nvidia-cdi-hook\",\n  \"args\": [\n    \"nvidia-cdi-hook\",\n    \"create-symlinks\",\n    \"--link\",\n    \"libnvidia-allocator.so.560.35.03::/usr/lib64/libnvidia-allocator.so.1\",\n    \"--link\",\n    \"../libnvidia-allocator.so.1::/usr/lib64/gbm/nvidia-drm_gbm.so\"\n  ]\n\nFallout from 649d02f8a6e1d3531324b571ce8a683b6989c41f\n\n[1] NVIDIA Container Toolkit commit aae3da88c33d9cf2\n    https://github.com/NVIDIA/nvidia-container-toolkit/commit/aae3da88c33d9cf2\n    https://github.com/NVIDIA/nvidia-container-toolkit/pull/548\n\nhttps://github.com/containers/toolbox/pull/1545","shortMessageHtmlLink":"cmd/initContainer, test/system: Handle NVIDIA's create-symlinks CDI hook"}},{"before":"9a87d15188bca749e99b6fd7a9cbcdf43b9368df","after":"f2dc3b8f63c00f7698d91183600435509c945baa","ref":"refs/heads/main","pushedAt":"2024-09-19T13:50:01.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":".zuul, test/system: Simplify line count checks by using Bats >= 1.10.0\n\nCommit 87eaeea6f0c2b245 already added a dependency on Bats >= 1.10.0,\nwhich is present on Fedora >= 39.  Therefore, it should be exploited\nwherever possible to simplify things.\n\nCurrently, the CI has been frequently timing out on stable Fedora nodes.\nSo, increase the timeout from 1 hour 50 minutes to 2 hours to avoid\nthat.\n\nFor what it's worth, the timeout for Fedora Rawhide nodes is 2 hours 10\nminutes and it seems enough.\n\nhttps://github.com/containers/toolbox/pull/1546","shortMessageHtmlLink":".zuul, test/system: Simplify line count checks by using Bats &gt;= 1.10.0"}},{"before":"c386a442f740d60b2bfa56cae48fa46ce243186a","after":"9a87d15188bca749e99b6fd7a9cbcdf43b9368df","ref":"refs/heads/main","pushedAt":"2024-09-17T17:13:44.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"cmd/initContainer: Unbreak application of CDI hooks for NVIDIA\n\nNVIDIA Container Toolkit 0.16.0 changed the hook arguments in the\nContainer Device Interface specification generated by it [1].\n\nFallout from 649d02f8a6e1d3531324b571ce8a683b6989c41f\n\n[1] NVIDIA Container Toolkit commit 179d8655f9b5fce6\n    https://github.com/NVIDIA/nvidia-container-toolkit/commit/179d8655f9b5fce6\n    https://github.com/NVIDIA/nvidia-container-toolkit/issues/435\n\nhttps://github.com/containers/toolbox/pull/1544","shortMessageHtmlLink":"cmd/initContainer: Unbreak application of CDI hooks for NVIDIA"}},{"before":"8dd2f8e80aad1b76659b44f20c346f75e647d65d","after":"c386a442f740d60b2bfa56cae48fa46ce243186a","ref":"refs/heads/main","pushedAt":"2024-09-17T17:10:56.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"cmd/initContainer: Log unknown Container Device Interface hook arguments\n\nNVIDIA Container Toolkit 0.16.0 changed the hook arguments in the\nContainer Device Interface specification generated by it [1].  Having\nthe unknown hook arguments show up in the debug logs makes it easier to\nunderstand what happened.\n\n[1] NVIDIA Container Toolkit commit 179d8655f9b5fce6\n    https://github.com/NVIDIA/nvidia-container-toolkit/commit/179d8655f9b5fce6\n    https://github.com/NVIDIA/nvidia-container-toolkit/issues/435\n\nhttps://github.com/containers/toolbox/pull/1543","shortMessageHtmlLink":"cmd/initContainer: Log unknown Container Device Interface hook arguments"}},{"before":"dcd4c4382c912f98c60e7abccc3de7aa8f786bdf","after":"8dd2f8e80aad1b76659b44f20c346f75e647d65d","ref":"refs/heads/main","pushedAt":"2024-09-16T00:11:51.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"cmd/run, pkg/nvidia: Detect mismatched NVIDIA kernel & user space driver\n\nThe proprietary NVIDIA driver has a kernel space part and a user space\npart, and they must always have the same matching version.  Sometimes,\nthe host operating system might end up with mismatched parts.  One\nreason could be that the different third-party repositories used to\ndistribute the driver might be incompatible with each other.  eg., in\nthe case of Fedora it could be RPM Fusion and NVIDIA's own repository.\n\nThis shows up in the systemd journal as:\n  $ journalctl --dmesg\n  ...\n  kernel: NVRM: API mismatch: the client has the version 555.58.02, but\n          NVRM: this kernel module has the version 560.35.03.  Please\n          NVRM: make sure that this kernel module and all NVIDIA driver\n          NVRM: components have the same version.\n  ...\n\nWithout any special handling of this scenario, users would be presented\nwith a very misleading error:\n  $ toolbox enter\n  Error: failed to get Container Device Interface containerEdits for\n      NVIDIA\n\nInstead, improve the error message to be more self-documenting:\n  $ toolbox enter\n  Error: the proprietary NVIDIA driver's kernel and user space don't\n      match\n  Check the host operating system and systemd journal.\n\nhttps://github.com/containers/toolbox/pull/1541","shortMessageHtmlLink":"cmd/run, pkg/nvidia: Detect mismatched NVIDIA kernel &amp; user space driver"}},{"before":"a653325279a0f63745f1cd8525e088794bcb3dff","after":"dcd4c4382c912f98c60e7abccc3de7aa8f786bdf","ref":"refs/heads/main","pushedAt":"2024-09-14T10:10:28.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"Foxboron","name":"Morten Linderud","path":"/Foxboron","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1042946?s=80&v=4"},"commit":{"message":"Add man pages and progress bars to Arch Linux image\n\nSigned-off-by: Amber Connelly <113668892+ac-z@users.noreply.github.com>","shortMessageHtmlLink":"Add man pages and progress bars to Arch Linux image"}},{"before":"a653325279a0f63745f1cd8525e088794bcb3dff","after":null,"ref":"refs/heads/mainn","pushedAt":"2024-09-11T14:26:13.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"}},{"before":"a8dd3c691c2e534aa56e158ed11715aeeb86a646","after":"a653325279a0f63745f1cd8525e088794bcb3dff","ref":"refs/heads/main","pushedAt":"2024-09-11T14:26:03.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"build: Bump github.com/NVIDIA/nvidia-container-toolkit to 1.16.1\n\nThe src/go.sum file was updated with 'go mod tidy'.\n\nhttps://github.com/containers/toolbox/pull/1540","shortMessageHtmlLink":"build: Bump github.com/NVIDIA/nvidia-container-toolkit to 1.16.1"}},{"before":null,"after":"a653325279a0f63745f1cd8525e088794bcb3dff","ref":"refs/heads/mainn","pushedAt":"2024-09-11T14:25:54.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"build: Bump github.com/NVIDIA/nvidia-container-toolkit to 1.16.1\n\nThe src/go.sum file was updated with 'go mod tidy'.\n\nhttps://github.com/containers/toolbox/pull/1540","shortMessageHtmlLink":"build: Bump github.com/NVIDIA/nvidia-container-toolkit to 1.16.1"}},{"before":"369781a6d615a9bc540b10fdd4c290e1485529c1","after":"a8dd3c691c2e534aa56e158ed11715aeeb86a646","ref":"refs/heads/main","pushedAt":"2024-09-11T13:32:10.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"build: Bump golang.org/x/sys to 0.22.0\n\nThe src/go.sum file was updated with 'go mod tidy'.\n\nhttps://github.com/containers/toolbox/pull/1539","shortMessageHtmlLink":"build: Bump golang.org/x/sys to 0.22.0"}},{"before":"26a76f2d7fcdc3af7c8ad23a8310975f61d30d8f","after":"369781a6d615a9bc540b10fdd4c290e1485529c1","ref":"refs/heads/main","pushedAt":"2024-09-10T21:05:53.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"test/system: Test attempts to create the same container twice\n\nhttps://github.com/containers/toolbox/issues/957","shortMessageHtmlLink":"test/system: Test attempts to create the same container twice"}},{"before":"d287588f3d0e7d74eb7512fd4dfe30a3485be7d4","after":"26a76f2d7fcdc3af7c8ad23a8310975f61d30d8f","ref":"refs/heads/main","pushedAt":"2024-09-10T18:18:45.000Z","pushType":"push","commitsCount":6,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"cmd/run, test/system: Handle exit code 127 in 'run' from forwarded call\n\nWhen 'toolbox run' is invoked on the host, an exit code of 127 from\n'podman exec' means either that the specified command couldn't be found\nor that the working directory didn't exist.  The only way to tell these\ntwo scenarios apart is to actually look inside the container.\n\nSecondly, Toolbx containers always have an executable toolbox(1) binary\nat /usr/bin/toolbox and it's assumed that /usr/bin is always part of the\nPATH environment variable.\n\nWhen 'toolbox run toolbox ...' is invoked, the inner toolbox(1)\ninvocation will be forwarded back to the host by the Toolbx container's\n/usr/bin/toolbox, which is always present as an executable.  Hence, if\nthe outer 'podman exec' on the host fails with an exit code of 127,\nthen it doesn't mean that the container didn't have a toolbox(1)\nexecutable, but that some subordinate process started by the container's\ntoolbox(1) failed with that exit code.\n\nTherefore, handle this as a special case to avoid losing the exit code.\nOtherwise, it leads to:\n  $ toolbox run toolbox run non-existent-command\n  bash: line 1: exec: non-existent-command: not found\n  Error: command non-existent-command not found in container\n      fedora-toolbox-40\n  $ echo \"$?\"\n  0\n\nInstead, it will now be:\n  $ toolbox run toolbox run non-existent-command\n  bash: line 1: exec: non-existent-command: not found\n  Error: command non-existent-command not found in container\n      fedora-toolbox-40\n  $ echo \"$?\"\n  127\n\nhttps://github.com/containers/toolbox/issues/957\nhttps://github.com/containers/toolbox/pull/1052","shortMessageHtmlLink":"cmd/run, test/system: Handle exit code 127 in 'run' from forwarded call"}},{"before":"76a8508019eb6ceef1a76002e768282931e49387","after":"d287588f3d0e7d74eb7512fd4dfe30a3485be7d4","ref":"refs/heads/main","pushedAt":"2024-09-10T17:53:11.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"cmd/root, cmd/run: Handle printing all errors but the CLI parsing ones\n\nThis will make it easier to propagate the exit codes of subordinate\nprocesses through an exitError instance, when toolbox(1) is invoked\ninside a container, and invocation is forwarded to the host.\n\nCobra doesn't honour the root command's SilenceErrors, if an error\noccurred when parsing the command line for a command, even though the\ncommand was found.  However, Cobra does honour SilenceErrors, if the\nerror occurred afterwards.\n\nTherefore, to avoid setting SilenceErrors in each and every command, it\nwas set in the PersistentPreRunE hook (ie., preRun), which is called\nafter all command line parsing has been successfully completed.\n\nhttps://github.com/containers/toolbox/issues/957","shortMessageHtmlLink":"cmd/root, cmd/run: Handle printing all errors but the CLI parsing ones"}},{"before":"62fcc093e7d9dbe2620835be7b30a7af61875ded","after":"76a8508019eb6ceef1a76002e768282931e49387","ref":"refs/heads/main","pushedAt":"2024-09-05T21:18:08.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"test/system: Test the output messages when a container is created\n\nhttps://github.com/containers/toolbox/pull/1536","shortMessageHtmlLink":"test/system: Test the output messages when a container is created"}},{"before":"c8c9e95ed05ec240f9d045bf18960ddd918e1482","after":"62fcc093e7d9dbe2620835be7b30a7af61875ded","ref":"refs/heads/main","pushedAt":"2024-09-03T21:15:56.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"pkg/utils, test/system: Retain errors without -v when forwarding to host\n\nhttps://github.com/containers/toolbox/issues/957\nhttps://github.com/containers/toolbox/pull/1052","shortMessageHtmlLink":"pkg/utils, test/system: Retain errors without -v when forwarding to host"}},{"before":"67d40024ce98451dffc738294a136b579ff295ad","after":"c8c9e95ed05ec240f9d045bf18960ddd918e1482","ref":"refs/heads/main","pushedAt":"2024-09-02T11:16:35.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"test/system: Test that CLI errors are shown inside Toolbx containers\n\nhttps://github.com/containers/toolbox/pull/1525","shortMessageHtmlLink":"test/system: Test that CLI errors are shown inside Toolbx containers"}},{"before":"3f359f3edd5699611a60c28fb826ad01c3745753","after":"67d40024ce98451dffc738294a136b579ff295ad","ref":"refs/heads/main","pushedAt":"2024-08-29T21:40:50.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"test/system: Consolidate teardown() to remove both containers & images\n\nIt's far more consistent and understandable if all tests start with a\nclean state without any containers or images present.  Otherwise, the\nsubtle side-effects of having some image left behind from a previous\ntest can lead to surprises, and there's no need to spend time wondering\nwhether some tests should only clean up the containers or both\ncontainers and images.\n\nThis additional work of cleaning up the images for all tests makes it\nnecessary to increase the timeout for all Fedora nodes to prevent the CI\nfrom timing out.\n\nhttps://github.com/containers/toolbox/pull/1526","shortMessageHtmlLink":"test/system: Consolidate teardown() to remove both containers &amp; images"}},{"before":"b684b190d1d931434d0d7d63c841973101dfb928","after":"3f359f3edd5699611a60c28fb826ad01c3745753","ref":"refs/heads/main","pushedAt":"2024-08-29T19:12:52.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"build: Bump tags.cncf.io/container-device-interface to v0.8.0\n\nThe src/go.sum file was updated with 'go mod tidy'.\n\nhttps://github.com/containers/toolbox/pull/1529","shortMessageHtmlLink":"build: Bump tags.cncf.io/container-device-interface to v0.8.0"}},{"before":"18d47d1fee9d894d68fb8f3c2937a4f2372ea8b6","after":"b684b190d1d931434d0d7d63c841973101dfb928","ref":"refs/heads/main","pushedAt":"2024-08-15T15:55:32.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":".zuul: Drop testing on Fedora 38\n\nFedora 38 reached End of Life on 21st May 2024:\nhttps://docs.fedoraproject.org/en-US/releases/eol/\n\nhttps://github.com/containers/toolbox/pull/1527","shortMessageHtmlLink":".zuul: Drop testing on Fedora 38"}},{"before":"cb6eee85ef88a0dc8694707d29737f61fa0ac330","after":"18d47d1fee9d894d68fb8f3c2937a4f2372ea8b6","ref":"refs/heads/main","pushedAt":"2024-07-31T18:10:39.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"test/system: Replace the RHEL toolbox:8.9 image with toolbox:8.10\n\nRed Hat Enterprise Linux 8.9 reached End of Life when RHEL 8.10 was\nreleased on 22nd May 2024:\nhttps://access.redhat.com/articles/3078\nhttps://access.redhat.com/support/policy/updates/errata\n\nFor what it's worth, RHEL 8's full support phase ended on the 31st of\nMay 2024 and it wil be in maintenance support, as RHEL 8.10, until the\ncorresponding day in 2029.\n\nhttps://github.com/containers/toolbox/pull/1522","shortMessageHtmlLink":"test/system: Replace the RHEL toolbox:8.9 image with toolbox:8.10"}},{"before":"6e848b250b4cde98fb9a40b17421f1f54eacd8f3","after":"cb6eee85ef88a0dc8694707d29737f61fa0ac330","ref":"refs/heads/main","pushedAt":"2024-06-18T08:43:49.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"README.md: Add GitHub star history chart\n\n... from https://star-history.com/.\n\nhttps://github.com/containers/toolbox/pull/1511","shortMessageHtmlLink":"README.md: Add GitHub star history chart"}},{"before":"ef98adbb7a9d48a68f89abf34d763ab302d1cdda","after":"6e848b250b4cde98fb9a40b17421f1f54eacd8f3","ref":"refs/heads/main","pushedAt":"2024-06-12T17:46:49.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"cmd, pkg/nvidia: Enable the proprietary NVIDIA driver\n\nThis uses the NVIDIA Container Toolkit [1] to generate a Container\nDevice Interface specification [2] on the host during the 'enter' and\n'run' commands.  The specification is saved as JSON in the runtime\ndirectories at /run/toolbox or $XDG_RUNTIME_DIR/toolbox to make it\navailable to the Toolbx container's entry point.  The environment\nvariables in the specification are directly passed to 'podman exec',\nwhile the hooks and mounts are handled by the entry point.\n\nToolbx containers already have access to all the devices in the host\noperating system's /dev, and containers share the kernel space driver\nwith the host.  So, this is only about making the user space driver\navailable to the container.  It's done by bind mounting the files\nmentioned in the generated CDI specification from the host to the\ncontainer, and then updating the container's dynamic linker cache.\n\nThis neither depends on 'nvidia-ctk cdi generate' to generate the\nContainer Device Interface specification nor on 'podman create --device'\nto consume it.\n\nThe main problem with nvidia-ctk and 'podman create' is that the\nspecification must be saved in /etc/cdi or /var/run/cdi, both of which\nrequire root access, for it to be visible to 'podman create --device'.\nToolbx containers are often used rootless, so requiring root privileges\nfor hardware support, something that's not necessary on the host, will\nbe a problem.\n\nSecondly, updating the toolbox(1) binary won't let existing containers\nuse the proprietary NVIDIA driver, because 'podman create' only affects\nnew containers.\n\nTherefore, toolbox(1) uses the Go APIs used by 'nvidia-ctk cdi generate'\nand 'podman create --device' to generate, save, load and apply the CDI\nspecification itself.  This removes the need for root privileges due to\n/etc/cdi or /var/run/cdi, and makes the driver available to existing\ncontainers.\n\nUntil Bats 1.10.0, 'run --keep-empty-lines' had a bug where it counted\nthe trailing newline on the last line as a separate line [3].  However,\nBats 1.10.0 is only available in Fedora >= 39 and is absent from Fedora\n38.\n\nBased on an idea from Ievgen Popovych.\n\n[1] https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/\n    https://github.com/NVIDIA/nvidia-container-toolkit\n\n[2] https://github.com/cncf-tags/container-device-interface\n\n[3] Bats commit 6648e2143bffb933\n    https://github.com/bats-core/bats-core/commit/6648e2143bffb933\n    https://github.com/bats-core/bats-core/issues/708\n\nhttps://github.com/containers/toolbox/issues/116","shortMessageHtmlLink":"cmd, pkg/nvidia: Enable the proprietary NVIDIA driver"}},{"before":"d9cdfe80d9da867056fd27223ead466a10a6609e","after":"ef98adbb7a9d48a68f89abf34d763ab302d1cdda","ref":"refs/heads/main","pushedAt":"2024-06-11T23:20:02.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"debarshiray","name":"Debarshi Ray","path":"/debarshiray","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3208107?s=80&v=4"},"commit":{"message":"playbooks: Avoid using potentially broken DNF5\n\nThe Zuul executor got updated from Ansible 2.13.7 to 2.15.10, which now\nhas support for DNF5 [1] and the previous DNF5 Change [2] for Fedora 39\nis now aiming at Fedora 41 (and Rawhide) [3].  Unfortunately, Ansible's\n'dnf5' module is still under development and doesn't seem to match the\nstate of DNF5 in Fedora Rawhide, which causes:\n  TASK [Install RPM packages]\n  fedora-rawhide | ERROR\n  fedora-rawhide | {\n  fedora-rawhide |   \"failures\": [],\n  fedora-rawhide |   \"msg\": \"Could not import the libdnf5 python module\n      using /usr/bin/python3 (3.12.3 (main, Apr 17 2024, 00:00:00) [GCC\n      14.0.1 20240411 (Red Hat 14.0.1-0)]). Please install\n      python3-libdnf5 package or ensure you have specified the correct\n      ansible_python_interpreter. (attempted\n      ['/usr/libexec/platform-python', '/usr/bin/python3',\n      '/usr/bin/python2', '/usr/bin/python'])\"\n  fedora-rawhide | }\n\nTrying to explicitly install python3-libdnf5, as suggested above, using\nAnsible's 'command' module before using the 'package' module to install\nthe Toolbx dependencies, still ends up with:\n  TASK [Install RPM packages]\n  fedora-rawhide | MODULE FAILURE:\n  fedora-rawhide | Traceback (most recent call last):\n  fedora-rawhide |   File \"<stdin>\", line 107, in <module>\n  fedora-rawhide |   File \"<stdin>\", line 99, in _ansiballz_main\n  fedora-rawhide |   File \"<stdin>\", line 47, in invoke_module\n  fedora-rawhide |   File \"<frozen runpy>\", line 226, in run_module\n  fedora-rawhide |   File \"<frozen runpy>\", line 98, in _run_module_code\n  fedora-rawhide |   File \"<frozen runpy>\", line 88, in _run_code\n  fedora-rawhide |   File \"/tmp/ansible_ansible.legacy.dnf5_payload_kecazv78/ansible_ansible.legacy.dnf5_payload.zip/ansible/modules/dnf5.py\",\n      line 708, in <module>\n  fedora-rawhide |   File \"/tmp/ansible_ansible.legacy.dnf5_payload_kecazv78/ansible_ansible.legacy.dnf5_payload.zip/ansible/modules/dnf5.py\",\n      line 704, in main\n  fedora-rawhide |   File \"/tmp/ansible_ansible.legacy.dnf5_payload_kecazv78/ansible_ansible.legacy.dnf5_payload.zip/ansible/modules/dnf5.py\",\n      line 487, in run\n  fedora-rawhide | AttributeError: 'Base' object has no attribute\n      'load_config_from_file'\n\nTherefore, force the use of DNF4 when an Ansible job is being attempted\nmore than once [4].\n\n[1] Ansible commit a81b787a05100986\n    https://github.com/ansible/ansible/commit/a81b787a05100986\n    https://github.com/ansible/ansible/issues/78898\n\n[2] https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5\n\n[3] https://fedoraproject.org/wiki/Changes/SwitchToDnf5\n\n[4] https://zuul-ci.org/docs/zuul/latest/job-content.html#var-zuul.attempts\n\nhttps://github.com/containers/toolbox/pull/1509","shortMessageHtmlLink":"playbooks: Avoid using potentially broken DNF5"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"startCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0yOVQxNzowNTowOS4wMDAwMDBazwAAAATD-B7v","endCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wNi0xMVQyMzoyMDowMi4wMDAwMDBazwAAAARivEPm"}},"title":"Activity · containers/toolbox"}