autoqa-devel March 2011

autoqa-devel@lists.fedorahosted.org

10 participants
103 discussions

[AutoQA] #293: CmdError: No more mirrors to try
by fedora-badges 11 Apr '11

11 Apr '11

#293: CmdError: No more mirrors to try ------------------------+--------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: production | Keywords: ------------------------+--------------------------------------------------- Occasionally (more often recently) some test ends with "CRASHED: CmdError ... returned non-zero exit status" and the cause is Yum Exception "No more mirrors to try". Usually I see this error when my network connection is down. The question is: 1. if this is the case 2. how did we receive the log results back in that case 3. why it is happening Search for CmdError here for examples: https://fedorahosted.org/pipermail/autoqa-results/2011-March/thread.html And a concrete example: https://fedorahosted.org/pipermail/autoqa-results/2011-March/087278.html [[BR]] https://fedorahosted.org/pipermail/autoqa-results/2011-March/096910.html -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/293> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 12

[AutoQA] #218: re-use fedora-qa script for checking PackageReviewGuidelines
by fedora-badges 07 Apr '11

07 Apr '11

#218: re-use fedora-qa script for checking PackageReviewGuidelines --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Future test cases Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- Aurélien Bompard has written a "fedora-qa" tool, which checks all the MUST items in !PackageReviewGuidelines that are not covered by rpmlint. http://fedoraproject.org/wiki/AurelienBompard#QA There's a high possibility that we could re-use parts of his code for several new AutoQA test cases. Worth investigating. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/218> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #294: Detect required Fedora releases correctly
by fedora-badges 06 Apr '11

06 Apr '11

#294: Detect required Fedora releases correctly --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: minor | Milestone: 0.5.0 Component: core | Keywords: --------------------+------------------------------------------------------- Currently we use this approach in control.autoqa to require a specific Fedora release for a test run: {{{ # if we want to install the package, we must have this test running on # Fedora release corresponding to the package; thus the autotest label of the # correct distribution must be present (like 'fc13'); let's strip it from the # NVR (last part) if autoqa_args.has_key('nvr'): labels.append(autoqa_args['nvr'].split('.')[-1]) }}} That is incorrect, because the package may look like foo-1.1-1.i686.fc15.1 . We have to use a different way. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/294> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 5

[PATCH] Update to 0.4.4-0.2.pre
by James Laska 05 Apr '11

05 Apr '11

--- autoqa.spec | 14 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/autoqa.spec b/autoqa.spec index 73ae957..ffe22c2 100644 --- a/autoqa.spec +++ b/autoqa.spec @@ -6,7 +6,7 @@ Name: autoqa Summary: Automated quality assurance framework Version: 0.4.4 -Release: 0.1.pre%{?dist} +Release: 0.2.pre%{?dist} Source0: http://fedorahosted.org/autoqa/releases/%{name}-%{version}.tar.gz License: GPLv2+ Group: Applications/Internet @@ -65,6 +65,18 @@ rm -rf $RPM_BUILD_ROOT %changelog +* Tue Mar 08 2011 James Laska <jlaska(a)redhat.com> - 0.4.4-0.2.pre +- upgradepath: run on post-bodhi-update-batch, test all updates, send bodhi + comments (kparal) +- depcheck: enable scheduling for -batch event (jskladan) +- Stop using epoch in NVR variables (kparal, jskladan) +- Replace old bodhi watcher with new koji watcher (jskladan) +- Ticket#269 - update repoinfo.conf for Fedora 15 branch (jlaska) +- Add a setup method to the no-swap-lvm test suite. (clumens) +- Update documentation in testclass template regarding email subject (kparal) +- bodhi_already_commented() does not require user arg anymore (kparal) +- New test - depcheck (wwoods) + * Tue Jan 25 2011 James Laska <jlaska(a)redhat.com> - 0.4.4-0.1.pre - Add BuildRequire: autotest (jlaska) - Copy config files to clients in a better way (jlaska) -- 1.7.4.1

2 14

[AutoQA] #268: Rename lib/python to lib/autoqa
by fedora-badges 05 Apr '11

05 Apr '11

#268: Rename lib/python to lib/autoqa ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: minor | Milestone: Finger Food Component: core | Keywords: ----------------------+----------------------------------------------------- It would make more sense to have it named as 'autoqa' rather than 'python' - e.g. when we want to import the library from inside the git, etc. Of course, adequate changes need to be made in Makefile and autoqa.spec -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/268> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

3 7

[AutoQA] #295: Provide proper functions for ENVRA manipulation
by fedora-badges 04 Apr '11

04 Apr '11

#295: Provide proper functions for ENVRA manipulation -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Finger Food Component: core | Keywords: -------------------------+-------------------------------------------------- Some testcases need to manipulate ENVRA names, like stripping epoch, stripping architecture, detecting whether build name contains epoch, parsing out package name, etc. The current implementation (taken from depcheck) is clearly sub-optimal, because it doesn't reflect the full RPM naming spec, just the most widespread usage (e.g. can colon be part of NVR, except for separating epoch?): {{{ def strip_epoch(rpmstr): return rpmstr.split(':',1)[-1] # works for E:N-V-R.A or N-V-R.A def strip_arch(rpmstr): return rpmstr.rsplit('.',1)[0] }}} Let's create one or more methods for these tasks in our library and let's use rpmUtils module in them. That ensures that the correct algorithms for detecting epochs, names, releases, etc are used. Most of the use cases for those methods have been mentioned in the description, but search through available code whether some more use cases are needed. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/295> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 10

[AutoQA] #272: Tell test which arch it is supposed to test
by fedora-badges 04 Apr '11

04 Apr '11

#272: Tell test which arch it is supposed to test -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: major | Milestone: Finger Food Component: core | Keywords: -------------------------+-------------------------------------------------- Some tests need to know which architecture to check. But currently we don't pass that information (in the control file). The test can take a guess by detecting operating system architecture (not hardware architecture), but that's an ugly workaround. Pass the architecture info from autoqa script to the test. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/272> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 5

[AutoQA] #297: depcheck reports rejected builds as ignored
by fedora-badges 04 Apr '11

04 Apr '11

