Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-08-19 Thread Francesco Poli 
On Fri, 19 Aug 2016 15:18:35 +0200 Julian Andres Klode wrote:

> On Fri, Aug 19, 2016 at 02:14:22PM +0200, Julian Andres Klode wrote:
[...]
> > I basically fixed this locally in theory, but in practice
> > this does not seem fixable. We invoke our commands with a shell,
> > as you might be aware. The signal handling of shells is not portable:
> > 
> > This means that regardless what apt-listbugs exits with, the dash
> > shell it was invoked by will always exit with the SIGINT signal.

Yes, it will.
This should be due to the already mentioned (in this same bug
report [1]) bug #683671 [2], which appears to be unfortunately still
unfixed...

[1] https://bugs.debian.org/832593#15
[2] https://bugs.debian.org/683671

> 
> I now added a build-time option APT_SHELL; defaulting to /bin/bash,
> and a APT config option Dir::Bin::sh, defaulting to the value of
> APT_SHELL, that is used instead of /bin/sh.
> 
> So things should work now:
> 
> https://github.com/Debian/apt/compare/master...julian-klode:bugfix/sigint?expand=1

Thanks a lot, I am looking forward to testing this modification, as
soon as the new version of apt is uploaded to unstable or has migrated
to testing.

Bye!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp2eZg0bpEIO.pgp
Description: PGP signature

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-08-19 Thread Julian Andres Klode 
On Fri, Aug 19, 2016 at 02:14:22PM +0200, Julian Andres Klode wrote:
> On Sat, Aug 13, 2016 at 12:00:06AM +0200, Francesco Poli wrote:
> > On Fri, 12 Aug 2016 00:45:55 +0200 Julian Andres Klode wrote:
> > 
> > > On Fri, Aug 12, 2016 at 12:40:44AM +0200, Francesco Poli wrote:
> > [...]
> > > > Please reply to my question
> > [...]
> > > > 
> > > > In the meanwhile, I am reopening the bug.
> > > 
> > > Yes, sorry, I forgot to take this out of the changelog.
> > 
> > No problem, reopening the bug was easy enough...
> > 
> > > So, basically,
> > > AFAICT, what we should do is ignore the interrupt, because if the child
> > > process exits with any error, we will error out as well. And if a child
> > > exits because of a SIGINT, it's exit code won't be 0.
> > 
> > Well, this sounds reasonable, after all.
> > I haven't been able to find a counterargument, although you have to
> > take into account that I am no expert of signal handling, so I could be
> > wrong...
> > 
> > Please implement the fix soon.
> > Thanks for your time and helpfulness!
> 
> I basically fixed this locally in theory, but in practice
> this does not seem fixable. We invoke our commands with a shell,
> as you might be aware. The signal handling of shells is not portable:
> 
> This means that regardless what apt-listbugs exits with, the dash
> shell it was invoked by will always exit with the SIGINT signal.

I now added a build-time option APT_SHELL; defaulting to /bin/bash,
and a APT config option Dir::Bin::sh, defaulting to the value of
APT_SHELL, that is used instead of /bin/sh.

So things should work now:

https://github.com/Debian/apt/compare/master...julian-klode:bugfix/sigint?expand=1


-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-08-19 Thread Julian Andres Klode 
On Sat, Aug 13, 2016 at 12:00:06AM +0200, Francesco Poli wrote:
> On Fri, 12 Aug 2016 00:45:55 +0200 Julian Andres Klode wrote:
> 
> > On Fri, Aug 12, 2016 at 12:40:44AM +0200, Francesco Poli wrote:
> [...]
> > > Please reply to my question
> [...]
> > > 
> > > In the meanwhile, I am reopening the bug.
> > 
> > Yes, sorry, I forgot to take this out of the changelog.
> 
> No problem, reopening the bug was easy enough...
> 
> > So, basically,
> > AFAICT, what we should do is ignore the interrupt, because if the child
> > process exits with any error, we will error out as well. And if a child
> > exits because of a SIGINT, it's exit code won't be 0.
> 
> Well, this sounds reasonable, after all.
> I haven't been able to find a counterargument, although you have to
> take into account that I am no expert of signal handling, so I could be
> wrong...
> 
> Please implement the fix soon.
> Thanks for your time and helpfulness!

I basically fixed this locally in theory, but in practice
this does not seem fixable. We invoke our commands with a shell,
as you might be aware. The signal handling of shells is not portable:

