General Support - kdelibs-bin removed by todays dist-upgrade - NO PROBLEM hubi - 30.05.2006, 08:39 Uhr Titel: kdelibs-bin removed by todays dist-upgrade - NO PROBLEM
I don't give it a try today
EDIT:
I did give it a try, no problems on desktop and Vaio. Thanks to devil28.
hubi
craigevil - 30.05.2006, 21:50 Uhr Titel: RE: kdelibs-bin removed by todays dist-upgrade - NO PROBLEM
SO removing the kdelibs-bin doesnt mess things up?
phen - 30.05.2006, 21:56 Uhr Titel: RE: kdelibs-bin removed by todays dist-upgrade - NO PROBLEM
did a dist-upgrade a few minuntes ago - removal of kdelibs-bin included. no problems for me too (except other things like somewhere else mentioned multicd or opera).
craigevil - 30.05.2006, 22:03 Uhr Titel:
What about all the bugs that are listed:
things like konqueor not starting?
hubi - 30.05.2006, 22:20 Uhr Titel:
Konqueror starts on all three of my boxes, all dist-upgraded today. Just the cursor bounces after login, but that looks funny. Otherwise no probs. But the next upgrade will be here soon, you have to be quick
hubi
clubex - 30.05.2006, 22:43 Uhr Titel:
Don't know if this related but I dist-upgraded this morning and have just
noticed that kscreensaver is no longer kicking in.
I've tryed various screensavers and removed/installed kscreensaver to
no avail.
Testing the screensaver from within the Control Center works perfectly.
It just doesn't seem to kick in after the proscribed period.
Any ideas?
devil - 31.05.2006, 00:02 Uhr Titel:
clubex,
give another day or two for kde to complete.
Thanks for the alert. I performed a dist-upgrade several days ago and crashed my install. (I didn't see any warnings and thought it was okay to d-u.)
So, I reinstalled with the Easter edition. It took 10 minutes. (I love Kanotix.) Everything seems to be working at the moment. I look forward to the final release of 2006.
michael
DeepDayze - 31.05.2006, 01:37 Uhr Titel:
konqueror started up for me OK
I also noticed that KNemo was dependent on kdelibs-bin...but it still worked after the d-u. Perhaps an erroneous dependency?
h2 - 31.05.2006, 03:28 Uhr Titel:
no problems, did the multicd fix before doing the dist-upgrade, removed opera too, no problems at all. Did upgrade on laptop without doing those fixes first and it wasn't as smooth, I'd recommend purging and reinstalling multicd first, purging opera, then doing dist-upgrade, then reinstalling opera.
I did the purge reinstall and it worked on both boxes so I'd guess that's the way to go.
No issues I can see, konqueror seems to start faster than it did before.
Not sure about knemo.
Still waiting for karm to work again, it hasn't retained any data I've put in for a while now, not sure what that's about.
On laptop, something in either new kernel, 2.16.16 or nfs stuff made nfs work again on it, which was nice to see.
Oh, and I've found a new bonus to doing dist-upgrades on main box: I actually finally now do backups routinely, I wrote a small rdiff-backup script that backs up my data and my main root stuff into different rdiff-backup folders, now I actually have recent, upto date backups, and I'm trying to do backups each time I do dist-upgrade no matter what. The more often you do rdiff-backups the less time they take.
So now, it's: backup fully, switch to init 3, run dist-upgrade, run fixes if required, switch back to init 5. On laptop I just boot directly into init 3 and run the dist-upgrade, then fixes if required, then start kdm
This removes the stress of wondering if you might be the one to get the very first buggy deb stuff that ends up breaking x or kde before anyone has time to warn about it.
I also have /home and all my other data on other partitions, so it's just the / directory that I have to restore in worst case, which has only happened one time so far.
DeepDayze - 31.05.2006, 03:56 Uhr Titel:
i ran karm in a terminal and got this error:
QFile::putch: Write operation not permitted
This may be the problem why your data was not being retained, h2.
Can anyone shed light on what is causing that error in karm?
h2 - 31.05.2006, 04:48 Uhr Titel:
deepdayze, that would certainly explain it, that's been the issue, while the stuff is in ram, it works fine, but as soon as I logout/reboot, all the data I placed in there since last time is lost.
I went to karm's site and couldn't find anything useful about the issue. But I didn't think of running karm in terminal either. This is not a new bug though, it's a few months old.
Zitat:
QFile::putch: Write operation not permitted
karm: WARNING: KarmStorage::save : Could not save
It repeats that every minute because I have karm set to save every minute, nice thinking on that one, unfortunately no parts of those error messages appear in google, but it's definitely enough to solve the problem, thanks.
h2 - 31.05.2006, 06:54 Uhr Titel:
I found the solution, finally... in german, figures, I'm hanging around kanotix too much:
1. karm beenden
2. ".lock" löschen: rm ~/.kde/share/apps/kabc/lock/*karm*
3. karm wieder starten
for non-german speakers: stop karm, rm the files above, start karm
In other words, a stuck lockfile.
DeepDayze - 31.05.2006, 13:39 Uhr Titel:
h2, did that fix work for you?
h2 - 31.05.2006, 22:09 Uhr Titel:
yes, it did. It was a stuck lock file. As soon as I found that german posting and saw the word 'lockfile' I immediately recognized the problem, I'd seen a similar thing working on a site with MS Access db, which also uses lockfiles.
That's definitely a bug of sorts though, there should be a routine to look for stuck lockfiles, but there isn't. Now karm is working again. For me this wasn't actually a trivial issue, it's cost me money and time since I rely on my timer for client billing. I was using gtimer but it sucks compared to karm, so now I can get back into the advanced features of karm, like sub project timers, all that cool stuff.
By the way, the error code you posted still appears when you start karm in console, but the save errors are gone, and it's again writing to its calendar file.
The location of the karm lockfiles in kabc is one of those radically unintuitive things that users should never be expected to know, that's so obscure it's not even funny, lockfiles for a program should obviously reside in the program directory so you can see them. How some of these decisions get made is beyond me, but they will get worked out as desktop linux moves into the real world.
