Fwd: New bodhi release in production
by Kamil Paral
> Major changes in bodhi 0.9.2
> ----------------------------
>
> - fedmsg support! Bodhi now fires off messages for various events
> that occur. Join #fedora-fedmsg to see it in action. (Ralph Bean)
Wow, the pony is here.
11 years, 8 months
[AutoQA] #428: Update repoinfo.conf - Add branch
by fedora-badges
#428: Update repoinfo.conf - Add branch
-------------------------+------------------------
Reporter: ausil | Owner:
Type: task | Status: new
Priority: critical | Milestone: Hot issues
Component: production | Keywords:
Blocked By: | Blocking:
-------------------------+------------------------
per the mass branching sop
https://fedoraproject.org/wiki/Mass_Branching_SOP
Update AutoQA repoinfo.conf
The AutoQA project maintains a config file (repoinfo.conf) that describes
available package repositories and their inheritance. In order to have
automated testing of Branched package builds, the repoinfo.conf file needs
to be updated. Please file an autoqa ticket to modify the repoinfo.conf
file to include pointers to the new release.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/428>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
11 years, 8 months
[AutoQA] #427: Purge unneeded files in autotest results dir
by fedora-badges
#427: Purge unneeded files in autotest results dir
-------------------------+-------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: minor | Milestone: Finger Food
Component: production | Keywords:
Blocked By: | Blocking:
-------------------------+-------------------------
Currently we have a script that periodically traverses through autotest
results dir and compresses too large files. Also we use tmpwatch to remove
too old results. But we still sometimes have problems with disk space and
number of inodes on our servers. Autotest stores large number of files in
each result directory. By cleaning those we don't want we can save
resources, speed up execution of maintenance scripts and potential
debugging (like grepping through results).
Let's create a script that would traverse the results directory
periodically and remove unneeded files. It would also compress large
files, so it would call or merge the existing script.
If we look into an example results dir:
http://autoqa-stg.fedoraproject.org/results/100310-autotest/qa07.qa/
I believe we need to keep:
{{{
/control
/debug/*.DEBUG
/host_keyvals
/keyval
/rpmguard/debug/*.DEBUG ("rpmguard" is a dynamic test name here)
/rpmguard/keyval
/rpmguard/results
/rpmguard/status
/status.log
/sysinfo/installed_packages
/sysinfo/uname
}}}
The rest of it can be deleted.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/427>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
11 years, 8 months
[AutoQA] #429: Don't test inaccessible repos?
by fedora-badges
#429: Don't test inaccessible repos?
-----------------------+-------------------------
Reporter: kparal | Owner:
Type: defect | Status: new
Priority: minor | Milestone: Finger Food
Component: watchers | Keywords:
Blocked By: | Blocking:
-----------------------+-------------------------
In ticket #428 we added F18 repo path to repoinfo.conf, but the path
hadn't existed yet. Still, a lot of tests get executed (repoclosure and
conflicts) and then crashed, because URL was inaccessible.
Shouldn't the watcher detect the URL is inaccessible and avoid scheduling
tests?
Please investigate.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/429>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
11 years, 8 months
[AutoQA] #157: conflicts: requested arch not respected
by fedora-badges
#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
11 years, 8 months
[AutoQA] #424: Add F17 machines and update F15 machines
by fedora-badges
#424: Add F17 machines and update F15 machines
-------------------------+-------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: major | Milestone: Nice to have soon
Component: production | Keywords:
Blocked By: | Blocking:
-------------------------+-------------------------------
F15 will be EOL soon. We need to upgrade those test clients. Also we have
none F17 test machines ATM. We need to have some of them.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/424>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
11 years, 8 months
[AutoQA] #421: depcheck: KeyError: 'strong_requires'
by fedora-badges
#421: depcheck: KeyError: 'strong_requires'
-----------------------+------------------------
Reporter: kparal | Owner:
Type: defect | Status: new
Priority: critical | Milestone: Hot issues
Component: tests | Keywords:
Blocked By: | Blocking:
-----------------------+------------------------
Since I updated our staging machines, a lot of these depcheck crashes
appeared:
{{{
Traceback (most recent call last):
File "./depcheck", line 112, in <module>
profile=opts.profile)
File "/usr/share/autotest/tests/depcheck/depcheck_lib.py", line 394, in
depcheck_main
test_dir=temp_dir, accepted_dir=acc_dir)
File "/usr/share/autotest/tests/depcheck/depcheck_lib.py", line 352, in
do_depcheck
(r, problems) = y.resolveDeps()
File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 855, in
resolveDeps
CheckDeps, checkinstalls, checkremoves, missing =
self._resolveRequires(errors)
File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 984, in
_resolveRequires
thisneeds = self._checkInstall(txmbr)
File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 1051, in
_checkInstall
oldreqs.extend(oldpo.returnPrco('strong_requires'))
File "/usr/lib/python2.7/site-packages/yum/sqlitesack.py", line 385, in
returnPrco
if isinstance(self.prco[prcotype], tuple):
KeyError: 'strong_requires'
}}}
http://autoqa-
stg.fedoraproject.org/results/69597-autotest/virt26.qa/depcheck/results/f17
-updates-testing-.html
http://autoqa-
stg.fedoraproject.org/resultsdb/frontend/search?type=Testcase&terms=depcheck
I suspect the problem is in updated yum. I see these crashes only on
virt26 and virt27, which are F16 machines. It does not happen on qa06 and
qa07, which are F15 machines. Also it does not seem to manifest on virt05,
which is F16 machine but has an old yum.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/421>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
11 years, 8 months
Re: Use AutoQA to track changes in "provides" and "requires"?
by Kamil Paral
> On Wed, 2012-08-01 at 11:17 -0500, Richard Shaw wrote:
> > On Wed, Aug 1, 2012 at 10:37 AM, Kamil Paral <kparal(a)redhat.com>
> > wrote:
> > > Something like this? [1] [2]
> >
> > Yup! Something a lot like that! I did look over the AutoQA wiki
> > before
> > posting but didn't know enough about rpmguard to know that where I
> > needed to look :)
> >
> >
> > > We already do that in the form of 'rpmguard' test [3]. Currently
> > > you have to sign-up manually to receive rpmguard/rpmlint results
> > > for new package builds [4].
> >
> > So you have to subscribe per package per release? I don't
> > necessarily
> > want them emailed to me but accessible somewhere would be nice.
>
> All AutoQA results can be accessed via resultsdb:
>
> http://autoqa.fedoraproject.org/resultsdb/frontend
http://autoqa.fedoraproject.org is enough, that will redirect you there.
>
> You can do a search for a specific package and/or test case. On the
> search page -
> http://autoqa.fedoraproject.org/resultsdb/frontend/search
> - 'Envr' seems to be the place to put the package name. So if you put
> 'kernel' in the 'Envr' box, and 'rpmguard' in the 'Testcase' box, and
> hit search, you get all the rpmguard tests for kernel package builds.
>
> Kamil, perhaps the search interface could be made a bit friendlier? A
> better name for the field than 'Envr', whatever the heck that's
> supposed
> to mean? A drop-down list for 'testcase', rather than free text?
> Friendly unicorn pictures? :)
> --
> Adam Williamson
ENVR is an abbreviation for epoch-name-version-release. So you can put there a package build specification in the ENVR format, or just a package name. I agree that it's not really descriptive. CCing autoqa-devel to annoy my colleagues and make them work harder :=)
Petr, can you adjust the "Envr" label text to "Package name or ENVR" (or similar)? And maybe have a look at drop-down lists for Testcase and Arch? Thanks.
11 years, 8 months
RATS tests still running against F17?
by Adam Williamson
So I took a quick look at the resultsdb and noticed that the RATS tests
- rats_sanity and rats_install - still seem to be being run against F17,
which isn't much use. (And they invariably fail). Is there a plan to
switch them to Rawhide? Do we need some kind of release-transition SOP
for AutoQA tests, to ensure they're bumped from Rawhide to Branched and
then back to Rawhide after the stable release, in a timely manner?
Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11 years, 8 months
