We were using a template setup.py which parsed __init__.py in complex
ways just to find out the version number. Simply import notmuch and use
__VERSION__ directly. Also adapt some wording and setup.py values while
going through.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Unfortunately Robin Green's patch 52e4dedf9a was lost when I created
gen-version-script.sh. This merges his changes manually into that
script. It turns out tabs seem not needed in version script
files, so I simplified a bit and removed the printf.
Thanks to Alexander Botero-Lowry for help and testing.
This prevents unsafe calls to decode for return value None in
get_authors/get_subject which would current throw an Exception. Original
patch modified by Sebastian Spaeth.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
len() exhausts the tag iterator and e.g. list() or "".join(tags)
implicitly call len() if existing and then failing. So, we remove
Tags.__len__().
If you need to know the number of tags a message has, do use
len(list(tags)). It would be nicer to be able to support len() directly...
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
If we try to pull a non-existing tag, Tags._get will return None and the
appended .decode() command will fail. So make sure that there is a tag to
be fetched before fetching it.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
In case, search_threads returns an error we are supposed to throw an
Exception. But we did not "raise" it, this was an oversight and this
commit fixes it.
There is still the problem that there is often output to stderr by
libnotmuch detailing the xapian error and this is simply printed
out. But this requires fixing at the libnotmuch level...
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
This is a lighter weight version of the release target, intended to
support uploading release candidates to Debian.
As a side effect, filter ~ out of VERSION to make tag names.
If the notmuch.sym target does not explicitly depend on $(libnotmuch_modules),
gen-version-script.sh may be run before all the .o files are created, for
example when doing a parallel build on a machine with many cores.
Conflicts:
lib/Makefile.local
The conflicts are from three kinds of commits not merged into release:
- typo fixes
- removal of debug output
- fix for CLEAN rule
That were never merged into the release branch.
This allows, e.g. gitpkg debian/0.x-1 to do the right thing. It also
helps enforce the convention that Debian upload -1 is identical to the
release tarball.
This generates a seperate notmuch-0.x.debian.tar.gz containing
./debian.
In the initial release this is redundant, but for Debian only updates
between releases, this allows updating the contents of ./debian, and
using the rest of the release tarball.
This supports both testing and use by non-upload privileged
users. Along with previous commits in the series, this lets one do a
dry run of the release process and created a tarball, signature file,
and release announcement to inspect before uploading.
The previous setup was dependent on the git-buildpackage configuration
to find the resulting tar file, and consequently a bit fragile.
We use pristine-tar instead to save a checksum-identical copy of the
tar file. This will also faciliate "non-native" debian packages, if
desired.
dput again depends on the local configuration, and mainly is a bit too
brave for me to do automatically.
The reasoning is that we might have some error in the build system
that causes something not to be rebuilt; this would potentially have
the tests run on the wrong version of the code.
The idea is to see if the version we are already releasing exists on
the notmuch website. Using wget allows more people to run this target,
and also allows people with ssh access to run it without access to
their keys.
There is concensus to use non-native version number for updates that
contain only Debian changes. Unfortunately changing back and forth
between native and non-native packages has the potential for
confusion, since the archive will end up with notmuch-0.x.tar.gz and
notmuch-0.x.orig.tar.gz. So we use non-native numbering from the
beginning.
The lack of such exporting seems to cause problems catching
exceptions, as suggested by
http://gcc.gnu.org/wiki/Visibility
This manifested in the symbol-hiding test failing when notmuch was
compile with gcc 4.4.5. On i386, this further manifested as notmuch
new failing to run (crashing with an uncaught exception on first run).
The vim front-end isn't written to handle nested parts.
This patch doesn't change that, it just changes the code to pretend that
multipart/* sections end immediately. This makes the parsing code think that
all sections are top-level, and are thus parsed well enough.
The lovely result of this is that citation folds and signature folds now work
in text/plain parts that are within multipart/* sections. Also, all mime
section starts are now shown correctly (before some were not parsed and showed
the ugly ^L and an ID and so on from notmuch.)
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Also change a passed parameter to be consistent with the current binding. This
parameter appears to be unused.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
This patch rewrites the reformatting of the from list so it shows full
capitalized names when available (without truncating them as the old code did)
and removes the pipe characters that appear between some names.
The old code appears to assume from list (the list of senders in the thread)
coming from notmuch would be e-mail addresses, but in this version it is mostly
full names. Also in this version, the names are sometimes separated by pipe
instead of comma.
For consistency with old versions, names are still truncated at the first
period. Perhaps they shouldn't be though.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
In vim, in the message view, space is supposed to remove the "unread" and
"inbox" tags, but was sometimes adding them instead.
This patch assures that they are always removed by this binding.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
