Aug 022017
 

Hi everyone,

 

I’ve started to put my trusted approach to seamless openSUSE upgrades into an easy to use shell script.

The script operates under a few assumptions (yes I know, assume makes an ass out of you and me), but what can you do, except calling them prerequisites:

  • Your system has all the latest updates applied according to your current repository setup (run “zypper patch; zypper dup” until there is nothing left to install)
  • All enabled repositories have priorities set that make it crystal clear which of them are preferred over which in case a package appears in more than one repo
  • All enabled repositories also exist for the target version, and use a repository URL that has that version number in it, and where the version number is the only difference between versions (this should usually be true for repositories from OBS and/or packman, buy YMMV)

If all this is true, running the script will create a backup of your current repository structure under /etc/zypp/repos.d_(current_version), and a repo setup for the target version under /etc/zypp/repos.d_(target_version), and then link the new structure to /etc/zypp/repos.d, and after that it will clean zyppers cache, refresh all repositories, and tell you the commands to execute to actually run the upgrade.

You might want to do those commands inside a screen session. You have been warned.

This script is provided with no warranty at all. Use it at your own risk. If you break things you get to keep the pieces.

If by any chance your root filesystem is on either LVM or btrfs, do a snapshot before you start upgrading your system.

Download the script here: leapup.tar.xz

So far I have used this script on two desktop systems which each use 20++ different repositories from OBS and packman, and no problems (aside from a few glitches in 42.3 that are connected to the nvidia drivers, but not to this upgrade process).

 

Update: in the last 4 days I updated five different machines using my script: my desktop computer which runs with 23 different repositories from OBS, my laptop and my work laptop which both run with 25 repos, my cloud host which runs with 10 repositories and my internal server/firewall which also runs with 10 repositories… no problems so far.

 Posted by at 11:57
May 312014
 

In my never ending story for single sign on on KDE4 the last post I had was this one.

There was just one little problem with that method: It stopped working when KDE 4.13 came around…

Now there is a new candidate for solving this, and it works just fine so far.

At this point all I can say is that anyone interested should read this blog post, and that the pam_kwallet package in my OBS project has been updated to the code in that post.

Have a lot of fun!

Dec 282013
 

Seeing that there are only two more weeks until openSUSE 12.2 reaches end of life, I’m doing my usual upgrade with zypper.

If you are about to say “didn’t you do that already some months ago“, that was a virtual machine…now it’s my “production” system. Let’s hope all goes as well as it did on the VM.

So far all is looking good, but 4500 packages takes some time, so I can’t really say anything yet. I’m doing 12.2 -> 12.3 and KDE 4.11 -> KDE 4.12 at the same time, so it might get a bit hairy at some point.

The fun part comes next week… if this goes well I’ll do the same to my wife’s laptop, where a failure will be way more painful…

 

Update: finished, all seems to be working fine.

Oct 262013
 

…at least with KDE4 on openSUSE 12.2.

In a previous post I mentioned that there are single-sign-on methods available for KDE to open the wallet right on login, but they do not work when you’re using NIS accounts.

Turns out they do work after all, you just need make sure that the references to the pam_kwallet module is after pam_unix2.so in common-auth, like this:

#%PAM-1.0
#
# This file is autogenerated by pam-config. All changes
# will be overwritten.
#
# Authentication-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
auth required pam_env.so
auth required pam_unix2.so
auth optional pam_kwalletopener.so use_first_pass
auth optional pam_gnome_keyring.so

After this, you just add the two modules pam_dbus_launch and pam_kwallet in common-session like this (pam_dbus_launch needs to be before pam_systemd, and pam_kwallet at the end):

#%PAM-1.0
#
# This file is autogenerated by pam-config. All changes
# will be overwritten.
#
# Session-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of sessions of *any* kind (both interactive and
# non-interactive
#
session required        pam_limits.so
session required        pam_unix2.so
session optional        pam_umask.so
session optional        pam_dbus_launch.so dbus-launch=/usr/bin/dbus-launch
session optional        pam_systemd.so
session optional        pam_kwalletopener.so    maxwait=60 session_timeout=360 localwallet start_daemon kwalletopener=/usr/bin/kwalletopener
session optional        pam_gnome_keyring.so    auto_start only_if=gdm,gdm-password,lxdm,lightdm

With these settings the pam modules work with any kind of useraccounts. Keep in mind that it will not work for automated logins where the system doesn’t actually prompt for a password.

The required pam modules can be installed from this OBS project.

Feb 072013
 

KDE 4.10 has been released, and I have upgraded my old desktop computer that sits on a shelf in our home server room and runs a NoMachine server to have KDE 4.10.0 on it.

First attempt: migrate my existing KDE 4.9.5 desktop environment.

First result: failure. Basically nothing related to kontact/KDEPIM works after this.

Second attempt: delete everything kde related from that home folder (basically ~/.kde*, ~/.local and ~/.config) and try again.

Second result: after going through the “wizard”, kontact/KDEPIM still needs too many additional steps to be actually usable, but after that it sort of works. I have no idea how much of it will still work if ~ is on a nfs drive, though.

Overall opinion: I hope that KDE 4.10 has matured enough once openSUSE 12.3 rolls around with it as the default KDE desktop.

Jan 032013
 

If you notice that your ssh agent and/or gpg agent aren’t running after logging in to KDE4 on openSUSE, and you just upgraded your KDE from the KDE:Release:49 buildservice repository, there is a simple fix.

Run this command as root:

ln -sf /etc/X11/xdm/Xsession /usr/share/kde4/config/kdm/Xsession

That will do it. By the way, the bug report for this bug is here. Please add your 2 cents worth if you are hit by it.

Dec 242012
 

If you are working with TGA images a lot, you might have seen the bug where KDE apps like Gwenview can’t open them and give you a weird message about being unable to read metadata.

This is a bug in qt. KDE4 brings its own image readers for TGA, but only uses them when the qt ones are not available. So let’s delete them (as root, of course):

rm /usr/lib/debug/usr/lib64/qt4/plugins/imageformats/libqtga.so.debug
rm /usr/lib/qt4/plugins/imageformats/libqtga.so
rm /usr/lib64/qt4/plugins/imageformats/libqtga.so

Some of these commands can fail, depending on whether you have debug information or 64bit versions installed.

Dec 232012
 

Ever had this happen?

You open the file requester in a GTK app to open or save a file, but the names don’t come with icons so it’s kind of hard to tell the difference between a folder and a file without extension.

Here’s the reason: your KDE styles have been updated but the gtk icon cache was not refreshed.

And here is the solution: run the following command as root to refresh all icon caches:

for i in /usr/share/icons/*; do [ -d $i ] && gtk-update-icon-cache $i; done
Jan 192012
 

Here are the results from the survey:

75% answered “yes” on the question whether they use kontact or not. Those who answered “no” did not get to the rest of the survey. All questions except the last two were multiple choice.

Component usage:

E-Mail93,42%
Contacts78,95%
Calendar77,63%
Feedreader53,95%
Task list35,53%
Summary19,74%
Yellow Notes17,11%
Journals10,53%
Time tracking9,21%
Other9,21%

Mail protocols:

IMAP72,6%
POP347,9%
Local Maildir17,8%
Other11,0%

Calendar sources:

Vcard files75,0%
Google contacts plugin29,4%
CardDAV11,8%
LDAP10,3%
Kolab etc10,3%
Other7,4%
Novell Groupwise1,5%

Address sources:

iCal file66,1%
Google calendar plugin32,3%
CalDAV21,0%
Kolab etc14,5%
Other11,3%

Quality compared to other PIM applications or email clients:

Poor11,1%
Below average16,7%
Average34,7%
Good33,3%
Excellent4,2%

Has kontact improved over time:

Improved23,9%
The same25,4%
Worse50,7%
Optimization WordPress Plugins & Solutions by W3 EDGE
%d bloggers like this: