On Mon, Jul 14, 2014 at 06:51:22AM -0300, David Bremner wrote:
> W. Trevor King writes:
> > On Sun, Jul 13, 2014 at 09:30:56AM -0300, David Bremner wrote:
> >> I consider it a useful feature that it works without the user
> >> configuring a local branch. I agree
On Sun, Jul 13, 2014 at 09:30:56AM -0300, David Bremner wrote:
> I consider it a useful feature that it works without the user
> configuring a local branch. I agree that in more complex setups
> this ambiguity is not as nice, but I'd rather it was only the
> minority of users with unusual setups (
On Sun, Jul 13, 2014 at 09:30:56AM -0300, David Bremner wrote:
> I consider it a useful feature that it works without the user
> configuring a local branch. I agree that in more complex setups
> this ambiguity is not as nice, but I'd rather it was only the
> minority of users with unusual setups (
On Sun, Jul 13, 2014 at 09:05:41AM +0300, Tomi Ollila wrote:
> I am satisfied with rst-man2any.py, but as being normal picky me I
> wonder whether the command prefix 'rst-' is being too generic
> i.e. is invading that "namespace". If no one else has the same
> feeling (or the feeling is just wrong
On Sun, Jul 13, 2014 at 09:05:41AM +0300, Tomi Ollila wrote:
> I am satisfied with rst-man2any.py, but as being normal picky me I
> wonder whether the command prefix 'rst-' is being too generic
> i.e. is invading that "namespace". If no one else has the same
> feeling (or the feeling is just wrong
excefile is gone in Python 3 [1]. Instead of exec-ing the
configuration, it's easier to insert the source directory in Python's
path [2], and just import the configuration. With this change,
prerst2man.py is compatible with both Python 2 and 3.
[1]: https://docs.python.org/3.0/whatsnew/3.0.html#
For example, with these changes we can build HTML output using:
$ rst-man2any.py -c rst2html -i ${SRCDIR} -o ${OUTDIR} -e html
The extension adjustment ensures that the output filenames from the
above command match what we currently generate with sphinx-html.
Adding argparse handling at the to
We already fall back to rst2man if Sphinx isn't available for building
the man pages. With this commit we'll fall back to rst2html for
building the HTML docs too. The only tricky bit here is that
HAVE_SPHINX explicitly checks for sphinx.writers.manpage. I'm just
assuming sphinx.writers.html exis
Gentoo's dev-python/docutils-0.10 installs Docutils scripts with a
*.py extension, so I have /usr/bin/rst2man.py and no rst2man script.
This patch supports users with both types of systems by checking for
rst2man, falling back on rst2man.py, and giving up only if neither is
found. Users can also s
2
[3]: id:m2lhrzj8kb@guru.guru-group.fi
http://article.gmane.org/gmane.mail.notmuch.general/18653
W. Trevor King (5):
doc: Allow rst2man.py as an alternative to rst2man
doc/prerst2man.py: Convert execfile to import
doc/rst-man2any.py: Adjust to handle any output format, not just man
page
The rst2man target was removed in 9d9a700 (doc: build man pages at
build time; introduce HAVE_SPHINX, HAVE_RST2MAN, 2014-03-13), but a
reference in the install docs slipped through. While I was removing
that reference, I also:
* Converted doc/INSTALL to reStructuredText, so I can link to Sphinx
We already fall back to rst2man if Sphinx isn't available for building
the man pages. With this commit we'll fall back to rst2html for
building the HTML docs too. The only tricky bit here is that
HAVE_SPHINX explicitly checks for sphinx.writers.manpage. I'm just
assuming sphinx.writers.html exis
The rst2man target was removed in 9d9a700 (doc: build man pages at
build time; introduce HAVE_SPHINX, HAVE_RST2MAN, 2014-03-13), but a
reference in the install docs slipped through. While I was removing
that reference, I also:
* Converted doc/INSTALL to reStructuredText, so I can link to Sphinx
For example, with these changes we can build HTML output using:
$ rst-man2any.py -c rst2html -i ${SRCDIR} -o ${OUTDIR} -e html
The extension adjustment ensures that the output filenames from the
above command match what we currently generate with sphinx-html.
Adding argparse handling at the to
excefile is gone in Python 3 [1]. Instead of exec-ing the
configuration, it's easier to insert the source directory in Python's
path [2], and just import the configuration. With this change,
prerst2man.py is compatible with both Python 2 and 3.
[1]: https://docs.python.org/3.0/whatsnew/3.0.html#
Gentoo's dev-python/docutils-0.10 installs Docutils scripts with a
*.py extension, so I have /usr/bin/rst2man.py and no rst2man script.
This patch supports users with both types of systems by checking for
rst2man, falling back on rst2man.py, and giving up only if neither is
found. Users can also s
]: id:m2lhrzj8kb.fsf at guru.guru-group.fi
http://article.gmane.org/gmane.mail.notmuch.general/18653
W. Trevor King (5):
doc: Allow rst2man.py as an alternative to rst2man
doc/prerst2man.py: Convert execfile to import
doc/rst-man2any.py: Adjust to handle any output format, not just
For folks that want to start versioning a new tag-space, instead of
cloning one that someone else has already started.
The empty-blob hash-object call avoids errors like:
$ nmbug commit
error: invalid object 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 for
'tags/...'
fatal: git-write-tr
l your tags. Replace the NMBPREFIX
with something else (e.g. NMBPREFIX='myproject::') to only track tags
for a particular project. You could also define aliases to set the
appropriate environment variables on the fly:
$ alias mpbug='NMBGIT=/tmp/nmbug NMBPREFIX="myproject:
If we don't have an upstream, there is nothing to merge, so nothing is
unmerged. This avoids errors like:
$ nmbug status
error: No upstream configured for branch 'master'
error: No upstream configured for branch 'master'
fatal: ambiguous argument '@{upstream}': unknown revision or path no
Add a '-2|' dir for "execute the command and pipe both stdout and
stderr to us". Use this to catch stderr from the rev-parse call in
is_unmerged. We already check the status, so we don't want to confuse
users with stuff like:
error: No upstream configured for branch 'master'
on nmbug's stderr
Sometimes we want to catch Git errors and handle them, instead of
dying with an error message. This lower-level version of git() allows
us to get the error status when we want it.
---
devel/nmbug/nmbug | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/devel/nmbug/
For folks that want to start versioning a new tag-space, instead of
cloning one that someone else has already started.
The empty-blob hash-object call avoids errors like:
$ nmbug commit
error: invalid object 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 for
'tags/...'
fatal: git-write-tr
Add a '-2|' dir for "execute the command and pipe both stdout and
stderr to us". Use this to catch stderr from the rev-parse call in
is_unmerged. We already check the status, so we don't want to confuse
users with stuff like:
error: No upstream configured for branch 'master'
on nmbug's stderr
If we don't have an upstream, there is nothing to merge, so nothing is
unmerged. This avoids errors like:
$ nmbug status
error: No upstream configured for branch 'master'
error: No upstream configured for branch 'master'
fatal: ambiguous argument '@{upstream}': unknown revision or path no
Sometimes we want to catch Git errors and handle them, instead of
dying with an error message. This lower-level version of git() allows
us to get the error status when we want it.
---
devel/nmbug/nmbug | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/devel/nmbug/
l your tags. Replace the NMBPREFIX
with something else (e.g. NMBPREFIX='myproject::') to only track tags
for a particular project. You could also define aliases to set the
appropriate environment variables on the fly:
$ alias mpbug='NMBGIT=/tmp/nmbug NMBPREFIX="myproject:
describing the program
Move the generated date from the top of the page to the footer.
W. Trevor King (3):
nmbug-status: Factor out header/footer context into a shared dict
nmbug-status: Add the time to the footer's build-date
nmbug-status: Optionally load the header and footer templates
For folks that don't like the default templates for whatever reason.
---
NEWS | 18 ++
devel/nmbug/nmbug-status | 37 +
2 files changed, 39 insertions(+), 16 deletions(-)
diff --git a/NEWS b/NEWS
index 5d85733..ab6f9e4 100644
Our repository [1] has a post-update hook that rebuilds the status
page after each push. Since that may happen several times a day, we
might as well show the build time (as well as the date) in the footer.
The trailing 'Z' is the ISO 8601 designator for UTC. Now that we're
showing times, it's ni
From: Carl Worth
Prefer a docstring to a header comment so we can use it as the
ArgumentParser description (formatted with 'nmbug-status --help').
Script readers still have it near the top of the file. Since it's a
docstring, use PEP 257's summary-line-and-body format [1].
[1]: http://legacy.py
From: Carl Worth
It's useful reference information, but anyone who wants it will look
for and find it. We don't need this front-and-center. Follow the
pattern set by our header template with a triple-quoted string.
The gray styling is less agressive. IE uses 'color' for drawing
the rule, whi
Rather than splitting this context into header-only and footer-only
groups, just dump it all in a shared dict. This will make it easier
to eventually split the header/footer templates out of this script
(e.g. if we want to load them from the config file).
---
devel/nmbug/nmbug-status | 16 +++
From: Carl Worth
It's nice to have for situations where this script is found outside of
the notmuch source repository (e.g. after being installed).
---
devel/nmbug/nmbug-status | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/devel/nmbug/nmbug-status b/devel/nm
For folks that don't like the default templates for whatever reason.
---
NEWS | 18 ++
devel/nmbug/nmbug-status | 37 +
2 files changed, 39 insertions(+), 16 deletions(-)
diff --git a/NEWS b/NEWS
index 5d85733..ab6f9e4 100644
Our repository [1] has a post-update hook that rebuilds the status
page after each push. Since that may happen several times a day, we
might as well show the build time (as well as the date) in the footer.
The trailing 'Z' is the ISO 8601 designator for UTC. Now that we're
showing times, it's ni
Rather than splitting this context into header-only and footer-only
groups, just dump it all in a shared dict. This will make it easier
to eventually split the header/footer templates out of this script
(e.g. if we want to load them from the config file).
---
devel/nmbug/nmbug-status | 16 +++
From: Carl Worth
It's useful reference information, but anyone who wants it will look
for and find it. We don't need this front-and-center. Follow the
pattern set by our header template with a triple-quoted string.
The gray styling is less agressive. IE uses 'color' for drawing
the rule, whi
From: Carl Worth
Prefer a docstring to a header comment so we can use it as the
ArgumentParser description (formatted with 'nmbug-status --help').
Script readers still have it near the top of the file. Since it's a
docstring, use PEP 257's summary-line-and-body format [1].
[1]: http://legacy.py
From: Carl Worth
It's nice to have for situations where this script is found outside of
the notmuch source repository (e.g. after being installed).
---
devel/nmbug/nmbug-status | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/devel/nmbug/nmbug-status b/devel/nm
Add a docstring describing the program
Move the generated date from the top of the page to the footer.
W. Trevor King (3):
nmbug-status: Factor out header/footer context into a shared dict
nmbug-status: Add the time to the footer's build-date
nmbug-status: Optionally load the header and foote
On Fri, May 30, 2014 at 10:43:04AM +0300, Jani Nikula wrote:
> Only include the relevant information.
I prefer this approach too.
> +# Whether the Xapian version in use supports compaction
> +_HAVE_XAPIAN_COMPACT=${have_xapian_compact}
Why the leading underscore? Are we worried about colliding
On Fri, May 30, 2014 at 10:43:04AM +0300, Jani Nikula wrote:
> Only include the relevant information.
I prefer this approach too.
> +# Whether the Xapian version in use supports compaction
> +_HAVE_XAPIAN_COMPACT=${have_xapian_compact}
Why the leading underscore? Are we worried about colliding
On Thu, May 15, 2014 at 10:40:06AM -0700, Wael Nasreddine wrote:
> David Edmondson writes:
> > I realise that you might answer "I will keep this up to date", but
> > we have to worry about what happens if you lose interest and
> > wander away.
>
> Absolutely, I understand your point and no one can
On Thu, May 15, 2014 at 10:40:06AM -0700, Wael Nasreddine wrote:
> David Edmondson writes:
> > I realise that you might answer "I will keep this up to date", but
> > we have to worry about what happens if you lose interest and
> > wander away.
>
> Absolutely, I understand your point and no one can
On Mon, May 12, 2014 at 12:35:41PM +0200, Amadeusz Żołnowski wrote:
> html_static_path is a kind of source directory and it was set to
> destination directory (../html) which caused infinite recursion with
> Sphinx 1.2 and above.
> ---
> bindings/python/docs/source/conf.py | 2 +-
> 1 file changed
On Mon, May 12, 2014 at 12:35:41PM +0200, Amadeusz ?o?nowski wrote:
> html_static_path is a kind of source directory and it was set to
> destination directory (../html) which caused infinite recursion with
> Sphinx 1.2 and above.
> ---
> bindings/python/docs/source/conf.py | 2 +-
> 1 file changed
On Sun, May 11, 2014 at 12:04:12PM -0700, Carl Worth wrote:
> "W. Trevor King" writes:
> > I've cherry-picked the three patches I liked from Carl's master [1,2]
> > and added two cleanup commits of my own. I've left Carl's commit
> > messages u
On Sun, May 11, 2014 at 12:04:12PM -0700, Carl Worth wrote:
> "W. Trevor King" writes:
> > I've cherry-picked the three patches I liked from Carl's master [1,2]
> > and added two cleanup commits of my own. I've left Carl's commit
> > messages u
So it's less agressive. IE uses 'color' for drawing the rule, while
Gecko and Opera use the border or 'background-color' [1].
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=239386
---
On Sun, May 11, 2014 at 12:08:10AM +0300, Tomi Ollila wrote:
> The rendered irritates me a bit, though. Maybe
So it's less agressive. IE uses 'color' for drawing the rule, while
Gecko and Opera use the border or 'background-color' [1].
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=239386
---
On Sun, May 11, 2014 at 12:08:10AM +0300, Tomi Ollila wrote:
> The rendered irritates me a bit, though. Maybe
More accessible errors and consistent config loading inspired by
Carl's report of the unhelpful 'No JSON object' traceback [1].
Cheers,
Trevor
[1]: id:87wqegr3dm@yoom.home.cworth.org
http://article.gmane.org/gmane.mail.notmuch.general/17995
W. Trevor King (2):
nmbug-
When loading configs from Git, the bare branch name (without a
refs/heads/ prefix or similar) matches all branches of that name
(including remote-tracking branches):
.nmbug $ git show-ref config
48f3bbf1d1492e5f3d2f01de6ea79a30d3840f20 refs/heads/config
48f3bbf1d1492e5f3d2f01de6ea79a30d3840f
Carl Worth pointed out that errors like:
$ ./nmbug-status
fatal: Not a git repository: '/home/cworth/.nmbug'
fatal: Not a git repository: '/home/cworth/.nmbug'
Traceback (most recent call last):
File "./nmbug-status", line 254, in
config = read_config(path=args.config)
File
When loading configs from Git, the bare branch name (without a
refs/heads/ prefix or similar) matches all branches of that name
(including remote-tracking branches):
.nmbug $ git show-ref config
48f3bbf1d1492e5f3d2f01de6ea79a30d3840f20 refs/heads/config
48f3bbf1d1492e5f3d2f01de6ea79a30d3840f
Carl Worth pointed out that errors like:
$ ./nmbug-status
fatal: Not a git repository: '/home/cworth/.nmbug'
fatal: Not a git repository: '/home/cworth/.nmbug'
Traceback (most recent call last):
File "./nmbug-status", line 254, in
config = read_config(path=args.config)
File
More accessible errors and consistent config loading inspired by
Carl's report of the unhelpful 'No JSON object' traceback [1].
Cheers,
Trevor
[1]: id:87wqegr3dm.fsf at yoom.home.cworth.org
http://article.gmane.org/gmane.mail.notmuch.general/17995
W. Trevor King (2):
This way we can use it as the ArgumentParser description (formatted
with 'nmbug-status --help') and script readers still have it near the
top of the file. I rephrased things a bit to match PEP 257's
summary-line-and-body format [1] while elaborating on the "if
available" Gmane views.
[1]: http://
From: Carl Worth
It's useful reference information, but anyone who wants it will look
for and find it. We don't need this front-and-center.
---
devel/nmbug/nmbug-status | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/devel/nmbug/nmbug-status b/devel/nmbug/nmbug-status
From: Carl Worth
It's quite simple, really.
---
devel/nmbug/nmbug-status | 3 +++
1 file changed, 3 insertions(+)
diff --git a/devel/nmbug/nmbug-status b/devel/nmbug/nmbug-status
index e14fecd..c9cc745 100755
--- a/devel/nmbug/nmbug-status
+++ b/devel/nmbug/nmbug-status
@@ -1,5 +1,8 @@
#!/usr/
From: Carl Worth
The "same license as notmuch" text was probably fine when the file was
contained within the notmuch source repository, but here, externally,
we should be explicit.
---
The "externally" reference in patch 1/5 won't apply if this commit
lands in master. I'm not sure it's worth cha
ter.
Add a comment describing the program
W. Trevor King (2):
nmbug-status: Use a triple-quoted string for the footer template
nmbug-status: Shift the script description into a docstring
devel/nmbug/nmbug-status | 36 +---
1 file changed, 29 insertions(+), 7 d
Follow the pattern set by our header template and avoid the long line.
---
devel/nmbug/nmbug-status | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/devel/nmbug/nmbug-status b/devel/nmbug/nmbug-status
index b4f9829..e14fecd 100755
--- a/devel/nmbug/nmbug-status
+++ b/devel
This way we can use it as the ArgumentParser description (formatted
with 'nmbug-status --help') and script readers still have it near the
top of the file. I rephrased things a bit to match PEP 257's
summary-line-and-body format [1] while elaborating on the "if
available" Gmane views.
[1]: http://
From: Carl Worth
It's quite simple, really.
---
devel/nmbug/nmbug-status | 3 +++
1 file changed, 3 insertions(+)
diff --git a/devel/nmbug/nmbug-status b/devel/nmbug/nmbug-status
index e14fecd..c9cc745 100755
--- a/devel/nmbug/nmbug-status
+++ b/devel/nmbug/nmbug-status
@@ -1,5 +1,8 @@
#!/usr/
Follow the pattern set by our header template and avoid the long line.
---
devel/nmbug/nmbug-status | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/devel/nmbug/nmbug-status b/devel/nmbug/nmbug-status
index b4f9829..e14fecd 100755
--- a/devel/nmbug/nmbug-status
+++ b/devel
From: Carl Worth
It's useful reference information, but anyone who wants it will look
for and find it. We don't need this front-and-center.
---
devel/nmbug/nmbug-status | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/devel/nmbug/nmbug-status b/devel/nmbug/nmbug-status
From: Carl Worth
The "same license as notmuch" text was probably fine when the file was
contained within the notmuch source repository, but here, externally,
we should be explicit.
---
The "externally" reference in patch 1/5 won't apply if this commit
lands in master. I'm not sure it's worth cha
ter.
Add a comment describing the program
W. Trevor King (2):
nmbug-status: Use a triple-quoted string for the footer template
nmbug-status: Shift the script description into a docstring
devel/nmbug/nmbug-status | 36 +---
1 file changed, 29 insertions(+), 7 deletions(-)
--
1.9.1.353.gc66d89d
We already fall back to rst2man if Sphinx isn't available for building
the man pages. With this commit we'll fall back to rst2html for
building the HTML docs too. The only tricky bit here is that
HAVE_SPHINX explicitly checks for sphinx.writers.manpage. I'm just
assuming sphinx.writers.html exis
The rst2man target was removed in 9d9a700 (doc: build man pages at
build time; introduce HAVE_SPHINX, HAVE_RST2MAN, 2014-03-13), but a
reference in the install docs slipped through. While I was removing
that reference, I also:
* Converted doc/INSTALL to reStructuredText, so I can link to Sphinx
excefile is gone in Python 3 [1]. Instead of exec-ing the
configuration, it's easier to insert the source directory in Python's
path [2], and just import the configuration. With this change,
prerst2man.py is compatible with both Python 2 and 3.
[1]: https://docs.python.org/3.0/whatsnew/3.0.html#
For example, with these changes we can build HTML output using:
$ prerst2x.py rst2html ${SRCDIR} ${OUTDIR} html
The extension adjustment ensures that the output filenames from the
above command match what we currently generate with sphinx-html.
---
doc/Makefile.local | 4 +--
doc/prerst2man.p
.org/gmane.mail.notmuch.general/17774
[6]: id:87wqejtxs9@maritornes.cs.unb.ca
http://article.gmane.org/gmane.mail.notmuch.general/17956
[7]: id:874n271plm@maritornes.cs.unb.ca
http://article.gmane.org/gmane.mail.notmuch.general/17746
[8]: id:871txb1j8z@maritornes.cs.unb.ca
We already fall back to rst2man if Sphinx isn't available for building
the man pages. With this commit we'll fall back to rst2html for
building the HTML docs too. The only tricky bit here is that
HAVE_SPHINX explicitly checks for sphinx.writers.manpage. I'm just
assuming sphinx.writers.html exis
The rst2man target was removed in 9d9a700 (doc: build man pages at
build time; introduce HAVE_SPHINX, HAVE_RST2MAN, 2014-03-13), but a
reference in the install docs slipped through. While I was removing
that reference, I also:
* Converted doc/INSTALL to reStructuredText, so I can link to Sphinx
For example, with these changes we can build HTML output using:
$ prerst2x.py rst2html ${SRCDIR} ${OUTDIR} html
The extension adjustment ensures that the output filenames from the
above command match what we currently generate with sphinx-html.
---
doc/Makefile.local | 4 +--
doc/prerst2man.p
excefile is gone in Python 3 [1]. Instead of exec-ing the
configuration, it's easier to insert the source directory in Python's
path [2], and just import the configuration. With this change,
prerst2man.py is compatible with both Python 2 and 3.
[1]: https://docs.python.org/3.0/whatsnew/3.0.html#
Gentoo's dev-python/docutils-0.10 installs Docutils scripts with a
*.py extension, so I have /usr/bin/rst2man.py and no rst2man script.
This patch supports users with both types of systems by checking for
rst2man, falling back on rst2man.py, and giving up only if neither is
found. Users can also s
ritornes.cs.unb.ca
http://article.gmane.org/gmane.mail.notmuch.general/17754
W. Trevor King (5):
doc: Allow rst2man.py as an alternative to rst2man
doc/prerst2man.py: Convert execfile to import
doc/prerst2x.py: Adjust to handle any output format, not just man
pages
doc: Consolidate
Avoid:
$ make HAVE_SPHINX=1 sphinx-html
python ./doc/mkdocdeps.py ./doc doc/_build doc/docdeps.mk
sphinx-build -b html -d doc/_build/doctrees -q ./doc doc/_build/html
Making output directory...
WARNING: html_static_path entry '/home/wking/src/notmuch/notmuch/doc/_static'
does not exist
Avoid:
$ make HAVE_SPHINX=1 sphinx-html
python ./doc/mkdocdeps.py ./doc doc/_build doc/docdeps.mk
sphinx-build -b html -d doc/_build/doctrees -q ./doc doc/_build/html
Making output directory...
WARNING: html_static_path entry '/home/wking/src/notmuch/notmuch/doc/_static'
does not exist
On Thu, Apr 17, 2014 at 04:34:57PM -0400, Austin Clements wrote:
> +$(DOCBUILDDIR)/.roff.stamp: ${MAN_RST_FILES}
> ifeq ($(HAVE_SPHINX),1)
> $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(DOCBUILDDIR)/man
> for section in 1 5 7; do \
> @@ -48,6 +54,7 @@ else
> @echo "Fatal: build depen
On Thu, Apr 17, 2014 at 04:34:57PM -0400, Austin Clements wrote:
> +$(DOCBUILDDIR)/.roff.stamp: ${MAN_RST_FILES}
> ifeq ($(HAVE_SPHINX),1)
> $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(DOCBUILDDIR)/man
> for section in 1 5 7; do \
> @@ -48,6 +54,7 @@ else
> @echo "Fatal: build depen
On Fri, May 09, 2014 at 02:59:02PM +, Wael Nasreddine wrote:
> On Travis Zlib is old and notmuch configure script exits with a
> failure, please see the Travis build #1
I'm just dropping a cross-link to the recent old-zlib discussion here
[1].
Cheers,
Trevor
[1]: id:1397809386-23356-1-git-se
On Fri, May 09, 2014 at 02:59:02PM +, Wael Nasreddine wrote:
> On Travis Zlib is old and notmuch configure script exits with a
> failure, please see the Travis build #1
I'm just dropping a cross-link to the recent old-zlib discussion here
[1].
Cheers,
Trevor
[1]: id:1397809386-23356-1-git-se
On Thu, May 08, 2014 at 09:43:01PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > I don't think merge conflicts are the problem here. If the GitHub
> > mirror claims to be a mirror but adds an additional commit B…
>
> That wouldn't be a problem if HEAD
On Thu, May 08, 2014 at 09:43:01PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > I don't think merge conflicts are the problem here. If the GitHub
> > mirror claims to be a mirror but adds an additional commit B?
>
> That wouldn't be a problem if HEAD
On Fri, May 09, 2014 at 12:13:51AM +, Wael Nasreddine wrote:
> I understand. Maybe we should convert the current Github to a real mirror,
> mirroring all the branches and tags as is and a) add .Travis.yml upstream
> or b) maintain a separate fork (maybe under my own profile) for Travis
> integr
On Fri, May 09, 2014 at 12:13:51AM +, Wael Nasreddine wrote:
> I understand. Maybe we should convert the current Github to a real mirror,
> mirroring all the branches and tags as is and a) add .Travis.yml upstream
> or b) maintain a separate fork (maybe under my own profile) for Travis
> integr
On Thu, May 08, 2014 at 11:18:23PM +, Wael Nasreddine wrote:
> Well like I said in my first email, if you guys are interested in owning
> and maintaining the GitHub repo it is yours, besides I have not done
> anything with the history I only added one commit which will never conflict
> with ups
On Thu, May 08, 2014 at 11:18:23PM +, Wael Nasreddine wrote:
> Well like I said in my first email, if you guys are interested in owning
> and maintaining the GitHub repo it is yours, besides I have not done
> anything with the history I only added one commit which will never conflict
> with ups
On Fri, May 09, 2014 at 12:45:27AM +0200, Suvayu Ali wrote:
> On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote:
> > On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
> > > One of my TODOs is to also package the ruby bindings, and
> > > n
On Fri, May 09, 2014 at 12:45:27AM +0200, Suvayu Ali wrote:
> On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote:
> > On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
> > > One of my TODOs is to also package the ruby bindings, and
> > > n
On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
> One of my TODOs is to also package the ruby bindings, and
> notmuch-vim. The only thing preventing me now is my unfamiliarty
> with ruby, and Fedora packaging guidelines for ruby-gems.
I think this is one argument argument in favor of
On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
> One of my TODOs is to also package the ruby bindings, and
> notmuch-vim. The only thing preventing me now is my unfamiliarty
> with ruby, and Fedora packaging guidelines for ruby-gems.
I think this is one argument argument in favor of
On Thu, May 08, 2014 at 07:54:38PM +, Wael Nasreddine wrote:
> - Revert my changes (except for the CI)
I'd revert all the changes and submit them upstream, so the GitHub
repository is an exact mirror of
http://git.notmuchmail.org/git/notmuch. A Travis-CI file is
Travis-specific, not necessari
On Thu, May 08, 2014 at 07:54:38PM +, Wael Nasreddine wrote:
> - Revert my changes (except for the CI)
I'd revert all the changes and submit them upstream, so the GitHub
repository is an exact mirror of
http://git.notmuchmail.org/git/notmuch. A Travis-CI file is
Travis-specific, not necessari
On Tue, Apr 22, 2014 at 11:01:09PM -0700, Carl Worth wrote:
> W. Trevor King writes:
> >> > I think that making nmbug and nmbug-status generally applicable
> >> > for other projects is a good target. I don't see any need to
> >> > pull them out
On Tue, Apr 22, 2014 at 11:01:09PM -0700, Carl Worth wrote:
> W. Trevor King writes:
> >> > I think that making nmbug and nmbug-status generally applicable
> >> > for other projects is a good target. I don't see any need to
> >> > pull them out
201 - 300 of 518 matches
Mail list logo
