DVD auto install test script
by Li Ming
Hi,
I write a very simple DVD auto install test script by referring
Will Woods's install script.Many thanks for Will.:) This is my first
Python script,it is definitely not good. I will take this script as a
starting-point,hope can write some high-qualified scripts in the future.
This script only supports DVD + kickstart install. If you want to try
it,please modify the attached ks.cfg to specify install source first.
this kickstart file can be accessed by http or ftp. Before run it, you
need to install virtualization,python-virtinst... Run the script like this:
mount -o loop DVDImage.iso /InstallTree
./dvd_install.py -k http://server/ks.cfg -a i386 -d /InstallTree |tee
test.log
I did not put it to git because some account issues. I will upload
later. See the attachments.
Thanks
Liam
14 years, 2 months
Re: autoinstall script
by James Laska
On Tue, 2010-01-26 at 16:17 +0800, Li Ming wrote:
> I use git push to summit my script,but I have no permission to
> access the server, do you know who I can get help from? Will woods or
> someone else?
Responding to the list ...
Will or Kamil, do you have a preference or a new committer hazing
ritual? Liam has an early working copy of a new install test. If I
understand, he'd like to create a branch and begin pushing changes to
that branch.
Thanks,
James
14 years, 2 months
[AutoQA] #116: koji_watcher: Pass ENVR instead of NVR
by fedora-badges
#116: koji_watcher: Pass ENVR instead of NVR
---------------------+------------------------------------------------------
Reporter: kparal | Owner: kparal
Type: defect | Status: new
Priority: major | Milestone:
Component: harness | Version: 1.0
Keywords: |
---------------------+------------------------------------------------------
I have found a problem with current koji_watcher implementation. It passes
package NVR to its tests. But if I want to limit max EVR in rpmguard test
using koji_utils.list_previous_release(), I have no way to find out the
current epoch of the received package. Which causes limitation to work
incorrectly. Therefore I think the watcher should be changed to provide
its tests with the whole ENVR in format '1:pidgin-2.5-1.fc12' or
'zip-0.4-2.fc12' (assuming epoch 0).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/116>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
14 years, 2 months
rats_install improvements
by James Laska
Greetings,
I've incorporated the earlier patch feedback on install.py and adjusted it slightly to accomodate how images are landing for RATS drops now. These compose trees contain only boot and install images, and no packages or repodata. I've modified rats.py, rats_install.py and install.py to accomodate installing using the images and packages in different locations. I've tested locally and it works well. This addresses ticket#115.
Also included in the patch is install.py support for adding boot arguments (e.g. updates=http://.../updates.img) as well as support for accepting this information from the control file in rats_install.py. This address ticket#103.
The next step will be adjusting post-tree-compose to watch this additional RATS drop location. But for now, I'm comfortable manually scheduling these tests to work out the kinks.
Please let me know if there are any corrections or suggestions.
Thanks,
James
14 years, 2 months
Re: rpmguard: comparing identical packages
by Kamil Paral
----- "Kamil Paral" <kparal(a)redhat.com> wrote:
> As I have mentioned, it is currently possible for a package to "fly
> under our radar" by simply moving to official repositories (stable,
> updates, updates-testing) too soon. It caused by our current strategy
> to compare the package against its most recent version in official
> repositories.
>
>
> Solution #2: Re-implement "search for latest" strategy
> I have been playing with koji command and it seems to be able
> to list all the history of builds with particular tag, not just
> the latest build. You can try it yourself:
> $ koji list-tag-history --package=PackageKit
> $ koji list-tagged dist-f12-updates PackageKit
> Therefore we can re-implement/add a new method to our library
> that would not just provide the latest build of a package, but
> all of them from the history. Then we would pick the one that
> suits us most. The API clearly offers this capabilities.
>
>
> There is also one question that is directly connected to this topic.
> Which tags do we want to search through when looking for previous
> builds?
> c) Or the other way round, would it be better to search through only
> stable and -updates (skip -updates-testing)?
> When more builds are in testing repo, the differences would be
> displayed always against the latest build in stable repos (stable or
> -updates).
>
As mentioned in ticket #114 [1], I have implemented solution #2c).
Only publicly available repos and searched through now bu default
(can be changed) and searching for most recent package should work
now correctly, you can specify maximum allowed EVR (exclusive).
No more fare dodgers! :)
[1] https://fedorahosted.org/autoqa/ticket/114
14 years, 2 months
[AutoQA] #114: koji_utils: list latest release fix
by fedora-badges
#114: koji_utils: list latest release fix
---------------------+------------------------------------------------------
Reporter: kparal | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: harness | Version: 1.0
Keywords: |
---------------------+------------------------------------------------------
As discussed on [https://fedorahosted.org/pipermail/autoqa-
devel/2010-January/000143.html autoqa-devel], the list_previous_releases()
method should be modified to support setting an optional supremum, so then
it just returns releases with NVR lesser then specified supremum. Also an
option should exist to allow us to look only in the "publicly available"
parent repositories (stable and -updates, skip -updates-testing and
-updates-candidate), since we need that for our tests.
Alternatively, another method with similar name can be created.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/114>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
14 years, 2 months
