[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [review] waagent: Windows Azure Linux Agent (part1)


On Thu, 06 Dec 2012 10:08:22 +0100
Arnaud Patard (Rtp) <arnaud.patard@rtp-net.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

Reply to: