Re: Lintian based autorejects

[Manoj Srivastava]

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
>> already has its own notion of warning/error and having the naming
>> overloaded by dak messages that are based on lintian outcome can be
>> quite confusing.
>
>> Can you please consider changing the above naming?
>> The first alternative naming that comes to my mind is "non-fatal errors"
>> vs "fatal errors". It is not particularly exciting as a choice, but I
>> believe it would be better than warning/error.
>
> I think that's a good idea, particularly since I suspect that we'll
> upgrade anything in Lintian that's an automatic reject to serious
> severity, which will make most of them errors.

We should also review policy, and make sure that these rejects
 are also linked to must directives in policy.

manoj
-- 
JOB PLACEMENT: Telling your boss what he can do with your job.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Clarify rationale for ‘debian/rules ’ shebang line

[Manoj Srivastava]

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 promote reproducibility, and
>> >   conform to the principle of least surprise.
>>
>> Rather than a new rule, I submit this patch to clarify the existing rule
>> for the shebang line.
>
> I was sloppy in my use of normative language; this is a “must” directive.
>
> === modified file 'policy.sgml'
> --- policy.sgml 2009-10-21 20:49:37 +
> +++ policy.sgml 2009-10-31 01:10:42 +
> @@ -1725,7 +1725,10 @@
> 
>   It must start with the line #!/usr/bin/make -f,
>   so that it can be invoked by saying its name rather than
> - invoking make explicitly.
> + invoking make explicitly. That is, invoking
> + either of make -f debian/rules args...
> + or ./debian/rules args... must cause
> + identical behaviour in each case.
> 
>
> 
>

Seconded.

manoj
-- 
The problem with this country is that there is no death penalty for
incompetence.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian/rules "make -f" restriction

[Charles Plessy]

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, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Clarify rationale for ‘debian/rules ’ shebang line

[Ben Finney]

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 principle of least surprise.
>
> Rather than a new rule, I submit this patch to clarify the existing rule
> for the shebang line.

I was sloppy in my use of normative language; this is a “must” directive.

=== modified file 'policy.sgml'
--- policy.sgml 2009-10-21 20:49:37 +
+++ policy.sgml 2009-10-31 01:10:42 +
@@ -1725,7 +1725,10 @@

  It must start with the line #!/usr/bin/make -f,
  so that it can be invoked by saying its name rather than
- invoking make explicitly.
+ invoking make explicitly. That is, invoking
+ either of make -f debian/rules args...
+ or ./debian/rules args... must cause
+ identical behaviour in each case.

 


-- 
 \ “We can't depend for the long run on distinguishing one |
  `\ bitstream from another in order to figure out which rules |
_o__)   apply.” —Eben Moglen, _Anarchism Triumphant_, 1999 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Clarify rationale for ‘debian/rules’ shebang line (was: debian/rules "make -f" restriction)

[Ben Finney]

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 than a new rule, I submit this patch to clarify the existing rule
for the shebang line.

=== modified file 'policy.sgml'
--- policy.sgml 2009-10-21 20:49:37 +
+++ policy.sgml 2009-10-31 00:59:18 +
@@ -1725,7 +1725,10 @@

  It must start with the line #!/usr/bin/make -f,
  so that it can be invoked by saying its name rather than
- invoking make explicitly.
+ invoking make explicitly. That is, invoking
+ either of make -f debian/rules args...
+ or ./debian/rules args... should cause
+ identical behaviour in each case.

 


-- 
 \ “Listen: we are here on Earth to fart around. Don't let anybody |
  `\  tell you otherwise.” —_Timequake_, Kurt Vonnegut |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#553400: ITP: spyder -- Spyder is a Python development environment specially suited for scientific computing

[Ludovic Aubry]

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 development environment specially suited 
for scientific computing

pyder (previously known as Pydee) is a free open-source Python development 
environment providing
MATLAB-like features in a simple and light-weighted software.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian/rules "make -f" restriction

[Yavor Doganov]

