Re: Environment variables, debian/rules and dpkg-buildpackage

[Manoj Srivastava]

On Mon, May 04 2009, Guillem Jover wrote:

> I'll try to summarize the discussion (althought it might be biased to
> my preferred option) and some facts, so that we can get to a conclusion:

+1

I agree with almost everything said in this email.

manoj
-- 
What use is your matted hair, you fool? What use is your antelope skin?
You are tangled inside, and you are just making the outside pretty. 394
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: make-kpkg and 2.6.29.2 vanilla sources

[Raffaele Morelli]

Thank you all, I should read changelogs..

regards
-r

Re: Environment variables, debian/rules and dpkg-buildpackage

[Andrew McMillan]

On Mon, 2009-05-04 at 07:35 +0200, Guillem Jover wrote:
> 
> On Fri, 2009-03-13 at 21:04:30 +0100, Raphael Hertzog wrote:
> > we have an unfortunate situation where the practice in dpkg-buildpackage
> > and the policy do not match fully.

...


> So I think for next dpkg upload we should make dpkg-buildpackage stop
> setting any flags by default, and switch the setting to go through the
> command line arguments to override the package options instead of the
> environment, so this would become the user override part. The
> DEB_VENDOR env var should not be set either, and we should work on
> getting a dpkg-vendor instead, before people try to start using the
> variable.
> 
> 
> Then if we get consensus that this is the righ path, agree on the
> makefile names (as once decided it will be a pain to change later on
> in all packages), we'll need to ship the distro defaults file
> somewhere and start fixing packages to include that makefile. The
> files could look something like:
> 
> ,-- /usr/share/dpkg/build-options.mk
> # distro defaults
> FOO := distro
> 
> -include /etc/dpkg/build-options.mk
> `--
> 
> ,-- /etc/dpkg/build-options.mk
> # site overrides
> #FOO := site
> `--
> 
> ,-- debian/rules
> -include /usr/share/dpkg/build-options.mk
> 
> # package overrides
> FOO := pkg
> `--
> 
> ,-- command line
> # user overrides
> $ make -f debian/rules FOO=cmd


That was really a very well-spent two months!

+1 from me :-)

Regards,
Andrew.


andrew (AT) morphoss (DOT) com+64(272)DEBIAN
You will be advanced socially, without any special effort on your part.




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

Bug#526936: ITP: formalchemy -- auto-generation and customizable form fields from SQLAlchemy mapped classes

[Arnaud Fontaine]

Package: wnpp
Owner: Arnaud Fontaine 
Severity: wishlist

* Package name: formalchemy
  Version : 1.2
  Upstream Author : Alexandre Conrad 
* URL : http://formalchemy.googlecode.com
* License : MIT
  Programming Lang: Python
  Description : auto-generation and customizable form fields from 
SQLAlchemy mapped classes

FormAlchemy  greatly speeds development  with SQLAlchemy  mapped classes
(models)  in a  HTML forms  environment.  It also  provides support  for
CouchDB and a Pylons administration interface.

FormAlchemy eliminates  boilerplate by autogenerating  HTML input fields
From a given model. FormAlchemy will try to figure out what kind of HTML
code  should be  returned by  introspecting the  model's  properties and
generate  ready-to-use   HTML  code   that  will  fit   the  developer's
application.

Of course,  FormAlchemy can't figure out everything,  i.e, the developer
might want  to display only  a few columns  from the given  model. Thus,
FormAlchemy is also highly customizable.


This package will be packaged as part of the python-modules debian team.

Regards,
Arnaud Fontaine


pgpETFQ2pIg6k.pgp
Description: PGP signature

Re: Environment variables, debian/rules and dpkg-buildpackage

[Bernd Zeimetz]

Guillem Jover wrote:
> [ BCCed debian-dpkg for the proposed dpkg changes. ]

> * Lots of packages (roughly around 4k) do not honour env vars for build
>   flags, as they follow the examples from policy (or dh-make and similar)
>   and thus are setting them unconditionally, which env vars do not
>   override.

Not to forget these packages where flags in the environment made the package
FTBFS as they were overriding flags set by makefiles or other build tools by
some default values which did not include all necessary options.


> * We can set the architecture and default flags (from policy) on the
>   makefile to be included, and packagers will be able to do the change
>   and fix any possible problems (progressive opt-in), but once it's
>   included by all packages, then we can do system-wide default changes
>   in the same we change toolchains (mass rebuild, bug filing, change
>   when bug count goes down). The makefile has the advantage that the
>   distro default can be temporarily changed for the mass build w/o
>   needing to totally override the build flags.

You need to take care here to use names which will not clash with variable names
upstream may be using, otherwise you'd add new problems while adding new vars.

> 
> 
> So I think for next dpkg upload we should make dpkg-buildpackage stop
> setting any flags by default, and switch the setting to go through the

Please do so!


+1 from me, too.
Thanks for the good work!


Bernd

-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


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

Re: Environment variables, debian/rules and dpkg-buildpackage

[Raphael Hertzog]

On Mon, 04 May 2009, Guillem Jover wrote:
> env var should not be set either, and we should work on getting a
> dpkg-vendor instead, before people try to start using the variable.

FYI, I already started this.

> start fixing packages to include that makefile. The files could look
> something like:
> 
> ,-- /usr/share/dpkg/build-options.mk
> # distro defaults
> FOO := distro
> 
> -include /etc/dpkg/build-options.mk
> `--

