April 2011 - autoqa-devel - Fedora mailing-lists

[AutoQA] #282: Update minimum python version requirement to 2.6
by fedora-badges 17 Aug '11

17 Aug '11

#282: Update minimum python version requirement to 2.6 --------------------+------------------------------------------------------- Reporter: jlaska | Owner: Type: task | Status: new Priority: major | Milestone: 0.5.0 Component: core | Keywords: --------------------+------------------------------------------------------- Supporting RHEL-5 (python-2.4) isn't fun. The packaging and python support is so dramatically different. I'd like to upgrade our autoqa/autotest server to use RHEL-6. I'd consider using a stable Fedora release, but as tflink pointed out, I'm even less excited about updating our infrastructure every 6 months. This ticket is intended to track: 1. Removal of the epel-5 packages and repositories 2. Any code updates/simplification (e.g. use of finally) -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/282> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 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

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

03 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] #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] #149: rpmlint: Provide whitelisting of messages
by fedora-badges 28 Jul '11

28 Jul '11

#149: rpmlint: Provide whitelisting of messages --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Package update tests Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- We need to provide some whitelisting capability of rpmlint packages, so the package maintainers can mark some messages as invalid. We will also probably want to mark some messages as invalid by default for the whole Fedora project. As an interesting inspiration, look at lintian project (validation of deb packages). It provides some "overrides" on a package basis, you just create a definition file in /etc/lintian/package_name or kind of. I have the feeling that rpmlint provides something similar, but we need to discover it more properly. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/149> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #104: virtguest.py: accept iso image(s) as install location
by fedora-badges 21 Jul '11

21 Jul '11

#104: virtguest.py: accept iso image(s) as install location --------------------+------------------------------------------------------- Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- allow {{{VirtGuest.create()}}} to use an iso image (or images) for its {{{location}}} arg, and automatically choose the appropriate {{{--location URL}}} or {{{--cdrom IMAGE}}} flag. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/104> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #308: depcheck: Handle packages with "Conflicts:" declarations better than just failing them
by fedora-badges 18 Jul '11

18 Jul '11

#308: depcheck: Handle packages with "Conflicts:" declarations better than just failing them -------------------------+-------------------------------------------------- Reporter: tflink | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Package Update Acceptance Test Plan Component: core | Keywords: -------------------------+-------------------------------------------------- In a recent [http://autoqa.fedoraproject.org/results/82955-autotest/qa03.c.fedoraproject… test for mediawiki on f13], depcheck rejected the updated because it conflicted with pho-common. The package conflicts with php-common because of a "Conflicts: php-common = 5.3.1" in the spec file for mediawiki starting with 1.16.2-56 ([http://pkgs.fedoraproject.org/gitweb/?p=mediawiki.git;a=blob;f=mediawiki.sp… current spec file]) I can't imagine that this is the only package with a "Conflicts:" declaration and I don't think that we should be just failing packages like that. Maybe the "Conflicts:" should be checked somewhere, I'm just thinking that it should be somewhere other than depcheck. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/308> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #248: depcheck: simultaneous run may report incorrect results
by fedora-badges 18 Jul '11

18 Jul '11

#248: depcheck: simultaneous run may report incorrect results --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: 0.4.4 Component: tests | Keywords: --------------------+------------------------------------------------------- This is taken from:[[BR]] https://fedorahosted.org/pipermail/autoqa-devel/2010-November/001306.html I have imagined a situation where two updates are accepted into the -pending tag in quick succession. Thus we can end up with two depcheck tests running simultaneously. And the one that was started earlier can finish up later. It could then report incorrect result. Do you have an idea what we can we do about that? Maybe we can somehow write down the state of the -pending tag in the time of starting the test, and if it is different from when the test is finished, we can just throw away the results? Just a wild idea. Wwoods mentioned that he's working on --accepted option for depcheck, here is short IRC excerpt, hopefully he will provide more info soon: {{{ (05:16:13 PM) wwoods: I'm working on a mailing list post about the "accepted" flag (05:19:13 PM) wwoods: the short answer is this: we mark packages as "accepted" when they pass depcheck (05:19:48 PM) wwoods: exactly *how* we mark the package is kind of an implementation detail - could be a koji tag or a local database of accepted package names or whatever (05:20:04 PM) wwoods: but since we're already planning to give +1 karma for packages that are accepted (05:21:02 PM) wwoods: then we can (I hope!) just check Bodhi for each thing in -pending (05:21:11 PM) wwoods: if it has +1, it was previously accepted (05:21:21 PM) wwoods: err - has a +1 from autoqa / depcheck (05:21:51 PM) wwoods: in the future we might want to query resultsdb instead, or use a second koji tag (05:22:39 PM) wwoods: I'll still write a (possibly longer) explanation for the list - or maybe a blog post }}} -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/248> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 9

[AutoQA] #312: depcheck: RuntimeError: maximum recursion depth exceeded
by fedora-badges 18 Jul '11

18 Jul '11

#312: depcheck: RuntimeError: maximum recursion depth exceeded --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Keywords: --------------------+------------------------------------------------------- This happened while running: {{{ # autoqa post-bodhi-update-batch --targettag dist-f14-updates-testing --arch x86_64 --arch i386 root-5.28.00a-1.fc14 -t depcheck --local }}} {{{ File "/usr/lib/python2.7/site- packages/yum/__init__.py", line 3633, in update tx_return): File "/usr/lib/python2.7/site- packages/yum/__init__.py", line 3392, in _newer_update_in_trans available_pkg) File "/usr/lib/python2.7/site- packages/yum/__init__.py", line 3373, in _check_new_update_provides tx_return.extend(self.update(po=pkg)) File "/usr/lib/python2.7/site- packages/yum/__init__.py", line 3633, in update tx_return): File "/usr/lib/python2.7/site- packages/yum/__init__.py", line 3392, in _newer_update_in_trans available_pkg) File "/usr/lib/python2.7/site- packages/yum/__init__.py", line 3373, in _check_new_update_provides tx_return.extend(self.update(po=pkg)) File "/usr/lib/python2.7/site- packages/yum/__init__.py", line 3633, in update tx_return): File "/usr/lib/python2.7/site- packages/yum/__init__.py", line 3392, in _newer_update_in_trans available_pkg) File "/usr/lib/python2.7/site- packages/yum/__init__.py", line 3373, in _check_new_update_provides tx_return.extend(self.update(po=pkg)) File "/usr/lib/python2.7/site- packages/yum/__init__.py", line 3612, in update updated_pkg = self.getInstalledPackageObject(updated) File "/usr/lib/python2.7/site- packages/yum/__init__.py", line 2811, in getInstalledPackageObject pkgs = self.rpmdb.searchPkgTuple(pkgtup) File "/usr/lib/python2.7/site- packages/yum/packageSack.py", line 114, in searchPkgTuple return self.searchNevra(name=n, arch=a, epoch=e, ver=v, rel=r) File "/usr/lib/python2.7/site- packages/yum/packageSack.py", line 406, in searchNevra return self._computeAggregateListResult("searchNevra", name, epoch, ver, rel, arch) File "/usr/lib/python2.7/site- packages/yum/packageSack.py", line 584, in _computeAggregateListResult sackResult = apply(method, args) File "/usr/lib/python2.7/site- packages/yum/sqlitesack.py", line 46, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.7/site- packages/yum/sqlitesack.py", line 1691, in searchNevra for pkg in self.searchNames(names=[name]): File "/usr/lib/python2.7/site- packages/yum/sqlitesack.py", line 46, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.7/site- packages/yum/sqlitesack.py", line 1270, in searchNames if self._skip_all(): File "/usr/lib/python2.7/site- packages/yum/sqlitesack.py", line 840, in _skip_all if repo not in self._all_excludes: RuntimeError: maximum recursion depth exceeded }}} Full log attached. Yum bug, or depcheck bug? -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/312> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #183: Write a script and a daemon to send signals between virt machine and host
by fedora-badges 11 Jul '11

