On Mon, Sep 27, 2010 at 02:29:34PM -0700, Russ Allbery wrote:
> Cyril Brulebois writes:
> > Russ Allbery (27/09/2010):
>
> >> The only other proposed solution in the bug was to just require
> >> build-arch/build-indep, and I think that would be more disruptive.
>
> > Do we have numbers here? Fr
Russ Allbery writes:
> Goswin von Brederlow writes:
>
>> Do we need this in debian/control?
>
>> Why not debian/source/options or debian/source/hardening if it is a more
>> special feature that requires extra args?
>
> debian/source so far only contains options that control the generation of
> t
Goswin von Brederlow writes:
> Do we need this in debian/control?
> Why not debian/source/options or debian/source/hardening if it is a more
> special feature that requires extra args?
debian/source so far only contains options that control the generation of
the source package or, in the case o
Russ Allbery writes:
> Raphael Hertzog writes:
>
>> Well, we specified DEB_BUILD_OPTIONS space separated because build flags
>> frequently embed commas. Shall we not take the same decision
>> preemptively here?
>
> Most fields that take multiple values use commas. We do have another that
> take
Raphael Hertzog writes:
> Well, we specified DEB_BUILD_OPTIONS space separated because build flags
> frequently embed commas. Shall we not take the same decision
> preemptively here?
Most fields that take multiple values use commas. We do have another that
takes spaces (Architecture), but I wou
Hi,
On Mon, 27 Sep 2010, Russ Allbery wrote:
> > Well, I don't make it a requirement to implement it right now and the
> > Build-Features code can certainly start with just the build-arch
> > stuff. But I want to make sure we gave it enough thought so that it's
> > not problematic later on to exte
Bernhard R. Link wrote:
> > This smells the same as the /usr/share/doc transition. That took
> > *years* -- and without significant efforts, it would have never finished.
>
> Sorry. Even if that was comparable and thus true, it still means that this
> is by far the superior solution. Only taking y
* Joey Hess [100929 18:33]:
> Bernhard R. Link wrote:
> > There really is no reason to keep build-arch and build-indep optional
> > (the only reason would have been to allow for them becoming widespread
> > on their own and then requiring them once that has no big effect), as
> > every package not
Joey Hess wrote:
> Adding the script to the make package would
> encapsulate the kludge cleanly. If Debian make had this command,
> it should be sufficient for both using build-arch and for half of debhelper's
> needs:
>
> make-first-existing-target target1 target2 [target3 ...]
Implemented
Bernhard R. Link wrote:
> There really is no reason to keep build-arch and build-indep optional
> (the only reason would have been to allow for them becoming widespread
> on their own and then requiring them once that has no big effect), as
> every package not supporting them can support them by a
* Russ Allbery [100928 00:19]:
> Roger Leigh writes:
>
> > Unless I missed it in a previous discussion, I can't see what's wrong
> > with simply mandating support with a new Standards-Version as Bernhard
> > suggested. Could you elaborate on why Build-Features seems preferable
> > since this app
On 2010-09-29 07:26 +0200, Marc Haber wrote:
> On Fri, 24 Sep 2010 15:19:01 -0700, Steve Langasek
> wrote:
>>That is the customary workaround for this issue. The downside is that it
>>causes the build to be run under $rootcmd instead of running as a normal
>>user. Since all buildds are using fa
On Fri, 24 Sep 2010 15:19:01 -0700, Steve Langasek
wrote:
>That is the customary workaround for this issue. The downside is that it
>causes the build to be run under $rootcmd instead of running as a normal
>user. Since all buildds are using fakeroot these days instead of sudo
Does pbuilder supp
On 2010-09-28, Simon Richter wrote:
> The least contentious solution right now would be filing bugs, IMO. All
> that'd need is an autobuilder and a few volunteers to process the
> logs.
If there's a clean plan and working software we can run this on Debian
infrastructure. We're working on provid
Hi,
On Mon, Sep 27, 2010 at 11:01:16AM -0700, Russ Allbery wrote:
> > The not-so-evident part is that I want the syntax of this field to be
> > sufficiently extensible so that we can encode more information like
> > support of hardening build flags and similar stuff that we might want to
> > know
On Mon Sep 27 15:18, Russ Allbery wrote:
> > Unless I missed it in a previous discussion, I can't see what's wrong
> > with simply mandating support with a new Standards-Version as Bernhard
> > suggested. Could you elaborate on why Build-Features seems preferable
> > since this appears to be a sim
On Mon, Sep 27, 2010 at 06:36:38PM -0400, Joey Hess wrote:
> Adam Borowski wrote:
> > # Hairy, but safe against locales and changed error messages.
>
> This fails in cases where the makefile emits something to stderr when
> setting a variable, which can happen even for non-existing rules.
> Makefi
Adam Borowski wrote:
> # Hairy, but safe against locales and changed error messages.
> make -f /dev/null build-indep 2>unique-tmp-1
> (debian/rules build-indep && rm unique-tmp-1) 3>&1 1>&2 2>&3 |tee unique-tmp-2
> cmp -s unique-tmp-1 unique-tmp-2
> case $? in
> 0) echo "The build-indep target do
Raphael Hertzog wrote:
> >From the whole discussion, relying on Standards-Version was not well
> accepted so the only sane way of doing it (and parsing make's output
> is not sane enough for me, even if debhelper does it)
Debhelper can get away with using make -n in one case, and parsing make
-p o
Roger Leigh writes:
> Unless I missed it in a previous discussion, I can't see what's wrong
> with simply mandating support with a new Standards-Version as Bernhard
> suggested. Could you elaborate on why Build-Features seems preferable
> since this appears to be a simple and easily implementabl
On Mon, Sep 27, 2010 at 02:27:20PM +0200, Raphael Hertzog wrote:
> On Mon, 27 Sep 2010, Bernhard R. Link wrote:
> > But this whole discussion got boring something like 10 years ago. It's
> > a shame there is still no proper solution for that now.
>
> Yeah, the only one who submitted code has been
Cyril Brulebois writes:
> Russ Allbery (27/09/2010):
>> The only other proposed solution in the bug was to just require
>> build-arch/build-indep, and I think that would be more disruptive.
> Do we have numbers here? From another mail, it looks like a while
> back, only a minority of packages w
Russ Allbery (27/09/2010):
> The only other proposed solution in the bug was to just require
> build-arch/build-indep, and I think that would be more disruptive.
Do we have numbers here? From another mail, it looks like a while
back, only a minority of packages was affected. Sounds like something
Raphael Hertzog writes:
> On Mon, 27 Sep 2010, Russ Allbery wrote:
>> ...it gets derailed by this feature request for Build-Features, which a
>> lot of people are much more dubious about (myself, for example: I think
>> hardening flags should be handled similarly to parallel build flags,
>> not v
On Mon, 27 Sep 2010, Russ Allbery wrote:
> > The not-so-evident part is that I want the syntax of this field to be
> > sufficiently extensible so that we can encode more information like
> > support of hardening build flags and similar stuff that we might want to
> > know to adjust the behaviour at
Raphael Hertzog writes:
> From the whole discussion, relying on Standards-Version was not well
> accepted so the only sane way of doing it (and parsing make's output is
> not sane enough for me, even if debhelper does it) is to have the
> package explicitly record that it provides the required su
* Raphael Hertzog [100927 14:28]:
> On Mon, 27 Sep 2010, Bernhard R. Link wrote:
> > But this whole discussion got boring something like 10 years ago. It's
> > a shame there is still no proper solution for that now.
>
> Yeah, the only one who submitted code has been Bill Allombert and he did
> it
On Mon, 27 Sep 2010, Bernhard R. Link wrote:
> But this whole discussion got boring something like 10 years ago. It's
> a shame there is still no proper solution for that now.
Yeah, the only one who submitted code has been Bill Allombert and he did
it without following my recommendations so I have
* Joachim Breitner [100926 21:45]:
> Let me rephrase Reinhard:
> what's the problem with requiring the build-arch and build-indep target
> for all packages in debian after squeeze release?
Most packages do not have build-arch and build-indep. (Mostly due to
dh_make not including them for single p
On 09/26/2010 03:45 PM, Joachim Breitner wrote:
> Am Sonntag, den 26.09.2010, 08:50 + schrieb Philipp Kern:
>> On 2010-09-26, Reinhard Tartler wrote:
>>> On Sa, Sep 25, 2010 at 21:59:51 (CEST), James Vega wrote:
No, it builds all the content for arch:all and non-arch:all, but only
cr
Am Sonntag, den 26.09.2010, 08:50 + schrieb Philipp Kern:
> On 2010-09-26, Reinhard Tartler wrote:
> > On Sa, Sep 25, 2010 at 21:59:51 (CEST), James Vega wrote:
> >> No, it builds all the content for arch:all and non-arch:all, but only
> >> creates the non-arch:all binaries. The issue is that
On 2010-09-26, Reinhard Tartler wrote:
> On Sa, Sep 25, 2010 at 21:59:51 (CEST), James Vega wrote:
>> No, it builds all the content for arch:all and non-arch:all, but only
>> creates the non-arch:all binaries. The issue is that there's currently
>> no way for the buildds to say "Only build the no
On Sa, Sep 25, 2010 at 21:59:51 (CEST), James Vega wrote:
> No, it builds all the content for arch:all and non-arch:all, but only
> creates the non-arch:all binaries. The issue is that there's currently
> no way for the buildds to say "Only build the non-arch:all content"
> since the only required
On Sat, Sep 25, 2010 at 11:22:26PM +0400, Dmitry E. Oboukhov wrote:
> JB> The problem is that build-indep and build-arch
> JB> are not required targets, and there is no easy way of checking whether
> JB> they exist.
>
> http://www.us.debian.org/doc/debian-policy/ch-source.html#s-debianrules
>
> =
JB> The problem is that build-indep and build-arch
JB> are not required targets, and there is no easy way of checking whether
JB> they exist.
http://www.us.debian.org/doc/debian-policy/ch-source.html#s-debianrules
=quote
Since an interactive debian/rules script makes it impossible to
auto-compil
Dmitry E. Oboukhov (25/09/2010):
> It seems that Debian doesn't contain all files which are nessesary
> to install Debian in qemu. Could You give me a link to how to
> install debian/armel(etc) in qemu?
qemu-system-$arch + debian-installer-$version-netboot-$arch?
Mraw,
KiBi.
signature.asc
Desc
Hi,
Am Samstag, den 25.09.2010, 17:04 +0200 schrieb Adam Borowski:
> On Sat, Sep 25, 2010 at 03:03:51PM +0200, Joachim Breitner wrote:
> > > Uhm, but shouldn't that massive multi-hour _building_ of data be in a
> > > "build" (specifically, "build-indep") target rather than "install"?
> >
> > one
On Sat, Sep 25, 2010 at 11:26:53AM +0400, Dmitry E. Oboukhov wrote:
> AB> If so, you could build it in qemu.
>
> It seems that Debian doesn't contain all files which are nessesary to
> install Debian in qemu. Could You give me a link to how to install
> debian/armel(etc) in qemu?
While I have no
On Sat, Sep 25, 2010 at 03:03:51PM +0200, Joachim Breitner wrote:
> > Uhm, but shouldn't that massive multi-hour _building_ of data be in a
> > "build" (specifically, "build-indep") target rather than "install"?
>
> one would expect that it works this way, any many people before you were
> surpris
Hi,
Am Samstag, den 25.09.2010, 00:18 +0200 schrieb Adam Borowski:
> On Fri, Sep 24, 2010 at 11:55:32PM +0200, Stéphane Glondu wrote:
> > What about building this architecture:all package only in binary-indep?
> > Like in the attached patch... This way, the buildds won't try to build them.
>
> >
On Sat, Sep 25, 2010 at 00:18:44 +0200, Adam Borowski wrote:
> On Fri, Sep 24, 2010 at 11:55:32PM +0200, Stéphane Glondu wrote:
> > What about building this architecture:all package only in binary-indep?
> > Like in the attached patch... This way, the buildds won't try to build them.
>
> > diff -
>> If this package is built it wants more than one gigabyte (~1.2-1.4G)
>> RAM to build. So there are two buildd servers can't build
>> *architecture:all* packages. So this package can't pass into testing
>> for a long time (more than 120 days).
SG> What about building this architecture:all packa
>> There is one src-package which builds a few packages with architecture
>> -all and -any. http://packages.qa.debian.org/w/wordnet.html
>>
>> If this package is built it wants more than one gigabyte (~1.2-1.4G)
>> RAM to build. So there are two buildd servers can't build
>> *architecture:all* pa
On Fri, Sep 24, 2010 at 11:55:32PM +0200, Stéphane Glondu wrote:
> Le 24/09/2010 22:44, Dmitry E. Oboukhov a écrit :
> > If this package is built it wants more than one gigabyte (~1.2-1.4G)
> > RAM to build. So there are two buildd servers can't build
> > *architecture:all* packages. So this packa
On Fri, Sep 24, 2010 at 11:55:32PM +0200, Stéphane Glondu wrote:
> What about building this architecture:all package only in binary-indep?
> Like in the attached patch... This way, the buildds won't try to build them.
> diff -u wordnet-3.0/debian/rules wordnet-3.0/debian/rules
> -build/goldendict-
Le 24/09/2010 22:44, Dmitry E. Oboukhov a écrit :
> If this package is built it wants more than one gigabyte (~1.2-1.4G)
> RAM to build. So there are two buildd servers can't build
> *architecture:all* packages. So this package can't pass into testing
> for a long time (more than 120 days).
What
On Sat, Sep 25, 2010 at 12:44:39AM +0400, Dmitry E. Oboukhov wrote:
> There is one src-package which builds a few packages with architecture
> -all and -any. http://packages.qa.debian.org/w/wordnet.html
>
> If this package is built it wants more than one gigabyte (~1.2-1.4G)
> RAM to build. So th
47 matches
Mail list logo
