Bug 9987

Created attachment 3990 [details]
solaar.spec  (adapted and functional for Mageia)

I, with a little research, adapted the spec file for Mageia.
The software works well.

Here to download the tarball for latest version 0.8.8 :

https://github.com/pwr/Solaar/archive/0.8.8.tar.gz

I have build package solaar-0.8.8.1 for Mageia 3,

Here the srpm package:

ftp://download.asso-linux-online.fr/download/packages-mlo/Mageia/3/SRPMS/core/solaar-0.8.8.1-1.mga3.src.rpm

It work very fine on mga3 for x86_64 and i586.

WIP

Status: NEW => ASSIGNED
CC: (none) => mageia

Please test solaar-0.8.9-1.mga4	in cauldron.
FYI: http://svnweb.mageia.org/packages/cauldron/solaar/

Thank you Damien,

It can not be installed on mga3 for x86_64 :

# LC_ALL=C urpmi solaar-0.8.9-1.mga4.noarch.rpm
A requested package cannot be installed:
solaar-0.8.9-1.mga4.noarch (due to unsatisfied typelib(AppIndicator3))
Continue installation anyway? (Y/n) n


More attention to the desktop file must be run as root (su - and not su) for the package to work properly, That's why I add gksu in Requires and had to change the line "Exec=solaar" in the desktop file with "Exec=gksu -l solaar".
Note: the "-l" is very important

I chose the gksu package so that it is accessible to users of Gnome and KDE

I think the installation error comes from the conffile :

$ rpmlint solaar-0.8.9-1.mga4.noarch.rpm 
solaar.noarch: W: spelling-error %description -l en_US unpair -> unpaid, unfair, unpaired

solaar.noarch: W: python-naming-policy-not-applied /usr/lib/python2.7/site-packages/solaar/listener.py

solaar.noarch: W: non-etc-or-var-file-marked-as-conffile /usr/lib/udev/rules.d/99-logitech-unifying-receiver.rules

solaar.noarch: W: no-manual-page-for-binary solaar

solaar.noarch: W: no-manual-page-for-binary solaar-cli

solaar.noarch: W: conffile-without-noreplace-flag /usr/lib/udev/rules.d/99-logitech-unifying-receiver.rules

1 packages and 0 specfiles checked; 0 errors, 6 warnings.

Ok, it requires libappindicator3 but it doesn't exist on mga

Version on Mageia: libappindicator1

No:
# urpmi --test lib64indicator3-devel
Package exists but missing files. WIP. ;-)

Thanks for your test.

Missing files added:
http://svnweb.mageia.org/packages/cauldron/libappindicator/current/SPECS/libappindicator.spec?r1=437374&r2=437373&pathrev=437374
Please test again David.

FYI, solaar *must not* be used as root!

Ok I confirm with this new files of libappindicator solaar is installed and works.

I also confirm that solaar.desktop *must be run as root* so that it can detect Logitech peripherale, if it does not detect any device :

With simple user (not permission to open device):
-----------------------------------------------------------------
[david@david ~]$ LC_ALL=C solaar
Complété
[david@david ~]$

a popup appears and says:
Found a Logitech Receiver, but did not have permission to open it.

If you've just installed Solaar, try removing the receiver
and plugging it back in.
------------------------------------------------------------------


With "su", not works (and no icon will appear in the tray)
--------------------------------------------------------------------
[david@david ~]$ su
Mot de passe : 
[root@david david]# LC_ALL=C solaar

(solaar:7917): libappindicator-WARNING **: Unable to get the session bus: The connection is closed

(solaar:7917): LIBDBUSMENU-GLIB-WARNING **: Unable to get session bus: The connection is closed
Complété
[root@david david]#
--------------------------------------------------------------------



With "su -" works fine :
--------------------------------------------------------------------
[root@david david]# su -
[root@david ~]# LC_ALL=C solaar
[root@david ~]# 
--------------------------------------------------------------------

https://github.com/pwr/Solaar/issues/17#issuecomment-15362635

FYI: *never* launch a X apps with root privileges! Never!

So there is another issue. Perhaps my patch0 is not good enough.
WIP.

Must comes from the users group not available by default.
Please give me your "$ solaar -dd" (as a regular user!).

One more test please.
Can you test to install the package, reboot the computer, and try again to check if the rules is launched by udev.
But please, do all your test as a regular user David.

Created attachment 4104 [details]
result of "solaar-dd"

