[gentoo-amd64] Re: Bug in Cooledit-3.17.17 - Patch Included

[Duncan]

Frank Peters <frank.peters@×××××××.net> posted
20090425222359.6e3c49ca.frank.peters@×××××××.net, excerpted below, on 
Sat, 25 Apr 2009 22:23:59 -0400:

> Hello,
>
> I am not sure if this list is the appropriate place to file a bug
> report, but the problem does need confirmation before I go through
> bugzilla.
>
> After building a working amd64 system using the latest portage tree, I
> emerged my favorite text editor, cooledit,  version 3.17.17  To my
> surprise, any cut/copy/paste operation immediately caused a crash.
> Fortunately, the error messages were quite informative and allowed me to
> quickly find the cause.  A call to "open" in the file widget/editcmd.c
> of the cooledit source does not include the mode parameter.  Somehow,
> with the latest libraries, this missing parameter causes the crash. The
> attached patch file, missing_mode.patch, will fix the problem.
>
> Apply with: patch -p1 < missing_mode.patch.  The gentoo sources include
> a few other patches as well that are also necessary, especially the gcc4
> patch.
>
> But, as I mentioned, it would be beneficial if this problem could be
> confirmed.  Cooledit is not the most popular text editor but maybe
> someone also uses it or is willing to test it.
>
> If someone can confirmn this, then I can file a bugreport with gentoo
> bugzilla.

Hi.  I don't use cooledit, but I use mc, the internal editor of which is 
a text console editor said to work very much like cooledit.  In fact, I 
believe it uses some of the same format config files, for syntax 
hilighting and the like (or so various mc comments and documentation 
leads one to believe).  So I feel a bit of kinship. =:^)

I'd suggest going ahead and filing that bug and patch with Gentoo's 
bugzilla, particularly since you have a patch ready.  Well, first do a 
search and see if there's already a bug filed on it that you can add the 
patch to.

Gentoo's bugzilla works a bit different than some (in more than one way, 
as you'll soon discover if this is your first bug filed there, they've 
customized their version a LOT and it can be difficult getting used to).  
For users that don't hang out on the Gentoo developer list or IRC 
channels, bugs.gentoo is the main way developers and users interact, as 
well as the main tracking mechanism for everything from new and retired 
developers to organizational metabugs to feature requests (for Gentoo 
ebuilds or where Gentoo is the upstream) to the ordinary "bugs" such 
trackers are normally used for.

If you have the skills to come up with a patch, you're already way ahead 
of most users and the bugs they file, and in the process of coming up 
with that patch will have already done way more verification than most 
users and their bugs do, so really, don't hesitate to file one.  The only 
time the Gentoo package maintainers tend to get a bit irritated is when 
people don't look for previous bugs and therefore create dups.  Sometimes 
that's unavoidable due to obscure bug names or something, but make a 
reasonable effort at searching for the bug before filing your own, and 
just file it if you don't find one.  As either a new bug or attached to 
an old one, however, they'll definitely appreciate the patch. =:^)

As I mentioned above, if you've not filed a bug on the Gentoo bugzilla 
before, it can be a bit confusing due to the way Gentoo uses bugzilla, 
especially if you're used to filing them elsewhere.  I know it certainly 
was for me, and I still consider the Gentoo setup one of the more obtuse 
unintuitive setups out there, even if I'm used to it by now and even with 
the wizard.  Thus, I'll quickly step thru the process below.  Maybe it'll 
help you avoid shouting at the web page about how dumb it is like I did 
the first couple times thru! =:^)

Short version: Product: Gentoo Linux, Component: Apps, include
CATEGORY/package-ver (app-editors/cooledit-3.17.17) "copy/cut/paste 
crash" and "[patch]" on the summary/subject line, describe, submit, 
attach your emerge --info if it wasn't in your description, attach the 
patch.

Long version:

For "product", choose Gentoo Linux.  That's the first page of the new bug 
wizard.

If you use the normal wizard (not expert, which skips this as experts 
will know to do it before they ever start with actually filing one), the 
next step is to search for a dup.

Then you fill out the rest of the bug information.  Component in this 
case will be Application.  Hardware platform, OS, etc...

For the summary, start with the category and package name and version, 
app-editors/cooledit-3.17.17 , then describe the problem ("crash on cut/
copy/paste" , for instance).  As you have a patch, add "[patch]" as 
well.  Including the category is very important as some of the initial 
bug wrangling is automated and without that, you force a human to look it 
up, which of course delays the final bug assignment, getting it to 
someone that actually cares about that specific package.

The normal wizard gets rather irritatingly "hand-holdy" at this point.  
There are a number of separate fields (description, reproducibility, 
steps to reproduce, actual results, expected results, additional info)  
that ultimately get merged into a single description field in the filed 
bug or if using the expert wizard.  The first time I tried it, I had most 
of those already in the description by the time I got to the others, and 
what wasn't there didn't fit with the bug I was filing!  But, it's 
evidence of the sort of bugs they normally get, or would, without the 
hand-holding, I guess.

One thing you'll get used to if you file many Gentoo bugs.  They almost 
always want/need your emerge --info output.  I usually attach mine 
instead of posting inline as it clutters the bug otherwise, but even if 
you do NOT think it's necessary, always either include/attach it anyway 
or state why you aren't and that you'll attach it on request.  Doing so 
often prevents a round with the bug wranglers before it even gets 
assigned to the appropriate package maintainer or herd.  Of course, since 
there's no way to attach to the initial filing, that means a line like 
"emerge --info to be attached."

Since you were getting error messages, if you still have them around, 
include them too.

Don't forget to add that you'll be attaching the patch too!

The Severity field is also treated differently on Gentoo.  You could go 
with critical since it's a crash, but most of the time I just leave this 
normal (unless it's obviously lower than that, trivial/enhancement) and 
let the bug wrangler or maintainer change it if they want to.

Then commit the bug, and go back and attach your emerge --info if 
necessary, then the patch.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman