to, 2005-06-23 kello 03:28 -0400, Kevin Mark kirjoitti:
> A simple question. You mention that you use apt-get in this new testing
> environment. Would it be useful to allow an apt-get
> workalike(dpkg/aptitude/wajig)?
Yes, that needs to be done. I haven't had trouble with it yet, so I
haven't bot
Hi,
> I've been thinking about that kind of package testing as well, but
> haven't gotten very far with it. See my two web log entries about it:
>
> http://liw.iki.fi/liw/log/2005-05.html#20050507b
> http://liw.iki.fi/liw/log/2005-05.html#20050509c
>
> In other words, I don't think it should be
On Thu, Jun 23, 2005 at 02:45:34AM +0300, Lars Wirzenius wrote:
> la, 2005-06-18 kello 22:53 -0400, Joey Hess kirjoitti:
> > I want to run a test that installs each package in woody in turn,
> > upgrades them to sarge, then to sid, then purges it, then looks for
> > /usr/doc and /usr/info stuff tha
Lars Wirzenius wrote:
> Finally, it reports problems against the state of the directory
> tree at the last distribution compared with the state without
> the packages having been installed.
It would be useful if it could report the same problems in the
intermediate dis
ma, 2005-06-20 kello 16:47 +0100, Paul Brossier kirjoitti:
> how about an optional debian/package.piuparts file that would contain
> the syntax to make runtime tests? this would allow to check that
> executables can be run, and possibly that their result is consistent. it
> could even be used to de
la, 2005-06-18 kello 22:53 -0400, Joey Hess kirjoitti:
> I want to run a test that installs each package in woody in turn,
> upgrades them to sarge, then to sid, then purges it, then looks for
> /usr/doc and /usr/info stuff that is were produced during the package's
> install or upgrade and not rem
Em Dom, 2005-06-19 às 17:57 +0900, Junichi Uekawa escreveu:
> # install-remove check
> dpkg -i /tmp/buildd/*.deb
> dpkg --remove $PKGNAMES
The problem with this kind of tests is that many packages build
conflicting packages. For example glade source package creates 'glade'
and 'glade-gnome' which
On Tue, Jun 21, 2005 at 07:01:06AM +0900, Junichi Uekawa wrote:
> lvm2 is supposed to be very much improved with read/write snapshots.
> (compared to lvm1 which only had read-only snapshots. Correct me
> if I'm wrong)
If you do not use linux 2.6.10, yes.
> Is it stable enough?
Except the usual
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> Hi,
>
>> > I think this can not quite do it, since the chroot will need to be a
>> > woody chroot but get at least partially upgraded in each test to allow
>> > installation of the sarge and sid packages. It looks like piuparts is
>> > otherwise close t
On Tue, 21 Jun 2005, Junichi Uekawa wrote:
> Hi,
>
> > > I think this can not quite do it, since the chroot will need to be a
> > > woody chroot but get at least partially upgraded in each test to allow
> > > installation of the sarge and sid packages. It looks like piuparts is
> > > otherwise clo
Hi,
> > I think this can not quite do it, since the chroot will need to be a
> > woody chroot but get at least partially upgraded in each test to allow
> > installation of the sarge and sid packages. It looks like piuparts is
> > otherwise close to the tool I need.
>
> Create a lvm logical volume
On Sun, Jun 19, 2005 at 04:15:08AM +0300, Lars Wirzenius wrote:
> Frank Lichtenheld and others have brought up the idea of automatically
> testing installation, upgrading, and removal of packages. It struck me
> that it should be pretty simple to implement at least basic versions of
> this. The res
In article <[EMAIL PROTECTED]> you wrote:
> Using lvm is the fastest way to do this. Alternatives are to copy or
> untar a clean chroot for every test. But that needs more time.
You can also use a loopback file and make a copy of it. Or use UML.
Gruss
Bernd
--
To UNSUBSCRIBE, email to [EMAIL P
Joey Hess <[EMAIL PROTECTED]> writes:
> Lars Wirzenius wrote:
>> Frank Lichtenheld and others have brought up the idea of automatically
>> testing installation, upgrading, and removal of packages. It struck me
>> that it should be pretty simple to implement at least basic versions of
>> this. The
[Joey Hess]
> I want to run a test that installs each package in woody in turn,
> upgrades them to sarge, then to sid, then purges it, then looks for
> /usr/doc and /usr/info stuff that is were produced during the
> package's install or upgrade and not removed.
I made a script to test upgrades fro
> "lars" == Lars Wirzenius <[EMAIL PROTECTED]> writes:
lars> la, 2005-06-18 kello 22:53 -0400, Joey Hess kirjoitti:
>> I want to run a test that installs each package in woody in
>> turn, upgrades them to sarge, then to sid, then purges it, then
>> looks for /usr/doc and /usr/i
la, 2005-06-18 kello 22:53 -0400, Joey Hess kirjoitti:
> I want to run a test that installs each package in woody in turn,
> upgrades them to sarge, then to sid, then purges it, then looks for
> /usr/doc and /usr/info stuff that is were produced during the package's
> install or upgrade and not rem
Hi,
> Frank Lichtenheld and others have brought up the idea of automatically
> testing installation, upgrading, and removal of packages. It struck me
> that it should be pretty simple to implement at least basic versions of
> this. The result: http://liw.iki.fi/liw/download/piuparts-0.4.tar.gz
>
Lars Wirzenius wrote:
> Frank Lichtenheld and others have brought up the idea of automatically
> testing installation, upgrading, and removal of packages. It struck me
> that it should be pretty simple to implement at least basic versions of
> this. The result: http://liw.iki.fi/liw/download/piupar
Frank Lichtenheld and others have brought up the idea of automatically
testing installation, upgrading, and removal of packages. It struck me
that it should be pretty simple to implement at least basic versions of
this. The result: http://liw.iki.fi/liw/download/piuparts-0.4.tar.gz
I have attached
20 matches
Mail list logo
