testing so far

[Greg Troxel]

NetBSD 9 amd64, with python3.9-config patched to have the right rpath
(as it should; missing it is a bug):
- LDFLAGS are wrongly rejected as bogus
- builds and passes tests

NetBSD 5 i386 with gcc7, and python 3.7 (with the rpath bug)
- LDFLAGS wrongly rejected
- build fails because of missing rpath


Adding the two patches just sent:
f1bbfb8 (HEAD -> master, gdt/master) configure.inc: fix LDFLAGS validation
b00a931 Capture ./configure CPPFLAGS for future, automatic runs

then:

NetBSD 9 amd64 is ok:
==== 120 passed, 6 skipped, 1 deselected, 43 warnings in 887.47s (0:14:47) =====

NetBSD 5 i386 fails on "cp -a" but POSIX does not require -a:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html
It looks like "cp -R -p" is the correct form following the
specification. With the cp change, the check phase:
Warning: pandoc not found; skipping manpage generation
dev/validate-python dev/python-proposed
cp -R -p dev/python-proposed dev/python
mkdir test/tmp
./pylint
./pylint: doing nothing given ./configure --with-pylint=no
! bup version # Ensure we can't test the local bup (cf. dev/shadow-bin)
error: something ran "bup"; bup imposter intentionally failing
./bup features
[bup.core produced]
FWIW, 0.32 passed all but one test on this system.
[Yes, I know this is an unreasonably old system.]

[Rob Browning]

Greg Troxel <g...@lexort.com> writes:

> NetBSD 5 i386 fails on "cp -a" but POSIX does not require -a:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html
> It looks like "cp -R -p" is the correct form following the
> specification.

Blarg. I thought I double-checked that when I merged the fix. I really
just need to add a local "cp -a" filter to try to save us from myself.

> With the cp change, the check phase:
> Warning: pandoc not found; skipping manpage generation
> dev/validate-python dev/python-proposed
> cp -R -p dev/python-proposed dev/python
> mkdir test/tmp
> ./pylint
> ./pylint: doing nothing given ./configure --with-pylint=no
> ! bup version # Ensure we can't test the local bup (cf. dev/shadow-bin)
> error: something ran "bup"; bup imposter intentionally failing

So that's a real problem. I'll need to figure out why that's happening.
I added dev/shadow-bin to the front of the PATH so that we can't
accidentally run (and/or test) the locally installed bup. Might have
missed some places.

Thanks for the testing.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[Rob Browning]

Rob Browning <r...@defaultvalue.org> writes:

> So that's a real problem. I'll need to figure out why that's happening.
> I added dev/shadow-bin to the front of the PATH so that we can't
> accidentally run (and/or test) the locally installed bup. Might have
> missed some places.

Oh, wait - that was just the check of the check I added... Nevermind,
should be fine. Maybe I'll add a bit of calmative output just before
the test so future me won't do this again :)

(Or perhaps even just suppress the output there...)

Thanks

[Greg Troxel]

Rob Browning <r...@defaultvalue.org> writes:

> Rob Browning <r...@defaultvalue.org> writes:
>
>> So that's a real problem. I'll need to figure out why that's happening.
>> I added dev/shadow-bin to the front of the PATH so that we can't
>> accidentally run (and/or test) the locally installed bup. Might have
>> missed some places.
>
> Oh, wait - that was just the check of the check I added... Nevermind,
> should be fine. Maybe I'll add a bit of calmative output just before
> the test so future me won't do this again :)

I actually didn't mean to complain about the shadow check (even though I
didn't understand it). What I meant was that bup was dumping core and
the tests failed to run.

But, I figured it out. realpath(3) has a historical behavior from
4.4BSD, where the 2nd arg must be present and the output goes there.
POSIX added the option for it to be NULL and if so the output is
malloced. So NULL 2nd blew up, and when I passed a MAXPATHLEN array the
free blew up. I have adjusted the code to use the 4.4BSD approach,
which is also required by POSIX, and runs on my NetBSD 9 system (tests
in process but some have passed already).

I also need to mess with pytest and $@ because of some shell
differences, but I don't understand that yet, and it only affects tests.

Patch to follow shortly.

I'll let you know test results offlist if they are good, and raise them
here if not.

Here's the NetBSD 5 realpath:
----------------------------------------
REALPATH(3) NetBSD Library Functions Manual REALPATH(3)

NAME
realpath -- returns the canonicalized absolute pathname

LIBRARY
Standard C Library (libc, -lc)

SYNOPSIS
#include <sys/param.h>
#include <stdlib.h>

char *
realpath(const char *pathname, char resolvedname[MAXPATHLEN]);

DESCRIPTION
The realpath() function resolves all symbolic links, extra ``/'' charac-
ters and references to /./ and /../ in pathname, and copies the resulting
absolute pathname into the memory referenced by resolvedname. The
resolvedname argument must refer to a buffer capable of storing at least
MAXPATHLEN characters.

The realpath() function will resolve both absolute and relative paths and
return the absolute pathname corresponding to pathname.

RETURN VALUES
The realpath() function returns resolvedname on success. If an error
occurs, realpath() returns NULL, and resolvedname contains the pathname
which caused the problem.

ERRORS
The function realpath() may fail and set the external variable errno for
any of the errors specified for the library functions chdir(2), close(2),
fchdir(2), lstat(2), open(2), readlink(2) and getcwd(3).

SEE ALSO
getcwd(3)

HISTORY
The realpath() function call first appeared in 4.4BSD.

BUGS
This implementation of realpath() differs slightly from the Solaris
implementation. The 4.4BSD version always returns absolute pathnames,
whereas the Solaris implementation will, under certain circumstances,
return a relative resolvedname when given a relative pathname.

NetBSD 5.2_STABLE August 13, 2005 NetBSD 5.2_STABLE