RPM submission script

[Eric S. Raymond]

The next point release of Bugzilla will include and support a script
called bug-bugzilla, written by Christian Reis and myself, that allows
posting of bugs without going through a Web interface. You supply an
RFC822-like message on input instead.

Some may recall my urging that submission of RPMs for Fedora needs to
be scriptable. I followed through by working with the Bugzilla crew
to build and document this tool. The bug-bugzilla script is the
essential piece of infrastructure for scriptable RPM submissions to
happen. It abstracts away the details of interacting with Bugzilla CGIs.

I therefore propose the following:

1. A bug-bugzilla RPM should become part of Fedora core.

2. I will write a fedora-submit script, which will call bug-bugzilla.

3. fedora-submit should become part of the Fedora RPM tools RPM, with
a dependency on bug-bugzilla.

Later, if Fedora's submission channel for RPMs changes, fedora-submit
can be changed to suit. The important thing, in my opinion, is to get
a fedora-submit mechanism in place in order to encourage contributions
from people like me who run lots of projects and need scriptable RPM
submission to support that.

[Jesse Keating]

Post by Eric S. Raymond
The next point release of Bugzilla will include and support a script
called bug-bugzilla, written by Christian Reis and myself, that
allows posting of bugs without going through a Web interface. You
supply an RFC822-like message on input instead.

Eric, this seems very nice. My lack of knowledge in the RFC area though
brings me to ask if you could provide a small example of a
"RFC822-like" message? Another project I manage is pressuring me to
move away from bugzilla so that our users/developers can submit bugs
w/out using the web interface.

[seth vidal]

Post by Jesse Keating

Post by Eric S. Raymond
The next point release of Bugzilla will include and support a script
called bug-bugzilla, written by Christian Reis and myself, that
allows posting of bugs without going through a Web interface. You
supply an RFC822-like message on input instead.

Eric, this seems very nice. My lack of knowledge in the RFC area though
brings me to ask if you could provide a small example of a
"RFC822-like" message? Another project I manage is pressuring me to
move away from bugzilla so that our users/developers can submit bugs
w/out using the web interface.

rfc822 == email.

-sv

[Eric S. Raymond]

Post by seth vidal

Post by Jesse Keating
Eric, this seems very nice. My lack of knowledge in the RFC area though
brings me to ask if you could provide a small example of a
"RFC822-like" message? Another project I manage is pressuring me to
move away from bugzilla so that our users/developers can submit bugs
w/out using the web interface.

rfc822 == email.

Yeah, what he said. Headers are various metadata, the body is the
description. Here's what the last version of my test load looked like:

------------------------------------------------------------------------
Product: TestProduct
Component: TestComponent
Version: other
Priority: P2
Keywords: mock
Status: FUBAR
Severity: normal
Summary: Eric's test bug for the submit script #20

This version tries to merge in data from options.
------------------------------------------------------------------------

Thing about this format is that it's trivial to generate using a
shellscript. I expect fedora-submit to be no more than about 30 lines
of code. Your other project could write its own submission wrapper --
the fact that (as you note) this is a more generally useful capability is
what would justify adding bug-bugzilla to Fedora core. (You can find it
in the contrib directory of Bugzilla CVS.)

Who's the gatekeeper for these decisions, and who's in charge of packaging
the Fedora RPM tools? This is a small, easy addition with big benefits;
I think it should definitely go in FC2.

[Alan Cox]

Post by Eric S. Raymond

Post by seth vidal
rfc822 == email.

Yeah, what he said. Headers are various metadata, the body is the

RFC822 is problematic because \n and ":" can occur as part of multibyte
symbols so dumb tools make dumb errors. It works for email only because
SMTP uses some brain damaged "so dont do that" rules.

[Eric S. Raymond]

Post by Alan Cox
RFC822 is problematic because \n and ":" can occur as part of multibyte
symbols so dumb tools make dumb errors. It works for email only because
SMTP uses some brain damaged "so dont do that" rules.

