Description of problem: Using the new rpm colord-kde-0.3.0-2.mga4 I discover the mandatory service to use it did not exist in the CCM service list. Version-Release number of selected component (if applicable): colord-1.1.5-1.mga4 on 3.12.8-desktop-2.mga4 How reproducible: install and use the color-kde rpm or more simple launch any command involving colord for ex: colormgr get-devices-by-kind display or colormgr get-profiles Result always will be: Aucune connexion à colordâ¯: Erreur lors de l'appel de StartServiceByName pour org.freedesktop.ColorManager : Le délai d'attente est dépassé And if you test if service is running on Mageia4, the command systemctl |grep -i color return nothing while on Mageia2, it is OK below systemctl |grep -i color colord.service loaded active running Daemon for managing, installing and generating color profiles Reproducible: Steps to Reproduce:
Component: Installer => RPM PackagesAssignee: bugsquad => neoclust
John and Nicolas, I'm not sure if this bug is caused by colord or colord-kde. For colord, we're using the development branch in Mageia 4, so I was planning to update it eventually anyway, preferably when the branch became the stable 1.2.0 release. As of right now, there is a newer development version 1.1.6, which we could provide as an update now if it would fix this.
CC: (none) => luigiwalser, mageiaAssignee: neoclust => balcaen.john
Hello, colord-kde is for KDE, with GNOME it is gnome-color-manager! So, if you use the gcm-viewer from this last, you have also the same error: "gcm-viewer (gcm-viewer:6693): Gcm-WARNING **: failed to connect to colord: Erreur lors de l'appel de StartServiceByName pour org.freedesktop.ColorManager : Le délai d'attente est dépassé" => as pb is existing also with GNOME, I am thinking problem do not come from the colord-kde introduced in Mageia4 but from the colord.service is not launched!
So if you enable and start the colord service, does it fix this problem?
It seems launching colord service is NOK 1) launching (root) service colord start Redirecting to /bin/systemctl start colord.service 2) making status service colord status Redirecting to /bin/systemctl status colord.service colord.service - Manage, Install and Generate Color Profiles Loaded: loaded (/usr/lib/systemd/system/colord.service; static) Active: inactive (dead) mars 16 12:50:56 localhost.P5B colord[5157]: loaded plugin libcd_plugin_scanner.so mars 16 12:50:56 localhost.P5B colord[5157]: Daemon ready for requests mars 16 12:50:56 localhost.P5B systemd[1]: Started Manage, Install and Generate Color Profiles. mars 16 13:20:19 localhost.P5B systemd[1]: Starting Manage, Install and Generate Color Profiles... mars 16 13:20:19 localhost.P5B colord[8247]: Using mapping database file /var/lib/colord/mapping.db mars 16 13:20:19 localhost.P5B colord[8247]: Using device database file /var/lib/colord/storage.db mars 16 13:20:20 localhost.P5B colord[8247]: loaded plugin libcd_plugin_camera.so mars 16 13:20:20 localhost.P5B colord[8247]: loaded plugin libcd_plugin_sane.so mars 16 13:20:20 localhost.P5B colord[8247]: loaded plugin libcd_plugin_scanner.so mars 16 13:20:20 localhost.P5B systemd[1]: Started Manage, Install and Generate Color Profiles. 3) colord PID is not existing ps -ef |grep -i color root 8575 6748 0 13:27 pts/1 00:00:00 grep --color -i color [root@localhost ~]#
OK, so the colord service is dbus activated, so rather than start at boot, it will start when something tries to use it. I think the message you posted in Comment 2 indicates that it's trying to start it via dbus and failing. I just started it manually in a Mageia 4 VM and got the same log messages you did, but it was running, so I can't reproduce it failing to start. Maybe if you ran either: strace /usr/libexec/colord ltrace /usr/libexec/colord one of those would give some indication of why it's dying.
Created attachment 5066 [details] strace /usr/libexec/colord &> straceColord.log
CC: (none) => kalagani
Hello David, strange behavior launching the "strace /usr/libexec/colord" command 1) without redirection on a log file strace /usr/libexec/colord If I use the color (need colord-kde installed) from the system configuration, I can see Peripherics (display and basic USB) and Profiles and also I can Add or remove a profil => all features from color-kde are OK 2) with redirection to a log file strace /usr/libexec/colord &> straceColord.log Now, color is also available but nothing is appearing in the windows, just on the rigth you can read: "You do not have any devices registered Make sure colord module on kded is running" then the systeme configuration go to freeze. I exit log by CTRL+C on the console I launched the command strace! I attached this log
The attached log is incomplete and doesn't show it failing. Maybe colord-kde doesn't like colord being killed and restarted while it's running. I guess the only thing to do would be to reboot and see if having it fail to start when needed is reproducible and see if you can get some debugging information (probably through systemd) when this happens. At the very least, if it is reproducible, we could see if colord 1.2.0 fixes it once it comes out (who knows when that will be).
Mikala is MIA, reassigning to current maintainer
CC: (none) => marja11Assignee: balcaen.john => mageia
Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 4's end of life. If you are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. If it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
Closing this. Please re-open and give additional debugging details if Mageia 5 is affected.
Status: NEW => RESOLVEDResolution: (none) => OLD
Since Mageia 5 might be affected, actually leaving 1 month like comment #10 announced.
Status: RESOLVED => REOPENEDResolution: OLD => (none)
The software has changed quite a bit from mga4 to mga5 and we haven't received any additional reports on this. There's no reason for this particular bug to assume that it has a high probability of still being valid.
Status: REOPENED => RESOLVEDResolution: (none) => OLD
Hello, verifying on my end-of-life Mageia4, I see pb do not appear because now colord service is launched while not previously: systemctl |grep -i color colord.service loaded active running Manage, Install and Generate Color Profiles So David Walcher in Comment 1 ..".I'm not sure if this bug is caused by colord or colord-kde..." was true! I think a particular Mageia4 update solved the pb found on Mageia4 begin-of-life! A new PC with another graphic card without calibration explains my late answer, sorry! PS: my versions rpm -qa |grep color ... lib64colord2-1.1.5-1.mga4 ... colord-1.1.5-1.mga4 colord-kde-0.3.0-2.mga4 on 3.14.43-server-1.mga4