#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
#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
#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
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/
#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
#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
> 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
#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
#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