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

[Benjamin Drung]

Am Freitag, den 01.02.2013, 04:21 +1100 schrieb 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.

Removing %d from git log would avoid such kind of Changelog differences.

> > 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.

I recommend to run it in a VCS and then "git diff" the changes before
committing.

> > > 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. ;)

A trailing comma after the last package is even worse.

> > 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.

So I think it makes sense to remove that restriction from the stylish
package.

I have uploaded your package and tagged the git revision.

-- 
Benjamin Drung
Debian & Ubuntu Developer