[PATCH] Trivial documentation fix.

Trivial xz documentation fix - I think that 6 is the default rather than 7 too... Cheers, Patrick >From b0dcc9d10acef5713b8bff61bdf4960c7c83764a Mon Sep 17 00:00:00 2001 From: Patrick Welche Date: Fri, 14 Dec 2012 00:21:39 + Subject: [PATCH] Trivial documentation fix. To display a progress

Re: automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first)

Quite a lengthy response for such a simple inquiry! Really, I'd just like to get gobject-introspection to compile on Arch Linux. The problem is that gobject-introspection's configure.ac has the line AM_PATH_PYTHON([2.5]) but gobject-introspection can't actually work with Python 3 or higher (the

[PATCH] {maint} tests: improve 'pkg-config' requirement

This improves (and unifies among different tests) the detection of both the 'pkg-config' program and m4 macros provided by it; they are needed in particular by tests on Vala support. Before this, some Vala-related tests were failing spuriously when the pkg-config program was available but the macr

[PATCH 5/8] maint: factor out the name of the dir where web manuals are generated

Just a minor refactoring to reduce duplication; no semantic change is intended. * Makefile.am (web_manual_dir): New. (web-manual, web-manual-update, clean-web-manual): Use it. Signed-off-by: Stefano Lattarini --- Makefile.am | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-)

[PATCH 4/8] maint: rename rules to build/upload web manuals

The new names are the same used by the similar-purpose rules provided by the 'top/maint.mk' makefile in gnulib (as of commit v0.0-7741-g4a8c422). No need to have gratuitous incompatibilities. * Makefile.am (web-manuals): Rename ... (web-manual): ... like this. (upload-web-manuals): Rename ... (web

[PATCH 8/8] HACKING: minor formatting changes, for better clarity

Signed-off-by: Stefano Lattarini --- HACKING | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/HACKING b/HACKING index 4641d90..bb5876e 100644 --- a/HACKING +++ b/HACKING @@ -244,19 +244,27 @@ be done carefully, because that command will remove *all* the fi

[PATCH 1/8] release: automate uploading of web manuals in CVS

This is partly inspired to the 'gnu-web-doc-update' script from gnulib. Unfortunately, we can't use that script directly, because as of now it assumes a build system integrated with gnulib. * Makefile.am (upload-web-manuals): New .PHONY rule. (RSYNC, CVS, CVSU, CVS_USER, WEBCVS_ROOT): New variabl

[PATCH 2/8] docs: build the web manuals for CVS in the builddir, not in the srcdir

We can do so using the '-I' option of the gendocs.sh script. Inspired by the 'web-manual' rule in the 'top/maint.mk' file provided by gnulib (as of commit v0.0-7741-g4a8c422) as customized by Bison in its 'cfg.mk' file (as of commit v2.6.5-1007-gf5fceda). * Makefile.am (web-manuals): Modify and s

[PATCH 0/8] More automation in generation/upload of web manuals

So we'll have even less clerical work when making a release. I will push this series by tomorrow if there is no objection. Regards, Stefano -*-*-*- Stefano Lattarini (8): release: automate uploading of web manuals in CVS docs: build the web manuals for CVS in the builddir, not in the srcd

Re: automake and pyconfigure: a future integration?

>> What happens in pyconfigure (more on that in a moment) is that you can >> pass an argument to AC_PROG_PYTHON. So if you want to use Python 2 >> specifically, you first search for it with AC_PROG_PYTHON([python2]). >> In a standard system, this should find the most recent Python 2 >> interpreter.

Re: automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first)

>> > Me too, mostly. But I agree that there is an underlying issue (albeit > not major). > >> The "Future Changes to this Recommendation" >> section of PEP 394 anticipates changing the `python' symlink to >> `python3' at some point in the future. This has already happened in Parabola, Arch and ot

Re: automake and pyconfigure: a future integration?

On 12/13/2012 03:14 PM, Brandon Invergo wrote: >>> What happens in pyconfigure (more on that in a moment) is that you can >>> pass an argument to AC_PROG_PYTHON. So if you want to use Python 2 >>> specifically, you first search for it with AC_PROG_PYTHON([python2]). >>> In a standard system, this s

Re: automake and pyconfigure: a future integration?

Hi Brandon. On 12/13/2012 02:20 PM, Brandon Invergo wrote: >>> >> Me too, mostly. But I agree that there is an underlying issue (albeit >> not major). >> >>> The "Future Changes to this Recommendation" >>> section of PEP 394 anticipates changing the `python' symlink to >>> `python3' at some point

automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first)

Severity: wishlist [+cc bug-automake, +cc bug-pyconfigure] Reference: On 12/13/2012 11:15 AM, Jack Kelly wrote: > Kerrick Staley writes: >> Usually, when AM_PATH_PYTHON is invoked with an argument of the form >> 2.X, it

Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first

Kerrick Staley writes: > Usually, when AM_PATH_PYTHON is invoked with an argument of the form > 2.X, it means that only a Python 2 interpreter should be used, and not > a Python 3 interpreter. However, the "python" command invokes a Python > 3 interpreter on some systems (see [1]), so if we try "p

[PATCH] AM_PATH_PYTHON: try "python2" et al. first

When checking for a suitable Python version, try "python2", "python 2.7", "python2.6", etc. before trying "python". Usually, when AM_PATH_PYTHON is invoked with an argument of the form 2.X, it means that only a Python 2 interpreter should be used, and not a Python 3 interpreter. However, the "pyth