Canceling an installation in Software Center crashes debconf with "Use of uninitialized value $reply in scalar chomp at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66,"

Thanks for your report.

Which package manager were you using ?

@pierre, Why did you set the status to confirmed ? Do you known a reliable way to reproduce this issue ?

Jean-Baptiste Lallement: I am using Synaptic at Ubuntu 9.10 Karmic - full updated.

@jader_nomak: Do you get the error in the description ? Is so could you please provide the detailed steps to reproduce it. Thanks in advance.

Jean-Baptiste, I was using the Ubuntu Software Center.

Thanks for the update. Confirmed in Lucid.

similar issue in bug 442941 but somewhat different conditions: mainly affects tzdata and users doesn't cancel anything.

Sres: Me falta software y actualizaciones, de lo contrario des instalare el sistema ubuntu
si no tiene solución a mi pedido.! Con limitaciones no se puede operar con un sistema
incompleto, espero una respuesta por MAIL- MUCHAS GRACIAS.>

So, I can't reproduce this *directly* on Oneiric, and I don't have a Lucid test environment right now. However, I emphasise "directly": with some fiddling, I can indirectly see what's probably going on here, even though the precise circumstances have changed in Oneiric. If I comment out the bits from debconf's Gnome frontend that hide the cancel button to try to reduce the incidence of this kind of problem, and then attach 'strace -f' to aptdaemon while installing acroread from software-center, I can see the Passthrough frontend failing with similar warning messages, and eventually being killed by SIGPIPE.

What's happening here is that the UI agent (in my case, the Gnome frontend) exits on being cancelled, and therefore stops responding to messages from the Passthrough frontend. The latter first tries to read, gets end-of-file (rendered in Perl as the <> operator returning undef), fails to handle that specifically, and throws a bunch of uninitialised-value warnings. When it next tries to write to the UI agent, it gets SIGPIPE as one might expect because all the readers have gone away.

Oneiric (and I suspect also Natty; acroread isn't yet in the Oneiric partner repository, but my test system has the Natty partner repository in sources.list) avoids this problem because acroread 9.4.2-0natty1 changed from asking questions directly in the postinst to asking them in a separate config script. Asking questions in config rather than postinst is good practice anyway and there's no reason why it shouldn't have been done in previous releases too. However, there are still situations where there is no alternative to asking a question directly in the postinst, and so we do still need to do something about this.

It's not clear to me how people are seeing the cancel button in Karmic or Lucid, since the change to suppress that in debconf's Gnome frontend was made in the Intrepid cycle. What does the dialog with the cancel button look like (perhaps a screenshot)?

As to what we can do about this bug report: it's not entirely obvious. We can certainly suppress the uninitialised-value warnings by handling end-of-file and SIGPIPE-on-write explicitly. We can try to reduce the incidence of cancellations, or make it more obvious that they constitute cancelling installation of a package and confirm that with the user (see Joey's comment in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501767), but that doesn't deal with the question of what the Passthrough frontend should actually *do* when its UI agent goes away unexpectedly. It doesn't have the ability to restart it, because it's running in some completely different context (different filesystem namespace, perhaps even a different machine, etc.) that Passthrough isn't allowed to know about. It can't itself display any UI because Passthrough isn't an X-based frontend, and is just there for shovelling data around. The only choices I can see are:

 * Exit non-zero (which would show up as a "crash" in much the same way, though perhaps we could handle it more gracefully, and improved cancellation handling in UI agents would certainly help);
 * Continue in noninteractive mode. On the one hand, this cor...

I'm downgrading this because the rewrite of the debconf GUI for error-tracking purposes <https://wiki.ubuntu.com/ErrorTracker#debconf> makes it even less likely that people will come across an errant "Cancel" button.

It looks like we also need updated steps to reproduce the problem.

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

Unsure why that was added to the artful list, software-center is not used there and gnome-software is using packagkit and not aptdaemon now, setting as notfixing for this cycle