Re: rpmguard tests - more thoughts
by Kamil Paral
----- "seth vidal" <skvidal(a)fedoraproject.org> wrote:
> I was thinking some more about the rpmguard/rpmlint/etc tests and
> looking around the tests subdir.
>
> rpmguard and rpmlint overlap in this weird way.
>
> rpmguard tests comparisons between old and new pkgs
> rpmlint tests just the new pkgs themselves.
>
>
> combining those under one umbrella seems to make the most sense.
>
> so you have:
>
> package-tests
> - comparisons/regression checks
> - *lintian checks
>
> For purposes of encouraging test authors it seems like it would make
> sense to make one interface for all of this.
>
> So, provide:
> - set of new pkgs
> - set of old pkgs
> - an object to use to spit back feedback (as described before)
>
> then the test author can choose to look at previous pkgs (or not) as
> they require and they don't have to learn two infrastructure.
>
> In this scheme them rpmlint check would just be another test that's
> run
> and happens to only act on the new pkg set.
>
> Is this worth pursuing?
>
> -sv
Seth,
thanks for an idea. Me and James already discussed that briefly a few
times and IIRC concluded that we would discuss it in more detail
some time in the future :)
It is true that rpmlint and rpmguard have many things in common. I also
took a lot of inspiration out of the former one when writing the latter
one. We could merge them together. I'm just not sure how much it would
complicate the interface. Also there are some other minor differences -
rpmlint checks package conformity to some guidelines, therefore it
can spit out meaningful errors. On the other hand there are no real
guidelines on how much the package can change in time, so rpmguard can't
really mark something as error, it can just output information messages
or warnings at best. But still that's fine I think.
We certainly have to speak with rpmlint's maintainer first - Ville
Skytta I think. And the most important question - now or some time
later? :) I agree it can be a nice future plan (it can be even a
summer coding topic, yay!), but currently our team has higher priority
in finishing AutoQA and implementing Package Update Acceptance Test
Plan, I think.
What do you say?
14 years
using 'git am' with Evolution
by Will Woods
So I've been having a tough time figuring out how to cleanly save
patches mailed to the list so I can apply them with 'git am', and I just
discovered this little trick in Evolution.
If you select the messages you want to save/apply, and drag-and-drop
them to a terminal window, it saves them to a temporary files and pastes
in the filename!
So you can just type 'git am ', drag-and-drop the message(s), and you'll
get something like:
git am '/home/wwoods/.evolution/cache/tmp/SOME_TEMPORARY_FILE'
hit Enter and it should Just Work. Yay!
-w
14 years
[PATCH 1/2] Add 'composes' item to repoinfo
by Will Woods
---
lib/python/repoinfo.py | 1 +
repoinfo.conf | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lib/python/repoinfo.py b/lib/python/repoinfo.py
index 5dc2d95..c99146e 100644
--- a/lib/python/repoinfo.py
+++ b/lib/python/repoinfo.py
@@ -49,6 +49,7 @@ class RepoinfoConfig(object):
'path': self.config.get(name,'path'),
'name': name, # kind of unnecessary
'collection_name': self.config.get(name, 'collection_name'),
+ 'composes': self.config.get(name,'composes'),
}
return repo
def getrepo_by_tag(self, tag):
diff --git a/repoinfo.conf b/repoinfo.conf
index 909878d..bb3c9cd 100644
--- a/repoinfo.conf
+++ b/repoinfo.conf
@@ -1,6 +1,7 @@
[DEFAULT]
parents =
arches = i386, x86_64, ppc
+composes =
# tag defaults to dist-[section_name]
tag = dist-%(__name__)s
baseurl = http://download.fedoraproject.org/pub/fedora/linux
--
1.7.0.1
14 years
No more reboots ...
by James Laska
Greetings,
Just a heads up, as you know we have a lot more tests running now in our
internal autoqa instance. Anyone watching autoqa-results can see the
activity. Our 3 test clients were having a hard time keeping up,
especially since one system seems to no longer grab a DHCP IP upon
reboot.
As a temporary measure, I've updated the /usr/bin/autoqa script on the
server to not reboot the test systems before or after a test is run on
the client. This allowed 3 systems to work down the backlog of over 200
jobs in one evening.
The patch is attached, I'm not ready to send this out for review yet.
However, I did want to let you know in case you observe any side-effects
from no longer rebooting after every test.
Thanks,
James
14 years
spam in autoqa-results
by Kamil Paral
Since spam starts to come into autoqa-results and I'm
tired of discarding it every time, I have set the list
to automatically reject messages from non-members.
If you want to send results into the list, be sure
you send it from autoqa(a)fedoraproject.org or from
some address that is subscribed to the list.
Thanks,
Kamil
14 years
rpmguard tests - more thoughts
by Seth Vidal
I was thinking some more about the rpmguard/rpmlint/etc tests and
looking around the tests subdir.
rpmguard and rpmlint overlap in this weird way.
rpmguard tests comparisons between old and new pkgs
rpmlint tests just the new pkgs themselves.
combining those under one umbrella seems to make the most sense.
so you have:
package-tests
- comparisons/regression checks
- *lintian checks
For purposes of encouraging test authors it seems like it would make
sense to make one interface for all of this.
So, provide:
- set of new pkgs
- set of old pkgs
- an object to use to spit back feedback (as described before)
then the test author can choose to look at previous pkgs (or not) as
they require and they don't have to learn two infrastructure.
In this scheme them rpmlint check would just be another test that's run
and happens to only act on the new pkg set.
Is this worth pursuing?
-sv
14 years
[PATCH] Skip reponames not in repoinfo
by Will Woods
---
hooks/post-tree-compose/watch-composes.py | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/hooks/post-tree-compose/watch-composes.py b/hooks/post-tree-compose/watch-composes.py
index 265e5fd..83283e1 100755
--- a/hooks/post-tree-compose/watch-composes.py
+++ b/hooks/post-tree-compose/watch-composes.py
@@ -39,6 +39,10 @@ repodict = {} # a place to save repo info as read
# Cycle through our list of repo watches and determine which should be tested.
for reponame in watchcomposes:
+ # Skip undefined repos - this is an expected condition, since sometimes
+ # we just won't be producing composes for e.g. branched.
+ if reponame not in repoinfo.repos():
+ continue
repo = repoinfo.getrepo(reponame)
repodict[reponame] = repo
if not reponame in testable:
--
1.7.0.1
14 years
