The patch was to add the O_LARGEFILE option fo several I/O calls in its core/adb/sysdeps.h file/
I find myself wondering why this fix hasn't even arrived in sid yet, as far as I can tell. It appears to be a serious bug, since it's possible that someone might thingk he has performed a backup and find, when it's time to restore, that it is seriously defective. Not something that should languish in limbo. I downloaded the source package, applied the patches, installed it, and then finally was able to back up my Transformer TF101. I haven't been able to test whether the backup can be restored, not having a spare Android device to restore it to. I hope someone with more hardware hsd performed this test. WHile applying the patches, I looked up the option O_LARGEFILE, just to check that I understood what the patch did. I discovered that it is not a standard option. And one source (http://stackoverflow.com/questions/2888425/is-o-largefile-needed-just-to-write-a-large-file) said it should not be used. Instead, one is to add -D_FILE_OFFSET_BITS=64 to CFLAGS, and " you'll never have to worry about anything". Now this looks like is something that should be in Debian's standard package build system, since the problem potentially affects every package that reads and writes files. I'd welcome the arrival of the present patches in testing, just so I don't have to maintain my own variant of the package, but it seems there's a more general problem to be solved with package builds. Where do I report this? (For the record, I'm doing this on a 32-bit intel system running jessie that places the backup on an NSF-mounted volume that resides on a AMD64 server running 64-bit wheezy.) -- hendrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
