Kubuntu 13.04 Raring Ringtail

[cavedweller]

The best I was able to do with it was to delete kscreenlocker_greet. That would cure the screen locking issue, The problem is then you have to install xscreensaver because kscreensaver doesn't work anymore either because it is part of kscreenlocker.

I finally got so pissed off at it the other night that I deleted it. This is a known issue from KDE upstream and the bug has been given a low priority. I have my wifes running ok on 12.10. If Kde hasn't dealt with it by the time 4.10 rolls down to 12.10 repos, I'll put something else on her's. The only need to have at this time is kmymoney. She uses it for a checking register. I can take an hour and set up gnucash for her which is a little bit of overkill for a check register.

[kubicle]

While waiting for it to be fixed, it could be an option to disable the automatic activation of screensaver (and locker) if you do not wish to lock the desktop?
(This option is not really a good one if you do wish to lock the desktop eventually, but after a longer grace period than 5 minutes...in this case you could set a longer activation time on the screensaver activation, of course)

[james147]

If you don't want the screen locked at all why even have a screen saver? It is far more power efficient to just turn off the screen rather then activating a screen saver (which most of them these days wake up your gpu and end up using more power then just having the screens on...)

[cavedweller]

While waiting for it to be fixed, it could be an option to disable the automatic activation of screensaver (and locker) if you do not wish to lock the desktop?
(This option is not really a good one if you do wish to lock the desktop eventually, but after a longer grace period than 5 minutes...in this case you could set a longer activation time on the screensaver activation, of course)

I've tried the longer activation time and it still does the same thing. I think the bug is that once set it runs it defaults irregardless of the options you may choose. That is the experience I am having with it. I can reset the grace period and have for 15 minutes, but after a 1 minute period..... password requried. It doesn't make any since at all.

Everything works fine as long as I stop with KDE 4.9.4. I can even add the backports and run apt-get update and apt-get upgrade and when I check version it says 4.9.95, but kcreensaver isn't integrated into kscreenlocker. Under setteings it is still screen saver. If I run apt-get dist-upgrade to get all of the 4.9.95 upgrade and kernel upgrades, that is when the cogs gum up. I thought about disabling the backports after upgrade, but then I wouldn't get the other upgrades pertaining to the kernel or 4.9.95. Problem is the way it is all tied together now kscreensaver, kscreenlocker, power management, and ksmserver from what I have been reading are all tied together. So not sure where the qlitch lies.

I could stick with 4.9.4. Just one little problem the touch of autism I have doesn't quite allow me to do that. I know it is out there so I have to keep messing with it.:lol:

[cavedweller]

If you don't want the screen locked at all why even have a screen saver? It is far more power efficient to just turn off the screen rather then activating a screen saver (which most of them these days wake up your gpu and end up using more power then just having the screens on...)

I prefer black screen. If you clean install that is your only option unless you install the screensavers. The catch is that if you look under system setting and power management, guess what you find? Screen locker has been integrated there as well, and once messed with.....password required.

[kubicle]

I've tried the longer activation time and it still does the same thing. I think the bug is that once set it runs it defaults irregardless of the options you may choose. That is the experience I am having with it. I can reset the grace period and have for 15 minutes, but after a 1 minute period..... password requried. It doesn't make any since at all.

