The officially official Devuan Forum!

You are not logged in.

#1 Re: Off-topic » you-get is a youtube-dl-like downloader for a lot of sites » 2018-08-15 01:02:06

Installed with pip3 and it works a treat.
Thanks for the tip.

#2 Re: Hardware & System Configuration » [SOLVED] policykit-1 0.105-15~deb8u3 requires libpam-systemd » 2018-08-03 00:43:02

Nice work devuan team smile
You chaps should make most other distros blush.


dev-1-dash-1 please let us all know how it goes.

#3 Re: Hardware & System Configuration » [SOLVED] policykit-1 0.105-15~deb8u3 requires libpam-systemd » 2018-08-02 23:14:06

apt show libpam-elogind
N: Unable to locate package libpam-elogind
N: Unable to locate package libpam-elogind
E: No packages found

Therefore I can not follow this advice:

So _perhaps_ try  installing that, and then attempting the upgrade. ?

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/

For this.
 

IMPORTANT NOTE: auto.mirror is now deprecated and will be decomissioned. Please make sure you have the latest devuan-keyring package with apt-get install devuan-keyring and then point your /etc/apt/sources.list to deb.devuan.org.

Devuan 2.0.0 ASCII (stable)

deb http://deb.devuan.org/merged ascii          main
deb http://deb.devuan.org/merged ascii-updates  main
deb http://deb.devuan.org/merged ascii-security main

#4 Re: Hardware & System Configuration » [SOLVED] policykit-1 0.105-15~deb8u3 requires libpam-systemd » 2018-08-02 15:57:47

$ apt-cache showpkg libpam-systemd

Package: libpam-systemd

// lots of reverse depends //

? However the very last line may be a clue ?

Reverse Provides:
libpam-elogind 234.4-2 (= )

So _perhaps_ try  installing that, and then attempting the upgrade. ?

#5 Re: Documentation » Local Mirror Package Caching using approx and xinetd » 2018-08-02 02:48:45

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

#6 Re: Other Issues » No mail out: hostname inconsistent » 2018-07-31 04:08:39

I quite possibly don't understand how you get your hostname  or mailname ....
The empty <>
(return / from / reply ) all not useful or this mail is going nowhere bat signal..

Is correct.

aside:
A MTA (mail server) should refuse to accept such a thing ... so you get the mail bounced back.

Here are some ?reasonable?  guesses and hints

1.  setting the formal system mail name in
               

 /etc/mailname

guess: 
$HOSTNAME.frontier.com

(you will know the real name)

2. set mutts (from) email variable

export EMAIL=you@yours.on.net

see the mutt config stuff later / last in this message.
 

More Waffle::
An email _requires_  a  complete header called  From:
 
Either mutt is configured to use some  You@DOMAIN.foo
(per MUTT mail account???? )

Or it  looks it up in /etc/mailname
or
It constructs one from your login and  hostname

or

It hands that problem to mail or sendmail

A quick look at man mutt seems to indicate that it can use "sendmail" or "xmail"
which would hint that it has a reasonable chance of honoring the /etc/mailname file.

Next ::
Gather some data and hints

Test your system sends ::

$ cat  /etc/devuan_version  | mail -v  -s "A test Mail"  haines@localhost haines-external@the.real.internet.net

which is assuming you have "/usr/bin/mail" onboard.

(( cat whatever Text file you feel comfortable ending up at your ISP admins account smile .))

Test your "sendmail"   (which will probably be exim4 or postfix providing the sendmail command as an alias)

 cat /etc/hosts | /usr/sbin/sendmail ${USER}@localhost 

see also:
((Every sane Mail Transfer Agent reads this:))

/etc/aliases 

This NEXT is where you can set different  "home mail domains" per user.
(it may be exim4 specific ?)

/etc/email-addresses
If its there it has instructions in it ... but

 
#This file contains email addresses to use for outgoing mail. Any local
# part not in here will be qualified by the system domain as normal.
#
# It should contain lines of the form:
#
#user: someone@isp.com
#otheruser: someoneelse@anotherisp.com