After reboot it's the same result of "$ solaar -dd".

(In reply to David GEIGER from comment #15)
> After reboot it's the same result of "$ solaar -dd".

Thank you David. Stay tuned! :-)

Thank you for you Damien. :)

Just in case a new version of solaar 0.8.9.1 is present:

https://github.com/pwr/Solaar/archive/0.8.9.1.tar.gz

I know but no Changelog for now so, I did not tried it yet. ;-)

Yep not for this problem, but some change for tray icons, and indeed, the 0.8.9 version does not display the icon in the tray on my system

Where did you see the changelog?
https://github.com/pwr/Solaar/blob/master/ChangeLog stops at 0.8.9 and inside the tarball, it's 0.8.8 IIRC.
No issue with tray icons on my GNOME. Are you using KDE or GNOME?

On README, I can see:
## Known Issues
 
+- KDE/Kubuntu: is some icons appear broken in the application, make sure you've
+  configured the Gtk theme.

I use KDE

Here : 

replaced light_* icons with smaller ones :
https://github.com/pwr/Solaar/tree/master/share/solaar/icons


https://github.com/pwr/Solaar/tree/0.8.9.1


added Keywords entry to .desktop file 
added attention() to tray icon :
https://github.com/pwr/Solaar/tree/0.8.9.1/share

