My apologies I should have read  your original post more attentively :
your not trying to upgrade to ascii .
Simply attempting to capture jessie-security updates.

As golinux mentions elsewhere  this issue is finally a packaging bug.

There are ways though...

a/ equivs   (rings a bell.  though you need something to equiv with)

Or even adding ascii to your sources list and using  -t ascii or /ascii on the apt-get install.
(for the _problem_ packages only)

If however you wish to stay "pure" to jessie  the package(s) will need their /debian/stuff fixed.

Please if your adding ascii see:
http://devuan.org/os/

Update:
The weekly cron script is simple and tweakable .
A 1000 days _may_ be too long or maybe not.

It is simply a couple of transparent  find commands.

It would also make a great template for other runs or even uses by other services.

The version below has  modified  comments

see:  /etc/cron.weekly/approx

#!/bin/sh
# /etc/cron.weekly/approx
# Remove old files from the approx(8) cache

# Location of the cache
cache=/var/cache/approx

# Maximum age of files to keep, in days
max_age=1000

# Delete  _files_  modified   +more than "max_age" days ago 
# and _print_ the activity noise to cron so it can tell somebody if needs be.

find $cache -type f -mtime +$max_age -delete -print

# Remove empty files and directories

find $cache -empty -delete

I will try not to be.

There are other good options as well.
squid  and  apt-cacher-ng

This approach works reasonably well for my home LAN
AND builds sane mirrors that are amenable to dpkg / apt / file::// 

(system tools)

From *bitter* experience:

I would suspect evdev (comes from X "freedesktop" world) or more likely one of the udev alternatives is not past unstable yet. (ceres)
So on ascii (testing) there will be issues.

Unless of course your trying to use wayland alone in which case good luck.
Wayland doesn't do anything but render stuff. (short version).

See if you have an /etc/X11/Xwrapper ?
( there are auth and legacy packages for X )

__the rest of this is just rambling nonsense that may or may not be useful correct or even english_

These days I short circuit all that "system initialisation" total nonsense by testing startx (as root).
If that works then work backwards.
(essentially all is well )

Permission / access / initialisation of pointers graphics cards and so on,  are not the task of a Display Manager. Sure loading a module or driver or protocol can be a handy *side effect* but in a "normal" work station / desktop / thin client  set of use cases other subsystems are meant to handle access to lumps of plastic, metal and wishes.

Pointer and keyboard may not be fully initialised (no mouse required for example) until you get all the way to your desktop / window manager.
Because:
The Display Manager is usually *and quite rightly* allowed access to a minimal set of files and  normally hosts.

Some go further than others in allowing access some do less, its impossible to guess our preferred security needs. So less is best here. The minimum required to get you logged into whatever desktop you use on whatever operating environment.

Slim more or less assumes you are on your own host.
It doesn't even allow you to select a locale  TZ or alternative set of languages.

Thanks for the well researched report !

As golinux suggests perhaps trying to set the resolution in xorg.conf (or one of the .d/files )
May help. If it does ? Bingo!
I saw those logs popped a few clues around kernel modules and possibly udev.

The video driver appears to be getting "bad parameters" from earlier tools.
(but yeah you knew that)
Its notable though that the screen resolution tools can not see or set the correct known good resolution...

So _*maybe*_ its a driver thing or even a kernel module:
(less likely but simpler to fix)

grep KMS /boot/config-$(uname -r)

If hand loading (insmod  modprobe) those and
startx >> xfce-resolution thing now allows access to the modes
then add the  appropriate modules to /etc/modules

Its not likely but this is video driver world there are plenty of weird dragons about.

So when neither of those above work:
Its time to look:
        harder at the actual driver itself.
        at what (assumptions) udev maybe throwing in the way.

