This came up in #fedora-qa today. The ghc-listsafe package (koji build, bodhi update) is new and about to be pushed stable. The result has been waivered so this isn't extremely urgent.
#fedora-qa
When it was in f27-updates-testing-pending, rpmdeplint was run against it on 2018-02-02 (taskotron.log, Individual build result).
When the build was pushed to f27-updates-pending, rpmdeplint ran again on 2018-02-13 (taskotron.log, Individual build result).
As near as I can tell, nothing relevant changed between 2018-02-02 and 2018-02-13. The repos used are the same, mash hasn't changed since f27 release, there are no relevant haskell packages that changed in that time period and rpmdeplint is the same version.
Why did the 2018-02-13 runs fail? Is this something we should be looking into? Should we still be testing multiarch on everything x86_64 now that i386 is a secondary arch?
The most probably reason is that mash is crashing on some package with rich dependencies and therefore is not finished properly. See:
[libtaskotron:mash_directive.py:149] 2018-02-13 16:44:29 INFO running mash multilib on /var/tmp/taskotron/root/task-zYqfss/downloaded_tag/ [libtaskotron:logger.py:88] 2018-02-13 16:44:31 CRITICAL Traceback (most recent call last): File "/usr/bin/runtask", line 11, in <module> load_entry_point('libtaskotron==0.4.25', 'console_scripts', 'runtask')() File "/usr/lib/python2.7/site-packages/libtaskotron/main.py", line 199, in main overlord.start() File "/usr/lib/python2.7/site-packages/libtaskotron/overlord.py", line 96, in start runner.execute() File "/usr/lib/python2.7/site-packages/libtaskotron/executor.py", line 62, in execute self._run() File "/usr/lib/python2.7/site-packages/libtaskotron/executor.py", line 98, in _run self._do_actions() File "/usr/lib/python2.7/site-packages/libtaskotron/executor.py", line 136, in _do_actions self._do_single_action(action) File "/usr/lib/python2.7/site-packages/libtaskotron/executor.py", line 157, in _do_single_action self.arg_data) File "/usr/lib/python2.7/site-packages/libtaskotron/directives/mash_directive.py", line 183, in process return self.do_mash(rpmdir, dodelta, arch, outdir) File "/usr/lib/python2.7/site-packages/libtaskotron/directives/mash_directive.py", line 150, in do_mash themash.doMultilib() File "/usr/lib/python2.7/site-packages/mash/__init__.py", line 666, in doMultilib pid = self.doDepSolveAndMultilib(arch, repocache) File "/usr/lib/python2.7/site-packages/mash/__init__.py", line 635, in doDepSolveAndMultilib (rc, errors) = yumbase.resolveDeps() File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 911, in resolveDeps CheckDeps, checkinstalls, checkremoves, missing = self._resolveRequires(errors) File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 1027, in _resolveRequires thisneeds = self._checkInstall(txmbr) File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 1146, in _checkInstall _deal_with_req(txmbr, req, True) File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 1126, in _deal_with_req provs = self.tsInfo.getProvides(*req) File "/usr/lib/python2.7/site-packages/yum/transactioninfo.py", line 636, in getProvides result = self.getOldProvides(name, flag, version) File "/usr/lib/python2.7/site-packages/yum/transactioninfo.py", line 629, in getOldProvides for pkg, hits in self.rpmdb.getProvides(name, flag, version).iteritems(): File "/usr/lib/python2.7/site-packages/yum/rpmsack.py", line 1494, in getProvides pkgs = self.searchProvides(name) File "/usr/lib/python2.7/site-packages/yum/rpmsack.py", line 497, in searchProvides ret = self.searchPrco(name, 'provides') File "/usr/lib/python2.7/site-packages/yum/rpmsack.py", line 467, in searchPrco (n,f,(e,v,r)) = misc.string_to_prco_tuple(name) File "/usr/lib/python2.7/site-packages/yum/misc.py", line 745, in string_to_prco_tuple raise Errors.MiscError, 'Invalid version flag: %s' % f MiscError: Invalid version flag: and
https://taskotron.fedoraproject.org/artifacts/all/ae5db2d8-10dc-11e8-8033-525400fc9f92/task_output/taskotron.log.gz
As a result, some i686 packages are kept in and not deleted, and then cause invalid results.
So this is a direct effect or #6. I'll merge them together.
Should we still be testing multiarch on everything x86_64 now that i386 is a secondary arch?
I believe so. i386 packages are still quite important in x86_64 repos, especially for gaming. And they can have an adverse effect on x86_64 packages.
Closing as a duplicate of #6.
Metadata Update from @kparal: - Issue close_status updated to: Duplicate - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.