April 2011 - autoqa-devel - Fedora mailing-lists

Bodhi update with mixed pending tags
by Kamil Paral 11 Apr '11

11 Apr '11

Hello Luke, another problem popped up. In this update: https://admin.fedoraproject.org/updates/control-center-3.0.0-1.fc15,gnome-s… control-center-3.0.0-1.fc15 is tagged as dist-f15-updates-pending, but gnome-settings-daemon-3.0.0.1-1.fc15 is tagged just as dist-f15-updates-candidate. Seems like Bodhi bug? Thanks for reply, Kamil

2 1

[AutoQA] #304: bodhi
by fedora-badges 11 Apr '11

11 Apr '11

#304: bodhi --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: 0.4.7 Component: core | Keywords: --------------------+------------------------------------------------------- Results link contains dot at the end, throws HTTP 404. See https://admin.fedoraproject.org/updates/xorg-x11-drv- nouveau-0.0.16-14.20101010git8c8f15c.fc14 and try to click on the links. {{{ AutoQA: depcheck test PASSED on i386. The result can be found at: http://autoqa.fedoraproject.org/results/80737-autotest/172.16.0.17/depcheck…. }}} Let's remove the dot at the end. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/304> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

Who's working on which bugs?
by Tim Flink 11 Apr '11

11 Apr '11

I assume that kparal is working on #304 since he just sent a patch out on #fedora-qa but I'm not sure who else is working on what. Specifically, I was going to start digging into #303 (depcheck: error: Incorrect number of arguments) if nobody else was working on it. Tim

1 0

Bodhi output.log results include '.'
by James Laska 11 Apr '11

11 Apr '11

Hey folks, Just examining some of the updated bodhi comments, and noticed that the output.log URL's do not work. Seems the cause is the '.' character is included in the URL. For a sample, see ... https://admin.fedoraproject.org/updates/fuse-encfs-1.7.4-1.fc13 Thanks, James

1 0

autoqa-0.4.6-1 built and deployed
by James Laska 11 Apr '11

11 Apr '11

Greetings folks, I've updated the repos and deployed autoqa-0.4.6-1 today. You can find the updated packages in the usual repos [1]. As noted by Kamil [2], I also enabled bodhi comments once again. Congrats on the new release! Thanks, James [1] http://repos.fedorapeople.org/repos/fedora-qa/autoqa/ [2] https://kparal.wordpress.com/2011/04/11/autoqa-vs-bodhi-round-2/

1 0

[AutoQA] #301: Reverse execute logic in control.autoqa
by fedora-badges 11 Apr '11

11 Apr '11

#301: Reverse execute logic in control.autoqa -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Finger Food Component: core | Keywords: -------------------------+-------------------------------------------------- The 'execute' variable is True by default and the test must specify execute=False in control.autoqa if it doesn't want to be run. That leads to constructs as: {{{ if event not in ['post-bodhi-update-batch']: execute = False }}} This would be more comprehensible: {{{ # execute = False by default if event in ['post-bodhi-update-batch']: execute = True }}} I.e. we would convert negative logic (saying when it should not run) into positive logic (saying when it should run). Do this change and make corresponding changes in all tests. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/301> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 7

AutoQA 0.4.6 released
by Kamil Paral 11 Apr '11

11 Apr '11

AutoQA 0.4.6 has been released. Congratulation to tflink and jlaska who own 50% of the new release changes each :-) https://fedorahosted.org/autoqa/milestone/0.4.6 Changelog: - Ticket#293 - CmdError: No more mirrors to try (tflink) - autoqa-git-hook: Improved error detection and bad input handling (jlaska)

1 0

[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

stale tags in koji
by Tim Flink 11 Apr '11

11 Apr '11

All, I happened to be going through the upgradepath results for F15 today and I'm seeing a lot of builds with stale tags (~50 so far and I'm not done). If we re-enable comments before these builds are taken care of, we're going to be adding a lot more comments to old builds again. This is why spot-checking (like I did before) isn't enough, I suppose. Anyhow, I sent an email to lmacken with my initial list and I'm planning to write a script to check for stale tags tomorrow. Tim