#297: depcheck reports rejected builds as ignored --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: major | Milestone: 0.4.5 Component: tests | Keywords: --------------------+------------------------------------------------------- Found a problem in depcheck: {{{ 03/30 15:28:58 INFO | depcheck:0230| Update FAILED: kadu-0.9.0-1.fc14 03/30 15:28:58 INFO | depcheck:0230| Build FAILED: kadu-0.9.0-1.fc14 03/30 15:28:58 INFO | depcheck:0230| Ignored: 03/30 15:28:58 INFO | depcheck:0230| kadu-0.9.0-1.fc14 }}} However, kadu-0.9.0-1.fc14 is in the REJECT line, not in IGNORE line (there is no such line): {{{ 03/30 15:28:23 DEBUG| utils:0105| [stdout] REJECT: kadu-0.6.5.4-5.fc14.x86_64 kadu-0.9.0-1.fc14.x86_64 kadu- globalhotkeys-0.6.5.4-5.fc14.x86_64 kadu-globalhotkeys-0.9.0-1.fc14.x86_64 kadu-led_notify-0.6.5.4-5.fc14.x86_64 kadu-led_notify-0.9.0-1.fc14.x86_64 kadu-nextinfo-0.9.0-1.fc14.x86_64 kadu-panelkadu-0.6.5.4-5.fc14.x86_64 kadu-panelkadu-0.9.0-1.fc14.x86_64 kadu-senthistory-0.6.5.4-5.fc14.x86_64 kadu-senthistory-0.9.0-1.fc14.x86_64 kadu- splitmessages-0.9.0-1.fc14.x86_64 03/30 15:28:23 DEBUG| utils:0105| [stdout] ACCEPT: 1:gnumeric-1.10.14-1.fc14.x86_64 policycoreutils- newrole-2.0.85-28.fc14.x86_64 audit-2.1-1.fc14.x86_64 coot- doc-0.6.2-4.20110328svn3442.fc14.x86_64 1:php- libguestfs-1.8.4-1.fc14.x86_64 coot-0.6.2-4.20110328svn3442.fc14.i686 pam_shield-0.9.5-2.fc14.x86_64 audit-libs-2.1-1.fc14.i686 yumex-3.0.2-1.fc14.noarch gnome-chemistry-utils- mozplugin-0.12.7-2.fc14.x86_64 1:python-libguestfs-1.8.4-1.fc14.x86_64 1 :gnumeric-plugins-extras-1.10.14-1.fc14.x86_64 groonga- libs-1.2.0-1.fc14.x86_64 audit-libs-2.1-1.fc14.x86_64 1:libguestfs- mount-1.8.4-1.fc14.x86_64 audit-libs-python-2.1-1.fc14.x86_64 groonga- plugin-suggest-1.2.0-1.fc14.x86_64 texworks-0.4.0-1.fc14.x86_64 groonga- devel-1.2.0-1.fc14.i686 aqsis-libs-1.6.0-8.fc14.i686 groonga-1.2.0-1.fc14.x86_64 groonga-php-1.2.0-1.fc14.x86_64 lyx- fonts-2.0.0-0.19.rc2.fc14.noarch docbook-style-xsl-1.76.1-1.fc14.noarch groonga-doc-1.2.0-1.fc14.x86_64 python-tornado-doc-1.2.1-1.fc14.noarch policycoreutils-sandbox-2.0.85-28.fc14.x86_64 audit-libs- devel-2.1-1.fc14.i686 backintime-kde-1.0.6-1.fc14.noarch goffice- devel-0.8.14-1.fc14.i686 1:libguestfs-java-1.8.4-1.fc14.i686 groonga- libs-1.2.0-1.fc14.i686 1:libguestfs-javadoc-1.8.4-1.fc14.x86_64 goffice- devel-0.8.14-1.fc14.x86_64 1:libguestfs-java-1.8.4-1.fc14.x86_64 1:perl- Sys-Guestfs-1.8.4-1.fc14.x86_64 rsync-3.0.8-1.fc14.x86_64 coot- devel-0.6.2-4.20110328svn3442.fc14.i686 xfce4-settings-4.6.5-2.fc14.x86_64 1:ocaml-libguestfs-1.8.4-1.fc14.x86_64 aqsis-core-1.6.0-8.fc14.x86_64 gnome-chemistry-utils-0.12.7-2.fc14.i686 1:libguestfs-java- devel-1.8.4-1.fc14.i686 perl-Module-Mask-0.03-1.fc14.noarch aqsis- data-1.6.0-8.fc14.noarch 1:libguestfs-tools-c-1.8.4-1.fc14.x86_64 audispd- plugins-2.1-1.fc14.x86_64 groonga-python-1.2.0-1.fc14.x86_64 aqsis- libs-1.6.0-8.fc14.x86_64 policycoreutils-python-2.0.85-28.fc14.x86_64 1:gnumeric-1.10.14-1.fc14.i686 audit-libs-static-2.1-1.fc14.x86_64 goffice-0.8.14-1.fc14.x86_64 groonga-munin-plugins-1.2.0-1.fc14.x86_64 1 :libguestfs-devel-1.8.4-1.fc14.i686 backintime-common-1.0.6-1.fc14.noarch pam_shield-0.9.5-2.fc14.i686 lyx-common-2.0.0-0.19.rc2.fc14.noarch 1:texmaker-2.3-1.fc14.x86_64 1:libguestfs-devel-1.8.4-1.fc14.x86_64 policycoreutils-2.0.85-28.fc14.x86_64 1:libguestfs- tools-1.8.4-1.fc14.x86_64 lyx-2.0.0-0.19.rc2.fc14.x86_64 gnome-chemistry- utils-gnumeric-0.12.7-2.fc14.x86_64 policycoreutils- gui-2.0.85-28.fc14.x86_64 groonga-devel-1.2.0-1.fc14.x86_64 jpilot-1.8.0-2.fc14.x86_64 aqsis-1.6.0-8.fc14.x86_64 1:libguestfs-1.8.4-1.fc14.x86_64 scout-0.4-7.fc14.noarch backintime- gnome-1.0.6-1.fc14.noarch goffice-0.8.14-1.fc14.i686 1:ocaml-libguestfs- devel-1.8.4-1.fc14.x86_64 1:ocaml-libguestfs-devel-1.8.4-1.fc14.i686 audit-libs-devel-2.1-1.fc14.x86_64 aqsis-devel-1.6.0-8.fc14.i686 ruby- augeas-0.4.1-1.fc14.x86_64 1:ruby-libguestfs-1.8.4-1.fc14.x86_64 1:guestfish-1.8.4-1.fc14.x86_64 1:gnumeric-devel-1.10.14-1.fc14.x86_64 gnome-chemistry-utils-0.12.7-2.fc14.x86_64 1:libguestfs-1.8.4-1.fc14.i686 1:gnumeric-devel-1.10.14-1.fc14.i686 coot- devel-0.6.2-4.20110328svn3442.fc14.x86_64 coot-0.6.2-4.20110328svn3442.fc14.x86_64 1:libguestfs-java- devel-1.8.4-1.fc14.x86_64 groonga-tokenizer-mecab-1.2.0-1.fc14.x86_64 python-tornado-1.2.1-1.fc14.noarch aqsis-devel-1.6.0-8.fc14.x86_64 xu4-1.1-0.14.20110329svn2873.fc14.x86_64 }}} We have a bug somewhere. Full log is here: http://pastebin.com/raw.php?i=EMiLuDm5 -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/297> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 4

