Jesse,
How are you creating the tarballs from aegis? One of the make targets near
the bottom of Makefile, or something else? make is complaining about
nonexistent targets, and I want to make sure I’m on the right track before I
try to debug it.
Jesse,
How are you creating the tarballs from aegis? One of the make targets near
the bottom of Makefile, or something else? make is complaining about
nonexistent targets, and I want to make sure I’m on the right track before I
try to debug it.
make tag-and-release-baseline
What sorts of autobuilding are you trying to do? (What are you packaging
for?)
–
jaq@spacepants.org http://spacepants.org/jaq.gpg
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
This one time, at band camp, Jesse Vincent wrote:>On Wed, Jun 04, 2003 at 04:08:42PM +1000, Jamie Wilkinson wrote:
Jesse,
How are you creating the tarballs from aegis? One of the make targets near
the bottom of Makefile, or something else? make is complaining about
nonexistent targets, and I want to make sure I’m on the right track before I
try to debug it.make tag-and-release-baseline
What sorts of autobuilding are you trying to do? (What are you packaging
for?)
I’m experimenting with automagic rpm building as part of the integration
build.
I found my problem with nonexistent targets though.
As an aside, slightly on topic, what do you feel about automake build
systems?
Oh, and how do you like your diffs? Should I just send you a bunch of
aedists in order?
As an aside, slightly on topic, what do you feel about automake build
systems?
Automake scares the pants off me. But I’ll look at anything that
someone thinks might help 
Oh, and how do you like your diffs? Should I just send you a bunch of
aedists in order?
As yet, nobody’s handed me an aedist. start with one or two for discrete
features and we’ll go from there. send them to rt-3.0-bugs@fsck.com
–
jaq@spacepants.org http://spacepants.org/jaq.gpg
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
This one time, at band camp, Jesse Vincent wrote:
As an aside, slightly on topic, what do you feel about automake build
systems?Automake scares the pants off me. But I’ll look at anything that
someone thinks might help
Ok, I’ll give it a go soon. It’s not that scary once you know what it
thinks it’s doing 
Oh, and how do you like your diffs? Should I just send you a bunch of
aedists in order?As yet, nobody’s handed me an aedist. start with one or two for discrete
features and we’ll go from there. send them to rt-3.0-bugs@fsck.com
What I’ve got now is about 5 cosmetic changes, and the beginnings of a test
suite (about 4 or 5 changes). The majority of the changes caused by the
testsuite are build system changes, all centred around Makefile.in. The
tests do the following:
- check that configure and make install works
- check that configure and make install works from outside the source tree
- check that make initialize-database works
- check that make install works with the FHS layout
They’re pretty simple, albeit big tests I’ve got some bigger goals with
the test suite in mind, such as automatic schema updates and web ui feature
checks… that’s going to require a bit of work though
So I’ll send some aedists to the bug address, in groups of related dists,
with some notes about which order they should be applied in.
Most of what I’m doing isn’t useful to RT users, just for development,
though, so I’ll understand if you find adding big ugly tests for known
working code annoying (though one of my tests found that postgresl ACL bug
that was mentioned on -users recently).
Oh, and once I’ve got the automatic RPM stuff done I’ll send it your way
too.
What I’ve got now is about 5 cosmetic changes, and the beginnings of a test
suite (about 4 or 5 changes). The majority of the changes caused by the
testsuite are build system changes, all centred around Makefile.in. The
tests do the following:
- check that configure and make install works
- check that configure and make install works from outside the source tree
- check that make initialize-database works
- check that make install works with the FHS layout
So. it might be best if those are integrated into the existing “make
regression” test suite of ~800 tests of the system…
They’re pretty simple, albeit big tests
the test suite in mind, such as automatic schema updates and web ui feature
checks… that’s going to require a bit of work though
So. we’re already doing some of that. And there’s more in the way of web
testing on the way too.
So I’ll send some aedists to the bug address, in groups of related dists,
with some notes about which order they should be applied in.
All right. it would really be best if you can manage one aedist per
change. (possibly by developing each change as a branch and sending me a
rollup for that branch when you’re done developing it)
Most of what I’m doing isn’t useful to RT users, just for development,
though, so I’ll understand if you find adding big ugly tests for known
working code annoying (though one of my tests found that postgresl ACL bug
that was mentioned on -users recently).
Well, my tests found it too Just for every incremental pre release,
we don’t do the full test matrix (test on every combo of mysql,
postgres, modperl and fastcgi)
Oh, and once I’ve got the automatic RPM stuff done I’ll send it your way
too.
neat
–
jaq@spacepants.org http://spacepants.org/jaq.gpg
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
This one time, at band camp, Jesse Vincent wrote:
What I’ve got now is about 5 cosmetic changes, and the beginnings of a test
suite (about 4 or 5 changes). The majority of the changes caused by the
testsuite are build system changes, all centred around Makefile.in. The
tests do the following:
- check that configure and make install works
- check that configure and make install works from outside the source tree
- check that make initialize-database works
- check that make install works with the FHS layout
So. it might be best if those are integrated into the existing “make
regression” test suite of ~800 tests of the system…
Interesting… those 4 files in t/ do 800 tests? I’d better look into it
So. it might be best if those are integrated into the existing “make
regression” test suite of ~800 tests of the system…Interesting… those 4 files in t/ do 800 tests? I’d better look into it
RT uses Test::Inline based tests. The code is bristled with tests that
are automatically extracted and run. “./configure;make regression”
will eat your local RT database, but should then spend a while churning
and eventaully tell you that it passed all 79x tests.
-j
–
jaq@spacepants.org http://spacepants.org/jaq.gpg
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.