Launchpad should give you the option to attach your apport collected information to an existing bug

This would be extremely useful for bugs which have been reported but marked invalid for lacking information and apport has captured the required data also for reports where maintainers request additional profiles.

in https://help.ubuntu.com/community/ReportingBugs theres info about command ubuntu-bug packagename
its almost on top.
and https://help.ubuntu.com/community/ReportingBugs#Filing%20bugs%20at%20Launchpad.net
has subsection Adding Apport Debug Information to an Existing Launchpad Bug
this could be written more preciseley like ubuntu-bug is to make new bug and apport-collect is to add to existing bug and it looks witch programms are affected so theres no need to use packagename in apport-collect
These are the main usefull commands to post bug about package witch doesnt have menu or cant be accesed.
The most usefull commands should be on top then following about old versions commands or a subsection about old version commands.

This affects apport collected bugs and ubuntu-bug collected bugs
Cant use ubuntu-bug to update bug and becouse of that time is wasted and also wasted bug reports
wasted time also trying to update bug using apport-collect couse it gave error.
You are not the reporter or subscriber of this problem report, or the report is a duplicate or already closed.

Please create a new report using "apport-bug".
to this bug https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/253803
i can overcome that by just suscribing but that will be wasting wasting time.
i would suggest that ill make bug reports but dont make that time consuming and strangely illogically difficult
with two commands witch if one doesnt adds updates then other cant add updates.
This is NOT useful if the report was not originally filed through Apport couse u need to use 2 different commands and to bug reporting are 3 commands involved apport witch takes crashes ubuntu-bug if user sees something is wrong nad apport-collect if som other user wants to add info to help couse hes really ******* of bug still existing

The problem with just telling users to use a different command is that they don't necessarily know how to cause the bug again. If they can't figure out how to cause it again then you lose the crash data that you could have collected.

The description of this bug is perfect. It is exactly what it is.

Moreover, from all the wiki labirynths about filing bugs etc., I remember that some months ago I digged a lot over ther and ultimately I really got the impression that the correct thing to do in this case is to file a duplicate and mark it as duplicate right away.

And that's still what I do... what else?

If many people have a serious crash when testing alpha-beta releases and Ubuntu developers are eager to fix such problem, it would be so much better to have the all the logs from everyone at the same report.

There was some discussion about this at UDS and the consensus
seemingly was not to allow others to apport-collect into an existing
bug. If the information is relevant, a note can be added to the
description to look at the other bug. The problem is that users don't
necessarily know if a bug is really a duplicate or not and the bug
reports end up being tangential and very hard to decipher if the
original report exists/still exists.

On 06/02/2010 08:14 AM, Leo wrote:
> <snip />
>
> If many people have a serious crash when testing alpha-beta releases and
> Ubuntu developers are eager to fix such problem, it would be so much
> better to have the all the logs from everyone at the same report.
>

While I generally agree that this bug should be fixed, LP should refuse adding the Information when the Status is either Fix Released/Committed (no point in adding it), Won't Fix (no point either) or Triaged (we already have what we need). Not sure about In Progress. And has someone thought about how to handle crash reports? Should the retracer run again or should we just discard coredumps etc.? How is one supposed to check if there's no private information in the crash logs?

The way files are attached and mails are sent all over could be improved by somehow grouping bunches of attached files together (both on mailing lists and on LP webpage display) to diminish the mess.

@Micah, I agree with the main argument, and that's more or less how I concluded that indeed I was supposed to file a new bug and tag it duplicated.
But there are side effects:
lots and lots of bugs that end up not being tagged duplicates creating really a lot of noise
many users will post a note pointing to the duplicate if they consider that the files might have interesting information, also creating noise and rendering the bug report webpage unreadable

Maybe create another status, instead of "Duplicate" it could be "Duplicate with crash logs" ?

According to Micah, it should be "Won't fix", right?

I don't think we have complete agreement about whether we should or shouldn't do this -- I imagine some maintainers would like this and know that some would not. I would like to keep the bug around as a reminder of the issue. Whether or not we do this the way the description here suggests is debatable, but understanding that it would be nice to have some means for apport-collecting into existing bugs is nice. I'll mark this Low priority since this is not an urgent issue for us, nor do we know exactly what we should do yet, but the problem is well understand.

Please do not toggle bugs out of the triaged state. You can mark the bug as affecting you with the green link above the table listing affected projects. This "affects me" data is tracked and is much more useful for helping us understand how an issue affects people than changing the status of a triaged bug.

Cheers,
deryck

FWIW, I think this is a good idea, though apport-collect will be driven automatically via whoopsie-daisy, so we may be able to remove most/all of the apport special casing in a couple of years (after older releases EOL).