[AutoQA] #441: conflicts crashes often crashes on fc19
by fedora-badges
#441: conflicts crashes often crashes on fc19
---------------------+-------------------------------------------------
Reporter: tflink | Owner:
Type: defect | Status: new
Priority: major | Milestone: Package Update Acceptance Test Plan
Component: tests | Keywords:
Blocked By: | Blocking:
---------------------+-------------------------------------------------
Looking at the jobstats for 2013-07-24 (roughly, has some of the day
before and the day after), there are a lot of crashes for the conflicts
test on fc19 (86 crashes of 120 runs - 72% failure rate) but not all of
them are failing.
Figure out why the test is crashing so much on fc19 and whether it's worth
fixing.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/441>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
10 years, 9 months
AutoQA Testcase Stats
by Tim Flink
I've been working to revamp the AutoQA infrastructure so that we're not
running completely on F17 clients and after building several new client
machines in staging, I was curious about how well the tests were
running on the new client machines.
I've included the numbers below but 2 things jump out at me:
- #438 is causing problems for repoclosure
- there is a problem with depcheck on f19. the only runs that didn't
crash are the ones without any builds in them. The crash looks
consistent but I don't know what the root cause is.
Note that these numbers reflect execution in staging autotest since I
rebuilt the clients (including the queued jobs that weren't run while
rebuilding), not pass/fail results and not from production. I was only
interested in numbers about execution of the tests (GOOD - executed
cleanly, reported results. ERROR - problems in execution, probably
didn't report results)
Tim
Global Stats
============
2077 Jobs
- 535 fc17
- 760 fc18
- 781 fc19
Crashes
-------
227 Crashes
- 0 fc17
- 80 fc18
- 147 fc19
Passes
-------
1849 Passes
- 535 fc17
- 680 fc18
- 634 fc19
Test Specific Stats
===================
depcheck
363 runs ( 167 GOOD, 196 ERROR )
- 84 fc17 runs ( 84 GOOD, 0 ERROR )
- 151 fc18 runs ( 75 GOOD, 76 ERROR )
- 128 fc19 runs ( 8 GOOD, 120 ERROR )
repoclosure
48 runs ( 27 GOOD, 21 ERROR )
- 7 fc17 runs ( 7 GOOD, 0 ERROR )
- 20 fc18 runs ( 20 GOOD, 0 ERROR )
- 21 fc19 runs ( 0 GOOD, 21 ERROR )
rpmguard
795 runs ( 790 GOOD, 5 ERROR )
- 202 fc17 runs ( 202 GOOD, 0 ERROR )
- 270 fc18 runs ( 268 GOOD, 2 ERROR )
- 323 fc19 runs ( 320 GOOD, 3 ERROR )
rpmlint
795 runs ( 790 GOOD, 5 ERROR )
- 220 fc17 runs ( 220 GOOD, 0 ERROR )
- 301 fc18 runs ( 299 GOOD, 2 ERROR )
- 274 fc19 runs ( 271 GOOD, 3 ERROR )
upgradepath
75 runs ( 75 GOOD, 0 ERROR )
- 22 fc17 runs ( 22 GOOD, 0 ERROR )
- 18 fc18 runs ( 18 GOOD, 0 ERROR )
- 35 fc19 runs ( 35 GOOD, 0 ERROR )
10 years, 9 months
[AutoQA] #442: depcheck crashes on fc19 with AttributeError: 'MetaSackRPMDB' object has no attribute 'returnObsoletePackages'
by fedora-badges
#442: depcheck crashes on fc19 with AttributeError: 'MetaSackRPMDB' object has no
attribute 'returnObsoletePackages'
---------------------+----------------------
Reporter: tflink | Owner:
Type: defect | Status: new
Priority: major | Milestone: Depcheck
Component: tests | Keywords:
Blocked By: | Blocking:
---------------------+----------------------
depcheck is crashing almost every time (116 crashes in 118 runs) on fc19.
The common crash seems to look like this [http://autoqa-
stg.fedoraproject.org/results/242568-autotest/virt10.qa/debug/client.0.DEBUG
example crash log]
Traceback:
{{{
[stderr] Traceback (most recent call last):
[stderr] File "./depcheck", line 112, in <module>
[stderr] profile=opts.profile)
[stderr] File "/usr/share/autotest/tests/depcheck/depcheck_lib.py", line
395, in depcheck_main
[stderr] test_dir=temp_dir, accepted_dir=acc_dir)
[stderr] File "/usr/share/autotest/tests/depcheck/depcheck_lib.py", line
353, in do_depcheck
[stderr] (r, problems) = y.resolveDeps()
[stderr] File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line
908, in resolveDeps
[stderr] if self._checkObsoletes():
[stderr] File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line
1329, in _checkObsoletes
[stderr] for po in self.rpmdb.returnObsoletePackages():
[stderr] AttributeError: 'MetaSackRPMDB' object has no attribute
'returnObsoletePackages'
--------------------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/autoqa/decorators.py", line 72,
in newf
f_result = f(*args, **kwargs) #call the decorated function
File "/usr/share/autotest/tests/depcheck/depcheck.py", line 192, in
run_once
depcheck_output = utils.system_output(cmd, retain_output=True)
File "/usr/share/autotest/common_lib/base_utils.py", line 931, in
system_output
args=args).stdout
File "/usr/share/autotest/common_lib/base_utils.py", line 658, in run
"Command returned non-zero exit status")
CmdError: Command <./depcheck f18-updates -f /var/tmp/tmp3dAvNZ> failed,
rc=1, Command returned non-zero exit status
* Command:
./depcheck f18-updates -f /var/tmp/tmp3dAvNZ
}}}
On the bright side, it seems to not happen on fc18 clients, so we could
work around it in the short term by limiting depcheck scheduling to fc18
clients but that's only going to work for so long.
Figure out how difficult it will be to fix this depcheck crash and whether
or not it's worth fixing in the short term.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/442>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
10 years, 9 months
Re: Need some help with 'AutoQA: depcheck test FAILED on x86_64'
by Tim Flink
On Tue, 23 Jul 2013 18:32:55 +0200
Jiri Popelka <jpopelka(a)redhat.com> wrote:
> Hi,
>
> I've been seeing [1] for couple of recent updates but have no idea
> what's wrong.
> I already added arch specific requirements, but that's not sufficient.
> I tend to think it's false positive because nobody reported any real
> problems with updates so far.
> Can anybody show me what am I missing ? Thanks.
Unfortunately, you're hitting a limitation in the depcheck test.
What's going on is that only the x86_64 builds are being checked when
both the x86_64 and i686 builds are "installed". Since the older i686
build of libsane-hpaio can't coexist with the newer x86_64 build and
isn't being updated, yum correctly (given the test setup) detects a
dependency issue and depcheck fails the update.
With the current depcheck and the current dependencies among the hplip
builds, I don't have a good solution to fix the problem. depcheck works
well in most situations, this is just one of the corner cases that it
trips over. Eventually, we want to replace depcheck with something
better but I don't even have a guess as to when that will happen :(
For future reference, you're likely to get a faster response by sending
test failure questions to qa-devel@ instead of devel@. I happened to
see this email quickly but we're not usually watching devel@ as closely
as qa-devel@ or test@.
Tim
> --
> Jiri
>
> [1]
> http://autoqa.fedoraproject.org/results/620415-autotest/virt06.qa/depchec...
>
10 years, 9 months
Review Request 32: Tests for html template rendering
by Martin Krizek
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-tflink.rhcloud.com/r/32/
-----------------------------------------------------------
Review request for blockerbugs.
Repository: blockerbugs
Description
-------
Simple tests for rendering html templates.
Diffs
-----
testing/test_controllers.py PRE-CREATION
testing/test_bugchange.py 7dfeb80fec3354aa998d02ed18bc94c1bb2e5530
blockerbugs/util/bz_interface.py 5ac5699cf1fcb0f37631c79deeb44c4f8119e51f
blockerbugs/util/bug_sync.py 49cce49740cd6f5b1f430f58c8d1b522e1f0b7e3
blockerbugs/templates/base_nav.html 021ddb3126b4c0f30a231d8d9b32df09c669280e
blockerbugs/models/release.py 2f74a69cec0b7769d4e6c21b7a4a84105c5d8a64
blockerbugs/controllers/main.py 6c3b1de09819fa37fccf6652dbadb43da3a72c63
Diff: http://reviewboard-tflink.rhcloud.com/r/32/diff/
Testing
-------
Thanks,
Ilgiz Islamgulov
10 years, 9 months
Upgrading or Replacing AutoQA
by Tim Flink
Apparently, I'm not paying enough attention to the F20 scheduling
process because the branch date is coming up far faster than I ever
expected (2013-08-06 is the currently listed date). I realize that
isn't set in stone yet but I also think it would be naive to plan on
that date moving back.
AutoQA is currently running on a mix of F17 and F16 clients (mostly
F17, there are only a couple of clients still running on F16) and with
F17 going EOL soon, my hope was to get taskbot up and running soon
enough to depreciate AutoQA before running on F17 was an issue and we
could avoid having to rebuild the AutoQA infrastructure.
With the schedule as it is now, I think that planning for taskbot to be
ready in time for F20 branch is too risky and pretty much impossible in
less than a month. I'm proposing that we take the time to rework the
AutoQA infrastructure so that it is running on a mix of F18 and F19
(maybe some rawhide) instead of leaving it as is.
If we rework the infra, I want to ansible-ize everything. The current
by-hand method of admin is crazy and way too much work to re-deploy or
even run updates on. I also want to tweak the db config a bit in the
hopes that we can get a bit better performance out of autotest in
production.
I'm going to discuss the possible changes with infra and put together a
more detailed proposal but wanted to see if there were any objections
or alternative proposals out there. If you're interested, more help
would also be appreciated :)
Tim
10 years, 9 months
Review Request 34: Tests for html template rendering
by Martin Krizek
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-tflink.rhcloud.com/r/34/
-----------------------------------------------------------
Review request for blockerbugs.
Repository: blockerbugs
Description
-------
Simple tests for rendering html templates.
Diffs
-----
testing/test_controllers.py PRE-CREATION
blockerbugs/util/bug_sync.py 49cce49740cd6f5b1f430f58c8d1b522e1f0b7e3
blockerbugs/templates/base_nav.html 021ddb3126b4c0f30a231d8d9b32df09c669280e
blockerbugs/models/release.py 2f74a69cec0b7769d4e6c21b7a4a84105c5d8a64
blockerbugs/controllers/main.py a8082121576015a86c31bc76ebc17e982062a08b
Diff: http://reviewboard-tflink.rhcloud.com/r/34/diff/
Testing
-------
Thanks,
Ilgiz Islamgulov
10 years, 10 months
[Fedora QA] #367: Display flash messages in appropriate place
by fedora-badges
#367: Display flash messages in appropriate place
--------------------------------------+----------------------------------
Reporter: mkrizek | Owner: tflink
Type: enhancement | Status: new
Priority: minor | Milestone: Undetermined Future
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+----------------------------------
= problem =
Currently flash messages containing information for user are not
displayed.
= analysis =
There should probably be a box right under the header on all pages that
would display flash messages.
= enhancement recommendation =
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/367>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
10 years, 10 months