On 2017-07-26 19:33:55 +0200, Francesco Poli wrote:
> On Fri, 21 Jul 2017 03:23:13 +0200 Vincent Lefevre wrote:
> > If you meant that these are the only supported options, then "notable"
> > is not the right word (as I understood "notable configuration
> > options", I thought these were the most important options in
> > practice, in the context of apt-listbugs).
>
> Maybe "relevant" would be clearer: what do you think?
Yes, that's much better.
But the first sentence should be modified too:
apt-listbugs understands APT configuration file (see apt.conf(5) for
more details).
is a bit meaningless. One can use / load / read / take into account
a configuration file, but I think that "understands" and
"configuration file" don't go together. It seems that the intent
was to mean the file format:
apt-listbugs understands the APT configuration file format (see
apt.conf(5) for more details).
Then, the issue is which configuration files are used. There's the
following option described in the man page:
-C apt.conf , --aptconf apt.conf
Specifies the APT configuration file to use.
"*the* APT configuration file to use" gives the impression that this
config file is used in place of /etc/apt/apt.conf, but according to
strace, it is read after "/etc/apt/apt.conf". If the current behavior
is the intent, then the above description should be:
Specifies an additional APT configuration file to use.
Similar issue with the -h help text.
Section "CONFIGURATION FILE" should say which configuration files
are used (this is not clearly documented yet, see above). Moreover,
Section "FILES" mentions
/etc/apt/apt.conf.d/10apt-listbugs
but /etc/apt/apt.conf and all the files from /etc/apt/apt.conf.d/ are
used too, aren't they? I suppose that /etc/apt/apt.conf.d/10apt-listbugs
is just the one where one should put apt-listbugs related options (those
to invoke apt-listbugs, like DPkg::Pre-Install-Pkgs, and those for
apt-listbugs).
> > > As far as the feature request itself is concerned, it seems to me
> > > that apt.conf(5) man page says:
> > >
> > > | The option timeout sets the timeout timer used by the method; this
> > > | value applies to the connection as well as the data timeout.
> > >
> > > It's not too clear to me whether the value is in seconds or in some
> > > other unit of measurement. Where is this documented?
> >
> > I was wondering the same thing (since I had to use this option for
> > "apt"), and assumed that this was in seconds, as this is the standard
> > time unit (and the man page also mentions "seconds" for other time
> > options). And indeed, this corresponds to the observed behavior.
>
> OK, maybe you should ask for confirmation to Apt developers and request
> them to properly document that the timeout has to be specified in
> seconds.
Done in this bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869832
> > That would be strange that standard modules wouldn't allow a
> > configurable timeout.
>
> Could you please perform the following test?
>
> As root, back up one file:
>
> # cp -ai /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/btssoap.rb /root/
>
> Then, edit lines 35÷37 of the file itself (using VIM or any other
> editor of your choice):
>
> # vim /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/btssoap.rb
>
> Please try to set 10 (in stead of 999) for the three timeout values.
>
> Does this solve your issue?
I can't test for now, maybe tomorrow.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