Their changelog does not seem very updated. :(

Tested the new update for solaar-0.8.9.2 and it's installed correctly (libappindicator), but :

- On kde there to have a picture that appears in the sys-tray I have to add the "solaar.png" file in the folder: /usr/share/icons/hicolor/128x128/apps/ 
if I have a blank image with a "?" inside.

Can you add this png files in package ? What I propose:
--------------------------------------------------------
# icons-hicolor
for png in 64x64 32x32 22x22 16x16; do
  mkdir -p %{buildroot}%{_iconsdir}/hicolor/${png}/apps/
  convert -geometry $png %{buildroot}%{_datadir}/%{name}/icons/%{name}.png %{buildroot}%{_datadir}/icons/hicolor/${png}/apps/%{name}.png
done
install -d %{buildroot}/%{_iconsdir}/hicolor/128x128/apps
cp %{buildroot}/%{_datadir}/%{name}/icons/%{name}.png %{buildroot}/%{_iconsdir}/hicolor/128x128/apps
--------------------------------------------------------

For the other problem with Permission it's always the same.

Thank you Damien

An other info :

If I execute a " chmod o+r+ w /dev/hidraw* " as root, solaar works very well.
Only problem the next reboot PC, permissions are not recovered.

(In reply to David GEIGER from comment #23)
> An other info :
> 
> If I execute a " chmod o+r+ w /dev/hidraw* " as root, solaar works very well.
> Only problem the next reboot PC, permissions are not recovered.

Yes, it's the normal way it should work. I'm on it. This update was not to fix this. Otherwise, I would have ask you for a test. ;-)

I will have a look for your icon request David.

I'm telling you once I've got a fix for /dev/hidraw0. It's a tag=+uaccess issue in the udev rules. Stay tuned! :-p

Thank you for the feedback.

(In reply to David GEIGER from comment #22)
> Tested the new update for solaar-0.8.9.2 and it's installed correctly
> (libappindicator), but :
> 
> - On kde there to have a picture that appears in the sys-tray I have to add
> the "solaar.png" file in the folder: /usr/share/icons/hicolor/128x128/apps/ 
> if I have a blank image with a "?" inside.
> 
> Can you add this png files in package ? What I propose:
> --------------------------------------------------------
> # icons-hicolor
> for png in 64x64 32x32 22x22 16x16; do
>   mkdir -p %{buildroot}%{_iconsdir}/hicolor/${png}/apps/
>   convert -geometry $png %{buildroot}%{_datadir}/%{name}/icons/%{name}.png
> %{buildroot}%{_datadir}/icons/hicolor/${png}/apps/%{name}.png
> done
> install -d %{buildroot}/%{_iconsdir}/hicolor/128x128/apps
> cp %{buildroot}/%{_datadir}/%{name}/icons/%{name}.png
> %{buildroot}/%{_iconsdir}/hicolor/128x128/apps
> --------------------------------------------------------

Just did it.
https://github.com/pwr/Solaar/issues/65
I will change it for svg or 256x256 once bug fixed.
Why do you want other size images?

> For the other problem with Permission it's always the same.

WIP.

> Thank you Damien

You're welcome!

> Why do you want other size images?

For nothing, it was just a proposal, if it is necessary or not.

Excellent I have news about permissions, 

This is what is said in the "99-logitech-unifying-receiver.rules" file :

# Make sure the users group exists on your system and your user is a member
# before applying these rules.


So I add my user to the group "users" through the MCC, reboot my machine, and now solaar works very well (no need to order, chmod o+r+w /dev/hidraw*). Perfect!!

Now the question:
is that permissions can be done automatically with the installation, or must it be done manually?

It's not the solution. It's the way it works on Ubuntu/Debian/others.
That's why WIP as I told you many time. ;-)
The solution is to use TAG+=uaccess.

Stay tuned!
The solution you give it's not a solution but a way to skirt the packaging issue on Mageia.

I should work on my fix next week depending on free time.

Please test solaar-0.8.9.2-3.mga4
It should fix the "non access to /dev/hidraw{0,1}".
Thanks

First I removed my user to the group "users" through the MCC, reboot my machine.

Tested for solaar-0.8.9.2-3.mga4, now it works very fine.

nice job Damien.

Great! So, I will work on an update for Mageia 2 and Mageia 3.
I think this package worth it.

(In reply to Damien Lallement from comment #31)
> Great! So, I will work on an update for Mageia 2 and Mageia 3.
> I think this package worth it.

Totally agree with you, I think so too.

Another big thank you for this excellent work.

Be careful though, you must also update libappindicator, 
And Mageia 2 uses /etc/udev/rules.d/ 


Another question:

Why use "%config" in the spec file ? "% config" must be used with 
(noreplace) %{_sysconfdir}, right?
=%config(noreplace) %{_sysconfdir}/*

and why to use "%{_usr}/lib/udev/rules.d/" instead of "% {_udevrulesdir}" for Mageia3 and Mageia4 ?

(In reply to David GEIGER from comment #32)
> (In reply to Damien Lallement from comment #31)
> > Great! So, I will work on an update for Mageia 2 and Mageia 3.
> > I think this package worth it.
> 
> Totally agree with you, I think so too.
> 
> Another big thank you for this excellent work.

You're welcome. Happy to see your hapiness. ;-)

> Be careful though, you must also update libappindicator, 
> And Mageia 2 uses /etc/udev/rules.d/ 

You're right. Good point.
 
> Another question:
> 
> Why use "%config" in the spec file ? "% config" must be used with 
> (noreplace) %{_sysconfdir}, right?
> =%config(noreplace) %{_sysconfdir}/*

Not really no.
%_sysconfdir == /etc
Here, no configuration file in this directory.
%config(noreplace) means that when doing urpme $package "/etc/$package.conf" will be renamed "/etc/$package.conf.rpmsave"
No need here as there is no .conf file.
Usually %config(noreplace) is used for web apps.
In the case of "/etc/udev/rules.d/" for Mageia 2, no need for "(noreplace)" as file don't have to be saved once package removed as file is not modified outside the package.

> and why to use "%{_usr}/lib/udev/rules.d/" instead of "% {_udevrulesdir}"
> for Mageia3 and Mageia4 ?

Just because I forgot the %_udevrulesdir macro. :-)

Please test solaar-0.8.9.4-1.mga3
I will as for an update request if package is working as expected on Mageia 3.
Thanks.

Testing complete for solaar-0.8.9.4-1.mga3 and lib64appindicator1-12.10.0-2.1.mga3 on Mageia release 3 (Official) for x86_64, for me it's Ok nothing to report and works fine.

Thank you dams.

solaar-0.9.2-1.mga3 is now available in updates_testing.
Sorry I was quite busy...
I will ask for an update request tonight or tomorrow.

Starting it from a terminal does show some errors.
(solaar:2307): Gtk-WARNING **: Failed to set text from markup due to error parsing markup: Error on line 1 char 24: Element 'markup' was closed, but the currently open element is 'b'
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/solaar/ui/__init__.py", line 176, in _status_changed
    window.update(device, need_popup)
  File "/usr/lib/python2.7/site-packages/solaar/ui/window.py", line 780, in update
    _model.set_value(item, _COLUMN.STATUS_ICON, 'network-wireless' if is_pairing else None)
  File "/usr/lib64/python2.7/site-packages/gi/overrides/Gtk.py", line 1298, in set_value
    Gtk.TreeStore.set_value(self, treeiter, column, value)
  File "/usr/lib64/python2.7/site-packages/gi/types.py", line 47, in function
    return info.invoke(*args, **kwargs)
TypeError: Argument 3 does not allow None as a value

It's working ok though.

CC: (none) => davidwhodgins

Thank you David!
And you don't have this warning under cauldron?

In cauldron, I get ...
/usr/lib64/python2.7/site-packages/gi/overrides/GLib.py:53: PyGIDeprecationWarning: threads_init no longer needs to be called. See: https://bugzilla.gnome.org/show_bug.cgi?id=686914
  PyGIDeprecationWarning)

(solaar:4467): Gtk-WARNING **: Failed to set text from markup due to error parsing markup: Error on line 1 char 24: Element 'markup' was closed, but the currently open element is 'b'
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/solaar/ui/window.py", line 390, in _device_selected
    _update_info_panel(device, full=True)
  File "/usr/lib/python2.7/site-packages/solaar/ui/window.py", line 695, in _update_info_panel
    _info._icon.set_from_icon_name(icon_name, _DEVICE_ICON_SIZE)
TypeError: Argument 1 does not allow None as a value

Advisory
====================
This update imports Solaar, a tool to monitor Logitechâs Unifying Receiver peripherals.

Packages
====================
solaar-0.9.2-1.mga3.src.rpm
solaar-0.9.2-1.mga3.noarch.rpm

Steps to Reproduce
====================
- Install Mageia 3 and plug a Logitechâs Unifying Receiver peripherals on your PC
- Install solaar (0.9.2 from "core/updates_release")
- Play with it (will be autolaunch on next boot, or launch it by the menu) and check it works!

Version: Cauldron => 3
Assignee: mageia => qa-bugs
Summary: Solaar_Tools to monitor Logitech hardware => [new package request] - Solaar tools to monitor Logitechâs Unifying Receiver peripherals
Source RPM: (none) => solaar-0.9.2-1.mga3.src.rpm

My understanding of https://wiki.mageia.org/en/Updates_policy#Version_Policy is
that the package will have to wait until backports are opened, and then be
submitted to backports testing, rather then updates testing.

CC: (none) => eeeemail, tmb

That is my understanding also.

Keywords: (none) => Backport
CC: (none) => stormi

It looks like there could be some icons missing. The right click menu of the taskbar icon has white pages, with the corner turned down, against the options there.

I have an old wireless logitech mouse. It doesn't recognise the receiver as a Unifying Receiver but doesn't affect the mouse in any way.

Policy is that this should be a backport but without backports open we should maybe use some judgement here.

WDYT?

Well, policy can be read in several ways the way it is written. Actually, I find easier for users to get new packages from updates (they appear automatically since updates media are always active) than from backports, the moment a package reaches updates being when usual restrictions to new updates come into application.

Of course such packages must not break anything nor impact other packages, but the same can be said of backports.

As backports are now open Damien, we should follow policy (even if it's all a bit up in the air still). Could you package this into backports please.

I'll add 'feedback' marker for now.

Thanks

Whiteboard: MGA3-64-OK => MGA3-64-OK feedback

Assigning back to Damien for the preparation of a backport for solaar and removal of old updates_testing package.

Assignee: qa-bugs => mageia
Whiteboard: MGA3-64-OK feedback => (none)

solaar-0.9.2-1.mga3 now available in 3/core/backports_testing
Assigning back to QA.

Assignee: mageia => qa-bugs

Hi Damien. You're being unlucky: Packagers have decided not to open backports for Mageia 3. So we can't validate this backport request.

I think it can be further discussed for new packages though (such as isodumper that I requested as backport too).

CC: (none) => remi

(In reply to Samuel VERSCHELDE from comment #46)
> Assigning back to Damien for the preparation of a backport for solaar and
> removal of old updates_testing package.

(In reply to Samuel VERSCHELDE from comment #48)
> Hi Damien. You're being unlucky: Packagers have decided not to open
> backports for Mageia 3. So we can't validate this backport request.

Hi Samuel, I was just answering your request. :-(
Unlucky yes! :-/
So, I close it as WONTFIX for Mageia 3?

My request was before the packagers meeting decided to refuse backports to mageia 3. So yes, either the decision changes in the future for new packages, or it's a wontfix :/

Closing, sorry Damien.

Status: ASSIGNED => RESOLVED
Resolution: (none) => WONTFIX

It might be worth asking for an exception to allow this as an update rather than backport.