[ 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 system,
especially when it's intercepted with upstream's and things are not
working as one would expect.  (I fixed a bug in a package using this
technique once, so it's not just a hypothetical argument.)

IMHO, the assumption that debian/rules is a makefile (or more
precisely, a GNU makefile) has its deep roots in maintainers' minds.

Personally, I've never associated it with alleged policy bureaucracy,
I've always thought that's simply the *right* thing to do.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#553386: ITP: flowcanvas -- interactive widget for “boxes and lines” environments

[Paul Brossier]

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 for “boxes and lines” environments

 FlowCanvas is an interactive Gtkmm/Gnomecanvasmm widget for “boxes and lines”
 environments (ie modular synths or interactive finite state automata diagrams).



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#553377: ITP: raul -- real time audio utility library

[Paul Brossier]

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

 Raul (Realtime Audio Utility Library) is a C++ utility library primarily aimed
 at audio/musical applications.

(note: raul is needed for patchage 0.4.2-1)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Lintian based autorejects

[Russ Allbery]

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 having the naming
> overloaded by dak messages that are based on lintian outcome can be
> quite confusing.

> Can you please consider changing the above naming?
> The first alternative naming that comes to my mind is "non-fatal errors"
> vs "fatal errors". It is not particularly exciting as a choice, but I
> believe it would be better than warning/error.

I think that's a good idea, particularly since I suspect that we'll
upgrade anything in Lintian that's an automatic reject to serious
severity, which will make most of them errors.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Lintian based autorejects

[Frank Küster]

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 having the naming
> overloaded by dak messages that are based on lintian outcome can be
> quite confusing.

ACK


-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#553359: ITP: darktable -- virtual lighttable and darkroom for photographers

[Bernd Zeimetz]

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 lighttable and darkroom for photographers

 darktable manages your digital negatives in a database and lets you view
 them through a zoomable lighttable. it also enables you to develop raw
 images and enhance them.  It tries to fill the gap between the many
 excellent existing free raw converters and image management tools (such
 as ufraw or f-spot). The user interface is built around efficient
 caching of image metadata and mipmaps, all stored in a database. the
 user will always be able to interact, even if the full resolution image
 is not yet loaded.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian/rules "make -f" restriction

[Manoj Srivastava]

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 you differing results is confusing enough to anyone
>>  building the packages manually (You know, as free software folks, the
>>  buildds are not the sole focus of our packaging) that I think it is
>>  good that the policy is specific enough to block these.
>
> I just don't think this is a problem at all. If you use
> SPECIAL_VDR_SUFFIX=devel, you do this for a reason. It's very specific
> for this  set of packages and without reading the documentation, you
> wouldn't even consider setting SPECIAL_VDR_SUFFIX=devel. And if you
> read the documentation, you know exactly, how to use
> SPECIAL_VDR_SUFFIX.

Oh, I am doing this for the reasons specified. But I have been
 assured by policy that it is a makefile, so I think any of the 4
 commands will give me the super-duper devel version, right?

Wrong!

And that is why this is a horrendous idea.

> In general: IMHO the policy shouldn't force implementation details, it
> should just enforce the interface.

The interface definition behind this is:
 calling make -f debian/rules and ./debian/rules should result in
 identical behaviour,  all other things being equal.  Either invocation
 should deal identically with the environment, and with variables set on
 the command line.

There.

manoj
-- 
Revolution, n.: A form of government abroad.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian/rules "make -f" restriction

[Tobi]

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 anyone
 building the packages manually (You know, as free software folks, the
 buildds are not the sole focus of our packaging) that I think it is
 good that the policy is specific enough to block these.


I just don't think this is a problem at all. If you use 
SPECIAL_VDR_SUFFIX=devel, you do this for a reason. It's very specific 
for this  set of packages and without reading the documentation, you
wouldn't even consider setting SPECIAL_VDR_SUFFIX=devel. And if you 
read the documentation, you know exactly, how to use SPECIAL_VDR_SUFFIX.


In general: IMHO the policy shouldn't force implementation details, it 
should just enforce the interface.


But as I wrote earlier: case closed, everything has been said - we will 
try to come up with another solution to satisfy the policy, even if it 
is uglier and requires some more brain cycles to be understood.


Tobias


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian/rules "make -f" restriction

[Manoj Srivastava]

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 with little
 rationale beyond "I think this is so".

I think that
 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 anyone
 building the packages manually (You know, as free software folks, the
 buildds are not the sole focus of our packaging) that I think it is
 good that the policy is specific enough to block these.

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.

manoj
-- 
Imagine what we can imagine! Arthur Rubinstein
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switch on compiler hardening defaults

[Henrique de Moraes Holschuh]

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:
> > > > > I would like to propose enabling[1] the GCC hardening patches that 
> > > > > Ubuntu
> > > > > uses[2].
> > > > 
> > > > How do they work? Do they also change the free-standing compiler or only
> > > > the hosted one? There is a lot of software, which (I would say) missuse
> > > > the hosted compiler to build non-userspace-code, including the Linux
> > > > kernel.
> > > 
> > > The stack protector is conditional on being linked with libc, so, if you
> > > build with -nostdlib (as the kernel does), it is implicitly disabled.
> > 
> > This doesn't make sense.  The kernel can, and does use stack protector
> > functionality for its built if you ask it to.  Do you mean the defaults are
> > changed only when -nostdlib is NOT given?
> 
> Yes, I was a bit unclear, sorry.  The -fstack-protector option is not
> added to the option list when either -fno-stack-protector or -nostdlib
> are already in the option list.  The GCC spec[1] for this is:

That, and the fact that -fstack-protector-all is NOT used, removes all
objections I might have: it means the kernel build won't be affected, and it
preserves the decisions made by the kernel upstream about which files should
get -fstack-protector and which files shouldn't.

Thanks!

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian/rules "make -f" restriction

[Joerg Jaspert]

> 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-buildpackage -tc -uc -us -rfakeroot
> This way it works out-of-the-box with all the various build tools.

And what is stopping you from doing that with a proper makefile?
You are constantly repeating you need to violate policy for an issue
that is similar easy to achieve while still following the policy.

You can use standard make syntax on deciding if you build a policy
compliant package or if you are going to do mad things to the debian/
before continuing the build, and the actual changes you are doing to
debian/rules seem to be easy enough to also achieve with make checking
for the environment var or not.

-- 
bye, Joerg
A BSP means that many DDs and other mere mortals get together to play
xroach. Sadly, that package was removed from Debian some time ago, so
they have to squash other bugs (preferably RC) instead.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian/rules "make -f" restriction

[Tobi]

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.


But it's not worth discussing this anymore. I think everything was 
said. We will try to find a different way to tackle this problem - it 
just hurts to throw away a nice working solution.


Tobias


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Lintian based autorejects

[Michael Banck]

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 completed the relevant section of the
> > resulting debian/copyright file, which I think we would all agree is
> > an obvious RC bug.
> 
> Yes, so can't we introduce a bogus line in dh-make's default copyright
> file? Something like a trap for lintian? If this is really about
> catching packages where the maintainer forgot to even think about
> debian/copyright, this would work perfectly and probably without false
> positives.

dh_make already inserts "put author's name and email here", I had
guessed that lintian would check for that and error out otherwise, but
if this is not yet the case, maybe it can be added.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Lintian based autorejects

[Mark Brown]

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 automatically generated text where the
programmer hasn't bothered to figure out if something is a plural or not.
Like I say, I don't think it's serious in itself but it seems wishlist.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian/rules "make -f" restriction

[Bernhard R. Link]

* 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. From my point of view it is so horrible a
kludge that I am happy policy is forbidding it explicitly.

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian/rules "make -f" restriction

[Michael Tautschnig]

[...]

> 
> 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 with all the various build tools.
> 

Why don't you provide a script like debian/make-special-rules such that

debian/make-special-rules
dpkg-buildpackage -tc -uc -us -rfakeroot

does the job? I'm sure you already considered this idea, so would you mind
explaining why this does not work? Obviously you can tell your users/developers
that calling this script is required just as you documented the
SPECIAL_VDR_SUFFIX thingy.

> >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.
> 
> We are still thinking about different solutions, not requiring to change
> the shebang line. But as said before - it's not that easy and it will most
> likely increase the complexity of debian/rules. A lot of pain, without a
> gain :-)
> 

[...]

I think Manoj already explained quite well why policy is that specific about a
single line. And apparently thousands of packages adhere to policy in this case,
so it's somewhat dubious that only VDR-related packages cannot cope with it. I
understand that any solution must remain easy to use and of course also easy to
maintain. But a hackish shebang line cannot be the only way to achieve this.

Best,
Michael



pgpXE7xLSaUKN.pgp
Description: PGP signature

Re: debian/rules "make -f" restriction

[Tobi]

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-* 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-buildpackage -tc -uc -us -rfakeroot

This way it works out-of-the-box with all the various build tools.

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

We are still thinking about different solutions, not requiring to change
the shebang line. But as said before - it's not that easy and it will most
likely increase the complexity of debian/rules. A lot of pain, without a
gain :-)

