The -v option should control whether build output is shown or not by default

17%

[ 80 ]

Other (please comment)

1%

[ 9 ]

Total Votes : 458

Author

Message

dalekVeteran

Joined: 19 Sep 2003Posts: 1303Location: Mississippi USA

Posted: Tue Nov 22, 2011 11:00 am Post subject:

disi wrote:

AidanJT wrote:

dalek wrote:

Yep. It worked for a looooong time. It wasn't broke. It didn't need fixin.

It was broken. That's not UNIX behaviour, it's stupid and wasteful behaviour.

BSD shows compile output...

Code:

% cd /usr/ports/blubb/bla && make install clean

I recently installed Kubuntu for my Brother. I wanted something quick, not to hard the the CPU since it has a stock cooler and they keep the puter room warm already, and didn't need updating to often either. So, no compiling for sure. There was several times where I wasn't sure if it was hung, doing something or what. I really wished I could see something, at times ANYTHING, to know it was doing something. Once, I just hit the reset and started over since it had been sitting there for a good while. Was it making progress, I'll never know. I know it did the second time since I forced myself to walk away from it.

I picked Gentoo over Linux from Scratch because of the package manager. I read it was about as close to Linux from Scratch as you can get without doing it all by hand. I'm not that OCD, yet. lol

If you install Linux from Scratch, is the compile process hidden? From my understanding and impression after years of using Gentoo, Gentoo is Linux from Scratch with a package manager and other tools such as config updates etc.

No, Gentoo Linux is Gentoo Linux. It has no association with Linux from Scratch in any way what so ever. It has more in common with debian.

There's plenty of open source bugs which have persisted for years without being fixed. It's fixed now, however.

dalek wrote:

Gentoo has a lot of great devs that make sure broken things are fixed. So, if it was broken, why the heck did it take them years to fix it?

Why is firefox still leaking memory like a sieve 10 years on?

dalek wrote:

Also, if it was broke, then you must not think much of the Gentoo devs. I may disagree with Zac on this setting, but I do know that he has done some, let me rephrase that, he has done a awesome job with portage. Some is making what he has done look like to little. He has done much more than "little".

I have plenty of disdain for Gentoo devs, lacking omnipotence and omniscience doesn't have anything to do with it. Such an inference is just ridiculous. Simply recognising a bug can take time, having sufficient motivation to fix it can also take time._________________

juniper wrote:

you experience political reality dilation when travelling at american political speeds. it's in einstein's formulas. it's not their fault.

If you install Linux from Scratch, is the compile process hidden? From my understanding and impression after years of using Gentoo, Gentoo is Linux from Scratch with a package manager and other tools such as config updates etc.

No, Gentoo Linux is Gentoo Linux. It has no association with Linux from Scratch in any way what so ever. It has more in common with debian.

Based on Debian? I thought it was closer to BSD as far as portage was concerned. Hmmmm. LFS, source based. Gentoo, source based. No comparison tho. Really?

And plenty of others have said why it was not broken too. Gentoo was working just fine with the output. Showing the output was NOT breaking anything.

dalek wrote:

AidanJT wrote:

If it was, it would have been fixed a very long time ago.

There's plenty of open source bugs which have persisted for years without being fixed. It's fixed now, however.

I wasn't talking about open source bugs. I was talking about portage.

dalek wrote:

AidanJT wrote:

Gentoo has a lot of great devs that make sure broken things are fixed. So, if it was broken, why the heck did it take them years to fix it?

Why is firefox still leaking memory like a sieve 10 years on?

I wasn't aware that Gentoo wrote Firefox code. I thought the Firefox devs did that. Glad you cleared that up. I bet the people writing the Firefox code had no idea they were part of the Gentoo team either.

dalek wrote:

AidanJT wrote:

Also, if it was broke, then you must not think much of the Gentoo devs. I may disagree with Zac on this setting, but I do know that he has done some, let me rephrase that, he has done a awesome job with portage. Some is making what he has done look like to little. He has done much more than "little".

I have plenty of disdain for Gentoo devs, lacking omnipotence and omniscience doesn't have anything to do with it. Such an inference is just ridiculous. Simply recognising a bug can take time, having sufficient motivation to fix it can also take time.

Well at least you admitted that you don't have much for the Gentoo devs. Sounds like I think more of them than you do. Not surprised really.

Where did I say it was based on Debian? I said it has more in common with Debian than LFS.

dalek wrote:

I thought it was closer to BSD as far as portage was concerned.

Portage was based on FreeBSD ports, there the comparison ends.

dalek wrote:

And plenty of others have said why it was not broken too.

The difference is, all their arguments amounted to nothing more than an appeal to tradition fallacy.

dalek wrote:

Gentoo was working just fine with the output. Showing the output was NOT breaking anything.

An F-15 can fly with a missing wing, that doesn't mean it's not broken when it gets a wing blown/ripped off.

