[gentoo-user] --jobs

[gentoo-user] --jobs

[Harry Putnam]

Under the newest portage with x86~, if I run `emerge -vuD world'
should I see something besides:

>>> Jobs 0 of 71 complete, 1 running [...]

Shouldn't there be more jobs running?

(This is on gentoo installed as guest on win7 using Vbox)

Re: [gentoo-user] --jobs

[Alan McKinnon]

On Wed, 07 Dec 2011 16:55:38 -0600
Harry Putnam <reader@newsguy.com> wrote:

> Under the newest portage with x86~, if I run `emerge -vuD world'
> should I see something besides:
> 
> >>> Jobs 0 of 71 complete, 1 running [...]
> 
> Shouldn't there be more jobs running?
> 
> (This is on gentoo installed as guest on win7 using Vbox)

What is the first job?

Assuming that the system is set up to run parallel jobs, you have 71
updates. That's quite a lot. Maybe the first one is some really basic
package in @system upon which the other 70 depend (directly or
indirectly). Portage must complete the first fully in that case, then
proceed.

Or, that first job is portage itself. It makes sense that portage
updates should be done in isolation.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

[gentoo-user] Re: --jobs

[Harry Putnam]

Alan McKinnon <alan.mckinnon@gmail.com> writes:

> On Wed, 07 Dec 2011 16:55:38 -0600
> Harry Putnam <reader@newsguy.com> wrote:
>
>> Under the newest portage with x86~, if I run `emerge -vuD world'
>> should I see something besides:
>> 
>> >>> Jobs 0 of 71 complete, 1 running [...]
>> 
>> Shouldn't there be more jobs running?
>> 
>> (This is on gentoo installed as guest on win7 using Vbox)
>
> What is the first job?
>
> Assuming that the system is set up to run parallel jobs, you have 71
> updates. That's quite a lot. Maybe the first one is some really basic
> package in @system upon which the other 70 depend (directly or
> indirectly). Portage must complete the first fully in that case, then
> proceed.
>
> Or, that first job is portage itself. It makes sense that portage
> updates should be done in isolation.

Now 38 are installed and it has never shown more than 1 running.
Appears to be doing them all one by one.

I'm not sure what you mean about system being setup for parallel jobs.

Isn't the new default emerge to run that way?  Isn't that why we now
have this line about jobs and load that completely removes the old -v
ouput?

This is a brand new install, and I've changed very little.  I've done
nothing consciously to effect how many jobs are to be run.

If its only going to do the jobs one by one, then why cover the -v
output?

I'd sooner disable this new behavior but it appears there is no across
the board way to do that.  Maybe a function like:

  emg () { emerge --quite-build=n $@; }

Would have that effect.  I can't see where it would be losing anything
since emerge is doing 1 job at a time anyway.  By the way, are these
heavy or unusual loads:

   1.10 1.17 1.14

Its an i7 processor but gentoo is running as vbox guest.

Re: [gentoo-user] Re: --jobs

[Paul Hartman]

On Wed, Dec 7, 2011 at 5:46 PM, Harry Putnam <reader@newsguy.com> wrote:
> This is a brand new install, and I've changed very little.  I've done
> nothing consciously to effect how many jobs are to be run.

In that case I think it is working normally. It won't run more than 1
job unless you ask it to do so.

[gentoo-user] Re: --jobs

[Harry Putnam]

Paul Hartman <paul.hartman+gentoo@gmail.com> writes:

> On Wed, Dec 7, 2011 at 5:46 PM, Harry Putnam <reader@newsguy.com> wrote:
>> This is a brand new install, and I've changed very little.  I've done
>> nothing consciously to effect how many jobs are to be run.
>
> In that case I think it is working normally. It won't run more than 1
> job unless you ask it to do so.

I followed another thread recently about this, and I understood the
new behavior is set this way because emerge will be running more than
1 job and that would be a mess to put into one terminal... hence the
line showing jobs.  

But if it is not default to run more than 1 job then why is the other
(emerge) default in place, and blocking the normal output of -v?

Seems like these defaults should all be on the same page.

If emerge is not set to run more than 1 job at a time then the
intrusive `--jobs ???? --load ????' baloney should not be in place by
default either.   But I'm sure our developers have much better reasons
than I might dream up for doing it this (seemingly confusing) way.

