platform / os testers wanted

[ThomasWaldmann]

anything except 64bit linux. enter your hardware and OS platform if you'ld like to regularly help with testing.

[lfam]

I can test on armv7 / Allwinner A20 (https://linux-sunxi.org/Cubietech_Cubieboard2) running Debian 8.

[parttimenerd]

I can test it on a 32bit linux.

Update: I actually meant 32bit linux on an x86 cpu

[ThomasWaldmann]

@lfam tests on arm are welcome! I can also test now and then on a raspberry pi2, but it is not my development machine.

@parttimenerd testing 32bit is very welcome, except my rpi2 I don't have a 32bit OS any more.

[jumper444]

Cygwin on 32bit Windows XP machine. (Soon to be Windows 10. Been holding out a long time)

When you say 'regularly' test my response is a bit vague.
With all the changes you are making and how it is going to break compatibility...I've just been hanging back until something is otherwise running on the standard linux/unix platforms first and then I will go through it with Cygwin. Since Cygwin is a patch to get something that is otherwise working on 'standard' Posix machines onto windows it would seem to me that my help will be a 2nd level of testing after the first level passes (Like I did with Attic earlier).

NOTE: I would like to write Cygwin/Windows documentation for the project when it's ready to go. I want people who otherwise mostly use Windows to know - line by line - how to install 'what is this thing cygwin??' and "what do I type just to get it to work." It's a great utility and I scoured the internet to find/use it. I would like to help others who might say 'well..it isn't a point and click exe, so next...'

[ThomasWaldmann]

@jumper444 tests on windows are welcome, too.

Just notice that windows is officially unsupported. Cygwin should somehow work though except the stuff that is known-missing for windows (ACLs, NTFS streams, maybe other).

If there are easy-to-fix compat bugs for cygwin, we can just fix them. Stuff that requires very big / global changes will have to be seen (I'ld rather not spoil the whole code with windows code).

[jumper444]

You might not remember, but that was my first posting on Attic site. I had encountered the software but it didn't run on Windows. I went through the code following the errors and eventually hacked a couple lines which were failing because it didn't recognize (or work) on Cygwin (even though logically everything else was mostly ok...minus obvious problems like ACLs, etc).

You came along a few days later made similar changes (but properly/professionally) to the project. I then tested those changes and replied that they looked good with no problems and that has been the status since.

So....yes, by your help (thanks) we got basic file saving/restoring in Cygwin and to the extent that Borg is a fork post those changes (and that nothing has broken it since) it should still work on that platform. Like I said I'll try it out again and put borg through various tests, but I will wait for it to bake a bit more on Linux/Unix first.

[ThomasWaldmann]

Yeah, I remember now. The stuff from back then is in borg.

About docs: we currently have rather small instruction for debian-like and fedora-like dists. I'ld appreciate similar docs for other systems, but keep scope in mind, the focus should be on installing borg and its dependencies.

[ThomasWaldmann]

https://paste.thinkmo.de/eetnEd46#borgbackup-0.23.0+21.g3303619-cp34-cp34m-macosx_10_10_x86_64.whl

I just built a binary wheel for Mac OS X 10.10 (Python 3.4) from current git master branch.

[ThomasWaldmann]

https://paste.thinkmo.de/YEaVTMDk#borgbackup-0.23.0+15.g2944bbe-cp34-cp34m-cygwin_2_0_4_x86_64.whl

I just built a binary wheel for cygwin 64bit Python 3.4 from current git master branch.

[ThomasWaldmann]

btw, the reason why I made these wheel packages is for testing:

• whether they work
• how compatible they are (try them on slightly different platforms also)

I built them on Python 3.4 and:

• OS X 10.10 (try on other OS X)
• Ubuntu Linux 14.04 64bit (try on other 64bit Linuxes)
• Windows 10 Preview 64bit with cygwin (try on other 64bit Windozes with cygwin)

Installing works like this: have python3.4 and pip(3) installed, then use: pip install borgbackup-xxxxx.whl

Then please report back what worked and what not.

[parttimenerd]

Installing works on 15.04 x64 linux.

[ghost]

Installs and works fine on Debian sid/unstable amd64.

[ThomasWaldmann]

BTW, if somebody wants to build a wheel: get the source from git, make it work (see docs) and then:

pip install --upgrade pip
pip install wheel
python setup.py bdist_wheel
ls -l dist/*.whl

[rawtaz]

FYI, I got this when trying the OS X 10.10 wheel on OS X 10.9.5:

$ pip3 install borgbackup-0.23.0+21.g3303619-cp34-cp34m-macosx_10_10_x86_64.whl
borgbackup-0.23.0+21.g3303619-cp34-cp34m-macosx_10_10_x86_64.whl is not a supported wheel on this platform.

[ThomasWaldmann]

Note: https://travis-ci.org/borgbackup/borg now tests linux and (new) OS X.

[ThomasWaldmann]

https://paste.thinkmo.de/aqsjg4fu#borgbackup-0.24.list
^ 0.24 release source code (+ signature)
^ binary wheel for linux x86_64 (+signature)
^ binary wheel for linux armv7el (+signature) e.g. raspberry pi2

[ThomasWaldmann]

@parttimenerd @jumper444 the current master branch code has some changes related to 32bit platforms in the C code (see #178). It would be good to test these, carefully.

I did some quick tests on 32bit arm v7, but x86 windows and linux would be more important.

If you want to help testing, make sure your backup data contains some files >>4GiB and verify if they get backed up / extracted correctly.

[jumper444]

Understood.
Might not be able to get to it for a while.
Last activity for me was Attic and I stepped back to let Borg settle
down from the fork. Certainly I will give it a test cycle before using
Borg and will keep the 4G test specifically in mind.

[lfam]

It worked for me on 32-bit linux.

I put 4097 mebibytes of urandom in a file.

$ dd bs=1M count=4097 if=/dev/urandom > file

Then:

$ sha256sum file > hash
$ borg init repo
$ borg create repo::file_$(date +%s) ~/tmp/file
$ cd restore && borg extract ~/repo::file_1441687000 home/user/tmp/file
$ cat ~/hash | sha256sum -c
file: OK

I did a few backup and restore cycles while using split to shuffle the data around and adding random bytes in the middle. Everything worked.

Here is some information about the system. It does not have PAE.

$ lscpu
Architecture:          i686
CPU op-mode(s):        32-bit
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 13
Stepping:              6
CPU MHz:               600.000
BogoMIPS:              1196.11

I might be able to use a newer kernel if you need it. I used the first old ISO that worked because the current Debian's base kernel isn't usable on this machine (I think this is the bug: https://bugzilla.kernel.org/show_bug.cgi?id=79261 ).

$ uname -a
Linux hostname 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:40:43 UTC 2013 i686 i686 i386 GNU/Linux

[ThomasWaldmann]

See #214 - the binaries definitely need more testing.

[ThomasWaldmann]

As we have Vagrant based testing now, everything in Vagrantfile can run the automated tests rather easily now. So, most UNIXoid platforms, 32 and 64bit are covered.

Non-x86 stuff and windows/cygwin is not yet covered by Vagrant.

For feedback about issues found while practically testing it, just open new issues.

I'm closing this ticket now, because I think it is clear that practical testing and unit testing is needed and feedback is welcome, but we don't need this ticket for that.