Control: tags -1 - wontfix
Control: severity -1 serious

On 31 Jan 2017, at 12:41, Thorsten Glaser <t...@mirbsd.de> wrote:
> 
> James Clarke dixit:
> 
>> Your mail server rejected my message (again). My guess is you didn't get the
>> message from the mailing list because it saw it was already addressed to you.
> 
> Ah, okay. (My mailserver does not reject properly sent messages
> after passing greylisting, except for servers on a blacklist,
> which the ones you use aren’t on.)

I don't have problems sending to anyone else. I use Google's SMTP server for
sending my messages, but SPF should be correctly set up.

>>> I disagree that --build is a command; it is an option that expects
>>> an argument (the .dsc file).
>>> 
>>> Please revert this!
>> 
>> What's your reasoning? This was never officially supported. Ever. Just give 
>> the
> 
> If for no other reason, then for, that cowbuilder is invoked by
> other tools, and such a breaking change ought to not be uploaded
> less than two weeks before the hard freeze.
> 
>> command first, like everyone has always had to do for pbuilder. And yes 
>> --build
>> *is* a command; it says so in the manpage[0]. Whether or not *you* think it 
>> is
> 
> The manpage of 0.83 says so:
> 
>       --build .dsc-file
> 
>> is irrelevant. All it takes is for you to change the order of the arguments 
>> you
>> give to your c script.
> 
> This is not very helpful. Do I reorder --build first, or the
> entirety of --build .dsc-file – after all, --build was always
> documented as requiring an argument (and has option format!),
> yet your changelog entry says something about parsing it now
> separately, which WILL break existing users.

Ok, so, on re-reading 0.83's manpage, it's actually wrong; --build never took
an argument directly. However, by virtue of getop_long, you could put the dsc
anywhere in the arguments; the following all worked:

> cowbuilder --build foo.dsc --option
> cowbuilder --build --option foo.dsc

> cowbuilder --option1 --build foo.dsc --option2
> cowbuilder --option1 --build --option2 foo.dsc


However, given that I did not notice the "--build .dsc-file" bit when I first
re-read it, I have changed my mind and will allow the old style to work. This
*will* give a deprecation warning though, and I intend to remove it during the
Buster release cycle; is that ok for you? I don't want to support this forever
as I can give better error messages without this backwards-compatibility. It
will also remain undocumented in the manpage.

Regards,
James

Reply via email to