I'm not really complaining so much as just a little confused as to
what is the reasoning for this change. 

Re: [gentoo-user] Re: --jobs

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]

On Dec 8, 2011 7:21 AM, "Harry Putnam" <reader@newsguy.com> wrote:
>
> Paul Hartman <paul.hartman+gentoo@gmail.com> writes:
>
> > On Wed, Dec 7, 2011 at 5:46 PM, Harry Putnam <reader@newsguy.com> wrote:
> >> This is a brand new install, and I've changed very little.  I've done
> >> nothing consciously to effect how many jobs are to be run.
> >
> > In that case I think it is working normally. It won't run more than 1
> > job unless you ask it to do so.
>
> I followed another thread recently about this, and I understood the
> new behavior is set this way because emerge will be running more than
> 1 job and that would be a mess to put into one terminal... hence the
> line showing jobs.
>
> But if it is not default to run more than 1 job then why is the other
> (emerge) default in place, and blocking the normal output of -v?
>

-v affects only the list of packages being emerged, it no longer has any
effect on the build output.

> Seems like these defaults should all be on the same page.
>
> If emerge is not set to run more than 1 job at a time then the
> intrusive `--jobs ???? --load ????' baloney should not be in place by
> default either.   But I'm sure our developers have much better reasons
> than I might dream up for doing it this (seemingly confusing) way.
>

It's not. The default is still "single job" and "no load limiting" but
"quietly build things"

> I'm not really complaining so much as just a little confused as to
> what is the reasoning for this change.
>

In the -project list, Zac explained his reasons. Some that I can recall:

* Computers are way too fast nowadays for us to properly peruse the build
output

* Gentoo newcomers are more likely to be confused by all those output. (And
my corollary: Gentoo oldtimers should be perfectly capable of finding out
how to disable quiet build ;-)

Rgds,

[-- Attachment #2: Type: text/html, Size: 2370 bytes --]

Re: [gentoo-user] Re: --jobs

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]

On Wed, 07 Dec 2011 18:09:39 -0600, Harry Putnam wrote:

> I followed another thread recently about this, and I understood the
> new behavior is set this way because emerge will be running more than
> 1 job and that would be a mess to put into one terminal... hence the
> line showing jobs.  

No, the compile output has been hidden for --jobs >1 for a long time.
The new quiet-build behaviour applies the same output rules when --jobs
is not in effect.

> But if it is not default to run more than 1 job then why is the other
> (emerge) default in place, and blocking the normal output of -v?

This was also covered in the other thread. The new default does not hide
the verbose output of emerge (the command to which -v is applied) it
hides the autotools and compiler output, which generally does nothing but
hide the useful information amongst tens of megabytes of
blurred, rapidly scrolling, uninformative text. 

That you have to explicitly enable this output is consistent with also
having to enable verbose output on emerge and most other programs.


-- 
Neil Bothwick

"Facts are stubborn things, but statistics are more pliable."
  - Mark Twain

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: --jobs

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

On Wed, 07 Dec 2011 17:46:15 -0600, Harry Putnam wrote:

> If its only going to do the jobs one by one, then why cover the -v
> output?

So that you can see at a glance where emerge is up to. 15 of 71 tells me
far more than gcc output flashing by too fast to read, so I have to use
an external program to parse the logfile to see where I am up to.

For non-devs, the gcc output does nothing but slow things down and make
them incomprehensible, for those that want it there is a switch to enable
it.


-- 
Neil Bothwick

Power outage at a department store yesterday, Twenty people were
trapped on the escalators.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: --jobs

[Claudio Roberto França Pereira]

-v has nothing to do with quiet-build. You want to use --quiet-build=N.
Also, emerge parallelization depends on the -j (--jobs) option, you
should use emerge --jobs N <other_options> <atoms>.
In your case, a -j7 should do the trick.

Re: [gentoo-user] Re: --jobs

[Dale]

Harry Putnam wrote:
> Alan McKinnon<alan.mckinnon@gmail.com>  writes:
>
>> On Wed, 07 Dec 2011 16:55:38 -0600
>> Harry Putnam<reader@newsguy.com>  wrote:
>>
>>> Under the newest portage with x86~, if I run `emerge -vuD world'
>>> should I see something besides:
>>>
>>>>>> Jobs 0 of 71 complete, 1 running [...]
>>> Shouldn't there be more jobs running?
>>>
>>> (This is on gentoo installed as guest on win7 using Vbox)
>> What is the first job?
>>
>> Assuming that the system is set up to run parallel jobs, you have 71
>> updates. That's quite a lot. Maybe the first one is some really basic
>> package in @system upon which the other 70 depend (directly or
>> indirectly). Portage must complete the first fully in that case, then
>> proceed.
>>
>> Or, that first job is portage itself. It makes sense that portage
>> updates should be done in isolation.
> Now 38 are installed and it has never shown more than 1 running.
> Appears to be doing them all one by one.
>
> I'm not sure what you mean about system being setup for parallel jobs.
>
> Isn't the new default emerge to run that way?  Isn't that why we now
> have this line about jobs and load that completely removes the old -v
> ouput?
>
> This is a brand new install, and I've changed very little.  I've done
> nothing consciously to effect how many jobs are to be run.
>
> If its only going to do the jobs one by one, then why cover the -v
> output?
>
> I'd sooner disable this new behavior but it appears there is no across
> the board way to do that.  Maybe a function like:
>
>    emg () { emerge --quite-build=n $@; }
>
> Would have that effect.  I can't see where it would be losing anything
> since emerge is doing 1 job at a time anyway.  By the way, are these
> heavy or unusual loads:
>
>     1.10 1.17 1.14
>
> Its an i7 processor but gentoo is running as vbox guest.
>
>
>