3 6

[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

[Fwd: Fedora SPEC Review Tool]
by James Laska 07 Apr '11

07 Apr '11

Hey gang, Anything finger-food worthy with this new spec_checks tool? Thanks, James

3 3

AutoQA 0.4.5 coming - please test
by Kamil Paral 07 Apr '11

07 Apr '11

I believe we have AutoQA 0.4.5 ready: https://fedorahosted.org/autoqa/milestone/0.4.5 There are a few hot issues remaining, but I don't think we should wait for them: #293 CmdError: No more mirrors to try - tflink working on this one - can be really difficult - doesn't produce bad results, just sometimes produces no result at all, not blocker #284 depcheck does not produce output for some pending updates - may be related to the above one - doesn't produce bad results, just sometimes produces no result at all, not blocker #289 Missing autotest debug logs - this may take some time to debug and solve So, I want to ask anyone interested to checkout "stable" branch a run a few tests (depcheck and upgradepath are top priorities) and report any problems found. If everything works as expected, we will publish a new release any day now. Thanks.

4 10

[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

[AutoQA] #302: depcheck should use correct version of yum for packages under test
by fedora-badges 06 Apr '11

06 Apr '11

#302: depcheck should use correct version of yum for packages under test -------------------------+-------------------------------------------------- Reporter: tflink | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Future tasks Component: tests | Keywords: -------------------------+-------------------------------------------------- == Description == I don't think that this is a problem yet but I figured that I would file a ticket before I forgot. When I was digging through the depcheck and yum code today, it occurred to me that we rely on the test host's yum installation for depcheck and we don't specify the version of fedora to use when scheduling the tests. Since each version of fedora has a different version of yum, this could cause problems in the future if there are yum metadata format changes or other forward/backward-incompatible changes in yum. == Possible Solutions == 1. schedule depcheck jobs to match the fedora version under test * This is the simplest fix 2. Use virtualenvs * While more complicated, this would allow depcheck scheduling on any version of fedora and multiple depcheck jobs on the same host if we ever figure out a way to get around the validity of concurrent jobs. Personally, I'm all for the scheduling change for a fix since I can't really see enough benefit to using virtualenv to justify the cost of implementing it right now. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/302> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[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

[PATCH] - Detect required Fedora releases correctly
by Vitezslav Humpa 05 Apr '11

05 Apr '11

Discussed and modified, hopefully ready now. Please review - https://fedorahosted.org/reviewboard/r/131/ Thanks! -- Vita Humpa Fedora QA

3 2

[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

[PATCH]: 268 - Rename lib/python to lib/autoqa
by Vitezslav Humpa 04 Apr '11

04 Apr '11

Please review: https://fedorahosted.org/reviewboard/r/128/

2 1

[AutoQA] #300: Do envra conversions with autoqa.util.envra()
by fedora-badges 04 Apr '11

04 Apr '11

#300: Do envra conversions with autoqa.util.envra() -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Finger Food Component: core | Keywords: -------------------------+-------------------------------------------------- In ticket #295 we added a new function autoqa.util.envra() for rpm namespec string conversion. The task is now to go through our code and make sure we use this function everywhere instead of manually searching for and stripping by columns, periods, etc. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/300> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

[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

[AutoQA] #299: Allow rpmguard to compare to previous releases
by fedora-badges 04 Apr '11

04 Apr '11

#299: Allow rpmguard to compare to previous releases -------------------------+-------------------------------------------------- Reporter: orion | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Future tasks Component: tests | Keywords: -------------------------+-------------------------------------------------- I have many packages that I only build once a release. Comparing those builds to previous releases would still be useful I think. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/299> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[PATCH] - Tell test which arch it is supposed to test implemented
by Vitezslav Humpa 01 Apr '11

01 Apr '11

Please review this patch: https://fedorahosted.org/reviewboard/r/126/ Thanks folks! -- Vita Humpa Fedora QA

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

autoqa-devel April 2011