Bug 25029 - Error launching albert after urpmi albert
Summary: Error launching albert after urpmi albert
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: MGA7-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2019-07-02 11:29 CEST by Nicolas Gibelin
Modified: 2019-07-10 12:45 CEST (History)
3 users (show)

See Also:
Source RPM: albert-0.14.21-4.mga7.src.rpm
CVE:
Status comment:


Attachments

Description Nicolas Gibelin 2019-07-02 11:29:28 CEST
Description of problem:

### 1: After installing albert package:

Launch albert from terminal: libalbertcore.so not found

ldd /usr/bin/albert                                                                                                                                                                                                                               
	linux-vdso.so.1 (0x00007ffc16989000)
	libalbertcore.so => not found
	libc.so.6 => /lib64/libc.so.6 (0x00007fcb23bfd000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fcb23de8000)

SOLUTION:
echo '/usr/lib64/albert/' >> /etc/ld.so.conf.d/albert
ldconfig

### 2: After launching in terminal:

11:05:37 [INFO] Systems icon theme is: "nimbus"
11:05:37 [WARN] QSqlDatabase: QSQLITE driver not loaded
11:05:37 [WARN] QSqlDatabase: available drivers: 
11:05:37 [FATAL] No sqlite available  --  [(null)]

SOLUTION:
installing lib64qt5-database-plugin-sqlite

urpmi lib64qt5-database-plugin-sqlite


### INFO:
I had the issue after upgrading from mageia 6.
Albert was not installed in my mageia 6.
Not tried to reproduce yet on my other computer, but i will try.
Comment 1 David GEIGER 2019-07-02 14:42:42 CEST
Assigning to QA now,


Advisory:
========================

There's a missing required dependency on the albert package from Mageia 7.
If no other packages pulling 'qt5-database-plugin-sqlite' are installed on the computer, albert can't start. This update adds this missing dependency.

========================

Packages in 7/core/updates_testing:
========================
albert-0.14.21-4.1.mga7.i586.rpm
albert-0.14.21-4.1.mga7.x86_64.rpm

Source RPM: 
========================
albert-0.14.21-4.1.mga7.src.rpm


How to test this update request:
========================
- Install a system and make sure you don't have 'qt5-database-plugin-sqlite' installed.
- Install 'albert' from core/release and see if you can open it,
  normally you can't.

- Install now 'albert' from core/updates_testing and check if it will install 'qt5-database-plugin-sqlite' and if now you can open and use it.

CC: (none) => geiger.david68210
Assignee: bugsquad => qa-bugs

Comment 2 Len Lawrence 2019-07-05 20:02:05 CEST
mga7, x86_64

$ sudo urpmi albert
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Release")
  albert                         0.14.21      4.mga7        x86_64  
  lib64qt5concurrent5            5.12.2       2.mga7        x86_64  

$ albert
albert: error while loading shared libraries: libalbertcore.so: cannot open shared object file: No such file or directory
$ rpm -qa | grep qt5-database-plugin-sqlite
$

Enabled updates testing.
# urpmi.update -a
# urpmi albert
  Package                        Version      Release       Arch    
(medium "Core Release")
  lib64qt5-database-plugin-sqli> 5.12.2       2.mga7        x86_64  
(medium "Core Updates Testing")
  albert                         0.14.21      4.1.mga7      x86_64  

$ albert
albert: error while loading shared libraries: libalbertcore.so: cannot open shared object file: No such file or directory
$ locate albertcore
/usr/lib64/albert/libalbertcore.so

# echo '/usr/lib64/albert/' >> /etc/ld.so.conf.d/albert
# ldconfig

$ albert
albert: error while loading shared libraries: libalbertcore.so: cannot open shared object file: No such file or directory
$ ll /usr/lib64/albert/libalbertcore.so
-rwxr-xr-x 1 root root 404072 Jul  2 12:27 /usr/lib64/albert/libalbertcore.so*

Plugin installed OK but albert does not respond.
Tried this:
# ldconfig -f /etc/ld.so.conf.d/albert
$ albert
18:41:11 [INFO] Systems icon theme is: "mate"
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

The "First run" dialogue comes up.  Crashed out of that.
$ albert -d
18:45:44 [INFO] Systems icon theme is: "mate"
18:45:44 [DEBG] Creating IPC server
18:45:44 [DEBG] Initializing mandatory paths
18:45:44 [DEBG] Checking last used version
18:45:44 [DEBG] Initializing database
18:45:44 [DEBG] Initializing core components
18:45:44 [DEBG] Initializing tray icon
18:45:44 [DEBG] Setting up hotkey
18:45:44 [DEBG] Setup signal handlers
18:45:44 [DEBG] Creating running indicator file
18:45:44 [DEBG] Creating settings widget
18:45:44 [DEBG] Entering eventloop