If you are emerging packages one at a time, look at my sig.  I'm 
thinking you are expecting to see the configure, gcc and install info 
like it used to be by default.  The new default doesn't show that.  If 
you want the old way, see my sig for the option to put in make.conf.

If I am wrong on what you are expecting, ignore me.  Lots of people do 
anyway.  lol

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] --jobs

[Paul Hartman]

On Wed, Dec 7, 2011 at 4:55 PM, Harry Putnam <reader@newsguy.com> wrote:
> Under the newest portage with x86~, if I run `emerge -vuD world'
> should I see something besides:
>
>>>> Jobs 0 of 71 complete, 1 running [...]
>
> Shouldn't there be more jobs running?

You have --jobs in the subject line of this messag, but you didn't
specify --jobs in the emerge commandline.

[gentoo-user] Re: --jobs

[Harry Putnam]

Paul Hartman <paul.hartman+gentoo@gmail.com> writes:

> On Wed, Dec 7, 2011 at 4:55 PM, Harry Putnam <reader@newsguy.com> wrote:
>> Under the newest portage with x86~, if I run `emerge -vuD world'
>> should I see something besides:
>>
>>>>> Jobs 0 of 71 complete, 1 running [...]
>>
>> Shouldn't there be more jobs running?
>
> You have --jobs in the subject line of this messag, but you didn't
> specify --jobs in the emerge commandline.

I see what you mean, yes the subject is a bit too brief, but then that
is the only place I've noticed where the --jobs stuff comes up
persistently.  In a command that is going to get a lot of use no has
something (by default) blocking what might be other more useful output.