August 2011 - autoqa-devel - Fedora mailing-lists

[AutoQA] #371: stop analog daemon after every installation
by fedora-badges 12 Aug '11

12 Aug '11

#371: stop analog daemon after every installation ----------------------+----------------------------------------------------- Reporter: hongqing | Owner: Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: core | Keywords: ----------------------+----------------------------------------------------- rsyslog has to be restarted to get logs from guest every time, from f15, although rsyslog is restarted , but the daemon rsyslogd_6080.pid is still there, this should be killed as rsyslog stops, or the logs will not be transferred to the host. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/371> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

AutoQA Staging Related Proposals
by Tim Flink 11 Aug '11

11 Aug '11

I put together some draft proposals on how I'd like to see us use the new staging environment. As a whole, the two proposals will require a decent amount of time and effort but I've tried to break them up into smaller chunks so that we can start seeing the benefits sooner rather than later. This all makes sense in my head and I think that I've put enough detail into the proposals for them to make sense to everyone else but I'm sure that I forgot some details. Please let me know what parts of this aren't clear and I will add detail and/or clarify. Other comments and/or suggestions are also very welcome. Thanks, Tim AutoQA in a box: - https://fedoraproject.org/wiki/User:Tflink/Sandbox:AutoQA_in_a_box - The idea here is to automate the creation and updating of the AutoQA environment. This would make it easier to setup dev environments and simplify the management of the production infrastructure. AutoQA Staging: - https://fedoraproject.org/wiki/User:Tflink/Sandbox:AutoQA_staging_environme… - This is the longer of the two proposals. I think that it will be good for us in the long run and ties together some of the things that we've talked about for testing AutoQA.

2 2

Error: Can't evaluate test 'initscripts': Distro name not found in glibc-2.14.90-4.1
by James Laska 11 Aug '11

11 Aug '11

Greetings gang, I discovered the following failure while examining cron output for in production. I haven't dug into the issue at all yet, but it seems to be caused by package NVR's that do not contain a %{dist} tag at the end. In this particular case, the package was 'glibc' [1]. I suspect this is not a systemmic problem, but perhaps a conditional check around the get_distro() call? Perhaps something like the following ... diff --git a/tests/initscripts/control.autoqa b/tests/initscripts/control.autoqa index c380c81..d088db1 100644 --- a/tests/initscripts/control.autoqa +++ b/tests/initscripts/control.autoqa @@ -9,8 +9,13 @@ labels = ['virt'] # must be present (like 'fc13'). If proper label is not found the test will not execute if autoqa_args.has_key('nvrs'): from autoqa.util import get_distro - distro = get_distro(autoqa_args['nvrs'][0]) - labels.append(distro) + try: + distro = get_distro(autoqa_args['nvrs'][0]) + except IndexError: + # Optionally emit a warning that no %{dist} string was found? + pass + else: + labels.append(distro) # we want to run initscripts just for post-koji-build if event in ['post-koji-build']: Thanks, James [1] http://koji.fedoraproject.org/koji/packageinfo?packageID=57 ----- Forwarded message from Cron Daemon <root(a)autoqa01.qa.fedoraproject.org> ----- Date: Tue, 9 Aug 2011 13:40:25 +0000 (UTC) From: Cron Daemon <root(a)autoqa01.qa.fedoraproject.org> To: autotest(a)autoqa01.qa.fedoraproject.org Subject: Cron <autotest@autoqa01> /usr/share/autoqa/watchers/koji-bodhi/watcher.py Created job: 'post-koji-build:rpmguard.noarch (id 155001)' Created job: 'post-koji-build:rpmlint.noarch (id 155002)' Created job: 'post-koji-build:rpmguard.noarch (id 155003)' Created job: 'post-koji-build:rpmlint.noarch (id 155004)' File "/usr/bin/autoqa", line 185, in resolve_tests test_vars[test] = eval_test_vars(test, default_test_vars) File "/usr/bin/autoqa", line 147, in eval_test_vars exec cfile in vars File "/usr/share/autotest/client/site_tests/depcheck/control.autoqa", line 12, in <module> distro = get_distro(autoqa_args['nvrs'][0]) File "/usr/lib/python2.6/site-packages/autoqa/util.py", line 253, in get_distro raise ValueError('Distro name not found in %s' % rpmstr) File "/usr/bin/autoqa", line 185, in resolve_tests test_vars[test] = eval_test_vars(test, default_test_vars) File "/usr/bin/autoqa", line 147, in eval_test_vars exec cfile in vars File "/usr/share/autotest/client/site_tests/initscripts/control.autoqa", line 12, in <module> distro = get_distro(autoqa_args['nvrs'][0]) File "/usr/lib/python2.6/site-packages/autoqa/util.py", line 253, in get_distro raise ValueError('Distro name not found in %s' % rpmstr) Error: Can't evaluate test 'depcheck': Distro name not found in glibc-2.14.90-4.1 Error: Can't evaluate test 'initscripts': Distro name not found in glibc-2.14.90-4.1 ----- End forwarded message -----

2 6

[AutoQA] #313: ResultsDB: Script to parse the mailing-list and fill the resultsDB
by fedora-badges 10 Aug '11

10 Aug '11

#313: ResultsDB: Script to parse the mailing-list and fill the resultsDB ----------------------+----------------------------------------------------- Reporter: vhumpa | Owner: vhumpa Type: task | Status: new Priority: major | Milestone: Resultdb Component: resultdb | Keywords: ----------------------+----------------------------------------------------- To continue development and AutoQA/ResultDB integration we need to have ResultsDB filled with relevant data for testing. Later on we might need to put already existing result data into ResultDB when it becomes operational. All the past data sits in the mailing list archives, so let's create a script that will parse the stored mbox file and input the data into ResultDB using it's input API. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/313> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 6

upgradepath bugfix, candidate for 0.6.1
by Kamil Paral 10 Aug '11

10 Aug '11

Hello, I have fixed a bug in upgradepath that demonstrated itself by crashing in certain conditions: commit 62aa5c02e89a7e4e6d442651e927b2f9ac4d9ce2 (HEAD, refs/remotes/origin/master, refs/remotes/origin/HEAD, refs/heads/master) Author: Kamil Páral <kparal(a)redhat.com> Date: Tue Aug 9 14:31:34 2011 +0200 upgradepath: fix crash This fixes a crash when there was no build of the tested package in the stable repository of an older release. You can see it in action here: https://fedorahosted.org/pipermail/autoqa-results/2011-August/181303.html I think it is desirable to push this into production asap. If no other important bugs are found, I'd like to tag, build & deploy 0.6.1 today or tomorrow. Just a heads-up.

2 3

[PATCH] control.autoqa: check for exceptions when using distro_tag()
by Kamil Paral 10 Aug '11

10 Aug '11

--- doc/control.autoqa.template | 7 +++++-- tests/depcheck/control.autoqa | 7 +++++-- tests/initscripts/control.autoqa | 24 +++++++++++------------- 3 files changed, 21 insertions(+), 17 deletions(-) diff --git a/doc/control.autoqa.template b/doc/control.autoqa.template index 435ca40..178ac1d 100644 --- a/doc/control.autoqa.template +++ b/doc/control.autoqa.template @@ -40,5 +40,8 @@ if event in ['post-koji-build']: # correct distribution must be present (like 'fc13') if autoqa_args.has_key('nvrs'): from autoqa.util import get_distro - distro = get_distro(autoqa_args['nvrs'][0]) - labels.append(distro) + try: + distro = get_distro(autoqa_args['nvrs'][0]) + labels.append(distro) + except ValueError: # no distro tag found + execute = False diff --git a/tests/depcheck/control.autoqa b/tests/depcheck/control.autoqa index bdd6041..c3236e4 100644 --- a/tests/depcheck/control.autoqa +++ b/tests/depcheck/control.autoqa @@ -9,5 +9,8 @@ if event in ['post-bodhi-update-batch']: # must be present (like 'fc13') If proper label is not found the test will not execute if autoqa_args.has_key('nvrs'): from autoqa.util import get_distro - distro = get_distro(autoqa_args['nvrs'][0]) - labels.append(distro) + try: + distro = get_distro(autoqa_args['nvrs'][0]) + labels.append(distro) + except ValueError: + execute = False diff --git a/tests/initscripts/control.autoqa b/tests/initscripts/control.autoqa index 51ea825..b7ec70b 100644 --- a/tests/initscripts/control.autoqa +++ b/tests/initscripts/control.autoqa @@ -5,23 +5,11 @@ # virtual machines as a precaution labels = ['virt'] -# because we install the package, the autotest label of the correct distribution -# must be present (like 'fc13'). If proper label is not found the test will not execute -if autoqa_args.has_key('nvrs'): - from autoqa.util import get_distro - try: - distro = get_distro(autoqa_args['nvrs'][0]) - except IndexError: - # FIXME - Optionally emit a warning that no %{dist} string was found? - pass - else: - labels.append(distro) - # we want to run initscripts just for post-koji-build if event in ['post-koji-build']: execute = True -# we also don't want to run this test for packages we currently don't have +# we don't want to run this test for packages we currently don't have # covered or for packages that contain no init scripts at all # let's just look into tests/ directory if we have test available and decide if autoqa_args.has_key('name'): @@ -29,3 +17,13 @@ if autoqa_args.has_key('name'): if autoqa_args['name'] not in os.listdir('tests'): # not supported execute = False + +# because we install the package, the autotest label of the correct distribution +# must be present (like 'fc13'). If proper label is not found the test will not execute +if autoqa_args.has_key('nvrs'): + from autoqa.util import get_distro + try: + distro = get_distro(autoqa_args['nvrs'][0]) + labels.append(distro) + except ValueError: + execute = False -- 1.7.6