Not a problem. I'll just specify that the input is expected to be UTF-8 and
screw all that multibyte crap. World's going that direction anyway.

[Justin Mason]

Post by Eric S. Raymond

Post by Alan Cox
RFC822 is problematic because \n and ":" can occur as part of multibyte
symbols so dumb tools make dumb errors. It works for email only because
SMTP uses some brain damaged "so dont do that" rules.

Not a problem. I'll just specify that the input is expected to be UTF-8 and
screw all that multibyte crap. World's going that direction anyway.

er, UTF-8 *is* multibyte ;)

However, using UTF-8 should be OK, alright, since UTF-8 multibyte
sequences must contain bit 7 set in all chars, so "\n" and ":" will not
show up as bytes. viz: http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8
notes 'no ASCII byte (0x00-0x7F) can appear as part of any other
character.'

- --j.

[Eric S. Raymond]

Post by Justin Mason
er, UTF-8 *is* multibyte ;)

Well, technically, yes...but not the way people usually mean it (16-bit
chars like Java).

Post by Justin Mason
However, using UTF-8 should be OK, alright, since UTF-8 multibyte
sequences must contain bit 7 set in all chars, so "\n" and ":" will not
show up as bytes. viz: http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8
notes 'no ASCII byte (0x00-0x7F) can appear as part of any other
character.'

Exactly.

[Alexandre Oliva]

Post by Eric S. Raymond
Well, technically, yes...but not the way people usually mean it (16-bit
chars like Java).

That's not UTF-8. That's another representation of Unicode.

[Eric S. Raymond]

Post by Alexandre Oliva

Post by Eric S. Raymond
Well, technically, yes...but not the way people usually mean it (16-bit
chars like Java).

That's not UTF-8. That's another representation of Unicode.

Um. Yes. Were you under the impression I had said otherwise?

[Alexandre Oliva]

Post by Eric S. Raymond

Post by Alexandre Oliva

Post by Eric S. Raymond
Well, technically, yes...but not the way people usually mean it (16-bit
chars like Java).

That's not UTF-8. That's another representation of Unicode.

Um. Yes. Were you under the impression I had said otherwise?

Since you said UTF-8 was not multibyte, I got the impression you were
missing something. Now I reread your follow up e-mail and realize I
had misunderstood it. Sorry.

[seth vidal]

Post by Eric S. Raymond

Post by Alan Cox
RFC822 is problematic because \n and ":" can occur as part of multibyte
symbols so dumb tools make dumb errors. It works for email only because
SMTP uses some brain damaged "so dont do that" rules.

Not a problem. I'll just specify that the input is expected to be UTF-8 and
screw all that multibyte crap. World's going that direction anyway.

ugh - a lot of data in rpms is not utf-8 happy. Often in latin-1 or
beyond that in the encoding.

You might find that mandating UTF-8 is harder than you think.

-sv

[Eric S. Raymond]

Post by seth vidal

Post by Eric S. Raymond
Not a problem. I'll just specify that the input is expected to be
UTF-8 and screw all that multibyte crap. World's going that
direction anyway.

ugh - a lot of data in rpms is not utf-8 happy. Often in latin-1 or
beyond that in the encoding.

Again, that's OK. The stuff in the message doesn't include the RPM itself,
One of the fields is optionally an associated-file-resource URL that could
*point* at an RPM, but that's a different matter.

[seth vidal]

Post by Eric S. Raymond

Post by seth vidal

Post by Eric S. Raymond
Not a problem. I'll just specify that the input is expected to be
UTF-8 and screw all that multibyte crap. World's going that
direction anyway.

ugh - a lot of data in rpms is not utf-8 happy. Often in latin-1 or
beyond that in the encoding.

Again, that's OK. The stuff in the message doesn't include the RPM itself,
One of the fields is optionally an associated-file-resource URL that could
*point* at an RPM, but that's a different matter.

no I mean things like:
descriptions
vendor names
packager names
summaries
filenames

shall I continue? :)

-sv

[Eric S. Raymond]