@all: Please don't feel offended because I question the policy here. It's
not because I don't like the policy, it's because I care about it!

Tobias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Submitting bugs for manpage improvements

[Stefano Zacchiroli]

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? If you like the target
package, I suggest to submit a wishlist bug report against devscripts
and keep that bug log posted with updates. (Yes, I'm generally paranoid
about forgetting good stuff :-)

> * I like Simon's patch/idea to handle I18n, and I would like to improve
>   it a bit further.
> * Also the script needs to handle dpkg's alternatives.
> * Last but not least, the script shouldn't discard the diff when
>   somehting fails or reportbug isn't configured.

By the way, does the current script allows (via reportbug) to post a
manpage patch to an already existing bug report? That would be a pretty
nice feature to have.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Lintian based autorejects

[Stefano Zacchiroli]

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. Those are tags corresponding to packaging errors serious

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 having the naming
overloaded by dak messages that are based on lintian outcome can be
quite confusing.

Can you please consider changing the above naming?
The first alternative naming that comes to my mind is "non-fatal errors"
vs "fatal errors". It is not particularly exciting as a choice, but I
believe it would be better than warning/error.

Thanks in advance,
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Can linux-any arch and friends be used?

[Philipp Kern]

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 syntax too and run stable outside the
>>> build chroot.
>> However the newer sbuild uses the tools within the chroot to fetch and work
>> with the packages.  Apart from the fact that Architecture is only read by
>> the build system, no?  (But well, quinn-diff is not adapted to understand
>> this, so it wouldn't be scheduled for building at the moment, but the
>> reason of this are not the buildds.)
> buildd as in wanna-build, quinn-diff, buildd, sbuild and whatever else
> in involved as a whole.
>
> Build-Depends are checked for auto dep-wait-ing packages so the
> problem arises there too, just in revers. One won't build while the
> other won't dep-wait.

Apart from the fact that the dep-wait count went back quite a bit thanks
to BD-Uninstallable, IIRC it should just work because the result of a
linux-any in the .dsc Architectures will result in a arch:any Dep and
thus be listed as such in the Packages file where the dep-waiting acts
upon.  It looks to me that only quinn-diff will need a bit of poking.
(Of course you never know in the current mess, but still.)

Kind regards,
Philipp Kern



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org