Description of problem:
I just tried to compile package gimp-2.2-0.0.pre2.2 from
Redhat Fedora development tree.
The compiler said
wmf.c(271): warning #175: subscript out of range
wmf.c(272): warning #175: subscript out of range
wmf.c(273): warning #175: subscript out of range
wmf.c(274): warning #175: subscript out of range
The source code is
values.type = GIMP_PDB_INT32;
values.data.d_int32 = width;
values.type = GIMP_PDB_INT32;
values.data.d_int32 = height;
static GimpParam values;
So values and values do not exist. Suggest code re-work.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Please check whether this problem is still existent in gimp-2.2.0-1 which is
available from Rawhide since yesterday. In that case, please raise the issue
upstream (http://bugs.gimp.org) and/or submit a patch.
>Please check whether this problem is still existent in gimp-2.2.0-1
Volunteer projects, eh ?
Sorry, I don't have time or resource to do this.
It would be a pity if this bug report just got ignored.
Apparently you have the time to rebuild our packages with a 3rd party compiler
(this is not a gcc warning). As you correctly pointed out, Fedora _is_ a
volunteer project. From http://fedora.redhat.com/about/:
"The community is defined as those who not only consume but also produce for the
good of other community members."
I.e. if there isn't a regression or the bug not only concerns parts of the
program a minority of people will be using (who needs Windows Meta Files anyway
nowadays), the bug report is pretty low on my list of things to do because my
time is limited as well (and I guess this applies to all package maintainers here).
As I see it, submitting your reports here instead of upstream without any
patches etc. from you is a big waste of resources, because submitting them
upstream would be no more of an effort to you than submitting them here, but it
leaves us to forward the bug report to upstream and to keep both bug reports in
sync. Whereas if you submitted it upstream from the start, we would get the fix
eventually anyway. Don't get me wrong here, I suggest this only because this
_is_ a bug that's trivial to fix but at the same time doesn't seem to have
visible regressions yet, so we actually can afford to wait until upstream
contains a fix.
The only question remaining to me is whether your actual motivation is getting
the bug fixed or rather using the packages as a testload for whatever compiler
you use (why would you build this with another compiler if not for that reason?).
>submitting them upstream would be no more of an effort to you than
>submitting them here
If it were the case that this package was the only package I ever
found bugs in, then what you write would be true.
Nearly all Redhat developers just fix the bug reports I send them.
A few don't - not my problem.
>why would you build this with another compiler
All compilers have strengths and weaknesses. Getting a different
opinion, from a second compiler, is an easy way to flush out a load
of obvious compile time bugs.
The issue is that this particular piece of software is not being
developed at Red Hat, not even to a small part -- there are some
programs we only package, some we develop partially and some we
develop virtually alone. In the first case we package it, we care
about regressions, but we cannot be a proxy between you and upstream,
especially if you do such a large number of packages.
Because you seem to do it on a regular basis I presuma at least some
proficiency in the field on your behalf and I expect a certain level
of actual participation in solving the problem whether it's by
submission upstream or by providing a patch. Anything less is just not
helpful at all:
- It doesn't help us -- we've got a minimum bug report, need to build
a patch, have to submit it upstream all the while you could it submit
it there by yourself with hardly more effort to people who actually
_know_ the code.
- It doesn't help you either -- you submit bug reports that probably
don't get acted upon.
- And last but not least it doesn't help other users because if we
tend to ignore bug reports as yours bugs that really do cause
regressions might not be looked at.
>there are some programs we only package, some we develop partially
>and some we develop virtually alone.
I afraid I have no way to distinguish these cases.
Perhaps a flag would help ?
On the one hand the Fedora project continues to solicit bug reports
and patches, but on the other hand, if I submit a bug report
for a certain unknown subset of packages, then that bug report
gets ignored, because I send it to Redhat, not the original
This sounds slightly less than optimal.
I would be happy if my bug reports for the unknown set merely got
forwarded onto their respective maintainers.
I am happy to continue as I am. Some bug reports will fall on
stony ground. Fair enough.