The icon appears in the Mate panel/taskbar.  Clicking on that raises the GL error again - the gui appears momentarily.  Glimpsed a frame border with a zero height window.

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
18:47:00 [DEBG] ========== SESSION SETUP STARTED ==========
18:47:00 [DEBG] TIME:      0 µs SESSION SETUP OVERALL
18:47:00 [DEBG] ========== QUERY: ""  ==========
18:47:00 [DEBG] TIME:    144 µs SESSION TEARDOWN OVERALL
18:47:01 [DEBG] ========== SESSION TEARDOWN STARTED ==========
18:47:01 [DEBG] TIME:  20295 µs SESSION TEARDOWN OVERALL

$ killall albert

stellarium failed also so these GL problems are outside the scope of this bug.
The good news is that albert now launches if ldconfig is used.
Need feedback on this.  Is the ldconfig issue separate or should it be fixed in this one?

CC: (none) => tarazed25
Keywords: (none) => feedback

Comment 3 Len Lawrence 2019-07-05 20:34:17 CEST
With reference to comment 2:
I reinstalled the nvidia graphics driver and rebooted.  glmark2 ran but albert needed the ldconfig operation to launch.   Clicking the icon in the system tray brought up the blank window for a couple of seconds this time and also reported the GL errors in the terminal.  After that glmark2 failed to run, so maybe the GL stuff is relevant to albert though not to this bug.
Comment 4 Len Lawrence 2019-07-07 17:08:58 CEST
With reference to comment 3:
Looks like the ldconfig operation is a common factor - that might have something to do with the damage inflicted on GL applications.
Comment 5 Len Lawrence 2019-07-07 17:28:44 CEST
Continuing from comment 4:
As an ordinary user I know nothing about administrator commands like ldconfig but I find it suspicious that the only other directory in /etc/ld.so.conf is GL which leads me to wonder just how the command is supposed to be invoked when adding  references to applications like albert.  Anybody?
Comment 6 David GEIGER 2019-07-07 18:31:51 CEST
A new update should fix this shared libraries issue!

========================

Packages in 7/core/updates_testing:
========================
albert-0.14.21-4.2.mga7.i586.rpm
albert-0.14.21-4.2.mga7.x86_64.rpm

Source RPM: 
========================
albert-0.14.21-4.2.mga7.src.rpm
Comment 7 Len Lawrence 2019-07-07 18:53:42 CEST
Thanks David.  Shall continue when my mirror syncs.
Comment 8 Len Lawrence 2019-07-07 21:08:43 CEST
OK, updated albert and it pulled in the plugin.  Invoking albert from the cli loads the applet in the mate panel but clicking on that brings up the empty window for a second or two then exits.  /etc/ld.so.conf.d still does not contain the albert file so I created it and added the redirection but I am unwilling to run ldconfig without expert help so the albert libraries are not in the cache.

About to reboot the system to see if systemd can do it without removing GL from the cache.

Rebooted.
# ldconfig -p | grep albert
#

Not a good sign.

$ albert &
Panel icon still does not launch a valid albert session but GL is still live.
Tried a couple of experiments; first renaming albert.conf then adding it to its own albert directory.  Neither worked so it looks like rebooting does not rebuild the cache.  It has to be updated in session so we are back to still needing expert help to run ldconfig.  Remember that the way I did it before enabled albert but destroyed GL.  Reverting to the plain albert file in /etc/ld.so.conf.d/.
# cat albert
/usr/lib64/albert/
Comment 9 Len Lawrence 2019-07-07 21:19:07 CEST
# ldconfig -p | wc -l
1548

# cat GL/standard.conf
# This file is knowingly empty since the libraries are in standard search
# path. Please do not remove this file.

# ll
total 8
-rw-r--r-- 1 root root   19 Jul  7 19:47 albert
drwxr-xr-x 2 root root 4096 Jul  5 21:41 GL/
lrwxrwxrwx 1 root root   25 Jul  5 22:36 GL.conf -> /etc/alternatives/gl_conf
Comment 10 Len Lawrence 2019-07-07 21:28:11 CEST
On the other hand this ldconfig stuff may be a red herring because libalbertcore is found.  The output of ldd looks OK.
# ldd /usr/bin/albert
	linux-vdso.so.1 (0x00007ffd838db000)
	libalbertcore.so => /usr/bin/../lib64/albert/libalbertcore.so (0x00007fd180133000)
[...]
Comment 11 Len Lawrence 2019-07-07 21:39:53 CEST
Beginning to see the light.  It may be working - the settings dialogue is there but none of that means much to me.  Given my ignorance of how to run this thing and the fact that it loads and does not report any errors this should probably be given the green light.

Whiteboard: (none) => MGA7-64-OK
Keywords: feedback => (none)

Comment 12 Rémi Verschelde 2019-07-10 11:18:50 CEST
Advisory uploaded, validating.

Keywords: (none) => advisory, validated_update
CC: (none) => sysadmin-bugs

Comment 13 Mageia Robot 2019-07-10 12:45:37 CEST
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2019-0055.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.