September 2011 - autoqa-devel - Fedora Mailing-Lists

[AutoQA] #380: initscripts: scheduled against wrong distro

by fedora-badges

#380: initscripts: scheduled against wrong distro ----------------------+----------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: critical | Milestone: Hot issues Component: tests | Keywords: ----------------------+----------------------------------------------------- James discovered a problem where openssh was upgraded to f17 version on a f15 system. There is probably a bug in initscripts's control.autoqa. But because we plan to remove initscripts soon, we just disabled the test for now as a hotfix on production server. If we don't decide to remove initscripts, we need to fix the bug. {{{ <jlaska> nothing urgent ... just an FYI on something I've come across on the autoqa production test clients <jlaska> last month, a few fc15 test clients were down because an fc17 openssh package was installed on them <jlaska> (which caused ssh logins to fail) <jlaska> I fixed the issue, but wasn't able to figure out the cause <jlaska> the problem surfaced again today <jlaska> Sep 12 15:11:45 Updated: openssh-5.9p1-4.fc17.x86_64 <jlaska> this is on an fedora-release-15-3.noarch <jlaska> system <jlaska> not urgent, I'll correct the problem on affected systems <jlaska> but still not sure how they're getting installed <jlaska> aha! <jlaska> initscripts <jlaska> https://fedorahosted.org/pipermail/autoqa- results/20110912/424699.html <jlaska> and <jlaska> https://fedorahosted.org/pipermail/autoqa- results/20110912/424827.html <jlaska> so initscripts is somehow running on an fc17 systems ... odd .. I thought the control.autoqa prevented that <jlaska> distro = get_distro(autoqa_args['nvrs'][0]) * kparal is back <jlaska> however, the control file only shows autoqa_args['nvr'] (not 'nvrs') ... is that the problem? <jlaska> http://autoqa.fedoraproject.org/results/191601-autotest/10.5.124.160/control <kparal> it is probably really caused by initscripts test <kparal> we're going to remove it soon <jlaska> it is ... but only because the test was incorrectly scheduled against fc15 systems (I think) <kparal> if we don't remove it, I'll look at this issue <jlaska> I'm going to hotfix this to avoid having to fix this again (prior to initscripts removal) <kparal> currently I think it would be easier to just disable initscripts execution <jlaska> I can do that too ... even better! :) <jlaska> just set execute = False in the control.autoqa? <kparal> just delete tests/initscripts on the production server <kparal> or yes, amend control.autoqa <kparal> both works <kparal> I'll create a ticket about this <jlaska> I think I see the bug, but easy for now just to disable <jlaska> added to initscripts/control.autoqa on production ... <jlaska> # Fri Sep 16 12:11:20 UTC 2011 - jlaska <jlaska> # initscripts is incorrectly being scheduled on systems of a different release <jlaska> # (see https://fedorahosted.org/pipermail/autoqa- results/20110912/424827.html) <jlaska> execute = False }}} -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/380> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

12 years, 6 months

1
1
0 / 0

[PATCH 0/3] Autotest API bug fixes

by Lucas Meneghel Rodrigues

This patchset fixes 3 bugs reported by Kamil Paral in January 2011. Sorry for the large delay. I've recently moved autotest to a new project hosting, and migrated the issues. Then I decided working on them, I hope they are still relevant for autoqa. The patchset was also submitted as a pull request on github, for the other autotest maintainers to review. Feel free to comment on it as well: https://github.com/autotest/autotest/pull/25 Lucas Meneghel Rodrigues (3): client.common_lib.base_packages: tar_package - renaming exclude_string client.common_lib.base_utils: Do not hardcode mail server in send_mail() server.hosts.abstract_ssh: Fix hosts.send_file scp fallback client/common_lib/base_packages.py | 20 +++++++++++++++++--- client/common_lib/base_utils.py | 32 +++++++++++++++++++++----------- server/autotest.py | 2 +- server/frontend.py | 30 ++++++++++++++++++++++-------- server/hosts/abstract_ssh.py | 35 ++++++++++++++++++++++++++++++----- 5 files changed, 91 insertions(+), 28 deletions(-) -- 1.7.6

