On 2009-10-29, Goswin von Brederlow wrote:
> Philipp Kern writes:
>> On 2009-10-29, Goswin von Brederlow wrote:
>>> We just had a similar issue (Architecture: linux-any) on irc yesterday
>>> and the outcome was that linux-any will only work post squeeze because
>>> the buildd need to grog that s
On Tue, Oct 27, 2009 at 03:06:07PM +0100, Joerg Jaspert wrote:
> As there are certain lintian tags that should only appear in very rare
> cases we have created two categories. The first is named "warning", tags
> The second category is named "error" and the tags listed can not be
> overridden. Tho
On Fri, Oct 30, 2009 at 12:33:37AM +0100, Frank Lin PIAT wrote:
> Since the proof of concept was fairly well accepted, I intend to polish
> my script a little bit before submitting it.
Pretty cool, thanks for the status update. BTW, do we have a bug report
where the progress of this can be tracked
Kalle Kivimaa wrote:
> the special cases are needed? debian/rules is a specific interface for
> Debian building, why are you using that same interface for other
> purposes?
It's just because we believe this is the easiest to use and easiest to
maintain way to do this:
Build a standard vdr-plugin
[...]
>
> Build a development version of the vdr-plugin-* package from the same
> source, but using the API of the development version of VDR and with a
> different binary package name:
>
> SPECIAL_VDR_SUFFIX=devel dpkg-buildpackage -tc -uc -us -rfakeroot
>
> This way it works out-of-the-box wi
* Tobi [091030 10:55]:
> From our point of view this is so easy to do and so easy to maintain (it's
> working quite well for over 2 years now), that this very specific
> requirement of the policy just seems to be a useless piece of bureaucratic
> over-specificiation.
That is your point of view. F
On Tue, Oct 27, 2009 at 05:51:12PM -0700, Ryan Niebur wrote:
> I prefer "Author(s)". Less text to update when a new author is
> added. It does no harm and affects nothing in the end result. I'm
> curious as to why you think "Author(s)" is a bad thing?
It's the sort of thing you get in automatical
On Wed, Oct 28, 2009 at 09:37:53AM +0100, Jan Hauke Rahm wrote:
> On Tue, Oct 27, 2009 at 07:42:21PM -0700, Russ Allbery wrote:
> > Please note that the intention of the Lintian tag is not to complain
> > about people using "Author(s)", but to catch people who have used
> > dh-make and then never c
Michael Tautschnig schrieb:
I think Manoj already explained quite well why policy is that specific about a
single line.
And I explaind why the policy is over specific in this case :-)
The modified shebang line didn't had any drawback in the past and
wouldn't have any drawback in the future.
> Build a standard vdr-plugin-* package:
> dpkg-buildpackage -tc -uc -us -rfakeroot
> Build a development version of the vdr-plugin-* package from the same
> source, but using the API of the development version of VDR and with a
> different binary package name:
> SPECIAL_VDR_SUFFIX=devel dpkg-buil
On Thu, 29 Oct 2009, Kees Cook wrote:
> On Thu, Oct 29, 2009 at 10:01:08PM -0200, Henrique de Moraes Holschuh wrote:
> > On Tue, 27 Oct 2009, Kees Cook wrote:
> > > On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > > > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> >
On Fri, Oct 30 2009, Tobi wrote:
> Michael Tautschnig schrieb:
>
>> I think Manoj already explained quite well why policy is that specific about
>> a
>> single line.
>
> And I explaind why the policy is over specific in this case :-)
No. You opined that the policy is over specific, but w
Manoj Srivastava schrieb:
1. SPECIAL_VDR_SUFFIX=devel make -f debian/rules build
2. make -f debian/rules SPECIAL_VDR_SUFFIX=devel build
3. SPECIAL_VDR_SUFFIX=devel ./debian/rules build
4. ./debian/rules SPECIAL_VDR_SUFFIX=devel build
Giving you differing results is confusing enough to anyo
On Fri, Oct 30 2009, Tobi wrote:
> Manoj Srivastava schrieb:
>
>> 1. SPECIAL_VDR_SUFFIX=devel make -f debian/rules build
>> 2. make -f debian/rules SPECIAL_VDR_SUFFIX=devel build
>> 3. SPECIAL_VDR_SUFFIX=devel ./debian/rules build
>> 4. ./debian/rules SPECIAL_VDR_SUFFIX=devel build
>> Giving
Package: wnpp
Severity: wishlist
Owner: Debian PhotoTools Maintainers
* Package name: darktable
Version : 0.3
Upstream Author : Johannes Hanika
* URL : http://darktable.sourceforge.net/
* License : GPL3 or later
Programming Lang:
Description : virtual
Stefano Zacchiroli wrote:
> On a second read of the proposal, it occurred to me (and a handful of
> other DDs in private communications agreed) that the above naming choice
> of "warning" and "error" can be a bit unfortunate. In fact, lintian
> already has its own notion of warning/error and hav
Stefano Zacchiroli writes:
> On a second read of the proposal, it occurred to me (and a handful of
> other DDs in private communications agreed) that the above naming choice
> of "warning" and "error" can be a bit unfortunate. In fact, lintian
> already has its own notion of warning/error and ha
Package: wnpp
Severity: wishlist
Owner: Paul Brossier
* Package name: raul
Version : 0.5.1
Upstream Author : Dave Robillard
* URL : http://drobilla.net/software/raul/
* License : GPL-2
Programming Lang: C++
Description : real time audio utility library
Package: wnpp
Severity: wishlist
Owner: Paul Brossier
* Package name: flowcanvas
Version : 0.5.1
Upstream Author : Dave Robillard
* URL : http://drobilla.net/software/flowcanvas/
* License : GPL-2
Programming Lang: C++
Description : interactive widget
[ I haven't looked the vdr-* source; apologies if I miss something
essential. ]
Tobi wrote:
> Personally I think debian/rules shouldn't be restriked to make.
What happens if you do `./debian/rules -p | less'? Although seldom
needed, that's a useful thing when you have to debug the build syste
Package: wnpp
Severity: wishlist
Owner: Ludovic Aubry
Package name: spyder
Version : 1.0.1
Upstream Author : Pierre Raybaut
URL : http://code.google.com/p/spyderlib/
License : MIT
Programming Lang: Python
Description : Spyder is a Python developm
Manoj Srivastava writes:
> I think it would be a good idea to _add_ to policy a rule that
> says that "make -f debian/rules" and "./debian/rules" must behave
> identically, to prevent confusion, and to promote reproducibility, and
> conform to the principle of least surprise.
Rather
Ben Finney writes:
> Manoj Srivastava writes:
>
> > I think it would be a good idea to _add_ to policy a rule that
> > says that "make -f debian/rules" and "./debian/rules" must behave
> > identically, to prevent confusion, and to promote reproducibility, and
> > conform to the prin
Le Fri, Oct 30, 2009 at 09:35:58AM -0500, Manoj Srivastava a écrit :
>
> The interface definition behind this is:
That ‘make -f debian/rules’ is not present anywhere in the Policy demonstrates
it is not the interface.
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, emai
On Fri, Oct 30 2009, Ben Finney wrote:
> Ben Finney writes:
>
>> Manoj Srivastava writes:
>>
>> > I think it would be a good idea to _add_ to policy a rule that
>> > says that "make -f debian/rules" and "./debian/rules" must behave
>> > identically, to prevent confusion, and to promot
On Fri, Oct 30 2009, Russ Allbery wrote:
> Stefano Zacchiroli writes:
>
>> On a second read of the proposal, it occurred to me (and a handful of
>> other DDs in private communications agreed) that the above naming choice
>> of "warning" and "error" can be a bit unfortunate. In fact, lintian
>> a
26 matches
Mail list logo
