Frank Peters <frank.pet...@comcast.net> posted
20090425222359.6e3c49ca.frank.pet...@comcast.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
