borgbackup 1.2.0 update built with no problems. However it has been reported on the forum that it is not working. https://community.ipfire.org/t/borgbackup-dependency-broken/8113 Running any borg command such as borg -h for example gives the following errors. Traceback (most recent call last): File "/usr/bin/borg", line 33, in <module> sys.exit(load_entry_point('borgbackup==1.2.0', 'console_scripts', 'borg')()) File "/usr/bin/borg", line 22, in importlib_load_entry_point for entry_point in distribution(dist_name).entry_points File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 919, in distribution return Distribution.from_name(distribution_name) File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 518, in from_name raise PackageNotFoundError(name) importlib.metadata.PackageNotFoundError: No package metadata was found for borgbackup
Bug confirmed on my IPFire vm systems with borgbackup installed. Checked borgbackup 1.2.0 on Arch Linux system and borg -h gives help screen, so the problem is not related specifically to the version number. Compared with Arch Linux installation and found that python-msgpack is installed on their system as a required dependency. Found requirements file that listed dependencies and msgpack is included there. This must be a run time dependency as the build completed successfully without any errors and without mentioning msgpack. running build of borgbackup with python3-msgpack also installed and will test addon in a vm setup.
msgpack is or was bundled with borgbackup for many versions. It is not 100% clear but it looks like it may now need to be included again, although there is a msgpack.py file in the helpers section of the borgbackup source tarball. Just in case I built python3-msgpack version 1.0.3 borgbackup specifies that msgpack<=1.0.3 Then on a vm I installed python3-pkgconfig using pakfire. Then I copied the .ipfire packages for python3-msgpack and borgbackup onto the vm machine from the build machine. Then python3-msgpack was extracted and installed followed by borgbackup. No difference to running borg -h Will do a test of going back to the previous version, 1.1.17, of borgbackup to confirm it still works in CU168
I think I have figured things out. By running a chroot shell in my IPFire build I ran borg -h and borg -V and got a reply. This was with python3-msgpack built. Repeating this with no python3-msgpack resulted in a different error message which said that python-msgpack module was not found. So there was no metadata issue when running in the chroot shell. In this case all the python borgbackup directories have been installed in the python site-packages directory. In a normal install then only the packages listed in the rootfile are installed. Reading up about the import.metadata library I found that it gets its information from a file(s) in the egg-info directory. In the borgbackup-1.2.0 release these files were commented out in the rootfile and hence not available when borgbackup was installed. Checking back with earlier versions of borgbackup these files were not commented out. That was an error I made when I did the 1.2.0 update of borgbackup. I will now organise a build which includes python3-msgpack and with the egg-info files not commented out in the rootfile and see how that build and installs on my vm.
Modifying the borgbackup rootfile to include the egg-info directory files has made the importlib.metadata error message to disappear. @michael also suggested that the egg-info files needed to be present. So the old error message disappeared but a new one occurred. Missing module packaging. python3-packaging was added with borgbackup-1.2.0 but only for the build. It is clear from the latest error message that it is also required for execution. New build with python3-packaging having the .py files uncommented and moved from common to packages directory under rootfiles. Also added as another dependency for borgbackup in the lfs file.
I have now successfully built, installed and run borgbackup. I tested out initialising a backup repo and then carried out two backups to it. All went successfully. Will now create a patch and submit it to the dev mailing list.
Patch series submitted to dev mailing list and to patchwork. https://patchwork.ipfire.org/project/ipfire/list/?series=2922
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=c9336f7a1f7f8293012b4a23db941039f9572b4c https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=006309eaafb66136193356fc73bf0e5a63ab199e https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=de6ef4d40adec7e1093b73c4397f042e830db15e Excellent, thank you for taking care of this.
https://blog.ipfire.org/post/ipfire-2-27-core-update-169-is-available-for-testing
I have upgraded a CU168 vm to CU169 and created a borgbackup repo and ran two backups. I also extracted the backups as tar archives and was able to confirm their correctness. So borgbackup is working fine for a fresh install in CU169.
Excellent - thank you for reporting back.
https://blog.ipfire.org/post/ipfire-2-27-core-update-169-released