June 2011 - autoqa-devel - Fedora mailing-lists

[AutoQA] #251: Move autotest applications into /usr/*bin
by fedora-badges 26 Sep '12

26 Sep '12

#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

1 2

[AutoQA] #191: Submit autotest for Fedora package approval
by fedora-badges 26 Sep '12

26 Sep '12

#191: Submit autotest for Fedora package approval -----------------------+---------------------------------------------------- Reporter: jlaska | Owner: Type: task | Status: new Priority: major | Milestone: Packaging and Review Component: packaging | Version: 1.0 Keywords: | -----------------------+---------------------------------------------------- * https://bugzilla.redhat.com/show_bug.cgi?id=548522 Currently stalled, pending packaging of the gwt package. This includes packaging all bundled .jar files included with gwt. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/191> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #157: conflicts: requested arch not respected
by fedora-badges 06 Aug '12

06 Aug '12

#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

1 7

[AutoQA] #270: Package and submit for review - compat-Django-1.0.4
by fedora-badges 02 Aug '12

02 Aug '12

#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

1 2

[AutoQA] #329: implement RPM checksum verification
by fedora-badges 30 Jul '12

30 Jul '12

#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

1 3

[AutoQA] #206: Update bodhi to enforce Package Update Acceptance policy
by fedora-badges 26 Mar '12

26 Mar '12

#206: Update bodhi to enforce Package Update Acceptance policy ----------------------------+----------------------------------------------- Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Package Update Acceptance Test Plan Component: infrastructure | Version: 1.0 Keywords: | ----------------------------+----------------------------------------------- In order to enforce the Package Update Acceptance Test Plan, Bodhi will need be modified to reject the push of any package that fails acceptance testing. The acceptance tests may need to send status/data to bodhi in order for it to make decisions about policy (see e.g. ticket #205). Later bodhi might just get data from resultdb (see that milestone for details). -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/206> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 7

[AutoQA] #252: Provide all autotest client combinations that we need
by fedora-badges 16 Mar '12

16 Mar '12

#252: Provide all autotest client combinations that we need ------------------------+--------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: 0.5.0 Component: production | Keywords: ------------------------+--------------------------------------------------- Currently our production server at http://autoqa.fedoraproject.org/ has 6 autotest clients assigned, all bare metals with Fedora 13 installed, with mixed architectures. But we need more. According to https://fedoraproject.org/wiki/Managing_autotest_labels we have two architecture labels, two fedora release labels (the two currently supported Fedora releases, I would omit Rawhide for now) and two virt labels (virtual machine or bare metal). We need machines for every combination of those labels (that is 8 IICC - if I count correctly). And we would like to see a bit more 64bit machines, because we use them for noarch tests. Currently the only test that really requires all those combinations is initscripts test. But there will be more in the future. It is quite some farm, but it seems we'll have to build it. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/252> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #255: Use Config class to simplify access to configuration options
by fedora-badges 07 Mar '12

07 Mar '12

#255: Use Config class to simplify access to configuration options --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: minor | Milestone: Component: core | Keywords: --------------------+------------------------------------------------------- Currently all our libraries and tests use ConfigParser and parse our configuration files (autoqa.conf, fas.conf, etc) directly. That is not ideal, it involves many lines of code, converting to correct variable types (int, bool), handling default values, and so on. We should create a Python class Config, which is initialized once in the beginning, and then can be access globally and easily from any other module. It will handle default values and type conversion centrally in one place. Also access will be much easier. PS: We already have autoqa.config module. Maybe we just don't use it? -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/255> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 6

[AutoQA] #338: AutoQATest.version - is it needed?
by fedora-badges 06 Mar '12

06 Mar '12

#338: AutoQATest.version - is it needed? -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Finger Food Component: tests | Keywords: -------------------------+-------------------------------------------------- In all our tests we have code like this: {{{ class rpmlint(AutoQATest): version = 1 # increment if setup() changes }}} The question is - is the ''version'' attribute needed and being used at all? I have never seen any difference in behavior, the setup() phase is run every time. We should have look at autotest documentation or source code whether this is being used and when. If we don't need it, let's remove it from all our tests and templates (the less code the better). -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/338> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 5

[AutoQA] #186: Automate media kit sanity tests
by fedora-badges 05 Mar '12

05 Mar '12

#186: Automate media kit sanity tests --------------------+------------------------------------------------------- Reporter: jlaska | Owner: lili Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- This ticket is intended to track automating the mediakit sanity tests (http://fedoraproject.org/wiki/Category:Installer_Image_Sanity_Test_Cases) Discussion already underway, along with code in Liam's private branch. For details see https://fedorahosted.org/pipermail/autoqa- devel/2010-June/000595.html -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/186> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 9

[AutoQA] #194: Incorporate automated anaconda storage suite
by fedora-badges 05 Mar '12

05 Mar '12

#194: Incorporate automated anaconda storage suite --------------------+------------------------------------------------------- Reporter: jlaska | Owner: Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- Chris Lumens has developed a virt-based test suite to automate different disk/storage install scenarios. I've discussed this briefly with Chris, but I'd be interested in seeing his test suite incorporated within autoqa and run on a regular interval (perhaps along-side Liam's install tests). The tests are currently available at http://clumens.fedorapeople.org /anaconda-storage-test/ -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/194> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #335: autotest_server autodetection fails
by fedora-badges 10 Feb '12

10 Feb '12

#335: autotest_server autodetection fails --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: minor | Milestone: Finger Food Component: core | Keywords: --------------------+------------------------------------------------------- Currently if we want to have working hyperlinks to logs, we have to fill in 'autotest_server' in autoqa.conf, because autodetection from hostname get's overwritten by empty value from the log. The links then look like this: http:///results/20-root/brutus.test.redhat.com/helloworld/results/full.log /autoqa: {{{ # Hardcoded defaults for the 'general' section conf = { 'local': 'false', 'testdir': '/usr/share/autotest/client/site_tests', 'eventdir': '/usr/share/autoqa/events', 'notification_email': '', 'autotest_server': socket.gethostname(), } conf = autoqa_conf.get_section('general', conf) conf = autoqa_conf.get_section('notifications', conf) # FIXME: conf['autotest_server'] gets overwritten here by empty value coming # from autoqa_conf }}} We can solve this by some easy hack or more properly by solving ticket #255. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/335> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #311: Improve Koji call performance with koji.ClientSession.multiCall
by fedora-badges 03 Feb '12

03 Feb '12

#311: Improve Koji call performance with koji.ClientSession.multiCall -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Finger Food Component: core | Keywords: -------------------------+-------------------------------------------------- We use koji calls quite extensively in watchers/tests/libraries. Some of the calls may be sped up substantially by using multicalls (executing multiple calls at once and waiting for a grouped result). See docstring at koji.!ClientSession.multiCall: {{{ Execute a multicall (multiple function calls passed to the server and executed at the same time, with results being returned in a batch). Before calling this method, the self.multicall field must have been set to True, and then one or more methods must have been called on the current session (those method calls will return None). On executing the multicall, the self.multicall field will be reset to False (so subsequent method calls will be executed immediately) and results will be returned in a list. The list will contain one element for each method added to the multicall, in the order it was added to the multicall. Each element of the list will be either a one-element list containing the result of the method call, or a map containing "faultCode" and "faultString" keys, describing the error that occurred during the method call. }}} Go through our code and re-write standard Koji calls to multicalls whenever possible. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/311> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 4

[AutoQA] #289: Missing autotest debug logs
by fedora-badges 12 Jan '12

12 Jan '12

#289: Missing autotest debug logs ----------------------+----------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: autotest | Keywords: ----------------------+----------------------------------------------------- I've found a test run where autotest debug logs are missing. What's wrong? We need them. http://autoqa.fedoraproject.org/results/72107-autotest/qa06.c.fedoraproject… -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/289> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 7

[AutoQA] #321: Store test logs for at least a month
by fedora-badges 16 Dec '11

16 Dec '11

#321: Store test logs for at least a month ------------------------+--------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Nice to have soon Component: production | Keywords: ------------------------+--------------------------------------------------- Today is May 3rd and some test output from April 30th is already inaccessible (https://admin.fedoraproject.org/updates/zabbix-1.8.5-1.fc15) That is problematic for package maintainers and also for us when dealing with test issues. We should aim to store results for at least a month. James mentioned that log pruning was run every 15 days, but sometimes it had to run more often, because e.g. some depcheck result logs may take up to several hundred MBs. James, can you provide links to such logs in order for us to evaluate that issue? Also, you can provide some disk space statistics? E.g. how much data we usually generate per week, how much disk space we have available, etc. If we can't extend available disk space easily, let's aim for reducing logs size. Can we do some form of transparent filesystem compression? From my experience depcheck logs have extremely good compress ratio. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/321> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 5

[AutoQA] #345: Implement file locks for all watchers
by fedora-badges 06 Dec '11

06 Dec '11

#345: Implement file locks for all watchers -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Finger Food Component: watchers | Keywords: -------------------------+-------------------------------------------------- In ticket #342 we implemented file lock for koji-bodhi watcher so that it is not run concurrently in multiple instances. Implement the same for all the remaining watchers. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/345> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 5

[AutoQA] #182: Write virt management script
by fedora-badges 22 Nov '11

22 Nov '11

#182: Write virt management script ----------------------------+----------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Virtualization Component: infrastructure | Version: 1.0 Keywords: | ----------------------------+----------------------------------------------- We must write a virt management script that will be able to the basic tasks for us: * query for available virt systems that we can use * switch between "real" disk and a disk snapshot for a virt system * revert a disk snapshot for a virt system * perform some command in a virt system - e.g. "yum update" for keeping it periodically up-to-date * install/reinstall a virt-system for us with specified distro * (some more to come?) We may want to use some pre-defined names syntax to recognize what virt systems do we have. For example: {{{ /dev/vg_autoqa/F12_i686_1 /dev/vg_autoqa/F12_i686_1-snap }}} -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/182> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

2 4

[AutoQA] #254: Trasnfer autoqa library to autotest clients
by fedora-badges 21 Nov '11

21 Nov '11

#254: Trasnfer autoqa library to autotest clients -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: autotest | Keywords: -------------------------+-------------------------------------------------- Currently autotest clients do not require autotest package installed, autotest server transfers all necessary files over rsync. But autotest clients require autoqa installed (because of our autoqa libraries), which in turn requires autotest. This creates quite a lot of confusion where to edit which files when testing new stuff. It would be much easier if we somehow transferred also the autoqa library together with autotest files. Can we bend autotest a little to rsync also our library to the client? Or, can we use similar approach as copying the config files to the test directory also with autoqa library? It would be great. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/254> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 14

[AutoQA] #196: Log failed job scheduling
by fedora-badges 11 Nov '11

11 Nov '11

#196: Log failed job scheduling -------------------------+-------------------------------------------------- Reporter: kparal | Owner: kparal Type: enhancement | Status: new Priority: major | Milestone: Component: harness | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- Currently when we schedule a job and it fails, we just print it out and forget about it: {{{ retval = schedule_job(control, email=email, name=testname, required_arch=arch, dryrun=opts.dryrun, labels=aq_labels) if retval != 0: print "ERROR: failed to schedule job %s" % testname }}} That should not be the case. We should: * use syslog and log important stuff to /var/log/autoqa.log or similar * send an email about failed scheduling to autoqa-results That way we will know something is wrong and will be able to fix it. Otherwise it just silently fails and we don't know about it. Feel free to reassign the ticket if you want to work on it. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/196> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 14

[AutoQA] #347: Test results are sometimes linked incorrectly in Bodhi
by fedora-badges 11 Nov '11

11 Nov '11

#347: Test results are sometimes linked incorrectly in Bodhi ------------------------+--------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: production | Keywords: ------------------------+--------------------------------------------------- Some Bodhi comments links are split in half, breaking the hyperlink: * https://admin.fedoraproject.org/updates/gnome-commander-1.2.8.12-1.fc15 * https://admin.fedoraproject.org/updates/tzdata-2011h-1.fc15 But some links are OK, even though the text length is about the same (and it's even from the same test run): * https://admin.fedoraproject.org/updates/xmlcopyeditor-1.2.0.4-1.fc14 Is it our problem or Bodhi problem? -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/347> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

2 49

[AutoQA] #192: Submit autoqa for Fedora package approval
by fedora-badges 13 Oct '11

13 Oct '11

#192: Submit autoqa for Fedora package approval -----------------------+---------------------------------------------------- Reporter: jlaska | Owner: Type: task | Status: new Priority: major | Milestone: Packaging and Review Component: packaging | Version: 1.0 Keywords: | -----------------------+---------------------------------------------------- Currently stalled, pending packaging of the gwt and autotest package. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/192> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #180: Initscript review: vsftpd
by fedora-badges 10 Oct '11

10 Oct '11

#180: Initscript review: vsftpd ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: minor | Milestone: Initscripts review Component: tests | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Check the test according to the <https://fedorahosted.org/autoqa/wiki/initscripts> -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/180> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #178: Initscript review: squid
by fedora-badges 10 Oct '11

10 Oct '11

#178: Initscript review: squid ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: minor | Milestone: Initscripts review Component: tests | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Check the test according to the <https://fedorahosted.org/autoqa/wiki/initscripts> -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/178> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #177: Initscript review: setroubleshoot
by fedora-badges 10 Oct '11

10 Oct '11

#177: Initscript review: setroubleshoot ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: minor | Milestone: Initscripts review Component: tests | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Check the test according to the <https://fedorahosted.org/autoqa/wiki/initscripts> -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/177> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #175: Initscript review: postgresql
by fedora-badges 10 Oct '11

10 Oct '11

#175: Initscript review: postgresql ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: minor | Milestone: Initscripts review Component: tests | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Check the test according to the <https://fedorahosted.org/autoqa/wiki/initscripts> -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/175> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 4

[AutoQA] #174: Initscript review: openswan
by fedora-badges 10 Oct '11

10 Oct '11

#174: Initscript review: openswan ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: minor | Milestone: Initscripts review Component: tests | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Check the test according to the <https://fedorahosted.org/autoqa/wiki/initscripts> -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/174> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #173: Initscript review: openldap
by fedora-badges 10 Oct '11

10 Oct '11

#173: Initscript review: openldap ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: minor | Milestone: Initscripts review Component: tests | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Check the test according to the <https://fedorahosted.org/autoqa/wiki/initscripts> -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/173> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #171: Initscript review: nss-pam-ldapd
by fedora-badges 10 Oct '11

10 Oct '11

#171: Initscript review: nss-pam-ldapd ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: minor | Milestone: Initscripts review Component: tests | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Check the test according to the <https://fedorahosted.org/autoqa/wiki/initscripts> -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/171> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #169: Initscript review: net-snmp
by fedora-badges 10 Oct '11

10 Oct '11

#169: Initscript review: net-snmp ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: minor | Milestone: Initscripts review Component: tests | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Check the test according to the <https://fedorahosted.org/autoqa/wiki/initscripts> -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/169> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #125: initscripts: Choosing the right repo for dependencies
by fedora-badges 10 Oct '11

10 Oct '11

#125: initscripts: Choosing the right repo for dependencies -------------------------+-------------------------------------------------- Reporter: kparal | Owner: jskladan Type: task | Status: new Priority: major | Milestone: Component: tests | Version: 1.0 Keywords: initscripts | -------------------------+-------------------------------------------------- Currently after new Koji build the initscripts test downloads all relevant binary packages (related to the particular source package) and installs them. But the RPM dependencies are installed from stable/updates repos, not from Koji. Also the dependencies parsed out of Makefile are installed from stable/updates repos. We have to inquire a little more into this situation. Is it sufficient/desirable? Or is it desirable to download dependencies from updates-testing or bleeding edge Koji? May the initscripts test sometimes fail because of insufficient dependencies are in stable/updates repos? This also depends on cases when we are going to use initscripts test. If it will be used with Bodhi hook, it will be probably easier to solve it than when used with Koji hook. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/125> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #224: initscripts: installing older package then current fails
by fedora-badges 10 Oct '11

10 Oct '11

#224: initscripts: installing older package then current fails --------------------+------------------------------------------------------- Reporter: kparal | Owner: jskladan Type: defect | Status: new Priority: major | Milestone: Package Update Acceptance Test Plan Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- In initscripts test we install some packages. But if those packages are older than currently installed, the test crashes. Usually we test only very new package builds, but in same cases this can also happen and we should have it handled. {{{ [root@aqd autoqa]# autoqa post-koji-build --kojitag dist-f13 openssh-5.4p1-1.fc13 --local -t initscripts 14:28:27 INFO | Writing results to /usr/share/autotest/client/results /post-koji-build:initscripts.noarch 14:28:27 INFO | Initializing the state engine 14:28:27 DEBUG| Persistent state variable __steps now set to [] 14:28:27 INFO | Symlinking init scripts 14:28:27 DEBUG| Running 'grep :initdefault: /etc/inittab' 14:28:27 DEBUG| Running 'ln -sf /usr/share/autotest/client/tools/autotest /etc/init.d/autotest' 14:28:27 DEBUG| Running 'ln -sf /usr/share/autotest/client/tools/autotest /etc/rc3.d/S99autotest' 14:28:27 DEBUG| Dropping caches 14:28:27 DEBUG| Running 'sync' 14:28:27 DEBUG| Running 'echo 3 > /proc/sys/vm/drop_caches' 14:28:27 DEBUG| Running 'rpm -qa' 14:28:28 INFO | START ---- ---- timestamp=1284121708 localtime=Sep 10 14:28:28 14:28:28 DEBUG| Persistent state variable __group_level now set to 1 14:28:28 INFO | START initscripts initscripts timestamp=1284121708 localtime=Sep 10 14:28:28 14:28:28 DEBUG| Persistent state variable __group_level now set to 2 14:28:28 DEBUG| Crash handling system enabled 14:28:28 DEBUG| Running 'rpm -qa' 14:28:29 INFO | /etc/yum.repos.d/beakerlib.repo:baseurl=http://afri.fedorapeople.org/beakerlib/ 14:28:29 DEBUG| Running 'yum -y install beakerlib' 14:28:29 DEBUG| [stdout] Setting up Install Process 14:28:30 DEBUG| [stdout] Package beakerlib-1.3-1.fc13.noarch already installed and latest version 14:28:30 DEBUG| [stdout] Nothing to do 14:28:31 INFO | Test started. Number of iterations: 1 14:28:31 INFO | Executing iteration 1 of 1 14:28:31 INFO | Dropping caches between iterations 14:28:31 DEBUG| Running 'sync' 14:28:31 DEBUG| Running 'echo 3 > /proc/sys/vm/drop_caches' 14:28:31 INFO | ======================================== 14:28:31 INFO | openssh-5.4p1-1.fc13 14:28:31 INFO | ======================================== 14:28:32 INFO | Saving RPMs to /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms 14:28:32 INFO | Grabbing http://koji.fedoraproject.org/packages/openssh/5.4p1/1.fc13/x86_64/pam_ssh_… 14:28:34 INFO | Grabbing http://koji.fedoraproject.org/packages/openssh/5.4p1/1.fc13/x86_64 /openssh-askpass-5.4p1-1.fc13.x86_64.rpm 14:28:35 INFO | Grabbing http://koji.fedoraproject.org/packages/openssh/5.4p1/1.fc13/x86_64 /openssh-server-5.4p1-1.fc13.x86_64.rpm 14:28:37 INFO | Grabbing http://koji.fedoraproject.org/packages/openssh/5.4p1/1.fc13/x86_64 /openssh-clients-5.4p1-1.fc13.x86_64.rpm 14:28:39 INFO | Grabbing http://koji.fedoraproject.org/packages/openssh/5.4p1/1.fc13/x86_64/openssh-… 14:28:41 DEBUG| Running 'yum -y --nogpgcheck localinstall /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/pam_ssh_agent_auth-0.9.2-24.1.fc13.x86_64.rpm /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh- askpass-5.4p1-1.fc13.x86_64.rpm /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh- server-5.4p1-1.fc13.x86_64.rpm /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh- clients-5.4p1-1.fc13.x86_64.rpm /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh-5.4p1-1.fc13.x86_64.rpm' 14:28:47 ERROR| Exception escaping from test: Traceback (most recent call last): File "/usr/share/autotest/client/common_lib/test.py", line 384, in _exec _call_test_function(self.execute, *p_args, **p_dargs) File "/usr/share/autotest/client/common_lib/test.py", line 570, in _call_test_function return func(*args, **dargs) File "/usr/share/autotest/client/common_lib/test.py", line 279, in execute postprocess_profiled_run, args, dargs) File "/usr/share/autotest/client/common_lib/test.py", line 201, in _call_run_once self.run_once(*args, **dargs) File "/usr/lib/python2.6/site-packages/autoqa/decorators.py", line 71, in newf f_result = f(*args, **kwargs) #call the decorated function File "/usr/share/autotest/client/site_tests/initscripts/initscripts.py", line 158, in run_once utils.system_output(cmd) File "/usr/share/autotest/client/common_lib/utils.py", line 689, in system_output args=args).stdout File "/usr/share/autotest/client/common_lib/utils.py", line 425, in run "Command returned non-zero exit status") CmdError: Command <yum -y --nogpgcheck localinstall /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/pam_ssh_agent_auth-0.9.2-24.1.fc13.x86_64.rpm /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh- askpass-5.4p1-1.fc13.x86_64.rpm /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh- server-5.4p1-1.fc13.x86_64.rpm /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh- clients-5.4p1-1.fc13.x86_64.rpm /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh-5.4p1-1.fc13.x86_64.rpm> failed, rc=1, Command returned non-zero exit status * Command: yum -y --nogpgcheck localinstall /usr/share/autotest/client/tmp/tmpS_K1om _initscripts/rpms/pam_ssh_agent_auth-0.9.2-24.1.fc13.x86_64.rpm /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh- askpass-5.4p1-1.fc13.x86_64.rpm /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh- server-5.4p1-1.fc13.x86_64.rpm /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh- clients-5.4p1-1.fc13.x86_64.rpm /usr/share/autotest/client/tmp/tmpS_K1om_i nitscripts/rpms/openssh-5.4p1-1.fc13.x86_64.rpm Exit status: 1 Duration: 0 stdout: Setting up Local Package Process Examining /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/pam_ssh_agent_auth-0.9.2-24.1.fc13.x86_64.rpm: pam_ssh_agent_auth-0.9.2-24.1.fc13.x86_64 Marking /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/pam_ssh_agent_auth-0.9.2-24.1.fc13.x86_64.rpm to be installed Examining /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms /openssh-askpass-5.4p1-1.fc13.x86_64.rpm: openssh- askpass-5.4p1-1.fc13.x86_64 Marking /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh- askpass-5.4p1-1.fc13.x86_64.rpm to be installed Examining /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms /openssh-server-5.4p1-1.fc13.x86_64.rpm: openssh- server-5.4p1-1.fc13.x86_64 /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh- server-5.4p1-1.fc13.x86_64.rpm: does not update installed package. Examining /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms /openssh-clients-5.4p1-1.fc13.x86_64.rpm: openssh- clients-5.4p1-1.fc13.x86_64 /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh- clients-5.4p1-1.fc13.x86_64.rpm: does not update installed package. Examining /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh-5.4p1-1.fc13.x86_64.rpm: openssh-5.4p1-1.fc13.x86_64 /usr/share/autotest/client/tmp/tmpS_K1om_initscripts/rpms/openssh-5.4p1-1.fc13.x86_64.rpm: does not update installed package. Resolving Dependencies --> Running transaction check ---> Package openssh-askpass.x86_64 0:5.4p1-1.fc13 set to be installed --> Processing Dependency: openssh = 5.4p1-1.fc13 for package: openssh- askpass-5.4p1-1.fc13.x86_64 --> Processing Dependency: libX11.so.6()(64bit) for package: openssh- askpass-5.4p1-1.fc13.x86_64 --> Processing Dependency: libatk-1.0.so.0()(64bit) for package: openssh- askpass-5.4p1-1.fc13.x86_64 --> Processing Dependency: libcairo.so.2()(64bit) for package: openssh- askpass-5.4p1-1.fc13.x86_64 --> Processing Dependency: libfontconfig.so.1()(64bit) for package: openssh-askpass-5.4p1-1.fc13.x86_64 --> Processing Dependency: libgdk-x11-2.0.so.0()(64bit) for package: openssh-askpass-5.4p1-1.fc13.x86_64 --> Processing Dependency: libgdk_pixbuf-2.0.so.0()(64bit) for package: openssh-askpass-5.4p1-1.fc13.x86_64 --> Processing Dependency: libgtk-x11-2.0.so.0()(64bit) for package: openssh-askpass-5.4p1-1.fc13.x86_64 --> Processing Dependency: libpango-1.0.so.0()(64bit) for package: openssh-askpass-5.4p1-1.fc13.x86_64 --> Processing Dependency: libpangocairo-1.0.so.0()(64bit) for package: openssh-askpass-5.4p1-1.fc13.x86_64 --> Processing Dependency: libpangoft2-1.0.so.0()(64bit) for package: openssh-askpass-5.4p1-1.fc13.x86_64 ---> Package pam_ssh_agent_auth.x86_64 0:0.9.2-24.1.fc13 set to be installed --> Running transaction check ---> Package atk.x86_64 0:1.30.0-1.fc13 set to be installed ---> Package cairo.x86_64 0:1.8.10-1.fc13 set to be installed --> Processing Dependency: libpng12.so.0(PNG12_0)(64bit) for package: cairo-1.8.10-1.fc13.x86_64 --> Processing Dependency: libpixman-1.so.0()(64bit) for package: cairo-1.8.10-1.fc13.x86_64 --> Processing Dependency: libXrender.so.1()(64bit) for package: cairo-1.8.10-1.fc13.x86_64 --> Processing Dependency: libpng12.so.0()(64bit) for package: cairo-1.8.10-1.fc13.x86_64 ---> Package fontconfig.x86_64 0:2.8.0-1.fc13 set to be installed ---> Package gtk2.x86_64 0:2.20.1-1.fc13 set to be installed --> Processing Dependency: libXrandr >= 1.2.99.4-2 for package: gtk2-2.20.1-1.fc13.x86_64 --> Processing Dependency: libtiff >= 3.6.1 for package: gtk2-2.20.1-1.fc13.x86_64 --> Processing Dependency: hicolor-icon-theme for package: gtk2-2.20.1-1.fc13.x86_64 --> Processing Dependency: libXrandr.so.2()(64bit) for package: gtk2-2.20.1-1.fc13.x86_64 --> Processing Dependency: libtiff.so.3()(64bit) for package: gtk2-2.20.1-1.fc13.x86_64 --> Processing Dependency: libXdamage.so.1()(64bit) for package: gtk2-2.20.1-1.fc13.x86_64 --> Processing Dependency: libXcursor.so.1()(64bit) for package: gtk2-2.20.1-1.fc13.x86_64 --> Processing Dependency: libcups.so.2()(64bit) for package: gtk2-2.20.1-1.fc13.x86_64 --> Processing Dependency: libXi.so.6()(64bit) for package: gtk2-2.20.1-1.fc13.x86_64 --> Processing Dependency: libjasper.so.1()(64bit) for package: gtk2-2.20.1-1.fc13.x86_64 --> Processing Dependency: libXext.so.6()(64bit) for package: gtk2-2.20.1-1.fc13.x86_64 --> Processing Dependency: libXcomposite.so.1()(64bit) for package: gtk2-2.20.1-1.fc13.x86_64 --> Processing Dependency: libXinerama.so.1()(64bit) for package: gtk2-2.20.1-1.fc13.x86_64 --> Processing Dependency: libXfixes.so.3()(64bit) for package: gtk2-2.20.1-1.fc13.x86_64 ---> Package libX11.x86_64 0:1.3.1-3.fc13 set to be installed --> Processing Dependency: libX11-common = 1.3.1-3.fc13 for package: libX11-1.3.1-3.fc13.x86_64 --> Processing Dependency: libxcb.so.1()(64bit) for package: libX11-1.3.1-3.fc13.x86_64 ---> Package openssh-askpass.x86_64 0:5.4p1-1.fc13 set to be installed --> Processing Dependency: openssh = 5.4p1-1.fc13 for package: openssh- askpass-5.4p1-1.fc13.x86_64 ---> Package pango.x86_64 0:1.28.0-1.fc13 set to be installed --> Processing Dependency: libthai >= 0.1.9 for package: pango-1.28.0-1.fc13.x86_64 --> Processing Dependency: libthai.so.0(LIBTHAI_0.1)(64bit) for package: pango-1.28.0-1.fc13.x86_64 --> Processing Dependency: libthai.so.0()(64bit) for package: pango-1.28.0-1.fc13.x86_64 --> Processing Dependency: libXft.so.2()(64bit) for package: pango-1.28.0-1.fc13.x86_64 --> Running transaction check ---> Package cups-libs.x86_64 1:1.4.4-5.fc13 set to be installed --> Processing Dependency: libgnutls.so.26(GNUTLS_1_4)(64bit) for package: 1:cups-libs-1.4.4-5.fc13.x86_64 --> Processing Dependency: libavahi-common.so.3()(64bit) for package: 1 :cups-libs-1.4.4-5.fc13.x86_64 --> Processing Dependency: libgnutls.so.26()(64bit) for package: 1:cups- libs-1.4.4-5.fc13.x86_64 --> Processing Dependency: libavahi-client.so.3()(64bit) for package: 1 :cups-libs-1.4.4-5.fc13.x86_64 ---> Package hicolor-icon-theme.noarch 0:0.12-1.fc13 set to be installed ---> Package jasper-libs.x86_64 0:1.900.1-15.fc13 set to be installed ---> Package libX11-common.noarch 0:1.3.1-3.fc13 set to be installed ---> Package libXcomposite.x86_64 0:0.4.1-2.fc13 set to be installed ---> Package libXcursor.x86_64 0:1.1.10-4.fc13 set to be installed --> Processing Dependency: dmz-cursor-themes for package: libXcursor-1.1.10-4.fc13.x86_64 ---> Package libXdamage.x86_64 0:1.1.2-2.fc13 set to be installed ---> Package libXext.x86_64 0:1.1.2-2.fc13 set to be installed ---> Package libXfixes.x86_64 0:4.0.4-2.fc13 set to be installed ---> Package libXft.x86_64 0:2.1.14-1.fc13 set to be installed ---> Package libXi.x86_64 0:1.3.2-1.fc13 set to be installed ---> Package libXinerama.x86_64 0:1.1-2.fc13 set to be installed ---> Package libXrandr.x86_64 0:1.3.0-5.fc13 set to be installed ---> Package libXrender.x86_64 0:0.9.5-1.fc13 set to be installed ---> Package libpng.x86_64 2:1.2.44-1.fc13 set to be installed ---> Package libthai.x86_64 0:0.1.14-2.fc13 set to be installed ---> Package libtiff.x86_64 0:3.9.4-1.fc13 set to be installed ---> Package libxcb.x86_64 0:1.5-1.fc13 set to be installed --> Processing Dependency: libXau.so.6()(64bit) for package: libxcb-1.5-1.fc13.x86_64 ---> Package openssh-askpass.x86_64 0:5.4p1-1.fc13 set to be installed --> Processing Dependency: openssh = 5.4p1-1.fc13 for package: openssh- askpass-5.4p1-1.fc13.x86_64 ---> Package pixman.x86_64 0:0.18.0-1.fc13 set to be installed --> Running transaction check ---> Package avahi.x86_64 0:0.6.25-7.fc13 set to be installed --> Processing Dependency: libdaemon >= 0.11 for package: avahi-0.6.25-7.fc13.x86_64 --> Processing Dependency: dbus for package: avahi-0.6.25-7.fc13.x86_64 --> Processing Dependency: libdaemon.so.0()(64bit) for package: avahi-0.6.25-7.fc13.x86_64 ---> Package dmz-cursor-themes.noarch 0:0.4-3.fc13 set to be installed ---> Package gnutls.x86_64 0:2.8.6-2.fc13 set to be installed --> Processing Dependency: libtasn1.so.3(LIBTASN1_0_3)(64bit) for package: gnutls-2.8.6-2.fc13.x86_64 --> Processing Dependency: libtasn1.so.3()(64bit) for package: gnutls-2.8.6-2.fc13.x86_64 ---> Package libXau.x86_64 0:1.0.5-1.fc12 set to be installed ---> Package openssh-askpass.x86_64 0:5.4p1-1.fc13 set to be installed --> Processing Dependency: openssh = 5.4p1-1.fc13 for package: openssh- askpass-5.4p1-1.fc13.x86_64 --> Running transaction check ---> Package dbus.x86_64 1:1.2.24-1.fc13 set to be installed ---> Package libdaemon.x86_64 0:0.14-1.fc13 set to be installed ---> Package libtasn1.x86_64 0:2.4-2.fc13 set to be installed ---> Package openssh-askpass.x86_64 0:5.4p1-1.fc13 set to be installed --> Processing Dependency: openssh = 5.4p1-1.fc13 for package: openssh- askpass-5.4p1-1.fc13.x86_64 --> Finished Dependency Resolution You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest stderr: Error: Package: openssh-askpass-5.4p1-1.fc13.x86_64 (/openssh- askpass-5.4p1-1.fc13.x86_64) Requires: openssh = 5.4p1-1.fc13 Installed: openssh-5.4p1-3.fc13.x86_64 (@updates) openssh = 5.4p1-3.fc13 Available: openssh-5.4p1-1.fc13.x86_64 (fedora) openssh = 5.4p1-1.fc13 }}} -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/224> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[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] #330: upgradepath: improve behavior when pushing update to multiple releases
by fedora-badges 04 Aug '11

04 Aug '11

#330: upgradepath: improve behavior when pushing update to multiple releases -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: major | Milestone: 0.5.0 Component: tests | Keywords: -------------------------+-------------------------------------------------- This ticket stems from my talk to mcepl and our following discussion: https://fedorahosted.org/pipermail/autoqa-devel/2011-May/002215.html Package maintainers usually push fixes to many Fedora releases at once. Upgradepath usually fails for all but the highest one. We should improve the output. 1. If upgradepath passes, no changes. 2. If upgradepath fails, check update-pending repos for the failed sections and determine whether the same proposed update is available there. If it is, check upgradepath again and determine whether test would pass if all those proposed updates for all releases were pushed at the same time. Inform the user about it. 3. If the condition in 2) is valid, change FAIL result to NEEDS_INSPECTION. I'll gladly take this ticket when I finish my current work. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/330> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 14

[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] #325: depcheck: setup tests such that conflicting packages are not tested together
by fedora-badges 18 Jul '11

18 Jul '11

#325: depcheck: setup tests such that conflicting packages are not tested together --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: task | Status: new Priority: major | Milestone: Future tasks Component: tests | Keywords: --------------------+------------------------------------------------------- We have found a couple of issues with depcheck lately where the setup of the test causes failures because of inherent conflicts between packages in the same update (#284, #384). In order to successfully test the dependencies of all packages, we would need to setup the runs differently such that we're not testing packages that are designed to fail when installed together. This would probably involve parsing the RPM conflicts during setup and changing the set of pending/accepted packages accordingly. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/325> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 6

[AutoQA] #328: depcheck: should not test packages from both x86_64 and iX86 unless needed
by fedora-badges 18 Jul '11

18 Jul '11

#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Future tasks Component: tests | Keywords: --------------------+------------------------------------------------------- Right now, depcheck is pulling in all packages (iX86 and x86_64) on x86_64 platforms as pending or accepted. This is not needed and can cause problems with some packages (see #284). Depcheck should only pull in iX86 packages on x86_64 when those packages are explicitly needed. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/328> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 9

[AutoQA] #322: depcheck (yum) gets stuck in a loop
by fedora-badges 18 Jul '11

18 Jul '11

#322: depcheck (yum) gets stuck in a loop --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Keywords: --------------------+------------------------------------------------------- See the log tflink posted in https://fedorahosted.org/autoqa/ticket/321#comment:2 . This is the pattern: {{{ 20:54:36 DEBUG| [stdout] SKIPBROKEN: ########### Round 5068 ################ 20:54:36 DEBUG| [stdout] SKIPBROKEN: Current Transaction : 215 member(s) 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 389-ds- base-1.2.8.2-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 389-ds- base-1.2.8.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 389-ds- base-1.2.8.2-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 389-ds- base-1.2.8.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 389-ds- base-1.2.8.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 389-ds- base-1.2.8.2-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : freeipa-server-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 389-ds-base- devel-1.2.8.2-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 389-ds- base-devel-1.2.8.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 389-ds-base- devel-1.2.8.2-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 389-ds- base-devel-1.2.8.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 389-ds-base- devel-1.2.8.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 389-ds- base-devel-1.2.8.2-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 389-ds-base- libs-1.2.8.2-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 389-ds- base-libs-1.2.8.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 389-ds-base- libs-1.2.8.2-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 389-ds- base-libs-1.2.8.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 389-ds-base- libs-1.2.8.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : 389-ds- base-1.2.8.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : 389-ds- base-devel-1.2.8.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 389-ds- base-libs-1.2.8.2-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : aeidon-0.17.1-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : aeidon-0.17.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : aeidon-0.17.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : aeidon-0.17.1-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : anaconda-15.29-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : anaconda-15.30-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : anaconda-15.30-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : anaconda-15.29-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: install : ant- antlr3-20110110-3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: install : ant- antlr3-javadoc-20110110-3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : avr- gcc-4.5.1-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : avr- gcc-4.5.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : avr- gcc-4.5.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : avr- gcc-4.5.1-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : avr- gcc-c++-4.5.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : avr- gcc-c++-4.5.1-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : avr- gcc-c++-4.5.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : avr- gcc-c++-4.5.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : avr- gcc-c++-4.5.1-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : binutils-2.21.51.0.6-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : binutils-2.21.51.0.6-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : binutils-2.21.51.0.6-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : binutils-2.21.51.0.6-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : binutils- devel-2.21.51.0.6-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : binutils-devel-2.21.51.0.6-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : binutils- devel-2.21.51.0.6-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : binutils- devel-2.21.51.0.6-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:dbus-1.4.6-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1:dbus-1.4.6-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:dbus-1.4.6-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:dbus-1.4.6-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : 1:dbus- devel-1.4.6-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : 1:dbus- doc-1.4.6-4.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : 1:dbus-x11-1.4.6-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:dbus- devel-1.4.6-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1:dbus- devel-1.4.6-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:dbus- devel-1.4.6-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:dbus- devel-1.4.6-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:dbus- doc-1.4.6-3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1:dbus- doc-1.4.6-4.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:dbus- doc-1.4.6-4.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:dbus- doc-1.4.6-3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:dbus- libs-1.4.6-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1:dbus- libs-1.4.6-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:dbus- libs-1.4.6-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : 1:dbus-1.4.6-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:dbus- libs-1.4.6-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:dbus-x11-1.4.6-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1:dbus-x11-1.4.6-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:dbus-x11-1.4.6-4.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:dbus-x11-1.4.6-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : eclipse- dtp-1.8.1-3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : eclipse-dtp-1.8.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : eclipse- dtp-1.8.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : eclipse- dtp-1.8.1-3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : eclipse- eclemma-1.5.1-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : eclipse-eclemma-1.5.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : eclipse- eclemma-1.5.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : eclipse- eclemma-1.5.1-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : eclipse- gef-3.6.1-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : eclipse-gef-3.6.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : eclipse- gef-3.6.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : eclipse- gef-3.6.1-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : eclipse-gef-examples-3.6.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : eclipse-gef-sdk-3.6.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : eclipse-gef- examples-3.6.1-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : eclipse-gef-examples-3.6.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : eclipse-gef- examples-3.6.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : eclipse- gef-examples-3.6.1-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : eclipse-gef- sdk-3.6.1-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : eclipse-gef-sdk-3.6.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : eclipse-gef- sdk-3.6.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : eclipse- gef-sdk-3.6.1-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : eclipse- moreunit-2.3.0-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : eclipse-moreunit-2.4.1-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : eclipse- moreunit-2.4.1-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : eclipse- moreunit-2.3.0-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : firstboot-1.117-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : firstboot-1.118-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : firstboot-1.118-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : firstboot-1.117-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : freeipa- admintools-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : freeipa-admintools-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : freeipa- admintools-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : freeipa- admintools-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : freeipa-server-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : freeipa- client-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : freeipa-client-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : freeipa- client-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : freeipa-admintools-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : freeipa- client-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : freeipa-server-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : freeipa- python-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : freeipa-python-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : freeipa- python-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : freeipa-admintools-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : freeipa-client-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : freeipa- python-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : freeipa-server-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : freeipa- server-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : freeipa-server-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : freeipa- server-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : freeipa- server-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : freeipa-server-selinux-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : freeipa-server- selinux-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : freeipa-server-selinux-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : freeipa-server- selinux-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : freeipa-server-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : freeipa- server-selinux-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : gaupol-0.17.1-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : gaupol-0.17.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : gaupol-0.17.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : gaupol-0.17.1-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : gdb-7.2.90.20110411-34.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : gdb-7.2.90.20110429-36.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : gdb-7.2.90.20110429-35.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : gdb-7.2.90.20110429-36.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : gdb-7.2.90.20110429-36.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : gdb-7.2.90.20110429-35.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : gdb- doc-7.2.90.20110411-34.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : gdb- doc-7.2.90.20110429-36.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : gdb- doc-7.2.90.20110429-35.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : gdb- doc-7.2.90.20110429-36.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : gdb- doc-7.2.90.20110429-36.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : gdb- doc-7.2.90.20110429-35.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : gdb- gdbserver-7.2.90.20110411-34.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : gdb- gdbserver-7.2.90.20110429-36.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : gdb- gdbserver-7.2.90.20110429-35.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : gdb- gdbserver-7.2.90.20110429-36.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : gdb- gdbserver-7.2.90.20110429-36.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : gdb- gdbserver-7.2.90.20110429-35.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : getmail-4.20.0-3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : getmail-4.20.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : getmail-4.20.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : getmail-4.20.0-3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 3:gnome- commander-1.2.8.10-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 3 :gnome-commander-1.2.8.11-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 3:gnome- commander-1.2.8.11-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 3:gnome- commander-1.2.8.10-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : gnome- desktop3-3.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : gnome- desktop3-3.0.1-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : gnome- desktop3-3.0.1-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : gnome- desktop3-3.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : gnome- desktop3-devel-3.0.1-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : gnome- desktop3-devel-3.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : gnome- desktop3-devel-3.0.1-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : gnome- desktop3-devel-3.0.1-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : gnome- desktop3-devel-3.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : gramps-3.2.5-3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : gramps-3.2.6-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : gramps-3.2.6-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : gramps-3.2.5-3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : groonga-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : groonga-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : groonga-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : groonga-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : groonga- devel-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : groonga-devel-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : groonga- devel-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : groonga- devel-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : groonga- doc-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : groonga-doc-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : groonga- doc-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : groonga- doc-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : groonga- libs-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : groonga-libs-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : groonga- libs-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : groonga-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : groonga-devel-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : groonga-doc-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : groonga- libs-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : groonga-munin-plugins-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : groonga-php-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : groonga-plugin-suggest-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : groonga-python-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : groonga-tokenizer-mecab-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : groonga-munin- plugins-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : groonga-munin-plugins-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : groonga-munin- plugins-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : groonga- munin-plugins-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : groonga- php-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : groonga-php-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : groonga- php-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : groonga- php-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : groonga-plugin- suggest-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : groonga-plugin-suggest-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : groonga-plugin- suggest-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : groonga- plugin-suggest-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : groonga- python-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : groonga-python-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : groonga- python-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : groonga- python-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : groonga-tokenizer- mecab-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : groonga-tokenizer-mecab-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : groonga-tokenizer- mecab-1.2.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : groonga- tokenizer-mecab-1.2.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : gv-3.7.1-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : gv-3.7.2-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : gv-3.7.2-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : gv-3.7.1-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : homebank-4.3-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : homebank-4.4-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : homebank-4.4-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : homebank-4.3-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : homebank-doc-4.4-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : homebank- doc-4.3-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : homebank-doc-4.4-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : homebank- doc-4.4-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : homebank- doc-4.3-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : kde-plasma- ktorrent-4.1.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : kde- plasma-ktorrent-4.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : kde-plasma- ktorrent-4.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : kde- plasma-ktorrent-4.1.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : kernel-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : kernel-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: install : kernel-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : kernel-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : kernel- PAE-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : kernel- PAE-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: install : kernel- PAE-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : kernel- PAE-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : kernel-PAE- devel-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : kernel- PAE-devel-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: install : kernel-PAE- devel-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : kernel- PAE-devel-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : kernel- PAEdebug-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : kernel- PAEdebug-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: install : kernel- PAEdebug-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : kernel- PAEdebug-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : kernel-PAEdebug- devel-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : kernel- PAEdebug-devel-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: install : kernel-PAEdebug- devel-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : kernel- PAEdebug-devel-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : kernel- debug-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : kernel- debug-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: install : kernel- debug-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : kernel- debug-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : kernel-debug- devel-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : kernel- debug-devel-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: install : kernel-debug- devel-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : kernel- debug-devel-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: install : kernel-debuginfo- common-i686-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : kernel- devel-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : kernel- devel-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: install : kernel- devel-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : kernel- devel-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : kernel- doc-2.6.38.4-20.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : kernel- doc-2.6.38.5-21.rc1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : kernel- doc-2.6.38.5-21.rc1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : kernel- doc-2.6.38.4-20.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : kernel- headers-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : kernel- headers-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : kernel- headers-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : kernel- headers-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : ktorrent-4.1.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : ktorrent-4.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : ktorrent-4.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : kde- plasma-ktorrent-4.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : ktorrent-4.1.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : ktorrent-libs-4.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : ktorrent- libs-4.1.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : ktorrent-libs-4.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : ktorrent- libs-4.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : ktorrent-4.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : ktorrent- libs-4.1.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : libktorrent-1.1.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : libktorrent-1.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : libktorrent-1.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : libktorrent-1.1.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : libktorrent-devel-1.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : libktorrent- devel-1.1.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : libktorrent-devel-1.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : libktorrent- devel-1.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : libktorrent-devel-1.1.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : lyx-2.0.0-0.21.rc3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : lyx-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : lyx-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : lyx-2.0.0-0.21.rc3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : lyx- common-2.0.0-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : lyx- common-2.0.0-0.21.rc3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : lyx- common-2.0.0-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : lyx- common-2.0.0-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : lyx-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : lyx- common-2.0.0-0.21.rc3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : lyx- fonts-2.0.0-0.21.rc3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : lyx- fonts-2.0.0-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : lyx- fonts-2.0.0-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : lyx-2.0.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : lyx- fonts-2.0.0-0.21.rc3.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:mc-4.7.5.1-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1:mc-4.7.5.2-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:mc-4.7.5.2-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:mc-4.7.5.1-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : mingw32-glibmm24-2.27.93-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : mingw32-glibmm24-2.28.0-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : mingw32-glibmm24-2.28.0-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : mingw32-glibmm24-2.28.0-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : mingw32-glibmm24-2.28.0-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : mingw32-glibmm24-2.28.0-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : nautilus-3.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : nautilus-3.0.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : nautilus-3.0.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : nautilus-3.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : nautilus-devel-3.0.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : nautilus-extensions-3.0.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : nautilus- devel-3.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : nautilus-devel-3.0.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : nautilus- devel-3.0.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : nautilus- devel-3.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : nautilus- extensions-3.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : nautilus-extensions-3.0.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : nautilus- extensions-3.0.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : nautilus-3.0.1.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : nautilus- extensions-3.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : obconf-2.0.3-5.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : obconf-2.0.3-6.20091221gitc8ac23.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : obconf-2.0.3-6.20091221gitc8ac23.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : obconf-2.0.3-5.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : perf-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : perf-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : perf-2.6.38.5-21.rc1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : perf-2.6.38.4-20.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : perl-Directory- Queue-1.0-4.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : perl- Directory-Queue-1.1-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : perl-Directory- Queue-1.1-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : perl- Directory-Queue-1.0-4.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : perl- Directory-Queue-tests-1.1-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : perl-Directory-Queue- tests-1.0-4.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : perl- Directory-Queue-tests-1.1-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : perl-Directory-Queue- tests-1.1-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : perl- Directory-Queue-tests-1.0-4.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : perl-IO-Socket- SSL-1.39-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : perl- IO-Socket-SSL-1.40-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : perl-IO-Socket- SSL-1.40-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : perl-IO- Socket-SSL-1.39-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : perl-Module- Refresh-0.13-9.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : perl- Module-Refresh-0.16-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : perl-Module- Refresh-0.16-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : perl- Module-Refresh-0.13-9.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : perl- Plack-0.9976-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : perl- Plack-0.9977-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : perl- Plack-0.9977-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : perl- Plack-0.9976-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : perl-Sysadm- Install-0.35-4.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : perl- Sysadm-Install-0.36-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : perl-Sysadm- Install-0.36-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : perl- Sysadm-Install-0.35-4.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : polkit-0.101-5.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : polkit-0.101-6.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : polkit-0.101-6.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : polkit-0.101-5.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : polkit- devel-0.101-6.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : polkit-desktop- policy-0.101-5.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : polkit- desktop-policy-0.101-6.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : polkit-desktop- policy-0.101-6.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : polkit- desktop-policy-0.101-5.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : polkit- devel-0.101-5.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : polkit- devel-0.101-6.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : polkit- devel-0.101-6.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : polkit- devel-0.101-5.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : polkit- docs-0.101-6.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : polkit- docs-0.101-5.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : polkit- docs-0.101-6.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : polkit- docs-0.101-6.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : polkit- devel-0.101-6.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : polkit- docs-0.101-5.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : scipy-0.7.2-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : scipy-0.9.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : scipy-0.9.0-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : scipy-0.7.2-3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : selinux- policy-3.9.16-15.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : selinux-policy-3.9.16-21.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : selinux- policy-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : selinux-policy-3.9.16-21.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : selinux- policy-3.9.16-21.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : freeipa-server-2.0.1-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : selinux- policy-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : selinux-policy-doc-3.9.16-21.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : selinux-policy-minimum-3.9.16-21.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : selinux-policy-mls-3.9.16-21.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : selinux-policy-targeted-3.9.16-21.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : selinux-policy- doc-3.9.16-15.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : selinux-policy-doc-3.9.16-21.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : selinux-policy- doc-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : selinux-policy-doc-3.9.16-21.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : selinux-policy- doc-3.9.16-21.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : selinux- policy-doc-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : selinux-policy- minimum-3.9.16-15.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : selinux-policy-minimum-3.9.16-21.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : selinux-policy- mls-3.9.16-15.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : selinux-policy-mls-3.9.16-21.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : selinux-policy- targeted-3.9.16-15.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : selinux-policy-targeted-3.9.16-21.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: install : sjinn-1.01-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : syslog- ng-3.1.1-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : syslog- ng-3.2.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : syslog- ng-3.2.3-0.20110424.3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : syslog- ng-3.2.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : syslog- ng-3.2.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : syslog- ng-3.2.3-0.20110424.3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : syslog- ng-devel-3.2.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : syslog-ng- devel-3.2.3-0.20110424.3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : syslog- ng-devel-3.2.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : syslog-ng- devel-3.2.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : syslog- ng-devel-3.2.3-0.20110424.3.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : terminus- fonts-4.32-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : terminus-fonts-4.34-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : terminus- fonts-4.34-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : terminus- fonts-4.32-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : terminus-fonts- console-4.32-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : terminus-fonts-console-4.34-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : terminus-fonts- console-4.34-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : terminus- fonts-console-4.32-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : vmpsd-1.4.01-7.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : vmpsd-1.4.03-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : vmpsd-1.4.03-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : vmpsd-1.4.01-7.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : wordpress-3.1-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : wordpress-3.1.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : wordpress-3.1.2-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : wordpress-3.1-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:xrootd-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1:xrootd-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:xrootd-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:xrootd-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:xrootd- client-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1 :xrootd-client-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:xrootd- client-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:xrootd- client-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:xrootd-client-admin- java-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1 :xrootd-client-admin-java-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:xrootd-client-admin- java-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:xrootd- client-admin-java-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:xrootd-client-admin- perl-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1 :xrootd-client-admin-perl-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:xrootd-client-admin- perl-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:xrootd- client-admin-perl-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:xrootd- devel-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1 :xrootd-devel-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:xrootd- devel-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:xrootd- devel-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:xrootd- doc-3.0.3-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1 :xrootd-doc-3.0.3-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:xrootd- doc-3.0.3-2.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:xrootd- doc-3.0.3-1.fc15.noarch 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:xrootd- fuse-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1 :xrootd-fuse-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:xrootd- fuse-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:xrootd- fuse-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updated : 1:xrootd- libs-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updatedby : 1 :xrootd-libs-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: update : 1:xrootd- libs-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : 1:xrootd-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : 1 :xrootd-client-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : 1 :xrootd-client-admin-java-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : 1 :xrootd-client-admin-perl-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : 1 :xrootd-devel-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: dependson : 1 :xrootd-fuse-3.0.3-2.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN: updates : 1:xrootd- libs-3.0.3-1.fc15.i686 20:54:36 DEBUG| [stdout] SKIPBROKEN:============================================================ 20:54:36 DEBUG| [stdout] --> Running transaction check 20:54:36 DEBUG| [stdout] ---> Package selinux-policy-minimum.noarch 0:3.9.16-18.fc15 will be updated 20:54:36 DEBUG| [stdout] Checking deps for selinux-policy-minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('selinux-policy', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('config(selinux-policy-minimum)', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy- minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('selinux-policy', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('policycoreutils-python', 'GE', ('0', '2.0.85', '26')) as a requirement of selinux-policy-minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('/bin/sh', None, (None, None, None)) as a requirement of selinux-policy-minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('coreutils', None, (None, None, None)) as a requirement of selinux-policy-minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] selinux-policy-minimum-3.9.16-18.fc15.noarch requires: selinux-policy = 3.9.16-18.fc15 20:54:36 DEBUG| [stdout] --> Processing Dependency: selinux-policy = 3.9.16-18.fc15 for package: selinux-policy-minimum-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] Searching pkgSack for dep: selinux-policy 20:54:36 DEBUG| [stdout] selinux-policy-minimum-3.9.16-18.fc15.noarch requires: selinux-policy = 3.9.16-18.fc15 20:54:36 DEBUG| [stdout] --> Processing Dependency: selinux-policy = 3.9.16-18.fc15 for package: selinux-policy-minimum-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] Searching pkgSack for dep: selinux-policy 20:54:36 DEBUG| [stdout] ---> Package selinux-policy-minimum.noarch 0:3.9.16-18.fc15 will be updated 20:54:36 DEBUG| [stdout] Checking deps for selinux-policy-minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('selinux-policy', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('config(selinux-policy-minimum)', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy- minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('selinux-policy', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('policycoreutils-python', 'GE', ('0', '2.0.85', '26')) as a requirement of selinux-policy-minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('/bin/sh', None, (None, None, None)) as a requirement of selinux-policy-minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('coreutils', None, (None, None, None)) as a requirement of selinux-policy-minimum.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] selinux-policy-minimum-3.9.16-18.fc15.noarch requires: selinux-policy = 3.9.16-18.fc15 20:54:36 DEBUG| [stdout] --> Processing Dependency: selinux-policy = 3.9.16-18.fc15 for package: selinux-policy-minimum-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] Searching pkgSack for dep: selinux-policy 20:54:36 DEBUG| [stdout] selinux-policy-minimum-3.9.16-18.fc15.noarch requires: selinux-policy = 3.9.16-18.fc15 20:54:36 DEBUG| [stdout] --> Processing Dependency: selinux-policy = 3.9.16-18.fc15 for package: selinux-policy-minimum-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] Searching pkgSack for dep: selinux-policy 20:54:36 DEBUG| [stdout] ---> Package selinux-policy-mls.noarch 0:3.9.16-18.fc15 will be updated 20:54:36 DEBUG| [stdout] Checking deps for selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('selinux-policy', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('config(selinux-policy-mls)', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('selinux-policy', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('policycoreutils', 'GE', ('0', '2.0.85', '26')) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('policycoreutils-newrole', 'GE', ('0', '2.0.85', '26')) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('setransd', None, (None, None, None)) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('coreutils', None, (None, None, None)) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('/bin/sh', None, (None, None, None)) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] selinux-policy-mls-3.9.16-18.fc15.noarch requires: selinux-policy = 3.9.16-18.fc15 20:54:36 DEBUG| [stdout] --> Processing Dependency: selinux-policy = 3.9.16-18.fc15 for package: selinux-policy-mls-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] Searching pkgSack for dep: selinux-policy 20:54:36 DEBUG| [stdout] selinux-policy-mls-3.9.16-18.fc15.noarch requires: selinux-policy = 3.9.16-18.fc15 20:54:36 DEBUG| [stdout] --> Processing Dependency: selinux-policy = 3.9.16-18.fc15 for package: selinux-policy-mls-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] Searching pkgSack for dep: selinux-policy 20:54:36 DEBUG| [stdout] ---> Package selinux-policy-mls.noarch 0:3.9.16-18.fc15 will be updated 20:54:36 DEBUG| [stdout] Checking deps for selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('selinux-policy', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('config(selinux-policy-mls)', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('selinux-policy', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('policycoreutils', 'GE', ('0', '2.0.85', '26')) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('policycoreutils-newrole', 'GE', ('0', '2.0.85', '26')) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('setransd', None, (None, None, None)) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('coreutils', None, (None, None, None)) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('/bin/sh', None, (None, None, None)) as a requirement of selinux-policy-mls.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] selinux-policy-mls-3.9.16-18.fc15.noarch requires: selinux-policy = 3.9.16-18.fc15 20:54:36 DEBUG| [stdout] --> Processing Dependency: selinux-policy = 3.9.16-18.fc15 for package: selinux-policy-mls-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] Searching pkgSack for dep: selinux-policy 20:54:36 DEBUG| [stdout] selinux-policy-mls-3.9.16-18.fc15.noarch requires: selinux-policy = 3.9.16-18.fc15 20:54:36 DEBUG| [stdout] --> Processing Dependency: selinux-policy = 3.9.16-18.fc15 for package: selinux-policy-mls-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] Searching pkgSack for dep: selinux-policy 20:54:36 DEBUG| [stdout] ---> Package selinux-policy-targeted.noarch 0:3.9.16-18.fc15 will be updated 20:54:36 DEBUG| [stdout] Checking deps for selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('config(selinux-policy-targeted)', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy- targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('selinux-policy', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('selinux-policy', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('policycoreutils', 'GE', ('0', '2.0.85', '26')) as a requirement of selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('/bin/sh', None, (None, None, None)) as a requirement of selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('coreutils', None, (None, None, None)) as a requirement of selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('/bin/sh', None, (None, None, None)) as a requirement of selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] selinux-policy-targeted-3.9.16-18.fc15.noarch requires: selinux-policy = 3.9.16-18.fc15 20:54:36 DEBUG| [stdout] --> Processing Dependency: selinux-policy = 3.9.16-18.fc15 for package: selinux-policy-targeted-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] Searching pkgSack for dep: selinux-policy 20:54:36 DEBUG| [stdout] selinux-policy-targeted-3.9.16-18.fc15.noarch requires: selinux-policy = 3.9.16-18.fc15 20:54:36 DEBUG| [stdout] --> Processing Dependency: selinux-policy = 3.9.16-18.fc15 for package: selinux-policy-targeted-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] Searching pkgSack for dep: selinux-policy 20:54:36 DEBUG| [stdout] ---> Package selinux-policy-targeted.noarch 0:3.9.16-18.fc15 will be updated 20:54:36 DEBUG| [stdout] Checking deps for selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('config(selinux-policy-targeted)', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy- targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('selinux-policy', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('selinux-policy', 'EQ', ('0', '3.9.16', '18.fc15')) as a requirement of selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('policycoreutils', 'GE', ('0', '2.0.85', '26')) as a requirement of selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('/bin/sh', None, (None, None, None)) as a requirement of selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('coreutils', None, (None, None, None)) as a requirement of selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] looking for ('/bin/sh', None, (None, None, None)) as a requirement of selinux-policy-targeted.noarch 0:3.9.16-18.fc15 - ud 20:54:36 DEBUG| [stdout] selinux-policy-targeted-3.9.16-18.fc15.noarch requires: selinux-policy = 3.9.16-18.fc15 20:54:36 DEBUG| [stdout] --> Processing Dependency: selinux-policy = 3.9.16-18.fc15 for package: selinux-policy-targeted-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] Searching pkgSack for dep: selinux-policy 20:54:36 DEBUG| [stdout] selinux-policy-targeted-3.9.16-18.fc15.noarch requires: selinux-policy = 3.9.16-18.fc15 20:54:36 DEBUG| [stdout] --> Processing Dependency: selinux-policy = 3.9.16-18.fc15 for package: selinux-policy-targeted-3.9.16-18.fc15.noarch 20:54:36 DEBUG| [stdout] Searching pkgSack for dep: selinux-policy 20:54:36 DEBUG| [stdout] ---> Package syslog-ng.i686 0:3.2.3-0.20110424.3.fc15 will be updated 20:54:36 DEBUG| [stdout] Checking deps for syslog-ng.i686 0:3.2.3-0.20110424.3.fc15 - ud 20:54:36 DEBUG| [stdout] ---> Package syslog-ng.i686 0:3.2.3-0.20110424.3.fc15 will be updated 20:54:36 DEBUG| [stdout] Checking deps for syslog-ng.i686 0:3.2.3-0.20110424.3.fc15 - ud 20:54:37 DEBUG| [stdout] --> Processing Conflict: sysklogd-1.5-10.fc15.i686 conflicts syslog-ng 20:54:37 DEBUG| [stdout] Package: syslog-ng.i686 - 0:3.2.3-1.fc15 already in ts 20:54:37 DEBUG| [stdout] Package in same mode, skipping. 20:54:37 DEBUG| [stdout] Package: syslog-ng.i686 - 0:3.1.1-2.fc15 already in ts 20:54:37 DEBUG| [stdout] Package in same mode, skipping. 20:54:37 DEBUG| [stdout] sysklogd conflicts with syslog-ng 20:54:37 DEBUG| [stdout] --> Finished Dependency Resolution 20:54:37 DEBUG| [stdout] Dependency Process ending 20:54:37 DEBUG| [stdout] SKIPBROKEN: sysklogd-1.5-10.fc15.i686 from f15 has depsolving problems 20:54:37 DEBUG| [stdout] SKIPBROKEN: --> sysklogd conflicts with syslog- ng 20:54:37 DEBUG| [stdout] SKIPBROKEN: selinux-policy- targeted-3.9.16-18.fc15.noarch from f15-updates-testing has depsolving problems 20:54:37 DEBUG| [stdout] SKIPBROKEN: --> Package: selinux-policy- targeted-3.9.16-18.fc15.noarch (f15-updates-testing) 20:54:37 DEBUG| [stdout] --> Requires: selinux-policy = 3.9.16-18.fc15 20:54:37 DEBUG| [stdout] --> Removing: selinux- policy-3.9.16-15.fc15.noarch (f15) 20:54:37 DEBUG| [stdout] --> selinux-policy = 3.9.16-15.fc15 20:54:37 DEBUG| [stdout] --> Updated By: selinux- policy-3.9.16-21.fc15.noarch (pending) 20:54:37 DEBUG| [stdout] --> selinux-policy = 3.9.16-21.fc15 20:54:37 DEBUG| [stdout] --> Removing: selinux- policy-3.9.16-18.fc15.noarch (f15-updates-testing) 20:54:37 DEBUG| [stdout] --> selinux-policy = 3.9.16-18.fc15 20:54:37 DEBUG| [stdout] --> Updated By: selinux- policy-3.9.16-21.fc15.noarch (pending) 20:54:37 DEBUG| [stdout] --> selinux-policy = 3.9.16-21.fc15 20:54:37 DEBUG| [stdout] SKIPBROKEN: selinux-policy- mls-3.9.16-18.fc15.noarch from f15-updates-testing has depsolving problems 20:54:37 DEBUG| [stdout] SKIPBROKEN: --> Package: selinux-policy- mls-3.9.16-18.fc15.noarch (f15-updates-testing) 20:54:37 DEBUG| [stdout] --> Requires: selinux-policy = 3.9.16-18.fc15 20:54:37 DEBUG| [stdout] --> Removing: selinux- policy-3.9.16-15.fc15.noarch (f15) 20:54:37 DEBUG| [stdout] --> selinux-policy = 3.9.16-15.fc15 20:54:37 DEBUG| [stdout] --> Updated By: selinux- policy-3.9.16-21.fc15.noarch (pending) 20:54:37 DEBUG| [stdout] --> selinux-policy = 3.9.16-21.fc15 20:54:37 DEBUG| [stdout] --> Removing: selinux- policy-3.9.16-18.fc15.noarch (f15-updates-testing) 20:54:37 DEBUG| [stdout] --> selinux-policy = 3.9.16-18.fc15 20:54:37 DEBUG| [stdout] --> Updated By: selinux- policy-3.9.16-21.fc15.noarch (pending) 20:54:37 DEBUG| [stdout] --> selinux-policy = 3.9.16-21.fc15 20:54:37 DEBUG| [stdout] SKIPBROKEN: selinux-policy- minimum-3.9.16-18.fc15.noarch from f15-updates-testing has depsolving problems 20:54:37 DEBUG| [stdout] SKIPBROKEN: --> Package: selinux-policy- minimum-3.9.16-18.fc15.noarch (f15-updates-testing) 20:54:37 DEBUG| [stdout] --> Requires: selinux-policy = 3.9.16-18.fc15 20:54:37 DEBUG| [stdout] --> Removing: selinux- policy-3.9.16-15.fc15.noarch (f15) 20:54:37 DEBUG| [stdout] --> selinux-policy = 3.9.16-15.fc15 20:54:37 DEBUG| [stdout] --> Updated By: selinux- policy-3.9.16-21.fc15.noarch (pending) 20:54:37 DEBUG| [stdout] --> selinux-policy = 3.9.16-21.fc15 20:54:37 DEBUG| [stdout] --> Removing: selinux- policy-3.9.16-18.fc15.noarch (f15-updates-testing) 20:54:37 DEBUG| [stdout] --> selinux-policy = 3.9.16-18.fc15 20:54:37 DEBUG| [stdout] --> Updated By: selinux- policy-3.9.16-21.fc15.noarch (pending) 20:54:37 DEBUG| [stdout] --> selinux-policy = 3.9.16-21.fc15 20:54:37 DEBUG| [stdout] SKIPBROKEN: ########### Round 5069 ################ ... }}} It created 1 GB log file and then it died. We need to find the cause of the loop. Maybe consult with yum developers? -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/322> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 7

[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 Documentation
by Tim Flink 14 Jul '11

14 Jul '11

This came up in the comments around #314 but I'm of the opinion that autoqa-devel is a better place for this conversation. How do we want to be doing documentation? At the moment, we're kind of spread across the fp.o wiki and the fedorahosted trac wiki and I agree with Kamil that we should probably start giving some thought to how our documentation is organized. Personally, I'm of the opinion that the fp.o wiki is not the best place for most of our documentation. Some of it, yes (project overview, some test documentation maybe) but not most of it. I'm looking at bodhi [1] as an example where most of their docs are not in the fp.o wiki. Taking this one step farther, my ideal preference would be to keep the docs with the code so that the lions share of our docs are in git and generated at build time (updated on push to master once we get CI implemented). I think that py.test [2] is a great example of doing this and I find their documentation well written and easy to follow (created with sphinx [3]). Granted, the tool is only part of that but I think that having things in one place and not handicapping ourselves with wiki syntax and "tools" (finding and changing occurrences are easier) would be a decent start towards better docs. Thoughts? Anything I missed? Tim PS I'm not proposing we change anything immediately, just thoughts for going forward [1] https://fedorahosted.org/bodhi/ [2] http://doc.pytest.org/en/latest/ [3] http://sphinx.pocoo.org/

5 15

[AutoQA] #340: Integrate depcheck tests into main testsuite
by fedora-badges 12 Jul '11

12 Jul '11

#340: Integrate depcheck tests into main testsuite --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: task | Status: new Priority: minor | Milestone: Finger Food Component: core | Keywords: --------------------+------------------------------------------------------- While an initial test suite was created for #258, it isn't currently running any of the tests written for depcheck. As currently written, these tests are functional tests and should be integrated as such. Another concern is that they are restricted to 64bit OS only and the integration would need to reflect this. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/340> 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] #346: Comments are being mangled before posting to bodhi
by fedora-badges 30 Jun '11

30 Jun '11

#346: Comments are being mangled before posting to bodhi ---------------------+------------------------------------------------------ Reporter: tflink | Owner: tflink Type: defect | Status: new Priority: blocker | Milestone: Hot issues Component: core | Keywords: ---------------------+------------------------------------------------------ There is a loop in bodhi_utils.py that is overwriting the comment set earlier in the bodhi_post_test_result method. source:lib/autoqa/bodhi_utils.py@3cf90d63c5a77dd1cdbc26f33dbc5ea70b7f1238#L261 The variable names need to be different. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/346> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

2 3

[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 0.5.0 released
by Kamil Paral 29 Jun '11

29 Jun '11

AutoQA 0.5.0 has just been released and deployed. Package maintainers will see some notable changes. Please read the whole description here: http://kparal.wordpress.com/2011/06/29/autoqa-0-5-0-released/ Comments welcome. Kamil

1 0

Merging master into stable - take 2
by Tim Flink 28 Jun '11

28 Jun '11

After the first botched attempt, I think that I got the merge done correctly without any differences to master or the new stable this time. If for some reason, you're interested - the code is up in the same github repo as before: https://github.com/tflink/autoqa-devel Instead of handling all the merge conflicts by hand, I found a vim plugin for git (fugitive) that made the process a lot easier and less vulnerable to human error: http://www.vim.org/scripts/script.php?script_id=2975 There is even a vimcast covering git merge resolving with fugitive: http://vimcasts.org/episodes/fugitive-vim-resolving-merge-conflicts-with-vi… Anyhow, it was more of an academic exercise at this point. The history is preserved after merge if you follow a specific file (git log --all --follow autoqa.spec for example). I captured that data for the fedorahosted repo [1] and my github repo [2]. Unfortunately, the graphs look horrible in either vim or firefox due to the way they're formatted but they look fine if you cat the files. I took screenshots of the git log graph for both the fedorahosted repo [1] and my github repo [2] (note that for the github graph, origin is github and upstream is fedorahosted). They do look different but I think that I created them the same way (QGit, same top and bottom). Tim [1] http://tflink.fedorapeople.org/autoqa/git_merge/fedorahosted_followspec [2] http://tflink.fedorapeople.org/autoqa/git_merge/github_followspec [3] http://tflink.fedorapeople.org/autoqa/git_merge/fedorahosted_graph.png [4] http://tflink.fedorapeople.org/autoqa/git_merge/github_graph.png

1 0

Odd Depcheck Output
by Tim Flink 28 Jun '11

28 Jun '11

I was looking through some of the results on the testing instance and I found an ... interesting depcheck log. http://10.11.230.168/results/13591-autotest/hp-xw9300.test.redhat.com/depch… I'm still not quite sure what happened here but the only real error that I'm seeing offhand is in qterm even though a lot of builds were failed along with it. The timing of this isn't great but I'm starting to question the wisdom of the "fix" for #284 [1]. I had not anticipated extranious failures like this and I'm wondering if this is just going to cause more confusion than test results that aren't reported to bodhi. Thoughts? Tim [1] https://fedorahosted.org/autoqa/ticket/284

4 7

[AutoQA] #326: Create user-facing documentation for depcheck
by fedora-badges 28 Jun '11

28 Jun '11

#326: Create user-facing documentation for depcheck ---------------------------+------------------------------------------------ Reporter: tflink | Owner: Type: task | Status: new Priority: major | Milestone: 0.5.0 Component: documentation | Keywords: ---------------------------+------------------------------------------------ Create a wiki page for depcheck that contains the following: * Thorough description of the test * How to read and interpret results * How to interpret the log output and use it to find failures * Description of common failures * Links to useful resources * correct procedure descriptions (e.g. packaging guidelines, etc). * Other relevant information {{{ #!comment For some reason, I can't get a ticket query with single result to render, changed to static }}} Related to #317 - Create user-facing documentation for upgradepath -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/326> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 6

0.5.0 Release TODO
by Tim Flink 28 Jun '11

28 Jun '11

These are the things that I can think of that still need to be done before we release 0.5.0: NEWS/CHANGELOG (jdulaney) Git tagging and updating (tflink, kparal) Spec file update (jlaska) Announcements (?) Final Doc Check (everyone) Please correct me if I missed or misunderstood anything. Tim

5 15

[AutoQA] #342: Prevent duplicate tests from being scheduled
by fedora-badges 27 Jun '11

27 Jun '11

#342: Prevent duplicate tests from being scheduled ----------------------+----------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: 0.5.0 Component: watchers | Keywords: ----------------------+----------------------------------------------------- We currently have an issue where tests are being scheduled more than once. This creates extra noise for maintainers and is a waste of resources - it should be fixed. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/342> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 9

[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] #344: Update repoinfo.conf - Remove release
by fedora-badges 27 Jun '11

27 Jun '11

#344: Update repoinfo.conf - Remove release ------------------------+--------------------------------------------------- Reporter: ausil | Owner: Type: task | Status: new Priority: critical | Milestone: Hot issues Component: production | Keywords: ------------------------+--------------------------------------------------- f13 is now eol -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/344> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

AutoQA to test update with yum and PackageKit
by Athmane Madjoudj 27 Jun '11

27 Jun '11

Hello, There's a talk about AutoQA being able to test update with yum and PackageKit (pkcon), afaik it is not true, can someone from AutoQA team comment about this. https://bugzilla.redhat.com/show_bug.cgi?id=716752#c4 -- Athmane Madjoudj

2 1

Autotest 0.13.0 released!
by Lucas Meneghel Rodrigues 23 Jun '11

23 Jun '11

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

2 1

autoqa-0.5.0-0.3.pre available
by James Laska 23 Jun '11

23 Jun '11

Greetings gang, I updated the autoqa.spec [1] and pushed out another pre-release autoqa package into the -testing repositories. Please let me know if you have any issues. You can find instructions for installing autoqa available at https://fedoraproject.org/wiki/Install_and_configure_AutoQA If there are no other immediate autoqa packaging needs, I'll be looking into the autotest-0.13.0 that should be landing shortly (congrats Lucas! ). Thanks, James [1] http://git.fedorahosted.org/git/?p=autoqa.git;a=commit;h=ab8ac464c09c319a24…

2 1

Some Depcheck runs taking long time
by Josef Skladanka 23 Jun '11

23 Jun '11

Hello, yesterday, Kamil spotted some depcheck run, which took quite a lot of time. It was caused by the depcheck_pretty() routines, which took some time to parse those 70k lines of text. Sadly, this is not-a-bug, but a feature. The positive thing is, that logs this long are not common and mostly sign a error in dependencies. J.

4 5

HTML results and highlight links
by James Laska 22 Jun '11

22 Jun '11

Greetings, I finally found a depcheck failure report that I could use to checkout some of the coolness coming in autoqa-0.5.0. First off, these results look *so* much better than text/plain reports, and it's really easy to find the failure information. Nice work on 0.5.0! I was talking to jskladan about the links (>>) in the highlight section. The character is small, and it didn't occur to me that it was a clickable link at first. We discussed changing the link to make it more obvious that it is intended to be clicked. I mocked up a few basic samples and Joza suggested I send them to the list for feedback. http://jlaska.fedorapeople.org/libreport-2.0.3-1.fc.html Any preferences? Thanks, James

3 5

0.5.0 testing status
by Kamil Paral 21 Jun '11

21 Jun '11

This a status report from our current 0.5.0 testing effort: 1. The tests seem to work properly (except for one Koji timeout and one NoMoreMirrorsRepoError yum error). 2. The number of items in the mailing list increased substantially, because we send one email for the full.log and one email for every (pretty) log created. Rpmlint equals two emails, upgradepath may equal to 10-20 emails. The mailing list is not much human readable now. We can make adjustments if you want. Personally I consider the list as another kind of storage place and I don't really mind. 3. We have found an issue with koji/bodhi watcher that caused every test to be scheduled multiple times. When asking Koji/Bodhi takes really long time, another watcher can be run in parallel. But the subsequent watcher still operates with the old data, thus resulting in scheduling the same tests as the first one. We have seen this issue happening also on our current production instance: https://fedorahosted.org/pipermail/autoqa-results/2011-June/thread.html - search for q4wine Jskladan already sent an example patch to tflink to examination, I believe a proper patch will appear on the ML/in git soon if we confirm it fixes the issue. 4. We have identified an issue where our email reduction does not work, it does not send email when it is supposed to (when both depchecks pass for an -updates-testing update). The root cause if not known yet. I suppose it will take a few days until the problems are identified and fixed.

3 5

[AutoQA] #343: Bodhi Comment Email Logic is not Detecting Tests
by fedora-badges 21 Jun '11

21 Jun '11

#343: Bodhi Comment Email Logic is not Detecting Tests --------------------+------------------------------------------------------- Reporter: tflink | Owner: tflink Type: task | Status: new Priority: major | Milestone: 0.5.0 Component: core | Keywords: --------------------+------------------------------------------------------- The logic used to determine whether or not to send an email with bodhi comments is not working. Example of what should have been INCOMPLETE to PASS: {{{ 06/13 11:07:13 INFO | test:0383| Submitting results (log, email, bodhi) for: depcheck: PASSED; 1 PASSED for phpMyAdmin-3.4.2-1.fc14 06/13 11:07:13 INFO | test:0308| Log created: /usr/share/autotest/results/default/depcheck/results/phpMyAdmin-3.4.2-1.f.html 06/13 11:07:13 INFO | test:0254| Email not sent: "depcheck: PASSED; 1 PASSED for phpMyAdmin-3.4.2-1.fc14" 06/13 11:07:20 INFO |bodhi_upda:0101| Current State of update phpMyAdmin-3.4.2-1.fc14 : 06/13 11:07:20 INFO |bodhi_upda:0101| {'result': 'PASSED', 'arch': 'x86_64', 'testname': 'depcheck', 'time': datetime.datetime(2011, 6, 13, 14, 52, 1)} 06/13 11:07:20 INFO |bodhi_upda:0101| 06/13 11:07:20 INFO |bodhi_upda:0101| Current State of update phpMyAdmin-3.4.2-1.fc14 : 06/13 11:07:20 INFO |bodhi_upda:0101| {'result': 'PASSED', 'arch': 'x86_64', 'testname': 'depcheck', 'time': datetime.datetime(2011, 6, 13, 14, 52, 1)} 06/13 11:07:20 INFO |bodhi_upda:0101| {'result': 'PASSED', 'arch': 'i386', 'testname': 'depcheck', 'time': datetime.datetime(2011, 6, 13, 15, 7, 20, 855416)} 06/13 11:07:20 INFO |bodhi_upda:0101| 06/13 11:07:20 INFO |bodhi_util:0390| update state : INCOMPLETE to INCOMPLETE 06/13 11:07:20 INFO |bodhi_util:0275| Bodhi email will NOT be sent }}} This logic needs to properly detect the tests that have been run. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/343> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #341: create watcher to download iso images one time during test
by fedora-badges 20 Jun '11

20 Jun '11

#341: create watcher to download iso images one time during test ----------------------+----------------------------------------------------- Reporter: hongqing | Owner: Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: core | Keywords: ----------------------+----------------------------------------------------- test wrapper will download the iso images for each run if we use the watcher to monitor the website for the images and trigger the test. James gave a multi-stage download solution. [[BR]] * running a squid proxy on your autotest-server to cache the ISO downloads so that clients really only download the image 1 time.[[BR]] * implementing some two-step ISO download process. Step one is a autotest server job (initiated by a watcher) that caches the ISO's in an NFS ro mount point (e.g. /var/cache/autoqa/install-isos). Step two is another ISO watcher that monitors /var/cache/autoqa/install-isos and initiates tests when new content is available[[BR]] I have written a samll script to watch the iso images at /var/cache/autoqa /install-isos[[BR]] 7a6087849aa7b526caf8e2886fb2b0166e328480[[BR]] I checked the existence and updated time to determine if it is a new one. I am not familiar with this part, do you have any idea about this? -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/341> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

autoqa-0.5.0-0.2.pre available for testing
by James Laska 16 Jun '11

16 Jun '11

Greetings, I built and pushed autoqa-0.5.0-0.2.pre [1] for testing today. It is available from the autoqa testing repos. The rpm %changelog will need some work before the release, but this should do the job for testing purposes. You can download the package from the usual place on repos.fedorapeople.org [2]. Thanks, James [1] http://git.fedorahosted.org/git/?p=autoqa.git;a=commit;h=c673949cf42d3d1b05… [2] http://repos.fedorapeople.org/repos/fedora-qa/autoqa/fedora-autoqa-testing.…

2 2

Re: Fedora 14 Update: lvm2-2.02.84-2.fc14
by Kamil Paral 16 Jun '11

16 Jun '11

> Mike McLean wrote: > > lvm2-2.02.84-2.fc14 has a higher NVR than the current F15 build > > (lvm2-2.02.84-1.fc15). Shouldn't some sanity check have caught this, > > or am I missing something? > > AutoQA complains about these kind of things, but most maintainers > don't read > AutoQA complaints, probably because: > * AutoQA always comments, even if everything is OK, and This will be solved in the next AutoQA release, in a week or so. > * there are also false positives, e.g. when a corresponding F15 update > is > already queued at the same time. It is not really a false positive, because AutoQA can't be sure the builds will be pushed in the right order (or that F15 update will not be unpushed in the meantime). But we will definitely improve the output, unfortunately not in the next release. > > Both these issues cause real upgrade path bugs to go unnoticed. > > Kevin Kofler > > -- > devel mailing list > devel(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel

1 0

Re: [AutoQA] #318: Provide access to test documentation
by fedora-badges 15 Jun '11

15 Jun '11

#318: Provide access to test documentation -------------------------+-------------------------------------------------- Reporter: kparal | Owner: kparal Type: enhancement | Status: closed Priority: major | Milestone: 0.5.0 Component: core | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by kparal): * status: assigned => closed * resolution: => fixed * component: documentation => core Comment: I have changed the wiki docs here: https://fedoraproject.org/w/index.php?title=Writing_AutoQA_Tests&action=his… -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/318#comment:4> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

[AutoQA] #315: Create per-item logs for multi-item tests
by fedora-badges 15 Jun '11

15 Jun '11

#315: Create per-item logs for multi-item tests -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: major | Milestone: 0.5.0 Component: core | Keywords: -------------------------+-------------------------------------------------- Currently multi-item tests (like upgradepath that is testing multiple updates at once) create one big log. That confuses some maintainers. Create a small separate log for every item tested and then link only this log in Bodhi comments. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/315> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[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

Re: [AutoQA] #319: Create HTML log output if possible
by fedora-badges 15 Jun '11

15 Jun '11

#319: Create HTML log output if possible --------------------+------------------------------------------------------- Reporter: kparal | Owner: vhumpa Type: task | Status: closed Priority: major | Milestone: 0.5.0 Component: core | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by kparal): * status: new => closed * resolution: => fixed * component: documentation => core Comment: I have changed the wiki docs here: https://fedoraproject.org/w/index.php?title=Writing_AutoQA_Tests&action=his… -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/319#comment:9> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

AutoQA pkg tests (Half baked)
by Athmane Madjoudj 14 Jun '11

14 Jun '11

Hello, This is my first attempt to integrate my small test suite (currently server-oriented) into AutoQA framework, I've not yet tested running testes through autoqa, I need to install some deps, next week I'll try to check [1]. git repo: git://fedorapeople.org/~athmane/autoqa.git tested are in: tests/pkg_tests/tests [1] http://repos.fedorapeople.org/repos/fedora-qa/autoqa/ -- Athmane Madjoudj

2 2

[AutoQA] #339: update mediakit_sanity to skip boot.iso existence test or warn boot.iso's absence
by fedora-badges 14 Jun '11

14 Jun '11

#339: update mediakit_sanity to skip boot.iso existence test or warn boot.iso's absence ----------------------+----------------------------------------------------- Reporter: hongqing | Owner: Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: core | Keywords: ----------------------+----------------------------------------------------- now the existences of all images, listed in .treeinfo [images-i386] section, are tested. In DVD.iso, boot.iso is listed in .treeinfo, but actually it does not exist. so the mediakit_sanity test always fails. I think the solution is to skip the boot.iso existence test, since it is not required in DVD.iso or we can just print warning information rather than fail it. or any other ideas? -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/339> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

Re: [AutoQA] #316: depcheck: extract possible cause of failure
by fedora-badges 10 Jun '11

10 Jun '11

#316: depcheck: extract possible cause of failure -------------------------+-------------------------------------------------- Reporter: kparal | Owner: jskladan Type: enhancement | Status: closed Priority: major | Milestone: 0.5.0 Component: tests | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by kparal): * status: assigned => closed * resolution: => fixed Comment: Pushed into master as 8a2b9ce2410009da8a4715ea0e33342ef46d4b2f . This doesn't need any documentation changes I believe, because it will be covered in ticket #326. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/316#comment:3> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

Re: [AutoQA] #318: Provide access to test documentation
by fedora-badges 10 Jun '11

10 Jun '11

#318: Provide access to test documentation ---------------------------+------------------------------------------------ Reporter: kparal | Owner: kparal Type: enhancement | Status: assigned Priority: major | Milestone: 0.5.0 Component: documentation | Resolution: Keywords: | ---------------------------+------------------------------------------------ Changes (by kparal): * component: core => documentation Comment: Pushed into master as 8a2b9ce2410009da8a4715ea0e33342ef46d4b2f . We could probably mention this in our wiki documentation ("if you create your own test, you can provide some documentation for it at <url>..."). -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/318#comment:3> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

Re: [AutoQA] #319: Create HTML log output if possible
by fedora-badges 10 Jun '11

10 Jun '11

#319: Create HTML log output if possible ---------------------------+------------------------------------------------ Reporter: kparal | Owner: vhumpa Type: task | Status: new Priority: major | Milestone: 0.5.0 Component: documentation | Resolution: Keywords: | ---------------------------+------------------------------------------------ Changes (by kparal): * component: core => documentation Comment: Pushed into master as 8a2b9ce2410009da8a4715ea0e33342ef46d4b2f . This will definitely need some documentation adjustments. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/319#comment:8> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

[PATCH] pretty logs
by Kamil Paral 10 Jun '11

10 Jun '11

This patch involves tickets: https://fedorahosted.org/autoqa/ticket/315 - Create per-item logs for multi-item tests https://fedorahosted.org/autoqa/ticket/316 - depcheck: extract possible cause of failure https://fedorahosted.org/autoqa/ticket/318 - Provide access to test documentation https://fedorahosted.org/autoqa/ticket/298 - test.py - split postprocess_iteration reporting into standalone methods https://fedorahosted.org/autoqa/ticket/319 - Create HTML log output if possible and it is the result of my, jskladan's and vhumpa's work. I'll the describe the patch in detail here, but I decided not to attach it nor to post it into reviewboard, because it is simply too large. Also I expect that it will receive a little more polish in the following days, so it's not absolutely finalized yet. But if you see anything you would like to change, please, send your comments. You can display the patch by command: $ git fetch $ git diff origin/master..origin/pretty -M Most important changes: 1. TestDetail class All the test's outcomes are now stored in a single class TestDetail. It works as a simple container for test result, summary, output, highlights and a few additional information. It is easier now to call methods that operate on these information, you just pass them your TestDetail instance. By default every test has a default "main" TestDetail instance created in self.detail. You can access self.detail to change the values of result, summary, etc. For a simple single-item tests (like rpmlint), this main TestDetail instance is all they need. For complex multi-item tests (like upgradepath) you need to create a TestDetail instance for every "report" you want to create. In the case of upgradepath and depcheck this means creating separate TestDetail for every Bodhi update tested. 2. TestDetail.update_result() method TestDetail class remembers list of result keywords sorted by importance. If you use TestDetail.update_result(result) method, it will set the test result only if your provided test result is more important (i.e. "worse") then the current test result. This way you can easily handle all error states inside your script and only as the last line include: self.detail.update_result('PASSED') 3. self.log() method We used to do a pretty complicated tasks when printing and saving some output. E.g. you would print in out on the stderr, and then you would append it to self.outputs and maybe even self.highlights. Now you just use: self.log(message, stderr=True, highlight=True) For multi-item tests (like upgradepath) you can also use self.log() to print to several TestDetail instances at once. 4. automatic log creation, different terminology We now have several types of logs (debug, output.log and pretty log). We want to have them transparent and simple for test authors. Debug log is just for us, the developers, so we don't mention it. The former output.log was renamed to full.log and we mention it as little as possible, preferably no at all. And the pretty log is referenced simply as "log" or "test log" and that's the only one we hope test authors will work with. Full log (full.log) is created automatically at the end of every test run. It contains everything that has been logged via self.log() method (provided that @param printout==True). It does not contain output of "print foo" messages (that's just in the debug log). Test log (aka pretty log) is also created automatically at the end of every test run and it's populated from main TestDetail instance (self.detail). Except for the case when the test author has created some test log already manually, then we don't create another one automatically. Test log is created in HTML and this file is used for reporting results everywhere (it is either sent or linked). 5. self.post_results() method There is now a single method for reporting results. It takes care of everything - creating log file, sending email, sending opt-in email and sending Bodhi comment. The first two are mandatory and the last two are optional - you have to provide correct parameters. By default the results are posted automatically at the end of the test run. It means for simple tests where you don't need anything fancy (like Bodhi comments or opt-in emails), you don't have to care about reporting results, everything is handled for you. For more advanced uses you have to call the self.post_results() method. For multi-items tests like upgradepath or depcheck you'll need to call self.post_results(test_detail) for every "item" (Bodhi update in our case) you want to report results for. 6. Test logs are in HTML Test logs are now in HTML. It will allow us to do pretty formatting, nice highlighting, etc. When sending as an email, only a plaintext overview header and a link to proper HTML log is included in the email body. Example: http://kparal.fedorapeople.org/autoqa/upgradepath2.html 7. All tests modified All tests were re-written to the new architecture. Most of them don't take any advantage of the new log features yet. rpmlint example: http://kparal.fedorapeople.org/autoqa/rpmlint.html Upgradepath and depcheck received more love and they should creater nice per-update logs with just the relevant info included. Depcheck now tries to filter out irrelevant messages and keep only the interesting ones in the log. upgradepath example: http://kparal.fedorapeople.org/autoqa/upgradepath.html depcheck example: http://kparal.fedorapeople.org/autoqa/depcheck.html We were working on it hard even today. Some code may be still rough. All comments welcome. Thanks, Kamil

2 4

Unit Testing Dependencies for AutoQA
by Tim Flink 10 Jun '11

10 Jun '11

Kamil asked a good question in his review of the code for comment spam reduction that made me realize that I haven't done enough explaining of how the unit test code is currently working. The question was whether python-virtualenv and python-pip (required for running 'make test') should be listed as build dependencies in autoqa.spec. My feeling on this is 'probably not' because of the way that those dependencies are being used. I'm open to other ideas, though. The current way that I have implemented 'make test' does the following: - create virtualenv if it doesn't already exist * install required packages (py.test etc.) if the env is being created - activate virtualenv - run tests - deactivate virtualenv The main reason that I wrote it this way is that an appropriate version of py.test still hasn't been reviewed for inclusion in Fedora and the version that does exist is not new enough to run these tests. I dropped the ball on that one and once we get 0.5.0 released, I will resume work on getting the needed packages reviewed so that they get into rawhide before F16 branch. I'm not sure that we want to be using virtualenv or pip during rpm packaging. I think that I would rather see direct execution of the tests during rpm build and I'm not even sure that the use of virtualenv for 'make test' is acceptable for Fedora packaging standards. Then again, AutoQA isn't a Fedora package yet so maybe we don't want to worry about this now. Thoughts? Tim

2 6

[PATCH] AutoQA Comment Spam Reduction
by Tim Flink 10 Jun '11

10 Jun '11

This patch involves fixes for tickets in preparation for 0.5.0 release: * https://fedorahosted.org/autoqa/ticket/314 - Decrease the volume of 'PASSED' email sent to maintainers from bodhi * https://fedorahosted.org/autoqa/ticket/258 - implement 'make test' This is a smaller change than the pretty log stuff, so I created a review request in reviewboard based off of a diff from master: - https://fedorahosted.org/reviewboard/r/149/ Otherwise, you can check the diff from master using the commands: $ git fetch $ git diff origin/master..origin/tflink -M Important changes: 1. Addition of bodhi_update_state: 2. bodhi_utils._is_bodhi_comment_email_needed() 3. Adding a parameter to bodhi_post_testresult() 4. [bodhi_email] section added to autoqa.conf 5. Tests for the code associated with #314 ------------------------------------------------------------ | Addition of bodhi_update_state: ------------------------------------------------------------ This object encapsulates information on the state of tests for a given bodhi update. The idea was to encapsulate the logic and make it relatively easy to understand. ------------------------------------------------------------ | bodhi_utils._is_bodhi_comment_email_needed() ------------------------------------------------------------ This was added to bodhi_utils to encapsulate the logic behind whether or not to send an email. _parse_result_from_comment() and _get_bodhi_email_config() were added to support this method ------------------------------------------------------------ | Adding a parameter to bodhi_post_testresult() ------------------------------------------------------------ Since the state of an update's tests depends on the koji tag currently being tested (upgradepath doesn't run on *-updates-testing), the current koji tag became an important part of determining whether or not to send an email. ------------------------------------------------------------ | [bodhi_email] section added to autoqa.conf ------------------------------------------------------------ To support the requirement of changing email behavior without code modifications, more configuration settings were needed. Adding a new section to autoqa.conf was deemed to be the easiest and most self-contained method of getting this done. ------------------------------------------------------------ | Tests for the code associated with #314 ------------------------------------------------------------ This kind of code is a poster child for unit tests, in my mind. Relatively simple code that has subtle changes in logic based on many changing inputs. The tests are written for py.test > 2.0.1 and are in lib/autoqa/tests/

2 7

action plan for 0.5.0
by Kamil Paral 09 Jun '11

09 Jun '11

Here's the current situation. The code is ready. We need to review it properly, that will cause slight changes (already happening for Tim's patch). Once the reviews are ready, we need to merge it (that shouldn't be a problem) and test it properly. Josef is ill. Vita is preparing for state exam. That leaves all the work up to me and Tim, and maybe James if he has some spare time. James, I think you have some machine with setup similar to our production server, where you can have the code running for a few days, right? That would help with the testing stage. Tim, before we reach the testing stage, I would like to discuss with you what the current process should be like. I've seen your patch and it's much shorter and isolated (not impacting many files) than the pretty patch, so I would like to merge it first. Provided that you are able to make the required changes (according to the review) in the following few days. In the meantime I can continue testing pretty patch, polishing HTML output or start creating documentation. Once your patch is merged, we will both work on reviewing pretty patch [1] and merging it. Then the final testing begins. Does it sound like a plan? Other ideas? [1] I'll probably try to load the pretty patch into reviewboard as well. Even though it's quite large and it will load really long, it's probably easier to read and to discuss particular lines than using git diff.

3 4

Re: Re: A puzzle about the ways of adding repos when installing
by Tao Wu 08 Jun '11

08 Jun '11

On 11-06-04 12:00, autoqa-devel-request(a)lists.fedorahosted.org wrote: > Send autoqa-devel mailing list submissions to > autoqa-devel(a)lists.fedorahosted.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://fedorahosted.org/mailman/listinfo/autoqa-devel > or, via email, send a message with subject or body 'help' to > autoqa-devel-request(a)lists.fedorahosted.org > > You can reach the person managing the list at > autoqa-devel-owner(a)lists.fedorahosted.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of autoqa-devel digest..." > > > Today's Topics: > > 1. Re: A puzzle about the ways of adding repos when installing > (James Laska) > 2. Re: A puzzle about the ways of adding repos when installing > (James Laska) > 3. Re: [AutoQA] #284: depcheck does not produce output for some > pending updates (AutoQA) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 03 Jun 2011 14:23:52 -0400 > From: James Laska <jlaska(a)redhat.com> > Subject: Re: A puzzle about the ways of adding repos when installing > To: autoqa-devel(a)lists.fedorahosted.org > Message-ID: <1307125435.3959.13.camel(a)flatline.mine.nu> > Content-Type: text/plain; charset="utf-8" > > On Fri, 2011-06-03 at 20:12 +0800, twu wrote: > > Hi folks, > > > > I'm trying to build a hard drive auto installation script but have a > > puzzle on the several methods of locating repo. > > > > As we know, there are at least 3 ways to locate the iso image: > > > > 1. add the boot argument 'askmethod', then choose the location when > > anaconda prompts, like: > > https://fedoraproject.org/wiki/QA/TestCases/InstallSourceHardDrive > > 2. add the boot argument 'repo=hd:<device>:/<path>', like: > > http://fedoraproject.org/wiki/Anaconda/Options#repo > > 3. write the repo location into kickstart file, like: > > https://fedoraproject.org/wiki/Anaconda/Kickstart#install > > 4. add the repo graphically (this method does not support using iso > > file), like: > > https://fedoraproject.org/wiki/QA:Testcase_Ftp_Repository > > > > Can someone tell me that are these methods the same to anaconda, and if > > they are different, which one can be treat as the third one(kickstart > > method)? > > Certainly refer to Chris' feedback for the internal differences on how > these options are handled. From a test perspective, the unfortunate > answer is that it would be great to test all of the combinations, since > bugs surface unique to each of the methods listed. Of course, testing > all of the options is going to get pretty rough for a first version of a > test script. I'd recommend choosing the evaluating which will give the > best results for the time invested. > > Option #1 is the documented procedure (install-guide) for performing a > HD-ISO installation. However, I don't know of an efficient and > straight-forward way to test this since it involves 1) custom boot args > ('askmethod') and 2) user input during loader. > > I think we have some examples of doing #1 (for pxe-based booting and for > ISO-based booting), so that might not be tremendously difficult, and > option #2 could use the same method, or just blindly emit the proper key > sequences to stdin of loader and assume it works right. > > If option#1 gives any trouble devising a solution that works for all > boot scenarios (ISO and pxeboot images), I'd likely fallback to > option#2. Option#2 would include a script that boots only using pxeboot > images (since that's easier to pass kernel boot parameters), and skips > data entry during loader. > > Option#3 is another valid test scenario we'll need, in addition to other > installation repository types (nfs, url, cdrom). > > The sweet spot will be a test script that is 1) capable of preparing a > guest with a partition containing a DVD ISO image, then able to 2) boot > the installer with custom boot args and a custom kickstart. Those boot > arguments could include "repo=hd:vda1/ ks=hd:vda1:/ks.cfg" (option#2), > or just "ks=hd:vda1:/ks.cfg" (option#3). Ideally, the same script, when > called with different options would be able to perform those two > functions. > > > 4. add the repo graphically (this method does not support using iso > > file), like: > > https://fedoraproject.org/wiki/QA:Testcase_Ftp_Repository > > As Chris mentioned, while similar, adding a package repository URL at > the reposetup phase only adds a package repo. Meaning, it isn't > preparing installation media or the installation source repository. I'd > consider option#4 a distinct future exercise that isn't unique to the HD > ISO install scenario. > > Thoughts/comments/concerns? > > Thanks, > James Thanks to Chris and James for the answer and analyze. Now in my understanding, the #4 is different from the others, and the #1,2,3 has its own scenario, so it might be better to realize the auto-test of all of them in the end. But for now, case #2 and #3 will be processed first. I don't know if I understand correctly? -- Best Regards, Tao Wu

1 0

[AutoQA] #337: install.py output buffered after being integrated into AutoQA
by fedora-badges 08 Jun '11

08 Jun '11

#337: install.py output buffered after being integrated into AutoQA ----------------------+----------------------------------------------------- Reporter: hongqing | Owner: Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: core | Keywords: ----------------------+----------------------------------------------------- After integrate url_install into AutoQA, all the install.py outputs to the terminal are buffered until the test is finished or error occurred. the test is ran as below: autoqa post-tree-compose http://download.englab.nay.redhat.com/pub/fedora/linux/releases/15/Fedora/x… --test=url_install --local -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/337> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

3 7

0.5.0 Status
by Tim Flink 06 Jun '11

06 Jun '11

Since we're looking to release this week, I figure it's time to start figuring out what is and is not going to make it into 0.5.0. For the stuff that isn't going to make it into 0.5.0, do we want to create a 0.5.1 milestone or just save it for 0.6.0 Other than what has already been closed, my read of what is going to be done is: - #314 Decrease the volume of 'PASSED' email sent to maintainers from bodhi * This 'just' needs to be merged and tested more - #326 Create user-facing documentation for depcheck * Going to start on this later today - #315 Create per-item logs for multi-item tests - #318 Provide access to test documentation Not sure: - #298 test.py - split postprocess_iteration reporting into standalone methods - #316 depcheck: extract possible cause of failure - #330 upgradepath: improve behavior when pushing update to multiple releases Probably not: - #319 Create HTML log output if possible * based on what is currently in the comments

2 1

[AutoQA] #336: Distinguish machine architecture and test architecture
by fedora-badges 06 Jun '11

06 Jun '11

#336: Distinguish machine architecture and test architecture -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: major | Milestone: Future tasks Component: core | Keywords: -------------------------+-------------------------------------------------- Currently we have the --arch option that relates to the client machine architecture. But that doesn't have to correspond to the desired architecture of the executed test (it may run 32bit code on 64bit system, for example). It is discussed here: https://fedorahosted.org/pipermail/autoqa-devel/2011-May/002302.html Distinguish these two separate things properly - allow to specify the test architecture. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/336> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

2 1

[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

A puzzle about the ways of adding repos when installing
by Tao Wu 03 Jun '11

03 Jun '11

Hi folks, I'm trying to build a hard drive auto installation script but have a puzzle on the several methods of locating repo. As we know, there are at least 3 ways to locate the iso image: 1. add the boot argument 'askmethod', then choose the location when anaconda prompts, like: https://fedoraproject.org/wiki/QA/TestCases/InstallSourceHardDrive 2. add the boot argument 'repo=hd:<device>:/<path>', like: http://fedoraproject.org/wiki/Anaconda/Options#repo 3. write the repo location into kickstart file, like: https://fedoraproject.org/wiki/Anaconda/Kickstart#install 4. add the repo graphically (this method does not support using iso file), like: https://fedoraproject.org/wiki/QA:Testcase_Ftp_Repository Can someone tell me that are these methods the same to anaconda, and if they are different, which one can be treat as the third one(kickstart method)? Thanks! -- Best Regards, Tao Wu

4 4

Re: [AutoQA] #319: Create HTML log output if possible
by fedora-badges 03 Jun '11

03 Jun '11

#319: Create HTML log output if possible --------------------+------------------------------------------------------- Reporter: kparal | Owner: vhumpa Type: task | Status: new Priority: major | Milestone: 0.5.0 Component: core | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by kparal): * component: documentation => core * milestone: Nice to have soon => 0.5.0 Comment: Let's keep it in 0.5.0 in order not to lose track of this ticket. And move to documentation once the code is in master. Thanks. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/319#comment:7> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

Re: [AutoQA] #319: Create HTML log output if possible
by fedora-badges 03 Jun '11

03 Jun '11

#319: Create HTML log output if possible ---------------------------+------------------------------------------------ Reporter: kparal | Owner: vhumpa Type: task | Status: new Priority: major | Milestone: Nice to have soon Component: documentation | Resolution: Keywords: | ---------------------------+------------------------------------------------ Changes (by vhumpa): * component: core => documentation * milestone: 0.5.0 => Nice to have soon -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/319#comment:6> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

[AutoQA] #327: create plaintext template for pretty logs
by fedora-badges 03 Jun '11

03 Jun '11

#327: create plaintext template for pretty logs --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: 0.5.0 Component: core | Keywords: --------------------+------------------------------------------------------- We need to have a plaintext template for pretty logs. It will be universal for all tests and different parts of the template will be replaced by actual results/data. Ideas for example template can be found here: https://fedorahosted.org/autoqa/wiki/Planning050logFormatting Create the template and also some means to replace different parts of the template. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/327> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 12

Improving the testability of AutoQA
by Tim Flink 03 Jun '11

03 Jun '11

As I've been working on the email reduction feature, I've been rather frustrated with how difficult it is to test AutoQA as a framework. I've written scripts to make testing depcheck (minus commenting and build gathering) easier but I have yet to find a reasonable way to exercise the whole AutoQA stack other than running jobs on my dev system with comments disabled and hope that they finish before production does. Before I go farther, I realize that what I'm discussing would be a non-trivial amount of work and I'm kind of thinking that it would be a little too much for 0.5.0. Then again, more testing could help improve the release. Thoughts on that part would be welcome. I can think of two methods that we could use to make testing easier and start down the road of retiring our mascot: - Refactor bodhi_utils and koji_utils so that they can be stubbed out in testing - Find an alternative to the production instances of koji and bodhi Either way, setting up the conditions for self-tests (making mock rpms, setting up the metadata, creating repos) is going to be a decent amount of work and will likely end up with fragile, high maintenance tests if we go beyond basic smoke tests. There were concerns over the refactoring I proposed for koji_utils a while back so I assume that isn't the way we want to proceed for now. I looked into setting up test instances of bodhi and koji but I'm rather intimidated by the amount of maintenance and hacking that would be required to induce the conditions that we would need for more complete testing on a regular basis. With this in mind, I started hacking at a mockup for replacing bodhi and koji for testing purposes that does nothing more than implement the parts of those interfaces that we're using in AutoQA. It took a little while to reverse engineer the interfaces to bodhi and koji but I do have some code that is able to fool the koji client with hard-coded results (haven't tried it with AutoQA yet nor have I gotten very far on mocking up bodhi). I can send out code if anyone wants to see it (kind of ugly ATM, though). While finishing the mockup would also be non-trivial, I think that it will be more manageable and flexible in the long run in addition to being better suited to our needs since we can add in testability features as needed without having to bug other teams about features that other people may never use. Anyhow, thoughts on the concepts? On the timing (try to have some for 0.5.0 or not)? Anything that I didn't consider? Tim

2 2

A puzzle about the ways of adding repos when installing
by Tao Wu 03 Jun '11

03 Jun '11

Hi folks, I'm trying to build a hard drive auto installation script but have a puzzle on the several methods of locating repo. As we know, there are at least 3 ways to locate the iso image: 1. add the boot argument 'askmethod', then choose the location when anaconda prompts, like: https://fedoraproject.org/wiki/QA/TestCases/InstallSourceHardDrive 2. add the boot argument 'repo=hd:<device>:/<path>', like: http://fedoraproject.org/wiki/Anaconda/Options#repo 3. write the repo location into kickstart file, like: https://fedoraproject.org/wiki/Anaconda/Kickstart#install 4. add the repo graphically (this method does not support using iso file), like: https://fedoraproject.org/wiki/QA:Testcase_Ftp_Repository Can someone tell me that are these methods the same to anaconda, and if they are different, which one can be treat as the third one(kickstart method)? Thanks! -- Best Regards, Tao Wu

1 0

A puzzle about the ways of adding repos when installing
by Tao Wu 03 Jun '11

03 Jun '11

Hi folks, I'm trying to build a hard drive auto installation script but have a puzzle on the several methods of locating repo. As we know, there are at least 3 ways to locate the iso image: 1. add the boot argument 'askmethod', then choose the location when anaconda prompts, like: https://fedoraproject.org/wiki/QA/TestCases/InstallSourceHardDrive 2. add the boot argument 'repo=hd:<device>:/<path>', like: http://fedoraproject.org/wiki/Anaconda/Options#repo 3. write the repo location into kickstart file, like: https://fedoraproject.org/wiki/Anaconda/Kickstart#install 4. add the repo graphically (this method does not support using iso file), like: https://fedoraproject.org/wiki/QA:Testcase_Ftp_Repository Can someone tell me that are these methods the same to anaconda, and if they are different, which one can be treat as the third one(kickstart method)? Thanks! -- Best Regards, Tao Wu

1 0

dealing with i686 builds
by Tim Flink 03 Jun '11

03 Jun '11

One of the things that I haven't dealt with yet for email reduction is i686 packages. At the moment, I assume that there are 2 or 3 tests that will be run depending on the koji tag: - depcheck i386 - depcheck x86_64 - upgradepath noarch (not run for updates-testing) These 2 or 3 tests are used to determine the state of an update's tests and that state is used as part of the decision process to send an email or not. I'm trying to figure out the best way to deal with i686 packages and the things that I have come up with so far are: - Ignore them and accept that emails will not be sent for those updates - Interface with bodhi/koji to determine whether an update has i686 builds and adjust the state determination as needed I remember Kamil found a list of i686 packages (but can't seem to find the email at the moment) but I'll find the list of updates that would be affected by not handling i686 builds. Any other thoughts on how to go about doing this or preferences on one over the other? Tim

2 2

Release Readyness
by Tim Flink 02 Jun '11

02 Jun '11

Well, it's been 2 weeks since the last time this question was asked and it's time to do it again: Are we ready for release? My vote is going to be for no again but I'm also wondering if we should re-evaluate next week instead of 2 weeks from now. I think that the email reduction feature is getting close to being done and it sounds like the logging feature is also getting close. Thoughts? Tim

2 1

[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

Simple Fix Pushed to Master
by Tim Flink 01 Jun '11

01 Jun '11

I pushed a quick fix to master (same code isn't in stable yet) that was throwing exceptions if an arch wasn't specified for koji (which is the default). https://fedorahosted.org/autoqa/changeset/7a230188ed2926498ceac4a4061e267eb… I can't think of any problems this would cause but figured that I would send out a quick email. Tim

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

autoqa-devel June 2011