Post by seth vidal

Post by Eric S. Raymond

Post by seth vidal
ugh - a lot of data in rpms is not utf-8 happy. Often in latin-1 or
beyond that in the encoding.

Again, that's OK. The stuff in the message doesn't include the
RPM itself, One of the fields is optionally an
associated-file-resource URL that could *point* at an RPM, but
that's a different matter.

descriptions
vendor names
packager names
summaries
filenames
shall I continue? :)

Maybe you'd better. You're not making any sense to me, which could mean
either that you are being stupid, or that I am being stupid, or that we
are talking right past one another. We'd better figure out which :-).

All bug-bugzilla does is mine some strings out of an RFC822-conformant
message and use them to script the bug-submission CGI on a Bugzilla instance.
You can think of the message as a job card. (The fields in the job card
can be supplied, or overridden, by command-line options.)

One of the fields handed to the CGI may be a URL pointing to an RPM.
It seems to me that the encoding of strings *in the RPM* is not an issue at
all for bug-bugzilla. Only the contents of the fields in the job card
is an issue. I don't understand why the requirement that those be UTF-8
should ever be onerous.

[seth vidal]

Post by Eric S. Raymond
Maybe you'd better. You're not making any sense to me, which could mean
either that you are being stupid, or that I am being stupid, or that we
are talking right past one another. We'd better figure out which :-).
One of the fields handed to the CGI may be a URL pointing to an RPM.
It seems to me that the encoding of strings *in the RPM* is not an issue at
all for bug-bugzilla. Only the contents of the fields in the job card
is an issue. I don't understand why the requirement that those be UTF-8
should ever be onerous.

b/c the content you're providing may well be data that is in an rpm
header or in the output of rpm -qi somepkg.

as the example I gave to Nicholas, rpm -qi cups - read the description
field, note the (R), notice that's it is 1 character, not 3.

your program can force the conversion and replace the characters outside
the 128 range with ?, but in the case of filenames that are using
non-utf-8 encoding you WILL lose some data.

That's all I'm saying.
-sv

[Eric S. Raymond]

Post by seth vidal

Post by Eric S. Raymond
One of the fields handed to the CGI may be a URL pointing to an RPM.
It seems to me that the encoding of strings *in the RPM* is not an issue at
all for bug-bugzilla. Only the contents of the fields in the job card
is an issue. I don't understand why the requirement that those be UTF-8
should ever be onerous.

b/c the content you're providing may well be data that is in an rpm
header or in the output of rpm -qi somepkg.
as the example I gave to Nicholas, rpm -qi cups - read the description
field, note the (R), notice that's it is 1 character, not 3.
your program can force the conversion and replace the characters outside
the 128 range with ?, but in the case of filenames that are using
non-utf-8 encoding you WILL lose some data.

Ahhhh. Now I see. This is not actually an issue sbout bug-bugzilla at
all. It's an issue about how fedora-submit will transcode non-ASCII stuff
that it mines out of RPM metadata fields.

I was aware of this problem. fedora-submit will have to call iconv in
certain circumstances to mung all the fields into UTF-8. Sometimes
it will fail and fedora-submit will error out as a result. Life is hard.

[Gordon Messmer]

Post by seth vidal
as the example I gave to Nicholas, rpm -qi cups - read the description
field, note the (R), notice that's it is 1 character, not 3.

What version of the package? Maybe I'm missing something, but it looks
like three characters to me:

[***@herald:~]$ rpm -qi cups | od -c
...
0001360 i n g l a y e r f o r \n U N
0001400 I X ( R ) o p e r a t i n g

