On 05/07/23 18:37, Richard Fish wrote: > Patrick Börjesson wrote: > > >>Oh, and despite what Patrick said, I think you were right to post here > >>first-- no need to clog up b.g.o with what might be a configuration > >>problem and waste developer's time closing an invalid bug. > >> > > > >I really don't see how this could be a configuration problem, since it > >would have complained about an erroneous compilation flag if it was the > >k8 thing that was at fault... And missing files (which the compilation > >error points at) sounds pretty much like a valid bug to me... > > > > Errors building packages are *frequently* configuration problems. > Anybody who has followed this list for at least a month knows that. > > Thus, this is a perfectly valid forum to get feedback on an issue before > filing a new bug report on b.g.o. Bug reports that are not really bugs > just waste valuable developer time. > > That said, I do agree that this looks like an AMD64 specific bug.
When did I say that it wasn't frequent with configuration problems leading to failed builds? I was (and anyone really reading my reply would realize it) pointing to this specific failed build. And I'm just curious; how would a configuration error (that the user has made) lead to a graphics file missing during the build? (not counting in those "configurations" where you're yourself editing the ebuild or otherwise fucking with depends and build options suggested by the ebuild maintainer) > >>I think it's always wise to try to make sure that it really is a bug > >>before posting it. > >> > > > >Of course, but looking at the ordinary response from developers to these > >kind of emails, I'd guess that b.g.o is where they want the report, not > >here... > > > > "Here" being gentoo-user, there are not a lot of developer responses > here. On gentoo-dev, you are correct, the standard response is "file on > b.g.o." But I still maintain that it is better to ask here (or on the > forums, or on #gentoo) first. > > >>And it seems to me that if there is a bug, it might be a *documentation* > >>bug (because the other person who mentioned using march=k8 said that > >>that was the recommendation of the docs, but that seems to no longer be > >>the case, if people using this flag are regularly receiving compilation > >>errors). > >> > > > >Documentation bug? Not recommended by the docs any more? > >You might want to actually try to find information about the subjects > >you respond to. > > > >Straight out of the AMD64 Gentoo Handbook: > >"AMD64 users who want to use a native 64 bit system should use > >-march=k8" > >Combining that cite with the information from the gcc info page, I'm > >pretty sure it's not a "documentation bug". > > > > > > > > Hold on...the -march thing would be an easy mistake to make for those of > us who don't run AMD processors, and are just trying to help. Afterall, > the platform keyword is "amd64". And gcc info says that k8, opteron, > athlon64, and athlon-fx are all equivalent, although I would suggest > that the non-k8 options are more descriptive. Of course, but in this case it wasn't an oversight... The poster explicitly said that using march=k8 seemed to no longer be the recommendation of the docs. That implies at least _some_ looking into the subject before posting... Since I'm myself using the specified platform and have had at least a bit experience with it before reading the post, I was mostly irritated of the reply since it was obvious that the poster didn't know what she was talking about (regarding the march thing...) Also, since the originator had posted the "emerge info" output, I assumed that he/she was at least a bit familiar with how bug handling is handled by Gentoo. -- Regards, Patrick Börjesson PGP signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21792A5D PGP fingerprint: 74AF D4EF 6BDE CF77 16BE 6A29 CDB8 7607 2179 2A5D
pgpmKb0RbakLd.pgp
Description: PGP signature
