When the DM ist switched to LXDM to XDM, the PATH changes to
"/bin:/usr/local/bin:/usr/bin:/usr/games:usr/lib64/qt4/bin:home/man-draker"
and the problem with shotwell remaines.

Target Milestone: --- => Mageia 3

Workaround until solved: Install and use KDM.

Colin maybe you have an ideas ? (sorry if you are not the best person don't know :/)

CC: sysadmin-bugs => mageia
Component: Release (media or process) => RPM Packages

The fact that /bin is in the path should be irrelevant. It's the same as /usr/bin - just a symlink. Does this *really* cause the problems you suggest or is there perhaps some other explanation?

This isn't the first report that having /bin in the PATH can cause issues, and some work has been done (at least some of which looks like by Luc Menut) to remove it from the default paths in Mageia.  KDM is one of the packages it was fixed in...I guess it needs fixed in LXDM and XDM too.  (See Bug 7119 for example)

It should not be an issue to have /bin in the PATH
shotwell should be fixed.
What is the exact issue?

CC: (none) => mageia

FWIW, I've noticed such paths appearing automatically in some config files. I guess maybe msec is modifying them? Again tho', as I mentioned in comment 4 and as blino just said also, it shouldn't cause any problems and if it does it sounds like a bug in the programs doing some kind of manual interpretation of $PATH...

Created attachment 3911 [details]
Error Messages thrown by Shotwell, when started with /bin in PATH

In reply to Comment 6

Can't reproduce here.

[colin@jimmy ~]$ shotwell 2>&1 | grep /bin
[colin@jimmy ~]$ echo $PATH
/usr/lib64/ccache/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib64/qt4/bin:/home/shared/scripts/:/home/colin/shared/scripts:/usr/sbin:/usr/local/bin:/home/colin/bin
[colin@jimmy ~]$ 

I strongly suspect the cause is not to do with the $PATH or if it is, it's a very strange one. Looking for icon files in your path is generally wrong anyway. I suspect you've maybe set some XDG_* variable somehow or have some other stale file. Perhaps try to reproduce with a clean/new user account?

Colin: make sure you have /bin before /usr/bin in your PATH to reproduce.
I can reproduce after switching them using your PATH.

This is a bug in shotwell.

Summary: MGA3 RC inserts "/bin:" into Userpath when started in RunLevel 5 => shotwell does not start when /bin is before /usr/bin in path

Yeah reproduced here now I do that. Nasty... Smells like it is in shotwell but grepping the source doesn't find any use of PATH. Perhaps it's in vala?

OK, so it's not *technically* $PATH related... if I run /usr/bin/shotwell, all is well, if I run /bin/shotwell it breaks, regardless of PATH.

I guess it's some kind of parsing of the basename. It's not likely to be in vala, so could very well be in shotwell itself.

Looking closer it's in
util/system.vala:

// Return the directory in which Shotwell is installed, or null if uninstalled.
File? get_sys_install_dir(File exec_dir) {
    File prefix_dir = File.new_for_path(Resources.PREFIX);
    return exec_dir.has_prefix(prefix_dir) ? prefix_dir : null;
}

This ultimately falls back to null and then uses the bin dir... This is code to allow running uninstalled (e.g. for devs testing builds).

Prepping a patch now.

I think it is not only the piece of code you mentioned, but also these:

./src/AppDirs.vala:        File exec_file = File.new_for_path(Environment.find_program_in_path(arg0));
./src/International.vala:        File.new_for_path(Environment.find_program_in_path(args[0])).get_parent().get_child(

In src/AppDirs.vala:

    // Return the directory in which Shotwell is installed, or null if uninstalled.
    public static File? get_install_dir() {
        return get_sys_install_dir(exec_dir);
    }

    public static File get_resources_dir() {
        File? install_dir = get_install_dir();
        
        return (install_dir != null) ? install_dir.get_child("share").get_child("shotwell")
            : get_exec_dir();
    }

get_resources_dir() will fallback to the local exec dir, as you said for devs with uninstalled builds.

Applied this. It should fix it.

http://git.yorba.org./cgit.cgi/shotwell/commit/src/util/system.vala?id=65574e34b90c5e5a19fcfc0d799b793ef7775691

OK, so it didn't actually work. I've now applied a more brutal patch that fixes it.

Will liaise with upstream to see why it didn't work.

In the short term we can push this version.

Shotwell 0.14.1-2 installed.
Shotwells starts with /bin in PATH.
Problem solved.

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