Re: Slim and build settings

Progress . . . congrats. Did you build it with the d1h? Since those with access to the resources to package properly don't come here often, you'll need to contact them on #devuan-dev once you've got it ready to package for ascii.

Re: Slim and build settings

golinux wrote:

Progress . . . congrats. Did you build it with the d1h? Since those with access to the resources to package properly don't come here often, you'll need to contact them on #devuan-dev once you've got it ready to package for ascii.

I'm just walking myself through all that now.Its either that or / and install the ..../debian/patches myself and hope.

(which I don't think is a great idea)

However I think I have exposed some issue with the theme <=> config.Essentially they must be kept in line with definitions for all "exposed" options.

I'm not totally sure yet, but w a l k i n g through the source seems to confirm this.

Anyway next bet is to build deb version and see how unbroken those patches make slim.(an entire executable (screen locker) is suppressed by those patches.)

... and C++ is not my favorite language .. must resist rewrite in C or erlang or perl or bash ;>

Also I have to merge to git.devuan as I branched here and ... sigh ...Its no biggy the web interface does not like it though

So sorry its taking a while to wrangle ME into this.

Finally I let ".ro" badguys into my gateway box and have been sweeping that clean ....

Re: Slim and build settings

golinux wrote:

Progress . . . congrats. Did you build it with the d1h? Since those with access to the resources to package properly don't come here often, you'll need to contact them on #devuan-dev once you've got it ready to package for ascii.

OK it builds with d1h ...e v e n t u a l l y

All works OK as installed from dpkg -i with _its_ confs

Notes TODO etc.

However It still needs better visibility on F1 not hard at all Testing for caps lock etc

slim :My own preferences would include: Dropping requirement for consolekit or dbus these can be run (if available) from the system xsession / xinitrd system per user ... but I guess that would be a bit radical

i.e. It should work with or without either of them.

Higher Priority for me:

Hack until the thing runs with other instances of X runningIt silently fails if I am using :0 or any other "port" for X

Work out why some apps will launch from keyboard and not others when I use it to login

Re: Slim and build settings

I cloned your repo, built the package and installed it. It works! Nice job. The error regarding libpng12-0 that was preventing installation from the repo is gone.

There is a potential problem. The version number you used is already taken. Looking at the changelog, it looks like you did not use the latest version, so there might be some changes that were lost. Although it looks like those changes involved removing the devuan theme and letting desktop-base handle it. I have no idea what should be done about that.

Re: Slim and build settings

You said it didn't have anything to do with that package but I thought maybe it did. I have no idea how Centurion_Dan set slim up at the 11th hour before the stable release. That's who has the answer though.

Re: Slim and build settings

golinux wrote:

You said it didn't have anything to do with that package but I thought maybe it did. I have no idea how Centurion_Dan set slim up at the 11th hour before the stable release. That's who has the answer though.

fsmithred wrote:

The error regarding libpng12-0 that was preventing installation from the repo is gone.

There is a potential problem. The version number you used is already taken. Looking at the changelog, it looks like you did not use the latest version, so there might be some changes that were lost. Although it looks like those changes involved removing the devuan theme and letting desktop-base handle it. I have no idea what should be done about that.

Quite happy to start again all the way from the original source if needs be.I think I understand the concept of having desktop-base installing the theme. Please read on as it _will_ break, unless you turn Devuan into a desktop distro.

Thoughts though: (way toooo many)

1/ I'm probably not _atypical_ in usually doing a minimal install and adding "stuff" as needed.*I still don't have desktop-base installed.* Though sure, I'm not a majority but Desktops are not required (yet). Which explains some confusions ?

2/ Is slim the default official X Display Manager ? I'd vote yes, but assume it is. I'm usually suspect of C++ (opacity) but this is clear enough to grep.. (though WTF most of the header files are trying to say ?)

In which case /usr/share/slim/themes should be installed by slim. and then slim itself Included (required) by one of XFCE or desktop_base ? (or some daisy chain) That way default *Desktop* installs get xfce + slim in devuan themes. The rest of us get a devuan themed X DM which we can break or not.

Its not an issue to leave options disabled in the slim.conf for more minimalist users. I have more or less done that already. Importantly the THEME file has to enable features otherwise "stuff" just doesn't happen. Breakages _may_ lead to no login or no choice of environment, which is DM's primary purpose.

3/ This (my) fork of slim started as an experiment really. I forked from helliken as it seemed to be where most of the theme works was at. I have no cultural memory here ! Which is probably why it works . <== Hellikens worked !

Which leads me to:

4/ How would one choose which fork or _reliably_ tell which is live from the gitlab site ? Is there a better place to nut this out ? Is that what the coloured Letter symbols mean ? I know there is IRC but thats not everyones TZ and is an excellent adjunct.

Re: Slim and build settings

Your gitlab-fu is better than mine. I think I've seen those pages, but I wouldn't know how to find them.

Yes, slim is the default display manager. And desktop-base is installed if you take the default desktop install, which uses a few task-* packages to fill up the installed-packages list.

It looks like the latest version of slim we have is 1.3.6-5+devuan4 in jessie. There's a newer version in stretch - 1.3.6-5.1, but I don't know if it has anything we want (plymouth patches and I forget what else). I tried building a package from the stretch sources, and it worked, but I didn't know how to put the devuan theme into it except to add it after installing slim. I only changed the changelog to give it a unique number. I did not have to change the dependencies, and I don't understand the deps. Specifically, I don't understand why apt complains that slim needs libpng12-0 when it's not listed in the control file.

I agree with you that the theme should be in the slim package. There are lots of people who don't install desktop-base but do use a dm. But I can't say anything about how desktop-base should interact with that. I know that the plan is to make it so that people can easily create and change themes for d-b that will show up at boot, login and desktop. I've avoided d-b ever since spacefun.

find the theme line in /etc/slim.confadd yourname comma,separated or just replace it...days of fun AND you get to keep the default and devuan-foo if it arrivesAND the task-thing will probably overwrite the conf file !(but you will have a backup )FWIW:This task-thing is probably a sane idea. Though it needs to be more carefully implemented !

The Devuan theme login can be assured and consistently debugged.The branding and art folks need only grok that world.Users can flip or even randomise from /etc/slim.conf(if they can admin it)There are still issues with the config file IMHO all of them quite fixable.e.g. The session list should be generated per install from the contents of /usr/share/xsessions(this is not such an ask for pre-install scripts)AND OR the "sessiondir" should be set to that directory.(then the user needs an easy way to set a default Finally the example ~/.xsession should be tidied up and extended to catch dbus users and stuffed in doc/exampes or something, with a note in the config.

(actually it could go system wide in /etc/X11/xsession.d with a moderate amount of work.)

Today I tested the official _stable_ _jessie_ version it can be built without consolkit (or dbus) or even the screenlock thing and with pam only. I have not bothered to fight d1h and its idea of git . Geeze you name a branch zombie and it gets all toey

(or dpkg-buildpkg s)

It works fine here stripped down like that.

(which would reduce the deps list a little as well) If it can't find the deps it just skips that functionality where possible.(for consolekit and pam)

There is a toggle on pam in the CMakefile.txt that allows (1) the screenlocker.So see the INSTALL but -DUSE_CONSOLEKIT=no -DUSE_PAM=yes (check these)No consolekit should mean no dbus as well.

Re: Slim and build settings

So here is the state of slim as seen by me Mon July 20th 2017.A rough report.

Devuan has diverged from Debian, both have diverged from Upstream. _None_ of these changes are major. (Philosophies aside.)

I really do not need (or want) to care about what Debian are doing to Slim, _other than noting_::

that Devuan's sources came from Deb rather than upsteam. - The patch set could be reduced but its not too bad. (I guess) - Devuan could start again from upstream at least as found on github with ONE patch of about 4-8 char in size ! (from memory)

Patching out debian "breakages" is a waste of this distros energy.( So the current devuan gitLAB packages should be the one Devuans' work on until upstream wakes up.)

Upstream does not look too active, though I would be happy to be proven wrong !I baited a line with "documentation" so far no bites.

Policy:: Devuan devs have policed (i.e policy-ed) out the theme directories under the debian/ tree. slim.theme will be set by other modes. I know of no reason that the current slim code default theme could not be replaced / kept and a Devuan default (not release aware) installed instead or as well. (This could be as simple as changing the background.)

The functionalities and depends list seems consistent across all suite/stablity levels.The Devuan devs will wrangle Branding and notably Usablility + Internationalisation .A deduction of sorts ::suites/{jessie,ascii,etc,etc} are about release branding really.suites/unstable (or experimental) is where functionality would be worked on.

I should think a documentation branch or perhaps tag would be useful?(though there is little need for much more beyond a how to ~/.xinitrc or some such and dbus notes)

I have yet to trip over any mention of the slimlock screen locker, but maybe I should look again.

Finally mine which once again you will need to check branches.The only useful thing may be the new dual format Docs or unstable branch. e.g. (docutils (rst) or md which just means being a little careful really)

Re: Slim and build settings

Just for "giggles" and testing

And not for general users I have made no deb for this.

I've started a branch called debugg with - "modernised" docs docutils and markdown friendly all in one file. - Hopefully clearer INSTALL instructions - A new bugg theme to login with - More info in /etc/slim.conf This all builds easily and reliably here of course. YMMV. cmake gives good hints.

You should not need lib-consolekit* or libdbus* If you follow INSTALL subtle clues.(and it don't need no task-desktop-* !)

Re: Slim and build settings

Not only do they shut them down, they do it without the root password! Big fancy desktop environments (that you've heard about ) provide buttons and/or menu entries for this. Whether those work or not in devuan seems to be somewhat of a crap shoot.

There are several threads about it here and it's come up in irc several times. Search forum for some combination of the following keywords:

I know I'm missing something again. Pretty sure there are more than four packages on that list.

If that was you volunteering to maintain slim at the end of you message, THANK YOU! Probably you and Centurion Dan should get together and talk (while I'm asleep) and we can get an installable slim in ascii.