$ cat trap.sh 
trap 'echo int' INT; sleep 10; exit 0
$ if dash -c ./trap.sh; then echo OK: $?; else echo FAIL: $?; fi
^Cint

FAIL: 130
$ if mksh -c ./trap.sh; then echo OK: $?; else echo FAIL: $?; fi
^Cint
OK: 0
$ if bash -c ./trap.sh; then echo OK: $?; else echo FAIL: $?; fi
^Cint
OK: 0

dash, which is our default shell, always exits with the interrrupt
signal.

This means that regardless what apt-listbugs exits with, the dash
shell it was invoked by will always exit with the SIGINT signal.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-08-12 Thread Francesco Poli 
On Fri, 12 Aug 2016 00:45:55 +0200 Julian Andres Klode wrote:

> On Fri, Aug 12, 2016 at 12:40:44AM +0200, Francesco Poli wrote:
[...]
> > Please reply to my question
[...]
> > 
> > In the meanwhile, I am reopening the bug.
> 
> Yes, sorry, I forgot to take this out of the changelog.

No problem, reopening the bug was easy enough...

> So, basically,
> AFAICT, what we should do is ignore the interrupt, because if the child
> process exits with any error, we will error out as well. And if a child
> exits because of a SIGINT, it's exit code won't be 0.

Well, this sounds reasonable, after all.
I haven't been able to find a counterargument, although you have to
take into account that I am no expert of signal handling, so I could be
wrong...

Please implement the fix soon.
Thanks for your time and helpfulness!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpHzY0siE_fh.pgp
Description: PGP signature

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-08-11 Thread Julian Andres Klode 
On Fri, Aug 12, 2016 at 12:40:44AM +0200, Francesco Poli wrote:
> Control: found -1 apt/1.3~rc1
> 
> 
> On Mon, 8 Aug 2016 01:05:31 +0200 Francesco Poli wrote:
> 
> [...]
> > > On Sun, Aug 07, 2016 at 12:22:47AM +0200, Francesco Poli wrote:
> [...]
> > > > [1] https://www.cons.org/cracauer/sigint.html
> [...]
> > Do I read the git diff output [2] correctly? It seems to me that the
> > modification implements the WUE approach (explained in [1]), rather
> > than the WCE approach.
> > I think that the WCE approach is really the way to go, since the hook
> > could use SIGINT for something very different from an abnormal exit.
> > Maybe, when the hook has finished its job, it exits successfully
> > without killing itself with a SIGINT. In that case, APT should *not*
> > abort the installation/upgrade!
> > 
> > [2] https://anonscm.debian.org/cgit/apt/apt.git/diff/?id=b2cfacf
> > 
> > In other words, I think that APT should wait for the child process to
> > exit (already implemented), but it should also figure out whether the
> > child process has exited on SIGINT or normally, in order to decide
> > whether it should abort or continue with the installation/upgrade.
> [...]
> > What is needed is the WCE strategy, as explained above.
> > Please implement it.
> > 
> > Thanks for your time.
> 
> Please reply to my question (quoted above).
> 
> In the meanwhile, I am reopening the bug.

Yes, sorry, I forgot to take this out of the changelog. So, basically,
AFAICT, what we should do is ignore the interrupt, because if the child
process exits with any error, we will error out as well. And if a child
exits because of a SIGINT, it's exit code won't be 0.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-08-11 Thread Francesco Poli 
Control: found -1 apt/1.3~rc1


On Mon, 8 Aug 2016 01:05:31 +0200 Francesco Poli wrote:

[...]
> > On Sun, Aug 07, 2016 at 12:22:47AM +0200, Francesco Poli wrote:
[...]
> > > [1] https://www.cons.org/cracauer/sigint.html
[...]
> Do I read the git diff output [2] correctly? It seems to me that the
> modification implements the WUE approach (explained in [1]), rather
> than the WCE approach.
> I think that the WCE approach is really the way to go, since the hook
> could use SIGINT for something very different from an abnormal exit.
> Maybe, when the hook has finished its job, it exits successfully
> without killing itself with a SIGINT. In that case, APT should *not*
> abort the installation/upgrade!
> 
> [2] https://anonscm.debian.org/cgit/apt/apt.git/diff/?id=b2cfacf
> 
> In other words, I think that APT should wait for the child process to
> exit (already implemented), but it should also figure out whether the
> child process has exited on SIGINT or normally, in order to decide
> whether it should abort or continue with the installation/upgrade.
[...]
> What is needed is the WCE strategy, as explained above.
> Please implement it.
> 
> Thanks for your time.

Please reply to my question (quoted above).

In the meanwhile, I am reopening the bug.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpw7VxCIrN3w.pgp
Description: PGP signature

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-08-07 Thread Francesco Poli 
On Sun, 7 Aug 2016 01:02:29 +0200 Julian Andres Klode wrote:

> On Sun, Aug 07, 2016 at 12:22:47AM +0200, Francesco Poli wrote:
[...]
> > I believe that trapping SIGINT and using this signal for something
> > other than an immediate exit is a perfectly legitimate use of SIGINT.
> > An already cited document [1] confirms this.
> >
> > [1] https://www.cons.org/cracauer/sigint.html
> 
> Fixed in git (but see below), and already tagged pending by the git hook.

Thanks for your reply!

Do I read the git diff output [2] correctly? It seems to me that the
modification implements the WUE approach (explained in [1]), rather
than the WCE approach.
I think that the WCE approach is really the way to go, since the hook
could use SIGINT for something very different from an abnormal exit.
Maybe, when the hook has finished its job, it exits successfully
without killing itself with a SIGINT. In that case, APT should *not*
abort the installation/upgrade!

[2] https://anonscm.debian.org/cgit/apt/apt.git/diff/?id=b2cfacf

In other words, I think that APT should wait for the child process to
exit (already implemented), but it should also figure out whether the
child process has exited on SIGINT or normally, in order to decide
whether it should abort or continue with the installation/upgrade.

> 
> > After pressing [Ctrl+C], the hook (simple-trap-sigint.sh) shows the
> > expected "Press [Enter] to continue" message, but immediately goes
> > on with its output, without waiting for input from the user.
> > The final prompt is obtained after hitting [Enter]. But apt has
> > already exited, instead of waiting for the hook to exit and checking
> > whether the hook was killed by a SIGINT...
> 
> Well, it obviously continues directly, because APT is feeding it
> package names via a pipe. But once all package names are piped
> thing should work as expected.

Ah, you are right, thanks for explaining this aspect of the behavior I
experienced during my tests!

> 
> We could also stop writing package names when interrupted, but I'm
> not sure if that makes a difference: Some might be buffered already.
> It's also a lot more work.

I don't think this is needed...

What is needed is the WCE strategy, as explained above.
Please implement it.

Thanks for your time.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpLr9YAtuZOP.pgp
Description: PGP signature

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-08-06 Thread Julian Andres Klode 
On Sun, Aug 07, 2016 at 12:22:47AM +0200, Francesco Poli wrote:
> Control: reassign -1 apt 1.3~pre2
> Control: affects -1 + apt-listbugs
> 
> 
> 
> On Fri, 29 Jul 2016 19:41:28 +0200 Francesco Poli wrote:
> 
> > Hence, I am suspecting that the misbehavior has something to do with
> > the way the package manager invokes its hooks...
> [...]
> > 
> > I am Cc-ing the APT Development Team: could any of you take a look at
> > bug #832593, please?
> > Any ideas on why a hook that traps SIGINT runs into troubles, when it
> > catches such signal, but does not immediately exit?
> 
> Hello again, APT Development Team.
> 
> I prepared an overly simple script that traps SIGINT, asks the user to
> press [Enter] and then goes on with its own business
> (simple-trap-sigint.sh, that should be found attached to this message).
> 
> I believe that trapping SIGINT and using this signal for something
> other than an immediate exit is a perfectly legitimate use of SIGINT.
> An already cited document [1] confirms this.

Fixed in git (but see below), and already tagged pending by the git hook.

> After pressing [Ctrl+C], the hook (simple-trap-sigint.sh) shows the
> expected "Press [Enter] to continue" message, but immediately goes
> on with its output, without waiting for input from the user.
> The final prompt is obtained after hitting [Enter]. But apt has
> already exited, instead of waiting for the hook to exit and checking
> whether the hook was killed by a SIGINT...

Well, it obviously continues directly, because APT is feeding it
package names via a pipe. But once all package names are piped
thing should work as expected.

We could also stop writing package names when interrupted, but I'm
not sure if that makes a difference: Some might be buffered already.
It's also a lot more work.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-08-06 Thread Francesco Poli 
Control: reassign -1 apt 1.3~pre2
Control: affects -1 + apt-listbugs