11 Jul '11

#183: Write a script and a daemon to send signals between virt machine and host ----------------------------+----------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Virtualization Component: infrastructure | Version: 1.0 Keywords: | ----------------------------+----------------------------------------------- We need to exchange some signals between virt machine and a host. For example "autotest job finished, need to revert to previous state". We need to write simple script that will send this signal for virt machine and a daemon that will receive this signal in the host machine and act accordingly. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/183> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 4

Re: Virtualization support
by Scott M Ferguson 11 Jul '11

11 Jul '11

> Hello Scott, > > I'm not exactly sure I get the idea. The autotest server already > handles starting the task and collecting results (arrows 2. and 3. in > the picture I added to > https://fedorahosted.org/autoqa/ticket/183#comment:description) Ticket > #183 mainly concerns arrow 4., signaling to the host (of that autotest > client VM). We can use it for reverting the VM to the previous state > (I think that's the main reason we need all of this). In the Virtualization > milestone there are other tickets that cover remaining parts of that > picture. > > So, the problem of ticket #183 is not getting the results (autotest handles > that for us), but telling the host (of that VM) "do something" right after > completing the test. > > Are we on the same page? Maybe I have missed something. Tell me. > > Thanks, > Kamil > Kamil, We were on a different page and it's completely due to lack-of-sleep on my end, but that's another story (4-week-old daughter). Thanks for clarifying. All should be well now :) Best, Scott

2 2

[AutoQA] #258: implement 'make test'
by fedora-badges 29 Jun '11

29 Jun '11

#258: implement 'make test' -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: major | Milestone: 0.5.0 Component: core | Keywords: -------------------------+-------------------------------------------------- Some of our modules have unit tests. Let's execute them all by "make test" command and report the result. We can use this functionality to periodically check whether nothing got broken. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/258> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 12

[AutoQA] #314: Decrease the volume of 'PASSED' email sent to maintainers from bodhi
by fedora-badges 27 Jun '11

27 Jun '11

#314: Decrease the volume of 'PASSED' email sent to maintainers from bodhi --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: task | Status: new Priority: major | Milestone: Hot issues Component: core | Keywords: --------------------+------------------------------------------------------- With the current setup, maintainers are sent an email with every single comment made by AutoQA. These emails aren't particularly useful and increase the amount of noise that maintainers need to filter out. Find a way to decrease the number of useless emails sent to maintainers. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/314> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 14

[AutoQA] #298: test.py - split postprocess_iteration reporting into standalone methods
by fedora-badges 15 Jun '11

15 Jun '11

#298: test.py - split postprocess_iteration reporting into standalone methods ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: minor | Milestone: 0.5.0 Component: core | Keywords: ----------------------+----------------------------------------------------- At the moment, postprocess_iteration() handles the whole reporting/sending results. When the run_once ends, this method takes the content of self.{result, summary, highlights, outputs} and automagically sends an email to the mailing list, creates output.log file, etc. This approach was very reasonable for tests which actually test just one thing (update/build/etc), because just a single result is to be sent. With the new tests like Depcheck and Upgradepath, we'd love to be able to force-send several results as the test proceeds - e.g. to be able to send bodhi comment to every update, but send just one overall email... So what I'd like to have is: 1) Take postprocess_iteration, and split it into standalone methods according to the 'destination' of the report (e.g. send_email(), create_output_log(), ...). These will be able to take {result, summary, highlights, outputs} parameters, which will override the 'automagicall' self.{result, summary, highlights, outputs}. I.e. if I set result parameter, summary, highlights and outputs will be filled using the 'self' variables, and so on. 2) Take the bodhi-reporting method (as used in depcheck and upgradepath), and move it to the AutoQATest class. 3) Add a method report_results(), again with the same parameters ({result, summary, highlights, outputs}) and one more (e.g. a dictionary) to control which reporting methods to call (i.e. to be able to say "send email, store in resultsdb, but do not send bodhi comment"). By default, this will call all the reporting routines. 4) In postprocess_iteration(), call the report_results(), so the 'automagical reporting' behaviour is not changed. 5) Add a variable, which will turn on/off the call of report_results() (True as default) in postprocess_iteration() (needs to be some attribute of AutoQATest class, since postprocess_iteration() does not take arguments). This is for the wrapper-writer, to be able to control if results are to be sent in the postprocess_iteration() or not (imagine Upgradepath - we will report all the results in the run_once(), and do not need postprocess iteration to actually send anything). ------------------------------- This is also preparation for resultsdb, because it solves the problem with reporting multiple results from one test. Also turning the resultsdb reporting on is a matter of adding one method, and calling it from report_results() (and adding more types of reporting [I'm looking at you fedora message bus!] in the future will be also this simple. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/298> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #284: depcheck does not produce output for some pending updates
by fedora-badges 05 Jun '11

05 Jun '11

