Xscreensaver will not unlock during upgrade

This bug is resolved in the latest Debian version of pam, 1.0.1-5, which has been merged into jaunty as pam 1.0.1-5ubuntu1. Changelog:

pam (1.0.1-5) unstable; urgency=low

  * Build-conflict with libxcrypt-dev, which otherwise pulls libxcrypt in as
    a dependency of libpam-modules if it's installed during the build.
    Thanks to Larry Doolittle for catching.
  * Don't refer to gnome-screensaver in the debconf template; it isn't
    actually affected by the libpam symbol issue because it forks a separate
    process to display the screensaver dialog.
  * Have libpam-modules Pre-Depend on ${misc:Depends}, so that we can
    warn users about needing to disable xscreensaver and xlockmore
    before libpam-modules is unpacked. Closes: #502140, LP: #256238.
  * Updated debconf translations for the new template:
    - Italian, thanks to David Paleino <email address hidden>
    - Simplified Chinese, thanks to Deng Xiyue
      <email address hidden> (closes: #510371)
    - Portuguese, thanks to Am<C3><A9>rico Monteiro <email address hidden>
    - Swedish, thanks to Martin Bagge <email address hidden> (closes: #510379)
    - Japanese, thanks to Kenshi Muto <email address hidden> (closes: #510380)
    - Finnish, thanks to Esko Araj<C3><A4>rvi <email address hidden> (closes: #510382)
    - Spanish, thanks to Javier Fernandez-Sanguino Pe<C3><B1>a <email address hidden>
      (closes: #510389)
    - Galician, thanks to Marce Villarino <email address hidden>
    - Slovak, thanks to helix84 <email address hidden> (closes: #510412)
    - Bulgarian, thanks to Damyan Ivanov <email address hidden>
    - Czech, thanks to Miroslav Kure <<email address hidden>
      (closes: #510608)
    - French, thanks to Steve Petruzzello <email address hidden>
    - German, thanks to Sven Joachim <email address hidden> (closes: #510617)
    - Basque, thanks to Piarres Beobide <email address hidden>
      (closes: #510699)
    - Russian, thanks to Yuri Kozlov <email address hidden> (closes: #510701)
    - Turkish, thanks to Mert Dirik <email address hidden> (closes: #510707)

To be clear, this doesn't fix the issue when upgrading from hardy to intrepid, which is still affected; it only provides the infrastructure for handling this case in future upgrades.

I'm not sure that, this far into the intrepid support cycle, it's justified to make this intrusive of a change via SRU for a one-time upgrade bug that most users will have already dealt with.

On Thu, Jan 8, 2009 at 2:05 PM, Steve Langasek
<email address hidden> wrote:
> To be clear, this doesn't fix the issue when upgrading from hardy to
> intrepid, which is still affected; it only provides the infrastructure
> for handling this case in future upgrades.

Makes sense.

> I'm not sure that, this far into the intrepid support cycle, it's
> justified to make this intrusive of a change via SRU for a one-time
> upgrade bug that most users will have already dealt with.

I agree. As long as it doesn't crop up again moving forward, problem
solved. :-)

-Greg
--
Greg Lund-Chaix
OSU Open Source Lab
<email address hidden> ~ (971) 533-7742

I know I'm commenting on a closed bug here, but comment #2 worries me:

> I'm not sure that, this far into the intrepid support cycle, it's justified to make this intrusive of a
> change via SRU for a one-time upgrade bug that most users will have already dealt with.

Since 8.04 / Hardy is an LTS, many people continue to run it and haven't yet upgraded, precisely because it is an LTS. I know I do.
That beign said, I'm not arguing that this has to be fixed if the likihood of running into this is deemed low enough, or if there are other reasons for not fixing it. But I am saying that the above in comment #2 does not strike me as a good justification for not fixing it.

The users who are still running hardy are almost certainly going to upgrade to the next LTS release, not to intrepid. The bug is only present if you upgrade to intrepid.