but this path exist and owned by user (with -rwxrwxr-x rights for pkcs11 file, and drwx------ for the folder). The files: control, gpg, pkcs11 & ssh are all 0 bit long.
So i'm wondering about a timing race.

svn also affected:
karp@karp:~/tmp/prj$ svn up
p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory
after upgrade from 11.10 to 12.04

Your diff for raring doesn't appear to add gnome-keyring-bin as a dependency fo gnome-keyring. I'd add this myself, but there may be a better way to go about this, and you would need to make the same change for precise and quantal as well.

Unsubscribing ubuntu-sponsors for now, please re-subscribe when this is fixed up.

I don't think the two proposed debdiffs here are correct for implementing multi-arch for gnome-keyring. While the plug-ins for gnome-keyring itself, and the pam module, could be built as multi-arch, it isn't necessary to do so. In fact, building the gnome-keyring plug-ins (currently in usr/lib/gnome-keyring/devel/*.so) into a Multi-Arch: same package, will result in a broken install if the :i386 package is installed on an x86_64 system, for example, as the gnome-keyring binary package is marked as foreign. Also, there are many non-arch-dependent files left in the gnome-keyring package, which are not installed in arch-dependent directories, resulting in file conflicts between the i386 and x86_64 versions of the package.

This is a better patch to add multi-arch support for gnome-keyring. It moves the p11-kit module to a new package, moves the pam module to multi-arch, and correctly marks the gnome-keyring package as multi-arch foreign, as it includes the main binary, and data files.

Andreas, that seems like it should be a separate patch, and something that should go upstream in GNOME (and possibly is already fixed there), while this multiarch patch currently only affects the packaging.

The quantal debdiff you posted is against an older version as well, as is the precise version. Also, if the proposed debdiffs were pushed out as updates on those platforms, it would break upgrades to the newer Ubuntu versions, as the changes are incompatible.

On 04/08/2013 11:02 AM, Rodney Dawes wrote:
> The quantal debdiff you posted is against an older version as well,
> as is the precise version. Also, if the proposed debdiffs were
> pushed out as updates on those platforms, it would break upgrades
> to the newer Ubuntu versions, as the changes are incompatible.
>
Ok ill fix it, Thanks!

Looks like you are pulling the gnome-keyring from the release pocket, and not from -proposed, as should be. So you now just applied my changes to the release packages, rather than the updated versions that were released on Quantal/Precise. See the Quantal backport patch I attached for the appropriate changes to the latest version on Quantal.

I'm unsure if an updated package has been released for Ubuntu 12.04 (Precise Pangolin) yet but the currently available version of gnome-keyring:i386 is not installable due to libgcr-3-common not being multiarch (bug #998715).

You wouldn't be able to install gnome-keyring:i386 on x86_64 with these changes in raring either even, without replacing a very large portion of the system with the 32-bit packages. Nor do I see any reason why one would ever want to, either. There's no reason do that.

@Martin, Quantal is still supported for almost a full 12 months more. Is it really out of scope to push SRUs to it after only 6 months in? If this were Raring, and there were only a couple months left of support, then I would agree it might be out of scope to push such a change. But given the work here is done, I don't see a good reason to not push it, unless something is actually broken, which I doubt, given the same changes are included in Raring already, and it works fine there. :)

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

# sudo apt-get install gnome-keyring:i386/precise-proposed
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '3.2.2-2ubuntu4.2' (Ubuntu:12.04/precise-proposed [i386]) for 'gnome-keyring:i386'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
gnome-keyring:i386 : Depends: libcap-ng0:i386 but it is not going to be installed Depends: libgck-1-0:i386 (>= 2.91.1) but it is not going to be installed Depends: libgcr-3-1:i386 (>= 3.2.2) but it is not going to be installed Depends: libcap2-bin:i386 but it is not going to be installed Recommends: libp11-kit-gnome-keyring:i386 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Looks like sid has quite a bit of changes to gnome-keyring compared with what's in precise, but multiarch is not one of them. However, the wine version in sid does not seem to suffer this problem with the library. 'wine notepad' only gives me an error in precise, but not in sid. sid has wine 1.4.1.

Yes, I did. But I don't see why gnome-keyring is marked as Multi-Arch:
foreign and libpam-gnome-keyring is converted to Mutli-Arch: same. As
I see it, it is sufficient to make 'libp11-kit-gnome-keyring' as
Multi-Arch: same and be done with it. To resolve the warning from wine
you would have to explicitly install the new libp11-kit package for
i386. I hope I'll get around to posting a working patch for 12.04
later today.

BTW, how is the new libp11-kit-gnome-keyring supposed to find it's way
to the affected users? Will wine declare a dependency on
libp11-kit-gnome-keyring:i386 or something?

On Mon, Jun 24, 2013 at 2:14 AM, Rodney Dawes <email address hidden> wrote:
> @eraserix have you looked at the diff? That's exactly what is done in
> 13.04, and what the diff is meant to backport to the older releases..
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/859600
>
> Title:
> Please convert gnome-keyring to multiarch
>
> Status in “gnome-keyring” package in Ubuntu:
> Fix Released
> Status in “gnome-keyring” source package in Precise:
> In Progress
> Status in “gnome-keyring” source package in Quantal:
> Won't Fix
> Status in “gnome-keyring” source package in Raring:
> Fix Released
> Status in “gnome-keyring” package in Debian:
> New
>
> Bug description:
> [Impact]
> Several applications are relying on this package as seen in comments 5 and 6.
>
> [Test case]
> Attempt to install both i386/amd64 versions and preferably verify if the reported applications in this bug are able to run successfully
>
> [Regression Potential]
> Minimal, several rdepends build testing have been completed successfully and nothing in the keyring code is attempting to dlopen any hardcoded library paths.
>
> gnome-keyring is still installing libraries to /usr/lib instead of the
> multarch compatible /usr/lib/$(DEB_HOST_MULTIARCH) directory. The
> attached patch does the conversion.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/859600/+subscriptions

So, my take ;). This patch just splits the pkcs11 library away from gnome-keyring binary package and leaves the rest of the packages alone.

I still don't see the use case for doing more, the warning when wine is started will be gone with this patch. And as far as I can tell, libgcr is still not multiarch on raring.

For the testcase, I'd say this should be something like that:
[Test case]
(on an amd64 system)
1. Run the command 'wine notepad'. Notice the warning from p11-kit.
2. sudo apt-get install libp11-kit-gnome-keyring:i386
3. Run the command 'wine notepad' again. Notice that the warning is gone.

It is adam-stokes' last attempt plus the following changes:
- Change gnome-keyring's Recommends on libp11-kit-gnome-keyring
to Depends.
- Change libp11-kit-gnome-keyring's Breaks and Replaces on
gnome-keyring to (<< ${binary:Version}).

@eraserix: I agree that installing libp11-kit-gnome-keyring:i386 is correct for the test case, not gnome-keyring:i386 as it contains the executables and is not co-installable.

I've updated the description with more specific instructions on how to test this SRU.

As for Depends vs Recommends from debian policy manual:
The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality.

The Recommends field should list packages that would be found together with this one in all but unusual installations.

I'm kind of inclined to stay with recommends. I can still store passwords in the keyring without the pkcs11 library, no?

@graham: Thanks for the info about how the new multiarched package finds its way to the users.

For the gnome-keyring package to be considered multi-arch in Precise, surely libgck and libgcr need to be multi-arch as well?
Then we can close LP: #998715 for Precise in this SRU.

My other concern is what will happen when someone picks up libp11-kit-gnome-keyring in Precise and then upgrades to Quantal?
Quantal's gnome-keyring will overwrite libp11-kit-gnome-keyring because its Breaks and Replaces are on a lower version of gnome-keyring. If this gets SRU'd for Precise, surely it must get SRU'd for Quantal as well?

OK. Everyone, just relax. First of all, this bug is not for the p11kit issue. That bug is #1094319 as clearly mentioned in the changelog entry. This bug is specifically about enabling Multi-Arch for the gnome-keyring source package, so that some of its binaries may be co-installable as needed. While I had fixed both bugs at the same time in Raring, they are not the same issue.

And on top of that, the gcr source package being converted to Multi-Arch is another separate issue. Please do not conflate them all into being the same bug. They are separate issues, even if they have dependencies on one another.

The update issue is another issue on top of those, which will also need to be carefully considered, and which means all of these fixes will need to be SRUed into Quantal first, indeed. Or we simply maintain the status quo in Precise and Quantal for these 3 issues, as it is a non-fatal issue, and only a slight annoyance, only when using certain software which requires use of 32-bit pieces while running on 64-bit. I see no good reason to force N complex updates upon the user base, to fix a very minor annoyance (which isn't this bug anyway).

I've built another gnome-keyring package for Precise in my PPA that I hope fixes all three issues (multi-arch gnome-keyring, multi-arch gcr and split libp11-kit-gnome-keyring).

The test case (on an x86_64 system) would be something like:

$ wine notepad
You should see the error message:
p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory

@graham: I think the usual way to do this is that you crate a debdiff to the current version in precise. Attach it to this bugreport and subscribe ubuntu-sponsors when done. Name/Version of the patch should be something like that:

This is Rodney's Quantal patch from comment #41 with the following changes:
The gnome-keyring package depends on libp11-kit-gnome-keyring instead of recommends.
The libp11-kit-gnome-keyring package now breaks and replaces gnome-keying (<< ${binary:Version}).

I believe this needs to be fixed in Quantal before it can be fixed in Precise so that the upgrade path is not broken.

OK, quick update on status for Quantal and Precise. The Quantal patch was never uploaded to the archive. The Precise patch was uploaded by xnox, but was rejected because of the ${binary:Version} issue below.

I've just uploaded a modified patch from comment 75 to Quantal only. I'd like to get Quantal landed before doing Precise, because as people have mentioned, the upgrade path gets complicated otherwise.

Here are the changes I made to Graham's Quantal patch:
- You shouldn't specify Breaks or Replaces lines with automatically generated versions like ${binary:Version}. This means that every time the package is built, it will say it breaks previous versions. Instead, just hardcode the version that you put in debian/changelog.
- When using DEB_HOST_MULTIARCH, please also make sure to manually set it [1] as recommended in the multiarch conversion doc [2]. This is because while normally the buildd will set it for us, it's not a requirement. For example, when dep8 tests rebuild the source, the variable is not set for us. Not likely an issue in practice , but still good to do.
- No need for quantal-proposed in the changelog entry. You can just say quantal now and LP will do the right thing. Minor point, but just saying.
- No need to manually add multiarch-support to the Pre-Depends line. It comes in via the ${misc:Pre-Depends} bit. Again, minor point.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

I can update my patch for precise, but as it stands, it also converts gcr, which was split out of gnome-keyring into its own package in quantal, to multiarch.
Before we can convert gnome-keyring (including gcr) to multiarch in precise, we would first need to convert gcr to multiarch in raring and quantal, see LP: #998715.

The verification of the Stable Release Update for gnome-keyring has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Is it really still important to be able to upgrade from 12.04 to 12.10? 12.04 is supported for 3 more years, 12.10 for something like a month. Once 14.04 is out, you will be able to upgrade from 12.04 directly.