Charles Plessy writes:
> I can try prepare a patch for the Policy if you are interested.
That would be great here. The current text doesn't reflect reality, so
unless we're going to change reality (for which there doesn't appear to be
much of a consensus), we should change Policy.
--
Russ All
Le Sat, Jan 31, 2009 at 10:15:15AM +0100, Raphael Hertzog a écrit :
>
> Note that this decision has been taken because:
> - dpkg-source has never used debian/substvars as input and did nothing
> unless you gave the -T option
> I hope my answer clarifies the situation. Given that it has not been
Roger Leigh writes:
> The .dsc file is exactly where the information is read from. See
> fetch_source_files() in Sbuild/Build.pm. This is for installing
> and removing build-dependencies and build-conflicts, respectively.
> Note that dpkg-buildpackage and other tools read debian/control
> to ch
On Fri, Jan 30, 2009 at 06:50:05PM +0100, Stefano Zacchiroli wrote:
> On Fri, Jan 30, 2009 at 09:00:46AM -0800, Russ Allbery wrote:
> > However, while build dependency information is copied into the *.dsc
> > file, my understanding is that it's not read from that file for
> > package builds.
>
> .
On Fri, 30 Jan 2009, Adam D. Barratt wrote:
> I'd guess Charles meant the following addition to
> README.feature-removal-schedule, from the dpkg source package:
>
> What: substvars support in dpkg-source and dpkg-genchanges
> Status: deprecated
> When: lenny+1
> Warning: program
> Why:
> substvar
Charles Plessy writes:
> Le Fri, Jan 30, 2009 at 09:00:46AM -0800, Russ Allbery a écrit :
>> What this is saying is that substvars will be expanded by those three
>> programs when generating the *.dsc, the *.changes, and the binary
>> control files. However, while build dependency information is
Le Fri, Jan 30, 2009 at 09:00:46AM -0800, Russ Allbery a écrit :
>
> What this is saying is that substvars will be expanded by those three
> programs when generating the *.dsc, the *.changes, and the binary control
> files. However, while build dependency information is copied into the
> *.dsc fi
"Adam D. Barratt" writes:
> I'd guess Charles meant the following addition to
> README.feature-removal-schedule, from the dpkg source package:
>
> What: substvars support in dpkg-source and dpkg-genchanges
> Status: deprecated
> When: lenny+1
> Warning: program
> Why:
> substvars do not make sen
On Fri, 2009-01-30 at 09:00 -0800, Russ Allbery wrote:
> Charles Plessy writes:
> > In reality, it is an endangered mechanism, as it was deprecated in
> > January 2008.
>
> I'm not sure what you're referring to here.
I'd guess Charles meant the following addition to
README.feature-removal-schedu
On Fri, Jan 30, 2009 at 09:00:46AM -0800, Russ Allbery wrote:
> However, while build dependency information is copied into the *.dsc
> file, my understanding is that it's not read from that file for
> package builds.
... while it could be, right?
(question to the buildd / sbuild gurus)
This diffe
Charles Plessy writes:
> Well, according to the Policy sections 5.2 and 4.10, it (should ? must?)
> work.
Policy 5.2:
These fields are used by dpkg-gencontrol to generate control files for
binary packages (see below), by dpkg-genchanges to generate the
.changes file to accompany the
Hi again,
>> At the beginning I thought that skipping the depandancy needed for build-time
>> tests was a logical extension, but now we all agree that it is useless. For
>> the
>> factorisation of the package list between Depends and Build-Depends, I will
>> solve this in my packages with a dpkg
* Charles Plessy [Wed, 28 Jan 2009 14:39:59 +0900]:
> At the beginning I thought that skipping the depandancy needed for build-time
> tests was a logical extension, but now we all agree that it is useless. For
> the
> factorisation of the package list between Depends and Build-Depends, I will
> s
Le Tue, Jan 27, 2009 at 09:53:00AM +0100, Adeodato Simó a écrit :
>
> No, not really. My point is: "*some* of the people whose packages have
> binary stanzas in debian/control which contain the correct set of binary
> dependencies at the beginning of the build, are unhappy about having to
> write
* Lucas Nussbaum [Mon, 26 Jan 2009 23:40:24 +0100]:
> OK. Your point is:
> In most cases, the binary stanzas in debian/control will contain the
> correct set of binary dependencies at the beginning of the build.
No, not really. My point is: "*some* of the people whose packages have
binary sta
On 26/01/09 at 23:08 +0100, Adeodato Simó wrote:
> * Lucas Nussbaum [Mon, 26 Jan 2009 22:51:24 +0100]:
>
> > On 26/01/09 at 19:26 +0100, Adeodato Simó wrote:
> > > * Lucas Nussbaum [Mon, 26 Jan 2009 19:21:54 +0100]:
>
> > > > It's a chicken-and-egg problem: binary deps are not known until
> > > >
* Lucas Nussbaum [Mon, 26 Jan 2009 22:51:24 +0100]:
> On 26/01/09 at 19:26 +0100, Adeodato Simó wrote:
> > * Lucas Nussbaum [Mon, 26 Jan 2009 19:21:54 +0100]:
> > > It's a chicken-and-egg problem: binary deps are not known until
> > > you build the binary package...
> > That is simply not true,
On 26/01/09 at 19:26 +0100, Adeodato Simó wrote:
> * Lucas Nussbaum [Mon, 26 Jan 2009 19:21:54 +0100]:
>
> > It's a chicken-and-egg problem: binary deps are not known until
> > you build the binary package...
>
> That is simply not true, and not the case with many of our interpreted
> languages.
* Lucas Nussbaum [Mon, 26 Jan 2009 19:21:54 +0100]:
> It's a chicken-and-egg problem: binary deps are not known until
> you build the binary package...
That is simply not true, and not the case with many of our interpreted
languages.
--
Adeodato Simó dato at
On 26/01/09 at 19:15 +0100, Adeodato Simó wrote:
> * Mike Hommey [Mon, 26 Jan 2009 19:13:10 +0100]:
>
> > On Mon, Jan 26, 2009 at 06:52:00PM +0100, gregor herrmann wrote:
> > > On Mon, 26 Jan 2009 08:44:01 +0100, Stefano Zacchiroli wrote:
>
> > > > Personally, I'd add as a condition for this to b
On Mon, Jan 26, 2009 at 19:13, Mike Hommey wrote:
> On Mon, Jan 26, 2009 at 06:52:00PM +0100, gregor herrmann wrote:
>> Are around 1200 arch:any libfoo-perl packages enough? They usually
>> duplicate the run-time dependencies in B-D-I for the tests
>
> OT, but why do they need to *duplicate* these
* Mike Hommey [Mon, 26 Jan 2009 19:13:10 +0100]:
> On Mon, Jan 26, 2009 at 06:52:00PM +0100, gregor herrmann wrote:
> > On Mon, 26 Jan 2009 08:44:01 +0100, Stefano Zacchiroli wrote:
> > > Personally, I'd add as a condition for this to be a reasonable
> > > request, the fact that there should be e
On Mon, Jan 26, 2009 at 06:52:00PM +0100, gregor herrmann wrote:
> On Mon, 26 Jan 2009 08:44:01 +0100, Stefano Zacchiroli wrote:
>
> > Personally, I'd add as a condition for this to be a reasonable
> > request, the fact that there should be enough packages with enough
> > test-only dependencies, w
On Mon, 26 Jan 2009 08:44:01 +0100, Stefano Zacchiroli wrote:
> Personally, I'd add as a condition for this to be a reasonable
> request, the fact that there should be enough packages with enough
> test-only dependencies, which I'm not convinced it is the case.
Are around 1200 arch:any libfoo-pe
On Mon, 26 Jan 2009, Stefano Zacchiroli wrote:
> On Mon, Jan 26, 2009 at 09:59:04AM +0100, Lucas Nussbaum wrote:
> > The goals of "nocheck" are different, and more useful, are bypassing
> > the test suite allows faster builds in all cases.
>
> The goals of Build-Depends-Test are the same of "noche
On Mon, Jan 26, 2009 at 09:59:04AM +0100, Lucas Nussbaum wrote:
> What is the real goal of adding Build-Depends-Test: ?
[ Note that I'm not pushing for that, but still, for the sake of the
argument ... ]
> The goals of "nocheck" are different, and more useful, are bypassing
> the test suite all
On 26/01/09 at 08:44 +0100, Stefano Zacchiroli wrote:
> On Fri, Jan 23, 2009 at 09:12:43PM -0800, Russ Allbery wrote:
> > The upcoming wording doesn't add a way to distinguish between build
> > dependencies required for the build and ones required for testing.
>
> I think that was already clear to
On Fri, Jan 23, 2009 at 09:12:43PM -0800, Russ Allbery wrote:
> > In addition, I thought that the 'notest' build option that was discussed
> > last year (or the year before?) on this list made it into the Policy,
> > but I was wrong.
>
> nocheck will be in 3.8.1 (see Bug#416450), but it doesn't re
Charles Plessy wrote:
> I felt a bit afraid that in some
> situations where some packages are temporarly mutually incompatible, we can
> end
> up in a situation where the source package that depends on it is not
> rebuidable
> unless the tests are disabled.
I found this kind of situation when pa
Charles Plessy writes:
> In addition, I thought that the 'notest' build option that was discussed
> last year (or the year before?) on this list made it into the Policy,
> but I was wrong.
nocheck will be in 3.8.1 (see Bug#416450), but it doesn't really address
your issue.
> Maybe I overvaluate
Dear Stefano, Adeodato and Noah, thank you for your answers.
Indeed, I wrote my previous mail after packaging half a dozen of perl modules,
plus enabling tests in a python package. For compiled programs, the situation
is definitely more simple. However, as Stefano noted, there may be sometimes
mor
On Fri, Jan 23, 2009 at 08:24:41PM +0100, Vincent Bernat wrote:
> > What about providing a test target in debian/rules and hooking into this
> > automatically with pdebuild. You should be able to run tests from within the
> > chroot without having to modify your debian/control file.
>
> One of the
OoO Lors de la soirée naissante du vendredi 23 janvier 2009, vers 18:55,
Noah Slater disait :
> What about providing a test target in debian/rules and hooking into this
> automatically with pdebuild. You should be able to run tests from within the
> chroot without having to modify your debian/con
What about providing a test target in debian/rules and hooking into this
automatically with pdebuild. You should be able to run tests from within the
chroot without having to modify your debian/control file.
--
Noah Slater, http://tumbolia.org/nslater
--
To UNSUBSCRIBE, email to debian-devel-r
* Charles Plessy [Fri, 23 Jan 2009 14:53:59 +0900]:
> Dear all,
> I packaged a lot programs that have a test suite, and realised that,
> in order to run it after build, the dependancies of the binary package
> produced must be present as well.
I think you've brought up this in the past already,
On Fri, Jan 23, 2009 at 02:53:59PM +0900, Charles Plessy wrote:
> I packaged a lot programs that have a test suite, and realised that, in order
> to run it after build, the dependancies of the binary package produced must be
> present as well. For the moment, I add them in Build-Depends(-Indep), bu
Dear all,
I packaged a lot programs that have a test suite, and realised that, in order
to run it after build, the dependancies of the binary package produced must be
present as well. For the moment, I add them in Build-Depends(-Indep), but this
is not satisfactory, because:
- The build dependanc
37 matches
Mail list logo