Note that recent changes have aimed at avoiding fork of dpkg by
integrating upstream some distro-specific logic. We should do the same for
this file then... ie accept that external vendors provide us their
defaults and have the dpkg source package pick the right one based on the
current vendor.

> ,-- debian/rules
> -include /usr/share/dpkg/build-options.mk
> 
> # package overrides
> FOO := pkg
> `--

Probably without the leading "-", otherwise we have a risk to not have any
sane default at all. And we should add a build-dependency instead.

Or maybe that choice can be left to the maintainer.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: dpkg-shlibdeps question

[Raphael Hertzog]

On Fri, 01 May 2009, Jiří Paleček wrote:
>> should
>> almost never happen (except diversion) and the result when it happens is
>
> Should I read it as "the only legal situation where it returns multiple  
> packages are diversions (the rest are errors)" or "the majority of  
> situations ... are diversions", ie. does it make sense to return multiple 
> packages in the absence of diversions?

dpkg -S can return multiple packages for directories too since they can be
shared by many packages but in the case of real files AFAIK it can only
happen with diversions.

> Yes, but I think this is unattainable. Especially when doing transitions, 
> you're not likely to have both packages in sync.

I don't see why it would be so difficult. Diverting a file means that you
have a drop-in replacement and I don't see why you couldn't provide
dependencies that are compatible (even if not exactly the same).

> I just wanted to know if it would be OK for dpkg-shlibdeps to use only 
> one package for a library (eg. in case of diversions, use dpkg-divert to 
> find the right one) and fail in case of ambiguity.

What is the right one, the non-diverted one ?

I think it would be ok for dpkg-shlibdeps to choose the right package
based on some clearly-documented criteria. I don't think that failing is
a good idea.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: ITP: developers-reference-es -- Spanish translation of the Debian Developers' Reference

[Raphael Hertzog]

On Fri, 01 May 2009, Joerg Jaspert wrote:
> Please let one central developers-reference package built the various
> languages. Which means this should be just another binary package of
> developers-reference and not something own.

That's already the case. Leandro, if you want to contribute a spanish
translation please contribute by way of patches against the SVN repository
and you will quickly be granted write access to the repository.

svn://svn.debian.org/ddp/manuals/trunk/developers-reference

Look at the french translation to see how you can add a spanish one.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Bug#508644: stable-p-u: mdadm 2.6.7.2-2

[Andreas Metzler]

On 2009-05-04 Josselin Mouette  wrote:
[...]
> The appropriate change would be to create a default-mta virtual package
> that is always provided by only one MTA at a time, so you might want to
> work on this solution instead of breaking important packages.

FWIW as previously discussed on debian-devel starting with the lastest
upload (4.69-10) exim4-daemon-light provides default-mta.

This is not very useful until this version has reached squeeze.
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



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

Re: Environment variables, debian/rules and dpkg-buildpackage

[Manoj Srivastava]

On Mon, May 04 2009, Raphael Hertzog wrote:

> On Mon, 04 May 2009, Guillem Jover wrote:

>> ,-- debian/rules
>> -include /usr/share/dpkg/build-options.mk
>> 
>> # package overrides
>> FOO := pkg
>> `--
>
> Probably without the leading "-", otherwise we have a risk to not have
> any sane default at all.

I disagree. Without the leading -, it would make it impossible
 to build on a machine with older dpkg -- and why be unnecessarily
 unfriendly to backporters?

If you want sane defaults, by all means provide sane defaults
 yourself. 

> And we should add a build-dependency instead.

And restrict the machines where the package can be built? I
 think not.

> Or maybe that choice can be left to the maintainer.