#284: depcheck does not produce output for some pending updates --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Keywords: --------------------+------------------------------------------------------- Free hot issues, come and stop by! Excerpt: depcheck inputs: {{{ Pending builds: ['PyKDE-3.16.6-7.fc14', 'PyQt-3.18.1-8.fc14', 'PyQt4-4.8.3-2.fc14', 'PyQwt-5.2.0-10.fc14', 'akonadi-1.5.1-1.fc14', 'attica-0.2.0-1.fc14', 'avogadro-1.0.1-11.fc14', 'backintime-1.0.6-1.fc14', 'calibre-0.7.38-3.fc14.2', 'calibre-0.7.38-4.fc14', 'digikam-1.9.0-1.fc14', 'jpilot-1.8.0-2.fc14', 'kde-i18n-3.5.10-14.fc14', 'kde-l10n-4.6.1-1.fc14.1', 'kde-plasma-smooth- tasks-0.0.1-0.1.wip20101106.fc14.2', 'kde-plasma-yawp-0.3.6-1.fc14.2', 'kdeaccessibility-4.6.1-1.fc14', 'kdeadmin-4.6.1-1.fc14', 'kdeartwork-4.6.1-1.fc14', 'kdebase-4.6.1-3.fc14', 'kdebase- runtime-4.6.1-1.fc14', 'kdebase-workspace-4.6.1-2.fc14', 'kdebindings-4.6.1-1.fc14', 'kdeedu-4.6.1-2.fc14', 'kdegames-4.6.1-1.fc14', 'kdegames3-3.5.10-9.fc14', 'kdegraphics-4.6.1-1.fc14', 'kdelibs-4.6.1-4.fc14', 'kdemultimedia-4.6.1-1.fc14', 'kdenetwork-4.6.1-2.fc14', 'kdepim-4.4.10-2.fc14', 'kdepim-runtime-4.4.10-2.fc14', 'kdepimlibs-4.6.1-1.fc14', 'kdeplasma-addons-4.6.1-1.fc14', 'kdesdk-4.6.1-1.fc14', 'kdetoys-4.6.1-1.fc14', 'kdeutils-4.6.1-1.fc14', 'kdevelop-4.2.0-2.fc14', 'kdevelop-php-1.2.0-2.fc14', 'kdevplatform-1.2.0-3.fc14', 'kicad-2011.01.28-1.rev2765.fc14', 'kipi- plugins-1.9.0-1.fc14', 'koffice-2.3.3-1.fc14', 'konq- plugins-4.6.1-1.fc14', 'kphotoalbum-4.1.1-7.fc14', 'ktorrent-4.1.0-1.fc14', 'libktorrent-1.1.0-1.fc14', 'nepomukcontroller-0.2-4.fc14', 'oxygen-icon-theme-4.6.1-1.fc14', 'perl- Locale-US-1.2-2.fc14', 'perl-Math-Random-ISAAC-1.004-2.fc14', 'phonon-4.4.4-2.fc14', 'phonon-backend-gstreamer-4.4.4-2.fc14', 'phonon- backend-xine-4.4.4-3.fc14', 'plowshare-0.9.4-0.5.svn1391.fc14', 'polkit- kde-0.99.0-2.fc14', 'polkit-qt-0.99.0-2.fc14', 'qedje-0.4.0-8.fc14', 'qgis-1.6.0-3.fc14.1', 'qscintilla-2.4.6-2.fc14', 'qzion-0.4.0-10.fc14', 'sems-1.3.1-4.fc14.1', 'shared-desktop-ontologies-0.6.0-1.fc14', 'sip-4.12.1-4.fc14', 'soprano-2.6.0-2.fc14', 'thunarx- python-0.2.3-3.fc14.1', 'veusz-1.9-2.fc14.1', 'wmtop-0.84-3.fc14'] }}} depcheck outputs: {{{ IGNORE: ktorrent-4.1.0-1.fc14.i686 plasma-scriptengine- googlegadgets-4.6.1-2.fc14.x86_64 plasma-scriptengine- python-4.6.1-2.fc14.x86_64 kdebase-workspace-ksplash- themes-4.6.1-2.fc14.noarch kdebase-runtime-devel-4.6.1-1.fc14.x86_64 nepomukcontroller-0.2-4.fc14.x86_64 1:kde-i18n-3.5.10-14.fc14.noarch kde- l10n-Maithili-4.6.1-1.fc14.1.noarch plasma-scriptengine- ruby-4.6.1-2.fc14.x86_64 kdebase-runtime-devel-4.6.1-1.fc14.i686 REJECT: ACCEPT: 7:kdenetwork-devel-4.6.1-2.fc14.x86_64 attica- devel-0.2.0-1.fc14.x86_64 attica-devel-0.2.0-1.fc14.i686 qzion- devel-0.4.0-10.fc14.i686 kde-l10n-Portuguese-4.6.1-1.fc14.1.noarch phonon- devel-4.4.4-2.fc14.i686 3:koffice-kplato-libs-2.3.3-1.fc14.i686 polkit-qt- doc-0.99.0-2.fc14.noarch 7:kdenetwork-devel-4.6.1-2.fc14.i686 sems-g722-1.3.1-4.fc14.1.x86_64 qscintilla-devel-2.4.6-2.fc14.i686 shared- desktop-ontologies-0.6.0-1.fc14.noarch kdepimlibs-4.6.1-1.fc14.x86_64 1 :kde-i18n-Japanese-3.5.10-14.fc14.noarch kde-l10n- Ukrainian-4.6.1-1.fc14.1.noarch php-qt-devel-4.6.1-1.fc14.x86_64 sems- xmlrpc2di-1.3.1-4.fc14.1.x86_64 kde-l10n-Thai-4.6.1-1.fc14.1.noarch kphotoalbum-4.1.1-7.fc14.x86_64 kdeedu-math-cantor-R-4.6.1-2.fc14.x86_64 kdeedu-marble-libs-4.6.1-2.fc14.i686 kdevplatform-1.2.0-3.fc14.i686 kde- l10n-LowSaxon-4.6.1-1.fc14.1.noarch qgis-grass-1.6.0-3.fc14.1.i686 1:kde- i18n-Danish-3.5.10-14.fc14.noarch kde-l10n-Brazil-4.6.1-1.fc14.1.noarch 1 :kde-i18n-Lithuanian-3.5.10-14.fc14.noarch kdevplatform- devel-1.2.0-3.fc14.i686 soprano-2.6.0-2.fc14.x86_64 qzion-python- devel-0.4.0-10.fc14.i686 kdeedu-math-libs-4.6.1-2.fc14.i686 libktorrent-1.1.0-1.fc14.i686 1:kdepim-runtime-libs-4.4.10-2.fc14.i686 7 :kdepim-devel-4.4.10-2.fc14.i686 kdm-4.6.1-2.fc14.x86_64 kipi- plugins-1.9.0-1.fc14.x86_64 PyQwt-devel-5.2.0-10.fc14.x86_64 sems- speex-1.3.1-4.fc14.1.x86_64 kdeplasma-addons-devel-4.6.1-1.fc14.x86_64 oxygen-icon-theme-4.6.1-1.fc14.noarch 6:kdebase-devel-4.6.1-3.fc14.x86_64 kde-l10n-Hindi-4.6.1-1.fc14.1.noarch 7:kdepim-libs-4.4.10-2.fc14.i686 PyKDE-3.16.6-7.fc14.x86_64 backintime-gnome-1.0.6-1.fc14.noarch 9:kdevelop-4.2.0-2.fc14.x86_64 qzion-0.4.0-10.fc14.x86_64 ktorrent- libs-4.1.0-1.fc14.i686 1:kde-i18n-Arabic-3.5.10-14.fc14.noarch kde-l10n- Danish-4.6.1-1.fc14.1.noarch qzion-python-0.4.0-10.fc14.x86_64 6 :kdemultimedia-libs-4.6.1-1.fc14.x86_64 6:kdebase-devel-4.6.1-3.fc14.i686 3:koffice-kplato-2.3.3-1.fc14.x86_64 3:koffice-kpresenter- libs-2.3.3-1.fc14.x86_64 kde-l10n-Korean-4.6.1-1.fc14.1.noarch sems- early_announce-1.3.1-4.fc14.1.x86_64 QtRuby-devel-4.6.1-1.fc14.x86_64 6 :kdelibs-apidocs-4.6.1-4.fc14.noarch kdeartwork-kxs-4.6.1-1.fc14.x86_64 kde-l10n-Latvian-4.6.1-1.fc14.1.noarch kdeedu-devel-4.6.1-2.fc14.x86_64 wmtop-0.84-3.fc14.x86_64 kde-style-phase-4.6.1-1.fc14.x86_64 3:koffice- kexi-libs-2.3.3-1.fc14.x86_64 kdeartwork-4.6.1-1.fc14.x86_64 3:koffice- okular-odpgenerator-2.3.3-1.fc14.x86_64 7:kdepim- devel-4.4.10-2.fc14.x86_64 7:system-config-printer-kde-4.6.1-1.fc14.x86_64 libktorrent-1.1.0-1.fc14.x86_64 kde-l10n-Interlingua-4.6.1-1.fc14.1.noarch 1:kde-i18n-Romanian-3.5.10-14.fc14.noarch 1:kde-i18n- British-3.5.10-14.fc14.noarch kde-l10n-Chinese- Traditional-4.6.1-1.fc14.1.noarch 7:kio_msits-4.6.1-1.fc14.x86_64 kde- l10n-Chinese-4.6.1-1.fc14.1.noarch kde-l10n-Romanian-4.6.1-1.fc14.1.noarch akonadi-1.5.1-1.fc14.x86_64 3:koffice-kpresenter-libs-2.3.3-1.fc14.i686 qzion-devel-0.4.0-10.fc14.x86_64 plowshare-0.9.4-0.5.svn1391.fc14.noarch qedje-python-devel-0.4.0-8.fc14.x86_64 7:kdegraphics-4.6.1-1.fc14.x86_64 6 :kdegames-libs-4.6.1-1.fc14.i686 PyQt-devel-3.18.1-8.fc14.i686 calibre-0.7.38-3.fc14.2.x86_64 kdeedu-kstars-libs-4.6.1-2.fc14.i686 3 :koffice-kword-2.3.3-1.fc14.x86_64 kde-l10n-Slovak-4.6.1-1.fc14.1.noarch sems-conference-1.3.1-4.fc14.1.x86_64 qscintilla- python-2.4.6-2.fc14.x86_64 kdesdk-devel-4.6.1-1.fc14.x86_64 6:kdebase- libs-4.6.1-3.fc14.x86_64 6:kdebase-libs-4.6.1-3.fc14.i686 sip- devel-4.12.1-4.fc14.x86_64 6:kdemultimedia-devel-4.6.1-1.fc14.x86_64 3 :koffice-karbon-2.3.3-1.fc14.x86_64 1:kde-i18n- Ukrainian-3.5.10-14.fc14.noarch 3:koffice-kword-libs-2.3.3-1.fc14.i686 kde-l10n-Serbian-4.6.1-1.fc14.1.noarch 3:koffice-devel-2.3.3-1.fc14.i686 1 :kdepim-runtime-4.4.10-2.fc14.x86_64 avogadro-devel-1.0.1-11.fc14.i686 kdevelop-php-1.2.0-2.fc14.x86_64 1:kdeaccessibility-libs-4.6.1-1.fc14.i686 kdeplasma-addons-libs-4.6.1-1.fc14.i686 kde-l10n-Norwegian- Nynorsk-4.6.1-1.fc14.1.noarch PyQt4-devel-4.8.3-2.fc14.x86_64 6:kdegames- devel-4.6.1-1.fc14.x86_64 1:kde-i18n-Slovak-3.5.10-14.fc14.noarch 6:kdebase-4.6.1-3.fc14.x86_64 qyoto-devel-4.6.1-1.fc14.i686 3:koffice- kexi-2.3.3-1.fc14.x86_64 kde-l10n-Estonian-4.6.1-1.fc14.1.noarch digikam- libs-1.9.0-1.fc14.x86_64 1:kdepim-runtime-libs-4.4.10-2.fc14.x86_64 qgis- python-1.6.0-3.fc14.1.i686 soprano-devel-2.6.0-2.fc14.x86_64 digikam- devel-1.9.0-1.fc14.x86_64 6:kdegames-minimal-4.6.1-1.fc14.x86_64 1:kde- i18n-Portuguese-3.5.10-14.fc14.noarch 6:kdemultimedia-4.6.1-1.fc14.x86_64 backintime-common-1.0.6-1.fc14.noarch 1:kde-i18n- Chinese-3.5.10-14.fc14.noarch 3:koffice-kplato-libs-2.3.3-1.fc14.x86_64 3 :koffice-karbon-libs-2.3.3-1.fc14.i686 kde-l10n- British-4.6.1-1.fc14.1.noarch kde-l10n-Bulgarian-4.6.1-1.fc14.1.noarch qgis-python-1.6.0-3.fc14.1.x86_64 kdepimlibs-devel-4.6.1-1.fc14.i686 kde- l10n-Spanish-4.6.1-1.fc14.1.noarch kde-l10n-Khmer-4.6.1-1.fc14.1.noarch kde-l10n-Catalan-Valencian-4.6.1-1.fc14.1.noarch qzion-0.4.0-10.fc14.i686 kdeartwork-screensavers-4.6.1-1.fc14.x86_64 attica-0.2.0-1.fc14.x86_64 9 :kdevelop-libs-4.2.0-2.fc14.x86_64 1:kde-i18n-Brazil-3.5.10-14.fc14.noarch python3-sip-devel-4.12.1-4.fc14.x86_64 6:kdegames-libs-4.6.1-1.fc14.x86_64 7:kdetoys-4.6.1-1.fc14.x86_64 sems-1.3.1-4.fc14.1.x86_64 3:koffice- kpresenter-2.3.3-1.fc14.x86_64 python3-sip-4.12.1-4.fc14.i686 kdepimlibs- akonadi-4.6.1-1.fc14.i686 qedje-devel-0.4.0-8.fc14.x86_64 PyQwt- devel-5.2.0-10.fc14.i686 PyKDE4-akonadi-4.6.1-1.fc14.x86_64 kde-l10n- Arabic-4.6.1-1.fc14.1.noarch qscintilla-python-devel-2.4.6-2.fc14.noarch kdeedu-kstars-libs-4.6.1-2.fc14.x86_64 3:koffice-kdchart- devel-2.3.3-1.fc14.i686 3:koffice-kexi-driver-pgsql-2.3.3-1.fc14.x86_64 konq-plugins-4.6.1-1.fc14.x86_64 jpilot-1.8.0-2.fc14.x86_64 kdeedu-4.6.1-2.fc14.x86_64 PyKDE4-devel-4.6.1-1.fc14.i686 7:kdegraphics- devel-4.6.1-1.fc14.i686 kdeedu-libs-4.6.1-2.fc14.x86_64 1:kde-i18n- Tamil-3.5.10-14.fc14.noarch sems-conf_auth-1.3.1-4.fc14.1.x86_64 sip-4.12.1-4.fc14.x86_64 PyQt-devel-3.18.1-8.fc14.x86_64 qyoto-4.6.1-1.fc14.x86_64 sems-ivr-1.3.1-4.fc14.1.x86_64 kdegames3-libs-3.5.10-9.fc14.x86_64 qgis-1.6.0-3.fc14.1.x86_64 6:kdeutils- printer-applet-4.6.1-1.fc14.x86_64 kdeedu-math-libs-4.6.1-2.fc14.x86_64 kde-l10n-Gujarati-4.6.1-1.fc14.1.noarch kdebindings-4.6.1-1.fc14.i686 kdevplatform-libs-1.2.0-3.fc14.x86_64 phonon-4.4.4-2.fc14.x86_64 PyQt4-devel-4.8.3-2.fc14.i686 1:kde-i18n-French-3.5.10-14.fc14.noarch sip- macros-4.12.1-4.fc14.x86_64 PyKDE-devel-3.16.6-7.fc14.i686 php-qt- devel-4.6.1-1.fc14.i686 3:koffice-kword-libs-2.3.3-1.fc14.x86_64 3 :koffice-filters-2.3.3-1.fc14.x86_64 php-qt-4.6.1-1.fc14.x86_64 kde- plasma-yawp-0.3.6-1.fc14.2.x86_64 avogadro-libs-1.0.1-11.fc14.i686 korundum-devel-4.6.1-1.fc14.i686 kdebase-workspace-devel-4.6.1-2.fc14.i686 korundum-devel-4.6.1-1.fc14.x86_64 qscintilla-2.4.6-2.fc14.i686 3:koffice- karbon-libs-2.3.3-1.fc14.x86_64 python3-sip-devel-4.12.1-4.fc14.i686 python3-PyQt4-devel-4.8.3-2.fc14.i686 soprano-2.6.0-2.fc14.i686 kdevplatform-devel-1.2.0-3.fc14.x86_64 kdeplasma- addons-4.6.1-1.fc14.x86_64 2:phonon-backend-gstreamer-4.4.4-2.fc14.x86_64 kde-l10n-Galician-4.6.1-1.fc14.1.noarch kdebindings- devel-4.6.1-1.fc14.x86_64 6:kdegames-4.6.1-1.fc14.x86_64 3:koffice-kexi- driver-mysql-2.3.3-1.fc14.x86_64 kdepimlibs-akonadi-4.6.1-1.fc14.x86_64 phonon-devel-4.4.4-2.fc14.x86_64 akonadi-devel-1.5.1-1.fc14.x86_64 kde- l10n-Punjabi-4.6.1-1.fc14.1.noarch qzion-python-devel-0.4.0-10.fc14.x86_64 kde-l10n-Walloon-4.6.1-1.fc14.1.noarch 1:kde-i18n- Greek-3.5.10-14.fc14.noarch 1:mono-icon-theme-4.6.1-1.fc14.noarch kdegames3-3.5.10-9.fc14.x86_64 kross-ruby-4.6.1-1.fc14.x86_64 digikam- libs-1.9.0-1.fc14.i686 qedje-python-devel-0.4.0-8.fc14.i686 qgis-1.6.0-3.fc14.1.i686 python3-PyQt4-devel-4.8.3-2.fc14.x86_64 kipi- plugins-libs-1.9.0-1.fc14.i686 qscintilla-2.4.6-2.fc14.x86_64 3:koffice- filters-2.3.3-1.fc14.i686 kdevplatform-libs-1.2.0-3.fc14.i686 kde-l10n- German-4.6.1-1.fc14.1.noarch kde-l10n-Croatian-4.6.1-1.fc14.1.noarch kdeartwork-sounds-4.6.1-1.fc14.noarch 7:kdepim-libs-4.4.10-2.fc14.x86_64 7 :kdenetwork-libs-4.6.1-2.fc14.x86_64 kdeedu-marble- libs-4.6.1-2.fc14.x86_64 sip-devel-4.12.1-4.fc14.i686 1:kde-i18n- Korean-3.5.10-14.fc14.noarch 1:kde-i18n-Hindi-3.5.10-14.fc14.noarch kdeartwork-wallpapers-4.6.1-1.fc14.noarch qgis-grass-1.6.0-3.fc14.1.x86_64 1:kde-i18n-Catalan-3.5.10-14.fc14.noarch qedje-0.4.0-8.fc14.x86_64 kde- l10n-Italian-4.6.1-1.fc14.1.noarch 1:kde-i18n-Czech-3.5.10-14.fc14.noarch kdepimlibs-devel-4.6.1-1.fc14.x86_64 PyQt4-4.8.3-2.fc14.x86_64 1:kde-i18n- Turkish-3.5.10-14.fc14.noarch sip-4.12.1-4.fc14.i686 1:kde-i18n- Hungarian-3.5.10-14.fc14.noarch python3-PyQt4-4.8.3-2.fc14.x86_64 oxygen- cursor-themes-4.6.1-2.fc14.noarch libktorrent-devel-1.1.0-1.fc14.i686 kdegames3-devel-3.5.10-9.fc14.x86_64 kde-l10n- Kannada-4.6.1-1.fc14.1.noarch 1:kde-i18n-Norwegian-3.5.10-14.fc14.noarch kdegames3-libs-3.5.10-9.fc14.i686 qgis-devel-1.6.0-3.fc14.1.i686 kimono-4.6.1-1.fc14.x86_64 ktorrent-4.1.0-1.fc14.x86_64 3:koffice- kspread-2.3.3-1.fc14.x86_64 1:kde-i18n-Icelandic-3.5.10-14.fc14.noarch 6 :kdelibs-devel-4.6.1-4.fc14.x86_64 kdeedu-math-4.6.1-2.fc14.x86_64 PyKDE4-akonadi-4.6.1-1.fc14.i686 perl-Locale-US-1.2-2.fc14.noarch kde- l10n-Swedish-4.6.1-1.fc14.1.noarch qedje-0.4.0-8.fc14.i686 kdepimlibs-4.6.1-1.fc14.i686 kdeplasma-addons-devel-4.6.1-1.fc14.i686 1 :kde-i18n-German-3.5.10-14.fc14.noarch kdeplasma-addons- libs-4.6.1-1.fc14.x86_64 korundum-4.6.1-1.fc14.x86_64 kdebase-workspace- devel-4.6.1-2.fc14.x86_64 attica-0.2.0-1.fc14.i686 libktorrent- devel-1.1.0-1.fc14.x86_64 kde-l10n-Dutch-4.6.1-1.fc14.1.noarch kdeedu- libs-4.6.1-2.fc14.i686 kde-l10n-Basque-4.6.1-1.fc14.1.noarch PyQt4-4.8.3-2.fc14.i686 PyKDE4-4.6.1-1.fc14.x86_64 1:kde-i18n- Polish-3.5.10-14.fc14.noarch sems-gsm-1.3.1-4.fc14.1.x86_64 ktorrent- libs-4.1.0-1.fc14.x86_64 kde-l10n-Hebrew-4.6.1-1.fc14.1.noarch digikam- devel-1.9.0-1.fc14.i686 1:kde-i18n-Swedish-3.5.10-14.fc14.noarch 3 :koffice-devel-2.3.3-1.fc14.x86_64 1:kde-i18n- Serbian-3.5.10-14.fc14.noarch PyKDE4-devel-4.6.1-1.fc14.x86_64 soprano- apidocs-2.6.0-2.fc14.noarch qyoto-devel-4.6.1-1.fc14.x86_64 PyQt- examples-3.18.1-8.fc14.x86_64 sems-mailbox-1.3.1-4.fc14.1.x86_64 1:kde- i18n-Slovenian-3.5.10-14.fc14.noarch polkit-qt-devel-0.99.0-2.fc14.i686 3 :koffice-krita-2.3.3-1.fc14.x86_64 sems-pin_collect-1.3.1-4.fc14.1.x86_64 kdepimlibs-apidocs-4.6.1-1.fc14.noarch plasma-wallpaper- marble-4.6.1-1.fc14.x86_64 1:kde-i18n-Chinese-Big5-3.5.10-14.fc14.noarch akonadi-1.5.1-1.fc14.i686 6:kdelibs-devel-4.6.1-4.fc14.i686 kipi-plugins- libs-1.9.0-1.fc14.x86_64 kde-l10n-Indonesian-4.6.1-1.fc14.1.noarch 1 :kdepim-runtime-devel-4.4.10-2.fc14.x86_64 kde-plasma-smooth- tasks-0.0.1-0.1.wip20101106.fc14.2.x86_64 1:kde-i18n- Italian-3.5.10-14.fc14.noarch kde-l10n-French-4.6.1-1.fc14.1.noarch 1:kde- i18n-Finnish-3.5.10-14.fc14.noarch 1:kdeaccessibility-4.6.1-1.fc14.x86_64 sems-gateway-1.3.1-4.fc14.1.x86_64 9:kdevelop-devel-4.2.0-2.fc14.i686 sems-diameter_client-1.3.1-4.fc14.1.x86_64 1:kdeaccessibility- libs-4.6.1-1.fc14.x86_64 thunarx-python-0.2.3-3.fc14.1.x86_64 3:koffice- kplato-2.3.3-1.fc14.i686 kde-l10n-Russian-4.6.1-1.fc14.1.noarch kdebindings-devel-4.6.1-1.fc14.i686 1:kde-i18n- Punjabi-3.5.10-14.fc14.noarch shared-desktop-ontologies- devel-0.6.0-1.fc14.noarch 7:kdeadmin-4.6.1-1.fc14.x86_64 1:kde-i18n- Spanish-3.5.10-14.fc14.noarch akonadi-devel-1.5.1-1.fc14.i686 1:kde-i18n- Dutch-3.5.10-14.fc14.noarch phonon-backend-xine-4.4.4-3.fc14.x86_64 6 :kdemultimedia-devel-4.6.1-1.fc14.i686 1:kde-i18n- Hebrew-3.5.10-14.fc14.noarch 1:kde-i18n-Estonian-3.5.10-14.fc14.noarch kde-l10n-Lithuanian-4.6.1-1.fc14.1.noarch kdevplatform-1.2.0-3.fc14.x86_64 kdeedu-kstars-4.6.1-2.fc14.x86_64 sems-python-1.3.1-4.fc14.1.x86_64 kde- l10n-Hungarian-4.6.1-1.fc14.1.noarch QtRuby-4.6.1-1.fc14.x86_64 kde- plasma-ktorrent-4.1.0-1.fc14.x86_64 kde-l10n-Turkish-4.6.1-1.fc14.1.noarch 1:kdepim-runtime-devel-4.4.10-2.fc14.i686 kdeedu-devel-4.6.1-2.fc14.i686 qedje-python-0.4.0-8.fc14.x86_64 nuvola-icon-theme-4.6.1-1.fc14.noarch kde-style-phase-4.6.1-1.fc14.i686 soprano-devel-2.6.0-2.fc14.i686 sems- dsm-1.3.1-4.fc14.1.x86_64 kdebindings-4.6.1-1.fc14.x86_64 PyQt-3.18.1-8.fc14.x86_64 kde-l10n-Finnish-4.6.1-1.fc14.1.noarch 7:kdepim-4.4.10-2.fc14.x86_64 QtRuby-devel-4.6.1-1.fc14.i686 7:kdenetwork-4.6.1-2.fc14.x86_64 9:kdevelop-libs-4.2.0-2.fc14.i686 kdegames3-devel-3.5.10-9.fc14.i686 kde-l10n-Greek-4.6.1-1.fc14.1.noarch 1 :kde-i18n-Bengali-3.5.10-14.fc14.noarch kde-l10n- Slovenian-4.6.1-1.fc14.1.noarch avogadro-devel-1.0.1-11.fc14.x86_64 kde- l10n-Icelandic-4.6.1-1.fc14.1.noarch digikam-1.9.0-1.fc14.x86_64 kdesdk- devel-4.6.1-1.fc14.i686 3:koffice-kexi-libs-2.3.3-1.fc14.i686 kde-l10n- Catalan-4.6.1-1.fc14.1.noarch 7:kdegraphics-devel-4.6.1-1.fc14.x86_64 3 :koffice-suite-2.3.3-1.fc14.x86_64 2:phonon-backend- gstreamer-4.4.4-2.fc14.i686 avogadro-1.0.1-11.fc14.x86_64 calibre-0.7.38-4.fc14.x86_64 python3-PyQt4-4.8.3-2.fc14.i686 6 :kdemultimedia-libs-4.6.1-1.fc14.i686 qgis-devel-1.6.0-3.fc14.1.x86_64 qedje-devel-0.4.0-8.fc14.i686 polkit-kde-0.99.0-2.fc14.x86_64 kross- python-4.6.1-1.fc14.x86_64 kde-l10n-Irish-4.6.1-1.fc14.1.noarch polkit-qt- devel-0.99.0-2.fc14.x86_64 PyKDE-devel-3.16.6-7.fc14.x86_64 qyoto-4.6.1-1.fc14.i686 kde-l10n-Japanese-4.6.1-1.fc14.1.noarch QtRuby-4.6.1-1.fc14.i686 avogadro-libs-1.0.1-11.fc14.x86_64 9:kdevelop- devel-4.2.0-2.fc14.x86_64 backintime-kde-1.0.6-1.fc14.noarch 1:kde-i18n- Bulgarian-3.5.10-14.fc14.noarch python3-sip-4.12.1-4.fc14.x86_64 kdeedu- marble-4.6.1-2.fc14.x86_64 PyQwt-5.2.0-10.fc14.x86_64 kde-l10n- Kazakh-4.6.1-1.fc14.1.noarch 1:kde-i18n-Russian-3.5.10-14.fc14.noarch kde- l10n-Polish-4.6.1-1.fc14.1.noarch qscintilla-devel-2.4.6-2.fc14.x86_64 veusz-1.9-2.fc14.1.x86_64 7:kdenetwork-libs-4.6.1-2.fc14.i686 kde-l10n- Czech-4.6.1-1.fc14.1.noarch phonon-4.4.4-2.fc14.i686 kde-l10n- Norwegian-4.6.1-1.fc14.1.noarch phonon-backend-xine-4.4.4-3.fc14.i686 3 :koffice-kdchart-devel-2.3.3-1.fc14.x86_64 perl-Math-Random- ISAAC-1.004-2.fc14.noarch 6:kdegames-devel-4.6.1-1.fc14.i686 1:kde-i18n- Norwegian-Nynorsk-3.5.10-14.fc14.noarch }}} error: {{{ AssertionError: Build kicad-2011.01.28-1.rev2765.fc14 passed in as a pending build, but depcheck produced no result for it. }}} Full log attached. There are surely more builds like that, not just kicad. The question is - who's got the balls to fight the yum objects and find the problem? :-) Or Will, would you have a look at that? -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/284> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 18

[AutoQA] #271: Create autotestd systemd.service file for F15 (and beyond)
by fedora-badges 01 Jun '11

01 Jun '11

#271: Create autotestd systemd.service file for F15 (and beyond) -----------------------+---------------------------------------------------- Reporter: jlaska | Owner: Type: task | Status: new Priority: major | Milestone: Package Update Acceptance Test Plan Component: packaging | Keywords: -----------------------+---------------------------------------------------- 07:41:40 Viking-Ice: jlaska: nr.1 upstream man pages nr.2 comparing converting https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability ( The Fedora autotest-server package includes a sysVinit script. A systemd.service file will be needed for f15 and beyond. Guidance from Viking-Ice included below ... {{{ 07:41:40 Viking-Ice: jlaska: nr.1 upstream man pages nr.2 comparing converting https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability ( you can side by side view them ) nr.3 scim through Lennart's blog 07:42:36 jlaska: Viking-Ice: perfect, just the bread-crumb trail I needed. Thank you 07:43:04 * jlaska goes to create a ticket with these instructions (need to eventually create an autotestd.service) 07:44:02 Viking-Ice: I deliberately designed the wiki page so those wanting to convert could side by side compare what already had been converted for you know ah.. they solve this problem that way moment.. 07:45:14 <-- juhp [~petersen(a)66.187.239.10] has quit (Ping timeout: 240 seconds) 07:46:51 Viking-Ice: jlaska: throw this link into your pool http://0pointer.de/blog/projects/systemd-for-admins-3.html 07:48:21 Viking-Ice: jlaska: what he mentioned there is the skeleton to be built upon as inn the first example of the service file. Always start like that then gradually build on top of that if needed }}} -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/271> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

RHEL5 in AutoQA and python 2.4 compatibility
by Tim Flink 23 May '11

23 May '11

This came up in the review of #293 and I thought that I would bring it up on the list. Since our AutoQA server runs RHEL5, it is also running python 2.4 which doesn't support "finally" blocks. What is the minimum version of python we want to support? Should all of our code be 2.4 compatible or just the stuff that will likely run on the autotest server ( events, watchers etc.)? We already have several finally blocks in our tests in stable and a couple in the libs, so breaking 2.4 compatibility wouldn't be a huge deal in the tests since we haven't seen too many problems so far. Thoughts? Tim

5 9

[AutoQA] #208: update minimon to transport logs between guest and host via virtio
by fedora-badges 20 May '11

20 May '11

#208: update minimon to transport logs between guest and host via virtio -------------------+-------------------------------------------------------- Reporter: liam | Owner: Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: tests | Version: 1.0 Keywords: | -------------------+-------------------------------------------------------- Since minimon has to use network during test, some test cases will not activate network during test,in this case, minimon can not transport logs to host, test also be identified fail even it was successfully run. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/208> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 4

Decreasing Bodhi Comment Emails From AutoQA
by Tim Flink 12 May '11

12 May '11

Since this has almost nothing to do with the log output of depcheck upgradepath, I'm splitting this conversation off into another thread. As Kamil pointed out, my initial proposal was naive and needs more thought before implementing anything. We will soon have the ability to disable emails for comments in Bodhi and we need to figure out how to best make use of that ability. Lots of questions here, I'll save my thoughts for replying to myself. Tim How would we deal with tests that change state between PASS and FAIL? - Either 'PASS -> FAIL' or 'FAIL -> PASS' What emails do we want to get rid of? - Just certain 'PASS' messages? - All results messages? How do we expect maintainers to learn of AutoQA results if we turn off email notifications? Can we do this in a way such that it is configurable by maintainer? - If so, should we attempt this? - What is the benefit? How big is it? Can we just send a single email after all tests have passed? - Again, if so, should we? Is there another approach that would be better?

3 10

[PATCH] koji_utils: allow package download caching
by Kamil Paral 10 May '11

10 May '11

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

2 3

How do you test AutoQA?
by Tim Flink 02 May '11

02 May '11

I really can't tell if this is a particularly bad pain point for me since I work remotely and my internet connection isn't great (frequent SSL timeouts on koji, package downloads take forever) but I was wondering how you all went about testing AutoQA. For me, it really depends on what I'm trying to poke at. Most of the time, I'll run 'watch-koji-builds.py --verbose' if I'm trying to do some general testing. I keep track of the events that are called if I want to run something again ('autoqa post-bodhi-update-batch --targettag dist-f13-updates --arch x86_64 --arch i386 oxygen-gtk-1.0.4-1.fc13' as an example). If I'm trying to poke at something very specific, I find myself manually cobbling together some one-off script that runs something specific, like depcheck or upgradepath. Testing the interaction with Koji or Bodhi? I still haven't figured out a good way to do that. Thus far, I have been hacking in print statements into bodhi_utils or koji_utils but that doesn't quite cover everything. I ask because speaking for myself, I'm human. The more of a PITA it is to test something, the more likely I am to not do it or limit the number of times that I do test it. I think that I've been pretty good about testing stuff before pushing to master or stable, but I'm bothered by the amount of time I'm wasting on setting up tests and figuring out ways that I can trick AutoQA into going down code paths I want to test. I'm not saying that testing is a waste of time, just thinking that some of this test setup time could be much better spent on coding or additional testing. This isn't meant to be aimless complaining. I have some ideas on how to make the testing of AutoQA easier but I wanted to know if I was missing something obvious before I went too far down that road. Thanks, Tim

3 9

Proposed Change in Focus for 0.5.0
by Tim Flink 29 Apr '11

29 Apr '11

This ended up being rather long, so as an executive summary: I'm proposing that we change the 0.5.0 release of AutoQA to focus on getting the best information and the least noise to package maintainers. The focus would be on decreasing the number of emails that maintainers are receiving and improving the understandability of our logs (focusing on depcheck and upgradepath). This is a proposal, and I'm hoping to spark a discussion with this thread; not dictate a change to our roadmap. ------------------------------------------------------------ After the thread in devel@ about the volume of email coming out of bodhi for AutoQA 'PASSED' comments [1], I started thinking more about some of my past experiences with user complaints about the information they're presented with. My major concern is this: low signal to noise ratio (SNR) in output leads to users ignoring or refusing to use the tool as a whole. In my experience, once users start ignoring the tool it is a very difficult, uphill battle to get them to stop ignoring/hating/distrusting it. At the moment, I think that we have two major SNR ratio issues in AutoQA: comment emails coming out of bodhi and log files (especially depcheck and upgradepath). I can't seem to find the book I have that discusses it right now, but one of the things that I believe strongly is: testing output that is difficult for a human (with sufficient background knowledge) to understand isn't much better than not testing at all and is actually worse in some cases (we're not at that point, though). As I heard James Bach [2] put it; building software is like building a house. The developers are the construction workers and the testers are responsible for shining light on the places of the house that need work. The people with the light can't directly build the house but the construction workers can build a better house when the light is shining on the most important things to fix. When we have a low SNR, our output is muddled which isn't very far from putting tissue paper over the lights in the building analogy. The light might be in the right places but it's really hard for the builders to tell where exactly the light is pointing and have a harder time fixing those issues. So, what is the point of all this? Basically, I'm proposing that we hijack our current plans for 0.5.0 and re-focus on improving the SNR and usability of our current tests. Specifically, I would like to see us focus on two things: 1) Stop spamming maintainers with not-needed comment updates from bodhi - The current proposal is covered in #314 [3] 2) Improve our logging - focusing on depcheck and upgradepath - Goal 1: maintainers should be able to find the information they need about why their package failed within 30 seconds of opening the log file. - Goal 2: users should be able to easily find documentation on what a test is supposed to do and examples on how to triage a failure using our logging output. How could we get there? 1) This seems pretty straight forward to me. I didn't think that the bodhi side of things would get implemented quite that quickly or I would have said something earlier. From my conversations with Kamil and James, I don't think that there is going to be much resistance to this solution, though. 2) This would take a bit more work. I'm not sure if the exact goal of 30 seconds is possible but I'm of the opinion that it is a good place to start. We could start by looking at what we want the output to look like, determine if that is possible and do some user testing to get input from actual maintainers (not directly involved with AutoQA). I know why things are the way that they are and I don't disagree with those design decisions. Blamestorming is pointless and counter-productive, anyways. I'm interested in finding a solution :) And now, discussion time! Thoughts, suggestions, complaints? Tim [1] http://lists.fedoraproject.org/pipermail/devel/2011-April/150901.html [2] http://www.satisfice.com/aboutjames.shtml [3] https://fedorahosted.org/autoqa/ticket/314

