This has been fixed in Precise (if not earlier): libsane depends on libsane-common, which now provides html/sane-mfgs.html.
jani@saegusa:~$ dlocate sane-mfgs.html
libsane-common: /usr/share/doc/libsane/html/sane-mfgs.html
jani@saegusa:~$ LC_ALL=C apt-cache depends libsane | grep libsane
libsane
Depends: libsane-common
libsane-common:i386
Suggests: libsane-extras
Replaces: libsane-extras
Replaces: libsane-extras:i386
Replaces: libsane:i386
Breaks: libsane:i386
The two dialogs are very, very inconsistent: the dialog icon they use (DIALOG_QUESTION in one, the DIALOG_ERROR in the other), the dialog window title (”Application problem” vs. none), the dialog title and explanation style (brief vs. verbose), the ignore option missing from one… It’s almost as if the engineers behind the two dialogs have intentionally tried to make them as different from one another as possible. (No offence intended, I just think it’s funny although it is a genuine accessibility problem as well.) Also, one dialog seems to be minimizable whereas the other is not — though this doesn’t appear in Blair’s screenshot; it may be something introduced in Precise which the system my screenshot is from is running.
Jason: As with Davide, it was indicator-power that was missing here. The greeter log didn’t show that though, it claimed libdatetime.so was missing even though indicator-datetime is in fact installed.
Emanuele: You’ll need to go through some hoops via the Overview page linked to on top of this report, until you get to https://launchpad.net/ubuntu/precise/+source/unity-greeter/0.2.0-0ubuntu4 where you need to pick the build for your architecture. Use dpkg –install to install the .deb file. Good luck!
After yesterday’s upgrades including libindicator7, unity-greeter crashes repeatedly until failsafe kicks in, and even then, after selecting low graphics mode for the session, it crashes. I managed to get X working again by downgrading unity-greeter back to 0.2.0-0ubuntu4 which I’m filing this report with. The crashing update was version 0.2.0-0ubuntu5.
I’m attaching the crash file.
It seems I’m not able to reproduce this on my other computer (also running up-to-date Precise), so I’ll look for differences in the setups.
Upgrade from 0.7~alpha5.1ubuntu6 to 0.7~beta2ubuntu1 brought this on: on every boot the ”Waiting for network configuration” and ”Waiting up to 60 seconds more for network” messages appear and boot is thus about 2 minutes slower than before. It also says it’s booting without network, but the network is in fact there after I log in.
Downgrading back to 0.7~alpha5.1ubuntu6 makes the wait go away again.
Reproduced this on three different computers on two different networks, both wired and wireless.
I’ve reproduced this on three separate computers, each running Precise.
Steps to reproduce:
1. Start Software Center.
2. From the File menu, choose Sync Between Computers…
3. From the registration window, choose to login to you existing account. Enter your credentials and continue forward.
What happens:
In addition to the window saying you’re now signed in, you also get the registration window. Sync is not available in the main window.
What I expect to happen:
To have only the successful sign-in window appear (i.e. not the registration window again) and have sync working in the main window.
Workaround:
Start the Sync procedure again. Repeat steps 1.-3. above. This time it works as I expect it to: the registration window doesn’t re-appear after entering my credentials, and I get the sync view in the main window.
@Roger: Thanks for the solution. On Ubuntu Precise, GMM 1.0.23.1334-r0 seems to use /usr/local/share/applications instead of /usr/share/applications for the desktop file (there’s also a copy in /opt/google/musicmanager/, but it’s apparently just used for installing the effective file into /usr/local/).
@Nuno: I’m not sure I see the point of encrypting the application-specific password, and then be prompted to enter the key for decrypting the password. Isn’t it more straightforward to just specify the application-specific password when GMM prompts you to? Actually, with the caveat that specifying the password on the commandline means exposing it to trusted users, isn’t having GMM prompt for it a *better* solution securitywise? I guess you do get the benefit of getting to specify your own password which can be as easily memorizable as you dare use though (the application-specific passwords are difficult). Instead of OpenSSL I’d probably use GNOME Keyring, as it gets unlocked during login without an extra prompt for another password. Then pick the key for GMM using gkeyring.
I should note that currently I’m unable to bring up X entirely with the intel driver. Too bad I didn’t make a note of which upgrade this started with. With intel it now just freezes when login screen should appear, with just the cursor showing on a purple background. It’s such a tough lockup that REISUB from the keyboard won’t work, I have to power off to reset. Comparing logs might help determine if it’s the same issue on a grand scale or an unrelated one, but I don’t know how (or if) I can get useful logs from such lockups.
I downgraded libdrm-intel1 to 2.4.26-1ubuntu1 from Oneiric, but the problem remains. So on Precise it doesn’t seem to be the cause. (I’m not using the Xorg-edgers PPA.)
