GNU bug report logs -
#38148
Guix packages old/broken version of qutebrowser
Previous Next
Full log
Message #11 received at 38148 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 5 years and 133 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.