The problem: You can see in my example, that there are many developers which are unhappy about the current situation with too many Bugzilla reports caused by insane cflags. The consequence: - Much wasted time - unhappy developers - unhappy users The reasons: - the ignorance of some users - gcc is evil ;D Reproducible: Always Steps to Reproduce: 1. Look on planet gentoo, count the unhappy devs 2. Wait a week 3. Count the new posts with unhappy devs Actual Results: I see more and more devs that are unhappy about the current situation. Expected Results: Happy Devs ;D I think, the current situation is not good and that we need to find a solution for this problem. But the solution should not restrict the user in what he does. My idea to solve this is: When portage notices, that an emerge did fail it should check the cflags and if it finds any of the really "unstable" flags there it should print a little message like: "This error/bug could be a consequence of your insane cflags. Please try to recompile with "-O2 ..." and dont fill a bug report before. Look at http://blablabla for a description of the different flags." I think that would also help a big part of the users which are using these flags without knowing about how dangerous they are. It would also not affect the normal users. If you would want to be more radical you could also add a little patch to make additionally, that does some nearly invisible changes the error output message when the user uses that flags, like "!!! If you need support post the topmost build error, NOT this status message." instead of "!!! If you need support, post the topmost build error, NOT this status message." . Because I bet that there are also some ignorant users who think its all the developers fault and which would probably still report it as a bug. But this would be an really scary idea. So this was my bugreport, I hope I didn't do s.th. wrong with it, because its the first one I ever posted, but I really think there is s.th. that needs to be changed. Feel free to discuss my ideas and to post your own ones. Greetings Moritz Kaufmann PS: I searched for this topic and didn't find any thing, if you don't like to change anything please forgive me and delete this "bug report"
The question is: Who is going to maintain that (black|white)list, and where should it be kept?
I think there are two possibilities: 1. Inside the portage tree speak: "/usr/portage...", this would have the advantage, that its very easy to update. 2. A blacklist comes with every gcc release, advantage: you just need the blacklist for the current compiler version, disadvantage: not that easy to update if there was a mistake. If you choose 2, the gcc ebuild team would have to do the work. If 1 every dev could do that (preferably the bug team, because they would be the one's who profit from the list ;D). When you choose 2, I would say that the blacklist should be kept somewhere in /etc
Do we want such a policy?
How about just outputting a checksum with emerge info for CFLAGS and so forth, so we know that emerge info that was pasted reflects the actual settings?
I don't see people lying that much about their flags, they just file bugs and either don't provide emerge info, or happily omit the bad portions ;) Fex. Dev: "Provide emerge info" user: "I'm using portage 2.0.51.19!" Dev: "Burn in hell ricing infidel!" or something like that... ;) Personally if the user has enough knowledge of their system to run with those ourageous settings and they have a FIX for their problem I don't see an issue with them filing a bug ( sadly I've only seen a few of these ). If there was a firm policy on not looking at compiling related bugs without emerge info, then I would guess we would see a lot more command CFLAGS usage, and if they don't provide those, then no amount of checking or policy is going to stop it. If they lie how is there a way to find out? :) In general I think if Gentoo isn't going to work on bugs filed with crazy use flags we need to state it, state it clearly, and promenantly(sp?). It's kind of alluded(sp?) to right now, but I don't think it's stated anywhere that people look at often.
I often ask people to provide the contents of /var/db/pkg/path/to/app/CFLAGS etc when I'm suspicious it's a CFLAGS problem and emerge info doesn't reflect.
A better idea might be to educate the users instead. This sometimes involves excessive force with heavy & blunt objects. Specifically, one idea to consider is making a gentoo-fied version of the gcc manual for a given compiler version, complete with our fancy GuideXML. The only difference is we "mark" what flags are considered by a majority of devs to be sane, and which ones aren't. The ones that aren't sane will contain a small message stating something to the effect of: "This flag is considered experimental, and quite likely will produce broken code and/or eat small kittens. If you use it and a compile breaks, do NOT file a bug. If you do, it WILL get rejected." And on the flags that we definitely know don't work/ar broken, we can go: "This is broke, don't use it. We mean it. Kittens will die if you use this flag. Please, think of the kittens." The upside of this is no maintainence of black/whitelists, no tracking of goofy CFLAGS, no obfuscation of eclasses to look for said goofy flags, etc.. Having such documentation, which needs to be updated only once every gcc release (which is sporadic enough that it shouldn't be a problem), allows us to close any such bugs with a friendlier form of "RTFM", and a URL to said document. Thoughts?
Figure out what you want to do, preferably on the gentoo-dev ML. reassign once you have a plan. Otherwise dev-portage can't do anything.
docs team has a bugzilla howto now which i think should cover this
Just FYI, our FAQ (which is way more popular doc than bugzie howto) already covers that. http://www.gentoo.org/doc/en/faq.xml#optimizations Short one, so quoting: "Don't bother using anything higher than -O3 since it isn't supported by current versions of gcc. Very aggressive optimizations sometimes cause the compiler to streamline the assembly code to the point where it doesn't quite do the same thing anymore." "Please try to compile with CFLAGS -O2 -march=<your_arch> before reporting a bug."
We have the information already in the FAQ.
