Arch Linux User Repository

@carsme currently there seems to be a bit of a mess with python 3.11 related packages on Arch32. So downgraded them all to the python 3.10 versions. After that I was able to build and run rdiff-backup 2.2.5-3 on my pentum4 (not i686 like I wrote earlier) Arch32 system.

@rwd2 I'm fairly certain you won't be able to cross-compile this, so I would focus on getting the PKGBUILD to work on your Arch Linux 32 system.

The wiki article is about packaging 32-bit software for other architectures, what you're trying to do is the opposite - packaging (potentially) 64-bit software for a 32-bit system. So you should avoid any of the instructions in it.

arch=(any) means that the built package is architecture independent, which is not the case for this package as it contains the shared library /usr/lib/python3.11/site-packages/rdiff_backup/C.cpython-311-x86_64-linux-gnu.so.

Try adding i686 to the arch array instead:

arch=(x86_64 i686)

Not sure this will fix your build issues though.

The log you posted seems to indicate something is wrong with the build process for Python. Could you check the versions of the components involved?

$ pacman -Q python-setuptools python-wheel python-build
python-setuptools 1:68.0.0-1
python-wheel 0.40.0-3
python-build 0.10.0-4

My suspicion is that this is unrelated to rdiff-backup and has to do with the Python packaging on Arch Linux 32. I've never packaged on a 32-bit system though so this is just a guess.

Let me know how it goes!

@carsme: I tried compiling on my arch32 system. I changed the value of arch in PKGBUILD to 'any', and then did a 'makepkg -rs'. I get errors, but they seem to be about the build environment rather than rdiff-backup : https://pastebin.com/A1Cc3u04. I will ask on the arch32 forums.

Would cross compiling on a x86_64 arch system be possible? I know 32 bit support was dropped in Ach so I can imagine the tools/libraries to do that are no longer there.

@rwd2 I'm not able to test that myself, but if you can test it and confirm that it works on i686 I'll add it arch.

Would it be possible to add i686 support as well? I am running an old version of rdiff-backup on arch32, and the package is about to be dropped from the repository.

Thank you for reporting and investigating the issues, @apocalyptech and @muesli4. Appreciate it!

To mitigate these I've:

• confirmed that building in a tmpfs causes some tests to fail and disabled these (testing/eas_aclstest.py and testing/fs_abilitiestest.py).
• applied the patch that should solve the timezone issue.

See be9bc4c16760 for further details.

Hopefully the package is buildable for you now, if not let me know.

I have test whether my filesystem does support them and can confirm. But I found that these are not the only errors. I created an issue in the project: https://github.com/rdiff-backup/rdiff-backup/issues/897

I see that those errors are both extended-attribute related. Do you happen to be building on a filesystem which doesn't support EAs / ACLs?

FWIW, after figuring out the timezone-related problems below, all the tests succeeded fine on my own machine, at least.

I got these test failures when building.

======================================================================
FAIL: testBasic (__main__.EATest.testBasic)
Test basic writing and reading of extended attributes
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/makepkg/rdiff-backup/src/rdiff-backup-2.2.5/testing/eas_aclstest.py", line 79, in testBasic
    self.assertEqual(new_ea.attr_dict, self.sample_ea.attr_dict)
AssertionError: {} != {b'user.empty': b'', b'user.not_empty': b'[1417 chars]xb1'}
Diff is 2186 characters long. Set self.maxDiff to None to see it.

======================================================================
FAIL: testIterate (__main__.EATest.testIterate)
Test writing several records and then reading them back
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/makepkg/rdiff-backup/src/rdiff-backup-2.2.5/testing/eas_aclstest.py", line 194, in testIterate
    self.assertEqual(sample_ea_reread, self.sample_ea)
AssertionError: <rdiff_backup.eas_acls.ExtendedAttributes object at 0x7fc415d85490> != <rdiffbackup.meta.ea.ExtendedAttributes object at 0x7fc416efbed0>

----------------------------------------------------------------------
Ran 20 tests in 11.944s

It is really scary to get these from a backup utility, especially when you needed a backup.

@LA-MJ - Ah yeah, the tests are very noisy and the output definitely includes some filenames with which they seemed to be testing various unicode-related conditions. I'd seen some filenames scroll past with some wild series-of-unintelligible-characters on 'em. On an en_US.UTF-8 console it doesn't actually screw up the whole terminal, but I'm not surprised that it could do so for other terms

@simon.wiles - Yeah, the path of least resistance is difficult to turn away from, for sure. :) Also makes sense why it was never caught before -- presumably the build machines for the main developers are all set to UTC (or postitive offsets), and I'm sure many folks building it manually either don't run the tests or ignore their output.