In that case, please feel free to contribute something useful (something other than your usual snarking) to this thread. No one is perfect but in terms of contributions at LQ discussions, DV leaves you in the dust.

chris

1 members found this post helpful.

Considering it was in a discussion with the OP, is relevant to the use of Skype and was a continuation of an earlier suggestion, it may behoove you to review threads before taking things personally. Obviously, DV did not see the post as snarky or not contributing, given the content of his reply to my post and he obviously understood the content/meaning/intention of my post.

Lighten up.

The SIP protocol is properly standardardized and there are no lack of clients to use it.

1 members found this post helpful.

In the linux kernel 65334 is the uid and gid number for overflows. See 'cat /proc/sys/fs/overflowuid' and 'cat /proc/sys/fs/overflowgid'. It is used by the kernel for subsystems which only support 16-bit IDs where an ID is encountered of greater than 65535. (In 16-bit two's complement it is -2.)

Some distributions map the nobody user and group to it: see https://lwn.net/Articles/695526/ for some discussion about that. logind and elogind synthesize nobody on UID/GID 65334 and report a mismatch when compiling if the local system has it on another number.

If you wanted to solve the warning, one answer is specify in /etc/passwd and /etc/group that ID 99 is for oldnobody and 65534 for nobody: that would prevent any files being unreachable. But the best thing is to ignore it. It almost certainly makes no difference in relation to skype or anything else you are going to meet in practice.

3 members found this post helpful.

A problem with this approach is that skype cannot then be started from the Applications->Internet (xfce) menu as an ordinary user; the script's command 'sudo -b /lib/elogind/elogind &' needs a command line to enter the user's password.

Maybe someone who knows how could write a .policy file so that the script could launch elogind using pkexec, which would pop up a dialog box to ask for a password. Ideally it should work with the user's password (like sudo) rather than root password. Any takers?

chris

Edit: I just tried it with gksudo (from SBo's gksu package) rather than plain sudo and that seems to work OK. It's one more thing to have to install though, so if we could make pkexec work like sudo it would still be preferable.

Yep. I worked in that space for years at Nortel.

The only drawback is when you want to talk to an old-style landline or other non-SIP endpoints. ¯\_(ツ)_/¯

I don't use skype so I'm not going to try, but it should also work with kdesu, in which case there's nothing additional to install (assuming a full Slackware installation).

I see you guys are advanced with elogind thing. I'm facing the same problem as the OP: no skype version works on -current anymore. I've been using skype rpm (after rpm2tgz) for years, but this is not an option anymore. Official snap never worked on Slackware, so it's not an option too.

I then ditched skype client out of my box and have been using skype web ever since. It works pretty nice even for audio and video calls. It has the drawback to keep a browser window open to interact with my skype contacts, but this proven to be a nice thing at the end as I can be online there only when I need to.

Maybe this could be a workaround while skype client complain in Slackware-current.

2 members found this post helpful.

Searching for skype for linux 8.30.0.50 gives few returns

https://answers.microsoft.com/en-us/...6-7a98dd285ee5

I would suggest that all Slackware Skype users open a new topic with microsoft support online, to make this issue more visible with their engineers.
It would not be hard for them to do as KDE and others have done before: accept ConsoleKit2's implementation of the dbus logind API and add support for it. This would take only a couple of lines of code.
See for instance how KWin does it: https://github.com/KDE/kwin/blob/9ad...logind.cpp#L66

5 members found this post helpful.

Good idea!

Here is the topic:
https://answers.microsoft.com/en-us/...=1537872777097

Hope you don't mind that i took most of what you mentioned.

4 members found this post helpful.

Thanks for the information, that was interesting reading. Always learning things. As you have suggested I'm choosing to ignore it. I thought about "fixing" it when I first encounter the warning but, decided not to mostly as that link pointed out possible problems. I figure if it needed "fixing" our BDFL would be the one to do that.

I actually got two warnings, adding '-Dnobody-group=nogroup' to the build fix this error.
The output of meson setup gives these two messages. Just before the warning messages.

I can start skype via the (plasma) menu as a normal user.

I added an entry to sudoers to allow chris to run '/lib/elogind/elogind &' and 'killall elogind' with no password.
I could easily modify sudoer for other users.

A full install is a good assumption with me, with Ktown installed. <grin>

It does work with kdesu. There are issues. It's not seamless. A few seconds after the kdesu dialog appears, the skype window starts and covers up the password prompt dialog. Skype starts without elogind. It is eventually started after the password is entered and skype does not complain. Just annoying to have to click in the kdesu dialog to get it on tip again.

Then there is the killall after skype is closed, really don't like the idea of prompting for root password again.

I did try using 'wait' in the wrapper script thinking kdesu would die after passing the command to start elogind, but kdesu does not die, wait isn't going to work. I could use 'sleep' to delay long enough to enter the password but I'm fine with my solution. No prompts, elogind starts before skype and is kill after skype is exited. I just noticed skype is reported a new version... maybe we will get lucky.

Edit: Nope on the lucky. 8.31.76.93 still needs elogind.

I use elogind as a traditional package, build after the SlackBuild I attached in a previous post. It works, and the Skype works like a charm too.

However, I noticed that elogind hijacked the computer power button, and now it execute right on the shutdown. Well, an eventual behavior like this was expected.

To note that by Plasma5 it was configured on Power Management to execute "Suspend"

The funny part is that a friend of mine, using slackware-curent and Plasma5 on a laptop, and who previously lamented of having issues with the LID (closing the display on laptop) which supposedly should go "Suspend", now using my elogind build to save his Skype, resulted also on his LID working fine now.

So, apparently elogind do its job better than ConsoleKit2. In fact, that's expected, because looks like everyone uses logind, either natively (from systemd) or as a cut away elogind. Then it is much better tested than that stray ConsoleKit, who nobody uses excluding us.

So, I will ask our friend Eric, IF is trivial to switch between ConsoleKit2 and elogind - and apparently the sole major distribution using today ConsoleKit2 instead of systemd or elogind is Slackware,

WHY we use ConsoleKit2 instead of elogind? And WHY we do NOT switched already to elogind too, as any other "systemd-free" distribution?

Heck, even the Devuan which forked Debian because systemd-hate politics uses elogind.