| 1 |
Richard Freeman <rich@××××××××××××××.net> posted |
| 2 |
45152B64.3010903@××××××××××××××.net, excerpted below, on Sat, 23 Sep 2006 |
| 3 |
08:41:08 -0400: |
| 4 |
|
| 5 |
> Simon Stelling wrote: |
| 6 |
>> And we all like X freezing: |
| 7 |
>> |
| 8 |
>> http://bugs.gentoo.org/show_bug.cgi?id=80329 |
| 9 |
>> |
| 10 |
>> In short, yes they can break your system. Pretty easily even, if you |
| 11 |
>> don't know what you're doing. |
| 12 |
>> |
| 13 |
> Well, I didn't see much that looked dangerous in the CFLAGS in the last |
| 14 |
> example. [] I'm sure there was either some kind of GCC bug, or some |
| 15 |
> sensitive aspect of the software itself (making assumptions about data |
| 16 |
> structures in memory/etc) that caused the problem. [] |
| 17 |
> |
| 18 |
> Don't get me wrong - I'm not suggesting having devs or ATs build |
| 19 |
> everything with 47 different CFLAGS before stabilizing either. I think |
| 20 |
> that users with unusual CFLAGS should be prepared to be trailblazers, |
| 21 |
> but if they can figure out which flag is killing the software and can |
| 22 |
> file a bug report it should probably be added to the ebuild as a filter. |
| 23 |
> |
| 24 |
> Then again, that is probably close to what is happening now anyway - I'm |
| 25 |
> sure that if a user filed a simple bug titled "please add - |
| 26 |
> -ftree-vectorize to filter-flags for xyz/abc-1.23" it would probably get |
| 27 |
> closed pretty quickly without much dev complaint. |
| 28 |
|
| 29 |
Agreed that there was nothing obviously wrong with the CFLAGS in that bug |
| 30 |
report, and agreed with your point that the users with unusual CFLAGS |
| 31 |
should be prepared to be trailblazers and figure out what the problem is |
| 32 |
and then it's pretty reasonable to file a bug with a filterflags request. |
| 33 |
|
| 34 |
The problem in this case is that's not what the user did. They had |
| 35 |
reasonably but aggressive CFLAGS, and filed the bug as such, without |
| 36 |
pinning down which CFLAG it was. Did they expect the Gentoo devs (and |
| 37 |
arch testers) to do their dirty work? Both you and I agree that's |
| 38 |
unreasonable. |
| 39 |
|
| 40 |
Yeah, I run reasonable but possibly troublesome on some individual |
| 41 |
packages CFLAGS. I also run masked for testing and specifically not |
| 42 |
supported versions of gcc and the like at times. However, if something |
| 43 |
fails to compile or otherwise acts strange, the first thing I do (BEFORE |
| 44 |
filing the bug) is revert to something rather more conservative for |
| 45 |
testing. Occasionally, I'll ask here whether others are experiencing an |
| 46 |
issue. Only when I've generally traced the problem do I file the bug. |
| 47 |
|
| 48 |
Here's a counterexample (filed by me) however. The problem was that I |
| 49 |
followed portage instructions -- as spewed forth by portage on the actual |
| 50 |
ebuild with the problem. Even tho the problem was simply that I had |
| 51 |
LDFLAGS as instructed, the bug was initially closed saying don't do that. |
| 52 |
To be fair, this WAS for an initially masked X, then unmasked to ~arch, |
| 53 |
but resolved before full stabilization. However, it should be fairly |
| 54 |
obvious from the discussion on the bug that X would have been stabilized |
| 55 |
WITH instructions from portage during the ebuild, which if followed would |
| 56 |
result in a borken X, if I hadn't persisted (and if the topic hadn't come |
| 57 |
up on the dev list), and had let the thing remain closed as a duplicate of |
| 58 |
a different if similar bug. Also look at the time to resolution. Despite |
| 59 |
the specific request, it was rather far from your "probably get closed |
| 60 |
pretty quickly without much dev complaint" ideal. Or rather, it was indeed |
| 61 |
closed pretty quickly, but that's a bit different than being resolved |
| 62 |
equally quickly. |
| 63 |
|
| 64 |
[Modular xorg] xorg-server, xf86-video-ati LDFLAGS |
| 65 |
http://bugs.gentoo.org/show_bug.cgi?id=116698 |
| 66 |
|
| 67 |
Not that this case is in any way the norm. Most bugs I've filed have been |
| 68 |
closed in a reasonable way in a reasonable time, and yes, I recognize |
| 69 |
that Gentoo devs are all volunteers and deserve a lot of credit for that |
| 70 |
alone, however they deal with bugs. This just happens to be one less than |
| 71 |
fortunate exception to my general experience with which I have no |
| 72 |
complaint (after all, I'm still on Gentoo, right <g>). |
| 73 |
|
| 74 |
-- |
| 75 |
Duncan - List replies preferred. No HTML msgs. |
| 76 |
"Every nonfree program has a lord, a master -- |
| 77 |
and if you use the program, he is your master." Richard Stallman |
| 78 |
|
| 79 |
-- |
| 80 |
gentoo-amd64@g.o mailing list |
Archives