Your message dated Sun, 16 Jun 2013 23:21:19 +0200
with message-id <[email protected]>
and subject line Re: Bug#711874: apt-listbugs: should allow the user to filter
on more severity/tag combinations
has caused the Debian Bug report #711874,
regarding apt-listbugs: should allow the user to filter on more severity/tag
combinations
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
711874: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711874
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: apt-listbugs
Version: 0.1.9
Severity: wishlist
According to the apt-listbugs(1) man page, apt-listbugs can filter
on severities and tags, but not on more specific combinations. For
instance, I would like to be able to list all bugs with *either*
of the following conditions:
* critical,grave,serious severity;
* security tag.
(note: *either*, not *both*).
Combinations like
* critical,grave,serious severity; or
* important severity and security tag.
could be useful too.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.9-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages apt-listbugs depends on:
ii apt 0.9.8.2
ii libruby1.8 1.8.7.358-7
ii ruby-debian 0.3.8+b1
ii ruby-gettext 2.3.9-1
ii ruby-httpclient 2.2.4-2
ii ruby-xmlparser 0.7.2-2
ii ruby1.8 1.8.7.358-7
apt-listbugs recommends no packages.
Versions of packages apt-listbugs suggests:
ii chromium [www-browser] 27.0.1453.110-1
ii debianutils 4.3.4
ii elinks [www-browser] 0.12~pre6-1
ii epiphany-browser [www-browser] 3.4.2-2.1
ii iceweasel [www-browser] 21.0-1
ii links [www-browser] 2.7-2
ii links2 [www-browser] 2.7-2
ii lynx-cur [www-browser] 2.8.8dev.15-2
ii midori [www-browser] 0.4.3+dfsg-0.1
ii reportbug 6.4.4
ii uzbl [www-browser] 0.0.0~git.20120514-1.1
ii w3m [www-browser] 0.5.3-8
-- Configuration Files:
/etc/apt/apt.conf.d/10apt-listbugs changed [not included]
-- no debconf information
--- End Message ---
--- Begin Message ---
Control: tags -1 - moreinfo
On Sat, 15 Jun 2013 17:39:24 +0200 Vincent Lefevre wrote:
> On 2013-06-15 16:17:17 +0200, Francesco Poli wrote:
> > On Tue, 11 Jun 2013 01:21:11 +0200 Vincent Lefevre wrote:
> > [...]
> > > On 2013-06-10 21:00:54 +0200, Francesco Poli wrote:
> > [...]
> > > > I agree that it would be useful, but I am afraid that implementing the
> > > > parser for such options would be somewhat of an overkill for a simple
> > > > tool like apt-listbugs...
> > >
> > > I think a list of filters could be both simple and sufficient.
> > > e.g. with a syntax like:
> > >
> > > apt-listbugs -f s:critical,grave,serious -f s:important,T:security apt
> >
> > This would still be a significant rewrite of the filtering features:
> > apt-listbugs currently queries the BTS (via SOAP) for bugs of the
> > desired severities, and then drops all the bugs that should be filtered
> > out (based on tags, bug numbers, and so forth...).
> > Hence all the filters are in AND with each other "by design", I would
> > almost say.
>
> I think that you could do something similar: query the BTS for bugs
> of the desired severities (on my example: critical, grave, serious,
> and important), and then drop all the bugs that should be filtered
> out (based on *severities*, tags, bug numbers, and so forth...). To
> implement the OR, an additional loop (on filters) would be needed;
> bugs should be regarded as being dropped by default, and in the loop,
> each condition should be reversed to mark the bug as kept instead of
> dropping it.
As I said, I feel that this would be a significant complication for a
simple tool such as apt-listbugs.
Moreover, the syntax you propose is not backward-compatible and I think
that turning it into a backward-compatible one would be tricky at best.
I am closing this bug report, since I don't feel that the additional
feature you requested would be worth the effort needed to implement it.
Sorry.
>
> > > However perhaps this won't happen very often.
> >
> > I re-iterate my suggestion to try this strategy and to let me know how
> > it worked.
>
> It's a bit slow because it seems that the bug reports are retrieved
> twice (they are not cached).
I can confirm that there's no form of caching (at least, nothing
explicitly implemented in the program; I am not 100 % sure about the
ruby SOAP client library, but I think it does not cache queries
transparently...): apt-listbugs needs the most up-to-date information
known to the BTS, therefore it queries the BTS SOAP interface each time.
As a consequence, the increase in execution time was expected:
basically, invoking apt-listbugs twice means you have to wait more or
less twice the time (apart from the ruby interpreter, which should
start a bit more quickly the second time...).
Sorry about this.
Bye and thanks for using apt-listbugs.
--
http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
New GnuPG key, see the transition document!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpdIzzL8_8Lv.pgp
Description: PGP signature
--- End Message ---
