... and what's worse, reverting to before it didn't fix them again as the conversion had already broken them. Thus, despite my finding that commit in the log relatively quickly and believing it to be the culprit, because reverting to before it didn't fix things, it took me hours to figure out what had happened. There's actually two bugs. This is the first one. I'll start with a description of the previous situation: All the files in autostart-scripts before the conversion were (differently named) symlinks to the same bash script file, named autostart-disabler. That script looks like this (file delimited by the >>>>/<<<< marks): >>>> #!/bin/bash # following line uncommented: autostart scripts disabled #exit # get my (symlink?) basename me=${0##*/} # exit if it's not *.sh [[ $me == *.sh ]] || exit # trim the .sh me=${me%.sh} # set special path OLDPATH="$PATH" PATH="$HOME/bin/autostart:$PATH" # runit exec $me <<<< The idea is that if I'm testing something and want to disable my autostart scripts, I can disable them all with a quick uncomment of that exit line. The script then gets the basename, checks for and strips the .sh extension, adds a priority path to the autostart subdir within my user bin directory, and executes the result, normally a shellscript or symlink in that bin/autostart subdir that invokes the executable I actually want to run. Of course the converter played havoc with all that, setting the same autostart-disabler shellscript in all the exec lines of the created *.desktop files so they'd launch the shellscript directly instead of via the symlinks that provided the information to the script that it was actually looking for, that being the name of the symlink formerly used to launch it, so it could launch the desired executable accordingly. Of course started directly like that the name didn't match the *.sh pattern so the script simply exited. Not that it could have figured out what to actually start if it didn't exit there. Now it's arguably not reasonable to expect the converter to figure out all that and properly convert things, but one /could/ expect it to popup a notice saying that it had converted the scripts in the autostart-scripts dir and the user might wish to verify the conversion, so the user would at least have some clue what happened if the converter wasn't smart enough and something broke, as it did for me. And/or it could do some sort of minimal sanity check, like ensuring that if the files there are symlinks, no two point to the same target, erroring out with a note to check them and perhaps a link to a page on how to do the conversion manually if necessary.
(In reply to Duncan from comment #0) > There's actually two bugs. This is the first one. The second is bug # 436439.
Did you restart after applying that commit? This happened to me too while testing, but after restarting, everything was all better. This is what users would (presumably, hopefully) do after a system upgrade.
(In reply to Nate Graham from comment #2) > Did you restart after applying that commit? Yes. Multiple times in fact. (As explained in bug #436439 on the repeated conversion, I ended up with 11 copies of each of 9 autostart scripts and deleted 10 copies of each, because it was reconverting each time. This bug's on the bad conversion and what to do about it, while the other one is on repeating the conversion over and over again at each restart.)
So time moved on and I reworked my scripts. Setting RESOLVED/WORKSFORME. (Wanted RESOLVED/OBSOLETE, but that's not an option on kde bugzi. Also considered RESOLVED/DOWNSTREAM, since that's effectively what it is as I'm downstream, but as NEEDSINFO/WAITINGFORINFO auto-resolves to WORKSFORME, and that's what I'd be doing if there were others who reported the bug in case they still had problems, I'll use that here too.)