Ubuntu bug reporting tools need to point to Ubuntu bug systems

Reported by Matt Zimmerman on 2004-09-07
162
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu
High
Martin Pitt

Bug Description

This includes bug-buddy and reportbug. bug-buddy can talk to bugzilla, I think,
so it should be modified to point to our bugzilla. reportbug can't, I don't
think, so we need an email gateway for that, and it needs to be configured to
send email.

We can't have Warty bugs being reported to Debian

Matt Zimmerman (mdz) wrote :

Dave, how soon can we have an email gateway for bugzilla?

Jeff, will you take care of the bug-buddy modifications?

Jeff Waugh (jdub) wrote :

Sorry, should have opened a bug on this myself, have been checking it out in the
last couple of days, will make sure Dave knows the requirements for our bugzilla
to accept + provide bug information.

David D Miller (justdave) wrote :

(In reply to comment #0)
> This includes bug-buddy and reportbug. bug-buddy can talk to bugzilla, I
> think, so it should be modified to point to our bugzilla. reportbug can't,
> I don't think, so we need an email gateway for that, and it needs to be
> configured to send email.

Bug Buddy needs some extra server-side support that gnome cooked up themselves,
and isn't part of Bugzilla upstream. But they have it in cvs, so I grabbed a
copy and have most of it ported already to the bugzilla version we're using now
(gnome has an older version of Bugzilla and there's been schema changes).

As best I can tell, bug-buddy actually submits via email, too. It just grabs a
couple XML files off the server to get the product list and frequent bugs and so
forth to display to the user first. bug-buddy's submission email is an XML file
though (which gets fed to Bugzilla's XML import).

It's pretty easy to tell whether it's an XML file or not, so having both
bug-buddy and reportbug going to the same address shouldn't be a problem.

Matt Zimmerman (mdz) wrote :

We need this implemented before the preview release, or else we'll need to
disable the bug reporting tools to avoid reporting bugs to the wrong place.

Matt Zimmerman (mdz) wrote :

Dave, how soon can we have an email gateway for bugzilla?

David D Miller (justdave) wrote :

(In reply to comment #5)
> Dave, how soon can we have an email gateway for bugzilla?

Working on it now... I *may* have something working before I sleep tonight, but
I won't guarantee it. Definitely before the release though.

I have the server-side stuff for bug-buddy about 90% ported to Bugzilla 2.19
(they have it running on 2.16 still at gnome). Currently working on getting the
client end to actually talk to it.

Matt Zimmerman (mdz) wrote :

Thanks for the update; let me know if and when you're ready for testing

Matt Zimmerman (mdz) wrote :

Per discussion on IRC and phone, for purposes of Wednesday's preview release, we
should replace the bug-buddy menu item with one that launches a browser pointed
at http://bugzilla.ubuntu.com/, and forego bug-buddy for now.

Jeff - please take care of the menu item

James - please add a CNAME for bugzilla.ubuntu.com and any virtualhost
configuration that is necessary, and add Bugs: mailto:sounder to the overrides
so that reportbug sends mail to us rather than filing debbugs bugs

Dave - please make any necessary changes to the bugzilla configuration to effect
the hostname change

David D Miller (justdave) wrote :

(In reply to comment #8)
> Dave - please make any necessary changes to the bugzilla configuration to effect
> the hostname change

I'll keep an eye out for the domain to go live, and switch it over as soon as it
does. If I switch it sooner, people won't be able to click links in the
bugmails. :)

Matt Zimmerman (mdz) wrote :

bugzilla.ubuntu.com is live, reassigning back to jdub for the remainder (menu item)

Matt Zimmerman (mdz) wrote :

Is it also necessary to modify bug-buddy so that it doesn't submit crash reports
to GNOME?

Jeff Waugh (jdub) wrote :

lowering to major, as the menu item now just launches a web browser for
bugzilla. but this bug is still open, as we need to make bug-buddy work against
our bugzilla for the final release.

David D Miller (justdave) wrote :

And just for status, I have another project for Mark that's due on the 20th
which I will be working on short-term. I will return to working on the
bug-buddy modifications once that's wrapped up.

James Troup (elmo) wrote :

Origin and Bugs tags have been added to all Packages files.

Matt Zimmerman (mdz) wrote :

I've updated reportbug:

reportbug (2.62ubuntu1) warty; urgency=low

  * [debianbts.py] Add an 'ubuntu' BTS entry
  * [reportbug.conf] Make 'ubuntu' the default BTS
  * [reportbug.conf] Don't check for newer versions of packages

 -- Matt Zimmerman <email address hidden> Sat, 18 Sep 2004 02:12:06 -0700

What's our strategy for bug-buddy for Warty? Can we get it talking to bugzilla
properly in time for final?

David D Miller (justdave) wrote :

(In reply to comment #15)
> What's our strategy for bug-buddy for Warty? Can we get it talking to bugzilla
> properly in time for final?

I have it talking to our Bugzilla already with the exception of bug submission,
which was stalled on a) email address/drop box that I requested from admins a
week or so ago, and b) the default mail setup in the release, or a way to work
around it for submit. The fake sendmail stub that accepts the mail and then
submits it via http works, but it's kind of a hack, and it depends on you being
connected to the network at the time.

Matt Zimmerman (mdz) wrote :

(In reply to comment #16)
> I have it talking to our Bugzilla already with the exception of bug submission,
> which was stalled on a) email address/drop box that I requested from admins a
> week or so ago, and b) the default mail setup in the release, or a way to work
> around it for submit. The fake sendmail stub that accepts the mail and then
> submits it via http works, but it's kind of a hack, and it depends on you being
> connected to the network at the time.

(b) doesn't seem solvable for Warty. Users should be able to submit bugs
without having a properly configured Unix mail setup; this is decidedly non-trivial.

The sendmail hack doesn't sound entirely awful, but it would be nicer if
bug-buddy did the http submit itself. That seems quite reasonable to me, as doe
s requiring network access to report a bug.

Matt Zimmerman (mdz) wrote :

So, is it feasible to have bug-buddy doing the right thing for Warty final? The
deadline is looming. I wouldn't be heartbroken if we stuck with Bugzilla for
accepting bug reports for final, but a decision needs to be taken. If it can be
done in time, I'd prefer bug-buddy.

David D Miller (justdave) wrote :

I can easily do the sendmail hack thing to make it do HTTP ... the changes to
bug-buddy to do that basically amount to including an extra file in the
.diff.gz, and changing a string to point at the new file instead of
/usr/sbin/sendmail. Making bug-buddy do the http directly would involve a lot
of C code that I know very little about and wouldn't feel comfortable messing with.

Sivan Greenberg (sivan) wrote :

(In reply to comment #19)
> I can easily do the sendmail hack thing to make it do HTTP ... the changes to
> bug-buddy to do that basically amount to including an extra file in the
> .diff.gz, and changing a string to point at the new file instead of
> /usr/sbin/sendmail. Making bug-buddy do the http directly would involve a lot
> of C code that I know very little about and wouldn't feel comfortable messing
with.

what about using python code to produce an external module that can be called
from bug-buddy to be handleing the HTTP transaction?

Matt Zimmerman (mdz) wrote :

It's a bit late to be hacking up bug-buddy. I'm inclined to leave things as
they are for the Warty release unless someone has a compelling reason to
reintroduce bug-buddy at this late hour.

Matt Zimmerman (mdz) wrote :

OK, it's far too late to do anything other than what we've already done. We'll
revisit this for Hoary.

Alain Perry (alain-perry) wrote :

Hoary is getting close.
I don't know about bug-buddy, but reportbug still sends bug reports to
<email address hidden>.
I think this bug needs to be closed for users to be able to easily send bugs,
and for developers to be able to only refer to the bugzilla as far as bugs are
concerned.

Matt Zimmerman (mdz) wrote :

*** Bug 12626 has been marked as a duplicate of this bug. ***

Matt Zimmerman (mdz) wrote :

As noted in bug #12626, reportbug still needs fixing as well. If we use the
sendmail-to-bugzilla gateway, we should be able to apply the same fix to both.
Seb, what do you think?

Sebastien Bacher (seb128) wrote :

how does this gateway work ? Do we have any documentation about it ?

Matt Zimmerman (mdz) wrote :

(In reply to comment #26)
> how does this gateway work ? Do we have any documentation about it ?

It is a program which provides a sendmail-like interface, but submits the bug to
Bugzilla over HTTP. I believe Dave wrote it, and I thought he had given me a
copy, but I can't seem to find it.

Dave, can you send us a copy?

David D Miller (justdave) wrote :

(In reply to comment #27)
> It is a program which provides a sendmail-like interface, but submits the bug to
> Bugzilla over HTTP. I believe Dave wrote it, and I thought he had given me a
> copy, but I can't seem to find it.
>
> Dave, can you send us a copy?

It was actually a theory and had not yet been written, but it should still be
pretty easy to do. It'll need support in the way of a CGI script on the
Bugzilla end, too. I still have a local copy of the Bugzilla code that's live
on bugzilla.ubuntu.com here so I'll see if I can cobble up both tomorrow.

Matt Zimmerman (mdz) wrote :

*** Bug 9704 has been marked as a duplicate of this bug. ***

David D Miller (justdave) wrote :

I ended up drowning in the Firefox 1.0.1 release stuff and hadn't got to this
yet. I've seen a couple indications that someone else might already be working
on it (got mail from a test bugzilla that indicated it was for a bug created
with some sort of script that could be this). Is it getting taken care of now?

Jeff Bailey (jbailey) wrote :

(In reply to comment #30)
> I ended up drowning in the Firefox 1.0.1 release stuff and hadn't got to this
> yet. I've seen a couple indications that someone else might already be working
> on it (got mail from a test bugzilla that indicated it was for a bug created
> with some sort of script that could be this). Is it getting taken care of now?

I have bug creation and retrieval working over xmlrpc on our test bugzilla
database. I'm just uploaded a libsoup with fernando's xmlrpc patch. I'm gluing
xmlrpc stuff into bug-buddy in a way that's hopefully suitable for upstream, and
Sivan said that he'd take a look at reportbug.

It's going slower than I'd like, but this one is getting done.

Tks,
Jeff Bailey

Sebastien Bacher (seb128) wrote :

*** Bug 20500 has been marked as a duplicate of this bug. ***

auspex (auspex) wrote :

Reportbug _still_ doesn't submit to bugzilla, over a year after opening this bug. I've been merrily posting bugs via
reportbug since the initial release of breezy, and only recently realized they were never being noticed.

pirast (pirast) wrote :

bug-buddy doesn't submit it to the Ubuntu Bugzilla, too. But in Breezy it does
not report bugs to the Gnome Bugzilla as it did in Hoary so the users think that
they submitted a bug but it was not submitted.

Jeff Bailey (jbailey) wrote :

The Malone XML-RPC Interface BOF has been proposed to provide an interface to
make this possible.

Nick_Hill (nick-nickhill) wrote :

As of release 5.10, on 17 oct 05, reportbug still sends bug reports to
<email address hidden>
which bounces back for moderator approval to a membership list.

I hope these reportbug messages are being acted upon, although I strongly suspect they are
going into a bitbucket, which has a strong cooling effect on the community contributions.

There are so many bugs with 5.10 which need to be fixed. So many boring things which require
attention to polish the free software desktop system. Like getting MIDI to work, making KIO
slaves and GnomeVFS launches talk to programs which are not part of their respective desktops.

David N. Welton (davidnwelton) wrote :

This bug is definitely a nasty one, because it essentially just throws away
information from bug reports. Either turn reportbug off completely, or *at
least* make it send mail somewhere where it can be archived for future processing.

Thanks,
Dave

Matt Zimmerman (mdz) wrote :

(In reply to comment #37)
> This bug is definitely a nasty one, because it essentially just throws away
> information from bug reports. Either turn reportbug off completely, or *at
> least* make it send mail somewhere where it can be archived for future processing.

The reports are not thrown away, except perhaps if unix-style mail is
misconfigured. They are sent to a mailing list which is archived.

I believe Scott has code to post bugs to Malone, which might be feasible to
integrate into reportbug

Sebastien Bacher (seb128) wrote :

*** Bug 24807 has been marked as a duplicate of this bug. ***

Zooko Wilcox-O'Hearn (zooko) wrote :

I'd like to echo the comment about the "strong cooling effect on community contributions". It looks like this bug has been outstanding for 16 months now. How about just removing reportbug from dapper? How many minutes of someone's time does it take to remove reportbug?

I'm afraid the answer might be: many minutes of policy vision articulation and comparative bike shed color theory.

auspex (auspex) wrote :

Matt, to say:
> The reports are not thrown away, except perhaps if unix-style mail
> is misconfigured. They are sent to a mailing list which is archived.

is really untrue. I'm subscribed to the ubuntu-users list where most (if not all) of the "reportbug" bugs get posted. Nobody every responds to them, and any bug _I've_ reported via reportbug has never made it into the bug tracking system. That's as close to "thrown away" as makes no difference.

I'd also point out that the Ubuntu developers decided, in their wisdom, to remove Postfix as a part of the standard ubuntu desktop install and, since reportbug only "suggests" an MTA, that means that reportbug is no longer guaranteed to do _anything_. I don't understand how reportbug can not _depend_ on an MTA

Craig Sampson (ubuntu-psi-aus) wrote :

I have to agree with the comments above - I usually don't bother with bug-buddy as in the past it has certainly seemed to me that any reports that magically do manage to get out of the machine are not logged anywhere nor acted upon.

However, years have passed and I had a particularly nasty firestarter bug pop up bug-buddy at me on one of my development machine so I gave it a go.

After jumping through several hoops and generally finangling around wasting time the task failed because I did not have an MTA. An enthusiastic new user would have spent probably a half hour or more at this point carefully filling the the bug report and wading through a whole bunch of stuff thats pretty geek only to be faced with no MTA, a bug report that's going nowhere and no idea where to turn next.

 MTA's are hard for new people to configure in a way that actually works, so I'd agree with what appears to be the general sentiment of this thread of responses, why not replace the whole thing with an dialog box and a link to launchpad.net?

Cheers,
Craig

I tried using BugBuddy (as suggested by the crash/error message when one of the applets failed) and, if I hadn't had the option to save the report, the work would of been wasted. In my opinion, it should either be configured for us "mere mortals" or removed. As it is now, it could be a major source of frustration for a variety of users.

With launchpad-integration, do we even need to ship reportbug or bugbuddy?

subscribe <email address hidden>
subscribe <email address hidden>

Some sort of crash-detection-and-info-gathering is nice, though I agree
it should then deliver data to Launchpad in one way or another. I
wonder if this should not work as follows:

- if we detect a segfault on a normal desktop, we ask the user if they
want to help debug it
- if they agree, we fetch and install the debugging libraries
- next time, we can generate a detailed crash trace (iiuc) and send
that to Malone
- we extend Malone with some sort of stack trace handler, which allows
us to identify top crashing bugs

Mark Shuttleworth (sabdfl) wrote :

 subscribe <email address hidden>

On Wednesday 25 January 2006 18:42, Scott James Remnant wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/7839
>
> Comment:
> With launchpad-integration, do we even need to ship reportbug or
> bugbuddy?

How do we handle bugs for ubuntu-server? Most of the server services are not
desktop aware. Actually `reportbug` has to be changed for launchpad, or we
are providing a selfmade tool, or we have the white magic in our wands, to
determine the source package and send <insert your favorite bug information
here> to launchpad/Malone for this package.

For changing `reportbug`, we should get rid of creating bugs in malone with
gpg signed mails. I think a good spamfilter is enough to let new bugreports
go through without a signature. "Edit bugs" functionality but should work
with signed emails, as it is right now.

regards,
\sh

Scott: launchpad integration is nice but not efficient for crashes by example (no menu when the app has crashed, the user will not use that to send a backtrace if they don't know what a backtrace is and what they are supposed to do)

Mark: we have a specification about that: https://wiki.ubuntu.com/AutomatedProblemReports, that would be nice to get it implemented to get proper backtraces without having to ask users to rebuild a debug package (or to have to upload debug package for them somewhere)

Corey Burger (corey.burger) wrote :

FYI, I currently catching about a bug a day through the ubuntu-users spam filters that currently I am filing manually.

On Wed, Jan 25, 2006 at 06:54:05PM -0000, Mark Shuttleworth wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/7839
>
> Comment:
> subscribe <email address hidden>
> subscribe <email address hidden>
>
> Some sort of crash-detection-and-info-gathering is nice, though I agree
> it should then deliver data to Launchpad in one way or another. I
> wonder if this should not work as follows:
>
> - if we detect a segfault on a normal desktop, we ask the user if they
> want to help debug it
> - if they agree, we fetch and install the debugging libraries
> - next time, we can generate a detailed crash trace (iiuc) and send
> that to Malone
> - we extend Malone with some sort of stack trace handler, which allows
> us to identify top crashing bugs

This is basically what AutomatedProblemReports is about, however, it isn't
on the Dapper roadmap. Meanwhile, we need a stop gap to just get bug
reports into Malone via the existing tools. Kiko has agreed to deliver code
for filing the bug report, which we can integrate into reportbug and
(hopefully) bug-buddy. The primary remaining issue is authentication, since
the tools are designed to submit more-or-less anonymous reports but
Launchpad requires authentication.

--
 - mdz

Matt Zimmerman (mdz) wrote :

On Thu, Jan 26, 2006 at 08:07:20AM -0000, Corey Burger wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/7839
>
> Comment:
> FYI, I currently catching about a bug a day through the ubuntu-users
> spam filters that currently I am filing manually.

Thank you for doing this.

--
 - mdz

>This is basically what AutomatedProblemReports is about, however, it isn't
>on the Dapper roadmap. Meanwhile, we need a stop gap to just get bug
>reports into Malone via the existing tools. Kiko has agreed to deliver code
>for filing the bug report, which we can integrate into reportbug and
>(hopefully) bug-buddy. The primary remaining issue is authentication, since
>the tools are designed to submit more-or-less anonymous reports but
>Launchpad requires authentication.

I noticed, that reportbug in dapper still isn't able to feed malone with bugreports, yet.
I think reportbug would be a nice tool to give people, who are willing to supply ubuntu with bugreports, an overview with already reported related bugreports. So they can simple decide, if they should append it to existing bugreports, or report it the first time, or if there is no need to report it.

Then reportbug supplies the user and the maintainer with useful information like dependencies, architecture etc.

The most important thing is that it offers a very convenient tool for reporting bugs on the commandline.

If it's possible to combine this functionality with the idea's in https://wiki.ubuntu.com/AutomatedProblemReports then it would be a first choice for reporting bugs.

But reportbug in ubuntu is useless if it does not feed malone with bugreports. I didn't like the behavior of reportbug at all, to sent all the reports to the ubuntu users ML.

I think email adresses and spam filters are enough authentication for people who are willing to send bugreports to the BTS. Maybe it's possible that reportbug sends an identification string, which clarifies, the bug report comes from an ubuntu os and report bug?

Gerhard Gaußling

Zooko Wilcox-O'Hearn (zooko) wrote :

Many of the ideas and plans discussed in this thread are good ones, but the current reportbug is worse than useless -- it is actively harmful to community contributions, unless Corey Burger continues to manually catch all bug reports sent by reportbug.

Please remove reportbug from edgy *now*. Put it back when it is fixed to do more good than harm. Think of the other useful things that Corey Burger can start doing when he/she no longer needs to spend time manually inspecting spam to find bug reports misfiled by this stupid reportbug.

P.S. Thank you Corey Burger.

Daniel Robitaille (robitaille) wrote :

An update of the current process.

 We receive on average around 3 or 4 bug reports per day via reportbug, stuck in the mailing list moderation queue.

Then Corey Burger forwards them to me once a day. Every few days I do some basic bug triage on this pile of accumulated bug reports, and file the good/usefu/non-duplicate ones to Launchpad as new bug reports.

I also notify every single reporter that they should use the LP web interface instead. This response seems to generate a range of answers from the reporters; from no response, to "yes I will do it for future ones" to very negative replies expressing the disbelief that Ubuntu would ship with a broken reportbug.

auspex (auspex) wrote :

I've filed bugs via reportbug. I've _never_ received a confirmation, let alone instruction to use Launchpad. Frankly, one of the reasons people will use reportbug is because it's a whole lot easier than trying to figure out how to submit a bug in Launchpad (I've submitted about a half-dozen through Launchpad - it still isn't becoming simple). And disbelief that Ubuntu is STILL shipping with a broken reportbug, almost two years after this bug was opened (and more than one fix was announced as imminent) is quite understandable.

"...is quite not(?) understandable."
Why reinventing the wheel by develop a commandline interface (we need one) without respecting the good aspects of reportbug? BTW, reportbug is very well integrated in the debian BTS, and you don't need something else beside than a working MUA.
Is there any developement on a commandline interface to malone (similar to reportbug to the debian BTS), which would be easy to use by a GUI? Sorry, but I'm not at the edge of the state of developement.

Yagisan (yagisan) wrote :

I too express disbelif that reportbug still is not integrated into the rest of the Ubuntu bug reporting infrastructure. I've come to expect now, that it never will.

Whilst reportbug is useless for reporting bugs to Ubuntu, it is extremely useful for peole like myself that provide 3rd party Ubuntu repositories. Should you run reportbug on one of my packages, it actually works, and sends the email to an adress that is monitored for bugs on a daily basis. Removal of reportbug, would castarate my bug reporting system, because Ubuntu appears to rather work on something else.

Whilst I'd rather see reportbug fixed - It could be set up to end email to a specifc address for bugs rather then the mailing list.

 I read the article about the new BugReportingTool BERT in the wiki, and I'm quite happy about the new(?) activity to develop a similar tool as reportbug in the debian BTS for malone:

https://wiki.ubuntu.com/BugReportingTool?highlight=%28bugreport%29

This is very impressive and promising.

Thanks to the developpers!

Sanjoy Mahajan (sanjoy) wrote :

I switched from Debian to Ubuntu on my laptop, and am 95% happy with it. The 5% is that there's no easy way to report bugs, so I cannot easily contribute to improving Ubuntu.

In Debian, I used M-x report-bug in Emacs, and it was easy. In Ubuntu, the Emacs interface is gone (M-x report-debian-bug sends to Debian), and the report-bug command line program is not integrated into the bug reporting system.

Filing bugs on a web system is a damn pain, and report-bug or its Emacs equivalent is much easier. Sure, some people like the web interface, but others (like me) hate it. If report-bug would send its reports to a gateway that posted to the web system, that would be ideal and would get the maximum bug reports submitted to Ubuntu.

There seems to be some new activity to develop a bugreporting tool - webbased with commandline-iface and gui - as I mentioned in my earlier comment, here are the links:

https://launchpad.net/distros/ubuntu/+spec/bug-reporting-tool
https://wiki.ubuntu.com/BugReportingTool

Does anybody know something about the progress of this promising project?

Matt Zimmerman (mdz) wrote :

The first URL you gave (the launchpad one) includes a status field which provides that information if available.

Though Bug Buddy appears to be removed from the default Ubuntu menus, it is still integrated into Evolution, and maybe others.

For instance:

Evolution: Launch Evolution, click Help -> Submit a Bug Report; Hello Bug Buddy (and it looks to deliver to Gnome Bugzilla, because the recent bugs filed pulls from same)

Brad Bollenbach (bradb) wrote :

Would it be useful to make bug-buddy and/or reportbug work with a Malone XMLRPC filebug interface? If so, or in case anyone else doing bug reporting tool things is interested, the Malone filebug xmlrpc interface is in production.

  https://help.launchpad.net/MaloneXMLRPC

It still has restrictions, like having to authenticate with an LP account, but it works right now, it's not as bad as gpg-signing, and it may be better than 100% brokenness. Testers welcome.

Corey Burger (corey.burger) wrote :

If reportbug did this for edgy, that would be stunning. Better yet, once we test it in edgy, I propose we backport this to dapper and breezy, to fix the problem once and for all.

Did someone implement MaloneXMLRPC in reportbug and bug-buddy in edgy?
I'm using dapper.

Phill (pmackj1) on 2006-10-28
description: updated
description: updated
Denis Nikolaenko (geckoneer) wrote :

Also see #42673 (apt-listbugs should also consult ubuntu bug tracking system besides debian's one)

Matt Zimmerman (mdz) wrote :

This bug is well on its way to being fixed; apport in feisty now has the basic elements of an enhanced bug reporting tool, accessible via Help->Report a bug. It needs some additional entry points, e.g. to launch with a specified package name without launching the application.

Great that progress is being made. However, that sounds like a
graphical tool, which I agree is nice, but makes similar activities
difficult for those of us trying to run Ubuntu servers. Is there
progress towards making something like reportbug still work? I think
those of us doing server stuff would be happy to configure the program
to use a launchpad login or something similar.

Happy to help with that, by the way.

Monty

On 1/26/07, Matt Zimmerman <email address hidden> wrote:
> This bug is well on its way to being fixed; apport in feisty now has the
> basic elements of an enhanced bug reporting tool, accessible via
> Help->Report a bug. It needs some additional entry points, e.g. to
> launch with a specified package name without launching the application.
>
> ** Changed in: Ubuntu
> Assignee: (unassigned) => Martin Pitt
> Status: Confirmed => In Progress
>
> --
> Ubuntu bug reporting tools need to point to Ubuntu bug systems
> https://launchpad.net/bugs/7839
>

Matt Zimmerman (mdz) wrote :

On Sat, Jan 27, 2007 at 01:08:59AM -0000, Monty Taylor wrote:
> Great that progress is being made. However, that sounds like a
> graphical tool

It is a library with a graphical front-end...

> Happy to help with that, by the way.

...for which a command-line front-end could be written. Note that a web
browser is required to finish off the process.

--
 - mdz

Monty Taylor (mordred) wrote :

On 1/26/07, Matt Zimmerman <email address hidden> wrote:
> On Sat, Jan 27, 2007 at 01:08:59AM -0000, Monty Taylor wrote:
> > Great that progress is being made. However, that sounds like a
> > graphical tool
>
> It is a library with a graphical front-end...
>
> > Happy to help with that, by the way.
>
> ...for which a command-line front-end could be written. Note that a web
> browser is required to finish off the process.

Sweet. I'll look at it and see what I can do. Still, anything
requiring a web browser is a usability problem for server
environments. But I suppose it can be scripted with a web client. A
web services version of the web site side of things would be very
helpful.

Monty

Matt Zimmerman (mdz) wrote :

On Sat, Jan 27, 2007 at 08:07:15AM -0000, Monty Taylor wrote:
> On 1/26/07, Matt Zimmerman <email address hidden> wrote:
> > On Sat, Jan 27, 2007 at 01:08:59AM -0000, Monty Taylor wrote:
> > > Great that progress is being made. However, that sounds like a
> > > graphical tool
> >
> > It is a library with a graphical front-end...
> >
> > > Happy to help with that, by the way.
> >
> > ...for which a command-line front-end could be written. Note that a web
> > browser is required to finish off the process.
>
> Sweet. I'll look at it and see what I can do. Still, anything
> requiring a web browser is a usability problem for server
> environments. But I suppose it can be scripted with a web client. A
> web services version of the web site side of things would be very
> helpful.

There is an XML-RPC interface for filing a bug, but it doesn't (yet) support
the additional metadata apport provides. I imagine that could be remedied
without too much trouble (subscribing BjornT).

--
 - mdz

Martin Pitt (pitti) wrote :

Hi,

Monty Taylor [2007-01-27 8:07 -0000]:
> On 1/26/07, Matt Zimmerman <email address hidden> wrote:
> > On Sat, Jan 27, 2007 at 01:08:59AM -0000, Monty Taylor wrote:
> > > Great that progress is being made. However, that sounds like a
> > > graphical tool
> >
> > It is a library with a graphical front-end...
> >
> > > Happy to help with that, by the way.
> >
> > ...for which a command-line front-end could be written.

This was on my mental wishlist anyway, although not very
high-priority. Thanks to the abstract UI code it is pretty easy,
though, so if you are interested to help, please grab me (pitti) in
#ubuntu-devel and I'll give you a heads-up about the code structure.

> Note that a web
> > browser is required to finish off the process.
>
> Sweet. I'll look at it and see what I can do. Still, anything
> requiring a web browser is a usability problem for server
> environments. But I suppose it can be scripted with a web client. A
> web services version of the web site side of things would be very
> helpful.

For reporting crash reports, there's not much that is necessary to be
entered interactively in the Launchpad bug filing page. So with a
little help from Malone it should actually be possible to file a bug
with automatic scripts.

However, there are quite a few text-based webbrowsers around (links,
lynx, w3m) which should work just fine now. The abstract UI
falls back to Python's webbrowser module which supports aforementioned
browsers.

Martin

auspex (auspex) wrote :

I agree with Monty that it's nice that a way to submit bugs exist, but this bug is about reportbug & bug-buddy. As it is now, if it's a KDE bug, I submit it via the KDE gui, to KDE, and skip Ubuntu. If the help menus start pointing to this tool, then it'll go to launchpad, and that's great - but I _still_ won't be able to submit bugs via reportbug.

So why is reportbug still in the Ubuntu distribution?

Sebastien Bacher (seb128) wrote :

There is no problem with bug-buddy and apport is used for GNOME on feisty

Matt Zimmerman (mdz) wrote :

On Mon, Jan 29, 2007 at 05:16:24PM -0000, auspex wrote:
> I agree with Monty that it's nice that a way to submit bugs exist, but
> this bug is about reportbug & bug-buddy. As it is now, if it's a KDE
> bug, I submit it via the KDE gui, to KDE, and skip Ubuntu. If the help
> menus start pointing to this tool, then it'll go to launchpad, and
> that's great - but I _still_ won't be able to submit bugs via reportbug.
>
> So why is reportbug still in the Ubuntu distribution?

Reportbug is no longer part of the default install (this changed with 6.10).
It is not removed from existing systems, because the user could very well be
using it, or have installed it explicitly.

It is still in main because a supported package indirectly depends on it
(dpkg-dev-el). We'll have to evaluate whether this package is worth any
confusion resulting from reportbug being in main.

--
 - mdz

auspex (auspex) wrote :

What? There can be less confusion not having reportbug for dpkg-dev-el, than from having a reportbug that has _never_, for the entire life of Ubuntu, worked as it should?

imo, removing reportbug from the distribution is the only way this bug is ever going to get closed.

Matt Zimmerman (mdz) wrote :

On Tue, Jan 30, 2007 at 12:44:57AM -0000, auspex wrote:
> What? There can be less confusion not having reportbug for dpkg-dev-el,
> than from having a reportbug that has _never_, for the entire life of
> Ubuntu, worked as it should?
>
> imo, removing reportbug from the distribution is the only way this bug
> is ever going to get closed.

I'm not inclined to remove reportbug (which is still useful as an interface
to the Debian BTS and other projects which use debbugs) from Ubuntu simply
to avoid confusion. We also ship bug-buddy, for example, for similar
reasons.

It is worth considering, though, moving it from main to universe, since it
is an auxiliary tool which is useful to relatively few users. I've added
this to the agenda for this evening's meeting of the Technical Board for
discussion.

--
 - mdz

Martin Pitt (pitti) wrote :

Matt, what was the outcome of the TB discussion? I couldn't join that meeting, sorry.

Matt Zimmerman (mdz) wrote :

On Wed, Feb 07, 2007 at 12:07:21PM -0000, Martin Pitt wrote:
> Matt, what was the outcome of the TB discussion? I couldn't join that
> meeting, sorry.

The meeting ran very late (2 hours), so we didn't finish the discussion, and
agreed to carry on by email. I'll CC you on the discussion.

--
 - mdz

Martin Pitt (pitti) wrote :

Just as a small status update, since yesterday apport ships an 'ubuntu-bug' program in /usr/bin which allows you to file a bug against the distro (with just 'ubuntu-bug') or a package ('ubuntu-bug -p package').

that's an immense improvement, thanks! would still love to work
entirely from ocmmand-line but this is almost as good.

mp
On Thu, 2007-02-15 at 08:00 +0000, Martin Pitt wrote:
> Just as a small status update, since yesterday apport ships an 'ubuntu-
> bug' program in /usr/bin which allows you to file a bug against the
> distro (with just 'ubuntu-bug') or a package ('ubuntu-bug -p package').
>
--
Matt Price
History Dept
University of Toronto
<email address hidden>

Martin Pitt (pitti) wrote :

Matt, what's the current status of the TB discussion about demoting reportbug? Is there anything else you want to see changed?

On Thu, Mar 15, 2007 at 01:07:01PM -0000, Martin Pitt wrote:
> Matt, what's the current status of the TB discussion about demoting
> reportbug? Is there anything else you want to see changed?

I already unseeded dpkg-dev-el, which was the only thing keeping it in main.
It's just pending action from an archive admin to move the package to
universe (it's in anastacia.txt already).

--
 - mdz

Martin Pitt (pitti) wrote :

I just demoted reportbug and the -el bits.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.