Yes, currently the maximum grace period seems to be 5 minutes, but I meant setting a longer time in screen saver activation (which effectively delays the locking by the same time [if you set the activation time to 20 minutes the screen will lock after 20+ minutes of inactivity]...or alternatively disable automatic activation of screen saver altogether, which then doesn't lock the screen at all)...this is just a workaround waiting it to be fixed, of course, not a permanent solution.

You can also blank screen with xset (this is actually what I do on one of machines that I don't need to lock based on activity...I've never been a fan of "screensavers"). On this setup, I have disabled automatic activation of screen saver in systemsettings, and use xset to set screen blanking in 10 minutes (you can also use xset to control DPMS settings, that is monitor standby,suspend or off at designated time intervals)...this machine blanks the screen nicely after 10 minutes and doesn't lock the screen.

Kscreenlocker is bugged since it doesn't work as expected in this regard, but I'm sure it will get fixed eventually. Kscreenlocker is new and regressions are fairly common in new software (especially pre-release software).

[kubicle]

Out of curiosity, I looked at the source code (kde-workspace/ksmserver/screenlocker/ksldapp.cpp), and the screenlocker doesn't read the "Lock" boolean key from kscreensaverrc (or use the value anywhere to inhibit screen locking, even though the setting can be ticked/unticked in systemsettings)...and the lock grace period is limited to 5 mins as suspected:

    m_lockGrace = KScreenSaverSettings::lockGrace();
    if (m_lockGrace < 0) {
        m_lockGrace = 0;
    } else if (m_lockGrace > 300000) {
        m_lockGrace = 300000; // 5 minutes, keep the value sane
    }

The latter is clearly by design, but the former is a bug...if there is a configuration setting to require a password or not...it should be read/used.

[OneLine]

RC testing

http://www.sharpley.org.uk/blog/
--> http://www.sharpley.org.uk/blog/rc-2-testing

KDE 4.10-RC2 Testing

With the second RC of KDE4.2 just released, now is a really important time to get involved in testing KDE 4.10.

During this release, due to changes based on feedback, two areas of KDE have undergone a significant change between Release Candidate 1 and 2. This isn't typical, so to ensure the final release goes as smoothly as possible an extra release candidate is going to be created. This will delay the KDE 4.10 release, but it does help ensure that KDE 4.10 is the best ever...

https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
--> https://lists.ubuntu.com/archives/ku...er/006565.html

KDE 4.10 release schedule changes, was: We are having RC3...

More links: http://www.kubuntuforums.net/showthr...l=1#post317323

[cavedweller]

Out of curiosity, I looked at the source code (kde-workspace/ksmserver/screenlocker/ksldapp.cpp), and the screenlocker doesn't read the "Lock" boolean key from kscreensaverrc (or use the value anywhere to inhibit screen locking, even though the setting can be ticked/unticked in systemsettings)...and the lock grace period is limited to 5 mins as suspected:

    m_lockGrace = KScreenSaverSettings::lockGrace();
    if (m_lockGrace < 0) {
        m_lockGrace = 0;
    } else if (m_lockGrace > 300000) {
        m_lockGrace = 300000; // 5 minutes, keep the value sane
    }

The latter is clearly by design, but the former is a bug...if there is a configuration setting to require a password or not...it should be read/used.

I am currently reloading my entire system. I needed a small install of Windows 7 to prepare my taxes on. I tried vmware player and above 4.0.5 and the program crashed. So I decided to re install my system with 3 OS's on it. A 50 GB partition for Windows to do taxes and any thing left from work so I can avoid bringing my work laptop in every day. I know that is lazy, but I get tired of unlocking it out of the desk in my work truck.

I figured I would split the rest of the drive between Kubuntu and Siduction. That way I can continue to work through my issues with both distros and still have the other to get the have to's done. I may just pick up another laptop in March to use for linux and throw this one on the desk for work and finances.

[wakeup]

Hello,

Do you recommend installing 32-bit Kubuntu into 64-bit system? I am not sure if it is possible, but if it is, I saw that compiling sources is easier in 32-bit version comparing to 64-bit one.

And what will be my loss by installing 32 bit into 64 bit system?

Thanks.

[james147]

Hello,

Do you recommend installing 32-bit Kubuntu into 64-bit system? I am not sure if it is possible, but if it is, I saw that compiling sources is easier in 32-bit version comparing to 64-bit one.

And what will be my loss by installing 32 bit into 64 bit system?

Thanks.

I do not recommend it... there is very little point in using 32bit on 64bit computers these days. You can do it though. Compiling source is just as easy on 64bit as it is on 32bit (might even be a little faster on 64bit). You might lose a bit of speed compared to 64bit, you will also be restricted to 3-4GB of ram under 32bit (unless you have a pae kernel, at which point only applications are restricted to this limit).

[wakeup]

I do not recommend it... there is very little point in using 32bit on 64bit computers these days. You can do it though. Compiling source is just as easy on 64bit as it is on 32bit (might even be a little faster on 64bit). You might lose a bit of speed compared to 64bit, you will also be restricted to 3-4GB of ram under 32bit (unless you have a pae kernel, at which point only applications are restricted to this limit).

Thank you for answer.

I saw on some website (currently I dont remember, but will post if I find it) we need to include extra parameters to build from source, that was why I asked...

[james147]

Thank you for answer.

I saw on some website (currently I dont remember, but will post if I find it) we need to include extra parameters to build from source, that was why I asked...

Don't know where you read that but I have never needed to. But it entirely depends on what you are building. Any project based on auto-tools (configured with ./configure), cmake or qmake do not need extra options (hell, I don't even think raw gcc does).

If you want to compile for 32bit on 64bit then it gets a bit more tricky (called cross compiling) but you don't generally need to do this.

[oshunluvr]

Is anybody able to install 13.04 outside of a VM? It seems there's a bug in Ubiquity that stops it at partition detection.

I guess I could install it to a VM, image the drive, copy the files to a subvolume, and maybe boot that.

[dequire]

I'm running Raring on metal. Not sure if it matters but I installed from a daily build image prior to the Alpha 1 release.

Is anybody able to install 13.04 outside of a VM? It seems there's a bug in Ubiquity that stops it at partition detection.

I guess I could install it to a VM, image the drive, copy the files to a subvolume, and maybe boot that.