Broken (or missing) multiarch support

Status changed to 'Confirmed' because the bug affects multiple users.

I've had a go at a simple conversion based on: http://wiki.debian.org/Multiarch/Implementation - I'm no packaging or multi-arch expert, but I'm learning enough to be dangerous. Please have a look at let me know where it could be improved.

It's was a little more complex than a simple conversion:
* Had to push out the Xsession file to two separate packages (appmenu-gtk-common, appmenu-gtk3-common) and mark Multi-arch: foreign; as this file would conflict if you had both i386 and x86_64 packages installed
* Removed the if statement around the export entry in Xsession file as I don't think this is required(?), if the package is installed, the module should exist - or was this a safety thing? Having the module path means this would be harder to split into -common packages and/or require you to have one per architecture with a different name
* moved debian/appmenu-gtk3.install and debian/appmenu-gtk.install to .in files and manipulate them in debian/rules as they contain arch specific paths that do not get auto generated the way I've seen in other packages with /*/

I'm going to be testing this out, it's currently building in my test ppa: https://launchpad.net/~tellis/+archive/multiarch

Feedback warmly welcome!

Submitted a clean merge proposal, appears my last branch had other files that were modified from a failed build of the package.

ok, 3rd time lucky... this time just a debdiff as my bzr foo is failing.

Same comments as before stand, this is an attempt at multi-arching the package. I'm not 100% confident on some of the changes so it needs a thorough review.

The attachment "appmenu-gtk_0.3.92-0ubuntu2.debdiff" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

--- appmenu-gtk-0.3.92.orig/80appmenu.in
+++ appmenu-gtk-0.3.92/80appmenu.in
@@ -1,4 +1 @@
-if [ -f @moduledir@/libappmenu.so ]
-then
- export UBUNTU_MENUPROXY="libappmenu.so"
-fi
+export UBUNTU_MENUPROXY="libappmenu.so"

This is a deliberate check, to ensure that UBUNTU_MENUPROXY isn't set when appmenu-gtk is removed but not purged (since /etc/X11/Xsession.d/80appmenu will then exist on the system, but libappmenu.so will not). Is this a safe change to make? UBUNTU_MENUPROXY is read by gtk, and I'm not sure what gtk does if the variable is set but pointing at a non-existent .so.

Ok, I checked the menuproxy patches in gtk; if the specified module is not found, the application will run, but it will spew a lot of warning messages to stderr. So we should probably find a better solution for that instead of unconditionally setting the variable.

--- appmenu-gtk-0.3.92.orig/debian/appmenu-gtk.install.in
+++ appmenu-gtk-0.3.92/debian/appmenu-gtk.install.in
@@ -0,0 +1 @@
+debian/tmp/gtk2/usr/lib/${DEB_HOST_MULTIARCH}/* /usr/lib/${DEB_HOST_MULTIARCH}/

Unnecessary; with the correct debhelper level, you can write this as:

  debian/tmp/gtk2/usr/lib/

... and all of the contents will be installed to the correct directory. (Or if necessary: debian/tmp/gtk2/usr/lib/* /usr/lib)

> * Add common packages for xsession file

We don't need to create a new package for the file given that it's identical across architectures. Though we do still have to work out a way to get it identical across architectures which doesn't result in the regression mentioned above.

Same warnings running Lotus Notes 8.5.3

Same warnings running FPP0.18Linux (www.flightplanpro.eu)

this bug affect skype too

rdeps testing on quantal

./indicator-appmenu_12.10.0-0ubuntu1_amd64.build:Status: successful

Updated patch to remove unecessary packaging for xsession and to confirm that @moduledir@ is updated to its respective arch location during builds.

Adam,

> Updated patch to remove unecessary packaging for xsession
> and to confirm that @moduledir@ is updated to its respective
> arch location during builds.

This wasn't unnecessary. Without this change, the resulting appmenu-gtk package is not multiarch-coinstallable, because each package will contain an /etc/X11/Xsession.d/80appmenu with different contents (because of the embedded arch string). So the latest patch is definitely incorrect, you won't be able to coinstall amd64 and i386 versions of appmenu-gtk.

The reason for the file check is, ostensibly, to make sure we don't try to set $UBUNTU_MENUPROXY when the appmenu-gtk package has been removed but not purged; since /etc/X11/Xsession.d/80appmenu is a config file, it's left on the filesystem when the package is in that state, so you want to check that the package is really installed before setting this variable that's going to spew warnings if it's wrong.

Since there's no filesystem check we can do to verify the package's status which isn't either a) architecture-dependent or b) dependent on /usr/share/doc (which sometimes gets purged), I think it's best to ask dpkg directly:

if dpkg-query --showformat '${Status}' -W appmenu-gtk | grep -q 'install ok installed'
then
  export UBUNTU_MENUPROXY=libappmenu.so
fi

Can you try changing 80appmenu.in to use this approach, and test that it works (including when amd64 and i386 versions are co-installed)? You'd do that by logging out and logging back in, and verifying that your menus are all still up in the top bar where you expect them.

Tested with both packages installed:

ii appmenu-gtk:amd64 12.10.1-0ubuntu1.1 amd64 Export GTK menus over DBus
ii appmenu-gtk:i386 12.10.1-0ubuntu1.1 i386 Export GTK menus over DBus

And verified menu's do exist with appmenu co-installed

Dropping upstream task as this looks like it'll require dpkg and should be in the debian packaging not upstream.

The latest patch looks good, except I just noticed that the 'appmenu-gtk' check is being applied literally in both the appmenu-gtk and appmenu-gtk3 packages. :/ It needs to check the corresponding package name in each case; otherwise it gives wrong behavior if appmenu-gtk is not installed and appmenu-gtk3 is, a potentially increasingly common situation as we have fewer and fewer gtk2 apps around.

Ah, ok I'll fix that and re-upload the debdiff.

Thanks!

Unsubscribing ubuntu-sponsors for now. Please feel free to resubscribe when there is something to sponsor.

Taking a look

First, there are the missing debhelper and cdbs build dependency bumps per http://wiki.debian.org/Multiarch/Implementation#cdbs_with_autotools_and_debhelper
Next, the appmenu hack is problematic. Right now, the .in file is converted into 2 files, 80appmenu and 80appmenu-gtk3 and each one installed. If you're going to make it use just one, then, which package does it go in. Also, the check doesn't help for the foreign arch check at all, it only checks the native arch. Unsubscribing sponsors for the moment, please resubscribe when these issues have been addressed.
Also, appmenu-gtk is maintained in an Ubuntu Desktop VCS branch. 'debcheckout appemnu-gtk' should get that for you if you'd like to commit the changes 1 by 1

> If you're going to make it use just one, then, which package does it go in.

The same file goes in both packages. This is the simplest change; since both packages were exporting the same shared variable anyway, it doesn't matter that the same script will be run twice.

> Also, the check doesn't help for the foreign arch check at all, it only checks the native
> arch.

This doesn't matter. We have only one environment variable we're setting, so if we have any instances of the package installed we should set it.

$ dpkg-query --showformat '${Status}' -W libc6
install ok installeddeinstall ok config-filesinstall ok installed
$

this query does what we want in a multiarch context.

> First, there are the missing debhelper and cdbs build dependency bumps per
> http://wiki.debian.org/Multiarch/Implementation#cdbs_with_autotools_and_debhelper

Strictly correct, but not a huge deal if we don't because those versioned build-dependencies will obviously be satisfied in the release this is being uploaded to. Adam, do you want to bump the build-dep versions and push new patches?

Sure thing I'll do that today.

Thanks
Adam

Changes made based on comments 28 and 29.

Thanks
Adam

Steve, thanks for the feedback.
Uploaded, waiting in queue

(unsubscribing sponsors since that's uploaded)

Precise uploaded and waiting in queue as well

Hello Benjamin, or anyone else affected,

Accepted appmenu-gtk into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/appmenu-gtk/12.10.2-0ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

I have tested appmenu-gtk from quantal-proposed. I can install the i386 and amd64 version in parallel and running the i386 libreoffice do not expose the wrong ELF class error message.

Upon closer inspection, I see that the version of appmenu-gtk in -proposed uses the dpkg-query logic that was rejected by the SRU team in discussion on IRC. So, pulling this package out of -proposed altogether - this needs a reupload with the reworked shell logic, so that it doesn't impact boot speed.

Latest revisions report this during testing:

zef@quantal:~$ dpkg -l |grep appmenu-gtk
ii appmenu-gtk:amd64 12.10.2-0ubuntu1.1 amd64 Export GTK menus over DBus
ii appmenu-gtk:i386 12.10.2-0ubuntu1.1 i386 Export GTK menus over DBus
ii appmenu-gtk3:amd64 12.10.2-0ubuntu1.1 amd64 Export GTK menus over DBus
ii appmenu-gtk3:i386 12.10.2-0ubuntu1.1 i386 Export GTK menus over DBus
zef@quantal:~$ cat /etc/X11/Xsession.d/80appmenu*
for i in /usr/lib/*/gtk-2.0/2.10.0/menuproxies/libappmenu.so
do
 if [ -f $i ]
 then
  export UBUNTU_MENUPROXY="libappmenu.so"
  break
 fi
