Re: [review] waagent: Windows Azure Linux Agent (part1)
On Thu, 06 Dec 2012 10:08:22 +0100
Arnaud Patard (Rtp) <firstname.lastname@example.org> wrote:
> > Yes, let's add "5.Debian 6.0+" :-)
> no, wheezy+. I really doubt that there's enough stuff on kernel side to
> have things working on squeeze.
>> >> 3.Suse (SLES) 11SP2+
SLES11 is shipped with Linux kernel 2.6.32, it's same as Squeeze.
So I thought Debian 6.0 is okay. But SLES11 "SP2" is 3.0.10.
Yes, probably you're right. It should be Wheezy+.
Anyway, let's ask to upstream to add Debian :)
> Well, it's upstream README. The example can be extracted but I'm not
> sure it's usefull. In most cases, one should only install the agent and
> there's nothing else to do.
Yes, its upstream one but proposal for upstream to improving is good
thing, IMO. And I said in previous mail, handling .conf file in post/pre
script is not good habit.
> This version of the agent has been taken from github before that any
> versionning scheme has been choosen by upstream (it's from 6th of june
> and 1.1 has been released on the 9th of november). I've made a 1.1-1
> yesterday and will update it when the 1.2 is there.
> In fact, I'm not even sure that the current changelog entries should be
> kept before uploading to the archive so it'll be 1.1-1 or 1.2-1 with the
> usual "Initial release (Closes: )" line.
You don't need to keep current changelog entries.
If you want to keep it, then version should be with epoch like 1:1.1-1.
> > and don't specify "testing", you should set "unstable" or "experimental"
> > if you don't have special reason (i.e. release managers ask you)
> I know. It's testing because my repo is for testing. It'll be fixed
> before uploading in the archive.
Okay, but stay to set "unstable" is good manner in that case.
> > Please submit ITP request to BTS and get its number, then put it as (Closes: #nnnnnn)
> will do today.
> oh. I meant debian/* but not patches. It'll be empty soon so I have not
> taken it into account. I'll add an entry for debian/patches to make
> things clearer.
Yes, most of packagers think so, but debian/* matches debian/patches/* .
It'll cause unnecessary misunderstanding, and applying same license as
upstream can avoid it by default.
Hideki Yamane henrich @ debian.or.jp/org