GNU bug report logs -
#12427
Why does OpenSuSE disabled the default of allowing multi-core use in Coreutils 'sort'??
Previous Next
Reported by: Linda Walsh <suse <at> tlinx.org>
Date: Wed, 12 Sep 2012 19:43:02 UTC
Severity: normal
Tags: notabug
Done: Jim Meyering <jim <at> meyering.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12427 in the body.
You can then email your comments to 12427 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#12427; Package
coreutils.
(Wed, 12 Sep 2012 19:43:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Linda Walsh <suse <at> tlinx.org>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Wed, 12 Sep 2012 19:43:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Philipp Thomas wrote:from the changelog (where you
> could have looked yourself ...).
>
> I need to be convinced that sort threading works on all platforms
> openSUSE/SLES support in order to disable that patch.
---
I wasn't aware that openSUSE supported all platforms. However
the people who wrote sort regularly do support 'many' platforms --
far more than what openSuSE supports.
Do you regularly disable feature from upstream requiring someone else
to provide extra proof that they work? Did you have some reason
to suspect that their fixes didn't work? Did you submit a bug
report upstream on the issue? I could easily have missed it, but
don't recall seeing one. If you don't submit bug reports they won't
get fixed.
Too often, I see see patches going back 7-10 versions for bugs openSuSE
has fixed in various progs/utils that should have been passed back
upstream -- but it doesn't *appear* that they have been -- if they
had been, you wouldn't need so many custom patches at build time.
> If you're
> willing to help and got a nice sample work load to stress test sort
> threading I'd try to turn that into a test for the coreutils-testsuite
> package that I could then build and thus run on all the supported
> platforms.
----
They worked through multiple iterations of this algorithm to
find a balance that worked and you just throw away their work without
question?
Do you have reason to believe they have buggy code by default?
I'll Cc' the coreutils bug-list on this and open a bug-report on this as
should have been done originally, and maybe your questions can be addressed.
Added tag(s) notabug.
Request was from
Jim Meyering <jim <at> meyering.net>
to
control <at> debbugs.gnu.org.
(Wed, 12 Sep 2012 20:29:01 GMT)
Full text and
rfc822 format available.
Reply sent
to
Jim Meyering <jim <at> meyering.net>:
You have taken responsibility.
(Wed, 12 Sep 2012 20:29:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Linda Walsh <suse <at> tlinx.org>:
bug acknowledged by developer.
(Wed, 12 Sep 2012 20:29:02 GMT)
Full text and
rfc822 format available.
Message #12 received at 12427-done <at> debbugs.gnu.org (full text, mbox):
tags 12427 notabug
thanks
Linda Walsh wrote:
...
> Do you have reason to believe they have buggy code by default?
> I'll Cc' the coreutils bug-list on this and open a bug-report on this as
> should have been done originally, and maybe your questions can be addressed.
Hi Linda,
Do you realize that by merely sending a message to bug-coreutils,
you have created an entry in our bug-tracking software? Here it is:
http://bugs.gnu.org/12427
If you can describe what you think is a bug in upstream coreutils, we
welcome such reports, but when you are not sure (as your message implies),
please address your mail to the coreutils <at> gnu.org mailing list instead.
That is a more general forum, e.g., for discussion, where each new thread
does not create a new bug-tracking issue that someone will end up having
to re-read, maybe mark as "notabug" and close some day.
In the future, if you open an issue, you're welcome (encouraged, even)
to close it yourself if/when you realize that the issue is not considered
a bug. To close bug DDDDD, just send an email to DDDDD-done <at> debbugs.gnu.org
where DDDDD is your bug number. That will save others the time and
trouble of having to close it for you, leaving them more time to address
issues that *are* deemed to be bugs.
The entire set of bugs:
http://debbugs.gnu.org/coreutils
Here are some graphs:
http://debbugs.gnu.org/rrd/coreutils.html
I've gone ahead and closed this issue (via the Cc' above),
but if you have details on a bug, please start a new thread
here to create a new one.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12427; Package
coreutils.
(Wed, 12 Sep 2012 22:01:01 GMT)
Full text and
rfc822 format available.
Message #15 received at 12427 <at> debbugs.gnu.org (full text, mbox):
OpenSuSE's maintainer/integrator of the gnu sort package
believes it to be faulty -- that's why I forwarded it here,
in hopes that his concerns would be heard/dealt with.
If the downstream maintain thinks there is a bug in sort,
then isn't submitting that bug back up stream the correct
thing to do?
Linda Walsh wrote:
> Philipp Thomas wrote:from the changelog (where you
>> could have looked yourself ...).
>>
>> I need to be convinced that sort threading works on all platforms
>> openSUSE/SLES support in order to disable that patch.
> ---
> I wasn't aware that openSUSE supported all platforms. However
> the people who wrote sort regularly do support 'many' platforms --
> far more than what openSuSE supports.
>
> Do you regularly disable feature from upstream requiring someone else
> to provide extra proof that they work? Did you have some reason
> to suspect that their fixes didn't work? Did you submit a bug
> report upstream on the issue? I could easily have missed it, but
> don't recall seeing one. If you don't submit bug reports they won't
> get fixed.
>
>
> Too often, I see see patches going back 7-10 versions for bugs openSuSE
> has fixed in various progs/utils that should have been passed back
> upstream -- but it doesn't *appear* that they have been -- if they
> had been, you wouldn't need so many custom patches at build time.
>
>> If you're
>> willing to help and got a nice sample work load to stress test sort
>> threading I'd try to turn that into a test for the coreutils-testsuite
>> package that I could then build and thus run on all the supported
>> platforms.
> ----
>
> They worked through multiple iterations of this algorithm to
> find a balance that worked and you just throw away their work without
> question?
>
> Do you have reason to believe they have buggy code by default?
> I'll Cc' the coreutils bug-list on this and open a bug-report on this as
> should have been done originally, and maybe your questions can be
> addressed.
>
>
>
>
>
>
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12427; Package
coreutils.
(Wed, 12 Sep 2012 22:10:01 GMT)
Full text and
rfc822 format available.
Message #18 received at 12427 <at> debbugs.gnu.org (full text, mbox):
>
> Linda Walsh wrote:
> ...
>> Do you have reason to believe they have buggy code by default?
>> I'll Cc' the coreutils bug-list on this and
>> >> open a bug-report << on this
>> as should have been done originally,
>> and maybe your questions can be addressed.
>
> Hi Linda,
>
> Do you realize that by merely sending a message to bug-coreutils,
> you have created an entry in our bug-tracking software?
----
Did you read the above?
*Ahem*. "Do you realize that merely by closing out the bug and not
addressing the issue you defeated the whole point of reporting
a downstream distributor's concern"?
I won't bother to play re-open the bug -- as my guess if you
can't get it from my original post was that it was fixed, but
as I coudln't address his concerns, I felt it needed to be
addessed from upstream -- thus the bug report. I don't think
closing it out without addressing the downstream integrator's
concern (openSuSE), is the clearest response that one might
make.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12427; Package
coreutils.
(Wed, 12 Sep 2012 23:28:01 GMT)
Full text and
rfc822 format available.
Message #21 received at 12427 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 09/12/2012 04:08 PM, Linda Walsh wrote:
>
>>
>> Linda Walsh wrote:
>> ...
>>> Do you have reason to believe they have buggy code by default?
>>> I'll Cc' the coreutils bug-list on this and >> open a
>>> bug-report << on this as should have been done originally,
>>> and maybe your questions can be addressed.
>>
>> Hi Linda,
>>
>> Do you realize that by merely sending a message to bug-coreutils,
>> you have created an entry in our bug-tracking software?
> ----
> Did you read the above?
> *Ahem*. "Do you realize that merely by closing out the bug and not
> addressing the issue you defeated the whole point of reporting
> a downstream distributor's concern"?
But you have not conveyed what the downstream distributor's concern
actually was. Without telling us what the bug is, then for all we know,
there IS no upstream bug, just a downstream decision to fork. If you
can tell us an actual problem, or get the downstream distributor to do
likewise, then we will gladly reopen this bug and address the topic.
But in the meantime, discussion would have been better on the discussion
list instead of creating a bug for a non-bug-report.
> I don't think
> closing it out without addressing the downstream integrator's
> concern (openSuSE), is the clearest response that one might
> make.
Until you identify the downstream integrator's concern, we have to
assume that it is their personal choice to fork things (the GPL allows
that after all), and not an upstream bug.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12427; Package
coreutils.
(Wed, 12 Sep 2012 23:30:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 12427 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 09/12/2012 03:59 PM, Linda Walsh wrote:
> OpenSuSE's maintainer/integrator of the gnu sort package
> believes it to be faulty -- that's why I forwarded it here,
> in hopes that his concerns would be heard/dealt with.
Nothing can be dealt with if it is not first identified what needs to be
dealt with.
>
> If the downstream maintain thinks there is a bug in sort,
> then isn't submitting that bug back up stream the correct
> thing to do?
Yes, reporting bugs upstream is generally the correct thing to do. But
please report the actual bug, and not just fill the bug tracker with a
'me too' report.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12427; Package
coreutils.
(Wed, 12 Sep 2012 23:46:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 12427 <at> debbugs.gnu.org (full text, mbox):
On 09/12/2012 02:59 PM, Linda Walsh wrote:
> OpenSuSE's maintainer/integrator of the gnu sort package
> believes it to be faulty
That is not a correct summary of the email that you forwarded.
That email merely said that he was not convinced that it works.
If no bugs are known, there's no point to filing a bug report.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 11 Oct 2012 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 200 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.