done
for i in /usr/lib/*/gtk-3.0/3.0.0/menuproxies/libappmenu.so
do
 if [ -f $i ]
 then
  export UBUNTU_MENUPROXY="libappmenu.so"
  break
 fi
done
zef@quantal:~$ sh -x /etc/X11/Xsession.d/80appmenu
+ [ -f /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/menuproxies/libappmenu.so ]
+ export UBUNTU_MENUPROXY=libappmenu.so
+ break
zef@quantal:~$ sh -x /etc/X11/Xsession.d/80appmenu-gtk3
+ [ -f /usr/lib/i386-linux-gnu/gtk-3.0/3.0.0/menuproxies/libappmenu.so ]
+ export UBUNTU_MENUPROXY=libappmenu.so
+ break
zef@quantal:~$

I think a corner case may arise if a amd64 system requests use of that library but only the i386 version is installed, but, I think the risk of that happening is slim to none.

On Thu, Nov 08, 2012 at 10:49:20PM -0000, Adam Stokes wrote:
> I think a corner case may arise if a amd64 system requests use of that
> library but only the i386 version is installed, but, I think the risk of
> that happening is slim to none.

Yep, that's an understood corner case at any rate, and the intended behavior
is still to set the variable if the proxy module is installed for *any*
architecture. If the variable is set and you run a program for an
architecture that we don't have the menuproxy for, you get warnings on
stderr. If the variable isn't set and you run a program for an architecture
that we *do* have the menuproxy for, you get reduced functionality.

This bug was fixed in the package appmenu-gtk - 12.10.2-0ubuntu2

---------------
appmenu-gtk (12.10.2-0ubuntu2) raring-proposed; urgency=low

  * Add multiarch support (LP: #932860)
 -- Adam Stokes <email address hidden> Thu, 08 Nov 2012 16:43:07 -0500

Thanks for all your work on this, Adam. I've sponsored the uploads to quantal and raring (so far - precise is still pending), with a few minor changes:

 - the raring diff didn't include the debian/rules changes to install files to the multiarch directories. Easily fixed.
 - the version numbers needed to be adjusted for upload: -0ubuntu2 for raring, -0ubuntu1.2 for quantal (not -0ubuntu1.1, because that version was previously accepted as an SRU and then removed again from the archive).

The precise diff had the same bug as raring (missing --libdir tweak in debian/rules). I fixed that and sponsored it, so it's now pending SRU review. Thanks, and sorry for the delay!

Hello Benjamin, or anyone else affected,

Accepted appmenu-gtk into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/appmenu-gtk/0.3.92-0ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Benjamin, or anyone else affected,

Accepted appmenu-gtk into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/appmenu-gtk/12.10.2-0ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

JFYI, multiarch support is broken again in raring: bug #1084266

re #50 that should be fixed now.

Also I've tested on both Precise/Quantal and the packages are co-installable and appmenu activates properly in the applications tested (Nautilus, Firefox, Gnome-Terminal)

Thanks
Adam

The verification of this Stable Release Update 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.

This bug was fixed in the package appmenu-gtk - 0.3.92-0ubuntu1.1

---------------
appmenu-gtk (0.3.92-0ubuntu1.1) precise-proposed; urgency=low

  * Add multiarch support (LP: #932860)

  [ Mark Russell ]
  * Add "IBM Notes" to blacklist (LP: #1077095)
 -- Adam Stokes <email address hidden> Thu, 08 Nov 2012 17:59:03 -0500

This bug was fixed in the package appmenu-gtk - 12.10.2-0ubuntu1.2

---------------
appmenu-gtk (12.10.2-0ubuntu1.2) quantal-proposed; urgency=low

  * Add multiarch support (LP: #932860)
 -- Adam Stokes <email address hidden> Wed, 17 Oct 2012 11:27:20 -0400