This is better than forcing people into restricting the
 platforms where their sources can be built, but still a cop
 out. Guillem's proposal is technically better.

manoj

-- 
You k'n hide de fier, but w'at you gwine do wid de smoke? Joel Chandler
Harris, proverbs of Uncle Remus
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: Packaging ltp selinux tests

[Riku Voipio]

On Mon, Apr 06, 2009 at 10:13:39PM -, Jiri Palecek wrote:
> I'd like to package the selinux tests from the ltp test suite. The tests  
> need a special selinux policy to be loaded and some files to be relabeled.  
> I haven't found any standard way of packaging this, so I made an  
> experimental package (see [1]; it sort of works - not completely, like 10 
> tests out of 30, but that's not an issue now) and I would like to hear your 
> opinion on these issues:

> 1. The package loads the policy on "postinst configure" with semodule -i, is 
> that right? (And did I implement it properly in the scripts?) There were some 
> avc message during package install (semodule was denied access to a terminal 
> with type apt_t), can this be solved?

As long as it fails gracefully is semodule binary is missing or selinux isn't 
enabled.

> 2. The relabeling has to be done manually with fixfiles relabel; is there a 
> way to do it  (and should it be done) automatically?

> 3. The runtime packages depend on selinux-policy-default; should it 
> (alternatively) depend on the other policies too? Would this need a separate 
> policy package?

> 4. Should the policy package be in /usr/share?

I didn't hear any comments for one month on debian-devel, perhaps our selinux 
masters
Russell or Manoj have a word to say? If there still isn't any opinion, I will 
work
on sponsoring the ltp package with selinux tests on weekend.

Cheers,
Riku

> [1]: http://mentors.debian.net/debian/pool/main/l/ltp/


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

mandate build-arch (was Re: Environment variables, debian/rules and dpkg-buildpackage)

[Zack Weinberg]

If we're doing something that ultimately requires modification of
every debian/rules file *anyway*, can we please make
build-arch/build-indep mandatory targets, so that dpkg-buildpackage -B
can *finally* (eight years later!) be changed to call build-arch?

zw
not subscribed to d-devel; please cc:


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

Re: Environment variables, debian/rules and dpkg-buildpackage

[Peter Eisentraut]

On Monday 04 May 2009 08:35:18 Guillem Jover wrote:

I like this proposal.  A small nit:

> ,-- /usr/share/dpkg/build-options.mk
> # distro defaults
> FOO := distro

Please be sure to use

FOO = bar

instead of ":=", unless you have determined that you really wanted ":=".  In 
most cases it won't make a difference, but in some it does, and then it would 
behave contrary to how make usually treats variables.


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

Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?

[Darren Salt]

I demand that Noah Slater may or may not have written...

[snip; in reply to Brett Parker]
> Considering that we're discussing on a mailing list, it's reasonable to
> assume that the common case is replying to the list. Why optimise for, what
> is surely by definition, the uncommon case?

Why *break* the uncommon case by adding/replacing (abusing) Reply-To?

Anyway, reply-to-list is a followup function (or, at least, it is such in all
news/mail software which I've used with mailing lists).

[snip]
-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + RIPA NOTICE: NO CONSENT GIVEN FOR INTERCEPTION OF MESSAGE TRANSMISSION

"He taught us drawing, stretching, and fainting in coils."


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

Bug#526993: ITP: claws-mail-debian-spam-plugin -- Claws-Mail plugin to report spam in Debian mailing lists

[David Paleino]

Package: wnpp
Severity: wishlist
Owner: David Paleino 

* Package name: claws-mail-debian-spam-plugin
  Version : 0.0.1
  Upstream Author : David Paleino 
* URL : to be defined yet :)
* License : GPL-3+
  Programming Lang: C
  Description : Claws-Mail plugin to report spam in Debian mailing lists

  This plugin allows you to report spam in Debian mailing lists, through
  a common API described in the wiki:
http://wiki.debian.org/Teams/ListMaster/ListArchiveSpam
  (see the "Methods to Nominate Spam for the Review-Process" section)

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Environment variables, debian/rules and dpkg-buildpackage

[Manoj Srivastava]

On Mon, May 04 2009, Peter Eisentraut wrote:

> On Monday 04 May 2009 08:35:18 Guillem Jover wrote:
>
> I like this proposal.  A small nit:
>
>> ,-- /usr/share/dpkg/build-options.mk
>> # distro defaults
>> FOO := distro
>
> Please be sure to use
>
> FOO = bar
>
> instead of ":=", unless you have determined that you really wanted ":=".  In 
> most cases it won't make a difference, but in some it does, and then it would 
> behave contrary to how make usually treats variables.

Why, in your opinion, would we want _not_ to use :=? What does
 delayed evaluation buy us?

manoj
 puzzled
-- 
When you live in a sick society, just about everything you do is wrong.
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: Bug#526993: ITP: claws-mail-debian-spam-plugin -- Claws-Mail plugin to report spam in Debian mailing lists

[David Paleino]

On Mon, 4 May 2009 22:45:45 +0200, David Paleino wrote:

> Package: wnpp
> Severity: wishlist
> Owner: David Paleino 
> 
> * Package name: claws-mail-debian-spam-plugin
>   Version : 0.0.1
>   Upstream Author : David Paleino 
> * URL : to be defined yet :)

