bug#9327: searching coreutils archives gives "can't open the index"
jida...@jidanni.org wrote: > I see this upon search at > http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=jidanni&submit=Search!&max=20&result=normal&sort=date:late "bug-coreutils" does not appear anywhere in that URL. You have to specify _which_ list to search. Visiting https://lists.gnu.org/archive/html/bug-coreutils/ and typing something in the search box takes you to: https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=something&submit=Search!&idxname=bug-coreutils&max=20&result=normal&sort=score So whoever you pass this report on to will want to know how you came up with the initial URL in the first place, without an idxname field.
bug#9327: searching coreutils archives gives "can't open the index"
tag 9327 notabug thanks On 08/18/2011 06:10 PM, jida...@jidanni.org wrote: I see this upon search at http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=jidanni&submit=Search!&max=20&result=normal&sort=date:late Search String: [jidanni ] Search! Display: [20 ] Description: [normal] Sort: [in reverse chronological order] Results: References: [ (can't open the index) ] Thanks for the report. However, this is not a coreutils bug, but more likely an issue in the web archive mailing list software. Unfortunately, I'm not sure where best to direct your mail to reach the right webmaster. I'm closing this issue, not because it is resolved, but because it is not a coreutils problem; feel free to continue replying to the thread if you track down further information on which webmaster can help you with your list searching issues. In the future, mail like this would better be directed to the coreut...@gnu.org discussion list, where it does not open up a spurious bug report. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
bug#9326: update bug addresses to point to bug-coreutils instead
OK It all started when that guy at gmane got the history backward.
bug#9327: searching coreutils archives gives "can't open the index"
I see this upon search at http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=jidanni&submit=Search!&max=20&result=normal&sort=date:late Search String: [jidanni ] Search! Display: [20 ] Description: [normal] Sort: [in reverse chronological order] Results: References: [ (can't open the index) ]
bug#9326: gmane.comp.gnu.fileutils.bugs - discontinued list - mark read-only?
Ah ha, reading http://article.gmane.org/gmane.discuss/14277 I thought EA> bug-sh-ut...@gnu.org EA> bug-textut...@gnu.org EA> bug-fileut...@gnu.org EA> have been replaced by EA> bug-coreutils@gnu.org i.e., 3->1 when in fact, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638388#15 it is really 1->4!
bug#9326: update bug addresses to point to bug-coreutils instead
I expect this to be futile, but here goes: Since bug-coreutils also uses a debbugs installation, please do not cross-post bug reports between submit@bugs.debian and bug-coreutils. The "package:" etc stuff is parsed by both systems, and it is impossible for it to work right if two are involved. Just pick the most appropriate address. (I'll leave it to the coreutils people to ask why you are cc'ing them on this Debian matter at all.) Dan Jacobson wrote (on Fri, 19 Aug 2011 at 07:31 +0800): > Package: findutils > X-debbugs-Cc: bug-coreutils@gnu.org > Version: 4.5.10-1 > Severity: minor > > According to http://article.gmane.org/gmane.discuss/14277 any > mention of e.g., bug-findutils should be updated throughout this and > other affected packages.
bug#9326: Bug#638388: update bug addresses to point to bug-coreutils instead
tag 9326 notabug thanks [Here's hoping that the GNU debbugs bug 9326, for coreutils is closed, without negatively impacting debian bug 638388] On 08/18/2011 05:31 PM, jida...@jidanni.org wrote: Package: findutils X-debbugs-Cc: bug-coreutils@gnu.org Version: 4.5.10-1 Severity: minor According to http://article.gmane.org/gmane.discuss/14277 any mention of e.g., bug-findutils should be updated throughout this and other affected packages. I have no idea why you submitted this as a coreutils bug. The bug-findutils address that you mention is in active use by the findutils package; and a 'git grep' of 'fileutils' within the findutils package shows that findutils does not have any stale references to the old coreutils mailing aliases. Likewise for a grep of the coreutils sources - the only references to the old addresses are in historical notes. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
bug#9326: Bug#638388: update bug addresses to point to bug-coreutils instead
Package: findutils X-debbugs-Cc: bug-coreutils@gnu.org Version: 4.5.10-1 Severity: minor According to http://article.gmane.org/gmane.discuss/14277 any mention of e.g., bug-findutils should be updated throughout this and other affected packages.
bug#9325: document that "all bets are off if the file contains non-unique join fields"
Mention in the join(1) documents that "all bets are off if the file contains non-unique join fields", e.g., a b b c Also mention if you get this email.
bug#9321: repeated segfaults sorting large files in 8.12
On 08/18/2011 07:30 AM, Andras Salamon wrote: > The repository changelog seems to indicate that the current development > release of sort has not changed since 8.12. Will attempting to track > the problem down with 8.12 be useful? Yes, I think so; thanks.
bug#9321: repeated segfaults sorting large files in 8.12
I am seeing repeated (but not reliably repeatable) segmentation faults sorting datasets in the 100MB-100GB range on a 64-bit Debian system using GNU sort 8.12 (and also 8.9). Stack traces seem to indicate problems during the merge phase, usually when the temporary files are being combined. This may or may not be related to the recent discussion about #9307, but I am definitely using 8.12, rebuilt with CFLAGS=-g since several indicative values were otherwise optimised out, configured with --disable-nls --disable-threads, and am running with a fixed buffer -S 100M and also --parallel=1 to try to isolate problems from possible threading issues. I was seeing these crashes with a vanilla build also. At least one crash occurred when comparing the very last entry in the memory buffer to a non-existent entry, when merging large files. There was also a crash with total_lines=851122 in mergelines_node, which leads to node->hi containing what appears to be garbage, with length=2882303761517117516. The repository changelog seems to indicate that the current development release of sort has not changed since 8.12. Will attempting to track the problem down with 8.12 be useful? If so I can post stack traces and values of relevant variables from the core dump, or post a new issue in the tracker, or reopen #9307. If not, please suggest some specific actions I should take to generate useful information. Thanks, -- Andras Salamon and...@dns.net
