From a clean install of Ubuntu Karmic (x86_64) (rather than in-place upgrade from Jaunty), and mounting the existing /home/ volume into it (so the user settings are all inherited) I've checked and this bug isn't affecting this PC.
The only difference I can see with regard to Compiz settings is I have custom settings (not 'Normal' or 'Extra'' visual effects) because I have the 3D cube configured on two X screens.
It looks as if the problem is in the source package generation and the patch itself.
The patch to fix this is "debian/patches/012_default_keybinding.patch" which patches "src/metacity.schemas.in" which is generated by automake (from "src/metacity.schemas.in.in"). These lead to 'make' creating "src/metacity.schemas".
However, when the package is built 'make' regenerates "src/metacity.schemas.in" thus wiping out the changes made by the patch:
So the obvious fix would be for the patch to be applied to "src/metacity.schemas.in.in".
However, looking at the contents of the patch it isn't clear to me *why* that should work since it affects the "/apps/metacity/window_keybindings/move_to_workspace_12" key, not "/apps/metacity/global_keybindings/switch_windows_backward".
Also, the patch is described as a fix for this bug in comment #15 and a changelog entry is shown there which is in the Hardy package changelog; however that entry *does not* appear in the current source package's changelog (or any since Hardy), instead the patch itself is referenced but no specific mention of this bug reference:
-- Pedro Fragoso <email address hidden> Tue, 03 Jun 2008 18:36:06 +0100
------
Inspecting the contents of the patches for Hardy (created my Michael) and the patch that is in Intrepid and later (from Pedro's changelog report) the difference is obvious - they are being applied to different key-bindings:
------
$ diff -Nu metacity-2.22.0/debian/patches/012_default_keybinding.patch metacity-2.28.0/debian/patches/012_default_keybinding.patch
...
+@@ -1348,7 +1348,7 @@
+ <applyto>/apps/metacity/window_keybindings/move_to_workspace_12</applyto> <owner>metacity</owner> <type>string</type>
- <default>disabled</default>
+ <default><Shift><Alt>Tab</default>
<locale name="C">
- <short>Move focus backwards between windows using popup display</short>
- <long>
+ <short>Move window to workspace 12</short>
+ <long>The format looks like "<Control>a" or "<Shift><Alt>F1".
------
So the issue seems to be twofold:
1. The patches are inconsistent, conflicting, or accidentally misformed during a source package refresh
2. The patch should apply to "metacity.schemas.in.in" if the package-build is going to cause "metacity.schemas.in" to be regenerated after source package patching has been applied.
From a clean install of Ubuntu Karmic (x86_64) (rather than in-place upgrade from Jaunty), and mounting the existing /home/ volume into it (so the user settings are all inherited) I've checked and this bug isn't affecting this PC.
The only difference I can see with regard to Compiz settings is I have custom settings (not 'Normal' or 'Extra'' visual effects) because I have the 3D cube configured on two X screens.
It looks as if the problem is in the source package generation and the patch itself.
The patch to fix this is "debian/ patches/ 012_default_ keybinding. patch" which patches "src/metacity. schemas. in" which is generated by automake (from "src/metacity. schemas. in.in") . These lead to 'make' creating "src/metacity. schemas" .
However, when the package is built 'make' regenerates "src/metacity. schemas. in" thus wiping out the changes made by the patch:
------ patches/ 012_default_ keybinding. patch at level 1 ... success. schemas. in.in schemas. in.in ./metacity. schemas. in intltool- merge -s -u -c ../po/. intltool- merge-cache ../po metacity.schemas.in metacity.schemas
$ fakeroot debian/rules build
...
Trying patch debian/
...
Generating keybinding schemas... ./metacity.
./schema_bindings ./metacity.
LC_ALL=C /usr/bin/
Generating and caching the translation database
Merging translations into metacity.schemas.
...
------
This is obvious if you try to do a package clean:
------ patches/ 012_default_ keybinding. patch at level 1 ... 0 ... 2 ... failure.
$ fakeroot debian/rules clean
...
Trying reverse patch debian/
make: *** [reverse-patches] Error 1
------
So the obvious fix would be for the patch to be applied to "src/metacity. schemas. in.in".
However, looking at the contents of the patch it isn't clear to me *why* that should work since it affects the "/apps/ metacity/ window_ keybindings/ move_to_ workspace_ 12" key, not "/apps/ metacity/ global_ keybindings/ switch_ windows_ backward" .
Also, the patch is described as a fix for this bug in comment #15 and a changelog entry is shown there which is in the Hardy package changelog; however that entry *does not* appear in the current source package's changelog (or any since Hardy), instead the patch itself is referenced but no specific mention of this bug reference:
------ 21-0ubuntu1) intrepid; urgency=low patches/ 012_default_ keybinding. patch:
metacity (1:2.23.
...
* debian/
Fix default keybinding for shift-alt-tab
-- Pedro Fragoso <email address hidden> Tue, 03 Jun 2008 18:36:06 +0100
------
Inspecting the contents of the patches for Hardy (created my Michael) and the patch that is in Intrepid and later (from Pedro's changelog report) the difference is obvious - they are being applied to different key-bindings:
------ 2.22.0/ debian/ patches/ 012_default_ keybinding. patch metacity- 2.28.0/ debian/ patches/ 012_default_ keybinding. patch /apps/metacity/ window_ keybindings/ move_to_ workspace_ 12</applyto>
<owner> metacity< /owner>
<type> string< /type> disabled< /default> <Shift& gt;< Alt> Tab</default> lt;Control& gt;a" or "& lt;Shift& gt;< Alt> F1" .
$ diff -Nu metacity-
...
+@@ -1348,7 +1348,7 @@
+ <applyto>
- <default>
+ <default>
<locale name="C">
- <short>Move focus backwards between windows using popup display</short>
- <long>
+ <short>Move window to workspace 12</short>
+ <long>The format looks like "&
------
So the issue seems to be twofold:
1. The patches are inconsistent, conflicting, or accidentally misformed during a source package refresh schemas. in.in" if the package-build is going to cause "metacity. schemas. in" to be regenerated after source package patching has been applied.
2. The patch should apply to "metacity.