Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=529496 --- Comment #51 from Felipe Contreras <felipe.contreras@xxxxxxxxx> 2010-01-13 14:27:21 EST --- (In reply to comment #49) > you presume too much. It's hard to know what exactly I'm wrongly presuming, but I'm going to make a guess that it's: You could just say: "gcc is ok, but g++ is not using the flags" If that's the case I don't think so. You certainly could have said that, and saved us a lot of time. > Go back a few comments to see that I explicitly referred to "the C++ file". And > still you didn't take a close look at the build.log. You choose to pay no > attention to "the C++ file". Indeed, because I was under the impression that this was not a game of finding the clues. > Prior to that you could have simply taken the review serious. At least a little > bit of trust in that the reviewer *may* be right. I wrote: "It still doesn't > honour RPM_OPT_FLAGS" which referred to the earlier mission objective. Instead > of trying to insult me, you could have asked for help on how to verify optflags > usage. A simple reply such as "Where? I fail to see it" would have done it. The > way you reacted left much to be desired, however. The fact of the matter is that the statement "It still doesn't honour RPM_OPT_FLAGS" is ambiguous. The .spec file was honoring the flags, the .c rules of the Makefile were honoring the flags, but not the .cpp rules. So at best that statement is 2/3 true. > As a general comment on those optflags: It's easy to miss such a detail in the > build.log. It's only one small item in the packaging guidelines. In the review > guidelines, it's only covered indirectly by this: [...] Indeed, I agree. > Anyway, many reviews don't just consist of a sequence of "do this, do that" > items, or else the reviewer would simply provide the fixed spec file. Packagers > are expected to do most of the work, to learn, to read the packaging > guidelines, to become capable of fixing packages themselves in accordance with > additional documentation, and to show whether they know their stuff in order to > convince a sponsor. [Many packagers are expected to demonstrate an > understanding of the review guidelines even, by doing a couple of reviews > completely on their own.] Once a packager's account request is approved, there > isn't any package reviewing process for updates applied to packages in fedora > package scm. That means, you will get less hand-guiding or none at all - unless > your sponsor (or somebody else) monitors your packaging activity closely. Yes, I understand that, but how exactly am I supposed to learn more about packaging if you don't point the issues directly? Or was your objective to inflict more pain than necessary in order for the experience to stick on my brain? If so, mission accomplished. > > It's better to go back and forth a couple of > > times without pointing out the problem. > > Nah, that's just your rather typical way of twisting things and making the > process tiresome. The initial mission objective was clear: > > MUSTFIX: Package doesn't honor RPM_OPT_FLAGS > > Either you understand what that means, where to look it up in the guidelines, > and how to fix the issue -- or you don't. > In case of the latter, ask. Simple as that. Are you implying that I didn't understand what that means? When I mentioned this line: make V=y CFLAGS="$RPM_OPT_FLAGS" %{?_smp_mflags} It was perfectly clear that I understood what that means. Now, the fact that this particular package has C++ code (which I usually avoid), means that was not enough, and that was an *oversight* from my part. The only lesson to learn here is: be careful with CFLAGS and C++ code. Not pointing out the problem directly didn't help at all to learn this lesson, so it served *absolutely no purpose*. OTOH, maybe I'm wrong, and the lesson actually was "Michael speaks in riddles". -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review