v4.4.28

Release notes

Changes

• Fixed a race-condition which could make any program-call (run_program, run_program_argsasarray and everything which is based on them) return an empty stdout and stderr although the program produced output and terminated with exitcode 0. The reading of the output stopped as soon as the process was terminated and the internal queues were empty, without checking whether the reader-threads had transferred the content of the pipes into those queues at all, so the output of short-running programs could be discarded completely. The problem occurred mainly on linux and under load, for example in a ci-pipeline
• Added the possibility to declare the credentials of an OCI-registry as environment-variables (OCIRegistry_<registryname>_Address, OCIRegistry_<registryname>_Username and OCIRegistry_<registryname>_Password), analogous to the declaration of a package-source. Until now the credentials could only be configured in ~/.ScriptCollection/GlobalCache/RegistryCredentials.csv, which is part of the configuration-folder of the user and is therefore not available inside a locally started build-container, so a build in a container could not pull an image of a registry which requires authentication (pull access denied [...] no basic auth credentials). The declared credentials are used for the docker-login as well as for the requests to the registry-api
• Added that the fallback-registry of the repository (<repository>/.ScriptCollection/OCIImages/ImageDefinition.csv) is not only used when no custom registry is defined for an image in ~/.ScriptCollection/GlobalCache/OCIImages/ImageRegistries.csv, but also when the custom registry does not provide the image (because it is not reachable, because it does not contain the image or because the available credentials do not permit the access). Whether the custom registry provides the image is checked by inspecting the manifest of the image once per image and process; a warning which names the reason is logged when the fallback-registry is used
• Fixed sync_xlf2_files leaving the source-text of a translation-unit of a messages.<language>.xlf-file at the state it had when the unit was created: the sync only added units which were missing in a language-file and removed units which the base-file did not contain anymore, so a unit which exists on both sides was never touched again and kept an outdated source-text forever once the text of that unit changed in messages.xlf. The source-text of such a unit is now taken over from the base-file, and a unit whose source-text changed goes back to the state "initial" - a target which was translated from the previous source-text is not a translation of the new one, so it has to be translated again - while its <target> is kept, so that a translation which was written by a human is still there until a new one was created for the new source-text