Since it works for the other user, it's not a problem with fluxbox or xorg. It's a problem with the first user account. It could be some other hidden file in that user's home or it could be something to do with permissions or authentication for that user. Did you change anything in pam or polkit configs? Something else?

I don't think editing the conky configs could do what happened. Something else had to happen around the same time. That's why I suggested looking in the command histories. Maybe you did something that you don't recall right now. (I do that all the time.) Just run history as root and as user, and look at the commands around when you edited conky.

Fixed.

thunderbird:
  Installed: (none)
  Candidate: 1:60.7.1-1~deb9u1
  Version table:
     1:60.7.1-1~deb9u1 500
        500 http://pkgmaster.devuan.org/merged ascii-security/main amd64 Packages
        500 http://auto.mirror.devuan.org/merged ascii-security/main amd64 Packages

I'm confused. In one post it looks like you said you created a new user and it worked, and in another post you said you didn't create a new user.

Anyway, maybe you should take a look in both root and user's command history to review what you actually did when you edited the conky config.

Is your home partition full? 

df -h

Note the dot in .Xauthority. That makes it a hidden file.

ls -la

Will show you all your files in home as well as who owns them.

Try removing .Xauthority first. If that doesn't fix it, you can start deleting user configs. Those can be found in a hidden directory - ~/.config. The nuclear option is to delete all of .config, and then you'd be logging in like a new user. (i.e. any of your custom desktop settings or desktop-application settings would be lost.)

I put the following in /root/.bashrc. It gives me root's normal path when I use 'su' in a user's terminal. The advantage is it keeps me in the user's home instead of moving me to /root, where I'd have to cd to user's home again. (for example to install a deb package I just downloaded). It also allows me to run graphical apps as root. (e.g. I use gparted a lot).

export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

I say not to use that feature because it does not work right or work the way anyone expects it to work. I've removed it from later versions of the installer.

You can do a clean install and copy files from backups. If you have a lot of big files, that could take some time. (I'm a little sensitive about this issue now because I recently had to move a terabyte of wav files.) Also, if you copy files from backup as some user, that user will own the copied files.

And if you just keep the files on the hard drive, keep the same user name and user ID number, then permissions and ownership of your files will be correct.

I've tried that many times, and it never seems to work. At this point, I'd be happy to know how to get google to return hits that contain my search terms.

FTR: With plain openbox, setting the theme in:

obconf - just changes the title bar, buttons (and borders?) but not
the highlights.

lxappearance - changes the highlights. (gets rid of the raleigh blue)

lxappearance-obconf - apparently does nothing, and it's described as a
theme switcher for LXDE.

gtk2-engines - didn't seem to do anything in openbox.

To get the cinnabar highlights in synaptic or other root apps, you can copy ~/.config/gtk-3.0/settings.ini to root's home after you set the theme with lxappearance.

If you're going to compile stuff from source you'll need to install build-essential and linux-headers-$(uname -r)

deb.devuan.org was fixed (today?)
another option for using mirrors is auto.mirror.devuan.org which was upgraded to the same software as deb.devuan a few months ago.

Edit: fixed typo - it's headers not header. (and it's build-essential, not essentials in case anyone was wondering)

Thanks, I knew there had to be other ways. (It's linux.)

OMG, I've been using feh for years, and I just read the man page for the first time. I had no idea it could do so much.

For plain encrypted filesystems without lvm, you can do the fix that changes the timeout.

Edit this function in /lib/cryptsetup/cryptdisks-functions. (And keep a spare copy of this file those times when an update wipes out your edits. )

_do_stop_callback() {
    local i rv=0
    for i in 1 2 4 8 16 32; do
        remove_mapping "$CRYPTTAB_NAME" 3<&- && break || rv=$?
        if [ $rv -eq 1 ] || [ $rv -eq 2 -a $i -gt 16 ]; then
            log_action_end_msg $rv
            break
        fi
        log_action_cont_msg "$CRYPTTAB_NAME busy..."
        sleep $i
    done

To look more like this. You can make it 'for i in 1' instead of 'for i in 1 2' if you want.

_do_stop_callback() {
    local i rv=0
    for i in 1 2 ; do
        remove_mapping "$CRYPTTAB_NAME" 3<&- && break || rv=$?
        if [ $rv -eq 1 ] || [ $rv -eq 2 -a $i -gt 16 ]; then
            log_action_end_msg $rv
            break
        fi
        log_action_cont_msg "$CRYPTTAB_NAME busy..."
        sleep $i
    done