[***@herald:~]$ rpm -qi cups
Name : cups Relocations: (not relocateab
Version : 1.1.19 Vendor: Red Hat, Inc.
Release : 13 Build Date: Thu 02 Oct 2003

[Nicolas Mailhot]

Post by seth vidal

Post by Eric S. Raymond

Post by seth vidal

Post by Eric S. Raymond
Not a problem. I'll just specify that the input is expected to be
UTF-8 and screw all that multibyte crap. World's going that
direction anyway.

ugh - a lot of data in rpms is not utf-8 happy. Often in latin-1 or
beyond that in the encoding.

Again, that's OK. The stuff in the message doesn't include the RPM itself,
One of the fields is optionally an associated-file-resource URL that could
*point* at an RPM, but that's a different matter.

descriptions
vendor names
packager names
summaries
filenames
shall I continue? :)

Ville Skyttä can tell you how people with non-ascii names feel about
UTF-8. He's been actively converting the JPackage spec files to UTF-8
since we agreed on it (I must admit I like UTF-8 but I certainly can not
match Ville's zeal).

UTF-8 is not the problem. Hanging on 8-bit limited encodings is. The
sooner everything is in i18n-resistant formats like xml and unicode the
better I'll feel.

I was quite amused about the FC1 comment on UTF-8 change problems. For
most non-US people the move to UTF-8 was/is just wonderful. If you
think current problems are bad, just try to actually work on a
pre-unicode release using non-ascii encoding.

Cheers,

[seth vidal]

Post by Nicolas Mailhot
Ville Skyttä can tell you how people with non-ascii names feel about
UTF-8. He's been actively converting the JPackage spec files to UTF-8
since we agreed on it (I must admit I like UTF-8 but I certainly can not
match Ville's zeal).
UTF-8 is not the problem. Hanging on 8-bit limited encodings is. The
sooner everything is in i18n-resistant formats like xml and unicode the
better I'll feel.

That's what I'm talking about.

When you try to force latin-1 or other encodings into utf-8 you end up
losing characters.

So a fun example:
take the Description field of cups and try to encode it in utf-8.

the (R) next to UNIX is the latin-1 (R) as one byte so you end up having
to drop the character entirely Unless you provide a mapping, for every
existent encoding.

ugh.

That's my point.

so mandating utf-8 is great, if you also do it in rpm spec files, and
filenames, etc, etc, etc.

-sv

[Alan Cox]

Post by seth vidal
so mandating utf-8 is great, if you also do it in rpm spec files, and
filenames, etc, etc, etc.

Linux filenames are utf-8 and defined that way. Gives the nautilus people
something to do ;)

[seth vidal]

Post by Alan Cox

Post by seth vidal
so mandating utf-8 is great, if you also do it in rpm spec files, and
filenames, etc, etc, etc.

Linux filenames are utf-8 and defined that way. Gives the nautilus people
something to do ;)

and yet if you look at packages from europe you often find file names
that are not.

-sv

[Alan Cox]

Post by seth vidal

Post by Alan Cox
Linux filenames are utf-8 and defined that way. Gives the nautilus people
something to do ;)

and yet if you look at packages from europe you often find file names
that are not.

Doesn't alter the way the Linux fs is specified. But yes you see this,
and even programs like cd-record with invalid 8859-1 symbols in the C
text

[Michael Schwendt]

Post by seth vidal

Post by Alan Cox

Post by seth vidal
so mandating utf-8 is great, if you also do it in rpm spec files, and
filenames, etc, etc, etc.

Linux filenames are utf-8 and defined that way. Gives the nautilus people
something to do ;)

and yet if you look at packages from europe you often find file names
that are not.

It's sort of a virus, e.g. in Germany. One of the first things the average
user does after a distribution upgrade is to edit /etc/sysconfig/i18n and
change from UTF-8 to @euro or ISO 8859-1. The reason is that the effects
of this change are not understood. It just "seems to work" with old
Latin-1 file names, file contents and non-Unicode-aware applications.

--

[Nicolas Mailhot]

Post by Michael Schwendt

Post by seth vidal

Post by Alan Cox

Post by seth vidal
so mandating utf-8 is great, if you also do it in rpm spec files, and
filenames, etc, etc, etc.

Linux filenames are utf-8 and defined that way. Gives the nautilus people
something to do ;)

and yet if you look at packages from europe you often find file names
that are not.

It's sort of a virus, e.g. in Germany. One of the first things the average
user does after a distribution upgrade is to edit /etc/sysconfig/i18n and

Yeah, sure, sure way to kill the € symbol.

Post by Michael Schwendt
The reason is that the effects
of this change are not understood. It just "seems to work" with old
Latin-1 file names, file contents and non-Unicode-aware applications.

So you provide a stupid shell script that recodes filenames to UTF-8 if
the old locale was something else (because you have access to the old
locale). And/or a glade app that recodes files in unicode.

As for file contents, either they have a sane encoding header and
they'll be fine, either they haven't and you're in a lot of trouble
anyway (in case you haven't noticed one of Java's top bugs is zip
encoding problems - Java uses zip-based formats everywhere but their
filename encoding is unspecified so java creates unicode zip filenames,
windows cp437/cp850 ones, linux iso8859-1 and now UTF-8 and unzipping
stuff can be... interesting)

.specs does not specify encodings.
People edit them in their default text editor which means the spec file
can be in any of the various encodings available, most notably in UTF-8
for all recent setups and people who regularly use something else than
base latin characters (and that includes a large part of even western
Europe).

Current specs are not ASCII already (not that it means anything anyway
since few people use 7-bit encodings and there are langages where you
need the upper 128 chars regularly). A growing number is in UTF-8, so
you can not say "hold on, specs have always been ascii". Plus in the
near future specs will have to be UTF-8 over the board, since that will
be the default mode of every single text editor available.

There is no easy solution. You have to require UTF-8 specs at some
point, and treat non-UTF-8 as a (minor) bug. In fact, it's probably high
time to do it, ie require all for-FC2 spec files to be converted as they
are updated so by the time FC2 is out everything will be nicely UTF-8
(FC1 staying the encoding mess it already is).

Cheers,

[Axel Thimm]

Post by Michael Schwendt
It's sort of a virus, e.g. in Germany. One of the first things the average
user does after a distribution upgrade is to edit /etc/sysconfig/i18n and

Yeah, sure, sure way to kill the € symbol.

:) That's why they are all running back to UTF-8 nowadays ;)

I think people did that upon upgrades (from pre RH8.0 generated
filesystems?), because the existing filesystem or perhaps NFS didn't
reflect the previous filenames and the introduction of UTF-8 in RH
could have documented better how to deal with these issues.

IIRC there wasn't any tool shipped with RH releases to migrate ext3
partitions with latin1 filenames to UTF-8.

[Nicolas Mailhot]

Post by Axel Thimm

Post by Nicolas Mailhot

Post by Michael Schwendt
It's sort of a virus, e.g. in Germany. One of the first things the average
user does after a distribution upgrade is to edit /etc/sysconfig/i18n and

Yeah, sure, sure way to kill the € symbol.

:) That's why they are all running back to UTF-8 nowadays ;)
I think people did that upon upgrades (from pre RH8.0 generated
filesystems?), because the existing filesystem or perhaps NFS didn't
reflect the previous filenames and the introduction of UTF-8 in RH
could have documented better how to deal with these issues.
IIRC there wasn't any tool shipped with RH releases to migrate ext3
partitions with latin1 filenames to UTF-8.

Not too difficult to code in shell using recode as backend but I agree
with you, it would have helped a lot. Now most people have mixed
latin1/UTF-8 filesystem so it's a bit too late for this:(

Unicode migration is our 2k bug, and it's not been handled too well till
now.

Regards,

[Alan Cox]

Post by Michael Schwendt
It's sort of a virus, e.g. in Germany. One of the first things the average
user does after a distribution upgrade is to edit /etc/sysconfig/i18n and
of this change are not understood. It just "seems to work" with old
Latin-1 file names, file contents and non-Unicode-aware applications.

The file system is still UTF-8, its just the user is filling it with
garbage now. The update is a pain but there are some handy scripts for
doing things like turning a subtree from 8859-15 to utf-8

[Bill Nottingham]

Post by Alan Cox