4 6

AutoQA 0.4.7 released
by Kamil Paral 29 Apr '11

29 Apr '11

Please read: http://kparal.wordpress.com/2011/04/29/autoqa-0-4-7-released/

2 1

[AutoQA] #238: Move ResultsDB to Turbogears2 application
by fedora-badges 28 Apr '11

28 Apr '11

#238: Move ResultsDB to Turbogears2 application ----------------------------+----------------------------------------------- Reporter: jskladan | Owner: jskladan Type: task | Status: new Priority: major | Milestone: Resultdb Component: infrastructure | Keywords: ----------------------------+----------------------------------------------- Because the current implementation has noticeable disadvantages (speed, database management, ...), I'd like to rewrite the resultsdb backend using TG2. This will also provide a json-rpc, added to the xml-rpc interface. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/238> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[PUSHED] depcheck and koji_utils changes
by Kamil Paral 27 Apr '11

27 Apr '11

For those interested, I just pushed to master a few changes in depcheck test and koji_utils library: commit 53aa452e605b61944d6b657bc09813972be2b262 Author: Kamil Páral <kparal(a)redhat.com> Date: Wed Apr 27 17:12:56 2011 +0200 depcheck: download only necessary archs If depcheck is run on i686, don't download x86_64 RPMs because we don't need them. commit 549517418759080f18b6e37ae3801b72adbfc879 Author: Kamil Páral <kparal(a)redhat.com> Date: Wed Apr 27 14:41:48 2011 +0200 depcheck: unittests require x86_64 machine, abort for other archs commit c7ef84ea635b5c862fc7c087f504eea230786116 Author: Kamil Páral <kparal(a)redhat.com> Date: Wed Apr 27 13:11:41 2011 +0200 koji_utils: rename ensure_connection() to check_connection() The new name fits better. Also use check_connection() mainly in tests' setup() phase to check whether Koji is running. It is not necessary to execute it then again in run_once() stage, that doesn't help anything.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

autoqa-devel April 2011