Re: [PATCH 1/5] debian/control: build-depend on python3-sphinx instead of python-sphinx
On Thu, Nov 30 2017, Daniel Kahn Gillmor wrote:
> On Thu 2017-11-30 04:40:39 -0500, Daniel Kahn Gillmor wrote:
>> python2 is going to be deprecated, and python3-sphinx is available all
>> the way back to oldoldstable. let's use the more modern version.
>> ---
>> debian/control | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/debian/control b/debian/control
>> index 20b8a2db..3a624fdc 100644
>> --- a/debian/control
>> +++ b/debian/control
>> @@ -18,7 +18,7 @@ Build-Depends:
>> python3-all (>= 3.1.2-7~),
>> dh-python,
>> dh-elpa (>= 1.3),
>> - python-sphinx (>= 1.0),
>> + python3-sphinx,
>> ruby, ruby-dev (>>1:1.9.3~),
>> emacs25-nox | emacs25 (>=25~) | emacs25-lucid (>=25~) |
>> emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~) |
>
> hm, on further reflection, this one is specifically problematic because
> of the use of:
>
> ${python} -m sphinx.writers.manpage
>
> in ./configure, used to test for the presence of the sphinx module.
>
> This can be fixed by preferring python3 here:
>
> --- a/configure
> +++ b/configure
> @@ -557,7 +557,7 @@ fi
> printf "Checking for python... "
> have_python=0
>
> -for name in ${PYTHON} python python2 python3; do
> +for name in ${PYTHON} python3 python python2; do
> if command -v $name > /dev/null; then
> have_python=1
> python=$name
>
> any thoughts or preferences on this?
I'd like this change. I was going to suggest "${PYTHON}" there
but perhaps if one sets e.g.
PYTHON='/usr/local/bin/python3 -B -E -u'
The above would still work (I'd say this is potentially more useful
than supporting whitespace in paths).
Tomi
>
> --dkg
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] cli/help: give a hint about notmuch-emacs-mua
On Thu, Nov 30 2017, Daniel Kahn Gillmor wrote: > On Thu 2017-11-30 11:08:05 +0200, Tomi Ollila wrote: >> On Thu, Nov 30 2017, Daniel Kahn Gillmor wrote: >> >>> On Thu 2017-10-26 18:27:51 -0400, Daniel Kahn Gillmor wrote: "notmuch help" doesn't mention "notmuch-emacs-mua" even though we support it through the try_external_command() mechanism. In addition, "notmuch help emacs-mua" doesn't work, even though we ship the appropriate manpage. This changeset fixes both of these problems. >>> >>> Ping! i don't think this patch is complex or objectionable. Can it be >>> merged? >> >> it may (*) look like we don't have #if WITH_EMACS (**) cpp macros defined ??? >> >> Tomi >> >> (*) did not check... >> >> (**) this is emacs-specific stull, less generic that other hints (if that >> matters) ... >> >> Sorry to cause confusion... > > confusion is right! i don't understand what you're saying, sorry. are > you suggesting a different change somehow? Want to propose a different > patch? My thought was that even though user may compile notmuch without emacs support (and notmuch-emacs-mua not installed) we would be hinting `notmuch emacs-mua` command to exist. Tomi > >--dkg ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: unbreak performance tests
On Sat, Dec 02 2017, David Bremner wrote:
> In 8e7fb88237aedea22 Jani replaced the use of $(pwd -P) to find the
> TEST_DIRECTORY in order to better support out of tree
> builds. Unfortunately the performance-tests need a different value for
> the variable and were thus broken.
>
> This commit splits out the setting of this variable for the two sets
> of tests. Performance tests still don't work out of tree, because
> the handling of the downloaded corpus needs to be updated.
Change fine by me.
Tomi
> ---
> performance-test/perf-test-lib.sh | 3 +++
> test/test-lib-common.sh | 4
> test/test-lib.sh | 3 +++
> 3 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/performance-test/perf-test-lib.sh
> b/performance-test/perf-test-lib.sh
> index 56538abd..b70288cc 100644
> --- a/performance-test/perf-test-lib.sh
> +++ b/performance-test/perf-test-lib.sh
> @@ -29,6 +29,9 @@ done
> # Ensure NOTMUCH_SRCDIR and NOTMUCH_BUILDDIR are set.
> . $(dirname "$0")/../test/export-dirs.sh || exit 1
>
> +# Where to run the tests
> +TEST_DIRECTORY=$NOTMUCH_BUILDDIR/performance-test
> +
> . "$NOTMUCH_SRCDIR/test/test-lib-common.sh" || exit 1
>
> set -e
> diff --git a/test/test-lib-common.sh b/test/test-lib-common.sh
> index 6c3571d4..2f7950ac 100644
> --- a/test/test-lib-common.sh
> +++ b/test/test-lib-common.sh
> @@ -41,10 +41,6 @@ restore_database () {
> cp -pR $TMP_DIRECTORY/notmuch-dir-backup."${test_name}"
> ${MAIL_DIR}/.notmuch
> }
>
> -# Test the binaries we have just built. The tests are kept in
> -# test/ subdirectory and are run in 'trash directory' subdirectory.
> -TEST_DIRECTORY=$NOTMUCH_BUILDDIR/test
> -
> # Prepend $TEST_DIRECTORY/../lib to LD_LIBRARY_PATH, to make tests work
> # on systems where ../notmuch depends on LD_LIBRARY_PATH.
> LD_LIBRARY_PATH=${TEST_DIRECTORY%/*}/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
> diff --git a/test/test-lib.sh b/test/test-lib.sh
> index 42a45f15..4c8607a1 100644
> --- a/test/test-lib.sh
> +++ b/test/test-lib.sh
> @@ -1066,6 +1066,9 @@ test_init_ () {
> }
>
>
> +# Where to run the tests
> +TEST_DIRECTORY=$NOTMUCH_BUILDDIR/test
> +
> . "$NOTMUCH_SRCDIR/test/test-lib-common.sh" || exit 1
>
> if [ "${NOTMUCH_GMIME_MAJOR}" = 3 ]; then
> --
> 2.15.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: DRAFT Introduce CFFI-based Python bindings
On Wed, Nov 29 2017, Floris Bruynooghe wrote: > David Bremner writes: > >> Floris Bruynooghe writes: >> >>> >>> Lastly there are some downsides to the choices I made: >>> - I ended up going squarely for CPython 3.6+. Choosing Python >>> 3 allowed better API design, e.g. with keyword-only parameters >>> etc. Choosing CPython 3.4+ restricts the madness that can >>> happen with __del__ and gives some newer (tho now unused) >>> features in weakref.finalizer. >>> - This is no longer drop-in compatible. >>> - I haven't got to a stage where my initial goal of speed has >>> been proven yet. >> >> I guess you'll have to convince the maintainers / users of alot and afew >> that this makes sense before we go much further. I'd point out that >> Debian stable is only at python 3.5, so that makes me a bit wary of this >> (being able to run the test suite on debian stable and similar aged >> distros useful for me, and I suspect other developers). >> >> I know there are issues with memory management in the current bindings, >> so that may be a strong reason to push to python 3.6; it seems to need >> more investigation at the moment. > > So on earlier Python versions, sure this is possible at not too much > cost. > > - Python 3.4+ would just cost the use of some f-strings. Not major, was > just nice to use. > - Python <3.4 afaik would only need a tweak to the Database.tags and > Message.tags properties. I *think* swapping the caching of these > using a weakref should suffice and not break the brittle > Python-libnotmuch memory management. > Mind you I think Python 3.0-3.3 are pretty old and not much point in > supporting them. But this would also apply for 2.7 support. > - Python 2.7 is probably the worst, in that keyword-only arguments would > be gone. If python 2.7 is required I'd be much keener to have another > go at a drop-in replacement with the memory safety features and then > build the "notdb" API on top off it. But for that to be worth it > people need to be convinced enough that maintaining a CFFI version is > nicer than a ctypes version I guess. IMO Python 3.4+ would be OK, if python 2 support can be dropped. Even Ubuntu 14.04 has python 3.4. One notable distribution that has Python 3.3 by default is RHEL 7, but there seems to be quite a few packaged alternatives available... > > Kind regards, > Floris Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