On Fri, 29 Jul 2016 19:41:28 +0200 Francesco Poli wrote:

> Hence, I am suspecting that the misbehavior has something to do with
> the way the package manager invokes its hooks...
[...]
> 
> I am Cc-ing the APT Development Team: could any of you take a look at
> bug #832593, please?
> Any ideas on why a hook that traps SIGINT runs into troubles, when it
> catches such signal, but does not immediately exit?

Hello again, APT Development Team.

I prepared an overly simple script that traps SIGINT, asks the user to
press [Enter] and then goes on with its own business
(simple-trap-sigint.sh, that should be found attached to this message).

I believe that trapping SIGINT and using this signal for something
other than an immediate exit is a perfectly legitimate use of SIGINT.
An already cited document [1] confirms this.

[1] https://www.cons.org/cracauer/sigint.html

When this script is called by a trivial script executed by bash
(calling-script.sh, also attached), everything works as expected, since
GNU bash implements the WCE approach (explained in [1]):

  $ ./calling-script.sh 
  Start
  Hello!
  Output 1
  Output 2
  Output 3
  ^CPress [Enter] to continue
  Output 4
  Output 5
  Output 6
  Output 7
  Output 8
  Output 9
  Output 10
  Bye!
  End

Of course, the last part of the output (from "Output 4" onwards) is
shown after hitting [Enter], as requested.

On the other hand, when the script is executed by APT as a hook, things
go wrong somehow:

  # cat /etc/apt/apt.conf.d/05test 
  DPkg::Pre-Install-Pkgs {"/root/simple-trap-sigint.sh";};
  # apt install locales
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  The following additional packages will be installed:
libc-l10n
  The following NEW packages will be installed:
libc-l10n locales
  0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
  Need to get 0 B/4198 kB of archives.
  After this operation, 17.1 MB of additional disk space will be used.
  Do you want to continue? [Y/n] 
  Hello!
  Output 1
  Output 2
  Output 3
  Output 4
  ^CPress [Enter] to continueOutput 5
  
  # Output 6
  Output 7
  Output 8
  Output 9
  Output 10
  Bye!
  
  #

After pressing [Ctrl+C], the hook (simple-trap-sigint.sh) shows the
expected "Press [Enter] to continue" message, but immediately goes
on with its output, without waiting for input from the user.
The final prompt is obtained after hitting [Enter]. But apt has
already exited, instead of waiting for the hook to exit and checking
whether the hook was killed by a SIGINT...

What's wrong? Does libapt implement the IUE approach (explained in [1])?
If this is the case, then I think that the WCE approach should be
implemented instead, at least when executing hooks, since some hooks
may use SIGINT for purposes other than an immediate exit.

I am consequently reassigning this bug report to apt/1.3~pre2 ...
Please fix this issue.

Thanks for your time.
Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


simple-trap-sigint.sh.gz
Description: application/gzip


calling-script.sh.gz
Description: application/gzip


pgpRb_ez1sNY2.pgp
Description: PGP signature

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-07-29 Thread Francesco Poli 
On Fri, 29 Jul 2016 00:41:47 +0200 Vincent Lefevre wrote:

> On 2016-07-28 22:48:54 +0200, Francesco Poli wrote:
> > This was somewhat intended: hitting [Ctrl-C] was supposed to interrupt
> > the bug report retrieval, while giving the user a chance to decide what
> > to do (retry and/or aborting and/or going on with the
> > installation/upgrade)...
> 
> So, apt-listbugs traps SIGINT.

Yes, it does.

