[Pkg-mozext-maintainers] RFS: stylish/1.3.1+git20130115-1 [ITP]

[Dmitry Smirnov]

On Fri, 1 Feb 2013 03:22:46 Benjamin Drung wrote:
> > > 1) get-orig-source generates a tarball that differs in the
> > > stylish/ChangeLog file.
> > [...]
> The problem is that the generated ChangeLog differs (diff attached) and
> that causes dpkg-source to complain. I prefer to have a get-orig-source
> rules that is reproducible.

I see... I corrected it, please have a look:

http://mentors.debian.net/debian/pool/main/s/stylish/stylish_1.3.1+git20130116-1.dsc

(repository is updated as well).

Lesson learned.


> 
> Weird sorting? I sorts the stuff alphabetical.

Yep, alphabetical sorting is sometimes not ideal.

For example I prefer debhelper on top, followed by package dependencies on the 
same line, followed by alphabetically sorted upstream dependencies one per 
line. 
wrap-and-sort is no help but disruption for this layout not to mention the 
fact that using this tool is (still) unsafe.


> > As you can see "strange formatting" is intentional and VCS-friendly.
> > What's the problem?
> 
> I find it strange to have a line beginning with a comma followed by the
> build dependency. When wrapping stuff in the normal language, you put
> the comma after the word and then wrap the line.

Well if "strange" is not a problem then let's move on please. :)

Comma in front allows to change exactly one line when adding/removing 
dependency. This is nicer for VCS and quite human-readable as well.

Alternative would be to use trailing comma after last package but it outrage 
some people for whatever reason and I reasonably expect that you wouldn't like 
it as well. ;)


> You have "debhelper (>= 9), mozilla-devscripts" on one line, but then
> only one build dependency listed per line.

Exactly. That's the way I want it to be quite deliberately. 


> > You meant "mozilla-devscripts (>= 0.22~)" right?
> 
> Yes.
> 
> > Perhaps that's unnecessary as we have 0.23 in stable.
> 
> Having someone trying to build the package with a too old
> mozilla-devscripts is very unlikely, but not impossible.

Of course but IMHO we can safely ignore the small probability that whoever 
tries to build it in oldstable will run into problems because of this.

> > 
> > I prefer to leave as is.
> 
> Okay.

Thank you.

> 
> > > 4) Why do you set --max-parallel=4 in debian/rules?
> > 
> > Safety. Once I had experience with FTBFS on 6 cores when it was all fine
> > on 4 cores. I can't attempt to build on more than 4 cores so I limited
> > to known/proven/working configuration that I actually tested. Perhaps
> > too paranoid in this case but you never know and it's better to be safe
> > than sorry...
> 
> Having a FTBFS on six core is a strong indicator for a race condition.
> Restricting the number of parallel jobs can work around the issue, but
> is no fix in such cases.

I only experienced it once on fairly big package that I built perhaps ~200 
times on 4 cores but my sponsor never could build it on 6 cores until we 
addressed the issue with --max-parallel=4. I don't know if it was a race 
condition or not. I'm not sure how to troubleshoot it either as I can't even 
reproduce therefore limit make sense as long as it addresses the problem.

Cheers,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B