Post by seth vidal
so mandating utf-8 is great, if you also do it in rpm spec files, and
filenames, etc, etc, etc.

Linux filenames are utf-8 and defined that way. Gives the nautilus people
something to do ;)

Erm, then the kernel should default to UTF-8 for NLS on vfat & iso9660.

Bill

[Alan Cox]

Post by Bill Nottingham

Post by Alan Cox

Post by seth vidal
so mandating utf-8 is great, if you also do it in rpm spec files, and
filenames, etc, etc, etc.

Linux filenames are utf-8 and defined that way. Gives the nautilus people
something to do ;)

Erm, then the kernel should default to UTF-8 for NLS on vfat & iso9660.

You want to be loading the modules to map your fs naming to/from utf-8 yes.

Alan

[Eric S. Raymond]

Post by seth vidal
take the Description field of cups and try to encode it in utf-8.
the (R) next to UNIX is the latin-1 (R) as one byte so you end up having
to drop the character entirely Unless you provide a mapping, for every
existent encoding.

Eh? Did somebody change Unicode so the low 256 chars aren't Latin-1
while I wasn't looking?

Post by seth vidal
so mandating utf-8 is great, if you also do it in rpm spec files, and
filenames, etc, etc, etc.

I think that would actually be a reasonable policy stipulation for Fedora.
But we don't have to settle that argument in order to write fedora-submit.

[Axel Thimm]

Post by Eric S. Raymond

Post by seth vidal
take the Description field of cups and try to encode it in utf-8.
the (R) next to UNIX is the latin-1 (R) as one byte so you end up having
to drop the character entirely Unless you provide a mapping, for every
existent encoding.

Eh? Did somebody change Unicode so the low 256 chars aren't Latin-1
while I wasn't looking?

At least UTF-8 has only the lower 127 characters common with
latin1. All other latin1 characters are multibyte.

Post by Eric S. Raymond

Post by seth vidal
so mandating utf-8 is great, if you also do it in rpm spec files, and
filenames, etc, etc, etc.

I think that would actually be a reasonable policy stipulation for Fedora.
But we don't have to settle that argument in order to write fedora-submit.

I think these issues are overdiscussed perhaps. Did rpm ever define
the encoding of the specfiles? There is (little used) provision for
providing i18n descriptions within specfiles. What is the encoding for
these?

If rpm had defined any encoding, then assume this for iconv and any
non-conforming specfile will automatically be detected.

If not, then let's define as of now, that rpm specfiles have to be
encoded in UTF-8.

[Mike A. Harris]

Post by Jesse Keating

Post by Eric S. Raymond
The next point release of Bugzilla will include and support a script
called bug-bugzilla, written by Christian Reis and myself, that
allows posting of bugs without going through a Web interface. You
supply an RFC822-like message on input instead.

Eric, this seems very nice. My lack of knowledge in the RFC area though
brings me to ask if you could provide a small example of a
"RFC822-like" message? Another project I manage is pressuring me to
move away from bugzilla so that our users/developers can submit bugs
w/out using the web interface.

This response is intended for the mailing list in general, and
not really as a response directly to Jesse's comments. I'm just
using this particular message at random, to reply to the thread
in a general sense...



Not using bugzilla is a MAJOR step backwards. I can't speak for
other projects out there, however bugzilla ultimately is present
firstly for developers and engineers actively working on the
distribution first and foremost, and is available to others such
as end users, testers, etc. second to that.

Any changes to bugzilla which make the job of engineers _more_
difficult, or require more work on the part of engineers and
other developers, means that the bug tracking solution is no
longer doing its job adequately.

Any change made to make things easier for users/testers
absolutely must not have an opposite effect of making things more
difficult for engineers/developers, or it wont be seen in good
light.

Bugzilla has an XMLRPC interface which can be used to write
client applications instead of using the web UI. You could write
a GTK or ncurses bugzilla client if you wish, or even write an
email gateway. There is no reason to replace bugzilla
whatsoever. Just use the existing interfaces and cook up a new
frontend for email/ncurses/GTK/whatever that is desired. I
believe Alex Larsson and Adrian Likins have both implemented
alternative bugzilla frontends using the XMLRPC interface
already, however I don't know how complete or fully functional
they are.

But please please please, don't suggest that we replace bugzilla
with something else. We have a lot of time and effort invested
in bugzilla, and a massive database behind it. The costs
associated with replacing all of that would be extremely
staggering, and to remotely consider such a change would have to
come with a massive number of benefits to Red Hat and engineers
here to make us work faster/better/etc. It's very unlikely we
would consider any such change with much seriousness, when
bugzilla is open source and we can (and do) modify it heavily to
meet the needs of Red Hat already.

Please - use the XMLRPC interface if the web interface is
insufficient for your needs, and suggest improvements to bugzilla
if you find it lacking in some area, because it is IMHO very
highly unlikely that a replacement for bugzilla would be
considered without much laughter. ;o)

[Jesse Keating]

Post by Mike A. Harris
Not using bugzilla is a MAJOR step backwards. I can't speak for
other projects out there, however bugzilla ultimately is present
firstly for developers and engineers actively working on the
distribution first and foremost, and is available to others such
as end users, testers, etc. second to that.
Any changes to bugzilla which make the job of engineers _more_
difficult, or require more work on the part of engineers and
other developers, means that the bug tracking solution is no
longer doing its job adequately.
Any change made to make things easier for users/testers
absolutely must not have an opposite effect of making things more
difficult for engineers/developers, or it wont be seen in good
light.

Hrm, I didn't think that this was an attempt to replace Bugzilla, only
make it a slight bit easier to manage. I fail to see how this
email-gateway thing will make things more difficult for the engineer.
It's mostly a way to make things easier for the end-user to file the
bug. Perhaps I'm not looking at the picture big enough, but isn't this
just a method to get the initial information into the bugzilla system,
and afterwhich the user/developer can use the web interface for
anything else necessary?

[Alan Cox]

make it a slight bit easier to manage. I fail to see how this=20
email-gateway thing will make things more difficult for the engineer. =20

It fills bugzilla with junk. I suspect the Gnome people may have more to
say on that subject. As a tool it also seems unneccessary given bug-buddy.

[Jesse Keating]

Post by Alan Cox
It fills bugzilla with junk. I suspect the Gnome people may have more
to say on that subject. As a tool it also seems unneccessary given
bug-buddy.

Is bug-buddy still a live project? I'm not so concerned with rpm
submission, but I have needs for a bug-buddy type thing for another
project I maintain. How configurable is bug-buddy, can you make it
work fairly easily for your own project?

[Alan Cox]

Is bug-buddy still a live project? I'm not so concerned with rpm=20

Very much so

submission, but I have needs for a bug-buddy type thing for another=20
project I maintain. How configurable is bug-buddy, can you make it=20
work fairly easily for your own project?

Assuming your bug tracker fits the standard patterns it ought to be.
bug-buddy already supports delivering bugs to multiple bug repositories
as well as useful stuff like dynamic updating.

It is tied to the GUI so it doesn't help text mode apps too much

[Jesse Keating]

Post by Alan Cox
Assuming your bug tracker fits the standard patterns it ought to be.
bug-buddy already supports delivering bugs to multiple bug
repositories as well as useful stuff like dynamic updating.
It is tied to the GUI so it doesn't help text mode apps too much

Is there a current project page for bug-buddy? I did some searching
around but I couldn't find a current page.

[Alan Cox]

Post by Alan Cox
It is tied to the GUI so it doesn't help text mode apps too much

Is there a current project page for bug-buddy? I did some searching=20
around but I couldn't find a current page.

Its part of gnome, although it can be happily run from non gnome X apps

[Eric S. Raymond]

Post by Alan Cox
It is tied to the GUI so it doesn't help text mode apps too much

See, that's why I wanted bug-bugzilla. I maintain 36 projects; I *need*
to be able to script releases, including shipping RPMs.