Summary of nss-softokn dependency problem for AutoQA check purposes
by Adam Williamson
Hi, everyone. I was asked at the last QA meeting to send a summary of
the nss-softokn dependency problem that emerged in Fedora 13 recently to
this list, so we can - if possible - try to ensure the AutoQA tests are
capable of detecting this kind of problem.
The problem was that, when an nss-softokn update was pushed for F13, the
updated i686 packages were not pushed to the x86-64 updates repository.
The original nss-softokn i686 packages, however, *are* in the x86-64
repo. So you hit trouble if you run the x86-64 version of Fedora and
have both x86-64 and i686 nss-softokn packages installed, which can
easily happen as part of a dependency chain when installing a 32-bit
package. When you went to an update, you would have an updated x86-64
package available but not an updated i686 package, which caused
problems.
The cause as described by Bill Nottingham in the ml thread:
"It's due to the fact that nss-softokn-freebl (actually, *all* the
nss/nspr libraires) do not fit the normal library naming, so it's not
explicitly pulled for multilib. For any update or release set that's
composed with a package that explicitly requires a compat arch of
nss-softokn-freebl (such as glibc, libpurple, pam_pkcs11, etc.), it will
get pulled in via dependency resolution. F-13 updates has none of these,
so it doesn't."
Bill's recommended fix (from the bug report,
https://bugzilla.redhat.com/show_bug.cgi?id=596840 ):
"There are two 'simple' fixes for this that don't involve hotfixing the
push infrastructure:
1) For all nss/nspr packages that don't have .so symlinks in their devel
packages, add %{?_isa} to the requires in the devel packages.
See https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires
for a packaging draft for this.
For example, that would change, in nss-softokn-freebl-devel:
Requires: nss-softokn-freebl = %{version}-%{release}
to:
Requires: nss-softokn-freebl%{?_isa} = %{version}-%{release}
in nss-softokn-freebl-devel,
Requires: nss-softokn = %{version}-%{release}
to
Requires: nss-softokn%{?_isa} = %{version}-%{release}
in nss-softokn-devel, and so on.
The reason this is needed is that for most -devel pacakges, there is
automatic dependencies added on the proper library package due to
following the '.so' devel symlink to the main library. This doesn't work
for nss/nspr, as the -devel packages don't have these symlinks.
2) Wait for either of
https://admin.fedoraproject.org/updates/glibc-2.12-2 or
https://admin.fedoraproject.org/updates/pidgin-2.7.1-2.fc13 to be pushed
to stable, as those will pull in the i686 nss-softokn freebl through
library dependencies. "
The critical thing to note here is that the bug is only apparent if you
look at which packages are (going to be) sent to which repositories when
the update is published. If you just look at the packages actually
generated as part of the update, you're unlikely to be able to catch the
problem. What we need to be able to check is that, if a given package's
32-bit build is available in the 64-bit release repository, when that
package is updated, the process will publish the 32-bit build to the
64-bit update repository. If not, we have trouble.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
13 years, 10 months
AutoQA live image?
by James Laska
Greetings,
While setting up autotest and autoqa to test the new post-bodhi-update
watcher, the thought occurred that might be helpful to have a autoqa
live image available for folks to test such a setup. I know several of
you have experienced the pain of setting up autotest and autoqa in the
past to confirm new tests, watchers or just proposed patches.
The live image would handle installing and configuring autotest, autoqa,
httpd and mysql. The user would be responsible for adding test clients.
Would this be of value? If so, I'll be happy to follow Kamil's
instructions [1] to create and document the use of an AutoQA live image.
Thanks,
James
[1] https://fedoraproject.org/wiki/QA/Test_Days/Live_Image
13 years, 10 months
2010-06-09 - AutoQA reprioritization discussion
by James Laska
# AutoQA priority discussion
# Date: 2010-06-09
# Time: 14:00 UTC (10:00 EDT, 15:00 CEST)
# Attendees: kparal, jskladan, wwoods, jlaska
Several folks working toward the Package Update Acceptance test plan met
and discussed re-prioritizing outstanding tasks. Below are the notes
from that meeting.
== Agenda ==
Mindmap:
http://kparal.fedorapeople.org/autoqa/tasks.png
== Conclusions ==
* Focus on infrastructure/architecture parts first
* testing autotest-server instance important, publicly available
instance not so important
* Current high priority tasks:
* post-bodhi-hook
* feature-complete, needs to be tested and merged into master
* resultdb
* quick version of virt support
* getting public accessible machines
* public autotest blocked on packaging gwt + deps (java booooo)
* Lower priority tasks
* Package sanity tests
* Package update tests
* Initscripts
* message bus (aka "pony")
* full virt support (destructive tests)
* depcheck (permissive vs enforcing)
* unit testing of koji/bodhi libraries
* requires test data stored in koji & bodhi
== TODO ==
* [jlaska] find a machine where resultdb may run (it can be VM, publicly
accessible preferred)
* [jlaska] set up testing instance of autotest-server
* [kparal] implement *quick* virtualization support
* [jskladan, wwoods helping] bodhi hook needs to be tested
* [jskladan, kparal, wwoods] continue implementing and testing resultdb
== Dependencies ==
-> testing instance of autotest-server -> bodhi hook testing -> add
support for our tests
-> testing instance of autotest-server -> quick virtualization support
-> (publicly accessible) machine -> resultdb efforts
== Next Meeting ==
* 2010-06-25 - Check-in on autoqa-devel@ for status on action items
13 years, 10 months
RFC - How to update repoinfo.conf
by James Laska
Greetings folks,
I took an action item last week to document the expected steps needed to
update the repoinfo.conf file. This file is important because it's used
by post-koji-build to figure out what repositories to monitor for
updates. In additional, it's used by the autoqa.repoinfo library to for
various packaging related tasks, including locating the previous release
of a package.
With the help of the {{FedoraVersion}} template, I think I've got the
page created such that it will need few content updates. Please take a
look at see if this is in keeping with your understanding of how, why
and when to update the repoinfo.conf file.
https://fedoraproject.org/wiki/How_to_update_AutoQA_repoinfo.conf
Thanks,
James
13 years, 10 months
automated iso sanity test
by Li Ming
Greetings,
As James discussed with me,we want the development of auto tests to
be transparent as possible,so I send out this mail to the list to show
the even uncompleted test. This automated iso sanity test will combine
the following four tests:
https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size
https://fedoraproject.org/wiki/QA:Testcase_Mediakit_Repoclosure
https://fedoraproject.org/wiki/QA:Testcase_Mediakit_FileConflicts
https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums
These tests also are listed in f13 install template:
https://fedoraproject.org/wiki/QA:Fedora_13_Install_Results_Template
You may want to try this script when you run f14 install test, it will
save your time for image sanity tests. Actually, I combined command
repoclosure and file potential_conflict.py,deleted some functions to
meet our test requirements.Currently, I only finished
Mediakit_ISO_Size,Mediakit_Repoclosure and Mediakit_FileConflicts. I
need some more time to add ISO_Checksums. The script will be attached,
you can try it as:
# ./mediakit_sanity.py --help
# ./mediakit_sanity.py -i /path/to/Fedora-12-i386-DVD.iso
# ./mediakit_sanity.py -r myrepo,http://url/to/tree/
or you can try:
# ./mediakit_sanity.py -r myrepo,http://url/to/tree/ -i
/path/to/Fedora-12-i386-DVD.iso
but I don't think it's a good method.
This test is not mature right now, I even did not test on
CD,LiveCD,etc... I only tested on local http tree and f12 DVD image. Any
weakness, feel free to point out.
Thanks
Liam
13 years, 10 months
ResultsDB Status
by Josef Skladanka
Hello gang,
I'd like to give you heads up on current ResultsDB state:
1) The 'Input' API is working and IMHO OK
<http://www.assembla.com/code/resultdb/git/nodes/resultdb/input_api.py?rev...>
These functions are made public via xmlrpc interface
<http://10.34.31.238/wsgi/resultsdb/xmlrpc>.
2) I'm starting to work on 'Output' API - i.e. functions to dig data
from the database. Since I don't really know what one would like to get
and how to filter the results (server side), it's pretty blunt for now
<http://www.assembla.com/code/resultdb/git/nodes/resultdb/output_api.py?re...>
3) Closely with {2} i started to work on some quick'n'dirty (yeah,
emphasise on the dirty part) project to test resultsdb's functionality
<http://10.34.31.238/wsgi/resultsdb/frontend/input_fake_data>
First of all, you can view (Testplans, Jobs, Testcases, Testruns) from
the database (if you'd like to add something, use
<http://10.34.31.238/phpmyadmin/index.php> user = "root", password =
"secret" [without quotes] - please be nice to that machine :-D).
The testplans/testcases in database have it's wiki-page counterparts set
up see either the tool, database or
<https://fedoraproject.org/wiki/Category:Jskladan_resultsdb_sandbox> for
links.
Why do I say that? Because some of the functionality takes advantage
from the information on the wiki! For example try starting a new testrun
<http://10.34.31.238/wsgi/resultsdb/frontend/input_fake_data?action=show_t...>
the key-value pairs are grabbed from the wiki (hint: try changing the
value of "required_keyval" key on the appropriate wiki page and
refreshing the 'start new testrun' page ;-) - once again, be nice, I
don't really deal with errors, since it's behind the scope of proof of
concept tool)
I'll let the machine (10.34.31.238) running until tomorrow (it's a virt
guest on my notebook), so feel free to play around!
Joza
13 years, 10 months
[AutoQA] #126: pst: Create script for Package Sanity Testing
by fedora-badges
#126: pst: Create script for Package Sanity Testing
-----------------------+----------------------------------------------------
Reporter: kparal | Owner: psss
Type: task | Status: new
Priority: major | Milestone: Package Sanity Tests
Component: docs/wiki | Version: 1.0
Keywords: pst |
-----------------------+----------------------------------------------------
Create script that will perform actual package sanity testing. It should
accept some command-line options denoting which packages to test and
return a result whether sanity tests passed or failed, together with more
detailed output.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/126>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 10 months