As a benchmark or simple comparison force the vesa driver
((and see/compare how everything behaves
(at least you can then eliminate the xorg-video-foo driver))

man xorg says: (lots and lots)
But this may help.

xorg -configure

  (see roots home)

I guess what I'm saying is try going the other way down the tool chain given you have reached higher levels of abstraction than the tools can use.
At this point, after a couple of days, I normally notice the auto button on the monitor and the reset the thing, which makes me feel a little better.

Its not hard to test this:

sudo service slim stop

(may not be slim.)

now try to 

startx 

or xinit -- :2

Which should get you default windowing environment
Once you have that all worked out you can remove gdm lightdm slim (or whichever(s) it is)

Perhaps this ~/.xinitrc may be of service::

https://git.devuan.org/PeteGozz/slim/bl … trc.sample

So until you are happy.

service slim restart

At some point you are ready to leave the Display Manager behind.
Or at least disable it as an interim move.

Next::

sudo update-rc.d slim disable

Finally: example only your Display Manager may be something else.

apt-get remove slim  

You _do_ read the list of _other_  things that will be removed and perhaps even installed!!

OK ? Confident ?

Then enter " y "

and _*welcome*_ to a simpler  life.

There may also be something useful here:
https://dev1galaxy.org/viewtopic.php?id=759

I'll put in the slim  theme
As per the link.
I wont change anything other than actual visibility.

^<edit>^^^ done ^^^^^
Copied over from the link.
Changes:
Moved messages to an informative position.
Above the entry box
(Where users eye line is
   (room for any longer messages))

Maybe a white space or two and a comment.

There appears to be no canonical source for themes ???
</edit>
I will also move it under debian/
   so that it only gets installed if there is no previous theme.
   Which means its functionally a failsafe.

See also the config file
  -simpler(ish) to change screen messages there

git (lightweight) tagged Kafka to remove message layout

This is why in the upstream (not devuan not debian) version I will do a visually basic theme that exposes the engine  more.

Not because its pretty or  tasked with branding but so that there is a template to do all that design stuff with.

I have the debian 8+ (?)  examples as well now to look at.
The first observation is that there are too many release specific directories of themes.
2  should be plenty.  We have already dumped all that

They put the instructions greyed out in the entry field. Which is nice.
My thought would be: Icons (generic)  first then text as an adjunct.

But not my call ! (and I don't want or think it should be).
Though I'm so _bad_ with GUI things ... maybe

So I'm looking at the incoming ceres/sid  stuff later today...

With a view to ascii.
(there is not much at all so far that I have seen)

... Butterflys ... I'm seeing butterfys ... and planets ....

News from the **deliberately breaking**  it front:

I have been testing slim with and without
       ** consolekit and dbus **    (they are a team here)

I have consistent enough results.

Which ever way it is done *slim should not get in the way* of _your_
Window or Desktop Manager
logging you out or mounting usb sticks etc.

Rebooting from desktops::
--------------------------------

I have tested this with XFCE at ascii levels of suite / stability.
XFCE does "The Right Thing" [TM] and probably uses *sudo* or something else.
I guess.  I can explore that more later.

The short version is that the desktop menu logout button works with XFCE4 at target ascii
(all the way to reboot at least) It has nothing to do with slim and _quite right too_.

OH bummer.
People shut down computers ?

I really should try the GUI things more often.

Perhaps its the init script includes or something ?
(note for later)

/update

Still easy enough to "fix" now. Just add USE_CONSOLEKIT=yes  (or =1)
Or rather just do a default cmake ../

It does a nice job doing the Right Thing [TM] anyhow.

Hmm should be able to use a "proper" system call > pam  or at least an extern or something.
It needed root password as well ...
consolekit has been depreciated I think ???

[cogitation ]

OK I will put my hand up for this.
I have a passing familiarity with the code base now.
(I am insane)

C++ ((shudder)) OK.

Off to read the code base.

Also GIT ROCKS !!!

I um went a lttle further than I intended with the pretty beetles 

lol who ever _reads the docs _ .

So you did a default cmake ../  ?
rather than 
cmake ../ -DUSE_PAM=yes  -DUSE_CONSOLEKIT=no

?
DOH!
I can get rid of dbus, consolekit and libck-connector0 here come to think of it.
((goes away does much of that. Everything keeps working ))

OK so got rid of consolekit* libck-connector0 --purged
It removed some unneeded gnomeish  stuff.

(and one gst thing I'll get back later)
I could not remove all of the dbus libs as there was a pulse dep lockin that took out most of X ...
[[[later]]]]

However DBUS gone (no system service left) dbus: unrecognized service

Builds fine  I didn't try a default build .
(as above)
Tests fine with :

slim -p /usr/local/share/slim/themes/buggs/

NB local install.