1 0

[AutoQA] #372: bad URLs in bodhi comments (extra blank character)
by fedora-badges 09 Aug '11

09 Aug '11

#372: bad URLs in bodhi comments (extra blank character) --------------------+------------------------------------------------------- Reporter: till | Owner: Type: defect | Status: new Priority: major | Milestone: Component: core | Keywords: --------------------+------------------------------------------------------- URLs in bodhi comments contain an extra blank character. For example in this update: https://admin.fedoraproject.org/updates/youtube-dl-2011.08.04-1.fc16 The first comment from AutoQA is: {{{ AutoQA: depcheck test PASSED on x86_64. Result log: http://autoqa.fedoraproject.org/results/150013-autotest/qa01.qa.fedoraproje… /youtube-dl-2011.08.0.html (results are informative only) }}} The URL included in the comment should be http://autoqa.fedoraproject.org/results/150013-autotest/qa01.qa.fedoraproje… /youtube-dl-2011.08.0.html and not http://autoqa.fedoraproject.org/results/150013-autotest/qa01.qa.fedoraproje… youtube-dl-2011.08.0.html -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/372> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #366: remove previous run logs
by fedora-badges 05 Aug '11

05 Aug '11

#366: remove previous run logs ----------------------+----------------------------------------------------- Reporter: hongqing | Owner: Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: autotest | Keywords: ----------------------+----------------------------------------------------- the installation steps are read from anaconda.log, if the previous run anaconda.log exists, the installation test steps will be read from the old one, so the logs should be cleaned before the next run. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/366> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #352: Determine AutoQA Functional Self Test Cases
by fedora-badges 05 Aug '11

05 Aug '11

#352: Determine AutoQA Functional Self Test Cases --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: task | Status: new Priority: major | Milestone: Self Test Component: core | Keywords: --------------------+------------------------------------------------------- In order to start forming a better self test suite for AutoQA, we need to start cataloging situations that will make for good functional regression tests. Instead of focusing on how to get them all run, the idea is to describe the situations that would make for good tests. Formatting and categorizing the tests will be left for another ticket. Examples of jobs that have caused problems in the past or continue to cause strange problems would be helpful. An extremely simplistic example for depcheck might look like: === Package Descriptions === || '''Package''' || '''Depends On''' || || foo-1.0-1 || bar-1.0-1 || || foo-2.0-1 || bar-2.0-1 || === Repo Contents === || '''Name''' || '''Packages''' || || stable || foo-1.0-1, bar-1.0-1 || || pending || foo-2.0-1 || === Expected Results === Failure because foo-2.0-1 depends on bar-2.0-1 which is not available. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/352> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

AutoQA 0.6 released
by Kamil Paral 05 Aug '11

05 Aug '11

Please read: https://kparal.wordpress.com/2011/08/05/autoqa-0-6-released/ Kamil

1 0

A depcheck that got away ...
by James Laska 05 Aug '11

05 Aug '11

Greetings gang, While testing some TC1 installations this morning, I came across a dependency problem that depcheck didn't hit. Thought this might be an interesting case-study. https://admin.fedoraproject.org/updates/libtevent-0.9.13-1.fc16,libldb-1.1.… I'm not entirely sure why depcheck passed, but testing highlighted the following dependency problems: sssd-1.6.0-2.fc16.x86_64 requires libtevent.so.0(TEVENT_0.9.9)(64bit) sssd-1.6.0-2.fc16.x86_64 requires libldb = 1.1.0 The build was updated to include a version of libtevent and libldb to resolve the dependency problem above. Looking through the logs it seems to be searching for deps to satisfy the issues above, but I'm not able to find where it finds them. Thanks, James

