Hello!
On Mon, 2 Mar 2020 13:45:31 +0200 Jussi Pakkanen <jpakk...@gmail.com> wrote:
> On Mon, Mar 2, 2020 at 1:15 PM Gianfranco Costamagna
> <locutusofb...@debian.org> wrote:
>
> > The following patch is not enough, because of something printed on stderr.
> >
> > I'm attaching a "fix" (better would be do not throw stuff on stderr)
> > crossbuild FAIL stderr: dpkg-architecture: warning: specified GNU
> > system type arm-linux-gnueabihf does not match CC system type
> > x86_64-linux-gnu, try setting a correct CC environment variable
>
> I hate, hate, hate, hate this feature. It is the stupidest policy
> choice and for some reason many test frameworks do that, sometimes
> even silently. The only thing this accomplishes is that people will
> run their tests with a wrapper script that does ./realcommand 2>&1,
> because if you call any external program then you have lost control of
> what gets printed to stderr. Some of those programs are chatty. The
> proper way of detecting failures is the exit code.
this breaks with newer compilers, newer pythons and newer glibc, and newer foo,
so I feel your pain and frustration there...
>
> That being said, does this happen on all platforms or only a subset of them?
>
lets see the sum of the issues without the stderr change
amd64:
crossbuild FAIL stderr: dpkg-architecture: warning: specified GNU
system type arm-linux-gnueabihf does not match CC system type
powerpc64le-linux-gnu, try setting a correct CC environment variable
arm64:
concurrent.futures.process._RemoteTraceback:
"""
Traceback (most recent call last):
File "/tmp/autopkgtest.LjDpNW/build.Q9G/src/mesonbuild/build.py", line 2485,
in load
obj = pickle.load(f)
AttributeError: Can't get attribute 'GnuBFDDynamicLinker' on <module
'mesonbuild.linkers' from
'/tmp/autopkgtest.LjDpNW/build.Q9G/src/mesonbuild/linkers.py'>
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.8/concurrent/futures/process.py", line 239, in
_process_worker
r = call_item.fn(*call_item.args, **call_item.kwargs)
File "run_project_tests.py", line 358, in run_test
return _run_test(testdir, build_dir, install_dir, extra_args, compiler,
backend, flags, commands, should_fail)
File "run_project_tests.py", line 420, in _run_test
builddata = build.load(test_build_dir)
File "/tmp/autopkgtest.LjDpNW/build.Q9G/src/mesonbuild/build.py", line 2491,
in load
raise MesonException(
mesonbuild.mesonlib.MesonException: Build data file
'/tmp/autopkgtest.LjDpNW/build.Q9G/src/b e364311df7/meson-private/build.dat'
references functions or classes that don't exist. This probably means that it
was generated with an old version of meson. Try running from the source
directory meson /tmp/autopkgtest.LjDpNW/build.Q9G/src/b e364311df7 --wipe
"""
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "run_project_tests.py", line 969, in <module>
(passing_tests, failing_tests, skipped_tests) = run_tests(all_tests,
'meson-test-run', options.failfast, options.extra_args)
File "run_project_tests.py", line 699, in run_tests
return _run_tests(all_tests, log_name_base, failfast, extra_args)
File "run_project_tests.py", line 759, in _run_tests
result = result.result()
File "/usr/lib/python3.8/concurrent/futures/_base.py", line 439, in result
return self.__get_result()
File "/usr/lib/python3.8/concurrent/futures/_base.py", line 388, in
__get_result
raise self._exception
mesonbuild.mesonlib.MesonException: Build data file
'/tmp/autopkgtest.LjDpNW/build.Q9G/src/b e364311df7/meson-private/build.dat'
references functions or classes that don't exist. This probably means that it
was generated with an old version of meson. Try running from the source
directory meson /tmp/autopkgtest.LjDpNW/build.Q9G/src/b e364311df7 --wipe
armhf: no issues no stderr
ppc64el: dpkg-architecture: warning: specified GNU system type
arm-linux-gnueabihf does not match CC system type powerpc64le-linux-gnu, try
setting a correct CC environment variable
s390x: Package g++-arm-linux-gnueabihf is not available, but is referred to by
another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'g++-arm-linux-gnueabihf' has no installation candidate
crossbuild FAIL badpkg
blame: meson
badpkg: Test dependencies are unsatisfiable. A common reason is that your
testbed is out of date with respect to the archive, and you need to use a
current testbed or run apt-get update or use -U.
autopkgtest [08:34:34]: @@@@@@@@@@@@@@@@@@@@ summary
you can see results here:
http://autopkgtest.ubuntu.com/packages/meson
note: version 0.53.2-2ubuntu1 is the version from sid + the patch attached to
this email
while version 0.53.2-1ubuntu3 is the version 0.53.2-1ubuntu3 is the version
0.53.2-1 from sid with the patch, except for the allow-stderr keyword
> > I also cherry-picked an upstream test failure when python is removed and
> > changed to python2 (a change that is retro-compatible, and will break also
> > Debian on the next few days)
>
> Please file this as a pull request upstream. All big changes like
> these should go in master first.
ehm it is already on master (I had to rebase it because it doesn't apply
cleanly)
the patch name is exactly the merged pull request
https://github.com/mesonbuild/meson/pull/6703
>
> > Also, please depend on rustc and valac on autopkgtests, so on
> > each new rustc and valac upstream releases, meson autopkgtests will be
> > triggered for regressions!
>
> That should already be happening. AFAIUI the exhaustive test has a
> dependency on all build deps of Meson, which includes valac and rustc.
>
nack on this. Fortunately there is a valac in unstable but not in testing, and
you can see there is no mention of meson autopkgtest against it.
https://tracker.debian.org/pkg/vala
G.
