On Fri, Jul 07, 2006 at 02:46:15PM +0200, Goswin von Brederlow wrote:
> The point of the helper is to remove the decision from the package
> alone to a central place that is easily configurable for a wide range
> of cases.
Ok, here goes my stab at the helper:
(attached)
Usage:
$(MAKE) -j`debian
On Friday 07 July 2006 19:06, Adam Borowski wrote:
> On Fri, Jul 07, 2006 at 03:34:59PM +0200, Wouter Verhelst wrote:
> > Err, AIUI, ruby gems are a way to automatically install extras to a
> > running ruby environment, much in the same way that the CPAN module is
> > used for Perl.
> >
> > I fail
On Fri, Jul 07, 2006 at 03:34:59PM +0200, Wouter Verhelst wrote:
> Err, AIUI, ruby gems are a way to automatically install extras to a
> running ruby environment, much in the same way that the CPAN module is
> used for Perl.
>
> I fail to see why this would be "completely useless" on smaller
> arc
On Thu, Jul 06, 2006 at 11:58:28PM +0200, Adam Borowski wrote:
> On Wed, Jul 05, 2006 at 08:23:00PM +0200, Wouter Verhelst wrote:
> > On Mon, Jul 03, 2006 at 03:04:14PM +0200, Adam Borowski wrote:
> > > On Sun, Jul 02, 2006 at 11:57:50AM +0200, Wouter Verhelst wrote:
> > > > Additionally, it puzzle
Adam Borowski <[EMAIL PROTECTED]> writes:
> On Sun, Jul 02, 2006 at 11:57:50AM +0200, Wouter Verhelst wrote:
>> Additionally, it puzzles me how you think a maintainer will be able to
>> accurately predict how much RAM a certain build is going to use. There
>> are so many variables, that I think an
On Thu, Jul 06, 2006 at 11:58:28PM +0200, Adam Borowski wrote:
> > > program X consist of a number of C files; it seems like compiling
> > > every file takes around 24MB,
> > Like I said, there's just too many variables. Also, I wouldn't be
> > interested in figuring out how much RAM the build tak
On Wed, Jul 05, 2006 at 08:23:00PM +0200, Wouter Verhelst wrote:
> On Mon, Jul 03, 2006 at 03:04:14PM +0200, Adam Borowski wrote:
> > On Sun, Jul 02, 2006 at 11:57:50AM +0200, Wouter Verhelst wrote:
> > > Additionally, it puzzles me how you think a maintainer will be able to
> > > accurately predic
On Mon, Jul 03, 2006 at 03:04:14PM +0200, Adam Borowski wrote:
> On Sun, Jul 02, 2006 at 11:57:50AM +0200, Wouter Verhelst wrote:
> > Additionally, it puzzles me how you think a maintainer will be able to
> > accurately predict how much RAM a certain build is going to use. There
> > are so many var
On Mon, 3 Jul 2006 15:04:14 +0200, Adam Borowski <[EMAIL PROTECTED]> said:
> On Sun, Jul 02, 2006 at 11:57:50AM +0200, Wouter Verhelst wrote:
>> Additionally, it puzzles me how you think a maintainer will be able
>> to accurately predict how much RAM a certain build is going to
>> use. There are s
On Sun, Jul 02, 2006 at 11:57:50AM +0200, Wouter Verhelst wrote:
> Additionally, it puzzles me how you think a maintainer will be able to
> accurately predict how much RAM a certain build is going to use. There
> are so many variables, that I think anything but 'this is the fastest
> way to build i
On Fri, Jun 30, 2006 at 12:12:10PM +0200, Adam Borowski wrote:
> On Fri, Jun 30, 2006 at 03:26:15AM +0200, Goswin von Brederlow wrote:
> > Adam Borowski <[EMAIL PROTECTED]> writes:
> > > Still, the buildd admin has no way to estimate how much a sub-process
> > > of a package is going to use, the ma
On Fri, Jun 30, 2006 at 12:12:10PM +0200, Adam Borowski wrote:
> Oh, so you mean checking the _free_ RAM instead of the _physical_ RAM?
> This would be reasonable -- I didn't use this in the debian/rules
> snippet I proposed as the physical memory is a trivially discernable
> number while free RAM
On Fri, Jun 30, 2006 at 08:41:33AM +0200, Ingo Juergensmann wrote:
> On Fri, Jun 30, 2006 at 03:22:48AM +0200, Goswin von Brederlow wrote:
> > The same can't be said for upstream makefiles though. Many sources
> > don't build with -j option.
Right, that's just what I said :p It's the upstream and
On Fri, Jun 30, 2006 at 03:26:15AM +0200, Goswin von Brederlow wrote:
> Adam Borowski <[EMAIL PROTECTED]> writes:
> > Still, the buildd admin has no way to estimate how much a sub-process
> > of a package is going to use, the maintainer has at least a rough
> > idea. Since the maintainer's action
On Fri, Jun 30, 2006 at 03:26:15AM +0200, Goswin von Brederlow wrote:
> > Still, the buildd admin has no way to estimate how much a sub-process
> > of a package is going to use, the maintainer has at least a rough
> > idea. Since the maintainer's action is needed anyway, he can as well
> > provid
On Fri, Jun 30, 2006 at 03:22:48AM +0200, Goswin von Brederlow wrote:
> The same can't be said for upstream makefiles though. Many sources
> don't build with -j option. I'm not sure if debian/rules should
> somehow enforce -j1 in those cases or if only packages that benefit
> from -jX should add s
Adam Borowski <[EMAIL PROTECTED]> writes:
> On Wed, Jun 28, 2006 at 07:50:50PM +0300, Lars Wirzenius wrote:
>> ke, 2006-06-28 kello 18:43 +0200, Adam Borowski kirjoitti:
>> > What do you think about going with Don Armstrong's suggestion
>> > ($CONCURRENCY_LEVEL), while handling the default (no env
Adam Borowski <[EMAIL PROTECTED]> writes:
> On Wed, Jun 28, 2006 at 03:17:27AM +0200, Henning Makholm wrote:
>> > If package maintainer wants to build it faster on their own machine, I
>> > would imagine that checking for an environment variable (DEB_MAKE_OPTS
>> > or something, perhaps?) and usin
On Wed, 28 Jun 2006, Adam Borowski wrote:
> On Wed, Jun 28, 2006 at 02:06:26AM -0700, Don Armstrong wrote:
> > On Wed, 28 Jun 2006, Adam Borowski wrote:
> > > Let's allow maintainers to use make -jX according to their common
> > > sense, requiring obeying an env variable to opt out.
> >
> > Why no
On Wed, Jun 28, 2006 at 07:50:50PM +0300, Lars Wirzenius wrote:
> ke, 2006-06-28 kello 18:43 +0200, Adam Borowski kirjoitti:
> > What do you think about going with Don Armstrong's suggestion
> > ($CONCURRENCY_LEVEL), while handling the default (no env var) my
> > way (decent memory => parallel, lit
ke, 2006-06-28 kello 18:43 +0200, Adam Borowski kirjoitti:
> What do you think about going with Don Armstrong's suggestion
> ($CONCURRENCY_LEVEL), while handling the default (no env var) my
> way (decent memory => parallel, little memory => -j 1) instead of
> Ingo's (-j 1 unless explicitely set)?
On Wed, Jun 28, 2006 at 03:42:07PM +0200, Wouter Verhelst wrote:
> SMP buildd systems currently run multiple instances of buildd at
> the same time, rather than expecting a package to specify make -j
> itself. Having three packages that specify 'make -j 4' on a
> multiprocessor buildd host that _al
On Wed, Jun 28, 2006 at 12:01:31PM +0200, Adam Borowski wrote:
> On Wed, Jun 28, 2006 at 02:06:26AM -0700, Don Armstrong wrote:
> > This has the disadvantage of not automatically using -j for every
> > package and requiring maintainer buy in to see results... but
> > presumably those packages where
On Wed, Jun 28, 2006 at 03:22:35PM +0200, Ingo Juergensmann wrote:
> On Wed, Jun 28, 2006 at 01:37:37PM +0200, Adam Borowski wrote:
> > The benefits on UP are small (~10%), but except for huge working
> > sets, non-negative. And the maintainer knows if the package handles
> > huge chunks at once o
On Wed, Jun 28, 2006 at 01:37:37PM +0200, Adam Borowski wrote:
> > Well, make -jX is not everywhere faster on UPs. It depends on other factors
> > as well. If you specify -j2 and the second make is causing lots of swapping,
> > you won't gain much if anything at all.
> Exactly, just like I said:
On Wed, Jun 28, 2006 at 12:38:51PM +0200, Ingo Juergensmann wrote:
> I don't think it's good to define an opt-out variable (*_NON_PARALLEL).
> Think positive! So, it would be better to define DEB_MAKE_PARALLEL, but even
> better it would be to use something existing: CONCURRENCY_LEVEL as Don
> Amst
On Wed, Jun 28, 2006 at 12:38:51PM +0200, Ingo Juergensmann wrote:
> On Wed, Jun 28, 2006 at 10:31:54AM +0200, Adam Borowski wrote:
> > On the other hand, making builds significantly faster is not
> > something that you can shake a stick at. Typically make -jX is faster
> > even on uniprocessor, a
On Wed, Jun 28, 2006 at 02:06:26AM -0700, Don Armstrong wrote:
> Why not just have some ENV variable (CONCURRENCY_LEVEL?) which
> specifies the maximum -j; the package maintainer is free to choose any
> level equal to or below that.
> [...]
> This has the disadvantage of not automatically using -
On Wed, Jun 28, 2006 at 10:31:54AM +0200, Adam Borowski wrote:
> On the other hand, making builds significantly faster is not
> something that you can shake a stick at. Typically make -jX is faster
> even on uniprocessor, and I don't need to tell you why it's much
> faster on SMP.
Well, make -jX
On Wed, Jun 28, 2006 at 02:06:26AM -0700, Don Armstrong wrote:
> On Wed, 28 Jun 2006, Adam Borowski wrote:
> > Let's allow maintainers to use make -jX according to their common
> > sense, requiring obeying an env variable to opt out.
>
> Why not just have some ENV variable (CONCURRENCY_LEVEL?) whi
On Wed, 28 Jun 2006, Adam Borowski wrote:
> Let's allow maintainers to use make -jX according to their common
> sense, requiring obeying an env variable to opt out.
Why not just have some ENV variable (CONCURRENCY_LEVEL?) which
specifies the maximum -j; the package maintainer is free to choose any
On Wed, Jun 28, 2006 at 03:17:27AM +0200, Henning Makholm wrote:
> > If package maintainer wants to build it faster on their own machine, I
> > would imagine that checking for an environment variable (DEB_MAKE_OPTS
> > or something, perhaps?) and using that would be the way to go. By
> > default, b
On Wed, Jun 28, 2006 at 03:17:27AM +0200, Henning Makholm wrote:
> Scripsit Lars Wirzenius <[EMAIL PROTECTED]>
>
> > If package maintainer wants to build it faster on their own machine, I
> > would imagine that checking for an environment variable (DEB_MAKE_OPTS
> > or something, perhaps?) and usi
Henning Makholm <[EMAIL PROTECTED]> wrote:
> Well, in fact also design a mechanism to share knowledge about which
> source packages may break if given a -j due to insufficiently
> specified dependencies. So perhaps using $(DEB_MAKE_J_OPTION) on the
> "$(MAKE) all" line in debian/rules is a better c
Scripsit Lars Wirzenius <[EMAIL PROTECTED]>
> If package maintainer wants to build it faster on their own machine, I
> would imagine that checking for an environment variable (DEB_MAKE_OPTS
> or something, perhaps?) and using that would be the way to go. By
> default, build with a single processor
On Sun, Jun 25, 2006 at 09:07:40PM +0200, Wouter Verhelst wrote:
> It's not a question of legislating; it's more a question of picking a
> good option and writing the specification in policy.
I fully agree with Wouter on this. Although the specification doesn't
necessarily have to be in policy (
On Sun, Jun 25, 2006 at 06:11:24PM +0300, Lars Wirzenius wrote:
> su, 2006-06-25 kello 16:36 +0200, Wouter Verhelst kirjoitti:
> > It has come to my attention that the gem package is currently built
> > using 'make -j 4', to have four compiler processes running at the same
> > time. This is a bit t
On Sun, Jun 25, 2006, Lars Wirzenius wrote:
> Sure, even on a single CPU -jX (X > 1) can be faster, but it depends on
> various factors, such as available memory, and other load on the
> machine. Using -j is not something that should be on by default, but it
> would be *really* nice if it were eas
su, 2006-06-25 kello 10:41 -0700, Tyler MacDonald kirjoitti:
> kernel-package uses the CONCURRENCY_LEVEL envrionment variable for
> this. And if I do a "CONCURRENCY_LEVEL=4" on my single-CPU system, it does
> actually go quite a bit faster. :)
Sure, even on a single CPU -jX (X > 1) can be fa
On Sun, Jun 25, 2006 at 06:51:31PM +0200, Petter Reinholdtsen wrote:
> [Lars Wirzenius]
> > As far as I can see, using make's -j option is only useful if you
> > have multiple processors. Packages should not make such assumptions
> > of the build environment.
> Actually, I've seem speedup with -j2
Lars Wirzenius <[EMAIL PROTECTED]> wrote:
> > It has come to my attention that the gem package is currently built
> > using 'make -j 4', to have four compiler processes running at the same
> > time. This is a bit troublesome for the poor m68k buildd, which is now
> > suffering under High Load And C
On Sun, 2006-06-25 at 16:56 +0200, Bastian Blank wrote:
> DoS against the buildd?
> There is none. But you may consider it as an attack against the
> infrastructure.
You on the other hand, might consider that developers might not have the
malicious intent you infer, but perhaps just made an hones
Am Sonntag, den 25.06.2006, 18:11 +0300 schrieb Lars Wirzenius:
> I doubt we need a policy change for this. At some point, we need to stop
> legislating and start assuming the package maintainers have common
> sense.
Agreed. However, it might be a good idea to have *one* canonical
variable name fo
[Lars Wirzenius]
> As far as I can see, using make's -j option is only useful if you
> have multiple processors. Packages should not make such assumptions
> of the build environment.
Actually, I've seem speedup with -j2 on a single CPU machine. I
suspect one process is compiling while the other
On Sun, Jun 25, 2006 at 05:07:16PM +0200, Turbo Fredriksson wrote:
> When the talk about the hijacking of Bacula was up, the consensus was
> 'who cares about the m68k? If they can't keep up, get more machines'.
You can also get the same from the other arches if you prefer.
Bastian
--
There are
Quoting Wouter Verhelst <[EMAIL PROTECTED]>:
> Since most packages currently
> do not do this, some of our infrastructure (in casu, buildd machines)
> assume this is not being done. Doing it anyway then might upset those
> machines -- not just on m68k; when there was talk of a 6-way SPARC
> buildd
su, 2006-06-25 kello 16:36 +0200, Wouter Verhelst kirjoitti:
> It has come to my attention that the gem package is currently built
> using 'make -j 4', to have four compiler processes running at the same
> time. This is a bit troublesome for the poor m68k buildd, which is now
> suffering under High
On Sun, Jun 25, 2006 at 04:36:08PM +0200, Wouter Verhelst wrote:
> It has come to my attention that the gem package is currently built
> using 'make -j 4', to have four compiler processes running at the same
> time. This is a bit troublesome for the poor m68k buildd, which is now
> suffering under
Hi,
It has come to my attention that the gem package is currently built
using 'make -j 4', to have four compiler processes running at the same
time. This is a bit troublesome for the poor m68k buildd, which is now
suffering under High Load And Constant Swapping (HLACS).
I was going to file a flam
49 matches
Mail list logo