12 years, 6 months

2
5
0 / 0

bodhi tagging issue

by Kamil Paral

Hello Luke, I just found this Bodhi update: https://admin.fedoraproject.org/updates/FEDORA-2011-10263 and I was quite horrified by the Comments section. AutoQA is running tests on it again and again and again, even though it's been pushed long time ago. And it's not the only case: https://admin.fedoraproject.org/updates/FEDORA-2011-10042 https://admin.fedoraproject.org/updates/FEDORA-2011-10248 https://admin.fedoraproject.org/updates/FEDORA-2011-10130 https://admin.fedoraproject.org/updates/FEDORA-2011-10171 https://admin.fedoraproject.org/updates/FEDORA-2011-10031 https://admin.fedoraproject.org/updates/FEDORA-2011-10459 https://admin.fedoraproject.org/updates/FEDORA-2011-9959 When I look at the first one: # koji list-tag-history --build shorewall-4.4.22-2.fc16 Wed Aug 3 19:17:05 2011: shorewall-4.4.22-2.fc16 tagged into f16-updates-candidate by orion Wed Aug 3 19:25:34 2011: shorewall-4.4.22-2.fc16 tagged into f16-updates-testing-pending by bodhi Wed Aug 3 20:52:38 2011: shorewall-4.4.22-2.fc16 untagged from f16-updates-candidate by bodhi Wed Aug 3 20:52:38 2011: shorewall-4.4.22-2.fc16 tagged into f16-updates-testing by bodhi [still active] Wed Aug 3 20:58:03 2011: shorewall-4.4.22-2.fc16 untagged from f16-updates-testing-pending by bodhi Thu Aug 11 01:10:26 2011: shorewall-4.4.22-2.fc16 tagged into f16-updates-pending by bodhi [still active] Sat Aug 20 03:48:00 2011: shorewall-4.4.22-2.fc16 tagged into f16 by bodhi [still active] I believe only 'f16' tag should be active by now. All others should be untagged. AutoQA checks it repeatedly because it's still in updates-pending. Luke, can you have a look at it and find the bug? Currently some people might be getting upset by the email traffic that AutoQA generates for those updates. Thanks, Kamil

12 years, 7 months

2
1
0 / 0

Bogus depcheck failure?

by Adam Williamson

Hey, folks. I noticed the second pair of depcheck fails in this update: https://admin.fedoraproject.org/updates/FEDORA-2011-13024 looks to be bogus - it thinks checkpolicy fails the test because it's already installed in the test environment...is this a known issue? being worked on? i guess it happens when an update is edited to add a new package? thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

12 years, 7 months

2
1
0 / 0

[AutoQA] #381: Depcheck: Better Handling of Modified Updates

by fedora-badges

#381: Depcheck: Better Handling of Modified Updates --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Depcheck Component: tests | Keywords: --------------------+------------------------------------------------------- When an update has builds added to it after being pushed to updates- testing, bodhi_utils ignores any previous test results and trys to re-test the original builds in the update. This causes problems because yum will toss out an "already installed" (ie in the updates-testing repo metadata) build and depcheck will fail it. We should have better detection of this situation and with better parsing of the comments, could set things up so that unmodified builds that passed in previous tests weren't marked as FAILED if they were returned as ignored by yum. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/381> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

12 years, 7 months

1
0
0 / 0

[AutoQA] #353: Create Mockups for AutoQA External Dependencies

by fedora-badges

#353: Create Mockups for AutoQA External Dependencies --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: task | Status: new Priority: major | Milestone: Future tasks Component: core | Keywords: --------------------+------------------------------------------------------- == Description == AutoQA is tightly coupled with Koji and Bobhi. This tight coupling makes it difficult to test AutoQA in isolation. Mocking up Koji and Bodhi would help to isolate AutoQA and provide a controlled environment to run better tests. By mocking up Bodhi and Koji, we can test without modifying more than the Bodhi and Koji URLs in config files. == Basic Design == Koji can be mocked up through its XML-RPC interface and Bodhi can be mocked up through its RESTful interface. Both interfaces can be mocked up using [http://flask.pocoo.org/ Flask] and its [https://bitbucket.org/leafstorm/flask-xml-rpc/ XML-RPC extension]. Both pieces of software are in the Fedora repos. The interfaces wouldn't be complete - just enough to get AutoQA to work. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/353> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

