Bug#952610: fixed in meson 0.53.2-2
On Tue, 10 Mar 2020 at 11:30, Gianfranco Costamagna wrote: > > Can you test if the issue is fixed fro you if you add > > stderr=subprocess.DEVNULL to debcrossgen line 38? > > > > ./debian/tests/crossbuild 1> /dev/null > 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 D'oh, that line number should have been 83, not 38. :facepalm:
Bug#952610: fixed in meson 0.53.2-2
Hello,
On Tue, 3 Mar 2020 23:01:41 +0200 Jussi Pakkanen wrote:
> On Mon, Mar 2, 2020 at 4:27 PM Gianfranco Costamagna
> wrote:
>
> > 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
>
> Can you test if the issue is fixed fro you if you add
> stderr=subprocess.DEVNULL to debcrossgen line 38?
>
./debian/tests/crossbuild 1> /dev/null
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
looks like nothing changed.
cat /usr/share/meson/debcrossgen
#! /usr/bin/python3
# Copyright 2017 Jussi Pakkanen
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
# http://www.apache.org/licenses/LICENSE-2.0
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
import sys, os, subprocess
import argparse
parser = argparse.ArgumentParser(description='''Generate cross compilation
definition file for the Meson build system.
If you do not specify the --arch argument, Meson assumes that running
plain 'dpkg-architecture' will return correct information for the
host system.
This script must be run in an environment where CPPFLAGS et al are set to the
same values used in the actual compilation.
'''
)
parser.add_argument('--arch', default=None,
help='The dpkg architecture to generate.')
parser.add_argument('--gccsuffix', default="",
help='A particular gcc version suffix if necessary.')
parser.add_argument('-o', required=True, dest='outfile',
help='The output file.')
stderr=subprocess.DEVNULL
def locate_path(program):
if os.path.isabs(program):
[...]
Bug#952610: fixed in meson 0.53.2-2
> Maybe the autopkg dependency lookup code gets confused by @builddeps@ somehow? Right, that's an known limitation of the autopkgtest infrastructure at the moment, builddepds resolve fine for installing packages in the test environement but fail to register triggers. You can workaround by adding manually the packages though which the patch is doing
Bug#952610: fixed in meson 0.53.2-2
On Mon, Mar 2, 2020 at 4:27 PM Gianfranco Costamagna wrote: > 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 Can you test if the issue is fixed fro you if you add stderr=subprocess.DEVNULL to debcrossgen line 38? > > 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. That is strange, because if you look at the install log for Ubuntu tests: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/m/meson/20200303_171925_00939@/log.gz both valac and rustc are installed. Maybe the autopkg dependency lookup code gets confused by @builddeps@ somehow?
Bug#952610: fixed in meson 0.53.2-2
Hello! On Mon, 2 Mar 2020 13:45:31 +0200 Jussi Pakkanen wrote: > On Mon, Mar 2, 2020 at 1:15 PM Gianfranco Costamagna > 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 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 (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
Bug#952610: fixed in meson 0.53.2-2
On Mon, Mar 2, 2020 at 1:15 PM Gianfranco Costamagna 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. That being said, does this happen on all platforms or only a subset of them? > 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. > 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.
Processed: Re: Bug#952610: fixed in meson 0.53.2-2
Processing control commands:
> reopen -1
Bug #952610 {Done: Jussi Pakkanen } [src:meson] meson:
autopkgtests regressions
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions meson/0.53.2-2.
> notfixed -1 0.53.2-2
Bug #952610 [src:meson] meson: autopkgtests regressions
Ignoring request to alter fixed versions of bug #952610 to the same values
previously set
> tags -1 patch
Bug #952610 [src:meson] meson: autopkgtests regressions
Added tag(s) patch.
--
952610: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952610
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#952610: fixed in meson 0.53.2-2
control: reopen -1
control: notfixed -1 0.53.2-2
control: tags -1 patch
>* Fix autopkgtest dependencies. Closes: #952610
unfortunately I was testing the patch only this morning, and I saw your upload.
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 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)
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!
thanks a lot
Gianfranco
diff -Nru meson-0.53.2/debian/changelog meson-0.53.2/debian/changelog
--- meson-0.53.2/debian/changelog 2020-02-28 23:20:11.0 +0100
+++ meson-0.53.2/debian/changelog 2020-03-02 12:05:06.0 +0100
@@ -1,9 +1,45 @@
+meson (0.53.2-2ubuntu1) focal; urgency=medium
+
+ * Merge from Debian unstable. Remaining changes:
+- add debian/patches/6703.patch
+- Allow stderr for new test
+- depend on rustc and valac, so autopkgtests can pick them up
+
+ -- Gianfranco Costamagna Mon, 02 Mar 2020
12:05:06 +0100
+
meson (0.53.2-2) unstable; urgency=medium
* Fix autopkgtest dependencies. Closes: #952610
-- Jussi Pakkanen Sat, 29 Feb 2020 00:20:11 +0200
+meson (0.53.2-1ubuntu4) focal; urgency=medium
+
+ * Also allow stderr
+
+ -- Gianfranco Costamagna Mon, 02 Mar 2020
11:58:04 +0100
+
+meson (0.53.2-1ubuntu3) focal; urgency=medium
+
+ * debian/patches/6703.patch
+- use upstream proposed approach instead of use_python3_tests.patch
+ * Tweak debian tests/control to fix another test failure (Closes: #952610)
+- patch taken from bug report
+
+ -- Gianfranco Costamagna Mon, 02 Mar 2020
07:24:25 +0100
+
+meson (0.53.2-1ubuntu1) focal; urgency=medium
+
+ [ Stefano Rivera ]
+ * debian/patches/use_python3_tests.patch:
+- Update use_python3_tests.patch to catch one more python binary use.
+
+ [ Rico Tzschichholz ]
+ * debian/tests/control:
+- Explicit depends on rustc and valac, so autopkgtests can pick it up
+
+ -- Rico Tzschichholz Wed, 26 Feb 2020 12:42:13 +0100
+
meson (0.53.2-1) unstable; urgency=medium
* New upstream release. Closes: #950020, #951487
diff -Nru meson-0.53.2/debian/patches/6703.patch
meson-0.53.2/debian/patches/6703.patch
--- meson-0.53.2/debian/patches/6703.patch 1970-01-01 01:00:00.0
+0100
+++ meson-0.53.2/debian/patches/6703.patch 2020-03-02 07:44:52.0
+0100
@@ -0,0 +1,46 @@
+Origin: https://github.com/mesonbuild/meson/pull/6703
+--- meson-0.53.2.orig/run_unittests.py
meson-0.53.2/run_unittests.py
+@@ -6650,9 +6650,9 @@ class NativeFileTests(BasePlatformTests)
+ '--native-file', config, '--native-file', config2,
+ '-Dcase=find_program'])
+
+-def _simple_test(self, case, binary):
++def _simple_test(self, case, binary, entry=None):
+ wrapper = self.helper_create_binary_wrapper(binary, version='12345')
+-config = self.helper_create_native_file({'binaries': {binary:
wrapper}})
++config = self.helper_create_native_file({'binaries': {entry or
binary: wrapper}})
+ self.init(self.testcase, extra_args=['--native-file', config,
'-Dcase={}'.format(case)])
+
+ def test_find_program(self):
+@@ -6675,16 +6675,21 @@ class NativeFileTests(BasePlatformTests)
+ # python module breaks. This is fine on other OSes because they
+ # don't need the extra indirection.
+ raise unittest.SkipTest('bat indirection breaks internal sanity
checks.')
+-if os.path.exists('/etc/debian_version'):
+-rc = subprocess.call(['pkg-config', '--cflags', 'python2'],
+- stdout=subprocess.DEVNULL,
+- stderr=subprocess.DEVNULL)
+-if rc != 0:
+-# Python 2 will be removed in Debian Bullseye, thus we must
+-# remove the build dependency on python2-dev. Keep the tests
+-# but only run them if dev packages are available.
++elif is_osx():
++binary = 'python'
++else:
++binary = 'python2'
++
++# We not have python2, check for it
++for v in ['2', '2.7', '-2.7']:
++rc = subprocess.call(['pkg-config', '--cflags',
'python{}'.format(v)],
++ stdout=subprocess.DEVNULL,
++ stderr=subprocess.DEVNULL)
++if rc == 0:
++break
++else:
+ raise unittest.SkipTest('Not running Python 2
