Hi,

Derek Scherger wrote:
> I've made this change

Cool, thanks.

> and also moved sqlite to the Attic 

..oops, looks like we've done duplicate work. I've just committed and
pushed what I have. It's not quite complete, yet (rev
4c625e162bf17c69406de23482187313dafd29cd). Have you pushed your work, yet?

> which went much
> more smoothly than I was expecting since it involved upgrading from 3.4.2 to
> 3.5.9. One test fails with this later change, fail_cleanly_on_unreadable_db,
> which I assume is an actual change in sqlite behaviour but I'm not certain
> of this.

Yes, Ralf S. Engelschall has noted that before, see my other mail.

I've tested my variant against sqlite 3.3.8 (included in debian etch),
3.5.9 (debian testing, IIRC) and 3.6.3 (current stable release). These
tests fail:


sqlite 3.3.8:

146 database_check                                FAIL (line 23)
192 empty_environment                             FAIL (line 29)
203 fail_cleanly_on_unreadable_db                 unexpected success
216 i_selector                                    FAIL (line 32)

(does not have the 'hex()' function, but obviously works like we expect
for 'fail_cleanly_on_unreadable_db')


sqlite 3.5.9:

192 empty_environment                             FAIL (line 29)
203 fail_cleanly_on_unreadable_db                 FAIL (line 62)

sqlite 3.6.3:

192 empty_environment                             FAIL (line 29)
203 fail_cleanly_on_unreadable_db                 FAIL (line 62)


The 'empty_environment' test fails due to LD_LIBRARY_PATH required for
building against libraries in non-standard locations.

> I'm now looking at idna (libidn) which ought to be easy but isn't because of
> some changes that were made at the 2007 summit iirc. Lapo, do you recall the
> "best effort" stuff that got added to idna/toutf8.c? This is not in idna 1.5
> but I'm wondering if maybe idna 1.5 might just do the right thing?

Okay, so I let you take care of libidn. If you don't mind, I'll follow
the sqlite things and try to fix those tests. Certainly not today,
though.  ... just trying to avoid duplicate work...

Regards

Markus Wanner



_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Reply via email to