2 2

autoqa-0.6.0 released
by James Laska 04 Aug '11

04 Aug '11

Greetings gang, I finished building and deploying autoqa-0.6.0 to production a short while ago. I suspect a wider announcement might be more appropriate, but for now I wanted to let folks know in case any issues surface. Congratulations autoqa team on another release!!! https://fedorahosted.org/autoqa/wiki/Planning060series Thanks, James

1 0

[AutoQA] #330: upgradepath: improve behavior when pushing update to multiple releases
by fedora-badges 04 Aug '11

04 Aug '11

#330: upgradepath: improve behavior when pushing update to multiple releases -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: major | Milestone: 0.5.0 Component: tests | Keywords: -------------------------+-------------------------------------------------- This ticket stems from my talk to mcepl and our following discussion: https://fedorahosted.org/pipermail/autoqa-devel/2011-May/002215.html Package maintainers usually push fixes to many Fedora releases at once. Upgradepath usually fails for all but the highest one. We should improve the output. 1. If upgradepath passes, no changes. 2. If upgradepath fails, check update-pending repos for the failed sections and determine whether the same proposed update is available there. If it is, check upgradepath again and determine whether test would pass if all those proposed updates for all releases were pushed at the same time. Inform the user about it. 3. If the condition in 2) is valid, change FAIL result to NEEDS_INSPECTION. I'll gladly take this ticket when I finish my current work. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/330> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 14

0.6 release readiness
by Kamil Paral 04 Aug '11

04 Aug '11

Hello, we have finished working on some important tickets. I want to discuss the readiness to release AutoQA 0.6.0. See the current tickets: https://fedorahosted.org/autoqa/milestone/0.6.0 Please note that ticket #330, albeit not yet closed, is also finished. I just want to amend the documentation only closely before the release. Important finished tickets that I'd like to see in production soon: * Depcheck - prefilter the list of packages passed to yum instance's rpmdb https://fedorahosted.org/autoqa/ticket/349 * upgradepath: improve behavior when pushing update to multiple releases https://fedorahosted.org/autoqa/ticket/330 Almost finished tickets: * Custom 404 page for autoqa.fp.o https://fedorahosted.org/autoqa/ticket/354 The rest of the tickets will probably take some more time and are not ready yet. I think that #354 is easy enough to be finished in a day. I propose waiting for that one and then releasing 0.6.0. That means that 0.6.0 would be released some day this week. The rest of the tickets would move to 0.7 (or more precisely - we'll discuss that at 0.7 planning stage). Comments?

4 7

stray pending builds in Bodhi
by Kamil Paral 04 Aug '11

04 Aug '11

Hello Luke, again we find quite a lot incorrectly tagged builds in Bodhi (still in pending, but same or newer version is already available in stable repos). Can you please find the bug? Stray builds I found in the last 10 minutes: ibus-1.3.99.20110419-2.fc15 in dist-f15-updates-pending icedtea-web-1.0.4-1.fc15 in dist-f15-updates-pending wordpress-3.1.3-3.fc15 in dist-f15-updates-pending wordpress-3.1.3-3.fc14 in dist-f14-updates-pending Thank you, Kamil

1 0

[AutoQA] #348: anaconda upgrade test
by fedora-badges 04 Aug '11

04 Aug '11

#348: anaconda upgrade test ----------------------+----------------------------------------------------- Reporter: hongqing | Owner: hongqing Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: core | Keywords: ----------------------+----------------------------------------------------- To implement test case: https://fedoraproject.org/wiki/QA:Testcase_Anaconda_Upgrade_New_Bootloader . we have already implemented Fedora installation automation from DVD, next step we will upgrade the previous release. "virsh' will be used to operate on the guest. [[BR]] The tasks include:[[BR]] * define upgrade steps [[BR]] * install previous release [[BR]] * modify guest xml to boot from new release[[BR]] * upgrade -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/348> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

F16 test clients available
by James Laska 03 Aug '11

03 Aug '11

Greetings folks, Just a quick heads up, I just added two new virt test clients to our production instance. With Fedora 16 branched, these new F16 clients should help handle some test load. Installing these systems required significant workarounds. While I expect things are working properly, let me know if you're seeing any strange results from these systems. $ atest host list -b fc16 Host Status Locked Platform Labels 10.5.124.163 Ready False i386 fc16, virt 10.5.124.164 Ready False x86_64 fc16, virt Thanks, James

1 0

[AutoQA] #354: Custom 404 page for autoqa.fp.o
by fedora-badges 03 Aug '11

03 Aug '11

#354: Custom 404 page for autoqa.fp.o ----------------------+----------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: minor | Milestone: 0.6.0 Component: autotest | Keywords: ----------------------+----------------------------------------------------- Quoting tflink: For some reason, this came to mind when I was thinking about the bodhi link issue but how do we feel about putting a custom 404 on autoqa.fp.o? Since we don't keep logs forever, anything that links to old results goes to a generic 404 without more explanation than "could not find the file you were looking for". Instead, we could do a custom 404 that contains: - Explanation of log retention policy - Relevant AutoQA or FedoraQA links It would involve a small change to the apache config and some static HTML on the autotest server. Pretty easy finger food :) https://fedorahosted.org/pipermail/autoqa-devel/2011-July/002546.html -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/354> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 11

[AutoQA] #102: post-iso-build hook
by fedora-badges 02 Aug '11

02 Aug '11

#102: post-iso-build hook ----------------------+----------------------------------------------------- Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: watchers | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- We need one (or more) standard locations where new iso images get posted for testing, and a watcher that can monitor for new iso images and launch appropriate installation/sanity tests. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/102> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #369: use watcher.py to download iso images to local nfs server
by fedora-badges 02 Aug '11

02 Aug '11

#369: use watcher.py to download iso images to local nfs server ----------------------+----------------------------------------------------- Reporter: hongqing | Owner: hongqing Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: core | Keywords: ----------------------+----------------------------------------------------- since the different time zone, the Fedora releases are usually published at night, and the download speed is limited in China office, it usually cost the more than half a day to download the images. luckily, watcher.py can watch the iso images on dl.fp.o, so it can be used to download the remote images to local nfs server. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/369> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #209: complete auto CD install test driver
by fedora-badges 02 Aug '11

02 Aug '11

#209: complete auto CD install test driver -------------------+-------------------------------------------------------- Reporter: liam | Owner: Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: tests | Version: 1.0 Keywords: | -------------------+-------------------------------------------------------- complete the cd_install.py as dvd_install.py to support CD install, with some functions like automatically swap CD when CD1 install was completed. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/209> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #365: update mediakit_sanity.py to accept different images, DVD, Live, netinst.iso
by fedora-badges 02 Aug '11

02 Aug '11

#365: update mediakit_sanity.py to accept different images, DVD, Live, netinst.iso -------------------------+-------------------------------------------------- Reporter: hongqing | Owner: hongqing Type: enhancement | Status: new Priority: minor | Milestone: Automate installation test plan Component: tests | Keywords: -------------------------+-------------------------------------------------- mediakit_sanity test covers the DVD.iso sanity test cases. But the Live.iso and netinst.iso are different with DVD.iso, they cannot be done repoclosure and fileconficts tests. mediakit_sanity should be updated to accept Live.iso and netinst.iso sanity tests. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/365> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

Very Rough Code for Mock Fedora Infrastructure
by Tim Flink 01 Aug '11

01 Aug '11

This kept falling off my TODO list, but I finally got what I have for initial mock Fedora infrastructure code up on github:

4 6

[AutoQA] #364: test.py: 'Unknown result keyword' handling in cmp_result()
by fedora-badges 01 Aug '11

01 Aug '11

