The decisions of when to mark messages read in notmuch-show has caused
confusion/irritation (several discussions on irc and the mailing list
eg the thread starting at id:87hadi0xse.fsf@boo.workgroup). This is an
attempt to get some logic that people are happier with.
Some examples of the current p
The following code, when linked with libnotmuch.a and libutil.a does a
passable imitation of sha1sum on amd64 (and I guess also i386) but
computes a different digest on powerpc and probably sparc and s390x.
In the long run we should maybe outsource hash computations to
e.g. librhash, but I'd like
David Bremner writes:
> The following code, when linked with libnotmuch.a and libutil.a does a
> passable imitation of sha1sum on amd64 (and I guess also i386) but
> computes a different digest on powerpc and probably sparc and s390x.
>
> In the long run we should maybe outsource hash computation
0.17~rc1 is failing several crypto tests on debian/kfreebsd [1]
FAIL signature verification
--- crypto.2.expected 2013-11-24 04:17:13.0 +
+++ crypto.2.output 2013-11-24 04:17:13.0 +
@@ -11,7 +11,7 @@
Ben Gamari writes:
> Signed-off-by: Ben Gamari
> ---
> NEWS | 8
> 1 file changed, 8 insertions(+)
pushed.
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
On Sun, Nov 24 2013, David Bremner wrote:
> The following code, when linked with libnotmuch.a and libutil.a does a
> passable imitation of sha1sum on amd64 (and I guess also i386) but
> computes a different digest on powerpc and probably sparc and s390x.
>
> In the long run we should maybe outsou
On Sun, Nov 24 2013, Austin Clements wrote:
> Support for dirent.d_type is OS-specific. Previously, we used
> _DIRENT_HAVE_D_TYPE to detect support for this, but this is apparently
> a glic-ism (FreeBSD, for example, supports d_type, but does not define
> this). Since there's no cross-platform
From: David Bremner
Previously PLATFORM_BYTE_ORDER and IS_LITTLE_ENDIAN were not defined,
so the little endian code was always compiled in.
This will have the effect that the "SHA1s" on big endian architectures
will change (i.e. become actual sha1s). So someone re-indexing their
database could c
From: David Bremner
We could give more details about how to migrate tags, but I'm not sure
that it's a practical problem, or just a theoretical one.
---
NEWS | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index 3383ecf..31c6284 100644
--- a/NEWS
++
Quoth da...@tethera.net on Nov 24 at 5:29 pm:
> From: David Bremner
>
> We could give more details about how to migrate tags, but I'm not sure
> that it's a practical problem, or just a theoretical one.
> ---
> NEWS | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> dif
The decisions of when to mark messages read in notmuch-show has caused
confusion/irritation (several discussions on irc and the mailing list
eg the thread starting at id:87hadi0xse.fsf at boo.workgroup). This is an
attempt to get some logic that people are happier with.
Some examples of the curren
The following code, when linked with libnotmuch.a and libutil.a does a
passable imitation of sha1sum on amd64 (and I guess also i386) but
computes a different digest on powerpc and probably sparc and s390x.
In the long run we should maybe outsource hash computations to
e.g. librhash, but I'd like
David Bremner writes:
> The following code, when linked with libnotmuch.a and libutil.a does a
> passable imitation of sha1sum on amd64 (and I guess also i386) but
> computes a different digest on powerpc and probably sparc and s390x.
>
> In the long run we should maybe outsource hash computation
0.17~rc1 is failing several crypto tests on debian/kfreebsd [1]
FAIL signature verification
--- crypto.2.expected 2013-11-24 04:17:13.0 +
+++ crypto.2.output 2013-11-24 04:17:13.0 +
@@ -11,7 +11,7 @@
Ben Gamari writes:
> Signed-off-by: Ben Gamari
> ---
> NEWS | 8
> 1 file changed, 8 insertions(+)
pushed.
d
On Sun, Nov 24 2013, David Bremner wrote:
> The following code, when linked with libnotmuch.a and libutil.a does a
> passable imitation of sha1sum on amd64 (and I guess also i386) but
> computes a different digest on powerpc and probably sparc and s390x.
>
> In the long run we should maybe outsou
On Sun, Nov 24 2013, Austin Clements wrote:
> Support for dirent.d_type is OS-specific. Previously, we used
> _DIRENT_HAVE_D_TYPE to detect support for this, but this is apparently
> a glic-ism (FreeBSD, for example, supports d_type, but does not define
> this). Since there's no cross-platform
From: David Bremner
Previously PLATFORM_BYTE_ORDER and IS_LITTLE_ENDIAN were not defined,
so the little endian code was always compiled in.
This will have the effect that the "SHA1s" on big endian architectures
will change (i.e. become actual sha1s). So someone re-indexing their
database could c
From: David Bremner
We could give more details about how to migrate tags, but I'm not sure
that it's a practical problem, or just a theoretical one.
---
NEWS | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index 3383ecf..31c6284 100644
--- a/NEWS
++
Quoth david at tethera.net on Nov 24 at 5:29 pm:
> From: David Bremner
>
> We could give more details about how to migrate tags, but I'm not sure
> that it's a practical problem, or just a theoretical one.
> ---
> NEWS | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
>
20 matches
Mail list logo