dalek wrote:

I wasn't talking about open source bugs. I was talking about portage.

I wasn't aware that Gentoo wrote Firefox code. I thought the Firefox devs did that. Glad you cleared that up. I bet the people writing the Firefox code had no idea they were part of the Gentoo team either.

Now you're being silly. The same factors which defer fixing bugs in other software are the same factors which defer fixing bugs in Gentoo software.

dalek wrote:

Well at least you admitted that you don't have much for the Gentoo devs. Sounds like I think more of them than you do. Not surprised really.

I don't need to be a boot licking sycophant for the status quo to identify a bug. Which is all the more reason why you should be paying attention when I actually agree with the devs on something._________________

juniper wrote:

you experience political reality dilation when travelling at american political speeds. it's in einstein's formulas. it's not their fault.

So, either it wasn't broke or you think the devs have been sitting around for years not fixing something. Care to say which?

Well, you see, it's a relatively recent bug.

The history goes something like this:

Several big-gun devs got systems with so many cores that MAKEOPTS just wasn't able to keep all the cores busy. To fix this "bug", Zac implemented the --jobs features so that multiple ebuilds could be simultaneously launched.

However, this caused another "bug": with multiple ebuilds running, the standard build chatter is completely meaningless. Thus the original quiet build mode was created as an automatic consequence of using the --jobs feature to solve this "bug". The downside of keeping all those cores busy is that you lose good detailed running build status.

The devs occasionally build on lesser boxen, though, which don't warrant launching multiple --jobs, and (at least some of them) have come to believe that the running build status that just appeared on those lesser boxen was inconsistent and just wrong. To fix this "bug", the --quiet-build option was created.

To me, the most important part of this somewhat whimsical history is, "The downside of keeping all those cores busy is that you lose good detailed running build status."

I'm changing my mind. I originally voted to hide the output by default. Temperamentally, I'm usually on the side of consistency and this is what I believe Zac was aiming for with this change. However, I've come to the renewed realization that detailed running build status is good. There may be legitimate reasons why you can't display it, but that doesn't meant that it isn't good.

I lived with the new default for a couple of weeks, but I missed my detailed status.

- John_________________I can confirm that I have received between 0 and 999 National Security Letters.

Well, the reasons have been stated elsewhere in this thread so I won't repeat 'em, but I think "useless" is inaccurate or, at least, a little harsh. Redundant is more technically accurate.

- John

As a non-developer, there is one thing I know for sure. That build output is pretty useless to me. What I really care about is that at the end of the emerge, I have a working system. How it got to the working system is not at all my interest. I run emerge in a terminal usually when I am not doing anything important on the machine and I almost never look at the output. Who even has the time to stare at the build output for more than a few minutes? If you do have that much time in your hands, I envy you.

Why did I choose Gentoo if I am a non-developer? I chose Gentoo because I could keep out stuff that I don't want and because I could build up a system from scratch configured exactly the way I wanted. For instance I want to use okular (because IMO it is by far the best pdf reader on linux), but I don't want to bring in the whole kde desktop with it. Similarly for many of the other softwares. Getting to an equivalent status with the binary distributions is a big problem, because I first need to undo whatever pre-configurations that have already been done (and many times it is simply impossible to remove some cruft in these binary distros)._________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

emerge is *not* a standard UNIX tool to fulfil a simple, single task and print nothing if everything went right. It is supposed to manage a time-consuming and complex process. It is the core of the Gentoo Linux system and should be treated differently.

You're not expected to actually watch the gcc output nor the tiny top-like leftovers since the change. You will most likely run it in a minimized terminal or a screen session in the background unless you want to have a glimpse of what is going on.

Just as the cool guys can understand the green rainy noise of the "Matrix", you can understand portage's "noise" while it's working. This should not be hidden by default from users of whatever level of experience.

No indeed. I find it occasionally useful for non-entertainment (i.e., development-related) purposes.

Such as?

I can say that since I set build parameters in make.conf it's nice to know (or notice) that certain pieces of software do not obey these settings and use something else, which could be forced in an ebuild, or an eclass, or from upstream. This could for example make a relatively small program take longer to build than something more complex if it is forced to a non-parallel build. There are lots of other things too that scroll by, cmake shows what modules are being built and a percentage.

So there is useful information and some of this useful information could be summarized instead of only getting to know that the cpu is working harder than it did in the previous 5 minutes by a scale of the number 3 perhaps compared to the number 2.89 maybe. (see i still find loadavg worthless)

I'd guess the unspoken here is people trying to pinch every watt out of their cpu and to some the less that moves the more it burns. _________________#gentoo-kde on freenode

emerge is *not* a standard UNIX tool to fulfil a simple, single task and print nothing if everything went right. It is supposed to manage a time-consuming and complex process. It is the core of the Gentoo Linux system and should be treated differently.

