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
19 matches
Mail list logo
