asterisk 1.2.0-0beta1

[Tzafrir Cohen]

On Sun, Oct 02, 2005 at 09:47:28AM +0200, Jose Carlos Garcia Sogo wrote:
> El dom, 02-10-2005 a las 03:21 +0300, Tzafrir Cohen escribió:
> > Hi
> > 
> > I just commited to the svn initial Asterisk 1.2 debian/ dir. It
> > generally seems to work, but still needs some work.
> 
>   OK, only some problems with this commit
>    1. If it is targeted to experimental, it should have gone to
> branches/scud, instead of trunk, to allow newer uploads to unstable

OK. Somehow that point have escaped me when reading the README.

> 
>    2. You have to try to integrate as much as possible changes made in
> unstable. I see a UNRELEASED 1.0.9-6 version, with a dependency in
> adduser 3.64 that was reverted with your commit, and also that
> {asterisk-}gtk-console package was removed from control file, which you
> have enabled agagin.

It is remmed-out, actually.

Also note that the sqlite module is deleted. This is something that I
copied from my spec and now I notice I shouldn't have.

I basically diffed and did copy most of the relevant changes. But maybe
I started to work on it before that package was commited. :-(

> 
>    3. And be cereful with version numbers. 1:1.2.0.dfsg.1-0beta1-1 is
> almost unparsable, but the most important thig is:
>    
>   jose at gimli:~$ dpkg --compare-versions 1:1.2.0.dfsg-1 gt
> 1:1.2.0.dfsg.1-0beta1-1
>   jose at gimli:~$ echo $?
>   1
> 
>   Which means that when we want to upload released 1.2.0, we will have
> to use another trick or mak epoch 2: For example, something as easy as
> 1:1.2.0.beta1.dfsg-1 will work (as final will be 1:1.2.0.dfsg-1 and d >
> b) Anyway, dpkg --compare-versions is your friend in this situations.

I didn't like it either. But I saw it used in the libpri package. What
would you suggest? Also considering that the original tarball will
differ from beta1 to final.

> 
>   I was going to fix this a bit, but first I need to know if this
> release is intended for experimental or not.

Very. I would have given it more polishing if I had not suspected this
would mean yet another week of delay.

-- 
Tzafrir Cohen     icq#16849755  +972-50-7952406
tzafrir.cohen at xorcom.com  http://www.xorcom.com