12 years, 7 months

1
9
0 / 0

[AutoQA] #379: autoqa: link to log at admin.fedoraproject.org is wrong, extra space

by fedora-badges

#379: autoqa: link to log at admin.fedoraproject.org is wrong,extra space ----------------------+----------------------------------------------------- Reporter: psklenar | Owner: Type: task | Status: new Priority: major | Milestone: Future tasks Component: core | Keywords: ----------------------+----------------------------------------------------- 1, go to https://admin.fedoraproject.org/updates/stardict-dic- cs_CZ-20110801-1.fc16 2, see comments autoqa - 2011-09-07 07:56:54 AutoQA: upgradepath test PASSED on noarch. Result log: http://autoqa.fedoraproject.org/results/189135-autotest/qa07.qa.fedorapro... /stardict-dic-cs_CZ-2.html (results are informative only) actual results: link is with space .../results /stardict-dic-cs_CZ-2.html expected results: ../results/stardict-dic-cs_CZ-2.html -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/379> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

12 years, 7 months

1
1
0 / 0

Autotest 0.13.1 released!

by Lucas Meneghel Rodrigues

We are proud to announce a new release of autotest, 0.13.1. This is a fairly boring bugfix release, so nothing really new here, just more of the same. What is autotest? Autotest is a framework for fully automated testing. It is designed primarily to test the Linux kernel, though it is useful for many other purposes such as qualifying new hardware, virtualization testing and general user space program testing under linux platforms. It's an open-source project under the GPL and is used and developed by a number of organizations, including Google, IBM, Red Hat, and many others. You can see results of kernel test runs on http://test.kernel.org/tko/ Release repository: http://test.kernel.org/releases/0.13.1/ Release notes: http://autotest.kernel.org/wiki/Release0.13.1 Autotest project main page: http://autotest.kernel.org/ Want to hack on autotest? Please refer to: http://autotest.kernel.org/wiki/DownloadSource http://test.kernel.org/cgi-bin/mailman/listinfo/autotest Please report any issues on our bug tracking system: http://autotest.kernel.org/newticket In order to be able to open tickets on our bug tracking system, refer to: http://autotest.kernel.org/wiki/SiteAminContact

12 years, 7 months

1
0
0 / 0

[AutoQA] #362: Add opt-in email support to anaconda tests

by fedora-badges

#362: Add opt-in email support to anaconda tests --------------------+------------------------------------------------------- Reporter: jlaska | Owner: Type: task | Status: new Priority: major | Milestone: Finger Food Component: tests | Keywords: --------------------+------------------------------------------------------- The anaconda crew has requested notification of installer automated results. I'd like to enable opt-in email notification for compose_tree, anaconda_storage and anaconda_checkbot. Once opt-in support in those tests exists, we can recommend that the anaconda crew [https://jlaska.wordpress.com/2010/06/01/fedora-package-maintainers-want- test-results/ sign-up for result notification]. I'm not sure how to do it, but we have several other tests (rpmguard and rpmlint) that offer this support now. Perhaps the test wrapper for each test needs to somehow call the following ... {{{ # submit results, including email opt-in self.post_results(optin={'pkg': name, 'kojitag': kojitag}) }}} Some things to consider ... when the compose_tree test fails, it's not always the fault of anaconda. Many components are responsible for composing trees (lorax, pungi, anaconda, createrepo, yum etc...). Maybe we at least submit notification for the particular component whose build triggered the test. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/362> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

12 years, 7 months

1
5
0 / 0

Suspicious autoqa failure.

by Peter Jones

Observe the glory that is http://autoqa.fedoraproject.org/results/186817-autotest/10.5.124.164/depc... . This test case is failing because I made grub and grub2 conflict with each other. They should never be installed at the same time (it causes various failures), so this is correct and should not fail. Any advice on what to do here would be appreciated. -- Peter Any connection between your reality and mine is purely coincidental.

12 years, 7 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

autoqa-devel September 2011