bug#38148: Guix packages old/broken version of qutebrowser

[Bengt Richter]

On +2019-11-09 17:49:49 +0100, Tobias Geerinckx-Rice via Bug reports for GNU 
Guix wrote:
> Florian,
> 
> [I'm not a regular qutebrowser user, nor maintainer — I don't think we have
> one.]
> 
> Florian Bruhin 写道：
> > I'm the upstream author of qutebrowser - it looks like Guix currently
> > packages
> > qutebrowser 0.11.0: https://guix.gnu.org/packages/qutebrowser-0.11.0/
> > 
> > That version is very outdated (July 2017, there have been 28 new
> > releases since
> > then). It has various known security issues, but currently it just
> > crashes
> > outright, because such an old version isn't compatible with Qt 5.11
> > which is
> > packaged in Guix.
> > 
> > That results in me getting crash reports around once per week - at this
> > point,
> > it'd probably be better to not package qutebrowser at all, seeing that
> > nobody
> > seems to maintain that package for a long time now.
> 
> Thank you for letting us know.  My apologies for the noise from these
> useless crash reports.
> 
> Is there a supported way to replace the default bug report URL with our own?
> 
> If not, I could patch qutebrowser to pop up a dialogue with our bug tracker
> (e-mail) address instead.  The crash report itself would likely be lost.
> 
> I've tried qutebrowser 1.8.1 with QtWebKit and it runs, but then freezes (@
> 0% CPU) after some minutes.  I had to SIGKILL it. However, so does 0.11.0.
> 
> I'll try to get it to run, and hopefully the state of qutebrowser's
> dependencies in Guix will improve as well.
> 
> Kind regards,
> 
> T G-R

On reading the above, I wonder if we can invent a useful measure of
"runs" vs "works" vs "crashes" that could automatically be visible
in "guix show whatever-package".

I mean, there is a huge difference in confidence (at least on my part :)
between knowing that two developers have successfuly built and run a package
for the first time after refurbishing some orphan package vs knowing that
a thousand users have been using a tool many times daily for months without 
problems.

Could packages be instrumented with a simple 
invocation-with-normal/abnormal-exit
counter intialized on install, that could be voluntarily submitted to
some guix email addrress for automatic reliability-score update that
guix show whatever-package then accesses and presents?

Some finer-grain reporting would problably be desirable for packages that
install many executables.

A service could be enabled to send reports periodically for a list of packages
in use by a particular user, at the user's opt-in option of course.

I guess you'd have to have some guard against robo-shill-bots pumping
successful-use scores, but WDYT of the general idea?

Maybe also a count of historical CVE's against any inputs to the package build?
Well, the imagination rambles, but maybe something simple to start with could
test the usefulness?
-- 
Regards,
Bengt Richter