#417: Prune old autotest results [waiting upstream]
-------------------------+---------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: major | Milestone: Packaging, Review, & Deployment
Component: production | Keywords:
Blocked By: | Blocking:
-------------------------+---------------------------------------------
Since we execute a large number of jobs, the database fills pretty quickly
and the autotest interface gets slower and slower. Lucas implemented a new
script to prune the database, but we have to wait until it is released in
a new autotest-server version (probably 0.14).
https://github.com/autotest/autotest/issues/98
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/417>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
#251: Move autotest applications into /usr/*bin
-----------------------+----------------------------------------------------
Reporter: jlaska | Owner:
Type: task | Status: new
Priority: minor | Milestone: Packaging, Review, & Deployment
Component: packaging | Keywords:
-----------------------+----------------------------------------------------
The autotest package should supply binaries in /usr/bin/ ... so we can
rely on PATH and not have to call autotest with the full-path
(/usr/share/autotest/client/bin/autotest) when scheduling jobs in
'/usr/bin/autoqa'.
Alternatively, the autotest package could drop a script that updates PATH
appropriately into /etc/profile.d/autotest. But yuck.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/251>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
#419: Adjust code to Autotest API changes
-----------------------+--------------------------
Reporter: mkrizek | Owner: mkrizek
Type: task | Status: new
Priority: major | Milestone: Future tasks
Component: autotest | Keywords:
Blocked By: | Blocking:
-----------------------+--------------------------
With recent proposed changes to Autotest API [1], the job here is to make
appropriate adjustments to AutoQA code and make sure that everything works
after that.
[1] http://test.kernel.org/pipermail/autotest/2012-April/010235.html
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/419>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
#414: rats_install: run twice, once for updates, once for updates+updates-testing
--------------------------+-------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: Nice to have soon
Component: tests | Keywords:
Blocked By: | Blocking:
--------------------------+-------------------------------
We decided it would be beneficial to run rats_install twice. Once for
stable updates only, once for main+updates, once for main+updates+updates-
testing. Currently we're running just the second option. The discussion is
here:
https://fedoraproject.org/wiki/QA/Meetings/20120319#t15:55:42
Change rats_install to execute twice and report both variants. The easiest
way is probably to modify 'control' file to execute the job twice and
modify some input argument to distinguish the two cases. Also we need to
change the summary accordingly so that we can easily distinguish that in
our ResultsDB view.
Marking "Nice to have soon" if we can do it before F17 Final, otherwise
it'll probably go into "Future tasks".
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/414>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
#157: conflicts: requested arch not respected
--------------------+-------------------------------------------------------
Reporter: kparal | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: tests | Version: 1.0
Keywords: |
--------------------+-------------------------------------------------------
This is a bug in the potential_conflict.py script in tests/conflicts/.
Usage suggests using --arch options for specifying requested architecture
to be tested. But if you look at the attached log, the first and second
output match (that's correct), but the third doesn't match, even though it
should. Everything was tested on x86_64 machine.
Also from the usage line it is not clear whether --arch is related only to
particular yum repository selection (replacing $basearch keyword), or
whether it also relates to packages built for one architecture but being
in different repo (e.g. i686 packages are very often in x86_64 repo).
I have looked into the source code of the script and it seems that the
--arch option is not used at all, just printed out in the usage help??
Seth, you're listed as script author. Any comments on that? Thanks.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/157>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
#270: Package and submit for review - compat-Django-1.0.4
-----------------------+----------------------------------------------------
Reporter: jlaska | Owner:
Type: task | Status: new
Priority: major | Milestone: Package Update Acceptance Test Plan
Component: packaging | Keywords:
-----------------------+----------------------------------------------------
Currently packaged so that it can coexist with the current Django package
(see http://repos.fedorapeople.org/repos/fedora-
qa/autoqa/fedora-14-testing/). I need to port existing security patches
linked from http://www.djangoproject.com/weblog/2010/dec/22/security/
Once patched, submit for review ... and enjoy.
Eventually autotest will be updated to use Django-1.2 ... but packaging
Django-1.0.4 removes one more packaging obstacle to having autotest as an
official Fedora package.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/270>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
#329: implement RPM checksum verification
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Finger Food
Component: core | Keywords:
-------------------------+--------------------------------------------------
Currently this method is in autoqa.util module:
{{{
261 def valid_rpm(rpm_file):
262 '''Check that RPM file is valid.
263 Note: This currently only extracts RPM header and presumes the
file is
264 OK if that succeeds. Full RPM hashsum check would be nice to
have
265 implemented too (FIXME).
266 @param rpm_file RPM file path
267 @return True if file seems OK or False if there is some
problem (file
268 can't be read, RPM header is corrupt)
269 '''
...
}}}
We would like to have full RPM checksum verification, not just reading the
header and saying that it's OK. Find out how to do it and change the
method accordingly. It would be nice to have a method argument to enable
full checksum verification/fall back to original header verification,
because it can be performance intensive operation and it may not be
suitable for all our use cases).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/329>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
#396: bodhi_util: Could not connect to bodhi!
---------------------+------------------------
Reporter: kparal | Owner:
Type: defect | Status: new
Priority: major | Milestone: Hot issues
Component: core | Keywords:
Blocked By: | Blocking:
---------------------+------------------------
There seems to be some problem when trying to submit certain results to
Bodhi:
{{{
12/22 07:10:13 INFO | test:0478| Submitting results (log, email,
bodhi) for: depcheck: PASSED; 66 PASSED for kde-
l10n-4.7.4-1.fc16,PyKDE4-4.7.4-1.fc16,blinken-4.7.4-1.fc16,cantor-4.7.4-1.fc16,gwenview-4.7.4-1.fc16,kalgebra-4.7.4-1.fc16,kalzium-4.7.4-1.fc16,kamera-4.7.4-1.fc16,kanagram-4.7.4-1.fc16,kate-4.7.4-1.fc16,kbruch-4.7.4-1.fc16,kcolorchooser-4.7.4-1.fc16
,kde-
wallpapers-4.7.4-1.fc16,kdeaccessibility-4.7.4-1.fc16,kdeadmin-4.7.4-1.fc16,kdeartwork-4.7.4-1.fc16,kdebase-4.7.4-2.fc16
,kdebase-runtime-4.7.4-2.fc16,kdebase-
workspace-4.7.4-5.fc16,kdeedu-4.7.4-1.fc16,kdegames-4.7.4-1.fc16,kdegraphics-4.7.4-1.fc16
,kdegraphics-strigi-analyzer-4.7.4-1.fc16,kdegraphics-
thumbnailers-4.7.4-1.fc16,kdelibs-4.7.4-1.fc16,kdemultimedia-4.7.4-2.fc16,kdenetwork-4.7.4-1.fc16,kdepim-4.7.4-1.fc16
,kdepim-runtime-4.7.4-1.fc16,kdepimlibs-4.7.4-2.fc16,kdeplasma-
addons-4.7.4-1.fc16,kdesdk-4.7.4-1.fc16,kdetoys-4.7.4-1.fc16,kdeutils-4.7.4-1.fc16,kgamma-4.7.4-1.fc16,kgeography-4.7.4-1.fc16,khangman-4.7.4-1.fc16,kig-4.7.4-1.fc16,kiten-4.7.4-1.fc16,klettres-4.7.4-1.fc16,kmplot-4.7.4-1.fc16,kolourpaint-4.7.4-1.fc16,konsole-4.7.4-1.fc16
,kross-
interpreters-4.7.4-1.fc16,kruler-4.7.4-1.fc16,ksaneplugin-4.7.4-1.fc16,ksnapshot-4.7.4-1.fc16,kstars-4.7.4-1.fc16,ktouch-4.7.4-1.fc16,kturtle-4.7.4-1.fc16,kwordquiz-4.7.4-1.fc16,libkdcraw-4.7.4-1.fc16,libkdeedu-4.7.4-1.fc16,libkexiv2-4.7.4-1.fc16,libkipi-4.7.4-1.fc16,libksane-4.7.4-1.fc16,marble-4.7.4-1.fc16,okular-4.7.4-1.fc16
,oxygen-icon-
theme-4.7.4-1.fc16,parley-4.7.4-1.fc16,rocs-4.7.4-1.fc16,smokegen-4.7.4-1.fc16,smokekde-4.7.4-1.fc16,smokeqt-4.7.4-1.fc16,step-4.7.4-1.fc16,svgpart-4.7.4-1.fc16
12/22 07:10:13 INFO | test:0361| Log created:
/usr/share/autotest/results/default/depcheck/results/kde-
l10n-4.7.4-1.fc1.html
12/22 07:10:13 INFO | test:0307| Email not sent: "depcheck: PASSED;
66 PASSED for kde-
l10n-4.7.4-1.fc16,PyKDE4-4.7.4-1.fc16,blinken-4.7.4-1.fc16,cantor-4.7.4-1.fc16,gwenview-4.7.4-1.fc16,kalgebra-4.7.4-1.fc16,kalzium-4.7.4-1.fc16,kamera-4.7.4-1.fc16,kanagram-4.7.4-1.fc16,kate-4.7.4-1.fc16,kbruch-4.7.4-1.fc16,kcolorchooser-4.7.4-1.fc16
,kde-
wallpapers-4.7.4-1.fc16,kdeaccessibility-4.7.4-1.fc16,kdeadmin-4.7.4-1.fc16,kdeartwork-4.7.4-1.fc16,kdebase-4.7.4-2.fc16
,kdebase-runtime-4.7.4-2.fc16,kdebase-
workspace-4.7.4-5.fc16,kdeedu-4.7.4-1.fc16,kdegames-4.7.4-1.fc16,kdegraphics-4.7.4-1.fc16
,kdegraphics-strigi-analyzer-4.7.4-1.fc16,kdegraphics-
thumbnailers-4.7.4-1.fc16,kdelibs-4.7.4-1.fc16,kdemultimedia-4.7.4-2.fc16,kdenetwork-4.7.4-1.fc16,kdepim-4.7.4-1.fc16
,kdepim-runtime-4.7.4-1.fc16,kdepimlibs-4.7.4-2.fc16,kdeplasma-
addons-4.7.4-1.fc16,kdesdk-4.7.4-1.fc16,kdetoys-4.7.4-1.fc16,kdeutils-4.7.4-1.fc16,kgamma-4.7.4-1.fc16,kgeography-4.7.4-1.fc16,khangman-4.7.4-1.fc16,kig-4.7.4-1.fc16,kiten-4.7.4-1.fc16,klettres-4.7.4-1.fc16,kmplot-4.7.4-1.fc16,kolourpaint-4.7.4-1.fc16,konsole-4.7.4-1.fc16
,kross-
interpreters-4.7.4-1.fc16,kruler-4.7.4-1.fc16,ksaneplugin-4.7.4-1.fc16,ksnapshot-4.7.4-1.fc16,kstars-4.7.4-1.fc16,ktouch-4.7.4-1.fc16,kturtle-4.7.4-1.fc16,kwordquiz-4.7.4-1.fc16,libkdcraw-4.7.4-1.fc16,libkdeedu-4.7.4-1.fc16,libkexiv2-4.7.4-1.fc16,libkipi-4.7.4-1.fc16,libksane-4.7.4-1.fc16,marble-4.7.4-1.fc16,okular-4.7.4-1.fc16
,oxygen-icon-
theme-4.7.4-1.fc16,parley-4.7.4-1.fc16,rocs-4.7.4-1.fc16,smokegen-4.7.4-1.fc16,smokekde-4.7.4-1.fc16,smokeqt-4.7.4-1.fc16,step-4.7.4-1.fc16,svgpart-4.7.4-1.fc16"
12/22 07:10:17 ERROR|bodhi_util:0278| An error occured:
ServerError(http://aqd/bodhi/list, 500, Internal Server Error)
12/22 07:10:17 ERROR|bodhi_util:0279| Could not connect to bodhi!
12/22 07:10:17 ERROR|bodhi_util:0279| Could not post a comment to bodhi
}}}
This is running on my development machine when using mock_fedorainfra
tool. I haven't spotted it yet on either production or staging machine.
That indicates that this could be a problem inside the mock_fedorainfra
tool. I have seen this bug happening several times, always only for
updates consisting of several builds.
Investigate whether this is really a problem in mock_fedorainfra and then
act on accordingly (fix the problem/report in upstream).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/396>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project