From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bengt Richter Subject: bug#38148: Guix packages old/broken version of qutebrowser Date: Sat, 9 Nov 2019 18:32:36 -0800 Message-ID: <20191110023236.GA900@PhantoNv4ArchGx.localdomain> References: <20191109100530.zdfrewfmengq7pud@hooch.localdomain> <87ftix9eqa.fsf@nckx> Reply-To: Bengt Richter Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:51037) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTd2F-0002ig-TB for bug-guix@gnu.org; Sat, 09 Nov 2019 21:33:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iTd2E-0005LM-Kv for bug-guix@gnu.org; Sat, 09 Nov 2019 21:33:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:41715) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iTd2E-0005LI-HY for bug-guix@gnu.org; Sat, 09 Nov 2019 21:33:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iTd2E-00062x-9S for bug-guix@gnu.org; Sat, 09 Nov 2019 21:33:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <87ftix9eqa.fsf@nckx> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Tobias Geerinckx-Rice Cc: Florian Bruhin , 38148@debbugs.gnu.org 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