We get a number of GNOME bugs that are completely unrecognisable / useless because people have used unsafe optimisations with their Gnome build. It'd be nice to limit the maxmimu optimisation to -O2, making things faster is always a matter of algorythmic improvement, not compiler options :-) Reproducible: Didn't try Steps to Reproduce: 1. 2. 3.
Hi Daniel: So I finally got my backside in gear, and filed this bug - as per our FOSDEM discussion, nice Bugzilla :-)
Just sorta stumbled over this bug and here's my take since i'm one of the GNOME maintainers for Gentoo. We really urge people to go to our bugzilla with their problems, so we can check it out and file upstream if there's really a reproducable problem. Besides that the first thing i always say when people come reporting is lowering down their optimizations and rebuild. Putting a compile cap on all of GNOME in this case is imo not an option (it happens in some ebuilds, when it's really needed), cause it runs just fine for 99.9% of the people with these optimizations and even if we did change all the ebuilds to cap it it would be circumvented in time by most of the users. Imo the only thing we can do is trying to stress even more to our users to go to our bugzilla first. Or maybe fix bug-buddy a bit to have some extra gentoo specific info/warning or something like that (altough im not in favour of this), if you make it easy to report bugs the downside will be that there will be more false positives. On the other hand Michael, i have heard of these problems before ofcourse, but isn't it like Gentoo with it's relative fast updates also hits a lot of problems as the first distro resulting in more bugreports from Gentoo users, which do identify a problem and get it fixed before other distros are there. This could be why more Gentoo reports show up about certain problems, like i noticed in #gnome suddenly a lot more debian questions popped up when Debian unstable finally caught up (with pre 2.2 release packages even). And another thing i'm thinking of, doesn't GARNOME support setting compiler flags, doesn't that get you a lot of extra (useless?) bugtraffic ? Just some random thoughts that popped up when i was thinking about this.
*grmbl* line wrapping is b0rked
Problems: a) Most Gentoo user bug reporters don't appreciate they have compiled an unsupportable system, and waste maintainers time in big chunks. b) They fail to report this until the 3rd or 4th bugzilla round-trip In summary - self building is a menace when combined with optimisations that are known unsafe / bad. The bug-buddy idea is a good one; along perhaps with a link to the gentoo bugzilla on the Gnome bugzilla page and/or binning user reported Gentoo bugs, and letting them filter through via people more used to handling massive compiler failure: you guys. Yes - we also get horror/bogus bug reports from 'LFS' users, I believe GARNOME doesn't encourage using crack-smoking compiler options though ;-) How can one detect that a system is a Gentoo system ? is there an /etc/gentoo-release or something ?
a) i think that is mildly overstated. Maybe a bugreport about a pack compiled with 'mad opts' should be ignored, but the same pack recompiled with standard opts showing the same behaviour usually really is a bug. The problem is people filing bugs too soon and too eagerly, we should get these user to report to us so we can filter out the cruft. b) that is the _real_ problem here I think the Gentoo users bugreports/optmizations madness are becoming a bit of a self sustained urban myth amongst certain groups of developers. I remember rhythmbox adding a dialog to CVS about Gentoo users not having to count on any help. We ofcourse went there and talked to them, turned out they had a lot bugreports from Gentoo users, but lately that stream had been decreasing already since the real culprit (the gstreamer ebuilds) had been fixed. Besides that Gentoo was like first in line (and back then possibly even the only one) if it came to doing their releases, so if there were going to be bugs from specific distro it could only be Gentoo. But the message so far hasn't been removed, while the reasons for it to be there are mostly gone. There's some outcommented lines in GARNOMES toplevel config file which include some fairly 'daring' CFLAGS. And actually there is a /etc/gentoo-release (didnt even know it was there :)). What i would like to avoid is stigmatisation of the Gentoo user, instead our goal should imho be to turn our bunch of bleeding edge users into useful bugreporters, cause i think that is what we can be as mentioned in my first comment. Fixing Bug-Buddy is an option, if this is considered i would like us fully consulted in this process (not some rhythmbox cvs alike hacktivity) - we could do this local as a Gentoo only patch. I think right now Gentoo users with real problems may get ignored because of this wrong image we have, while e.g. Debian _unstable_ users do get help while the packagers just messed up. But even so, you will ofcourse still get bugreports, we can't stop people from doing what they want to do. Ofcourse Gentoo may generate more bugreports then other i686 or i386 compiled binary distro, but you do get a more thorough testing of the software on more possible configurations. If we can steer this the right way, i think thats only positive to OSS projects as whole resulting in more robust code.
Seems reasonable - as you say it's not so much the fact that the bugs are reported - but that reporters don't seem to think a cobbled-up self-built system of some sort is something we need to know ;-) [ and indeed they're prolly right, they get more attention if they hide that fact for a while ]. Is it possible then to have a bug-buddy patch that will ensure that the OS is set to Gentoo ? and/or do you store the compile-flags used for each package somewhere ? would it be possible for bug-buddy to report them in the bug text: Built with: '-fomit-frame-pointer -fstrength-reduce -funsafe-floating-point -O75' etc. ;-) It may well be an urban myth as you say - but it's a pretty annoying one when it happens, it's stressful enough having real bugs in ones code, without imaginary ones too :-) Either way - more, reliable information would be good; we could also perhaps come up with some text for 'self builders' to stick on the bugzilla.gnome.org 'New bug' pre-amble (not that anyone will read it I'm sure )
We do store compile flags per package and such (probably even compiler/glibc should look into that), though it may not be so easy to implement with portage being written in Python and not having a C API wrapper (for as far as there is an API). So it might take some time before we get around to that/it working at all. It should be easier to at least put an extra warning (dialog) in bug buddy for some extra Gentoo specific warning about submitting bugs while using 'mad opts'. And the 'not read' part is exactly what we are fighting here, since we do urge our users to come to us first :) Setting the OS should probably fairly easy, i'll try to look into it asap. Can you btw confirm that these false postive bugreports come from bug buddy. I do sorta assume that, but does the GNOME bugzilla register where the bugs come from ?
This is more than a year and a half old, and I'd hope things have improved in terms of users reporting Gentoo bugs to our bugzilla, rather than GNOME's. foser, any comments before we close this?
no i think this still can be improved : at least provide 'emerge info' & check if there's reasonable cflags used (don't send out backtraces with omit-frame-pointer etc.) . Problem is that I really don't have the time to work on it... or anyone else here i bet.
Created attachment 59999 [details, diff] Patch to enable bug buddy to report C(XX)FLAGS
I just added a patch for bug-buddy. This is somewhat of a hack (hey its late...), but it works. Just an idea to toss out there. It just adds CFLAGS/CXXFLAGS to the bug report. This is more or less a proof of concept. I'll look into seeing if we can get reports at our bugzilla (rather than GNOME's) tomorrow. foser, what direction do you want to go with this?
OK, I just submitted a patch for "emerge info" to allow us to specify a package name afterwards. This should be what we need to query in the bugbuddy patch. The bug for the new portage feature is Bug #95741 and I will update the bug buddy patch shortly.
to all people here and to Gnome Herd, It's been a year and a half since the last comment was made on this bug. Is there anything we can do to improve this situation? I see we don't patch bug-buddy. Anyway, just a reminder :) Thanks
Well, we do limit gtk+ to -O2. In addition, bug-buddy in 2.17.x has many reporting improvements. I think we can close this.
