[PATCH] subtree: Obey USE_ASCIIDOCTOR when present
Defining USE_ASCIIDOCTOR=1 when building Git uses asciidoctor over asciidoc when generating DocBook and man page documentation. However, the contrib/subtree module does not presently honour that flag. This causes a build failure when asciidoc is not present on the build system. Instead, adapt the main Documentation/Makefile logic to use asciidoctor when requested. Signed-off-by: A. Wilcox --- contrib/subtree/Makefile | 26 +++--- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 6afa9aa..1b8fcd1 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -19,15 +19,27 @@ htmldir ?= $(prefix)/share/doc/git-doc INSTALL ?= install RM ?= rm -f -ASCIIDOC = asciidoc -XMLTO= xmlto +ASCIIDOC = asciidoc +ASCIIDOC_CONF= -f ../../Documentation/asciidoc.conf +ASCIIDOC_HTML= xhtml11 +ASCIIDOC_DOCBOOK = docbook +ASCIIDOC_EXTRA = +XMLTO= xmlto + +ifdef USE_ASCIIDOCTOR +ASCIIDOC = asciidoctor +ASCIIDOC_CONF= +ASCIIDOC_HTML= xhtml5 +ASCIIDOC_DOCBOOK = docbook45 +ASCIIDOC_EXTRA += -I../../Documentation -rasciidoctor-extensions +ASCIIDOC_EXTRA += -alitdd='&\#x2d;&\#x2d;' +endif ifndef SHELL_PATH SHELL_PATH = /bin/sh endif SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH)) -ASCIIDOC_CONF = ../../Documentation/asciidoc.conf MANPAGE_XSL = ../../Documentation/manpage-normal.xsl GIT_SUBTREE_SH := git-subtree.sh @@ -65,12 +77,12 @@ $(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML) $(XMLTO) -m $(MANPAGE_XSL) man $^ $(GIT_SUBTREE_XML): $(GIT_SUBTREE_TXT) - $(ASCIIDOC) -b docbook -d manpage -f $(ASCIIDOC_CONF) \ - -agit_version=$(GIT_VERSION) $^ + $(ASCIIDOC) -b $(ASCIIDOC_DOCBOOK) -d manpage $(ASCIIDOC_CONF) \ + -agit_version=$(GIT_VERSION) $(ASCIIDOC_EXTRA) $^ $(GIT_SUBTREE_HTML): $(GIT_SUBTREE_TXT) - $(ASCIIDOC) -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) \ - -agit_version=$(GIT_VERSION) $^ + $(ASCIIDOC) -b $(ASCIIDOC_HTML) -d manpage $(ASCIIDOC_CONF) \ + -agit_version=$(GIT_VERSION) $(ASCIIDOC_EXTRA) $^ $(GIT_SUBTREE_TEST): $(GIT_SUBTREE) cp $< $@ -- 2.10.0
Git 2.14.1: t6500: error during test on musl libc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi there, While bumping Git's version for our Linux distribution to 2.14.1, I've run in to a new test failure in t6500-gc.sh. This is the output of the failing test with debug=t verbose=t: expecting success: # make sure we run a background auto-gc test_commit make-pack && git repack && test_config gc.autopacklimit 1 && test_config gc.autodetach true && # create a ref whose loose presence we can use to detect a pack-refs run git update-ref refs/heads/should-be-loose HEAD && test_path_is_file .git/refs/heads/should-be-loose && # now fake a concurrent gc that holds the lock; we can use our # shell pid so that it looks valid. hostname=$(hostname || echo unknown) && printf "$$ %s" "$hostname" >.git/gc.pid && # our gc should exit zero without doing anything run_and_wait_for_auto_gc && test_path_is_file .git/refs/heads/should-be-loose [master 28ecdda] make-pack Author: A U Thor 1 file changed, 1 insertion(+) create mode 100644 make-pack.t Counting objects: 3, done. Delta compression using up to 8 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), done. Total 3 (delta 0), reused 0 (delta 0) Auto packing the repository in background for optimum performance. See "git help gc" for manual housekeeping. File .git/refs/heads/should-be-loose doesn't exist. not ok 8 - background auto gc respects lock for all operations # # # make sure we run a background auto-gc # test_commit make-pack && # git repack && # test_config gc.autopacklimit 1 && # test_config gc.autodetach true && # # # create a ref whose loose presence we can use to detect a pack-refs run # git update-ref refs/heads/should-be-loose HEAD && # test_path_is_file .git/refs/heads/should-be-loose && # # # now fake a concurrent gc that holds the lock; we can use our # # shell pid so that it looks valid. # hostname=$(hostname || echo unknown) && # printf "$$ %s" "$hostname" >.git/gc.pid && # # # our gc should exit zero without doing anything # run_and_wait_for_auto_gc && # test_path_is_file .git/refs/heads/should-be-loose # # failed 1 among 8 test(s) 1..8 I admit I am mostly blind with the Git gc system. Should I use strace on the git-gc process at the end? How would I accomplish that? Is there a better way of debugging this error further? Core system stats: Intel x86_64 E3-1280 v3 @ 3.60 GHz musl libc 1.1.16+20 git 2.14.1, vanilla except for a patch to an earlier test due to musl's inability to cope with EUC-JP bash 4.3.48(1)-release Thank you very much. All the best, - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZuz4yAAoJEMspy1GSK50UORwP/0Jxfp3xzexh27tSJlXYWS/g g9QK8Xmid+3A0R696Vb2GguKg2roCcTmM2anR7iD1B2f2W31sgf+8M5mnJRHyJ1p geEeqwrTdpCk6jQ/1Pj03L0NOftb1ftR6hcoVujBFAOph4jRlRdZDPA87fe6snrh q99C3LoDXQcyK6WWJwzX+t2wOplKgpGJP8wTAaZ0AHoUwVS5CLPl8tP2XaY4kLfD ZPPcvtp9wisVzzZ2ssE/CLGd38EbenNNZ6OJCBFJIHmlwey4G2isZ9kk6fVIHXi2 unBJ8yVqI7hQKmQFSVQMMSFSd9azhHnDjTBO5mzWeRK9HNVMda3LZsXTtVeswnRs lN/ASMdt5KdfpNy/plFB7yDWLlQSQY7j1mxBMR8lL3AdVVQUbJppDM795tt+rn6a NCE2ESZMWd/QEULmT92AbkNJTj5ibBEoubnVTka05KMjaBLwIauhpqU5XxLFq2UH y3JYQU9hm0E7dQE0CLXxIm5/574T6bBUgp1cXH3CjxkeUYKR1USVKtDfBV6t/Qmt xlDZKPEfjKbTvL3KUF33G+eAp55wTwrJTaWlOp8A/JqooXavYghcsuFhYtCPJ8qo fFUa8kBZP70E/O7JkycUu8wi7p42+j1a8gR6/AnPG2u2wyoiosLCxHX+nll4gKmN b6BuiRn0Z9ie5xw4xcMR =Vf8Z -END PGP SIGNATURE-
Re: Git 2.14.1: t6500: error during test on musl libc
On 15/09/17 06:30, Jeff King wrote: > On Fri, Sep 15, 2017 at 08:37:40AM +0200, Kevin Daudt wrote: > >> On Thu, Sep 14, 2017 at 09:43:12PM -0500, A. Wilcox wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA256 >>> >>> Hi there, >>> >>> While bumping Git's version for our Linux distribution to 2.14.1, I've >>> run in to a new test failure in t6500-gc.sh. This is the output of >>> the failing test with debug=t verbose=t: >> >> This is a new test introduced by c45af94db >> (gc: run pre-detach operations under lock, 2017-07-11) which was >> included in v2.14.0. >> >> So it might be that this was already a problem for a longer time, only >> just recently uncovered. > > The code change there is not all that big. Mostly we're just checking > that the lock is actually respected. The lock code doesn't exercise libc > all that much. It does use fscanf, which I guess is a little exotic for > us. It's also possible that hostname() doesn't behave quite as we > expect. > > If you instrument gc like the patch below, what does it report when you > run: > > GIT_TRACE=1 ./t6500-gc.sh --verbose-only=8 > > I get: > > [...] > trace: built-in: git 'gc' '--auto' > Auto packing the repository in background for optimum performance. > See "git help gc" for manual housekeeping. > debug: gc lock already held by $my_hostname > [...] > > If you get "acquired gc lock", then the problem is in > lock_repo_for_gc(), and I'd suspect some problem with fscanf or > hostname. > > -Peff Hey there Peff, What a corner-y corner case we have here. I believe the actual error is in the POSIX standard itself[1], as it is not clear what happens when there are not enough characters to 'fill' the width specified with %c in fscanf: > c >Matches a sequence of bytes of the number specified by the field > width (1 if no field width is present in the conversion > specification). I've tested a number of machines: * OpenBSD 5.7/amd64 * NetBSD 7.0/i386 * FreeBSD 12/PowerPC * glibc/arm * Windows 7 with Microsoft Visual C++ 2013 All of them will allow a so-called "short read" and give you as many characters as they can, treating the phrase "a sequence of bytes of the number specified" as meaning "*up to* the number". The musl libc treats this phrase as meaning "*exactly* the number", and fails if it cannot give you exactly the number you ask. IBM z/OS explicitly states in their documentation[2]: > Sequence of one or more characters as specified by field width And Microsoft similarly states[3]: > The width field is a positive decimal integer controlling the maximum > number of characters to be read for that field. No more than width > characters are converted and stored at the corresponding argument. > Fewer than width characters may be read if a whitespace character > (space, tab, or newline) or a character that cannot be converted > according to the given format occurs before width is reached. While musl's reading is correct from an English grammar point of view, it does not seem to be how any other implementation has read the standard. However! It gets better. The ISO C standard, committee draft version April 12, 2011, states[4]: > cMatches a sequence of characters of exactly the number specified > by the field width (1 if no field width is present in the directive). Since "[t]his volume of POSIX.1-2008 defers to the ISO C standard", it stands to reason that this is the intended meaning and behaviour. Thus meaning that literally every implementation, with the exception of the musl libc, is breaking the ISO C standard. Since Git is specifically attempting to read in a host name, there may be a solution: while 'c' guarantees that any byte will be read, and 's' will skip whitespace, RFCs 952 and 1123 §2.1[5] specify that a network host name must never contain whitespace. IDNA2008 §2.3.2.1[6] (and IDNA2003 before it) specifically removes ASCII whitespace characters from the valid set of Unicode codepoints for an IDNA host name[7]. Additionally, the buffer `locking_host` is already defined as an array of char of size HOST_NAME_MAX + 1, and the width specifier in fscanf is specified as HOST_NAME_MAX. Therefore, it should be safe to change git to use the 's' type character. Additionally, I can confirm that this change (patch attached) allows the Git test suite to pass on musl. I hope this message is informative. This was an exhausting, but necessary, exercise in trying to ensure code correctness. I am cc'ing the musl list so that this information may live there as wel
Re: Git 2.14.1: t6500: error during test on musl libc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16/09/17 19:36, Junio C Hamano wrote:
> "A. Wilcox" writes:
>
>> While musl's reading is correct from an English grammar point of
>> view, it does not seem to be how any other implementation has
>> read the standard.
>>
>> However! It gets better.
>>
>> The ISO C standard, committee draft version April 12, 2011,
>> states[4]:
>>
>>> cMatches a sequence of characters of exactly the number
>>> specified by the field width (1 if no field width is present in
>>> the directive).
>> ... Since Git is specifically attempting to read in a host name,
>> there may be a solution: while 'c' guarantees that any byte will
>> be read, and 's' will skip whitespace, RFCs 952 and 1123 §2.1[5]
>> specify that a network host name must never contain whitespace.
>> IDNA2008 §2.3.2.1[6] (and IDNA2003 before it) specifically
>> removes ASCII whitespace characters from the valid set of Unicode
>> codepoints for an IDNA host name[7]. Additionally, the buffer
>> `locking_host` is already defined as an array of char of size
>> HOST_NAME_MAX + 1, and the width specifier in fscanf is specified
>> as HOST_NAME_MAX. Therefore, it should be safe to change git to
>> use the 's' type character. Additionally, I can confirm that
>> this change (patch attached) allows the Git test suite to pass on
>> musl.
>
> I did a quick scan for substring "scanf" and read through the
> output, and it seems that this is the only one that wants to do
> the this many characters, e.g. "%42c", conversion.
>
> I am a bit worried about the correctness of your conclusion,
> though.
%[width]s means read up to [width] non-ws characters. It is exactly
what Git wants out of %[width]c, with the difference that 's' will
stop at whitespace. Since hostnames cannot legally contain
whitespace, the difference is negligible.
> As long as we are reading from the file written by us, because the
> string we write as the hostname part comes from what we prepare in
> my_host[HOST_NAME_MAX+1] using xgethostname(), we may know it
> would fit in locking_host[HOST_NAME_MAX+1]. But because
> HOST_NAME_MAX on my platform may be shorter than what your platform
> uses, I'll run over the end of my buffer if I am reading the
> lockfile you write to notice that the repository is in use from
> your host. After all, the reason why we write hostname in the file
> is because we expect the filesystem is shared across different
> hosts, so relying on HOST_NAME_MAX to be the same across platforms
> would not be a good way to go.
You cannot run over the buffer in any scenario: if the hostname is
longer than [width], then [width] + \0 will be written to the buffer.
Since the buffer is HOST_NAME_MAX+1 and the width is HOST_NAME_MAX,
it stands to reason that you cannot overflow the buffer.
> So it seems to me that a real fix has to read the file ourselves
> and parse up to our HOST_NAME_MAX+1 to see if the hostname refers
> to us, and fscanf that cannot take "slurp up to this many bytes" is
> not useful tool to implementing that parsing.
Except that is *exactly* *what* *s* *does* (quoting C11 §7.21.6.2):
9 An input item is defined as the longest sequence of input
characters which does not exceed any specified field width
s Matches a sequence of non-white-space characters.
awilcox on elaine ~ $ cat -> myhost
elaine.foxkit.us
awilcox on elaine ~ $ cat -> test.c
#include
int main(void) {
char test[9];
fscanf(fopen("myhost", "r"), "%8s", test);
printf("result: %s\n", test);
return 0;
}
awilcox on elaine ~ $ c99 -o test test.c
awilcox on elaine ~ $ ./test
result: elaine.f
awilcox on elaine ~ $ /usr/lib/libc.so
musl libc (powerpc)
Version 1.1.16
> The current scan_fmt variable comes from da25bdb7 ("use
> HOST_NAME_MAX to size buffers for gethostname(2)", 2017-04-18),
> and before that, we used to use "%"SCNuMAX" %127c", which was
> already problematic. The "%127c" part came from the very original
> of this codepath in 64a99eb4 ("gc: reject if another gc is running,
> unless --force is given", 2013-08-08), whose first appearance in
> released versions was in v1.8.5, it seems. IOW, nobody tried to
> run Git with musl C in the past 4 years and you are the first one
> to notice?
Yes. Yes I am.
Because this is the first version that has a *test* that *tests* this
behaviour.
The odds that someone:
* is using musl
* with a Git repository over a network file system
* with another platform with a different HOST_NAME_MAX
* both concurrently running `git gc`,
Re: Git 2.14.1: t6500: error during test on musl libc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16/09/17 22:16, Junio C Hamano wrote:
> Subject: gc: call fscanf() with %s, not %c, when reading
> hostname
>
> Earlier in this codepath, we (ab)used "%c" to read the
> hostname recorded in the lockfile into locking_host[HOST_NAME_MAX +
> 1] while substituting with the actual value of
> HOST_NAME_MAX.
>
> This turns out to be incorrect, as it an instruction to read
> exactly
it -> it is
> the specified number of bytes. We are trying to read at most that
> many bytes, we should be using "%s" instead.
>
> Helped-by: A. Wilcox Signed-off-by: Junio
> C Hamano --- builtin/gc.c | 2 +- 1 file
> changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/gc.c b/builtin/gc.c index
> 3c78fcb9b1..bb2d6c1fb2 100644 --- a/builtin/gc.c +++
> b/builtin/gc.c @@ -258,7 +258,7 @@ static const char
> *lock_repo_for_gc(int force, pid_t* ret_pid) int should_exit;
>
> if (!scan_fmt) - scan_fmt = xstrfmt("%s %%%dc",
> "%"SCNuMAX,
> HOST_NAME_MAX); + scan_fmt = xstrfmt("%s %%%ds",
> "%"SCNuMAX,
> HOST_NAME_MAX); fp = fopen(pidfile_path, "r"); memset(locking_host,
> 0, sizeof(locking_host)); should_exit =
>
Ack. This is what I used in my testing; looks great. Thanks so much
for your time and patience.
Sincerely,
- --arw
- --
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJZve4WAAoJEMspy1GSK50UruQP/3rca4kZp/mootkcgJrNwlSc
5SvFETaBMYb9M6CewOIgDWtQVqdGmkX+vhlyz/fO1aMUzed9JNgoYD0Fj8S+8RL/
aan96+Om94znlWydSlU48ZaR69sbj012TSJBvQdAs9K9Nfi40lMVGi8BvI5vsAG0
PCMyAUB4N6b9FYUNb6zO73JjmQSYzYV2TFOvACFgHwZ7ailyeyGI3LIP5Yd4OiF1
ERyJIKDoBjf0ns95xjox+HYFzG3VFDriM6GdEG1w25sLG+nvWxy/XV1Dv/K1/LiV
VzSJ3FEdNdOoO5SLcX4uRMYzRKLt3ihwnwIS6SC44Xd7XaqaWpfpueGxilQCI3Yn
FNWB3mX9oeXICIvM6PscJTzRLJd+gp3RbyLfavaQ2cNakrL9z+Qm5v6a52ufCqvP
SGdruVLGLDCR0qPWokKa64+uSfi6QNNmVgzVx4fRIwbMSUm1+sEh0uIjqgTQPBTq
Jyn6og/T234punjBI+GuEXhsb3FEbJh2xGyOQbmhW4l/DPzerUpXJAgCPC2JT93+
Z1s0aeDqC0n/dMHofVd8ZRFKt/ImVT0ywg7A9bJahhaJwmtkh0Xgb2hLgO5FGeuI
zY+9FI+doH6Al+KgxqSduKfxDOsEoxYRLCRYO2QnNjE7iYLIdUYRXEucw3Z/VQA1
b44AES8+WthuxQKsRstE
=Zwpa
-END PGP SIGNATURE-
Test failures when Git is built with libpcre and grep is built without it
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello! I'm attempting to package Git for our new Linux distribution and I have run in to a failure on our PowerPC builder while running the test suite. The PowerPC builder runs a tiny version of grep(1) that was not built with PCRE. As such, grep -P returns 2 and prints: grep: support for the -P option is not compiled into this - --disable-perl-regexp binary However, our Git build *does* link against libpcre. This causes a tests numbered 142 and 143 to fail in t7810-grep.sh. I am not sure the best way to handle this but I felt it would be prudent to inform you of this issue. I will be happy to provide any other information you may require. Best, arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYaIycAAoJEMspy1GSK50U/g4P/AtPRfeOv8pENfI/PnlhXqSD C28CR0Hzv4qBv/Ay8vpBfmkM177bBnra5GTcfnAZ0wvxJUiqnkluu+EJ2UWfPNse r5ZbDkXCp42oek+vIi7jYi7UsyNqwyT1DziYLR5PDopT3L8YK7i9pZCQZ+mDSmVT Iu3gYmLvyyEL7r104o6ACRw11P5CDL9bKFmSVacD9UvPL3EjOM9LrSdRDzvJmk0u nqAOH6yw4wknxCWGPA3JT4DM9GD5DB/Y+UmVQrrpA+Txl8gbPjgzb1PX4qogHjNq dNDk1jeKJd/CmwJdAU6eKQ3bgfnIXzLbTDVmaMTMlUUsHzlqE/7QYnrae76ECmmn drmezgKRwTtVgQjQ8l/F/c+EQhux9c0zM9Lz+0Hrd7v1WwohLQDA0xYOE8cCaLw1 8WmXQWjNG1Ih2GpAZH7CRreWyiDAiaAZI2d/zOhsgG9edNEmNn+LkesajVdMywUJ jKlxmKk6qK2uPDPVrD261ODtMxVdptG6/+m24iz56WRERWkkFBpZz15OtrtlLa2E 0LcFiu2f5lki12XDZsSJwkLeGfb6KyxfCPKtGP7TAVAYO43ORQHKhks8pheOMwJa dpL4+72CzkI57LyCtl0NiSMZH2zKUvxp8OqKgE/gpDwbhwh8spAHdUaiaS6emiPj MM6jb7ru9eo4gD6seRCp =R9eQ -END PGP SIGNATURE-
Re: Test failures when Git is built with libpcre and grep is built without it
On 02/01/17 00:53, Jeff King wrote:
> On Sat, Dec 31, 2016 at 10:59:11PM -0600, A. Wilcox wrote:
>
>> I'm attempting to package Git for our new Linux distribution and
>> I have run in to a failure on our PowerPC builder while running
>> the test suite.
>>
>> The PowerPC builder runs a tiny version of grep(1) that was not
>> built with PCRE. As such, grep -P returns 2 and prints:
>>
>> grep: support for the -P option is not compiled into this -
>> --disable-perl-regexp binary
>>
>> However, our Git build *does* link against libpcre. This causes
>> a tests numbered 142 and 143 to fail in t7810-grep.sh.
>
> If we are using "grep -P" in our test suite, it should definitely
> be marked with a prerequisite that is independent of the LIBPCRE
> one.
>
> But I can't find any such place in our test suite. [snip] Can you
> show us the output of "./t7810-grep.sh -v -i"?
>
> -Peff
>
The output of this command was almost 1400 lines, so I attached the log.
Interestingly enough, you seem to be right. The failure is very
bizarre and has nothing to do with system /bin/grep:
test_must_fail: command succeeded: git grep -G -F -P -E a\x{2b}b\x{2a}c ab
not ok 142 - grep -G -F -P -E pattern
#
# >empty &&
# test_must_fail git grep -G -F -P -E "a\x{2b}b\x{2a}c"
ab >actual &&
# test_cmp empty actual
#
However:
elaine trash directory.t7810-grep # git grep -G -F -P -E
a\x{2b}b\x{2a}c ab >actual
fatal: command line, 'ax{2b}bx{2a}c': Invalid contents of {}
elaine trash directory.t7810-grep # echo $?
128
elaine trash directory.t7810-grep # cat actual
elaine trash directory.t7810-grep #
I can reliably reproduce this on our x86_64 builder as well. Note
that our distro is based on the musl libc, not glibc. The shell is:
GNU bash, version 4.3.48(1)-release (powerpc-foxkit-linux-musl)
lrwxrwxrwx 1 root root 4 Dec 29 10:43 /bin/sh -> /bin/bash
Any further assistance would be greatly appreciated; this one really
has me stumped.
Best,
-arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
elaine t # ./t7810-grep.sh -v -i
Initialized empty Git repository in /usr/src/dev-vcs/git-2.7.3-r1/work/git-2.7.3/t/trash directory.t7810-grep/.git/
expecting success:
{
echo foo mmap bar
echo foo_mmap bar
echo foo_mmap bar mmap
echo foo mmap bar_mmap
echo foo_mmap bar mmap baz
} >file &&
{
echo Hello world
echo HeLLo world
echo Hello_world
echo HeLLo_world
} >hello_world &&
{
echo "a+b*c"
echo "a+bc"
echo "abc"
} >ab &&
echo vvv >v &&
echo ww w >w &&
echo x x xx x >x &&
echo y yy >y &&
echo zzz > z &&
mkdir t &&
echo test >t/t &&
echo vvv >t/v &&
mkdir t/a &&
echo vvv >t/a/v &&
{
echo "line without leading space1"
echo " line with leading space1"
echo " line with leading space2"
echo " line with leading space3"
echo "line without leading space2"
} >space &&
git add . &&
test_tick &&
git commit -m initial
[master (root-commit) cfd9fd5] initial
Author: A U Thor
13 files changed, 32 insertions(+)
create mode 100644 ab
create mode 100644 file
create mode 100644 hello.c
create mode 100644 hello_world
create mode 100644 space
create mode 100644 t/a/v
create mode 100644 t/t
create mode 100644 t/v
create mode 100644 v
create mode 100644 w
create mode 100644 x
create mode 100644 y
create mode 100644 z
ok 1 - setup
expecting success:
test_must_fail git grep "("
fatal: unmatched parenthesis
ok 2 - grep should not segfault with a bad input
expecting success:
{
echo ${HC}file:1:foo mmap bar
echo ${HC}file:3:foo_mmap bar mmap
echo ${HC}file:4:foo mmap bar_mmap
echo ${HC}file:5:foo_mmap bar mmap baz
} >expected &&
git -c grep.linenumber=false grep -n -w -e mmap $H >actual &&
test_cmp expected actual
ok 3 - grep -w HEAD
expecting success:
{
echo ${HC}file:1:foo mmap bar
echo ${HC}file:3:foo_mmap bar mmap
echo ${
Re: Test failures when Git is built with libpcre and grep is built without it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
(Hi, musl developers! Read on for some information regarding what
began as a test failure during packaging of Git 2.7.3 that appears to
be related to musl's regexp library.)
On 09/01/17 05:27, Jeff King wrote:
> Are you trying with a version of git older than v2.7.x?
We are using 2.7.3. I will admit the version is a bit old, but it is
working on all other arches (and it took an inordinate amount of time
to spin up PowerPC - hooray for toolchain issues).
On 09/01/17 15:33, Jeff King wrote:
> On Mon, Jan 09, 2017 at 02:05:44PM +0100, Andreas Schwab wrote:
>> You need to quote the regexp argument, see the line starting
>> with "test_must_fail" above.
>
> Oh, duh. I checked that the line in the test was quoted
Guilty of this as well. Sorry about that. With the proper
invocation, I receive a success:
elaine trash directory.t7810-grep # git grep -G -F -P -E
"a\x{2b}b\x{2a}c" ab
error: cannot run less: No such file or directory
ab:a+b*c
elaine trash directory.t7810-grep # echo $?
0
Haven't managed to build less(1) for PowerPC yet, but it does seem to
work when quoted. Yikes!
> The problem is that we are expecting the regex "\x{2b}" to complain
> in regcomp() (as an ERE), but it doesn't. And that probably _is_
> related to musl, which is providing the libc regex (I know this
> looks like a pcre test, but it's checking that "-P -E" overrides
> the pcre option with "-E").
>
> I'm not sure if musl is wrong for failing to complain about a
> bogus regex. Generally making something that would break into
> something that works is an OK way to extend the standard. So our
> test is at fault for assuming that the regex will fail. I guess
> we'd need to find some more exotic syntax that pcre supports, but
> that ERE doesn't. Maybe "(?:)" or something.
>
> -Peff
>
I am cc:ing in the musl development list to see what their thoughts are.
Thanks for the help so far; I really appreciate it. Hopefully we can
resolve this in a way that makes musl and Git's test suite both more
correct, if necessary.
Happy new year!
- --arw
- --
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJYdLk+AAoJEMspy1GSK50Uz9kP/2JUSzSSXkKLy3788aAjgBOq
aTPBqKXLCvnTeBpsymXoGueaJzgDnYP6Xi9tUb/j4JAXqaJKGHXTgz8ixsFQJ4SJ
p7NN1JZXsIVGKWQHcxvEXEIRmBK7T9BQ2Hq6qUuk3n4PM6lbD1Ur3G1rUqIM/z76
5cSkvwgvGuOVYXLwSTTprb6EbbZc6WTgcDECFIl4z7eJ3GihChg+EgH4cTDt3xLD
9VHx++hWoEZXued0g0myENjBMeCiFOpYw1bzxn7d2s8masx/If2TkK0CLdexy2ti
hFV/F7g8etgZSdmrmiaJIudTsY6p46/sm/VmGm+8yPIeR8/8EOBlyhKhz4EidNtA
2dpUUJW/RD4uz9yVNjmWhIHaL10weuNLQLd/Tt5O/0dG422vhJxOwwJL9Vhxw70y
1PprD11+ZUJeWsz91C/Bl9CqHqljDP00QX8w/dbHCDsjeKgfUdksy2iKlHBG0sx3
CbL0EcHeE9BLmqmJi9ED7w78cTmNryemK29WFHUGSwzR99Rv9QlMn+4GCF1s0O3N
UKPCueLpPcNvRK+1WHkAwUC0iV97Un3WI6kyExs9khygIHRd1y/yRhbpxibbz337
FJfOTcT7e/YqML8Nb8EdwECRhdGX5u1tKqaOfBwLC62SKGTPi5qXpjaSPPJcJsrZ
phxFt6a45PPECV3ZsEO1
=PMkh
-END PGP SIGNATURE-
