Versioning of KVM

Versioning of KVM

[Baruch Even]

Avi,

Can you please decide on a normal version number for KVM? I currently
use 0.0.2 in order to be able to use later a proper version number, If
I'd use 2 now than any other sane version later such as 1.0 will be
lower and I'll have to use a prefix to fix that. It would be nice if you
could just use normal version numbers from the start so the Debian
version number will be the same as your version number.

Some other issues I had with packaging were clean targets that are
either missing or incomplete. You can take a look at the .diff.gz file
that is in http://people.debian.org/~baruch/kvm/ to see all the changes
I needed to do to the package to build it. It is rather messy right now
but you might be able to get some things you can incorporate in order to
make packaging easier.

Thanks,
Baruch

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Versioning of KVM

[Avi Kivity]

Baruch Even wrote:
> Avi,
>
> Can you please decide on a normal version number for KVM? I currently
> use 0.0.2 in order to be able to use later a proper version number, If
> I'd use 2 now than any other sane version later such as 1.0 will be
> lower and I'll have to use a prefix to fix that. It would be nice if you
> could just use normal version numbers from the start so the Debian
> version number will be the same as your version number.
>
>   

Well, I'd have thought that the natural numbers are a perfectly sane 
numbering scheme.  However, I'll bow to tradition and the next release 
will be 0.3.

> Some other issues I had with packaging were clean targets that are
> either missing or incomplete. You can take a look at the .diff.gz file
> that is in http://people.debian.org/~baruch/kvm/ to see all the changes
> I needed to do to the package to build it. It is rather messy right now
> but you might be able to get some things you can incorporate in order to
> make packaging easier.
>   

My current tree has fixes for most of the problems.  I'll look at the 
clean targets (why are they necessary for packaging?)


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Versioning of KVM

[Baruch Even]

* Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [061115 09:50]:
> Baruch Even wrote:
> >Avi,
> >
> >Can you please decide on a normal version number for KVM? I currently
> >use 0.0.2 in order to be able to use later a proper version number, If
> >I'd use 2 now than any other sane version later such as 1.0 will be
> >lower and I'll have to use a prefix to fix that. It would be nice if you
> >could just use normal version numbers from the start so the Debian
> >version number will be the same as your version number.
> >
> >  
> 
> Well, I'd have thought that the natural numbers are a perfectly sane numbering scheme.  However, I'll bow to tradition 
> and the next release will be 0.3.

If you plan to use natural numbers permanenly than it's fine with me, I
just thought that the version 2 is just an interim numbering scheme.

> >Some other issues I had with packaging were clean targets that are
> >either missing or incomplete. You can take a look at the .diff.gz file
> >that is in http://people.debian.org/~baruch/kvm/ to see all the changes
> >I needed to do to the package to build it. It is rather messy right now
> >but you might be able to get some things you can incorporate in order to
> >make packaging easier.
> >  
> 
> My current tree has fixes for most of the problems.  I'll look at the clean targets (why are they necessary for 
> packaging?)

Some of the packages are being built by other computers, I'm building on
my machine only the i386 version and the amd64 is built by an
auto-builder. The clean target is needed since otherwise there are the
.d files which have absolute paths for my machine and my build
environment, this will kill the auto builder. In my case I build for
Debian testing on my machine and then use a chroot to do a clean build
for Debian unstable, the .d files killed the chroot build as well.

The Debian build process does a clean before it starts the build to make
sure we do a pristine build every time to avoid such problems. It
doesn't always work when upstream clean target doesn't really clean.
Normally there is a clean target and distclean to really clean the
package back to distribution state.

Cheers,
Baruch

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Versioning of KVM

[Avi Kivity]

Baruch Even wrote:

 

>> My current tree has fixes for most of the problems.  I'll look at the clean targets (why are they necessary for 
>> packaging?)
>>     
>
> Some of the packages are being built by other computers, I'm building on
> my machine only the i386 version and the amd64 is built by an
> auto-builder. The clean target is needed since otherwise there are the
> .d files which have absolute paths for my machine and my build
> environment, this will kill the auto builder. In my case I build for
> Debian testing on my machine and then use a chroot to do a clean build
> for Debian unstable, the .d files killed the chroot build as well.
>
> The Debian build process does a clean before it starts the build to make
> sure we do a pristine build every time to avoid such problems. It
> doesn't always work when upstream clean target doesn't really clean.
> Normally there is a clean target and distclean to really clean the
> package back to distribution state.
>
>   

I don't understand.  If you start from an empty directory and unpack the 
archive there, you shouldn't have any problems.  I don't see how .d 
files can move from your machine to the autobuilder unless you added 
them to the archive.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Versioning of KVM

[Baruch Even]

* Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [061115 10:00]:
> Baruch Even wrote:
> 
> 
> >>My current tree has fixes for most of the problems.  I'll look at the clean targets (why are they necessary for packaging?)
> >>    
> >
> >Some of the packages are being built by other computers, I'm building on
> >my machine only the i386 version and the amd64 is built by an
> >auto-builder. The clean target is needed since otherwise there are the
> >.d files which have absolute paths for my machine and my build
> >environment, this will kill the auto builder. In my case I build for
> >Debian testing on my machine and then use a chroot to do a clean build
> >for Debian unstable, the .d files killed the chroot build as well.
> >
> >The Debian build process does a clean before it starts the build to make
> >sure we do a pristine build every time to avoid such problems. It
> >doesn't always work when upstream clean target doesn't really clean.
> >Normally there is a clean target and distclean to really clean the
> >package back to distribution state.
> >
> >  
> 
> I don't understand.  If you start from an empty directory and unpack the archive there, you shouldn't have any problems.  I don't see how .d files can move from 
> your machine to the autobuilder unless you added them to the archive.

You assume that I was able to do the change I needed in exactly one
take. The problem starts when there is an iterative process that only
after several tries you get to a working package. In that case there are
left overs from former builds, these left overs become part of the
Debian .diff.gz and are part of the Debian packaging.

Cheers,
Baruch

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV