[gentoo-dev] [RFC] enable verbose build whenever it's possible

[gentoo-dev] [RFC] enable verbose build whenever it's possible

[Kacper Kowalik]

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

Hi,
I'd like to ask that we enable verbose building by default. I have
cmake-utils.eclass in mind, because it's dead easy there, but there's a
lot of packages that support things like "make V=1" or "make VERBOSE=1" too.

I've seen too many bugs reports today that gave me cute, colorful
build.logs and almost no information about underlaying bug...
Cheers,
Kacper


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

[gentoo-dev] Re: [RFC] enable verbose build whenever it's possible

[Ryan Hill]

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

On Sat, 05 Nov 2011 09:58:00 +0100
Kacper Kowalik <xarthisius@gentoo.org> wrote:

> Hi,
> I'd like to ask that we enable verbose building by default. I have
> cmake-utils.eclass in mind, because it's dead easy there, but there's a
> lot of packages that support things like "make V=1" or "make VERBOSE=1" too.
> 
> I've seen too many bugs reports today that gave me cute, colorful
> build.logs and almost no information about underlaying bug...
> Cheers,
> Kacper

+1

glibc breaks with `make V=1` but I think I saw a fix somewhere recently.


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible

[Fabian Groffen]

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

On 05-11-2011 09:58:00 +0100, Kacper Kowalik wrote:
> Hi,
> I'd like to ask that we enable verbose building by default. I have
> cmake-utils.eclass in mind, because it's dead easy there, but there's a
> lot of packages that support things like "make V=1" or "make VERBOSE=1" too.
> 
> I've seen too many bugs reports today that gave me cute, colorful
> build.logs and almost no information about underlaying bug...

... and with the actual build information, some of Portage's checks can
do their work too.

+1, I'd love to see this being the norm.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible

[Nirbheek Chauhan]

On Sat, Nov 5, 2011 at 2:28 PM, Kacper Kowalik <xarthisius@gentoo.org> wrote:
> Hi,
> I'd like to ask that we enable verbose building by default. I have
> cmake-utils.eclass in mind, because it's dead easy there, but there's a
> lot of packages that support things like "make V=1" or "make VERBOSE=1" too.
>
> I've seen too many bugs reports today that gave me cute, colorful
> build.logs and almost no information about underlaying bug...

Is there a way to output the verbose log to build.log, but show the
shortened log to the terminal? The non-verbose build is quite useful
for seeing the actual warnings as they fly by rather than the entire
gcc/libtool command, which is often mostly noise.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible

[Fabio Erculiani]

On Sat, Nov 5, 2011 at 11:27 AM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
>
> Is there a way to output the verbose log to build.log, but show the
> shortened log to the terminal? The non-verbose build is quite useful
> for seeing the actual warnings as they fly by rather than the entire
> gcc/libtool command, which is often mostly noise.
>

And writing to std{out,err} is expensive! ;-)

> --
> ~Nirbheek Chauhan
>
> Gentoo GNOME+Mozilla Team
>
>



-- 
Fabio Erculiani
http://lxnay.com

Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible

[Ulrich Mueller]

>>>>> On Sat, 05 Nov 2011, Kacper Kowalik wrote:

> I'd like to ask that we enable verbose building by default. I have
> cmake-utils.eclass in mind, because it's dead easy there, but
> there's a lot of packages that support things like "make V=1" or
> "make VERBOSE=1" too.

> I've seen too many bugs reports today that gave me cute, colorful
> build.logs and almost no information about underlaying bug...

In fact, there's already bug 379497 [1] open for this. Some build
systems might use the variable V for something else, so adding
--disable-silent-rules may be the safer solution.

Ulrich

[1] <https://bugs.gentoo.org/show_bug.cgi?id=379497>

Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible

[Michał Górny]

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

On Sat, 5 Nov 2011 12:05:15 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Sat, 05 Nov 2011, Kacper Kowalik wrote:
> 
> > I'd like to ask that we enable verbose building by default. I have
> > cmake-utils.eclass in mind, because it's dead easy there, but
> > there's a lot of packages that support things like "make V=1" or
> > "make VERBOSE=1" too.
> 
> > I've seen too many bugs reports today that gave me cute, colorful
> > build.logs and almost no information about underlaying bug...
> 
> In fact, there's already bug 379497 [1] open for this. Some build
> systems might use the variable V for something else, so adding
> --disable-silent-rules may be the safer solution.

Yeah, please use the correct configure opt rather than throwing in
random makevars.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible

[Kacper Kowalik]

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

W dniu 05.11.2011 18:04, Michał Górny pisze:
> On Sat, 5 Nov 2011 12:05:15 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
> 
>>>>>>> On Sat, 05 Nov 2011, Kacper Kowalik wrote:
>>
>>> I'd like to ask that we enable verbose building by default. I have
>>> cmake-utils.eclass in mind, because it's dead easy there, but
>>> there's a lot of packages that support things like "make V=1" or
>>> "make VERBOSE=1" too.
>>
>>> I've seen too many bugs reports today that gave me cute, colorful
>>> build.logs and almost no information about underlaying bug...
>>
>> In fact, there's already bug 379497 [1] open for this. Some build
>> systems might use the variable V for something else, so adding
>> --disable-silent-rules may be the safer solution.
Of course --disable-silent-rules is the way to go for autotools based
packages.
> 
> Yeah, please use the correct configure opt rather than throwing in
> random makevars.
I don't want to throw any vars blindly to emake. V=1 was just an example
that I've seen in some packages' build systems. It was more like a
proposal to use whatever build system of given package provides.
Cheers,
Kacper



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible

[Pacho Ramos]

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

El sáb, 05-11-2011 a las 09:58 +0100, Kacper Kowalik escribió:
> Hi,
> I'd like to ask that we enable verbose building by default. I have
> cmake-utils.eclass in mind, because it's dead easy there, but there's a
> lot of packages that support things like "make V=1" or "make VERBOSE=1" too.
> 
> I've seen too many bugs reports today that gave me cute, colorful
> build.logs and almost no information about underlaying bug...
> Cheers,
> Kacper
> 

I also support this :)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 912 bytes --]

On Saturday 05 of November 2011 09:58:00 Kacper Kowalik wrote:
> Hi,
> I'd like to ask that we enable verbose building by default. I have
> cmake-utils.eclass in mind, because it's dead easy there, but there's a
> lot of packages that support things like "make V=1" or "make VERBOSE=1"
> too.
> 
> I've seen too many bugs reports today that gave me cute, colorful
> build.logs and almost no information about underlaying bug...

That's usually because users sometimes attach only "relevant" parts of build 
log (well, relevant according to their taste = last lines, even when they use 
parallel compilation).
Any particular example of bug report with entire build log from cmake-utils in 
fancy mode, and still being unable to locate the problem?

I ask, because we're appending summary just after configure phase to make 
vorbose logging of whole build process unecessary.

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible

[Kacper Kowalik]

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

On 11/05/11 21:00, Maciej Mrozowski wrote:
> On Saturday 05 of November 2011 09:58:00 Kacper Kowalik wrote:
>> Hi,
>> I'd like to ask that we enable verbose building by default. I have
>> cmake-utils.eclass in mind, because it's dead easy there, but there's a
>> lot of packages that support things like "make V=1" or "make VERBOSE=1"
>> too.
>>
>> I've seen too many bugs reports today that gave me cute, colorful
>> build.logs and almost no information about underlaying bug...
> 
> That's usually because users sometimes attach only "relevant" parts of build 
> log (well, relevant according to their taste = last lines, even when they use 
> parallel compilation).
> Any particular example of bug report with entire build log from cmake-utils in 
> fancy mode, and still being unable to locate the problem?
> 
> I ask, because we're appending summary just after configure phase to make 
> vorbose logging of whole build process unecessary.
Yeah take bug 297699 as an example and relavant snippet:

^[[0m^[[31m^[[1mLinking CXX executable eqsl
^[[0m[ 22%] CMakeFiles/eqsl.dir/eqsl.cxx.o: In function `callback(char
const*)':
eqsl.cxx:(.text+0x192a): undefined reference to `Fl::lock()'
eqsl.cxx:(.text+0x1ef1): undefined reference to `Fl::unlock()'

As we don't see actual linking we cannot immediately tell what libraries
were linked and rule out/diagnose as-needed issue. As I cannot even
reproduce the bug right now I can only rely on clairvoyance to figure
what happened there...

Cheers,
Kacper


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

[gentoo-dev] Re: [RFC] enable verbose build whenever it's possible

[Ryan Hill]

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

On Sat, 5 Nov 2011 21:00:32 +0100
Maciej Mrozowski <reavertm@gmail.com> wrote:

> > I've seen too many bugs reports today that gave me cute, colorful
> > build.logs and almost no information about underlaying bug...
> 
> That's usually because users sometimes attach only "relevant" parts of build 
> log (well, relevant according to their taste = last lines, even when they use 
> parallel compilation).

I think you're confusing build log with build output.

> Any particular example of bug report with entire build log from cmake-utils in 
> fancy mode, and still being unable to locate the problem?
> 
> I ask, because we're appending summary just after configure phase to make 
> vorbose logging of whole build process unecessary.

How are you supposed to debug a compile or linker error without the compiler
command line?


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-dev] Re: [RFC] enable verbose build whenever it's possible

[Pacho Ramos]

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

El sáb, 05-11-2011 a las 21:03 -0600, Ryan Hill escribió:
> On Sat, 5 Nov 2011 21:00:32 +0100
> Maciej Mrozowski <reavertm@gmail.com> wrote:
> 
> > > I've seen too many bugs reports today that gave me cute, colorful
> > > build.logs and almost no information about underlaying bug...
> > 
> > That's usually because users sometimes attach only "relevant" parts of build 
> > log (well, relevant according to their taste = last lines, even when they use 
> > parallel compilation).
> 
> I think you're confusing build log with build output.
> 
> > Any particular example of bug report with entire build log from cmake-utils in 
> > fancy mode, and still being unable to locate the problem?
> > 
> > I ask, because we're appending summary just after configure phase to make 
> > vorbose logging of whole build process unecessary.
> 
> How are you supposed to debug a compile or linker error without the compiler
> command line?
> 
> 

How all this ended up? It would still be nice to have verbose output
enabled by default (even people being able to use emerge --quiet to
silent it) to check for undesired flags (like -Werror,
-DG_DISABLE_DEPRECATED...) easily :)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [RFC] enable verbose build whenever it's possible

[Zac Medico]

On 04/02/2012 03:24 PM, Pacho Ramos wrote:
> How all this ended up? It would still be nice to have verbose output
> enabled by default (even people being able to use emerge --quiet to
> silent it) to check for undesired flags (like -Werror,
> -DG_DISABLE_DEPRECATED...) easily :)

We've got a feature request bug about detecting -Werror here:

  https://bugs.gentoo.org/show_bug.cgi?id=409955
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: [RFC] enable verbose build whenever it's possible

[Pacho Ramos]

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

El lun, 02-04-2012 a las 15:34 -0700, Zac Medico escribió:
> On 04/02/2012 03:24 PM, Pacho Ramos wrote:
> > How all this ended up? It would still be nice to have verbose output
> > enabled by default (even people being able to use emerge --quiet to
> > silent it) to check for undesired flags (like -Werror,
> > -DG_DISABLE_DEPRECATED...) easily :)
> 
> We've got a feature request bug about detecting -Werror here:
> 
>   https://bugs.gentoo.org/show_bug.cgi?id=409955

But that is the bug I was also waiting for ;), the problem is that it
needs verbose output :|

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible

[Luca Barbato]

On 11/5/11 1:58 AM, Kacper Kowalik wrote:
> Hi,
> I'd like to ask that we enable verbose building by default. I have
> cmake-utils.eclass in mind, because it's dead easy there, but there's a
> lot of packages that support things like "make V=1" or "make VERBOSE=1" too.
>
> I've seen too many bugs reports today that gave me cute, colorful
> build.logs and almost no information about underlaying bug...

That could be done, but I'd advise to make sure our users know that the 
could have a quiet/silent output from portage.

lu

Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 769 bytes --]

On Thursday 10 November 2011 19:09:28 Luca Barbato wrote:
> On 11/5/11 1:58 AM, Kacper Kowalik wrote:
> > I'd like to ask that we enable verbose building by default. I have
> > cmake-utils.eclass in mind, because it's dead easy there, but there's a
> > lot of packages that support things like "make V=1" or "make VERBOSE=1"
> > too.
> > 
> > I've seen too many bugs reports today that gave me cute, colorful
> > build.logs and almost no information about underlaying bug...
> 
> That could be done, but I'd advise to make sure our users know that the
> could have a quiet/silent output from portage.

if you want quiet portage output, use something like --quiet when running 
emerge.  the verbosity of the build output isn't really an issue imo.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] have portage be quiet by default

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 938 bytes --]

On Thursday 10 November 2011 20:39:11 Mike Frysinger wrote:
> On Thursday 10 November 2011 19:09:28 Luca Barbato wrote:
> > On 11/5/11 1:58 AM, Kacper Kowalik wrote:
> > > I'd like to ask that we enable verbose building by default. I have
> > > cmake-utils.eclass in mind, because it's dead easy there, but there's a
> > > lot of packages that support things like "make V=1" or "make VERBOSE=1"
> > > too.
> > > 
> > > I've seen too many bugs reports today that gave me cute, colorful
> > > build.logs and almost no information about underlaying bug...
> > 
> > That could be done, but I'd advise to make sure our users know that the
> > could have a quiet/silent output from portage.
> 
> if you want quiet portage output, use something like --quiet when running
> emerge.  the verbosity of the build output isn't really an issue imo.

perhaps a more controversial question: should we make --quiet the default ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/10/2011 05:56 PM, Mike Frysinger wrote:
> On Thursday 10 November 2011 20:39:11 Mike Frysinger wrote:
>> On Thursday 10 November 2011 19:09:28 Luca Barbato wrote:
>>> On 11/5/11 1:58 AM, Kacper Kowalik wrote:
>>>> I'd like to ask that we enable verbose building by default. I have
>>>> cmake-utils.eclass in mind, because it's dead easy there, but there's a
>>>> lot of packages that support things like "make V=1" or "make VERBOSE=1"
>>>> too.
>>>>
>>>> I've seen too many bugs reports today that gave me cute, colorful
>>>> build.logs and almost no information about underlaying bug...
>>>
>>> That could be done, but I'd advise to make sure our users know that the
>>> could have a quiet/silent output from portage.
>>
>> if you want quiet portage output, use something like --quiet when running
>> emerge.  the verbosity of the build output isn't really an issue imo.
> 
> perhaps a more controversial question: should we make --quiet the default ?
> -mike

I think --quiet-build would be a reasonable default, but --quiet
suppresses various warning messages that I think need to be enabled by
default for newbies.
-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 719 bytes --]

On Thursday 10 November 2011 21:11:38 Zac Medico wrote:
> On 11/10/2011 05:56 PM, Mike Frysinger wrote:
> > On Thursday 10 November 2011 20:39:11 Mike Frysinger wrote:
> >> if you want quiet portage output, use something like --quiet when
> >> running emerge.  the verbosity of the build output isn't really an
> >> issue imo.
> > 
> > perhaps a more controversial question: should we make --quiet the default
> 
> I think --quiet-build would be a reasonable default, but --quiet
> suppresses various warning messages that I think need to be enabled by
> default for newbies.

WFM

would putting this as EMERGE_DEFAULT_OPTS in profiles/base/make.defaults be too 
hideous for people to swallow ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/10/2011 06:59 PM, Mike Frysinger wrote:
> On Thursday 10 November 2011 21:11:38 Zac Medico wrote:
>> On 11/10/2011 05:56 PM, Mike Frysinger wrote:
>>> On Thursday 10 November 2011 20:39:11 Mike Frysinger wrote:
>>>> if you want quiet portage output, use something like --quiet when
>>>> running emerge.  the verbosity of the build output isn't really an
>>>> issue imo.
>>>
>>> perhaps a more controversial question: should we make --quiet the default
>>
>> I think --quiet-build would be a reasonable default, but --quiet
>> suppresses various warning messages that I think need to be enabled by
>> default for newbies.
> 
> WFM
> 
> would putting this as EMERGE_DEFAULT_OPTS in profiles/base/make.defaults be too 
> hideous for people to swallow ?
> -mike

Less than sys-apps/portage-2.1.9.43 will choke on that, it's an
unrecognized option. So, we'd better just enable it by default for the
next portage release.
-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/10/2011 07:17 PM, Zac Medico wrote:
> On 11/10/2011 06:59 PM, Mike Frysinger wrote:
>> On Thursday 10 November 2011 21:11:38 Zac Medico wrote:
>>> On 11/10/2011 05:56 PM, Mike Frysinger wrote:
>>>> On Thursday 10 November 2011 20:39:11 Mike Frysinger wrote:
>>>>> if you want quiet portage output, use something like --quiet when
>>>>> running emerge.  the verbosity of the build output isn't really an
>>>>> issue imo.
>>>>
>>>> perhaps a more controversial question: should we make --quiet the default
>>>
>>> I think --quiet-build would be a reasonable default, but --quiet
>>> suppresses various warning messages that I think need to be enabled by
>>> default for newbies.
>>
>> WFM
>>
>> would putting this as EMERGE_DEFAULT_OPTS in profiles/base/make.defaults be too 
>> hideous for people to swallow ?
>> -mike
> 
> Less than sys-apps/portage-2.1.9.43 will choke on that, it's an
> unrecognized option. So, we'd better just enable it by default for the
> next portage release.

Actually, it's been around since portage-2.1.7.5 (bug #291200). Still,
it's probably better not to set it in the profile.
-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1545 bytes --]

On Thursday 10 November 2011 22:23:57 Zac Medico wrote:
> On 11/10/2011 07:17 PM, Zac Medico wrote:
> > On 11/10/2011 06:59 PM, Mike Frysinger wrote:
> >> On Thursday 10 November 2011 21:11:38 Zac Medico wrote:
> >>> On 11/10/2011 05:56 PM, Mike Frysinger wrote:
> >>>> On Thursday 10 November 2011 20:39:11 Mike Frysinger wrote:
> >>>>> if you want quiet portage output, use something like --quiet when
> >>>>> running emerge.  the verbosity of the build output isn't really an
> >>>>> issue imo.
> >>>> 
> >>>> perhaps a more controversial question: should we make --quiet the
> >>>> default
> >>> 
> >>> I think --quiet-build would be a reasonable default, but --quiet
> >>> suppresses various warning messages that I think need to be enabled by
> >>> default for newbies.
> >> 
> >> WFM
> >> 
> >> would putting this as EMERGE_DEFAULT_OPTS in profiles/base/make.defaults
> >> be too hideous for people to swallow ?
> > 
> > Less than sys-apps/portage-2.1.9.43 will choke on that, it's an
> > unrecognized option. So, we'd better just enable it by default for the
> > next portage release.
> 
> Actually, it's been around since portage-2.1.7.5 (bug #291200). Still,
> it's probably better not to set it in the profile.

good point.  we don't want to punish old portage users.  let's enable it by 
default in portage itself then.  just add `elog` output to the portage ebuild 
to inform users of the change ?  or do we want a news item ?

what's the flag to negate the default ?  --no-quiet-build ? ;)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/11/2011 07:11 AM, Mike Frysinger wrote:
> On Thursday 10 November 2011 22:23:57 Zac Medico wrote:
>> On 11/10/2011 07:17 PM, Zac Medico wrote:
>>> On 11/10/2011 06:59 PM, Mike Frysinger wrote:
>>>> On Thursday 10 November 2011 21:11:38 Zac Medico wrote:
>>>>> On 11/10/2011 05:56 PM, Mike Frysinger wrote:
>>>>>> On Thursday 10 November 2011 20:39:11 Mike Frysinger wrote:
>>>>>>> if you want quiet portage output, use something like --quiet when
>>>>>>> running emerge.  the verbosity of the build output isn't really an
>>>>>>> issue imo.
>>>>>>
>>>>>> perhaps a more controversial question: should we make --quiet the
>>>>>> default
>>>>>
>>>>> I think --quiet-build would be a reasonable default, but --quiet
>>>>> suppresses various warning messages that I think need to be enabled by
>>>>> default for newbies.
>>>>
>>>> WFM
>>>>
>>>> would putting this as EMERGE_DEFAULT_OPTS in profiles/base/make.defaults
>>>> be too hideous for people to swallow ?
>>>
>>> Less than sys-apps/portage-2.1.9.43 will choke on that, it's an
>>> unrecognized option. So, we'd better just enable it by default for the
>>> next portage release.
>>
>> Actually, it's been around since portage-2.1.7.5 (bug #291200). Still,
>> it's probably better not to set it in the profile.
> 
> good point.  we don't want to punish old portage users.  let's enable it by 
> default in portage itself then.  just add `elog` output to the portage ebuild 
> to inform users of the change ?  or do we want a news item ?
> 
> what's the flag to negate the default ?  --no-quiet-build ? ;)
> -mike

It's --quiet-build=n. I've gone ahead and enabled it for release in
portage-2.1.10.34:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc174b6fc28feb26ea151d76f794e0ff2c2fa39

-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Patrick Lauer]

On 11/11/11 16:44, Zac Medico wrote:
>> good point.  we don't want to punish old portage users.  let's enable it by
>> default in portage itself then.  just add `elog` output to the portage ebuild
>> to inform users of the change ?  or do we want a news item ?
>>
>> what's the flag to negate the default ?  --no-quiet-build ? ;)
>> -mike
> It's --quiet-build=n. I've gone ahead and enabled it for release in
> portage-2.1.10.34:
>
> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc174b6fc28feb26ea151d76f794e0ff2c2fa39
>
Lots of people in #gentoo are unhappy with it.

Most devs will be unhappy as it makes it harder to view the log while 
building.

Please consider reverting it and let users set it with 
EMERGE_DEFAULT_OPTS if they want it less noisy.


Patrick

Re: [gentoo-dev] have portage be quiet by default

[Rafael Goncalves Martins]

On Sat, Nov 12, 2011 at 8:24 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 11/11/11 16:44, Zac Medico wrote:
>>>
>>> good point.  we don't want to punish old portage users.  let's enable it
>>> by
>>> default in portage itself then.  just add `elog` output to the portage
>>> ebuild
>>> to inform users of the change ?  or do we want a news item ?
>>>
>>> what's the flag to negate the default ?  --no-quiet-build ? ;)
>>> -mike
>>
>> It's --quiet-build=n. I've gone ahead and enabled it for release in
>> portage-2.1.10.34:
>>
>>
>> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc174b6fc28feb26ea151d76f794e0ff2c2fa39
>>
> Lots of people in #gentoo are unhappy with it.
>
> Most devs will be unhappy as it makes it harder to view the log while
> building.
>
> Please consider reverting it and let users set it with EMERGE_DEFAULT_OPTS
> if they want it less noisy.

+1


-- 
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/

Re: [gentoo-dev] have portage be quiet by default

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 973 bytes --]

On Saturday 12 November 2011 17:24:08 Patrick Lauer wrote:
> On 11/11/11 16:44, Zac Medico wrote:
> >> good point.  we don't want to punish old portage users.  let's enable it
> >> by default in portage itself then.  just add `elog` output to the
> >> portage ebuild to inform users of the change ?  or do we want a news
> >> item ?
> >> 
> >> what's the flag to negate the default ?  --no-quiet-build ? ;)
> > 
> > It's --quiet-build=n. I've gone ahead and enabled it for release in
> > portage-2.1.10.34:
> > 
> > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc1
> > 74b6fc28feb26ea151d76f794e0ff2c2fa39
> 
> Lots of people in #gentoo are unhappy with it.

most changes people will be unhappy with because it's different

> Most devs will be unhappy as it makes it harder to view the log while
> building.

devs are not the normal case.  it's trivial to have them use --quiet-build=n 
in their default emerge opts.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Nirbheek Chauhan]

On Sun, Nov 13, 2011 at 5:10 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Saturday 12 November 2011 17:24:08 Patrick Lauer wrote:
>> Lots of people in #gentoo are unhappy with it.
>
> most changes people will be unhappy with because it's different
>

This is objectively true. That's why you weigh changes based on
whether they yield a net gain.

I don't have strong opinions about this, but from the beginning, I've
thought that *always* showing verbose output in emerge wasn't really
useful for general users except as a CPU-intensive screensaver.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] have portage be quiet by default

[Rafael Goncalves Martins]

On Sat, Nov 12, 2011 at 9:40 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Saturday 12 November 2011 17:24:08 Patrick Lauer wrote:
>> On 11/11/11 16:44, Zac Medico wrote:
>> >> good point.  we don't want to punish old portage users.  let's enable it
>> >> by default in portage itself then.  just add `elog` output to the
>> >> portage ebuild to inform users of the change ?  or do we want a news
>> >> item ?
>> >>
>> >> what's the flag to negate the default ?  --no-quiet-build ? ;)
>> >
>> > It's --quiet-build=n. I've gone ahead and enabled it for release in
>> > portage-2.1.10.34:
>> >
>> > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc1
>> > 74b6fc28feb26ea151d76f794e0ff2c2fa39
>>
>> Lots of people in #gentoo are unhappy with it.
>
> most changes people will be unhappy with because it's different
>
>> Most devs will be unhappy as it makes it harder to view the log while
>> building.
>
> devs are not the normal case.  it's trivial to have them use --quiet-build=n
> in their default emerge opts.

Then why not you and the other 2 guys that approved this change here
(and are the only people I saw approving this, TBH), add
--quiet-build=y to your default emerge opts and avoid this kind of
change?

Regards,

-- 
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/

Re: [gentoo-dev] have portage be quiet by default

[Mike Gilbert]

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

On 11/12/2011 06:49 PM, Rafael Goncalves Martins wrote:
> Then why not you and the other 2 guys that approved this change here
> (and are the only people I saw approving this, TBH), add
> --quiet-build=y to your default emerge opts and avoid this kind of
> change?

I like the new default.

Anyone using the --jobs option has seen this behavior for a while.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Gilles Dartiguelongue]

Le samedi 12 novembre 2011 à 21:49 -0200, Rafael Goncalves Martins a
écrit :
> Then why not you and the other 2 guys that approved this change here
> (and are the only people I saw approving this, TBH), add
> --quiet-build=y to your default emerge opts and avoid this kind of
> change?
> 
> Regards,
> 

I like the new default too, it's true that I could just enable this
myself but I don't see any good in having it verbose by default as
properly explained in this already long thread.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

Re: [gentoo-dev] have portage be quiet by default

[Hilco Wijbenga]

On 12 November 2011 15:40, Mike Frysinger <vapier@gentoo.org> wrote:
> On Saturday 12 November 2011 17:24:08 Patrick Lauer wrote:
>> On 11/11/11 16:44, Zac Medico wrote:
>> >> good point.  we don't want to punish old portage users.  let's enable it
>> >> by default in portage itself then.  just add `elog` output to the
>> >> portage ebuild to inform users of the change ?  or do we want a news
>> >> item ?
>> >>
>> >> what's the flag to negate the default ?  --no-quiet-build ? ;)
>> >
>> > It's --quiet-build=n. I've gone ahead and enabled it for release in
>> > portage-2.1.10.34:
>> >
>> > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc1
>> > 74b6fc28feb26ea151d76f794e0ff2c2fa39
>>
>> Lots of people in #gentoo are unhappy with it.
>
> most changes people will be unhappy with because it's different

I'm a bit surprised by the negative comments. I was pleasantly
surprised this morning when I discovered the clean output now
generated by default by Portage.

After all, most of the time the build logs are "useless". By that I
mean that one only looks at them when the build fails. So not seeing
them by default seems the right thing to do. This may not always be
true (especially for devs) but changing the default is very simple in
those special cases.

By the way, is there a noticeable difference in build time (for
relatively large builds) when logging to the console is off? Not
important, just curious.

>> Most devs will be unhappy as it makes it harder to view the log while
>> building.
>
> devs are not the normal case.  it's trivial to have them use --quiet-build=n
> in their default emerge opts.
> -mike

[gentoo-dev] Re: have portage be quiet by default

[Duncan]

Hilco Wijbenga posted on Sat, 12 Nov 2011 16:05:36 -0800 as excerpted:

> By the way, is there a noticeable difference in build time (for
> relatively large builds) when logging to the console is off? Not
> important, just curious.

There can be.  AFAIK it's not too bad when output is to a vgacon text-
console, but to frame-buffer (kms mode text console or X) tends to be 
more CPU intensive and to slow things down if you're bottlenecking on CPU 
as is often (but not always, especially on multi-core systems without 
emerge --jobs set to allow multiple parallel package emerges at once, as 
well as MAKEOPTS=-j, to allow multiple make jobs with a single merge job) 
the case.  Terminal windows tend to use what a text console framebuffer 
does, often more, depending on effects and how much is hardware 
accelerated.

Perhaps the biggest efficiency gain, however, if you have 4 gig plus of 
memory (and a 64-bit system to handle it reasonably efficiently), is to 
point PORTAGE_TMPDIR at a tmpfs and control its size and the number of 
parallel jobs to avoid more than a few MB of swappage.  Based on my 
experience here, with four or even at two cores, the load average doesn't 
bog down the system anywhere close to what disk I/O does, regardless of 
whether it's swap or conventional disk I/O access.  Putting the temp-dir 
in tmpfs means a lot of scratch files are never written to disk at all, 
thus saving that disk access, and theoretically it could even save if 
you're into swap (forums or user list for the details), but obviously far 
less then, so I now set jobs and load average to best control, if 
indirectly, for memory usage including the tmpfs, as opposed to direct 
CPU load control.

But there's whole threads on optimizing emerges on the forums and user 
list.  This really isn't the place for further discussion on that.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] have portage be quiet by default

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/12/2011 11:40 PM, Mike Frysinger wrote:
> 
> devs are not the normal case.  it's trivial to have them use
> --quiet-build=n in their default emerge opts. -mike
Or add --quiet-build=n to dev/ profiles.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOv61hAAoJEPqDWhW0r/LCkV8P/jq/tz3KuId1irz6N3BsbFgg
xbqVgrrNrzxynt9QRrv6u/5U1I2IWwZ4oICtL7upLx038wSOMZrkpaysgubbhRwp
YRCCJjX+xRwgLjrodDcwNFAcdOcrw0DI4/bmNxwzL0GBHN0yiRcRCZYO6j/bqf5Z
7rlRQbPHoBdfZknVnKNliVK+PsGNP51PLosWPfqumTb8XiwSaxypOFOl4r9NccNv
GjHhHqL5t93zjZ2vJGE0qf8mi7+4sOjt8vXmd1+ZvYKVweXloDcrKwEA8V9EVYtn
MjrWo3IOhbY3XSJyYU4iSVA9WfSNHrvrnEMw1On7skYW1iaJdGm1P6Hy5kPZhS3A
3v8XMkm/QdL0J98k06VuqaUd6S50+u35Fp38l5kFuFwo1+i7bnU/eBv0I+3B4DjL
qPH+2i6HnR28hqF0IZNh3kwe+JBsUyZAT2h78CaDXDvEGMdThfQ/Lgj2ff1XyqpG
50R2pWBezdwHQQF7j33Kt4f6S4ngMLo79KD0zFZjP3WDKKNHbOWBvIQNCpP7UW9g
UEGnoltkca2B9WFTS3kR9e4UVqu80CGD3/dKCJHNz05tb5ZaHoSjHkPHdBkGDl9l
+0XDybir3YSvXWdC32wd8FxX16xYGG3pEU2LbXYFkGKffGf87cXoaXdJAZIBk91p
ea8hiBof9TmVpdoBtzvW
=W8pw
-----END PGP SIGNATURE-----

Re: [gentoo-dev] have portage be quiet by default

[Thomas Sachau]

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

Mike Frysinger schrieb:
> On Saturday 12 November 2011 17:24:08 Patrick Lauer wrote:
>> On 11/11/11 16:44, Zac Medico wrote:
>>>> good point.  we don't want to punish old portage users.  let's enable it
>>>> by default in portage itself then.  just add `elog` output to the
>>>> portage ebuild to inform users of the change ?  or do we want a news
>>>> item ?
>>>>
>>>> what's the flag to negate the default ?  --no-quiet-build ? ;)
>>>
>>> It's --quiet-build=n. I've gone ahead and enabled it for release in
>>> portage-2.1.10.34:
>>>
>>> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc1
>>> 74b6fc28feb26ea151d76f794e0ff2c2fa39
>>
>> Lots of people in #gentoo are unhappy with it.
> 
> most changes people will be unhappy with because it's different
> 
>> Most devs will be unhappy as it makes it harder to view the log while
>> building.
> 
> devs are not the normal case.  it's trivial to have them use --quiet-build=n 
> in their default emerge opts.
> -mike

This can be argued from either side, if the default is verbose, you can make it quiet in the default
emerge opts and the other way round. So this is no argument for or against default quiet build in my
eyes.

As already said, it is nice to see, where a build hangs, when some specific task does take longer
and until now, it was easy to see, just watch the output. With the new default, you cannot say, what
it does, where it may be or if there are many things or just one line taking much time. And you
additionally have to go to the build.log manually to actually see something.
In addition, it is also nice to just a quick look into the console to see, what and where it failed.

Both points are probably not only usefull to devs, but also to many users, in addition to the point,
that changing the default emerge opts gets time consuming, when you have more than 1 or 2 machines.
Additionally, not every machine used by a dev will or should be using a dev/ profile, so changing
the default there will not fix the issue.

So i also vote for a revert of this. If you dont want to see the output for whatever reason, you can
still make it quiet, but i have not yet seen any reason to make it quiet by default for everyone.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 380 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Amadeusz Żołnowski]

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

Excerpts from Thomas Sachau's message of 2011-11-13 13:39:17 +0100:
> This can be argued from either side, if the default is verbose, you
> can make it quiet in the default emerge opts and the other way round.
> So this is no argument for or against default quiet build in my eyes.

Not every user studies manpages of every program they use.  Making
--quiet-build=y default is a *benefit* for people who don't care much.
If somebody cares about the output probably will care to read the
manpage how to make it verbose.  How many emerge users know that option?


> As already said, it is nice to see, where a build hangs, when some
> specific task does take longer and until now, it was easy to see, just
> watch the output. With the new default, you cannot say, what it does,
> where it may be or if there are many things or just one line taking
> much time. And you additionally have to go to the build.log manually
> to actually see something.

Build output tells almost nothing about the progress (except of cmake).
Many packages compile in few minutes on average machine.  I hardly ever
experience hangs and if - it's usually for boost.  For those few
packages it's no harm to check build.log.

But --quiet-build=y actually gives more useful and handy info: what is
a total progress.  Which user cares about which module is actually being
compiled?  He/she cares more which package out of total is being
compiled at the moment.


> In addition, it is also nice to just a quick look into the console to
> see, what and where it failed.

When it fails, it prints tail of build.log.


-- 
Amadeusz Żołnowski

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

Re: [gentoo-dev] have portage be quiet by default

[Thomas Sachau]

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

Amadeusz Żołnowski schrieb:
> Excerpts from Thomas Sachau's message of 2011-11-13 13:39:17 +0100:
>> This can be argued from either side, if the default is verbose, you
>> can make it quiet in the default emerge opts and the other way round.
>> So this is no argument for or against default quiet build in my eyes.
> 
> Not every user studies manpages of every program they use.  Making
> --quiet-build=y default is a *benefit* for people who don't care much.
> If somebody cares about the output probably will care to read the
> manpage how to make it verbose.  How many emerge users know that option?

How is that an argument for default quiet build? It is exactly the same argument against default
quiet build. If someone does not care, he does not care about the output being verbose or not, so no
need to change a default for him.
And what does a number of users knowing about an option have to do with a default setting?
> 
> 
>> As already said, it is nice to see, where a build hangs, when some
>> specific task does take longer and until now, it was easy to see, just
>> watch the output. With the new default, you cannot say, what it does,
>> where it may be or if there are many things or just one line taking
>> much time. And you additionally have to go to the build.log manually
>> to actually see something.
> 
> Build output tells almost nothing about the progress (except of cmake).
> Many packages compile in few minutes on average machine.  I hardly ever
> experience hangs and if - it's usually for boost.  For those few
> packages it's no harm to check build.log.

You expect people to manually check the build.log just to see, where it hangs? I prefer checking the
console, there i can see it directly and dont have to check for the path of the current build.log
and then have to additionally open it manually. So your "no harm" is plain wrong, since it takes me
more time for doing the same thing as before, while i still see no benefit for the change of the
default.

> 
> But --quiet-build=y actually gives more useful and handy info: what is
> a total progress.  Which user cares about which module is actually being
> compiled?  He/she cares more which package out of total is being
> compiled at the moment.

If someone does not care about the current state of a compile, he wont care about the total state
either. Beside the point, that you can see the total state in the terminal bar (i hope, i got the
right name for that thing).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 380 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Amadeusz Żołnowski]

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

Excerpts from Thomas Sachau's message of 2011-11-13 14:59:57 +0100:
> How is that an argument for default quiet build? It is exactly the
> same argument against default quiet build. If someone does not care,
> he does not care about the output being verbose or not, so no need to
> change a default for him.

As I have written below, information about overall process is more
valuable than some gmake rubbish (to the user) output which slows down
build time.  And having that shinny human readable output gives actually
an information to the reader.


> And what does a number of users knowing about an option have to do
> with a default setting?

More user-friendly options should be default, not developer-friendly.
The discussion started with problem, that build.log could be more
verbose, which will clutter users' screen even more.


> You expect people to manually check the build.log just to see, where
> it hangs? I prefer checking the console, there i can see it directly
> and dont have to check for the path of the current build.log and then
> have to additionally open it manually. So your "no harm" is plain
> wrong, since it takes me more time for doing the same thing as before,
> while i still see no benefit for the change of the default.

If you need to watch build output, change defaults.  Defaults are for
less experienced users, not for us developers or power users.


> > But --quiet-build=y actually gives more useful and handy info: what
> > is a total progress.  Which user cares about which module is
> > actually being compiled?  He/she cares more which package out of
> > total is being compiled at the moment.
> 
> If someone does not care about the current state of a compile, he wont
> care about the total state either.

Build output hardly ever says about current state of a compile.  If you
can tell from the output how much is left for example for firefox -
respect.


> Beside the point, that you can see the total state in the terminal bar
> (i hope, i got the right name for that thing).

This not always work.


-- 
Amadeusz Żołnowski

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

Re: [gentoo-dev] have portage be quiet by default

[Thomas Sachau]

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

Amadeusz Żołnowski schrieb:
> Excerpts from Thomas Sachau's message of 2011-11-13 14:59:57 +0100:
>> How is that an argument for default quiet build? It is exactly the
>> same argument against default quiet build. If someone does not care,
>> he does not care about the output being verbose or not, so no need to
>> change a default for him.
> 
> As I have written below, information about overall process is more
> valuable than some gmake rubbish (to the user) output which slows down
> build time.  And having that shinny human readable output gives actually
> an information to the reader.
> 
> 
>> And what does a number of users knowing about an option have to do
>> with a default setting?
> 
> More user-friendly options should be default, not developer-friendly.
> The discussion started with problem, that build.log could be more
> verbose, which will clutter users' screen even more.

And you do define, what is user-friendly and what not? :-)

Remember, that every developer is also a user. And i hope, you dont define user-friendlyness the
same way as some say about gnome upstream: the less the user gets or sees, the more user friendly
the application will be.
While the quiet-build setting suppresses everything, the verbose output does not harm me (more lines
dont reduce the time i can use that screen or anything similar), but it can tell me something about
the actual build process (even if it is only some basics like "still doing the time-consuming
confiure phase, still compiling, currently at linking stage, for some packages even more detailed).

Please give me a good reason, why i should by default do more things (adding quiet-build=n to the
default emerge opts or searching for and opening the build.log) and what i or others do get from
that. And less lines on the screen is no added value for me, it removes value.

> 
> 
>> You expect people to manually check the build.log just to see, where
>> it hangs? I prefer checking the console, there i can see it directly
>> and dont have to check for the path of the current build.log and then
>> have to additionally open it manually. So your "no harm" is plain
>> wrong, since it takes me more time for doing the same thing as before,
>> while i still see no benefit for the change of the default.
> 
> If you need to watch build output, change defaults.  Defaults are for
> less experienced users, not for us developers or power users.

I disagree. Defaults should not be for a specific user group, they should be adding most possible
values without doing harm. Otherwise everyone could see a different user group as target and see
himself as right without any chance for a consensus.

> 
> 
>>> But --quiet-build=y actually gives more useful and handy info: what
>>> is a total progress.  Which user cares about which module is
>>> actually being compiled?  He/she cares more which package out of
>>> total is being compiled at the moment.
>>
>> If someone does not care about the current state of a compile, he wont
>> care about the total state either.
> 
> Build output hardly ever says about current state of a compile.  If you
> can tell from the output how much is left for example for firefox -
> respect.

So you can get anything from "build 8 of 124" or "build 1 of 2"? This is similar to verbose build
output: It could tell you, which package currently is compiled, but you dont get any specific
details like "How long until finished?" or "How much more time until finished?", since even the last
remaining package could require 99% of total build/install time.
So if you like details about total state, why do you want to hide the state of the current compile?

> 
> 
>> Beside the point, that you can see the total state in the terminal bar
>> (i hope, i got the right name for that thing).
> 
> This not always work.

Sure, you can work inside a screen without such a bar. So in such a case, you dont have any detail
from this feature. But do you ignore such a feature, just because some people might not be able or
willing to see it? And do you want to replace other output a user can get by this one just to be
sure everyone gets this by default?


I have 2 additional questions:

1. Who defines, what the default should be and when it is acceptable to force an unknown amount of
users to change their settings?

2. Since this change is obviously controversal now, will it be reverted or do the people arguing
against the change have to somehow force a revert or proove it being less good than the previous
default (also thinking about how such a proove could be done) to get the new behaviour changed or
reverted?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 380 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Rich Freeman]

On Sun, Nov 13, 2011 at 10:49 AM, Thomas Sachau <tommy@gentoo.org> wrote:
> 1. Who defines, what the default should be and when it is acceptable to force an unknown amount of
> users to change their settings?

Well, this did go on a mailing list, and so far we have all of 13
unique participants, so this seems like a bit of a tempest in a teapot
considering that the change is trivial to undo.

I'll admit that it is pretty subjective either way, and that is just
more of a reason not to turn it into a huge controversy.  Users who
would be most sensitive to changes won't even see this until it hits
stable (if you don't like change, you shouldn't be running ~arch).

This is actually the sort of thing that might make for a good news
item (hey, we have a new setting and if you don't like it just do
this...).

Ultimately I think that it is up to the team maintaining a particular
component of the distro to make initial determinations of how that
component should behave, of course consulting with the list about
things likely to be of wide interest is always good but this was done
in this case.

If people want to appeal there is always making an appeal to the team
lead, and then to the Council.    There should be no reprimands or
stigma associated with having a decision reversed by the Council -
people shouldn't have to second-guess minor decisions like this.

I don't think it serves Gentoo to call for a vote (council, devs, or
otherwise) every time somebody wants to change the portage defaults,
especially regarding matters that are cosmetic.

Rich

Re: [gentoo-dev] have portage be quiet by default

[Matthew Summers]

On Sun, Nov 13, 2011 at 9:59 AM, Rich Freeman <rich0@gentoo.org> wrote:
> this seems like a bit of a tempest in a teapot

It cracks me up, this colloquialism.

Please don't change this back. </$0.02>

In theory, this should make Portage slightly more efficient since it
won't be performing the simultaneous operation of spewing to a file
and stdout.

> considering that the change is trivial to undo.

Perhaps this will entice our most excellent user base to read the man
page from time to time to see what new features might crop up. Had I
known this option existed I would have set it a long time ago.
Although, now I am concerned that my IQ may be caused to decline since
I will not be soaking up learning via the osmotic process of blankly
staring at builds screaming by on my machine.

For those that want to see the build output in real time, for
development purposes or otherwise, it is trivial to change on a more
permanent basis via EMERGE_DEFAULT_OPTS or on a case by case basis by
adding --quiet-build=n to the command invocation.

Change is hard, but this one yields some boost in efficiency and noise
reduction. So cheerio.

Many thanks,
quantum
-- 
Matthew W. Summers
Gentoo Foundation Inc.

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/13/2011 07:49 AM, Thomas Sachau wrote:
> Please give me a good reason, why i should by default do more things (adding quiet-build=n to the
> default emerge opts or searching for and opening the build.log) and what i or others do get from
> that. And less lines on the screen is no added value for me, it removes value.

Why should we expose new users to legacy defaults that are useless to
more than 99% users, when they would most likely prefer the
--quiet-build display?
-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Thomas Sachau]

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

Zac Medico schrieb:
> On 11/13/2011 07:49 AM, Thomas Sachau wrote:
>> Please give me a good reason, why i should by default do more things (adding quiet-build=n to the
>> default emerge opts or searching for and opening the build.log) and what i or others do get from
>> that. And less lines on the screen is no added value for me, it removes value.
> 
> Why should we expose new users to legacy defaults that are useless to
> more than 99% users, when they would most likely prefer the
> --quiet-build display?

Why should we change the default behaviour for existing users? Those, who dont want to see it,
probably already use --jobs or quiet-build=y. For the rest, they either dont know about those
options (which does not get better, if some default behaviour changes) or they dont want those
options (in which case you force them to change their configuration/scripts/way to do things).

Additionally, do you have any numbers about existing or new users and about the percentage, which
would like the build output to be quiet? Otherwise i see such lines as guess and could say the same
about the exact opposite view ;-)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 380 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/13/2011 03:09 PM, Thomas Sachau wrote:
> Zac Medico schrieb:
>> On 11/13/2011 07:49 AM, Thomas Sachau wrote:
>>> Please give me a good reason, why i should by default do more things (adding quiet-build=n to the
>>> default emerge opts or searching for and opening the build.log) and what i or others do get from
>>> that. And less lines on the screen is no added value for me, it removes value.
>>
>> Why should we expose new users to legacy defaults that are useless to
>> more than 99% users, when they would most likely prefer the
>> --quiet-build display?
> 
> Why should we change the default behaviour for existing users? Those, who dont want to see it,
> probably already use --jobs or quiet-build=y. For the rest, they either dont know about those
> options (which does not get better, if some default behaviour changes) or they dont want those
> options (in which case you force them to change their configuration/scripts/way to do things).

When we change defaults, it affects everyone who hasn't yet overridden
the setting in EMERGE_DEFAULT_OPTS. That's just how it is.

> Additionally, do you have any numbers about existing or new users and about the percentage, which
> would like the build output to be quiet?

All I have is the feedback from this mailing list, an my own intuition.
My intuition says that --quiet-build is reasonable default that the
silent majority of people will welcome.

> Otherwise i see such lines as guess and could say the same
> about the exact opposite view ;-)

Well, my interpretation of this thread says that the response is
overwhelmingly positive, but I could be biased. ;)
-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Chí-Thanh Christopher Nguyễn]

Zac Medico schrieb:
> All I have is the feedback from this mailing list, an my own intuition.
> My intuition says that --quiet-build is reasonable default that the
> silent majority of people will welcome.

Per discussion on IRC, I propose to make -v turn off quiet-build by default.
It can remain enabled by default if -v is not passed to emerge.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/13/2011 04:24 PM, Chí-Thanh Christopher Nguyễn wrote:
> Zac Medico schrieb:
>> All I have is the feedback from this mailing list, an my own intuition.
>> My intuition says that --quiet-build is reasonable default that the
>> silent majority of people will welcome.
> 
> Per discussion on IRC, I propose to make -v turn off quiet-build by default.
> It can remain enabled by default if -v is not passed to emerge.

I think -v controls too many other things to make it override
--quiet-build, especially since I consider --quiet-build=n to be a mode
that most people would prefer to avoid.
-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Chí-Thanh Christopher Nguyễn]

Zac Medico schrieb:
>> Per discussion on IRC, I propose to make -v turn off quiet-build by default.
>> It can remain enabled by default if -v is not passed to emerge.
> 
> I think -v controls too many other things to make it override
> --quiet-build, especially since I consider --quiet-build=n to be a mode
> that most people would prefer to avoid.

No, in my proposal --quiet-build would override -v, not the other way round.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/13/2011 04:36 PM, Chí-Thanh Christopher Nguyễn wrote:
> Zac Medico schrieb:
>>> Per discussion on IRC, I propose to make -v turn off quiet-build by default.
>>> It can remain enabled by default if -v is not passed to emerge.
>>
>> I think -v controls too many other things to make it override
>> --quiet-build, especially since I consider --quiet-build=n to be a mode
>> that most people would prefer to avoid.
> 
> No, in my proposal --quiet-build would override -v, not the other way round.

Your proposal was for -v to override the new default --quiet-build
setting, was it not?
-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Chí-Thanh Christopher Nguyễn]

Zac Medico schrieb:
> On 11/13/2011 04:36 PM, Chí-Thanh Christopher Nguyễn wrote:
>> Zac Medico schrieb:
>>>> Per discussion on IRC, I propose to make -v turn off quiet-build by default.
>>>> It can remain enabled by default if -v is not passed to emerge.
>>>
>>> I think -v controls too many other things to make it override
>>> --quiet-build, especially since I consider --quiet-build=n to be a mode
>>> that most people would prefer to avoid.
>>
>> No, in my proposal --quiet-build would override -v, not the other way round.
> 
> Your proposal was for -v to override the new default --quiet-build
> setting, was it not?

To be more explicit:
1) "emerge foo": quiet build
2) "emerge foo --quiet-build=n": non-quiet build
3) "emerge foo -v": non-quiet build
4) "emerge foo -v --quiet-build=y": quiet-build

So -v sets the default for quiet build, but user can still override with
explicit --quiet-build=...

I think the case 1) covers the arguments in favour of having quiet build
by default.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/13/2011 04:45 PM, Chí-Thanh Christopher Nguyễn wrote:
> Zac Medico schrieb:
>> On 11/13/2011 04:36 PM, Chí-Thanh Christopher Nguyễn wrote:
>>> Zac Medico schrieb:
>>>>> Per discussion on IRC, I propose to make -v turn off quiet-build by default.
>>>>> It can remain enabled by default if -v is not passed to emerge.
>>>>
>>>> I think -v controls too many other things to make it override
>>>> --quiet-build, especially since I consider --quiet-build=n to be a mode
>>>> that most people would prefer to avoid.
>>>
>>> No, in my proposal --quiet-build would override -v, not the other way round.
>>
>> Your proposal was for -v to override the new default --quiet-build
>> setting, was it not?
> 
> To be more explicit:
> 1) "emerge foo": quiet build
> 2) "emerge foo --quiet-build=n": non-quiet build
> 3) "emerge foo -v": non-quiet build
> 4) "emerge foo -v --quiet-build=y": quiet-build
> 
> So -v sets the default for quiet build, but user can still override with
> explicit --quiet-build=...
> 
> I think the case 1) covers the arguments in favour of having quiet build
> by default.

I think that's too fragile because you could easily have people using -v
and getting the --quiet-build=n behavior even though they didn't want
it. I think most people would prefer to avoid the --quiet-build=n
behavior since, generally, people who want to analyze build output are
better served by PORT_LOGDIR.
-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Chí-Thanh Christopher Nguyễn]

Zac Medico schrieb:
>> To be more explicit:
>> 1) "emerge foo": quiet build
>> 2) "emerge foo --quiet-build=n": non-quiet build
>> 3) "emerge foo -v": non-quiet build
>> 4) "emerge foo -v --quiet-build=y": quiet-build
>>
>> So -v sets the default for quiet build, but user can still override with
>> explicit --quiet-build=...
>>
>> I think the case 1) covers the arguments in favour of having quiet build
>> by default.
> 
> I think that's too fragile because you could easily have people using -v
> and getting the --quiet-build=n behavior even though they didn't want
> it. I think most people would prefer to avoid the --quiet-build=n
> behavior since, generally, people who want to analyze build output are
> better served by PORT_LOGDIR.

I think it is a solution which most of the critics of quiet-build could
live with and users still won't see build output by default.

If a user passes -v and as a result sees build output, I think he won't
be confused or angry about it.[1]


Best regards,
Chí-Thanh Christopher Nguyễn

[1] http://xkcd.com/242/

Re: [gentoo-dev] have portage be quiet by default

[Thomas Sachau]

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

Zac Medico schrieb:
> On 11/13/2011 03:09 PM, Thomas Sachau wrote:
>> Zac Medico schrieb:
>>> On 11/13/2011 07:49 AM, Thomas Sachau wrote:
>>>> Please give me a good reason, why i should by default do more things (adding quiet-build=n to the
>>>> default emerge opts or searching for and opening the build.log) and what i or others do get from
>>>> that. And less lines on the screen is no added value for me, it removes value.
>>>
>>> Why should we expose new users to legacy defaults that are useless to
>>> more than 99% users, when they would most likely prefer the
>>> --quiet-build display?
>>
>> Why should we change the default behaviour for existing users? Those, who dont want to see it,
>> probably already use --jobs or quiet-build=y. For the rest, they either dont know about those
>> options (which does not get better, if some default behaviour changes) or they dont want those
>> options (in which case you force them to change their configuration/scripts/way to do things).
> 
> When we change defaults, it affects everyone who hasn't yet overridden
> the setting in EMERGE_DEFAULT_OPTS. That's just how it is.

So you have no problem changing the expected behaviour for the existing user, who already got used
to the output or adjusted it themselves and might even rely on the verbose output? Additionally i
have not seen any message from portage telling me about this change, so most users wont know, what
changed or how to revert the change...

I would at least expect some longer waiting period in the "discussion" before doing such changes or
presenting some real numbers before doing such change.
> 
>> Additionally, do you have any numbers about existing or new users and about the percentage, which
>> would like the build output to be quiet?
> 
> All I have is the feedback from this mailing list, an my own intuition.
> My intuition says that --quiet-build is reasonable default that the
> silent majority of people will welcome.
> 
>> Otherwise i see such lines as guess and could say the same
>> about the exact opposite view ;-)
> 
> Well, my interpretation of this thread says that the response is
> overwhelmingly positive, but I could be biased. ;)

You are obviously biased, since you prefer the quiet output. ;-)
The numbers of commenting people in here are way too low to say anything, but there is obviously no
big majority for either side, which implies to me, that such a change should not have been done in
the first place and should be reverted.
And just for the record: If i am not responding during the next 14 (timeframe between suggestion and
implementation) or more hours, this does not mean, that i changed my mind, it just means, that i
have also other things to do ;-)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 380 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Chí-Thanh Christopher Nguyễn]

Thomas Sachau schrieb:

> The numbers of commenting people in here are way too low to say anything,

To get more numbers, I created a forum poll as suggested by ferringb.

http://forums.gentoo.org/viewtopic-t-901858.html (plain)
https://forums.gentoo.org/viewtopic-t-901858.html (ssl)


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/13/2011 05:27 PM, Thomas Sachau wrote:
> Zac Medico schrieb:
>> On 11/13/2011 03:09 PM, Thomas Sachau wrote:
>>> Zac Medico schrieb:
>>>> On 11/13/2011 07:49 AM, Thomas Sachau wrote:
>>>>> Please give me a good reason, why i should by default do more things (adding quiet-build=n to the
>>>>> default emerge opts or searching for and opening the build.log) and what i or others do get from
>>>>> that. And less lines on the screen is no added value for me, it removes value.
>>>>
>>>> Why should we expose new users to legacy defaults that are useless to
>>>> more than 99% users, when they would most likely prefer the
>>>> --quiet-build display?
>>>
>>> Why should we change the default behaviour for existing users? Those, who dont want to see it,
>>> probably already use --jobs or quiet-build=y. For the rest, they either dont know about those
>>> options (which does not get better, if some default behaviour changes) or they dont want those
>>> options (in which case you force them to change their configuration/scripts/way to do things).
>>
>> When we change defaults, it affects everyone who hasn't yet overridden
>> the setting in EMERGE_DEFAULT_OPTS. That's just how it is.
> 
> So you have no problem changing the expected behaviour for the existing user, who already got used
> to the output or adjusted it themselves and might even rely on the verbose output? Additionally i
> have not seen any message from portage telling me about this change, so most users wont know, what
> changed or how to revert the change...

It's in the ebuild ChangeLog, the RELEASE-NOTES, and there's also an
elog message that's triggered when upgrading from less than
portage-2.1.10.34 (portage-2.2.x users won't see the elog message, of
course).

I think it's worth noting that there's no guarantee that a given person
who sees one of these notifications will make a mental connection
between the notification and the new behavior that they will observe
from emerge at a later time. The time gap leaves lots of room for a lack
of comprehension.

> I would at least expect some longer waiting period in the "discussion" before doing such changes or
> presenting some real numbers before doing such change.

Well, the initial feedback was all positive. By deploying the change, it
has enabled us to gather more interest and get more feedback.

>>> Additionally, do you have any numbers about existing or new users and about the percentage, which
>>> would like the build output to be quiet?
>>
>> All I have is the feedback from this mailing list, an my own intuition.
>> My intuition says that --quiet-build is reasonable default that the
>> silent majority of people will welcome.
>>
>>> Otherwise i see such lines as guess and could say the same
>>> about the exact opposite view ;-)
>>
>> Well, my interpretation of this thread says that the response is
>> overwhelmingly positive, but I could be biased. ;)
> 
> You are obviously biased, since you prefer the quiet output. ;-)
> The numbers of commenting people in here are way too low to say anything, but there is obviously no
> big majority for either side, which implies to me, that such a change should not have been done in
> the first place and should be reverted.

Well, it's much easier to gather interest and get feedback if we deploy
the change and ask questions later.
-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Alex Alexander]

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

On Sun, Nov 13, 2011 at 05:59:21PM -0800, Zac Medico wrote:
> Well, it's much easier to gather interest and get feedback if we deploy
> the change and ask questions later.

What if we tried solving this problem by providing more options instead
of trying to guess what the users want? :)

Imagine the following output (when jobs == 1):

>>> Verifying ebuild manifests
>>> Emerging (1 of 1) www-client/chromium-16.0.912.36
>>> Quiet building enabled. Enable for [P]ackage or [S]ession. [L]earn more.
>>> Jobs: 0 of 1 complete, 1 running                Load avg: 0.23, 0.18, 0.10

Pressing P would only show the log for the actively built package.
Pressing S would show all the logs for this session, starting with the
active one.

Pressing L would print out a short set of instructions, something
like:

"To make portage output easier to track and understand, --quiet-build
has been enabled by default. You may restore the old, verbose behavior
temporarily by using the P and S commands, or permanently by adding
'--quiet-build=n' to your make.conf's EMERGE_DEFAULT_OPTS."

I believe many users would appreciate the ability to output logs on
demand. :)
-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[JD Horelick]

On 14 November 2011 03:25, Alex Alexander <wired@gentoo.org> wrote:
> On Sun, Nov 13, 2011 at 05:59:21PM -0800, Zac Medico wrote:
>> Well, it's much easier to gather interest and get feedback if we deploy
>> the change and ask questions later.
>
> What if we tried solving this problem by providing more options instead
> of trying to guess what the users want? :)
>
> Imagine the following output (when jobs == 1):
>
>>>> Verifying ebuild manifests
>>>> Emerging (1 of 1) www-client/chromium-16.0.912.36
>>>> Quiet building enabled. Enable for [P]ackage or [S]ession. [L]earn more.
>>>> Jobs: 0 of 1 complete, 1 running                Load avg: 0.23, 0.18, 0.10
>
> Pressing P would only show the log for the actively built package.
> Pressing S would show all the logs for this session, starting with the
> active one.
>
> Pressing L would print out a short set of instructions, something
> like:
>
> "To make portage output easier to track and understand, --quiet-build
> has been enabled by default. You may restore the old, verbose behavior
> temporarily by using the P and S commands, or permanently by adding
> '--quiet-build=n' to your make.conf's EMERGE_DEFAULT_OPTS."
>
> I believe many users would appreciate the ability to output logs on
> demand. :)
> --
> Alex Alexander | wired
> + Gentoo Linux Developer
> ++ www.linuxized.com
>

IMO, that is *THE PERFECT* solution. It requires writing a significant
amount of code (i'd bet), but IMO, that's perfect and i think all the
rest of the detractors and most of the people in favour of
--quiet-build=y would be happy with that solution.

Another idea I had which is also difficult to implement but would
somewhat solve the "screen full of configure/make output" is to (in
portage) basically parse the output of verbose buildsystems and
reformat them to look like the output of say AutoMake's silent-rules
or CMake. That way each line is like "CC" + filename, as opposed to a
couple hundred character line full of the entire GCC command.

I'd prefer Alex's suggestion though.

Re: [gentoo-dev] have portage be quiet by default

[Patrick Lauer]

On 11/14/11 09:25, Alex Alexander wrote:
> On Sun, Nov 13, 2011 at 05:59:21PM -0800, Zac Medico wrote:
>> Well, it's much easier to gather interest and get feedback if we deploy
>> the change and ask questions later.
> What if we tried solving this problem by providing more options instead
> of trying to guess what the users want? :)
>
> Imagine the following output (when jobs == 1):
>
>>>> Verifying ebuild manifests
>>>> Emerging (1 of 1) www-client/chromium-16.0.912.36
>>>> Quiet building enabled. Enable for [P]ackage or [S]ession. [L]earn more.
>>>> Jobs: 0 of 1 complete, 1 running                Load avg: 0.23, 0.18, 0.10
> Pressing P would only show the log for the actively built package.
> Pressing S would show all the logs for this session, starting with the
> active one.
>
> Pressing L would print out a short set of instructions, something
> like:
>
> "To make portage output easier to track and understand, --quiet-build
> has been enabled by default. You may restore the old, verbose behavior
> temporarily by using the P and S commands, or permanently by adding
> '--quiet-build=n' to your make.conf's EMERGE_DEFAULT_OPTS."
>
> I believe many users would appreciate the ability to output logs on
> demand. :)
Interactive stuff is a bad idea. Please don't make me figure out ways to 
interactively stab you ;)
(I already spent so much time getting interactive ebuilds into a 
manageable state, and that was a more futile discussion than this one)

Why do y'all want to make it harder for me to figure out

1) is it just slow at compiling or stuck in a loop?
2) did it compile with proper settings ( just because the ebuild 
finished with exit code 0 doesn't mean it's correct - yesterday I had to 
turn off quiet-build and re-compile squashfs-tools just to see if the 
build output was as expected)
3) did it install the files I expected it to install? (hmm, why don't I 
have the "znurgh" binary now?!)

Not all failures are detected build failures ...

And handling it over EMERGE_DEFAULT_OPTS is also ugly, if I had anything 
else in there I'd find it quite annoying to figure out how to keep --ask 
--keep-going while disabling --quiet-build selectively.
So it'd be nicer to have a PORTAGE_QUIET_BUILD or similar var in 
make.conf - and still I'm annoyed that I have to spend time unbreaking 
the defaults.

Can we please get this reset to "classic mode" and not try to innovate 
things that worked perfectly well the last decade?


Patrick

Re: [gentoo-dev] have portage be quiet by default

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 267 bytes --]

On Monday 14 November 2011 04:39:50 Patrick Lauer wrote:
> Why do y'all want to make it harder for me to figure out

you've already told you how to put it into verbose mode (it's all of one line 
in your make.conf).  you do it once, and then you're done.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/14/2011 12:25 AM, Alex Alexander wrote:
> On Sun, Nov 13, 2011 at 05:59:21PM -0800, Zac Medico wrote:
>> Well, it's much easier to gather interest and get feedback if we deploy
>> the change and ask questions later.
> 
> What if we tried solving this problem by providing more options instead
> of trying to guess what the users want? :)
> 
> Imagine the following output (when jobs == 1):
> 
>>>> Verifying ebuild manifests
>>>> Emerging (1 of 1) www-client/chromium-16.0.912.36
>>>> Quiet building enabled. Enable for [P]ackage or [S]ession. [L]earn more.
>>>> Jobs: 0 of 1 complete, 1 running                Load avg: 0.23, 0.18, 0.10
> 
> Pressing P would only show the log for the actively built package.
> Pressing S would show all the logs for this session, starting with the
> active one.
> 
> Pressing L would print out a short set of instructions, something
> like:
> 
> "To make portage output easier to track and understand, --quiet-build
> has been enabled by default. You may restore the old, verbose behavior
> temporarily by using the P and S commands, or permanently by adding
> '--quiet-build=n' to your make.conf's EMERGE_DEFAULT_OPTS."
> 
> I believe many users would appreciate the ability to output logs on
> demand. :)

I think that would be an interesting option. We could put stdin in raw
mode, like dispatch-conf does, in order to read single characters of
input instead of whole lines.

I can imagine that this option wouldn't be desired by some people, if
only because emerge would consume all keystrokes from the input buffer.
In the past we had a few portage releases that consumed keystrokes like
that (it was part of the support for interactive ebuilds), and I recall
someone (I think it was grobian) complaining because he had a habit of
typing his next shell command before emerge had completed.
-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Alex Alexander]

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

On Mon, Nov 14, 2011 at 07:19:35AM -0800, Zac Medico wrote:
> On 11/14/2011 12:25 AM, Alex Alexander wrote:
> > On Sun, Nov 13, 2011 at 05:59:21PM -0800, Zac Medico wrote:
> >> Well, it's much easier to gather interest and get feedback if we deploy
> >> the change and ask questions later.
> > 
> > What if we tried solving this problem by providing more options instead
> > of trying to guess what the users want? :)
> > 
> > Imagine the following output (when jobs == 1):
> > 
> >>>> Verifying ebuild manifests
> >>>> Emerging (1 of 1) www-client/chromium-16.0.912.36
> >>>> Quiet building enabled. Enable for [P]ackage or [S]ession. [L]earn more.
> >>>> Jobs: 0 of 1 complete, 1 running                Load avg: 0.23, 0.18, 0.10
> > 
> > Pressing P would only show the log for the actively built package.
> > Pressing S would show all the logs for this session, starting with the
> > active one.
> > 
> > Pressing L would print out a short set of instructions, something
> > like:
> > 
> > "To make portage output easier to track and understand, --quiet-build
> > has been enabled by default. You may restore the old, verbose behavior
> > temporarily by using the P and S commands, or permanently by adding
> > '--quiet-build=n' to your make.conf's EMERGE_DEFAULT_OPTS."
> > 
> > I believe many users would appreciate the ability to output logs on
> > demand. :)
> 
> I think that would be an interesting option. We could put stdin in raw
> mode, like dispatch-conf does, in order to read single characters of
> input instead of whole lines.
> 
> I can imagine that this option wouldn't be desired by some people, if
> only because emerge would consume all keystrokes from the input buffer.
> In the past we had a few portage releases that consumed keystrokes like
> that (it was part of the support for interactive ebuilds), and I recall
> someone (I think it was grobian) complaining because he had a habit of
> typing his next shell command before emerge had completed.

As long as everything is optional, I don't think we'll have any
reasonable complaints.

The stdin raw mode would only be enabled when --quiet-build=y and
--jobs=1. Any other combination would switch to standard mode and we
could also introduce an --allow-options=[y/n] (or similar) parameter for
those who want to completely disable the feature.

I'm confident many users that are currently against quiet-build would
consider it if they were provided with these options :)

Would it be difficult to implement?
-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/15/2011 04:27 AM, Alex Alexander wrote:
> On Mon, Nov 14, 2011 at 07:19:35AM -0800, Zac Medico wrote:
>> On 11/14/2011 12:25 AM, Alex Alexander wrote:
>>> On Sun, Nov 13, 2011 at 05:59:21PM -0800, Zac Medico wrote:
>>>> Well, it's much easier to gather interest and get feedback if we deploy
>>>> the change and ask questions later.
>>>
>>> What if we tried solving this problem by providing more options instead
>>> of trying to guess what the users want? :)
>>>
>>> Imagine the following output (when jobs == 1):
>>>
>>>>>> Verifying ebuild manifests
>>>>>> Emerging (1 of 1) www-client/chromium-16.0.912.36
>>>>>> Quiet building enabled. Enable for [P]ackage or [S]ession. [L]earn more.
>>>>>> Jobs: 0 of 1 complete, 1 running                Load avg: 0.23, 0.18, 0.10
>>>
>>> Pressing P would only show the log for the actively built package.
>>> Pressing S would show all the logs for this session, starting with the
>>> active one.
>>>
>>> Pressing L would print out a short set of instructions, something
>>> like:
>>>
>>> "To make portage output easier to track and understand, --quiet-build
>>> has been enabled by default. You may restore the old, verbose behavior
>>> temporarily by using the P and S commands, or permanently by adding
>>> '--quiet-build=n' to your make.conf's EMERGE_DEFAULT_OPTS."
>>>
>>> I believe many users would appreciate the ability to output logs on
>>> demand. :)
>>
>> I think that would be an interesting option. We could put stdin in raw
>> mode, like dispatch-conf does, in order to read single characters of
>> input instead of whole lines.
>>
>> I can imagine that this option wouldn't be desired by some people, if
>> only because emerge would consume all keystrokes from the input buffer.
>> In the past we had a few portage releases that consumed keystrokes like
>> that (it was part of the support for interactive ebuilds), and I recall
>> someone (I think it was grobian) complaining because he had a habit of
>> typing his next shell command before emerge had completed.
> 
> As long as everything is optional, I don't think we'll have any
> reasonable complaints.
> 
> The stdin raw mode would only be enabled when --quiet-build=y and
> --jobs=1. Any other combination would switch to standard mode and we
> could also introduce an --allow-options=[y/n] (or similar) parameter for
> those who want to completely disable the feature.
> 
> I'm confident many users that are currently against quiet-build would
> consider it if they were provided with these options :)

I don't know, some people are hard to please. :)

> Would it be difficult to implement?

It doesn't seem very difficult. We should be able to use the poll loop
to handle the input, so it won't require a separate thread.

I wouldn't be opposed to adding support for something like this. Since
I'm not really interested in using an interface like that myself, so I
don't feel inspired to implement it myself.
-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Dirkjan Ochtman]

On Mon, Nov 14, 2011 at 02:59, Zac Medico <zmedico@gentoo.org> wrote:
> Well, it's much easier to gather interest and get feedback if we deploy
> the change and ask questions later.

I like the new output, but find it kind of annoying that there's very
little feedback on how far the progress is within a single job.
Perhaps we could show the currently executing ebuild phase in order to
give a little more feedback? Maybe most packages are completely
dominated by src_compile(), but for smaller packages it would be
helpful, IMO.

Cheers,

Dirkjan

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/14/2011 12:47 AM, Dirkjan Ochtman wrote:
> On Mon, Nov 14, 2011 at 02:59, Zac Medico <zmedico@gentoo.org> wrote:
>> Well, it's much easier to gather interest and get feedback if we deploy
>> the change and ask questions later.
> 
> I like the new output, but find it kind of annoying that there's very
> little feedback on how far the progress is within a single job.
> Perhaps we could show the currently executing ebuild phase in order to
> give a little more feedback? Maybe most packages are completely
> dominated by src_compile(), but for smaller packages it would be
> helpful, IMO.

I think that would be an interesting option. I imagine that it would be
too much information for many people, so I don't think that we'd want to
enable it by default.
-- 
Thanks,
Zac

[gentoo-dev] Re: have portage be quiet by default

[Duncan]

Zac Medico posted on Mon, 14 Nov 2011 07:22:19 -0800 as excerpted:

> On 11/14/2011 12:47 AM, Dirkjan Ochtman wrote:
>> On Mon, Nov 14, 2011 at 02:59, Zac Medico <zmedico@gentoo.org> wrote:
>>> Well, it's much easier to gather interest and get feedback if we
>>> deploy the change and ask questions later.
>> 
>> I like the new output, but find it kind of annoying that there's very
>> little feedback on how far the progress is within a single job. Perhaps
>> we could show the currently executing ebuild phase in order to give a
>> little more feedback? Maybe most packages are completely dominated by
>> src_compile(), but for smaller packages it would be helpful, IMO.
> 
> I think that would be an interesting option. I imagine that it would be
> too much information for many people, so I don't think that we'd want to
> enable it by default.

Thanks for thinking "out of the box". =:^)

This is one thing that I've found frustrating with parallel emerging, 
myself.

The first thing I discovered were that some phases (at least the merge 
phase, and I believe install) aren't counted, so the numbers don't 
entirely add up (complete + running + not-started + failed <> total).  
Thus, some packages appear to be simply sitting there doing nothing.  
When a whole bunch of packages are in that state, it appears emerge is 
doing nothing but consuming cycles and real-time, for no visible reason 
at all.

Since for a number of packages (I seem to notice it most on kde packages, 
but perhaps it's all C++ or most CMAKE or some such, plus of course 
primarily data packages that don't have a significant build phase but 
install many or large files) the install phase can be as intense as the 
build phase if not more so, so if some phases aren't counted in 
"running", then I'd definitely prefer they be counted /somewhere/.

Of course, listing the number of packages in each phase (which in single-
mode would by definition list the phase the single package is in) would 
cure the above issue at the same time.

Another problem, but one I'm not sure how to fix (tho the interactive 
display would offer opportunities here), is that it'd be nice to get a 
list of completed packages, in-process packages, and still not started 
packages.  That doesn't so easily fit in a neat summary, but as noted, 
the interactive proposal introduces quite some opportunity, here.

Alternatively, since often the real info desired is the status of a 
particular package, it'd be useful to have either an interactive command 
or a simple separate querying command, that can be run to query the 
status of a particular package.

*** Which brings up an alternative to the whole interactive emerges idea 
as well -- what about a separate command, say "emerging", that when run, 
would simply output a bunch of detail on any pending emerges?

This would certainly offer a safer initial implementation, as well, since 
it's less likely to break the current setup due to bugs, etc.  Another 
noted benefit is that it leaves the existing defaults alone, so it's not 
going to be threatening anyone's sacred cows (or scripted assumptions) in 
terms of how portage has always behaved. =:^)


So, perhaps improve the current "quiet" display marginally, either 
including all phases in "running" or adding another listing so the 
numbers add up, but more importantly...

*** Add a new "emerging" (name up for bikeshedding) command, that 
displays a nice multiline summary, perhaps something like this (the 
second emerge command was for a failure in the first, with a second 
attempt made before completion of the main emerge @world has completed):

Current emerge status:

2 emerge command(s) running.
7 emerge jobs outstanding.

Commands:

** emerge --upgrade --deep --newuse --keep-going @world

Status:

123 of 257 jobs complete, 1 failed, 6 running, 120 not yet started,
7 dependencies removed due to failures.

Running (6):

1 pkgsetup (cat-egory/package-ver)

1 configure (cat-egory/package-ver, cat-egory/package-ver)

2 build (cat-egory/package-ver, cat-egory/package-ver)

1 install (cat-egory/package-ver)

1 merge (cat-egory/package-ver)

Failed (1):

dev-libs/boost-1.47.0-r1

Complete (123):

<list		in		nice		columns>
...

Not started (120):

<list 		in		nice		columns>
...

Removed dependencies due to failure (7):

<list		in		nice		columns>
...


** emerge -u1 boost

Status:

0 of 1 jobs complete, 1 running.

Running (1):

1 build (dev-libs/boost-1.47.0-r1)

Obviously the first implementation might not have all the information 
above, and there might have been some nice information I missed and other 
information that could be displayed better, but it's a very cool idea 
even if I /do/ say so myself. =:^)

Note that zeroed-out listings aren't displayed, so the the --oneshot 
doesn't list failed, not yet started, etc, and inactive phases are also 
not displayed.

Also note how easy this sort of detailed display would make it to retry 
failed jobs and the resulting removed dependencies, once the failure has 
been resolved.

"emerging" could have a "repeat" mode as well as one-shot, with a polling-
delay parameter set to something sane like 30 or 60 seconds by default.  
That way, I wouldn't have to feed it to "watch" =:^)

Because this is a separate command, worries about TMI/TLI should be 
eliminated.  Additionally, it should go some way toward easing the whole 
quiet/noisy debate as well, since there's now another command available 
with an intermediate level of information.

Something like this:

edisplaylog 
If we then throw in one more tool, I'll call it edisplaylog for lack of a 
better name, that reads make.conf to find the elog dir, and can 
automatically pick out the latest log for a package, thus eliminating the 
trouble of doing it manually, that should help eliminate another 
objection to quiet-by-default.  So...

edisplaylog boost

... would find the last elog for boost and display it.

To make things easy for the user, simply ...

edisplaylog

... could be made to filetime search and display the last active log in 
tail -f mode.  If after say a couple seconds of no activity, it re-polled 
the log dir and switched to displaying a different log (have it list the 
log it's displaying at the top) if it was newer, that could pretty much 
replace "noisy" mode entirely.  =:^)

Obviously running simply "edisplaylog" by itself during a parallel-jobs 
emerge would be nearly as confusing as portage not automatically going 
into quiet mode for parallel emerging would be, tho not quite since it 
would display the logfile name at the top, but "edisplaylog <pkg>" would 
still be very useful, ESPECIALLY for those using --keep-going, so they 
could track down and fix whatever failed a build before the parallel 
emerge spit out the results at the end.

Talking about which... an "edisplaylog failed" mode, which would 
automatically find the last failure and displayed the log for it, could 
be very helpful as well. =:^)

Obviously all these ideas entail a lot of coding, and I realize it's easy 
to sit here and make requests without doing the coding, but implementing 
them as separate commands first and incremental implementation should 
help a lot, and I hadn't seen anything like this proposed yet, so...

I'll close with a thanks to Zac and everyone else who has already made 
portage the great tool it is today, because without them, we'd obviously 
not be having this discussion in the first place. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: have portage be quiet by default

[Zac Medico]

On 11/14/2011 03:17 PM, Duncan wrote:
> Zac Medico posted on Mon, 14 Nov 2011 07:22:19 -0800 as excerpted:
> 
>> On 11/14/2011 12:47 AM, Dirkjan Ochtman wrote:
>>> On Mon, Nov 14, 2011 at 02:59, Zac Medico <zmedico@gentoo.org> wrote:
>>>> Well, it's much easier to gather interest and get feedback if we
>>>> deploy the change and ask questions later.
>>>
>>> I like the new output, but find it kind of annoying that there's very
>>> little feedback on how far the progress is within a single job. Perhaps
>>> we could show the currently executing ebuild phase in order to give a
>>> little more feedback? Maybe most packages are completely dominated by
>>> src_compile(), but for smaller packages it would be helpful, IMO.
>>
>> I think that would be an interesting option. I imagine that it would be
>> too much information for many people, so I don't think that we'd want to
>> enable it by default.
> 
> Thanks for thinking "out of the box". =:^)
> 
> This is one thing that I've found frustrating with parallel emerging, 
> myself.
> 
> The first thing I discovered were that some phases (at least the merge 
> phase, and I believe install) aren't counted, so the numbers don't 
> entirely add up (complete + running + not-started + failed <> total). 
> Thus, some packages appear to be simply sitting there doing nothing. 

This behavior is discussed in the "When packages are built in parallel
with the --jobs option, why aren't some packages installed immediately
after they have finished building? They are installed only after a long
delay." section of the FAQ [1].

> When a whole bunch of packages are in that state, it appears emerge is 
> doing nothing but consuming cycles and real-time, for no visible reason 
> at all.

I haven't noticed anything like that. You can send a SIGUSR1 signal to
the emerge process and that will cause it drop to a pdb shell so you can
poke around and see what's happening.

> Since for a number of packages (I seem to notice it most on kde packages, 
> but perhaps it's all C++ or most CMAKE or some such, plus of course 
> primarily data packages that don't have a significant build phase but 
> install many or large files) the install phase can be as intense as the 
> build phase if not more so, so if some phases aren't counted in 
> "running", then I'd definitely prefer they be counted /somewhere/.

The src_install phase is counted along with all of the earlier phases.

> Of course, listing the number of packages in each phase (which in single-
> mode would by definition list the phase the single package is in) would 
> cure the above issue at the same time.
> 
> Another problem, but one I'm not sure how to fix (tho the interactive 
> display would offer opportunities here), is that it'd be nice to get a 
> list of completed packages, in-process packages, and still not started 
> packages.  That doesn't so easily fit in a neat summary, but as noted, 
> the interactive proposal introduces quite some opportunity, here.
> 
> Alternatively, since often the real info desired is the status of a 
> particular package, it'd be useful to have either an interactive command 
> or a simple separate querying command, that can be run to query the 
> status of a particular package.
> 
> *** Which brings up an alternative to the whole interactive emerges idea 
> as well -- what about a separate command, say "emerging", that when run, 
> would simply output a bunch of detail on any pending emerges?
> 
> This would certainly offer a safer initial implementation, as well, since 
> it's less likely to break the current setup due to bugs, etc.  Another 
> noted benefit is that it leaves the existing defaults alone, so it's not 
> going to be threatening anyone's sacred cows (or scripted assumptions) in 
> terms of how portage has always behaved. =:^)
> 
> 
> So, perhaps improve the current "quiet" display marginally, either 
> including all phases in "running" or adding another listing so the 
> numbers add up, but more importantly...
> 
> *** Add a new "emerging" (name up for bikeshedding) command, that 
> displays a nice multiline summary, perhaps something like this (the 
> second emerge command was for a failure in the first, with a second 
> attempt made before completion of the main emerge @world has completed):
> 
> Current emerge status:
> 
> 2 emerge command(s) running.
> 7 emerge jobs outstanding.
> 
> Commands:
> 
> ** emerge --upgrade --deep --newuse --keep-going @world
> 
> Status:
> 
> 123 of 257 jobs complete, 1 failed, 6 running, 120 not yet started,
> 7 dependencies removed due to failures.
> 
> Running (6):
> 
> 1 pkgsetup (cat-egory/package-ver)
> 
> 1 configure (cat-egory/package-ver, cat-egory/package-ver)
> 
> 2 build (cat-egory/package-ver, cat-egory/package-ver)
> 
> 1 install (cat-egory/package-ver)
> 
> 1 merge (cat-egory/package-ver)
> 
> Failed (1):
> 
> dev-libs/boost-1.47.0-r1
> 
> Complete (123):
> 
> <list		in		nice		columns>
> ...
> 
> Not started (120):
> 
> <list 		in		nice		columns>
> ...
> 
> Removed dependencies due to failure (7):
> 
> <list		in		nice		columns>
> ...
> 
> 
> ** emerge -u1 boost
> 
> Status:
> 
> 0 of 1 jobs complete, 1 running.
> 
> Running (1):
> 
> 1 build (dev-libs/boost-1.47.0-r1)
> Obviously the first implementation might not have all the information 
> above, and there might have been some nice information I missed and other 
> information that could be displayed better, but it's a very cool idea 
> even if I /do/ say so myself. =:^)
> 
> Note that zeroed-out listings aren't displayed, so the the --oneshot 
> doesn't list failed, not yet started, etc, and inactive phases are also 
> not displayed.
> 
> Also note how easy this sort of detailed display would make it to retry 
> failed jobs and the resulting removed dependencies, once the failure has 
> been resolved.
> 
> "emerging" could have a "repeat" mode as well as one-shot, with a polling-
> delay parameter set to something sane like 30 or 60 seconds by default.  
> That way, I wouldn't have to feed it to "watch" =:^)

I'm not sure how many people would use an interface like that in
practice, but I wouldn't be opposed to adding support for something like
that. Since I'm not really interested in using an interface like that
myself, so I don't feel inspired to implement it myself.

> Because this is a separate command, worries about TMI/TLI should be 
> eliminated.  Additionally, it should go some way toward easing the whole 
> quiet/noisy debate as well, since there's now another command available 
> with an intermediate level of information.
> 
> Something like this:
> 
> edisplaylog 
> If we then throw in one more tool, I'll call it edisplaylog for lack of a 
> better name, that reads make.conf to find the elog dir, and can 
> automatically pick out the latest log for a package, thus eliminating the 
> trouble of doing it manually, that should help eliminate another 
> objection to quiet-by-default.  So...
> 
> edisplaylog boost
> 
> ... would find the last elog for boost and display it.
> 
> To make things easy for the user, simply ...
> 
> edisplaylog
> 
> ... could be made to filetime search and display the last active log in 
> tail -f mode.  If after say a couple seconds of no activity, it re-polled 
> the log dir and switched to displaying a different log (have it list the 
> log it's displaying at the top) if it was newer, that could pretty much 
> replace "noisy" mode entirely.  =:^)
> 
> Obviously running simply "edisplaylog" by itself during a parallel-jobs 
> emerge would be nearly as confusing as portage not automatically going 
> into quiet mode for parallel emerging would be, tho not quite since it 
> would display the logfile name at the top, but "edisplaylog <pkg>" would 
> still be very useful, ESPECIALLY for those using --keep-going, so they 
> could track down and fix whatever failed a build before the parallel 
> emerge spit out the results at the end.
> 
> Talking about which... an "edisplaylog failed" mode, which would 
> automatically find the last failure and displayed the log for it, could 
> be very helpful as well. =:^)

That sounds pretty handy.

> Obviously all these ideas entail a lot of coding, and I realize it's easy 
> to sit here and make requests without doing the coding, but implementing 
> them as separate commands first and incremental implementation should 
> help a lot, and I hadn't seen anything like this proposed yet, so...
> 
> I'll close with a thanks to Zac and everyone else who has already made 
> portage the great tool it is today, because without them, we'd obviously 
> not be having this discussion in the first place. =:^)
> 

[1] http://www.gentoo.org/proj/en/portage/doc/faq.xml#doc_chap1_sect9
-- 
Thanks,
Zac

[gentoo-dev] Re: have portage be quiet by default

[Duncan]

Zac Medico posted on Tue, 15 Nov 2011 12:11:23 -0800 as excerpted:

> [1] http://www.gentoo.org/proj/en/portage/doc/faq.xml#doc_chap1_sect9

Thanks for that link.  Somehow, I don't have the portage FAQ in my 
bookmarks, where I could refer to it answering questions, etc (as well as 
for my own use).

Since due to the mix of USE flags, etc, stuff like kdelibs appears in my 
@system's deps, that FAQ entry does help answer the question you so well 
intuited that I was alluding to. =:^)

Meanwhile, now that I've envisioned the "emerging" app as described 
thanks to the stimulus provided by this thread, perhaps I'll implement at 
least parts of it in my own customized portage front-end scripts.  I 
already have quite a collection accumulated as I expect many gentoo users 
do after a few years, but this would certainly be one of my more 
ambitious to date.  If anything comes of the idea...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] have portage be quiet by default

[Alex Alexander]

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

On Mon, Nov 14, 2011 at 07:22:19AM -0800, Zac Medico wrote:
> On 11/14/2011 12:47 AM, Dirkjan Ochtman wrote:
> > On Mon, Nov 14, 2011 at 02:59, Zac Medico <zmedico@gentoo.org> wrote:
> >> Well, it's much easier to gather interest and get feedback if we deploy
> >> the change and ask questions later.
> > 
> > I like the new output, but find it kind of annoying that there's very
> > little feedback on how far the progress is within a single job.
> > Perhaps we could show the currently executing ebuild phase in order to
> > give a little more feedback? Maybe most packages are completely
> > dominated by src_compile(), but for smaller packages it would be
> > helpful, IMO.
> 
> I think that would be an interesting option. I imagine that it would be
> too much information for many people, so I don't think that we'd want to
> enable it by default.

I like the idea as well. IMO it would make a sane default. Not too
noisy, not too silent.

-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Dale]

Zac Medico wrote:
> On 11/13/2011 03:09 PM, Thomas Sachau wrote:
>> Zac Medico schrieb:
>>> On 11/13/2011 07:49 AM, Thomas Sachau wrote:
>>>> Please give me a good reason, why i should by default do more things (adding quiet-build=n to the
>>>> default emerge opts or searching for and opening the build.log) and what i or others do get from
>>>> that. And less lines on the screen is no added value for me, it removes value.
>>> Why should we expose new users to legacy defaults that are useless to
>>> more than 99% users, when they would most likely prefer the
>>> --quiet-build display?
>> Why should we change the default behaviour for existing users? Those, who dont want to see it,
>> probably already use --jobs or quiet-build=y. For the rest, they either dont know about those
>> options (which does not get better, if some default behaviour changes) or they dont want those
>> options (in which case you force them to change their configuration/scripts/way to do things).
> When we change defaults, it affects everyone who hasn't yet overridden
> the setting in EMERGE_DEFAULT_OPTS. That's just how it is.
>
>> Additionally, do you have any numbers about existing or new users and about the percentage, which
>> would like the build output to be quiet?
> All I have is the feedback from this mailing list, an my own intuition.
> My intuition says that --quiet-build is reasonable default that the
> silent majority of people will welcome.
>

Here is some feedback then.  I liked it the way it was.  When a build 
fails, I do a one of install of that package and I like to see the 
output.  Why, because sometimes it gives me a hint as to why it failed 
or something I can google for.

This is a users point of view.  I expect things to remain the same 
unless that will break something.  I like emerge, or any program, to 
work like it always has, at least what the user sees, until the change 
is so drastic to compel a change a user does see.

So, the option to change the output that people expect to see is not 
anything that needs to be done.  It doesn't change what portage does 
under the hood and there is no real reason to change it.

On a side note.  I do wish things like this, added features to portage, 
could be announced on something like user-announce.  That would mean a 
addition mailing list but that could be read only except to devs.  When 
something is going to change, announce it there.  Maybe some thread on 
the forums for those who don't use mailing lists.  I have noticed that 
portage is a moving target.  Things are constantly being added and it is 
difficult to keep up at times.  This would certainly help.  The messages 
would be few but I think it would be awesome to have.  When something 
gets added, send out a announcement so people know to expect it and can 
decide if it is something they can use.

Hope you enjoy my feedback even tho it is different from what you 
expected.  I'm rare but not that rare.

Dale

:-)  :-)

Re: [gentoo-dev] have portage be quiet by default

[Amadeusz Żołnowski]

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

Excerpts from Dale's message of 2011-11-14 13:17:28 +0100:
> Here is some feedback then.  I liked it the way it was.  When a build
> fails, I do a one of install of that package and I like to see the
> output.  Why, because sometimes it gives me a hint as to why it failed
> or something I can google for.

If it fails you get tail of build.log, so you see it anyway.

-- 
Amadeusz Żołnowski

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

Re: [gentoo-dev] have portage be quiet by default

[Dale]

Amadeusz Żołnowski wrote:
> Excerpts from Dale's message of 2011-11-14 13:17:28 +0100:
>> Here is some feedback then.  I liked it the way it was.  When a build
>> fails, I do a one of install of that package and I like to see the
>> output.  Why, because sometimes it gives me a hint as to why it failed
>> or something I can google for.
> If it fails you get tail of build.log, so you see it anyway.
>

That doesn't always go back far enough tho.  I have on my new rig seen 
the failure be as far back as a couple hundred lines.  There are a 
number of times that I have had to use the Find function to even find 
the original failure because it is so far back.  I have even set Konsole 
to have unlimited history.    Unless it is going to tail -n 500 or more, 
that may not go back far enough.  This is the age of multiple cores and 
enough ram to use tmpfs.  I have both.  4 cores and 16Gbs of ram.

MAKEOPTS="-j10"
tmpfs on /var/tmp/portage type tmpfs (rw,noatime)

The MAKEOPTS is increasing.  I'm looking for that sweet spot.  ;-)

Dale

:-)  :-)

Re: [gentoo-dev] have portage be quiet by default

[Amadeusz Żołnowski]

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

Excerpts from Dale's message of 2011-11-14 13:43:36 +0100:
> Amadeusz Żołnowski wrote:
> > Excerpts from Dale's message of 2011-11-14 13:17:28 +0100:
> > > Here is some feedback then.  I liked it the way it was.  When a
> > > build fails, I do a one of install of that package and I like to
> > > see the output.  Why, because sometimes it gives me a hint as to
> > > why it failed or something I can google for.
> >
> > If it fails you get tail of build.log, so you see it anyway.
> 
> That doesn't always go back far enough tho.  I have on my new rig seen
> the failure be as far back as a couple hundred lines.

Well, don't say that if problem is hundreds lines back you search it in
that output.  I'd use for that purpose "less build.log" anyway.


-- 
Amadeusz Żołnowski

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

Re: [gentoo-dev] have portage be quiet by default

[Dale]

Amadeusz Żołnowski wrote:
> Excerpts from Dale's message of 2011-11-14 13:43:36 +0100:
>> Amadeusz Żołnowski wrote:
>>> Excerpts from Dale's message of 2011-11-14 13:17:28 +0100:
>>>> Here is some feedback then.  I liked it the way it was.  When a
>>>> build fails, I do a one of install of that package and I like to
>>>> see the output.  Why, because sometimes it gives me a hint as to
>>>> why it failed or something I can google for.
>>> If it fails you get tail of build.log, so you see it anyway.
>> That doesn't always go back far enough tho.  I have on my new rig seen
>> the failure be as far back as a couple hundred lines.
> Well, don't say that if problem is hundreds lines back you search it in
> that output.  I'd use for that purpose "less build.log" anyway.
>
>

If emerge puts it on the screen like it always has, I won't need to go 
to any build.log.  It will be there on the screen already since I have 
history set to save everything.   That just means this change is going 
to cause users to do even more to find out what is broke.  That could 
lead to posts on the forums or mailing lists where people have a build 
to fail and very little if any info since there is not much on the screen.

As I mentioned in another post.  Users expect things to work like they 
always have.  That is my point.  There is really no reason to change 
this.  It doesn't change what portage does under the hood at all.  The 
old way does help the user tho.  It has been a while but I have had 
compiles to freeze or loop.  No output means it would sit there for a 
good long while, possibly doing nothing.

Dale

:-)  :-)

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/14/2011 05:11 AM, Dale wrote:
> Amadeusz Żołnowski wrote:
>> Excerpts from Dale's message of 2011-11-14 13:43:36 +0100:
>>> Amadeusz Żołnowski wrote:
>>>> Excerpts from Dale's message of 2011-11-14 13:17:28 +0100:
>>>>> Here is some feedback then.  I liked it the way it was.  When a
>>>>> build fails, I do a one of install of that package and I like to
>>>>> see the output.  Why, because sometimes it gives me a hint as to
>>>>> why it failed or something I can google for.
>>>> If it fails you get tail of build.log, so you see it anyway.
>>> That doesn't always go back far enough tho.  I have on my new rig seen
>>> the failure be as far back as a couple hundred lines.
>> Well, don't say that if problem is hundreds lines back you search it in
>> that output.  I'd use for that purpose "less build.log" anyway.
>>
>>
> 
> If emerge puts it on the screen like it always has, I won't need to go
> to any build.log.  It will be there on the screen already since I have
> history set to save everything.

This is already the case with --quiet-build. In the event of a build
failure, emerge dumps the *entire* log to the terminal. So, the above
dialog is discussing a problem that doesn't even exist.
-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Rich Freeman]

On Sun, Nov 13, 2011 at 8:59 AM, Thomas Sachau <tommy@gentoo.org> wrote:
> You expect people to manually check the build.log just to see, where it hangs? I prefer checking the
> console, there i can see it directly and dont have to check for the path of the current build.log
> and then have to additionally open it manually.

I do think this is a fair point.  It is pretty common practice in
tasks that are expected to take a long time to have some kind of
progress indicator.  Even if it just means echoing a period every 10
seconds, or every 10 files, or whatever, it would be a nice way to
tell that something is happening.  I think we used to have a spinner,
which would also work, especially if it is somehow tied to forward
progress on the build..

Most binary distros don't do this, but it doesn't ever take them 15
minutes to install one package.

Another useful thing might be to print out the path of the build logs
each time a package starts building.  That would make tailing a log of
interest easier than hunting through them all.

Rich

[gentoo-dev] Re: have portage be quiet by default

[Duncan]

Amadeusz Żołnowski posted on Sun, 13 Nov 2011 14:04:49 +0100 as excerpted:

> Excerpts from Thomas Sachau's message of 2011-11-13 13:39:17 +0100:
>> This can be argued from either side, if the default is verbose, you can
>> make it quiet in the default emerge opts and the other way round. So
>> this is no argument for or against default quiet build in my eyes.
> 
> Not every user studies manpages of every program they use.  Making
> --quiet-build=y default is a *benefit* for people who don't care much.
> If somebody cares about the output probably will care to read the
> manpage how to make it verbose.  How many emerge users know that option?

Surely this is to a large degree bikeshedding.  Whatever the default is, 
the user can change it as desired, and if a Gentoo user isn't comfortable 
with that, they *REALLY* need to question whether they've made the best 
choice possible choosing Gentoo, based on their needs and goals.

Similarly, someone mentioned how time consuming it could be to change the 
option in a high-unit-number installation, but I'd suggest that if such 
is the case, the person doing it really needs to rethink their approach 
in the first place, and if this is what finally triggers that, well...

>> As already said, it is nice to see, where a build hangs, when some
>> specific task does take longer and until now, it was easy to see, just
>> watch the output. With the new default, you cannot say, what it does,
>> where it may be or if there are many things or just one line taking
>> much time. And you additionally have to go to the build.log manually to
>> actually see something.
> 
> Build output tells almost nothing about the progress (except of cmake).
> But --quiet-build=y actually gives more useful and handy info: what is a
> total progress.

>> In addition, it is also nice to just a quick look into the console to
>> see, what and where it failed.
> 
> When it fails, it prints tail of build.log.

While I already stated that I believe this to be bikeshedding, here's my 
take, hinted at earlier.

The previous defaults made perfect sense to me already.  Parallel emerge 
jobs already puts portage in quiet mode, and that's what most people who 
care (see my point above about whether this is the right distro choice or 
not) should already be using.  That default makes sense, since otherwise 
the output would be jumbled anyway.

1-at-a-time merge defaults are therefore where the question is.  Two 
positions could be taken here.  If it is argued that those who care will 
already be using parallel mode in most cases, and that those who care but 
that can't be bothered to switch their defaults really should be 
questioning whether gentoo is an appropriate choice in the first place, 
then a "noisy" default for 1-at-a-time makes sense too, because the only 
time most (who care) will see it is when they're actually troubleshooting 
something and thus deliberately using 1-at-a-time mode, in which case the 
higher level of detail by default for that mode makes the the most sense.

OTOH, it could equally be argued that quiet mode /does/ speed things up 
slightly and/or lessen CPU requirements for output scrolling, so that 
mode should be the default, because again, those who care can always 
change it anyway, and the Gentoo presumption should be that they will.

But because I /do/ believe it's bikeshedding, since it's easily 
configurable in any case and the gentoo assumption must be that we expect 
people to configure it if desired, or indeed, what's the whole point of 
running gentoo anyway, my personal preference is to revert to the way 
things were, quiet parallel emerge jobs, "noisy" 1-at-a-time, just 
because I'm selfish and that happens to be what'll require no changes on 
my part, since it's the previous and thus already assumed behavior built 
into my scripts.

But since the change is already made and changing the assumption of my 
scripts is as trivial as it is, no skin off my nose if Zach simply sticks 
with the change already made.

Bikeshed away! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: have portage be quiet by default

[Zac Medico]

On 11/13/2011 08:24 AM, Duncan wrote:
> The previous defaults made perfect sense to me already.  Parallel emerge 
> jobs already puts portage in quiet mode, and that's what most people who 
> care (see my point above about whether this is the right distro choice or 
> not) should already be using.  That default makes sense, since otherwise 
> the output would be jumbled anyway.
> 
> 1-at-a-time merge defaults are therefore where the question is.  Two 
> positions could be taken here.  If it is argued that those who care will 
> already be using parallel mode in most cases, and that those who care but 
> that can't be bothered to switch their defaults really should be 
> questioning whether gentoo is an appropriate choice in the first place, 
> then a "noisy" default for 1-at-a-time makes sense too, because the only 
> time most (who care) will see it is when they're actually troubleshooting 
> something and thus deliberately using 1-at-a-time mode, in which case the 
> higher level of detail by default for that mode makes the the most sense.

Ever since I added --jobs support, I've felt that suppression of build
output would be a better default for at least the following reasons:

1) I estimate that the flooding of the terminal with build output is
useless for more than 99% of users. Usually, there's too much
information scrolling by at too high of a rate for it to be
intelligible. Having this as the default behavior is ridiculous and
leads to jokes like apt-gentoo [1]. Generally, people who want to
analyze build output are best served by PORT_LOGDIR.

2) With --quiet-build, the user is presented with a useful summary of
overall progress, along with current load average data. The output is
consistent regardless of whether or not the emerge --jobs option is used.

[1] http://chris-lamb.co.uk/2011/08/12/careful-what-you-wish-for/
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: have portage be quiet by default

[Dale]

Zac Medico wrote:
> On 11/13/2011 08:24 AM, Duncan wrote:
>> The previous defaults made perfect sense to me already.  Parallel emerge
>> jobs already puts portage in quiet mode, and that's what most people who
>> care (see my point above about whether this is the right distro choice or
>> not) should already be using.  That default makes sense, since otherwise
>> the output would be jumbled anyway.
>>
>> 1-at-a-time merge defaults are therefore where the question is.  Two
>> positions could be taken here.  If it is argued that those who care will
>> already be using parallel mode in most cases, and that those who care but
>> that can't be bothered to switch their defaults really should be
>> questioning whether gentoo is an appropriate choice in the first place,
>> then a "noisy" default for 1-at-a-time makes sense too, because the only
>> time most (who care) will see it is when they're actually troubleshooting
>> something and thus deliberately using 1-at-a-time mode, in which case the
>> higher level of detail by default for that mode makes the the most sense.
> Ever since I added --jobs support, I've felt that suppression of build
> output would be a better default for at least the following reasons:
>
> 1) I estimate that the flooding of the terminal with build output is
> useless for more than 99% of users. Usually, there's too much
> information scrolling by at too high of a rate for it to be
> intelligible. Having this as the default behavior is ridiculous and
> leads to jokes like apt-gentoo [1]. Generally, people who want to
> analyze build output are best served by PORT_LOGDIR.

One key.  Scroll Lock.  You can look all you want then hit it again to 
let it carry on.  There is also ctrl Z as well.  I use that a good bit 
to see what is going on.  Just type in fg to carry on.

As for progress, genlop -c does that already.
>
> 2) With --quiet-build, the user is presented with a useful summary of
> overall progress, along with current load average data. The output is
> consistent regardless of whether or not the emerge --jobs option is used.
>
> [1] http://chris-lamb.co.uk/2011/08/12/careful-what-you-wish-for/

Unless you are trying to compile one that failed earlier.  Then you 
don't want the default, you want to see what made it fail.  Then google 
is our friend again.

That said, GREAT work on portage.  :-D

Dale

:-)  :-)

Re: [gentoo-dev] Re: have portage be quiet by default

[Zac Medico]

On 11/14/2011 04:36 AM, Dale wrote:
> Zac Medico wrote:
>> 1) I estimate that the flooding of the terminal with build output is
>> useless for more than 99% of users. Usually, there's too much
>> information scrolling by at too high of a rate for it to be
>> intelligible. Having this as the default behavior is ridiculous and
>> leads to jokes like apt-gentoo [1]. Generally, people who want to
>> analyze build output are best served by PORT_LOGDIR.
> 
> One key.  Scroll Lock.  You can look all you want then hit it again to
> let it carry on.  There is also ctrl Z as well.  I use that a good bit
> to see what is going on.  Just type in fg to carry on.
> 
> As for progress, genlop -c does that already.

We're not stopping you from using your preferred approach. Just set
EMERGE_DEFAULT_OPTS="--quiet-build=n" in /etc/make.conf if it suits you.

>>
>> 2) With --quiet-build, the user is presented with a useful summary of
>> overall progress, along with current load average data. The output is
>> consistent regardless of whether or not the emerge --jobs option is used.
>>
>> [1] http://chris-lamb.co.uk/2011/08/12/careful-what-you-wish-for/
> 
> Unless you are trying to compile one that failed earlier.  Then you
> don't want the default, you want to see what made it fail.  Then google
> is our friend again.

With --quiet-build, if a build fails then the *entire* build log is
displayed on the terminal.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: have portage be quiet by default

[Dale]

Zac Medico wrote:
> On 11/14/2011 04:36 AM, Dale wrote:
>> Zac Medico wrote:
>>> 1) I estimate that the flooding of the terminal with build output is
>>> useless for more than 99% of users. Usually, there's too much
>>> information scrolling by at too high of a rate for it to be
>>> intelligible. Having this as the default behavior is ridiculous and
>>> leads to jokes like apt-gentoo [1]. Generally, people who want to
>>> analyze build output are best served by PORT_LOGDIR.
>> One key.  Scroll Lock.  You can look all you want then hit it again to
>> let it carry on.  There is also ctrl Z as well.  I use that a good bit
>> to see what is going on.  Just type in fg to carry on.
>>
>> As for progress, genlop -c does that already.
> We're not stopping you from using your preferred approach. Just set
> EMERGE_DEFAULT_OPTS="--quiet-build=n" in /etc/make.conf if it suits you.
>
>
Well, I'm off to disable another default being pushed out.  I just 
wonder if make.conf is going to end up the largest file portage uses one 
day.  :/   Every time something changes, I go add another setting to 
make.conf.

As I type:

emerge should show build output by default (unless --quiet-build=y) 42%

So far that's the winner.  As I posted earlier, people expect things to 
work like they have always worked.  I say that as a user.

Dale

:-)  :-)

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

Re: [gentoo-dev] Re: have portage be quiet by default

[Zac Medico]

On 11/14/2011 09:38 AM, Dale wrote:
> As I type:
> 
> emerge should show build output by default (unless --quiet-build=y) 42%
> 
> So far that's the winner.  As I posted earlier, people expect things to
> work like they have always worked.  I say that as a user.

As I've explained in my post to that forum thread [1], you have to
factor in the "silent majority" that welcomes the change and does not
express it publicly. A forumor mailing list thread tends to attract a
"vocal minority", which tends to bias the discussion (or voting results)
in way that does not give a fair statistical representation of the
gentoo population as a whole (it excludes the "silent majority"). It's
part of human nature that those who are displeased with the changed more
likely to speak up than those who welcome the change.

[1]
https://forums.gentoo.org/viewtopic-p-6871718.html?sid=960ebd269384029c21e708d8dfa745ef#6871718
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: have portage be quiet by default

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 14/11/11 01:07 PM, Zac Medico wrote:
> On 11/14/2011 09:38 AM, Dale wrote:
>> As I type:
>>
>> emerge should show build output by default (unless --quiet-build=y) 42%
>>
>> So far that's the winner.  As I posted earlier, people expect things to
>> work like they have always worked.  I say that as a user.
> 
> As I've explained in my post to that forum thread [1], you have to
> factor in the "silent majority" that welcomes the change and does not
> express it publicly.

Uhh..  isn't that like saying, in a general election, "you have to take
into account all the people that don't vote" ??  Just sayin'...


My $0.02 is that, after 50-60 (or more? i lost count) posts on whether
this flag is set or not, and what seems to be entrenchment instead of
consolidation on either side, maybe this should be put on the agenda at
the next Council meeting -- 5 mins of debate + a vote and the argument
is done, right?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk7BWn0ACgkQAJxUfCtlWe0gvwD/ZyU1VkmIaLYP9sX7N0ynXWAH
2sr6ebi2tHVAvEcFMu0BAIBX8JRUYRbTTsOBmykfcm8OzJsDASoCLX4liYPIoT+i
=hi57
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: have portage be quiet by default

[Zac Medico]

On 11/14/2011 10:14 AM, Ian Stakenvicius wrote:
> On 14/11/11 01:07 PM, Zac Medico wrote:
>> On 11/14/2011 09:38 AM, Dale wrote:
>>> As I type:
>>>
>>> emerge should show build output by default (unless --quiet-build=y) 42%
>>>
>>> So far that's the winner.  As I posted earlier, people expect things to
>>> work like they have always worked.  I say that as a user.
> 
>> As I've explained in my post to that forum thread [1], you have to
>> factor in the "silent majority" that welcomes the change and does not
>> express it publicly.
> 
> Uhh..  isn't that like saying, in a general election, "you have to take
> into account all the people that don't vote" ??  Just sayin'...

You've snipped my comment about human nature, which is that those who
are displeased with the changed more likely to speak up than those who
welcome the change.

> My $0.02 is that, after 50-60 (or more? i lost count) posts on whether
> this flag is set or not, and what seems to be entrenchment instead of
> consolidation on either side, maybe this should be put on the agenda at
> the next Council meeting -- 5 mins of debate + a vote and the argument
> is done, right?

That sound fair to me. Maybe not entirely "statistically fair", but that
can only ever be approximated anyway.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: have portage be quiet by default

[Dale]

Zac Medico wrote:
> On 11/14/2011 09:38 AM, Dale wrote:
>> As I type:
>>
>> emerge should show build output by default (unless --quiet-build=y) 42%
>>
>> So far that's the winner.  As I posted earlier, people expect things to
>> work like they have always worked.  I say that as a user.
> As I've explained in my post to that forum thread [1], you have to
> factor in the "silent majority" that welcomes the change and does not
> express it publicly. A forumor mailing list thread tends to attract a
> "vocal minority", which tends to bias the discussion (or voting results)
> in way that does not give a fair statistical representation of the
> gentoo population as a whole (it excludes the "silent majority"). It's
> part of human nature that those who are displeased with the changed more
> likely to speak up than those who welcome the change.
>
> [1]
> https://forums.gentoo.org/viewtopic-p-6871718.html?sid=960ebd269384029c21e708d8dfa745ef#6871718

The same could be said if the poll was going the other way as well.  If 
the results are not going to be used or just going to be explained away, 
then why have the poll to begin with?   I don't think you started the 
poll but just saying. . .

Again, as a loooooong time user, I expect things to remain like they are 
unless that is going to break something or is a must change with no 
other option.  That does happen from time to time but this is not one of 
those times.  I shouldn't have to go override settings just to keep it 
like it was.

All this said, if my opinion doesn't matter, that's fine.  I changed my 
make.conf already.  So now your change doesn't affect me.  It just may 
confuse the heck out of others that don't subscribe here and know about 
the change.  That is the biggest reason I subscribed here a long time 
ago.  Changes pop up that I wasn't expecting and I tend to like to see 
things coming even if it is a freight train.  ;-)  This gives me time to 
undo some things or at least prepare for them.

Later.

Dale

:-)  :-)

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

Re: [gentoo-dev] Re: have portage be quiet by default

[Zac Medico]

On 11/14/2011 10:34 AM, Dale wrote:
> Zac Medico wrote:
>> On 11/14/2011 09:38 AM, Dale wrote:
>>> As I type:
>>>
>>> emerge should show build output by default (unless --quiet-build=y) 42%
>>>
>>> So far that's the winner.  As I posted earlier, people expect things to
>>> work like they have always worked.  I say that as a user.
>> As I've explained in my post to that forum thread [1], you have to
>> factor in the "silent majority" that welcomes the change and does not
>> express it publicly. A forumor mailing list thread tends to attract a
>> "vocal minority", which tends to bias the discussion (or voting results)
>> in way that does not give a fair statistical representation of the
>> gentoo population as a whole (it excludes the "silent majority"). It's
>> part of human nature that those who are displeased with the changed more
>> likely to speak up than those who welcome the change.
>>
>> [1]
>> https://forums.gentoo.org/viewtopic-p-6871718.html?sid=960ebd269384029c21e708d8dfa745ef#6871718
>>
> 
> The same could be said if the poll was going the other way as well.

Well the part about human nature has some tricky implications. It means
that the "vocal minority" is likely to contain a larger percentage of
unhappy people than percentage that exists in the whole population.

> If
> the results are not going to be used or just going to be explained away,
> then why have the poll to begin with?

Why do we go on living when we know that we will eventually die and that
there will be no trace left of our existence? Life is a journey, and we
are required to surrender all of our souvenirs in the end.
-- 
Thanks,
Zac

[gentoo-dev] Re: have portage be quiet by default

[Duncan]

Zac Medico posted on Mon, 14 Nov 2011 10:55:57 -0800 as excerpted:

> Why do we go on living when we know that we will eventually die and that
> there will be no trace left of our existence? Life is a journey, and we
> are required to surrender all of our souvenirs in the end.

Whole religions are built on people's ideas there.  Perhaps 
unfortunately, you didn't explicitly note that your question was 
rhetorical.  In case anybody had any ideas, let's make it explicit, it's 
rhetorical, don't go there, or find some other more appropriate list for 
your discussion if you do!

=:^\

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: have portage be quiet by default

[Hilco Wijbenga]

On 14 November 2011 10:34, Dale <rdalek1967@gmail.com> wrote:
> Zac Medico wrote:
>>
>> On 11/14/2011 09:38 AM, Dale wrote:
>>>
>>> As I type:
>>>
>>> emerge should show build output by default (unless --quiet-build=y) 42%
>>>
>>> So far that's the winner.  As I posted earlier, people expect things to
>>> work like they have always worked.  I say that as a user.
>>
>> As I've explained in my post to that forum thread [1], you have to
>> factor in the "silent majority" that welcomes the change and does not
>> express it publicly. A forumor mailing list thread tends to attract a
>> "vocal minority", which tends to bias the discussion (or voting results)
>> in way that does not give a fair statistical representation of the
>> gentoo population as a whole (it excludes the "silent majority"). It's
>> part of human nature that those who are displeased with the changed more
>> likely to speak up than those who welcome the change.
>>
>> [1]
>>
>> https://forums.gentoo.org/viewtopic-p-6871718.html?sid=960ebd269384029c21e708d8dfa745ef#6871718
>
> The same could be said if the poll was going the other way as well.  If the
> results are not going to be used or just going to be explained away, then
> why have the poll to begin with?   I don't think you started the poll but
> just saying. . .
>
> Again, as a loooooong time user, I expect things to remain like they are
> unless that is going to break something or is a must change with no other
> option.  That does happen from time to time but this is not one of those
> times.  I shouldn't have to go override settings just to keep it like it
> was.

Shouldn't you still be on MS-DOS then? ;-) Insisting that basically
nothing should ever change seems rather extreme... And not very
realistic?

> All this said, if my opinion doesn't matter, that's fine.  I changed my
> make.conf already.  So now your change doesn't affect me.  It just may
> confuse the heck out of others that don't subscribe here and know about the
> change.  That is the biggest reason I subscribed here a long time ago.
>  Changes pop up that I wasn't expecting and I tend to like to see things
> coming even if it is a freight train.  ;-)  This gives me time to undo some
> things or at least prepare for them.
>
> Later.
>
> Dale
>
> :-)  :-)
>
> --
> I am only responsible for what I said ... Not for what you understood or how
> you interpreted my words!
>
>
>

Re: [gentoo-dev] Re: have portage be quiet by default

[Dale]

Hilco Wijbenga wrote:
> On 14 November 2011 10:34, Dale<rdalek1967@gmail.com>  wrote:
>> Zac Medico wrote:
>>> On 11/14/2011 09:38 AM, Dale wrote:
>>>> As I type:
>>>>
>>>> emerge should show build output by default (unless --quiet-build=y) 42%
>>>>
>>>> So far that's the winner.  As I posted earlier, people expect things to
>>>> work like they have always worked.  I say that as a user.
>>> As I've explained in my post to that forum thread [1], you have to
>>> factor in the "silent majority" that welcomes the change and does not
>>> express it publicly. A forumor mailing list thread tends to attract a
>>> "vocal minority", which tends to bias the discussion (or voting results)
>>> in way that does not give a fair statistical representation of the
>>> gentoo population as a whole (it excludes the "silent majority"). It's
>>> part of human nature that those who are displeased with the changed more
>>> likely to speak up than those who welcome the change.
>>>
>>> [1]
>>>
>>> https://forums.gentoo.org/viewtopic-p-6871718.html?sid=960ebd269384029c21e708d8dfa745ef#6871718
>> The same could be said if the poll was going the other way as well.  If the
>> results are not going to be used or just going to be explained away, then
>> why have the poll to begin with?   I don't think you started the poll but
>> just saying. . .
>>
>> Again, as a loooooong time user, I expect things to remain like they are
>> unless that is going to break something or is a must change with no other
>> option.  That does happen from time to time but this is not one of those
>> times.  I shouldn't have to go override settings just to keep it like it
>> was.
> Shouldn't you still be on MS-DOS then? ;-) Insisting that basically
> nothing should ever change seems rather extreme... And not very
> realistic?
>

Allow me to quote myself:

" is a must change with no other option."

I wasn't talking about computers in general but about portage.  So let 
me rephrase this a bit.  I expect PORTAGE to work like it has unless a 
change is forced because of a lack of other options.  I was trying to 
keep it on topic.  I could use the analogy that Ford might decide to 
make it so that when you turn the steering wheel to the right the car 
goes left.  Thing is, that doesn't quite stay on topic and may not even 
be a good comparison.  Thing is, it is not what people are used to or 
expect.  If you think about it, they could just say that the bottom of 
the steering wheel tells which way you will be going not the top.  This 
would be the case even if the steering wheel is on the opposite side of 
the car too.  ^_^

Also, I don't use anything M$.  I have NEVER bought anything that M$ 
makes.  Period.  As long as Linux exists, I have not only a good option 
but a GREAT option.  Read that as I hate winders.

Dale

:-)  :-)

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

Re: [gentoo-dev] Re: have portage be quiet by default

[Alec Warner]

On Mon, Nov 14, 2011 at 10:34 AM, Dale <rdalek1967@gmail.com> wrote:
> Zac Medico wrote:
>>
>> On 11/14/2011 09:38 AM, Dale wrote:
>>>
>>> As I type:
>>>
>>> emerge should show build output by default (unless --quiet-build=y) 42%
>>>
>>> So far that's the winner.  As I posted earlier, people expect things to
>>> work like they have always worked.  I say that as a user.
>>
>> As I've explained in my post to that forum thread [1], you have to
>> factor in the "silent majority" that welcomes the change and does not
>> express it publicly. A forumor mailing list thread tends to attract a
>> "vocal minority", which tends to bias the discussion (or voting results)
>> in way that does not give a fair statistical representation of the
>> gentoo population as a whole (it excludes the "silent majority"). It's
>> part of human nature that those who are displeased with the changed more
>> likely to speak up than those who welcome the change.
>>
>> [1]
>>
>> https://forums.gentoo.org/viewtopic-p-6871718.html?sid=960ebd269384029c21e708d8dfa745ef#6871718
>
> The same could be said if the poll was going the other way as well.  If the
> results are not going to be used or just going to be explained away, then
> why have the poll to begin with?   I don't think you started the poll but
> just saying. . .

A common misconception is that input is being ignored because it did
not affect the results as expected.

I don't expect the poll's current results to change Zac's mind
(certainly not at the 60 / 40 it is currently at; that is not a
compelling story at all.) You can say that the 'majority wins' on the
poll; but the reality of the situation is that only a subset of users
actually use the forums and only a tiny subset of forums users
actually voted thus far (130 votes total at my reading.)

The story is not a compelling one; if it was 80 / 20 or something more
obvious and there were thousands of voters you might be able to draw a
more powerful conclusion from the poll; as it stands any conclusion
drawn are weak at best.

>
> Again, as a loooooong time user, I expect things to remain like they are
> unless that is going to break something or is a must change with no other
> option.  That does happen from time to time but this is not one of those
> times.  I shouldn't have to go override settings just to keep it like it
> was.
>
> All this said, if my opinion doesn't matter, that's fine.  I changed my
> make.conf already.  So now your change doesn't affect me.  It just may
> confuse the heck out of others that don't subscribe here and know about the
> change.  That is the biggest reason I subscribed here a long time ago.
>  Changes pop up that I wasn't expecting and I tend to like to see things
> coming even if it is a freight train.  ;-)  This gives me time to undo some
> things or at least prepare for them.

Your opinion does matter; just not enough to change the behavior ;)

-A

>
> Later.
>
> Dale
>
> :-)  :-)
>
> --
> I am only responsible for what I said ... Not for what you understood or how
> you interpreted my words!
>
>
>

Re: [gentoo-dev] Re: have portage be quiet by default

[Chí-Thanh Christopher Nguyễn]

Zac Medico schrieb:
> On 11/14/2011 09:38 AM, Dale wrote:
>> As I type:
>>
>> emerge should show build output by default (unless --quiet-build=y) 42%
>>
>> So far that's the winner.  As I posted earlier, people expect things to
>> work like they have always worked.  I say that as a user.
> 
> As I've explained in my post to that forum thread [1], you have to
> factor in the "silent majority" that welcomes the change and does not
> express it publicly. A forumor mailing list thread tends to attract a
> "vocal minority", which tends to bias the discussion (or voting results)
> in way that does not give a fair statistical representation of the
> gentoo population as a whole (it excludes the "silent majority"). It's
> part of human nature that those who are displeased with the changed more
> likely to speak up than those who welcome the change.

For the record, I think as lead developer zmedico should have the final
word over what is default in portage, and if arguments or compromise
proposals fail to convince him otherwise, then it shall be as he decides.

That being said, please keep the crap out of this discussion. Especially
the claim that the majority of users welcome this change. You have no
data to back this up, other than selective perception à la "in 14 hours
after proposing this change, no dissenting opinion was posted to
gentoo-dev". In fact, the data which was collected so far suggests
otherwise.

The vocal minority argument is just made up. A vocal minority can push
or oppose changes.

If you think that the change is better for users, and they just need
time to adjust, then be a man and stand to your opinion. Don't hide it
behind such phony claims.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: have portage be quiet by default

[Zac Medico]

On 11/14/2011 02:52 PM, Chí-Thanh Christopher Nguyễn wrote:
> Zac Medico schrieb:
>> On 11/14/2011 09:38 AM, Dale wrote:
>>> As I type:
>>>
>>> emerge should show build output by default (unless --quiet-build=y) 42%
>>>
>>> So far that's the winner.  As I posted earlier, people expect things to
>>> work like they have always worked.  I say that as a user.
>>
>> As I've explained in my post to that forum thread [1], you have to
>> factor in the "silent majority" that welcomes the change and does not
>> express it publicly. A forumor mailing list thread tends to attract a
>> "vocal minority", which tends to bias the discussion (or voting results)
>> in way that does not give a fair statistical representation of the
>> gentoo population as a whole (it excludes the "silent majority"). It's
>> part of human nature that those who are displeased with the changed more
>> likely to speak up than those who welcome the change.
> 
> For the record, I think as lead developer zmedico should have the final
> word over what is default in portage, and if arguments or compromise
> proposals fail to convince him otherwise, then it shall be as he decides.
> 
> That being said, please keep the crap out of this discussion. Especially
> the claim that the majority of users welcome this change. You have no
> data to back this up, other than selective perception à la "in 14 hours
> after proposing this change, no dissenting opinion was posted to
> gentoo-dev". In fact, the data which was collected so far suggests
> otherwise.
> 
> The vocal minority argument is just made up. A vocal minority can push
> or oppose changes.

You've failed to understand the implications of the "human nature" part
of the analysis. Since people who are unhappy with the change are more
likely to speak up, and thereby join the "vocal minority", the "vocal
minority" is likely to contain a larger percentage of unhappy people
than percentage that exists in the whole population.

In the current context, this means that people who are unhappy with the
change in defaults tend to to be more likely to join the mail and forum
threads than people who welcome the change in defaults. This tends to
bias all of your statistics in favor of the unhappy people.

> If you think that the change is better for users, and they just need
> time to adjust, then be a man and stand to your opinion. Don't hide it
> behind such phony claims.

Honestly, I don't think that my opinion weighs more than anyone else's.
-- 
Thanks,.
Zac

Re: [gentoo-dev] have portage be quiet by default

["Paweł Hajdan, Jr."]

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

On 11/12/11 11:24 PM, Patrick Lauer wrote:
> Most devs will be unhappy as it makes it harder to view the log while
> building.

We can have a different default in the developer profile.

> Please consider reverting it and let users set it with
> EMERGE_DEFAULT_OPTS if they want it less noisy.

Why don't people who want it more noisy use EMERGE_DEFAULT_OPTS in a
similar way? I generally agree with the comment that in most cases it's
just like a screensaver. We should just make sure the logs can be
retrieved later if needed.

One note though: sometimes build or test hangs at some point. There are
situations where it's useful to see the current build output.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 533 bytes --]

On Sunday 13 November 2011 05:48:40 Paweł Hajdan, Jr. wrote:
> On 11/12/11 11:24 PM, Patrick Lauer wrote:
> > Most devs will be unhappy as it makes it harder to view the log while
> > building.
> 
> We can have a different default in the developer profile.

the original reason for not doing this via profiles in the first place was old 
versions of portage would barf.  i think that still applies to the developer 
profile :(.  the first version of portage to support this option was released in 
like ~Mar 2011.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] have portage be quiet by default

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/13/2011 04:59 PM, Mike Frysinger wrote:
> On Sunday 13 November 2011 05:48:40 Paweł Hajdan, Jr. wrote:
>> On 11/12/11 11:24 PM, Patrick Lauer wrote:
>>> Most devs will be unhappy as it makes it harder to view the log
>>> while building.
>> 
>> We can have a different default in the developer profile.
> 
> the original reason for not doing this via profiles in the first
> place was old versions of portage would barf.  i think that still
> applies to the developer profile :(.  the first version of portage
> to support this option was released in like ~Mar 2011. -mike
Yeah but can't we just assume devs have recent versions of portage? I
can't imagine a dev using a 6-month old portage :-/

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOwBWrAAoJEPqDWhW0r/LC6VgQAJZ2pMQJbJtKw5gxivu+fKe+
dgiqjxio7BLqxmavImBfwcPXkRUgCuAYHWc6WNQ/NB8W9vmVvOUUhtzh1EEHG7kX
bno3r9utHXkEkLkbKK9Y8yKYzczUBIBg1S/XEzAE4I2JEhwJLSLAgcbBbLjixcuE
1LKCjMrq4fzeJWJav8mQGHKerb8QWKeU8F6EHomSYP/3DK0Ival5WohL0J/bwErh
8m9dsfgUsVPBX7/ZM18GJDHxRD0SH59lBPJAoRCzoPA1SP8+SBgYUewj4GUxfLPN
1FtvAffTUMwrbnp9aQVJUCRrGz/USN0EO79Pzr1Qn/tNueRQwCcTJpjJW3nsrKCF
dRNnchlucN0TWYLNsMtBmFOd+AIDC1EMtFk29Awoyn73yE58DLOH9s3eFvG+ixp+
a/rEQOFg1QzL99T31JqUO7sUxIq0UgTN3JXbZCIby73J+yo9yU3z4FpEgd+VMizx
UJnt8FklB1V1ujbs6IhWMFFRRGKrbRWZYYJAnRsLtvi3i06+Y9P+2ATEPyid2VTY
RVCGqy1+pz4A252zN1Ew3HCm8ZXTpR3xg8fAJVHfyJQ8mD4L3P6YBNHHNSsKqsRK
tF5L0KFC7QLz2QA+WP2tfj+HwdY2Hw8Q5kqPp4jAfY0KS6V94a0GddiCrD43RTmk
OkfBryQBc7EuPXoq6up1
=SeUP
-----END PGP SIGNATURE-----

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/13/2011 11:08 AM, Markos Chandras wrote:
> On 11/13/2011 04:59 PM, Mike Frysinger wrote:
>> On Sunday 13 November 2011 05:48:40 Paweł Hajdan, Jr. wrote:
>>> On 11/12/11 11:24 PM, Patrick Lauer wrote:
>>>> Most devs will be unhappy as it makes it harder to view the log
>>>> while building.
>>>
>>> We can have a different default in the developer profile.
> 
>> the original reason for not doing this via profiles in the first
>> place was old versions of portage would barf.  i think that still
>> applies to the developer profile :(.  the first version of portage
>> to support this option was released in like ~Mar 2011. -mike
> Yeah but can't we just assume devs have recent versions of portage? I
> can't imagine a dev using a 6-month old portage :-/

Another problem is that the user may have another EMERGE_DEFAULT_OPTS
setting which overrides EMERGE_DEFAULT_OPTS from the profile, unless
they use something like EMERGE_DEFAULT_OPTS="--foo
${EMERGE_DEFAULT_OPTS}" in order to explicitly inherit options from the
profile. And no, I don't think we should make EMERGE_DEFAULT_OPTS into
an "incremental" variable. I think the current behavior is just fine.
-- 
Thanks,
Zac

[gentoo-dev] Re: have portage be quiet by default

[Duncan]

Zac Medico posted on Thu, 10 Nov 2011 18:11:38 -0800 as excerpted:

> I think --quiet-build would be a reasonable default, but --quiet
> suppresses various warning messages that I think need to be enabled by
> default for newbies.

What's the difference in output format between --quiet, and the output 
one gets with parallel portage jobs (not just MAKEOPTS but emerge-jobs, 
too) turned on (my default these days)?

If it's the same as with parallel emerge-jobs, yeah, quiet emerges by 
default makes sense to me.

But please do at least einfo the change, and what to do to get back to 
non-quiet by default if desired.  Someone mentioned a news item.  I'm not 
sure it warrants that, but certainly an einfo, and if a news item will 
prevent needless bugs and is thought to be worth the required 
bureaucracy, I've no problem with it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: have portage be quiet by default

[Zac Medico]

On 11/10/2011 10:59 PM, Duncan wrote:
> Zac Medico posted on Thu, 10 Nov 2011 18:11:38 -0800 as excerpted:
> 
>> I think --quiet-build would be a reasonable default, but --quiet
>> suppresses various warning messages that I think need to be enabled by
>> default for newbies.
> 
> What's the difference in output format between --quiet, and the output 
> one gets with parallel portage jobs (not just MAKEOPTS but emerge-jobs, 
> too) turned on (my default these days)?
> 
> If it's the same as with parallel emerge-jobs, yeah, quiet emerges by 
> default makes sense to me.

It's identical.

> But please do at least einfo the change, and what to do to get back to 
> non-quiet by default if desired.  Someone mentioned a news item.  I'm not 
> sure it warrants that, but certainly an einfo, and if a news item will 
> prevent needless bugs and is thought to be worth the required 
> bureaucracy, I've no problem with it.

Yeah, I think a new item is a bit too much. I'll mention it in the
ebuild ChangeLog, the RELEASE-NOTES, and I'll also trigger an elog
message when upgrading from earlier versions.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: have portage be quiet by default

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 736 bytes --]

On Friday 11 November 2011 10:50:47 Zac Medico wrote:
> On 11/10/2011 10:59 PM, Duncan wrote:
> > But please do at least einfo the change, and what to do to get back to
> > non-quiet by default if desired.  Someone mentioned a news item.  I'm not
> > sure it warrants that, but certainly an einfo, and if a news item will
> > prevent needless bugs and is thought to be worth the required
> > bureaucracy, I've no problem with it.
> 
> Yeah, I think a new item is a bit too much. I'll mention it in the
> ebuild ChangeLog, the RELEASE-NOTES, and I'll also trigger an elog
> message when upgrading from earlier versions.

a note to dev-announce might be a good compromise.  i think a news item too 
heavy as well ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: have portage be quiet by default

[Ryan Hill]

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

On Thu, 10 Nov 2011 20:56:22 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> On Thursday 10 November 2011 20:39:11 Mike Frysinger wrote:
> > On Thursday 10 November 2011 19:09:28 Luca Barbato wrote:
> > > That could be done, but I'd advise to make sure our users know that the
> > > could have a quiet/silent output from portage.
> > 
> > if you want quiet portage output, use something like --quiet when running
> > emerge.  the verbosity of the build output isn't really an issue imo.
> 
> perhaps a more controversial question: should we make --quiet the default ?
> -mike

I really didn't like this idea until I discovered that the whole build log is
spit out on error.  So yeah, cool.  Too bad we lose colored output though.

If this changes then it might warrant a news item so people don't freak out.


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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