Skype For Linux
Trinity Pullam
Can you even log in?More precisely: can you log in and not immidiately be logged out (what is the average duration between log in and (automatic) log out)? Please, post a screenshot of the entire window.
And you can try clearing the cache, who knows, it might help:
Thanks everyone for the answers, i checked out this page but i cant find how to make skype remember my password, i'm missing something?
EDIT: gnome-keyring asked me if i wanted to remember password when i opened skype
SOLVED THANK YOU GUYS!!
So it looks like the latest version of Skype for Linux (I'm using 8.11.0.4) has a helpful "misfeature". If you close the Skype window, the ui disappears, but Skype does not quit -- there are at least four "skypeforlinux" processes still running.
For the new 2017 version of skype that's impudent enough to add itself to autostart each time it's started (seriously? Never installing it on my own machine) it's enough to create a folder with the same name as a file it's trying to create:
Then, inspired by azeam's suggestion, go to (Xubuntu) Settings > Sessions and Startup > Application Autostart, and remove the item for Skype. I'm not sure if unchecking works; I tried that first, but it may have conflicted with Skype's internal settings when I tried it.
Had the same problem and the following seems to have taken care of it: go to (Xubuntu) Settings > Sessions and Startup > Session, find Skype and left click where it says "If Running" and change it to "Never".
I'm assuming that the next time you actually, intentionally run Skype (I hope, for the sake of your sanity, that this day is far in the future) that it will try to put that file back. In which case you might have to delete it again or scour Skype for the setting that will prevent that behavior.
For regular Ubuntu 16.04, search "Startup Applications". When the window opens, just remove the tick from Skype to prevent it starting at boot, then click remove while you selected Skype to clear it from the list.
Closing Skype is not the same as Quitting Skype. I did three things in Kubuntu 14.04.After Opening Skype I went to Skype(Menu)>Options>General and checked "Start Skype Minimised in System Tray". Then Options>Advanced and unchecked "Check for updates on Startup". Finally, rather than "Sign out" I clicked "Quit" at the bottom of the menu.I believe that it was the final step that did the trick.
The Skype desktop client has, for quite some time now, been admirably behaving itself.....until very recently. The last couple of releases - at least, for me - every time you go to make a call, or try the 'test call', the client promptly re-starts itself!
If anyone has any ideas about why this is happening, I'd love to hear them. I suspected gnome-keyring, initially, because running the client from the terminal throws up no end of messages about "can't find keychain".....but making sure gnome-keyring was installed & functioning in all my Pups hasn't made a scrap of difference. And MyCrudSoft are annoying, because any really critical error messages, they go out of their way to suppress them. Buggers!
Following reports from ozsouth a few months ago about the video & microphone functioning fine in the webapp (web.skype.com) running in Chrome, I decided it was time to do a spot of investigating.
At that time, 'test calls' functioned fine under Chrome, and, naturally enough (as you would expect) in Edge for Linux. In Opera, Iron, Vivaldi, or any of the 'clones', video functionality was completely lacking.
Fast-forward to this morning; just for the hell of it, since I'm in Opera ATM, I thought I'd give it another go, and.....yay! Video/mike functionality is now operational in something other than Chrome/Edge. So I tried some of the others:-
In any of the 'clones', at least, Skype video-calling, in Linux, using the webapp is now a reality. Whether it's to do with the recently-updated version of the webapp - this is always several releases behind the desktop client, and gets updated whenever M$ feel like it! - or whether it's to do with recent changes in the Chromium code-base to support it, I wouldn't like to say. Quite possibly, a bit of both.
.....in any of the 64-bit Puppies. (It's still a 'no-go' in these same browsers where they still support 32-bit, because the desktop client/webapp are written for a 64-bit code-base, I'm afraid.) This is why the webapp & client look identical; the client is Electron-based, meaning it runs under a stripped-back version of Chromium.....well; you get the picture.
You fire-up the webapp in Firefox, everything seems fine. Go into Settings, the Audio/Video subsection is there, and, at first glance, all is tickety-boo. Firefox has only ever accepted mike input from
.....unlike the 'clones', where you can select the input source of your choice. For Firefox, you have to set your source to work with the browser, rather than the browser working with the selected source. This in itself is something Mozilla definitely need to address; automatically 'assuming' you'll set everything up to work with Firefox is a bit arrogant, to my way of thinking.....and not what you would expect from one of the biggest names in the open-source world, given that they're always banging on about 'freedom of choice'..!
(Extra 'brownie' points here for Google & the Chromium project. Love 'em or loathe 'em, you can't deny that Google do go out of their way to make their entire cloud infrastructure extremely easy to work with. Everything just functions as expected.)
Even after ensuring that Firefox is working with the 'default' mike input, you then notice that the 'Test speakers' and 'Test call' buttons are non-existent. Attempting to make a test call from the side-panel results in initial showing of the test-screen.....and after less than 2 seconds, it just quits, and returns to the home screen. No explanation, no error messages.
So; Firefox is a 'no-go' with the web-client. I'm not surprised; I didn't expect Mozilla would have 'unbent' sufficiently to work with those who basically dictate how the 'net runs. It doesn't gel with their philosophy, after all....
Now, I don't quite know what's going on here, boys & girls. Just for the hell of it, I've been trying out the Skype web-client again in a 32-bit Puppy.....specifically, this time, Slimjet-portable in Xenialpup 7.5.
For some strange reason, video-calling - in the current release of Slimjet - is FULLY functional ATM. I'm gobsmacked, and more than a little bemused. The more so, given that the Skype client, being Electron-based, is essentially the web-app running on the desktop.....which has been 64-bit ONLY for a long time. So how 32-bit Slimjet is managing to run it I don't know...
(As expected, once again, Iron will not play ball. The webcam feed will come up, and you can select the audio input source.....but the 'Test speakers' button, and the 'Make a test call' button, are non-functional. I'm not surprised at this.)
Since of the latest updates (within the last two weeks) skypeforlinux stopped working and the only thing I find in the logs is[ 324.575813] traps: skypeforlinux[2487] trap int3 ip:555cb8dab847 sp:7fff797c57b0 error:0 in skypeforlinux[555cb6e96000+5016000].A Google search did not return anything useful, most results deal with an invalid opcode rather than the int3 trap.
So, your skypeforlinux version is 8.51.0.86, the current up-to-date version at this moment - which was released fairly recently. In fact, I have the exact same version on my Debian 10 system, and it works just fine.
But in your case, the int3 is encountered while skypeforlinux is not being run under a debugger, so the int3 trap vector points to a default kernel routine, which is essentially equivalent to sending a SIGTRAP signal to the program.
Why does the skypeforlinux program code include int3 instructions in a production version with no debugger present? Only the people at Microsoft with access to the source code of skypeforlinux could answer that without a significant reverse-engineering effort.
Note that Microsoft only promises that skypeforlinux will work on Ubuntu, Debian, OpenSuSE and Fedora. It could be that this most recent version may have accidentally included some debugging code that only gets executed when some condition does not match any of the supported distributions - and causes Skype to crash because the expected debugging environment is not present.
Just for completeness reason, some may find this useful:web version of Skype is mature enough and works well under google chrome browser, so you do not need to install the application locally to be able to skype. This includes not only chat feature but audio/video calls and screen sharing/recording.
Here's a simple workaround that works. I followed the instructions in this answer and was successfully able to run skypeforlinux on kali linux root's desktop. You would need to create another user e.g user2 for this to work.
Thank you guys. My biggest concern is why a package with invalid GPG key is blocking the installation of other legit updates until I figured what to do with that single one and than I have to re-run the full update again.
Is this behaviour is by design or can it be changed somewhow and leave only the package with the issue uninstalled?
After I disabled GPG check and re-run dnf update all 46 update package gets installed:
The file skypeforlinux-64.rpm downloaded directly into /home/dcat/Downloads directory. Next I switched to the /home/dcat/Downloads directory, and checked to make sure of the file name by starting up mc just to be sure. Making sure I was in the /home/dcat/Downloads directory, I then ran:
So what happened? My GUESS is that TecMint (and other step-by-step copy and paste sites) download GPG Key that that is outdated (Why? I have no idea. ) But by downloading the Skype rpm file directly from M$ you now have the direct corresponding GPG Key that goes with the downloaded file. Now when you run dnf install skypeforlinux-64.rpm everything, including the GPG Key matches so it installs without errors.
d3342ee215