Ok, my ITPs are being silly in this period, gar!

I mean, the "homepage" is to be defined yet, but the source code is already
available:

  
http://alioth.debian.org/~hanska-guest/claws-mail-debian-spam-plugin_0.0.1.orig.tar.gz

I've also updated the proper page on the wiki:

  http://wiki.debian.org/Teams/ListMaster/ListArchiveSpam/MUAPlugins

David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Environment variables, debian/rules and dpkg-buildpackage

[Peter Eisentraut]

On Monday 04 May 2009 23:53:15 Manoj Srivastava wrote:
> On Mon, May 04 2009, Peter Eisentraut wrote:
> > Please be sure to use
> >
> > FOO = bar
> >
> > instead of ":=", unless you have determined that you really wanted ":=". 
> > In most cases it won't make a difference, but in some it does, and then
> > it would behave contrary to how make usually treats variables.
>
> Why, in your opinion, would we want _not_ to use :=? What does
>  delayed evaluation buy us?

That is up for debate, to some degree, I guess.  I just want to make sure that 
a conscious decision is made either way.  (In my experience, many uses of := 
are made without knowledge about what it does.)

I think delayed evaluation is sort of the default way in which make treats 
variables, and so to avoid surprises and confusion, we should go with that one 
unless there is a specific reason otherwise.

In practical terms, using delayed evaluation makes the outcome mostly 
independent of the order of the assignments.  Which might become quite 
relevant when you design an include-a-bit-here, override-a-bit-there scheme 
that is supposed to be robust against all the nonsense that 1 source 
packages might do with it afterwards.

Also note that someone who wants to be careful not to overwrite values 
supplied elsewhere might use ?=, which creates a delayed expansion type 
variable.

In any case, we should be careful to define and document it one way or the 
other.  Otherwise stuff like

CPPFLAGS += -DFOO=$(BAR)

has unclear behavior, depending on how or whether CPPFLAGS was previously set 
up.  (And note that it will change if initially you don't define CPPFLAGS at 
all and in a later version make a := definition for it -- delayed variables 
being the default.)


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

Bug#527015: ITP: libmath-random-isaac-xs-perl -- XS implementation of ISAAC (see libmath-random-isaac-perl)

[Jonathan Yu]

Package: wnpp
Severity: wishlist
Owner: Jonathan Yu 


* Package name: libmath-random-isaac-xs-perl
  Version : 1.0.3
  Upstream Author : Jonathan Yu 
* URL : CPAN
* License : Public Domain
  Programming Lang: Perl, C
  Description : XS implementation of ISAAC (see libmath-random-isaac-perl)



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

Bug#527017: ITP: libmath-random-tt800-perl -- An implementation of the TT800 PRNG algorithm

[Jonathan Yu]

Package: wnpp
Severity: wishlist
Owner: Jonathan Yu 


* Package name: libmath-random-tt800-perl
  Version : 1.01
  Upstream Author : Otmar Lendl 
* URL : CPAN
* License : Perl (Artistic+GPL)
  Programming Lang: Perl
  Description : An implementation of the TT800 PRNG algorithm



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

Bug#508644: new release goal default-mta? (was: stable-p-u: mdadm 2.6.7.2-2)

[martin f krafft]

[moving debian-rele...@l.d.o to Bcc, continuing discussion in bug log]

also sprach Andreas Metzler  [2009.05.04.1856 
+0200]:
> FWIW as previously discussed on debian-devel starting with the
> lastest upload (4.69-10) exim4-daemon-light provides default-mta.

Excellent. If there are no objections, I'll formulate a squeeze
release goal and file the bugs.

(updated mdadm coming to s-p-u on Thursday, are there other
comments?
http://lists.debian.org/debian-release/2009/05/msg00024.html)

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)