#364: test.py: 'Unknown result keyword' handling in cmp_result() ----------------------+----------------------------------------------------- Reporter: pschindl | Owner: Type: defect | Status: new Priority: minor | Milestone: Finger Food Component: core | Keywords: ----------------------+----------------------------------------------------- Test.py raise exception when unknown result keyword is used in PrettyLog.summary_detail dictionary: {{{ Traceback (most recent call last): File "/usr/share/autotest/client/bin/parallel.py", line 18, in fork_start l() File "/usr/share/autotest/client/bin/job.py", line 522, in <lambda> l = lambda : test.runtest(self, url, tag, args, dargs) File "/usr/share/autotest/client/bin/test.py", line 115, in runtest job.sysinfo.log_after_each_iteration) File "/usr/share/autotest/client/common_lib/test.py", line 710, in runtest mytest._exec(args, dargs) File "/usr/share/autotest/client/common_lib/test.py", line 419, in _exec _call_test_function(self.execute, *p_args, **p_dargs) File "/usr/share/autotest/client/common_lib/test.py", line 630, in _call_test_function raise error.UnhandledTestFail(e) UnhandledTestFail: Unhandled ValueError: tuple.index(x): x not in tuple Traceback (most recent call last): File "/usr/share/autotest/client/common_lib/test.py", line 623, in _call_test_function return func(*args, **dargs) File "/usr/share/autotest/client/common_lib/test.py", line 291, in execute postprocess_profiled_run, args, dargs) File "/usr/share/autotest/client/common_lib/test.py", line 215, in _call_run_once self.postprocess_iteration() File "/usr/lib/python2.7/site-packages/autoqa/test.py", line 135, in postprocess_iteration self.post_results() File "/usr/lib/python2.7/site-packages/autoqa/test.py", line 183, in post_results logname = self._write_log(test_detail) File "/usr/lib/python2.7/site-packages/autoqa/test.py", line 313, in _write_log log.write(test_detail.create_output(full_log=full_log)) File "/usr/lib/python2.7/site-packages/autoqa/test.py", line 561, in create_output return self.log.create() File "/usr/lib/python2.7/site-packages/autoqa/pretty_log.py", line 245, in create summary_detail = self._make_summary_detail() File "/usr/lib/python2.7/site-packages/autoqa/pretty_log.py", line 87, in _make_summary_detail cmp=lambda x,y: td.cmp_result(x,y)) File "/usr/lib/python2.7/site-packages/autoqa/pretty_log.py", line 87, in <lambda> cmp=lambda x,y: td.cmp_result(x,y)) File "/usr/lib/python2.7/site-packages/autoqa/test.py", line 499, in cmp_result index1 = self.result_order.index(result1) if result1 is not None else -1 ValueError: tuple.index(x): x not in tuple }}} Problem is in cmp_result() from test.py. It compares only results which are in result_order tuple. We can write some reasonable error message or we can rewrite cmp_result to handle this problem (then it is needed to check if it won't break something). -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/364> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 5

[AutoQA] #349: Depcheck - prefilter the list of packages passed to yum instance's rpmdb
by fedora-badges 01 Aug '11

01 Aug '11

#349: Depcheck - prefilter the list of packages passed to yum instance's rpmdb ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: major | Milestone: 0.6.0 Component: core | Keywords: ----------------------+----------------------------------------------------- Recent problem with libreport <http://autoqa.fedoraproject.org/results/140482-autotest/172.16.0.20/depchec…> is most probably caused by depcheck selecting too old packages (i.e. ignoring the newest packages in repos) due to the fact that YUM selects packages alphabeticaly on fist-comes-first served basis. Because YUM is hacked into believing that all packages are installed by passing the content of _whole_ pkgsack into the rpmdb, it contains multiple versions of the same package. I belive, that this can be easily solved by pre-filtering the list, so it contains only the newest from each package. <code> # This YumBase object will act like all repo packages are already installed y = YumDepcheck() y.tsInfo = yum.transactioninfo.TransactionData() y.tsInfo.debug = 1 # this line is causing the problems y.rpmdb = MetaSackRPMDB(yum_repos.pkgSack) y.xsack = yum.packageSack.PackageSack() # Hacky way to set up the databases (this is copied from yum's testbase.py) y.tsInfo.setDatabases(y.rpmdb, y.xsack) </code> the yum_repos.pkgSack is a list of tuples NAEVR <code>[('libreport', 'x86_64', '0', '2.0.2', '5.fc15'), ('libreport', 'i686', '0', '2.0.2', '5.fc15'), ('libreport', 'x86_64', '0', '2.0.4', '1.fc15'), ('libreport', 'i686', '0', '2.0.4', '1.fc15')]</code> After the filtering, only the newest package for each architecture should be left. Newest = the first while sorting using E,V,R as keys with decreasing importance in this order. I.e. <code> [('libreport', 'x86_64', '0', '2.0.4', '1.fc15'), ('libreport', 'i686', '0', '2.0.4', '1.fc15')]</code>. koji_utils.compareEVR() can be used to compare EVRs. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/349> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

autoqa-devel August 2011