Your message dated Thu, 31 Oct 2019 23:10:06 +0100 with message-id <[email protected]> and subject line Re: Building in reproducible build has caused the Debian Bug report #908862, regarding Tests fail in some environments to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 908862: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908862 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: src:neutron Version: 2:13.0.0-1 Severity: serious Tags: ftbfs Dear maintainer: I tried to build this package but it failed: -------------------------------------------------------------------------------- [...] debian/rules build-indep pyversions: missing X(S)-Python-Version in control file, fall back to debian/pyversions pyversions: missing debian/pyversions file, fall back to supported versions py3versions: no X-Python3-Version in control file, using supported versions dh build-indep --buildsystem=python_distutils --with python3,systemd dh_update_autotools_config -i -O--buildsystem=python_distutils dh_autoreconf -i -O--buildsystem=python_distutils dh_auto_configure -i -O--buildsystem=python_distutils dh_auto_configure: Please use the third-party "pybuild" build system instead of python-distutils dh_auto_configure: This feature will be removed in compat 12. debian/rules override_dh_auto_build make[1]: Entering directory '/<<PKGBUILDDIR>>' pyversions: missing X(S)-Python-Version in control file, fall back to debian/pyversions pyversions: missing debian/pyversions file, fall back to supported versions [... snipped ...] File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ self.force_reraise() File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise six.reraise(self.type_, self.value, self.tb) File "/usr/lib/python3/dist-packages/six.py", line 693, in reraise raise value File "/usr/lib/python3/dist-packages/neutron_lib/db/api.py", line 179, in wrapped return f(*dup_args, **dup_kwargs) File "/<<PKGBUILDDIR>>/neutron/plugins/ml2/drivers/type_tunnel.py", line 154, in sync_allocations allocs = ctx.session.query(self.model).all() File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 2783, in all return list(self) File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 2935, in __iter__ return self._execute_and_instances(context) File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 2958, in _execute_and_instances result = conn.execute(querycontext.statement, self._params) File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 948, in execute return meth(self, multiparams, params) File "/usr/lib/python3/dist-packages/sqlalchemy/sql/elements.py", line 269, in _execute_on_connection return connection._execute_clauseelement(self, multiparams, params) File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1060, in _execute_clauseelement compiled_sql, distilled_params File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1200, in _execute_context context) File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1409, in _handle_dbapi_exception util.raise_from_cause(newraise, exc_info) File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 203, in raise_from_cause reraise(type(exception), exception, tb=exc_tb, cause=cause) File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 186, in reraise raise value.with_traceback(tb) File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1193, in _execute_context context) File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 508, in do_execute cursor.execute(statement, parameters) oslo_db.exception.DBNonExistentTable: (sqlite3.OperationalError) no such table: ml2_geneve_allocations [SQL: 'SELECT ml2_geneve_allocations.geneve_vni AS ml2_geneve_allocations_geneve_vni, ml2_geneve_allocations.allocated AS ml2_geneve_allocations_allocated \nFROM ml2_geneve_allocations'] (Background on this error at: http://sqlalche.me/e/e3q8) ---------------------------------------------------------------------- Ran 14783 tests in 3712.856s FAILED (failures=292, skipped=1221) make[1]: *** [debian/rules:46: override_dh_install] Error 1 make[1]: Leaving directory '/<<PKGBUILDDIR>>' make: *** [debian/rules:6: binary-indep] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess returned exit status 2 -------------------------------------------------------------------------------- The build was made in my autobuilder with "dpkg-buildpackage -A" on buster but it also fails here in buster and sid: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/neutron.html where you can get a full build log if you need it. If this is really a bug in one of the build-depends, please use reassign and affects, so that this is still visible in the BTS web page for this package. Please re-re-reconsider uploading packages in source-only form (dpkg-buildpackage -S). I can't compare my build log with the official one because there is simply no official build log: https://buildd.debian.org/status/package.php?p=neutron Thanks.
--- End Message ---
--- Begin Message ---Santiago, This is a sad situation... The point of running unit tests at package build time, is to avoid regressions, and to make sure the package is healthy and working. This is the case for this package, where the unit tests are demonstrating the package state, and the fact that it integrates well with the current version of its build-dependencies. The package built well in my laptop with a normal sbuild setup, in the buildd (also with sbuild), builds well in reproducible build in Buster in 2 different environment (see the bullseye builds). I have just tried another time on my laptop, with an up-to-date Sid env, and it worked once more. All of this shows exactly what I intended to do when running unit tests at build time. That's more than enough for me. Now, it fails on "some env", but you can't provide an explanation on what going on, and in what way your build environment is different from the normal sbuild which both I and the buildd network are running, then I don't know what I can do, and it feels like all of this is just a loss of time, especially when knowing that Neutron is otherwise fully working as expected (I use it in production, both the version currently in Buster, and version 15.0.0 currently in Sid/Bullseye). If you understand what's going on, good, I'll accept a patch. Otherwise, if there's nothing I can do, why leaving this bug open? Why should I spend more time on this, rather than adding more features and doing more useful Q/A, or let's say, work more on the Python 2 removal in Bullseye? I spent already a lot of time on this... Cheers, Thomas Goirand (zigo)
--- End Message ---