root: you@some.place

Finally I would suggest that there would be a way to tell mutt your mail domain for external mail (per mail account) .

I found this is the muttrc manual

 from
              Type: e-mail address
              Default: ""

              When set, this variable contains a default from address.  It can
              be  overridden using "my_hdr" (including from a "send-hook") and
              $reverse_name.  This variable is ignored if $use_from is unset.

              This setting defaults to the contents of the  environment  vari-
              able $EMAIL.

So I tried the easy way smile

$export EMAIL=anotheremail@another.place.net
$mutt
press m 
          compose mail
press y
(wait a moment or three)

check new mail 

press q

I rarely use mutt anymore.

Though it is still an excellent Mail User Agent .


Hopefully this was some help and not too confusing.

#7 Re: Documentation » Local Mirror Package Caching using approx and xinetd » 2018-07-30 03:25:43

golinux wrote:
PeteGozz wrote:

Hi
Um yeah lost my password smile

For future reference . . . all you have to do is ping one of the admins to get a new one.

PeteGozz wrote:

Thought I would/should contribute some tested configs I have here.
The spin offs just from this one could probably fill a small book.

Your contributions are always welcome.  Don't be a stranger . . .

I will try not to be.

#8 Re: Documentation » Local Mirror Package Caching using approx and xinetd » 2018-07-30 01:10:39

Hi
Um yeah lost my password smile

Thought I would/should contribute some tested configs I have here.
The spin offs just from this one could probably fill a small book.

#9 Re: Documentation » Local Mirror Package Caching using approx and xinetd » 2018-07-30 01:01:19

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)

#10 Documentation » Local Mirror Package Caching using approx and xinetd » 2018-07-30 00:55:38

PeteGozz
Replies: 6

This Walk through documents setting up a HTTP based proxy using
*approx_ and xinetd_*.


Features of this approach include::

  - Reliable and _low_ maintenance
  - Small and light
  - efficient enough for enterprise level deployment.
    Should scale up to 100's of LAN clients including virtuals
    (depends on hardware and bandwidth)

  - Tunable access by network space and optionally time of day. (xinetd)
    No need to worry your iptables or other filtering.
  - Tunable system loads. (xinetd)
   
  - A simply structured *pool based mirror*  under /var/cache/approx  (default).
  - Readily and cleanly supports other Debian type systems
    and 3rd party repositories
 
  - Low standby resource demand (xinetd)
  - Fast start up and shutdown. (xinetd)

  - Logs flexibly. To file or syslog. ( approx and / or xinetd )

  - flexible client side configurations

Downsides::

  - For simple use its easier to modify the clients apt sources.list (s)
  - NOT a single apt install (and walk away)
  - _You_ have to create a new config file for xinetd
 

The Process ::

With *minimal examples*  (for some version of clarity.)

_All network addressing / names etc will need to be adapted to your LAN_.
(so don't just cut and paste)

# apt-get install xinetd approx

1. edit the servers /etc/approx/approx.conf
     (this is a minimal example)
::
   

devuan http://deb.devuan.org/merged 


2. edit a clients /etc/apt/sources.list.d/01-stable.list
    (? disable the rest while you test ?)
    *The client can be the same machine as the server.*
   
::
   

deb http://10.1.1.10:9999/devuan stable  main contrib non-free

3. create xinetd approx service description  file at ::
 
  /etc/xinetd.d/approx

A somewhat more than minimal example.
   
::

   # /etc/xinetd.d/approx
    service approx
    {
    id           = approx
    disable      = no
    bind         = 10.1.1.10    
    port         = 9999
    only_from    = 127.0.0.1/8 10.1.1.1/8 
    protocol     = tcp
    socket_type  = stream
    wait         = no
    user         = approx
    server       = /usr/sbin/approx
    }

4. Restart xinetd

::
   

root@yours~#  /etc/init.d/xinetd  restart

                      (or)

   root@yours~#  service xinetd restart

check xinetd has enabled your new service ::

   

you@yours~$  netstat -tan | grep 9999

   
A simple test if you have netcat onboard.

   

you@yours~$  nc 10.1.1.10 9999

        "get foo"

        HTTP/1.1 400 Bad Request
        Server: approx/5.10 Ocamlnet/4.1.2

(yes that *nc get*  is deliberately broken)

   

 you@yours~$  CTL c 

    to close the "conversation".

5. check default logging (and any errors like the one above)

::

  $ tail -f /var/log/daemonlog

something like: *Nethttpd: Bad request line*

6. simple test from the configured client

::
   

# apt-get update


Operations::

    see:    /var/cache/approx/     (your new pool(s) of packages)
    see:   /var/log/daemon.log    (default logging)
    see:   service xinetd status

References::

    see:  /usr/share/doc/approx/examples
    see:  /usr/share/doc/xinetd/examples
    $ apropos approx
    $ apropos xinetd

Longer Verbose version at::

https://wombatsandemus.blogspot.com/201 … -with.html
(yeah sorry)

ASIDE::

Basic testing and checking of the approx-import tool  seems to be OK.
As do the devuan "passthroughs to debian"  at the repository.

Though this requires another doc or two.

#11 Re: Desktop and Multimedia » Slim and build settings » 2017-08-14 01:08:52

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. smile
It doesn't even allow you to select a locale  TZ or alternative set of languages.

#12 Re: Devuan » What can I expect regarding MTA, the mail command, cron? » 2017-07-29 13:20:41

Hi ajhlinuxuser,
I totally agree with you.
Its just that sort of "thing" that had me stop recommending Ubuntu or Redhat years ago.
Debian has joined the flocks of zombie seagulls squarking around some "market driven" bag of grey clammy lowest common denominator chips...

Devuan aims only to be "Debian with no systemd" though it's not, and never going to be, that simple.

I would be a little saddened but not at all surprised if some version of of Debians X and Architecture plans found its way here as well. 

So you should not be dependant on upstream to decide on your installed package set.

I keep a mental list of a set of packages I need and it grows smaller not larger as time goes by.

In the mail command case there are a few options ... they all work fine with some slight differences. mailx works for me but there are others that are just fine.
update-alternatives  has this at the moment.

/etc/alternatives/mail -> /usr/bin/bsd-mailx

Also exim4 supports all the traditional "sendmail" commands.
including :

sendmail -i 
is actually:

 /usr/sbin/exim4 -i <recipient-address(es)>
         <message content, including all the header lines>
         CTRL-D

       The  -i  option prevents a line containing just a dot from terminating
       the message. Only an end-of-file (generated by typing  CTRL-D  if  the
       input is from a terminal) does so.

see: man 8 sendmail

This also applies to other MTA's postfix for example.

#13 Re: Desktop and Multimedia » [SOLVED] XFCE (Really Xorg) Max Resolution Problem » 2017-07-29 02:06:36

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.

#14 Re: Desktop and Multimedia » Slim and build settings » 2017-07-23 11:27:10

Updates:
UP stream fork at git hub has useful updates

https://github.com/PeteGozz/slim

- *new distro _agnostic_  "xamplar"  theme*
        + clearer THEME / INSTALL docs
        + tested slim.theme (example) file.
    - More examples and comments and tidy of the system conf file.
      (some of those already on Devuans git-lab)

       A simple minimal panel (which can be made smaller).
       (some silly colour examples to expose theming a little more)

    - designed to work with centred backgrounds and colour
       
    -  basic alpha level support for slimlock in themes and conf file

        + rough and barely tested but it does lock your screen
           which requires password access.
   - New *hints* messages so that we can more nicely say"press F1" (configurable)
      ((this is working now to a *solid beta* level))
   -  runs into slimlock interface "bugs" though ... I will look at that soonish.
     - Exposes other (optional) messaging functionality like Welcome to %hostname

Some of these thing  I will merge into the Devuan GitLAB version
   For packaging tests etc.

The INSTALL file should get you on your way.

#15 Re: Desktop and Multimedia » Disabling display manager -- slim? » 2017-07-21 04:45:08

Count_Cucaracha wrote:

I don't need to have a gdm so I want to disable and remove it. Is that easy to do? I don't want to try too much and make the system unusable.

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

usage: update-rc.d [-n] [-f] <basename> remove
       update-rc.d [-n] [-f] <basename> defaults
       update-rc.d [-n] <basename> disable|enable [S|2|3|4|5]
        -n: not really
        -f: force


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

#16 Re: Documentation » Using d1h (a.k.a. "Devuan packaging made easier") » 2017-07-20 13:48:11

evilham wrote:

Since installing d1h requires adding experimental to sources.list, there should be a step about pkg pinning, something like:

In order not to upgrade your whole system to experimental, add a file /etc/apt/preferences.d/stay-on-ascii
with following content:

Package: *
Pin: release a=ascii
Pin-Priority: 900

Package: *
Pin: release a=experimental
Pin-Priority: 500

Its not a bad idea.
dist-upgrade _will_ go there if it needs to.
(guess it depends what you have from experimental)

Doesn't seem to break anything.

Wouldn't hurt to check your default release (if any) in /etc/apt/apt.conf.d/*
(even when set to jessie I was getting stuff auto included from experimental)

#17 Re: Documentation » Using d1h (a.k.a. "Devuan packaging made easier") » 2017-07-20 01:26:07

ghaverla wrote:

Some Debian packages have man pages written by Debian maintainers, as the parent package had no man page.  This I believe happens with some Perl modules in Debian packaging.  It might make sense to replace those kinds of man pages.  But, it is easy enough to have POD in Perl code to produce a man page.  The source of that man page, is the product of the original author(s), and I don't think should be replaced.  To provide extra documentation for those packages, would be something added by Devuan.  So having some guidance as to what to call it, and where to place it in the filesystem would be useful.

2Cents::

/usr/share/doc/PKGNAME/
   
internally.deb something approximating::
      debian/PACKAGE.docs 
      debian/PACKAGE.example

though::

In some cases it is totally appropriate to add extra man pages
and ref them from the footer of the original.

e.g.
    exim4 has a page that captures its many config files and extensions

In others (depending on how you "call" the program) by extension.

e.g
    git  has a man page for  many (sub) command

However python and perl have foo-doc commands.
(as YOUR probably aware)

So maybe they can be made spit man pages ?
As they already have a doc formatting system ... docutils > rst >
so in python like worlds ::
rst2man - generate unix manpages from reStructured text
(which is my personal favourite)

Given perls awesome legendary text handling ....

#18 Re: Desktop and Multimedia » Slim and build settings » 2017-07-19 15:16:53

All done and hand quilted

Which of course means that there are build issues with the package.

quilt push -a   AOK

dpkg-source --commit     not so much .

So normal really.

I look again with fresh eyes tomorrow.

So anyway a test build or three I did went well enough
(except for the /etc/slim.conf file)
But hand edits made that all work
essentially it falls over to failsafe OK

This now should be "f i x e d"  will see tomorrow.

#19 Re: Desktop and Multimedia » Slim and build settings » 2017-07-19 02:35:53

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

#20 Re: Desktop and Multimedia » Slim and build settings » 2017-07-18 16:59:03

This is a snapshot of a test of what I'm proposing as the failsafe theme.
Its essentially purpy with some tweaks to message positioning and higher contrast font colours.

https://drive.google.com/file/d/0B6DOd- … sp=sharing

There are configure file changes.
I also need to detect if the desktop set is in place at install time.
(and not set this in the configure file or even not install it ...?)

I have not built a working deb yet.

(there may be quilt patch issues)

https://git.devuan.org/PeteGozz/slim/tree/tribulate0

#21 Re: Desktop and Multimedia » Slim and build settings » 2017-07-17 00:57:28

golinux wrote:

Positioning items on the slim screen is challenging to say the least.  You have my sympathy.  That's why the layout is currently so sparse.

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 smile

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 smile

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 .... smile

#22 Re: Desktop and Multimedia » Slim and build settings » 2017-07-17 00:12:08

Oh man GUI design stuff.

Now there is a bucket of spiders I don't want to upturn !

#23 Re: Desktop and Multimedia » Slim and build settings » 2017-07-16 11:42:11

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_.

Slim Functionality::

With a standard package install.                |                Built without consolekit (and dbus)
Which includes xconsolekit and dbus                           But with default /etc/slim.conf

     F1  > lists available X sessions                              Does NOT list ... as is. [later]
                                                                                set up YOUR ~/.xinitrc
                                                                                for anything other than default.
                    see #26
--------------------------------------------------------------------------------------------------------
     F11 > screenshots to /root/scrot.png        |       Depends on what YOU have installed
              (which is reconfigurable)               |       Same root dir "issue" with Screenshots
------------------------------------------------------------------------------------------------   
    type -  exit                                           |                exits
                                                              |           to tty console           
           drops you to a linux console / tty.      |
           This "kills" the running slim instance   |

------------------------------------------------------------------------------------------------

    type - halt                                          |                halts
           halt >> root pass                         |       asks: shutdown -h now
          shutdown -h now
          Do not pass GO

------------------------------------------------------------------------------------------------
     
    type -  reboot                                                     reboots
        and root pass                                        asks: shutdown -r now
        as advertised .
-------------------------------------------------------------------------------------------------       

   type - console                                  |          login to on screen Xterm
       login to xconsole (xterm)               |                a simple X session
       "exit" from that =>
       returns you to slim.
      NOTE mouse behaviour. (focus terminal)

#24 Re: Desktop and Multimedia » Slim and build settings » 2017-07-12 04:41:29

Rather than not remember to keep the ~/xinitrc script example up to date,
see:

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

** the latest version should be on the tribulate0 branch **
But others if different may suite better.

It should be self explanatory.
(well it has comments)

The **new functionality** is that the script (rather than slim)
can get you logged in and GUIed up with or without slims dbus and consolekit* status.
It also sets _your_ default which is just that.
The default /etc/slim.conf should be OK as it is.

Essentially (for now), if slim was built with consolekit and dbus
           then _they_ _have_ to be available.

If **system dbus** is not running::
    slim _will_ actually startup and wait for a login
    but when it tries to create YOUR session
    it will fail (as it can't find the system dbus socket)
    and hang on a black screen.
    /var/log/slim.log will say so as well.
 
so::
     

sudo service dbus restart 

    (or your preferred incantations)


If Slim can not find consolekit::

    Slim will behave precisely as though you can never type your password correctly
                                     (or username)
   i.e. You will keep coming back to the login screen.

   
   There may be other states that have this behaviour.
   This is probably consolekit not connecting to PAM services.
   Or even an xauth issue... (in some cases)

There are a minimum of two libs involved.

So check with::

   

 $ apt-cache show slim 

Forcing a re-install of slim _should_ make apt  go get the dependencies
slim needs if they are missing.

     

$ apt-get install slim --reinstall -t jessie  

     (or ascii)

(you will know if its any suite else right ?)

#25 Re: Desktop and Multimedia » Slim and build settings » 2017-07-11 15:47:49

fsmithred wrote:

consolekit is needed for shutdown and reboot buttons to work. This has been a recurring issue since about when we started on this path a couple years ago.

OH bummer.
People shut down computers ?

I really should try the GUI things more often.

me wrote:

update:
Just tested this here from a local install
started from console under sudo.

$ sudo slim -d

Both halt and reboot worked fine.
(with roots password)
and exit dropped me back to console tty no worries.

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 !!!

Board footer

Forum Software