Re: Fwd: rpmguard: PASSED; 0 warnings for netcdf-4.1.2-1.fc16
by Tim Flink 31 Mar '11

31 Mar '11

On 03/31/2011 01:17 PM, Orion Poplawski wrote: > This doesn't seem right. Can't compare across releases? At the moment, this is expected behavior. Rpmguard only compares builds within a release or, more specifically, within a koji tag (dist-f16 in this particular case). If you would like to see comparisons across tags, please file an enhancement request with AutoQA [1]. Tim [1] https://fedorahosted.org/autoqa/ PS: autoqa-devel@ would probably be a good list to at least cc: for rpmguard (or other autoqa test) questions. > -------- Original Message -------- > Subject: rpmguard: PASSED; 0 warnings for netcdf-4.1.2-1.fc16 > Date: Thu, 31 Mar 2011 19:14:27 +0000 (UTC) > From: autoqa(a)fedoraproject.org > To: autoqa-results(a)lists.fedorahosted.org, netcdf-owner(a)fedoraproject.org > > Stored logs available at > <http://autoqa.fedoraproject.org/results/76250-autotest/qa03.c.fedoraproject…> > > ---------------------------------------------------------------------- > ======================================== > netcdf-4.1.2-1.fc16 > ======================================== > N: There is no previous build of netcdf-4.1.2-1.fc16 in dist-f16 tag (or its > parents). > N: ----

1 0

AutoQA next releases plan meeting - topics proposal
by Josef Skladanka 31 Mar '11

31 Mar '11

Hello gang, I know from James, that we all are eager to discuss the next steps and goals in AutoQA development. As I promised to James, I've created some topics outline with some brief keynotes(see below). Feel free to add/remove/change anything on-list. J. = Next AutoQA release(s) = == Genearal Goals == * Small incremental changes * Faster releases === Requirements === * Staging server (so we can test incremental changes) * Ideally testing & pushing changes by individual tickets rather than whole releases. == Functional Goals == * #262 - Changed watcher/event architecture * vhumpa already submitted some changes, they are under review right now * #276 - Support for independent test development * Extremely usefull not only for external developers, but also for our own use - i.e. we'd like to be able to update tests without the need for building whole new autoqa rpm. * Suggested solutions * "quick'n'dirty" - autotest grabbing tests from specified git repo/branch before scheduling the test * "proper" - creating some variant of pypi e.g. 'repo' based on .tgz files & tools to install/check updates/etc from that 'repo' * what tools/services are out there (pipy, slackware repo, ...)? Can we use them for our purposes without too much hacking? * #258 - 'make test' * #196 - Standard logging for autoqa & watchers * there are some changes in some of the mkrizek's logging branch * IMHO mostly unusable, since autoqa scripts (and watchers) changed quite a bit. * The autoqa.logger lib can be a good start <http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=lib/python/logger.py…> * I'd also rather see the autoqa.logger library to provide logging interface (e.g. {{{autoqa.logger.error("message")}}} instead of{{{logging.error("message")}}}). This can simply provide the logging calls, but if we ever decide to do some stuff other than just simple "put to stdout/stderr", we won't have to change all the code, just the library. * #254 - Transfer autoqa library to clients * lmr & jlaska are working on patching autotest so it complains with fedora packaging policies <https://github.com/lmr/autotest/tree/fudcon> * this will probably change the way how single parts of autotest are discovered & transfered to the clients. We should keep an eye on the matter, so we can search for possible ways to bend this routine to our purposes. * #245 - Support for test re-scheduling * I see this as quite huge & not so explored area. I guess I'd postpone this particular ticket at least up until ResultsDB is in place.

4 10

← Newer
1
2
3
4
5
6
7
8
...
11
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

autoqa-devel March 2011