Bug 966658

I notice from the source, that the host specific settings use the contents of /etc/machine-id, or if not found the contents of /var/lib/dbus/machine-id or if that fails, then it defaults to "00000000000000000000000000000000"

As /etc/machine-id doesn't exist, then a simple hack would be to create this file on all hosts containing the same string (e.g. 32x "0", as above)

I've tested this and it works - I can now share preferences between hosts for the same Wacom type - although it would be much better if an option could be added to the preferences setting display to choose shared or host specific settings

Hi James,

I'm checking this and I see that it was changed from https://bugzilla.gnome.org/show_bug.cgi?id=674792 but perhaps Bastien can help us understand the motivation behind the change and whether what you suggest (having a key for enabling/disabling the use of the machine-id) is a good idea because having such a setting sounds weird to me.

Best regards,

Just to clarify - do you mean that having a key for enabling/disabling the use of the machine-id is a weird idea - or the change to per-machine settings is a weird idea ???

Hi James,

I mean having a key for that seems weird. I'd like to hear first why it is so important to have per machine settings and if they are not, then I'd just remove it (of course that since there was an individual patch made for this, then there might be a good reason... so let's hear it).

OK - yes it would be good to know why this change was made - there in no indication in that Gnome bug as to the reason for the change

A customer (one of the original users of this tool) requested that configuration be made per-machine (or per-host depending on how you look at the machine-id).

/etc/machine-id is the location of the file in newer versions of Fedora (offered by systemd) and I guess it wasn't ported properly to RHEL. From the machine-id(5) man page:
---8<---
The simple configuration file format of /etc/machine-id originates in the /var/lib/dbus/machine-id file introduced by D-Bus. In fact this latter file might be a symlink to /etc/machine-id.
---8<---

The RHEL 6 code should use /var/lib/dbus/machine-id instead.

Unfortunately this is a change/regression from how wacomcpl worked prior to 6.4 - so it causes problems for our users that frequently move between different machines

Ideally the default behaviour should not change from 6.3 -> 6.4

If a change in behaviour is requested, then shouldn't this been made an option rather than the default behaviour that can't be altered by other users?

I made the change upstream, and I explained the possible loss of configuration for users upgrading from earlier RHEL versions in our conversations internally.

I wasn't responsible for backporting those changes (otherwise I'd have changed the path for the machine-id, certainly), or deciding whether it should be merged into this version of RHEL, so I can't really help more on this.

I guess it was a pity that the upstream changes didn't include something to make the change of behaviour optional - especially if loss of configuration for users was a known issue at the time?

I suppose the backporting to RHEL just took those changes verbatim ???

I agree with James Pearson. We also rely on the fact that the wacom configuration is purely user based. We have users that float between machines and want their setting to float with them. 

Having an option to make the config switch between user@machine or user would be fine. Then it could handle both situations without loosing the original functionality.

Any news on when this regression will be fixed?

I've put this patch up for review upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=723099

Once it's accepted upstream, work can be done backporting this fix to RHEL 6.x.

If migration tools are necessary for pre-RHEL 6.4 installations, please file a separate bug, or contact your support manager.

It should be fairly straight forward to write a script to do that using "gconftool-2 --dump", changing the paths of the configuration and reloading them using "gconftool-2 --load".

The patch does seem a bit hacky ... I'm currently using a similar hack - but in my case, using an environment variable to toggle sharing of setting between hosts

Shouldn't the toggle for this be a gconf setting? - that can be managed via standard gconf tools - and ideally via the Wacom control panel ???

Created attachment 913714 [details]
gnome-wacom-properties-bz966658.patch

Dear James,

it seems we have a fixed rpm(s), would you be willing to test within your environment? If you agree I will ask someone to provide them to you.

Thanks
-Tom

I should be able to test - thanks

Hi James, are you able to test this issue with the latest packages and report the results back here?

I guess you mean packages from 6.9-beta?

I'll see if I can find some time to have a look before the end of the year ...

Using gnome-settings-daemon-2.28.2-37 and control-center-2.28.1-41 (from 6.9-beta) appears to 'fix' the issue

i.e. when ~/.config/gnome-settings-daemon/no-per-machine-config exists, then the directory tree ~/.gconf/desktop/gnome/peripherals/wacom/00000000000000000000000000000000-usb:$vendor:$product/ is created - and used when the Wacom tablet is moved between hosts

(In reply to James Pearson from comment #33)
> Using gnome-settings-daemon-2.28.2-37 and control-center-2.28.1-41 (from
> 6.9-beta) appears to 'fix' the issue
> 
> i.e. when ~/.config/gnome-settings-daemon/no-per-machine-config exists, then
> the directory tree
> ~/.gconf/desktop/gnome/peripherals/wacom/00000000000000000000000000000000-
> usb:$vendor:$product/ is created - and used when the Wacom tablet is moved
> between hosts

Thanks James

your versions are the right ones. Moving to verified based on your feedback.

Thanks again!

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2017-0705.html