Re: Is there any issue with reportbug in unstabl or bugs.debian.org?
On Wed, 12 Oct 2011 22:07:04 -0600, Bob Proulx wrote:
> Camaleón wrote:
>> Bob Proulx wrote:
>> > Camaleón wrote:
>> >> Besides, I'm sure you know that flash player plugin can contact you
>> >> webcam and audio devices very easily.
>> >
>> > Is that true on an ARM based platform? Remember that Debian supports
>> > a large number of architectures. AFAIK there is no Adobe Flash
>> > available for ARM based systems.
>>
>> And what has ARM to do with this? Are you running an ARM based machine?
>> Yes? Then good for you :-) But people running flash player on their
>> systems are subject to that type of scannings.
>
> Yes, an ARM machine. And I picked that one because there is no Adobe
> Flash for ARM.
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.
>> > Is that true with Gnash (GNU Flash)? Gnash is the only flash player
>> > on my main desktop (although other machines of mine have the Adobe
>> > proprietary player). (Although I mentioned ARM above my main desktop
>> > is amd64. I didn't want to be misleading here. But I do have ARM
>> > based systems.)
>>
>> Good, but again, are we talking about "you" specifically or we are
>> taking a more wide user case?
>
> 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?
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 am telling you what happens right now with technology that is
>> available in our systems, I can't speak for every concrete desktop
>> there is on the earth as you can understand...
>
> 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? In what way
is Bugzilla reporting tool -or similar applications- limiting any of the
above, being also "open source"? ;-)
>> 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.
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.
>> Bugzilla (and related web based bug tracking systems) also provides
>> wizards which guide the user to write the report. It's the same as
>> reportbug, you can customize the level of help you want to receive and
>> set that level as the default for the next time.
>
> 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 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.
>> > But I disagree completely here that a web browser filling in a web
>> > form has access to the local system as it is intended to be
>> > impossible by design and security layers to run local programs across
>> > the local filesystem as a web form. Note that Javascript runs inside
>> > a security layer and is restricted from this access.
>>
>> 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 :-)
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.
>> That's all. It's possible, easy and convenient for the user that can
>> run the script when he/she wants and attach it to the bug later, when
>> there is Internet connection, for example.
>
> 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.
>> > Try moving it out of the way and running without local customization.
>> >
>> > $ mv ~/.reportbugrc reportbugrc.suspect $ reportbug -b somepackage
>>
>> I had to not only remove that config file several times but also set
>> "ncurses" GUI as the default to avoid perpetual crashes...
>
> Does that mean that when you were experiencing crashes you were using a
> graphical GUI interface?
Yes, the GUI crashed more often than ncurses.
> 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?
> 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 ;-). The GUI is an option and it's indeed _the default_ when you
launch reportbug from the GNOME menu ("reportbug --exit-prompt --ui
gtk2").
¹http://www.arm.com/about/newsroom/26062.php
Greetings,
--
Camaleón
Reply to: