Bug#667979: libtokyocabinet9: TokyoCabinet got endianness in DB wrong on both big- and little-endian architectures

2012-04-25 Thread coldtobi
Package: libtokyocabinet9 Followup-For: Bug #667979 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tagging this wontfix / help-needed, as currently I have no feasible way to resolve this, but to heavily patch tokyocabinet. Of course, I'm open to other approaches which we might have missed...

Bug#667979: libtokyocabinet9: TokyoCabinet got endianness in DB wrong on both big- and little-endian architectures

2012-04-11 Thread Tobias Frost
Well... I'm still waiting for the answer from upstream, but if you are right (and I fear you are) changing the behaviour would break other applications, and I do not believe that this would be wise. Moreless we would need an migration path, like patching tokyocabinet to automatically detect

Bug#667979: libtokyocabinet9: TokyoCabinet got endianness in DB wrong on both big- and little-endian architectures

2012-04-11 Thread Mikhail Gusarov
Tobias, Twas brillig at 08:28:53 11.04.2012 UTC+02 when t...@frost.de did gyre and gimble: TF I'm still waiting for the answer from upstream, but if you are TF right (and I fear you are) changing the behaviour would break other TF applications, and I do not believe that this would be wise.

Bug#667979: libtokyocabinet9: TokyoCabinet got endianness in DB wrong on both big- and little-endian architectures

2012-04-09 Thread Mikhail Gusarov
Hi. I would revert to upstream's default and use native endianness. Having a endian-neutral databases is be nice, but given it is not a upstream's goal anyway, I'd stick to upstream and avoid introducing incompatibilities. -- pgp4wg5sz66EM.pgp Description: PGP signature

Bug#667979: libtokyocabinet9: TokyoCabinet got endianness in DB wrong on both big- and little-endian architectures

2012-04-09 Thread Tobias Frost
Package: libtokyocabinet9 Followup-For: Bug #667979 Updaea after some research on this topic. In particular I was puzzled if the change on the endianess breaks exsitings database files, but this seems not the case, as http:/fallabs.com/tokyocabinet/spex-en.html tells quote Because database files

Bug#667979: libtokyocabinet9: TokyoCabinet got endianness in DB wrong on both big- and little-endian architectures

2012-04-09 Thread Mikhail Gusarov
Hi. Upstream Tokyo Cabinet uses little-endian data in databases and hence the databases are portable. After disabling the switch database format will not change for big-endian machines, but *will* for little-endian ones, so existing databases on little-endian machines will become unreadable and

Bug#667979: libtokyocabinet9: TokyoCabinet got endianness in DB wrong on both big- and little-endian architectures

2012-04-08 Thread Tobias Frost
Package: libtokyocabinet9 Followup-For: Bug #667979 Hallo Mikhail, thanks for reporting this issue. Always enable swab of course seems not not make sense, however I cannot tell the reasons of the then-maintainer. Basically we have three options here: 1) Go for little-endian for all archs 2) Go

Bug#667979: libtokyocabinet9: TokyoCabinet got endianness in DB wrong on both big- and little-endian architectures

2012-04-07 Thread Mikhail Gusarov
Package: libtokyocabinet9 Version: 1.4.47-1 Severity: important TokyoCabinet under Debian unconditionally uses --enable-swab option, which has the following two effects: - It forces tcucodec conf to say that the machine is big-endian (wrong). - It enforces the *non-native* data endianness in DB