Camaleón wrote:
> Bob Proulx wrote:
> > Yes, an ARM machine. And I picked that one because there is no Adobe
> > Flash for ARM.
>
> (although it seems that ARM already supports Flash Player¹)
I did not know that ARM now had closed source proprietary binary blobs
for it. As you can see ARM truly is a first class architecture. :-)
> Again, I selected Flash player as an example of what can be done through
> a web browser. HTML5 was another example I used. If you don't like this
> specific example (although it seems that ARM already supports Flash
> Player¹), you can rename "flash player" by "java" or whatever plugin you
> prefer.
Regardless of what you substitute in there those all operate by design
in a sandbox with limited access to the underlying host. Otherwise it
creates a security vulnerability. And of course when the sandbox is
penetrated due to a bug then an actual vulnerability exists and must
be fixed.
> > I am talking about "Debian". This is a Debian mailing list. Debian
> > supports many architectures and not just 32-bit x86. Are we talking
> > about "you" specifically here running a 32-bit x86 architecture and able
> > to run Adobe Flash? :-)
>
> But this is not about "Debian" but "bug reporting" for Debian.
>
> And reporting bugs can happen on any platform. You can be running Debian
> but having the system at a completely unbootable stage nd you need to
> report a bug in a windows/macos/solaris machine... what to do then if
> reportbug is not available under those systems? Manually gather the
> required data and write an e-mail?
Yes! That is exactly correct. You are expected to write an email.
http://www.debian.org/Bugs/Reporting
Sending the bug report via e-mail
You can report bugs in Debian by sending an e-mail to
submit@bugs.debian.org with a special format described
below. reportbug (see above) will properly format the e-mails for you;
please use it!
As seen by the volume of email on this mailing list, sending an email
is very easy making this form of bug reporting very accessible.
> I'd say "interoperability" is the key for a Bugzilla-alike reporting
> system. Interoperability and "standarization" between projects because
> Bugzilla is a very well-known platform in other open source projects so
> for users who were already used to that system, the learning curve will
> be "zero" when they have to report in Debian.
I reject the argument that whatever is most popular, whatever is used
by the most people, is the best method just because it has the most
users using it.
And since Debian isn't the most popular operating system on the planet
I dare say that all of us Debian users have also rejected that too.
Otherwise we would not be running Debian but would instead be running
a more popular operating system.
> > I am talking about mainstream Debian systems. Debian has been called
> > the Universal Operating System for good reason. It runs on many
> > different architectures. Here is the official list.
> >
> > http://www.debian.org/ports/
> >
> > Debian is all about free(dom) software and the Social Contract and the
> > DFSG (Debian Free Software Guidelines) reflect this. If you have the
> > source code then you are not limited to a proprietary blob limiting you
> > to a specific architecture. If you have the source code then you are
> > free to run on whatever architecture you have available. This is a core
> > point of Debian and one that makes it "Outstanding". :-)
>
> Good. You have given me more arguments... Do you know something more
> open, universal and flexible than the web and its protocols?
Email? :-)
> In what way is Bugzilla reporting tool -or similar applications-
> limiting any of the above, being also "open source"? ;-)
At that point in the discussion I was referencing your referencing of
Adobe Flash which is a closed source proprietary binary blob and that
it is not available for every architecture. Sorry for not making that
clear. Adobe Flash is not free software neither is it open source
software, does not meet the DFSG, and cannot be part of Debian.
> >> To be sincere, I don't care about flash player very much, just put it
> >> as an example of what can be done with a small plugin and a browser.
> >
> > "Small" plugin? Maybe. (At 134K I think that is quite large.) But it
> > certainly has been a big problem for a long time. In any case it is a
> > good example of a bad example.
>
> It's very small for what it provides. It's about ~20 MiB of size in my
> system, though.
Did I say 134K? My bad. I slipped a finger and looked at the Java
plugin. The Adobe Flash plugin is 12M on an x86 system. That is
pretty large.
12M /usr/lib/flashplugin-nonfree/libflashplayer.so
> And for the "bad example", well, that's your personal opinion. I was not
> referring about its quality nor its code, but I find is a perfect example
> for an addon and its current capabilities. One thing is that we don't
> like Flash Player and another thing is neglecting its capabilities.
On this point we will simply have to agree to disagree.
> > To be clear I have never opposed having a web interface to submit bugs
> > to the BTS. I however think the best part of the BTS is the ability to
> > use email to interface to it. Email is so simple and pervasive that I
> > can't see ever wanting to use any other method.
>
> Maybe you did not read well what I said before.
I was reacting to and disagreeing with the premise that a web form can
run processes that access the local filesystem. You have maintained
throughout that this is possible and I have maintained throughout that
this is not possible and cannot be possible without introduction
security holes. That has been the critical contentious point in the
discussion. So far most rationale readers have had the good sense to
ignore the discussion and let us rant at each other. :-)
Along the way there was discussion about reportbug crashing. I
believe the standard reportbug to be rock solid. You believe it to be
terrible unreliable and buggy. Through the discussion it was revealed
that invoking reportbug through the GNOME menu system starts it using
a graphical GUI system. That graphical GUI was previously unknown to
me. I have only ever launched it from a shell prompt. Who would have
thought that someone would have written a GUI for such a simple tool?
I find that unfathomable. I daresay that you believe the GUI to be
the standard interface to reportbug and probably the only way you had
ever seen it. Apparently that interface is unreliable. I believe the
text interface to be the standard interface. Apparently that
interface is reliable.
> I wouldn't like to see reportbug dissapearing nor losing the possibility
> to send bug reports by e-mail , that would be terrible. What I said is I
> would like to have *an alternative* way for bug reporting. You like
> reportbug? You use it. You like the http interface? You use it. You like
> plain based e-mails? You write them. It's all about possibilities.
You are drifting off topic. All of that is fine. I don't think you
will find any words from me arguing that you should not have available
to you a web based bug reporting interface. If you or another wanted
to write one that would be fine with me.
I did say that the ability of reportbug to run processes on the local
filesystem and to generate the bug report template is a highly useful
convenience. And that is something that a web browser cannot do.
> >> Oh, come on, is not that hard. In the worst scenario, you can tell the
> >> user to download a script with instructions to run it and then send the
> >> output to a file to be uploaded with the report.
> >
> > I think that would be teaching users bad habits. Most users are not
> > well versed on the details of verifying trust paths from scripts
> > downloaded from the Internet.
>
> Why "bad habits"? That's nonsense, you are instructing users how to deal
> with command line and scripts :-)
Sigh. I choose not to participate in this topic drift.
> What indeed is a "bad habit" is sending extra information about your
> system when you only want to open a "wishlist" report, for example. You
> are gratuitously exposing data that is not useful for the bug report and
> you could be sending sensitive information of the user system.
Sure. I always hate it when people do not remove the instructions to
the reporting user from the template too.
> > So... There could be a script on the web site. The user could download
> > the script and run it. That script could be called something like
> > "reportbug"? :-)
>
> Nope, reportbug does not run specific tests, it's a generic app to
> generate and track (somehow) bug reports.
The purpose of reportbug is to generate an email message to the BTS
with reasonable content. The BTS does all tracking. In the
generation of the email template reportbug can run package specific
bug helpers to gather information. Then after having generated a
template it launches your editor so that you can edit the template and
turn it into a bug report. Upon finish it hands the message off to
the mail transport agent for transport and delivery. Simple. But
there is a *lot* of validation checking along the way which is what
gives it the value add over just sending an email message.
> > Does that mean that when you were experiencing crashes you were using a
> > graphical GUI interface?
>
> Yes, the GUI crashed more often than ncurses.
Does reportbug have a curses interface? Until you proved to me that
it had a GUI I had only ever known about the command line text
interface. So now I am shy of talking about a curses interface.
> > If so then that is not the default and must have been customized that
> > way. If so then that explains the problem.
>
> You mean the GUI interface is known to be problematic?
After your report and Disc Magnet's report corroborating it I would
say yes there is a problem. Someone experiencing the problem should
report it. Once reported then it will become a known problem. It was
not known to me because I didn't even know it had a GUI. I can't
report it since I don't use it and have never experienced the problem.
> > I dare say that people like me who have never experienced a crash are
> > using 'reportbug' in the default configuration and those that are
> > complaining about it crashing have turned on some GUI interface. There
> > appears to be one. I have never used it. It is not the default
> > setting. I didn't even know it existed until a moment ago.
>
> Then you should launch it from time to time and see how/if it works for
> you ;-).
I did. Wow. I can't imagine using that interface a second time. It
didn't crash for me. But it was unwieldy and extremely ugly.
> The GUI is an option and it's indeed _the default_ when you
> launch reportbug from the GNOME menu ("reportbug --exit-prompt --ui
> gtk2").
To be clear that isn't the reportbug default. That menu item seems to
be new in Squeeze. I don't see it in Lenny. The menu system is
shared among desktop systems including GNOME, KDE, and others.
In any case this thread has exhausted me. I think I will let it
expire and die here.
Bob
Attachment:
signature.asc
Description: Digital signature