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 takes if I
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 anything
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 puzzles me how
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
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 to see why
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)
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 predict how
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
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 it
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 so many
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 maintainer
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
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
provide this
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 is
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 the
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 can
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 using that
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 var) my
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 using that
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, build
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 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?) which
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 is
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 -j
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, and I
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
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: it
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 or not.
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 it
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
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)?
I'm
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, little
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 not just have
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.
If
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 choice
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
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
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
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
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
[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
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 for
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 honest
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 Constant
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 on a
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 faster,
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 easy to
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
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
49 matches
Mail list logo