> 
> > > but apt-listbugs is still running and attached to the terminal:
> > > 
> > > UIDPID  PPID  C STIME TTY  TIME CMD
> > > root   702   701  1 12:36 pts/600:00:00 /usr/bin/ruby 
> > > /usr/sbin/apt-listbugs apt
> > 
> > ... this is instead unexpected!
> > I managed to reproduce the misbehavior, but I have no idea why it
> > happens.   :-(
> > 
> > The shell prompt should not reappear, while apt-listbugs is still
> > running!
> 
> Perhaps a problem on how SIGINT is handled, similar to what is
> described here if /bin/sh is involved somewhere:
> 
>   https://www.cons.org/cracauer/sigint.html
> 
> I suspect that some process (aptitude or a descendant) runs
> apt-listbugs with system(), which is based on /bin/sh

I noticed that the bug may be reproduced only when apt-listbugs is
invoked by a package manager (such as aptitude or apt or ...).

On the other hand, when apt-listbugs is invoked directly by the user,
as in:

  $ apt-listbugs list -s all aptitude

the bug is not triggered.

Hence, I am suspecting that the misbehavior has something to do with
the way the package manager invokes its hooks...

> , thus
> dash in most cases. So, it could be a consequence of this bug:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683671

Maybe, but I performed the following test:

  # cd /bin
  # ln -sf bash sh

and then I tried to reproduce the bug (with apt-listbugs invoked by
aptitude).
I was again able to reproduce the misbehavior, although dash was not
involved, as far as I can tell...

So I am more and more puzzled.


I am Cc-ing the APT Development Team: could any of you take a look at
bug #832593, please?
Any ideas on why a hook that traps SIGINT runs into troubles, when it
catches such signal, but does not immediately exit?

Please let me know, thanks a lot for your time and patience.



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpPYmBQXCADp.pgp
Description: PGP signature

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-07-28 Thread Vincent Lefevre 
On 2016-07-28 22:48:54 +0200, Francesco Poli wrote:
> This was somewhat intended: hitting [Ctrl-C] was supposed to interrupt
> the bug report retrieval, while giving the user a chance to decide what
> to do (retry and/or aborting and/or going on with the
> installation/upgrade)...

So, apt-listbugs traps SIGINT.

> > but apt-listbugs is still running and attached to the terminal:
> > 
> > UIDPID  PPID  C STIME TTY  TIME CMD
> > root   702   701  1 12:36 pts/600:00:00 /usr/bin/ruby 
> > /usr/sbin/apt-listbugs apt
> 
> ... this is instead unexpected!
> I managed to reproduce the misbehavior, but I have no idea why it
> happens.   :-(
> 
> The shell prompt should not reappear, while apt-listbugs is still
> running!

Perhaps a problem on how SIGINT is handled, similar to what is
described here if /bin/sh is involved somewhere:

  https://www.cons.org/cracauer/sigint.html

I suspect that some process (aptitude or a descendant) runs
apt-listbugs with system(), which is based on /bin/sh, thus
dash in most cases. So, it could be a consequence of this bug:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683671

(note: the particular problem with Emacs has been "fixed" in Emacs,
i.e. Emacs no longer uses SIGINT for Ctrl-G or something like that,
but the problem related to SIGINT is still present in dash.)

> > Now, if I type Return, it is grabbed by apt-listbugs though I have
> > my shell prompt, and I get an additional error message:
> > 
> > root@zira:/home/vinc17# aptitude
> > Interruptedactions...
> >  Faileving bug reports... 0%^C
> > Error retrieving bug reports from the server with the following error 
> > message:
> > E: exit
> > It could be because your network is down, or because of broken proxy 
> > servers, or the BTS server itself is down. Check network configuration and 
> > try again
> > Retry downloading bug information? [Y/n] 
> > root@zira:/home/vinc17# E: Input/output error @ io_fillbuf - fd:0 
> 
> This is even more awkward: I tried to understand where this error is
> coming from, but I haven't yet succeeded.

Both the interactive shell and apt-listbugs are attached to the
terminal and try to read from it. So, awkward things can occur.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-07-28 Thread Francesco Poli 
On Wed, 27 Jul 2016 12:41:24 +0200 Vincent Lefevre wrote:

> Package: apt-listbugs
> Version: 0.1.18
> Severity: normal

Hello Vincent and thanks for your bug report!

> 
> When I run aptitude, start an upgrade, then hit Ctrl-C just after
> apt-listbugs is started, I get:
> 
> root@zira:/home/vinc17# aptitude
> Interruptedactions...
>  Faileving bug reports... 0%^C
> Error retrieving bug reports from the server with the following error message:
> E: exit
> It could be because your network is down, or because of broken proxy servers, 
> or the BTS server itself is down. Check network configuration and try again
> Retry downloading bug information? [Y/n] 
> root@zira:/home/vinc17# 

This was somewhat intended: hitting [Ctrl-C] was supposed to interrupt
the bug report retrieval, while giving the user a chance to decide what
to do (retry and/or aborting and/or going on with the
installation/upgrade)...

> 
> but apt-listbugs is still running and attached to the terminal:
> 
> UIDPID  PPID  C STIME TTY  TIME CMD
> root   702   701  1 12:36 pts/600:00:00 /usr/bin/ruby 
> /usr/sbin/apt-listbugs apt

... this is instead unexpected!
I managed to reproduce the misbehavior, but I have no idea why it
happens.   :-(

The shell prompt should not reappear, while apt-listbugs is still
running!

> 
> Now, if I type Return, it is grabbed by apt-listbugs though I have
> my shell prompt, and I get an additional error message:
> 
> root@zira:/home/vinc17# aptitude
> Interruptedactions...
>  Faileving bug reports... 0%^C
> Error retrieving bug reports from the server with the following error message:
> E: exit
> It could be because your network is down, or because of broken proxy servers, 
> or the BTS server itself is down. Check network configuration and try again
> Retry downloading bug information? [Y/n] 
> root@zira:/home/vinc17# E: Input/output error @ io_fillbuf - fd:0 
> 

This is even more awkward: I tried to understand where this error is
coming from, but I haven't yet succeeded.


Anyway, I am considering the possibility to change the "exit 130"
statement into "exit! 130" at /usr/bin/apt-listbugs:325

That way, a [Ctrl+C] would make apt-listbugs exit (unsuccessfully)
immediately, without asking the user what to do.
But, at least, it seems that it would not trigger the strange behavior
you experienced.

I'll let you know, as soon as I make up my mind.
Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpG8YNN7TJdv.pgp
Description: PGP signature

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-07-27 Thread Vincent Lefevre 
Package: apt-listbugs
Version: 0.1.18
Severity: normal

When I run aptitude, start an upgrade, then hit Ctrl-C just after
apt-listbugs is started, I get:

root@zira:/home/vinc17# aptitude
Interruptedactions...
 Faileving bug reports... 0%^C
Error retrieving bug reports from the server with the following error message:
E: exit
It could be because your network is down, or because of broken proxy servers, 
or the BTS server itself is down. Check network configuration and try again
Retry downloading bug information? [Y/n] 
root@zira:/home/vinc17# 

but apt-listbugs is still running and attached to the terminal:

UIDPID  PPID  C STIME TTY  TIME CMD
root   702   701  1 12:36 pts/600:00:00 /usr/bin/ruby 
/usr/sbin/apt-listbugs apt

Now, if I type Return, it is grabbed by apt-listbugs though I have
my shell prompt, and I get an additional error message:

root@zira:/home/vinc17# aptitude
Interruptedactions...
 Faileving bug reports... 0%^C
Error retrieving bug reports from the server with the following error message:
E: exit
It could be because your network is down, or because of broken proxy servers, 
or the BTS server itself is down. Check network configuration and try again
Retry downloading bug information? [Y/n] 
root@zira:/home/vinc17# E: Input/output error @ io_fillbuf - fd:0 

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt-listbugs depends on:
ii  apt 1.3~pre2
ii  ruby1:2.3.0+4
ii  ruby-debian 0.3.9+b6
ii  ruby-gettext3.1.7-1
ii  ruby-soap4r 2.0.5-3
ii  ruby-unicode0.4.4-2+b7
ii  ruby-xmlparser  0.7.3-3

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.7.1-1

Versions of packages apt-listbugs suggests:
ii  debianutils 4.8
ii  firefox [www-browser]   47.0.1-1
ii  firefox-esr [www-browser]   45.2.0esr-1
ii  lynx [www-browser]  2.8.9dev9-1
ii  opera-stable [www-browser]  38.0.2220.41
ii  reportbug   6.6.6
ii  w3m [www-browser]   0.5.3-29

-- Configuration Files:
/etc/apt/apt.conf.d/10apt-listbugs changed:
// Before installing packages, check whether they have release-critical
// or security bugs.
DPkg::Pre-Install-Pkgs
{
  "/usr/sbin/apt-listbugs apt";
  "/usr/sbin/apt-listbugs apt -T security -s all";
};
DPkg::Tools::Options::/usr/sbin/apt-listbugs "";
DPkg::Tools::Options::/usr/sbin/apt-listbugs::Version "3";
DPkg::Tools::Options::/usr/sbin/apt-listbugs::InfoFD "20";
AptListbugs::Severities "critical,grave,serious";
AptListbugs::IgnoreRegexp "FTBFS";
// $Id: 10apt-listbugs 63984 2013-10-06 15:39:15Z vinc17/xvii $


-- no debconf information