That's what's known as a design flaw.

karmaking wrote:

You're not expected to actually watch the gcc output nor the tiny top-like leftovers since the change. You will most likely run it in a minimized terminal or a screen session in the background unless you want to have a glimpse of what is going on.

Shit scrolling by faster than you can read doesn't tell you what's going on other than something is going on. And the associated overhead simply isn't worth it especially given that there are other more concise means of finding out if something is going on.

karmaking wrote:

Just as the cool guys can understand the green rainy noise of the "Matrix", you can understand portage's "noise" while it's working. This should not be hidden by default from users of whatever level of experience.

No you can't, and pretending you understand the noise is just plain nonsense. If spewing gcc noise was beneficial then the kernel devs would enable it instead of only printing what module make is working on, and warnings and errors. You know, something actually relevant. And even that is only of value to kernel programmers, not users who're only interested in using the software rather than actively coding and debugging._________________

juniper wrote:

you experience political reality dilation when travelling at american political speeds. it's in einstein's formulas. it's not their fault.

I can say that since I set build parameters in make.conf it's nice to know (or notice) that certain pieces of software do not obey these settings and use something else, which could be forced in an ebuild, or an eclass, or from upstream. This could for example make a relatively small program take longer to build than something more complex if it is forced to a non-parallel build. There are lots of other things too that scroll by, cmake shows what modules are being built and a percentage.

Forcing software that breaks with parallel building to build in parallel? Genius. You are, of course, free to do something that stupid, but Gentoo doesn't have to support stupid by default, it should be sane by default, and just make stupid optional, which it's still doing._________________

juniper wrote:

you experience political reality dilation when travelling at american political speeds. it's in einstein's formulas. it's not their fault.

Just as the cool guys can understand the green rainy noise of the "Matrix", you can understand portage's "noise" while it's working.

That's why i prefer to develop a Matrix output Mode for portage, as mentioned in first posts on Page 2 , but that's a different Story...

I guess we should start sometimes, when the heat cools down, a new thread to collect more useful ideas of features, the devs and the users wish to see in future releases of portage.
Of course only if zmedico agrees to it, to get new suggestions.

I don't may say this feature isn't useful. I only advance the view, that this feature should not the default setting of portage.
Hopefully it get down to this.
Then this discussion has a little positive side effect at the end: much more users would know the EMERGE_DEFAULT_OPTS=" --quiet-build=what ever you like"[/quote]_________________If you want to see a Distro done right, compile it yourself!

A yes, infamous Gentoo condescending elitism, I expect nothing less from Gentoo devs.

I've noticed a lot of this kind of condescending elitist attitude among Gentoo devs, but I don't think that kind of attitude represents the majority. All it takes is a vocal minority to create a bad reputation for the whole community._________________Zac

I can say that since I set build parameters in make.conf it's nice to know (or notice) that certain pieces of software do not obey these settings and use something else, which could be forced in an ebuild, or an eclass, or from upstream. This could for example make a relatively small program take longer to build than something more complex if it is forced to a non-parallel build. There are lots of other things too that scroll by, cmake shows what modules are being built and a percentage.

Forcing software that breaks with parallel building to build in parallel? Genius. You are, of course, free to do something that stupid, but Gentoo doesn't have to support stupid by default, it should be sane by default, and just make stupid optional, which it's still doing.

Really? read much?

Code, Which can break due to being built in 6 little bits all at once, Is forced by an ebuild to build in order. Thus it takes longer.

If I set -j6, but the ebuild or the source code itself strips it away, how do i know this without seeing the output?_________________#gentoo-kde on freenode

There's plenty of open source bugs which have persisted for years without being fixed. It's fixed now, however.

dalek wrote:

Gentoo has a lot of great devs that make sure broken things are fixed. So, if it was broken, why the heck did it take them years to fix it?

Why is firefox still leaking memory like a sieve 10 years on?

dalek wrote:

Also, if it was broke, then you must not think much of the Gentoo devs. I may disagree with Zac on this setting, but I do know that he has done some, let me rephrase that, he has done a awesome job with portage. Some is making what he has done look like to little. He has done much more than "little".

I have plenty of disdain for Gentoo devs, lacking omnipotence and omniscience doesn't have anything to do with it. Such an inference is just ridiculous. Simply recognising a bug can take time, having sufficient motivation to fix it can also take time.

A major factor is that I do not like to make major changes to the default user interface, like this one, since I know that it will tend to upset some of the users (as this thread clearly demonstrates). In the case of --quiet-build, in the long-term, I think it will be worth the short-term ruckus that the change has caused.

firephoto wrote:

If I set -j6, but the ebuild or the source code itself strips it away, how do i know this without seeing the output?

Maybe we could detect this automatically and trigger a QA Notice for display via elog?_________________Zac