A KMail Breakthrough.
Introduction ![]() From here on, just follow the instructions and you will usually be astonished at how fast the process works. You will end up with all the relevant emails from the mbox file imported into their correct KMail folder - sort of; see the next paragraph for the last little "tweak". Doing this procedure again and again is slow and tedious compared to importing a single archive file, but it works. It is quite possible that all the inbox emails will be marked as "unread". If this is the case, then an even more tedious job is waiting for you, because as far as I know, you have to select the files one by one so they are marked as read. There is also another minor and tedious task to be undertaken. Each time you import an mbox file into the KMail folder, it does NOT go immediately into the folder itself, but instead the emails are copied into a subfolder of the folder you are working with. What you then do is open that subfolder, select all the emails in it and "drag and drop move" them into the designated folder and delete the subfolder. Okay, messy, but once again, it does work. Last But Not Least. As I indicated above, there seems to be no way you can drop a Unix based copy of the entire set of KMail files into the present version of KMail using the standard file managers. I'd be enormously happy to be corrected if I am wrong in this matter. As I presently see it, there are two methods available to the KMail user if some sort of backup system is to be applied - there may be others. The first is to use the "mbox" export method and keep that set of files as an "unreadable but savable" copy. The second is to use KMail's archive process and make a standard archive. I'd also stress that this article contains my perceptions of the situation as it unfolded. There are probably other ways of doing what I wanted, but I found a way to effectively solve a problem and tedious or not, I'm very content with the results. It is very possible that some of my assumptions are incorrect and readers should recall that I am just a user who has fought his way through a problem and seen it from a particular perspective. I'm very happy to be told of any errors I've made in this text, just as long as I also get the real answer. At the moment, KMail 4.11.5 seems to be running perfectly. I have altered no settings which concern the Akonadi system. I cordially detest the fact that KMail is wholly dependent on Akonadi, but I don't dare touch any of its default settings for fear of rendering KMail inoperable. I have no objections to Akonadi itself, I simply believe that users should have the choice/option of operating KMail completely independently from Akonadi and preferably with Akonadi wholly disabled. I have gone through some "convoluted process" which seems to have stored the server password in KMail rather than the wallet, but if you ask me how I did it, I simply don't quite know. Just luck that I pushed the right buttons, I think. I do recall that when the Wallet kept on asking me if I wanted to Keep the password in the system, I selected Keep each time, and I think the Wallet got sick of asking. What I do know, is that when I just looked at my account, the password is clearly shown as having been registered in the KMail software itself. If that is the case, then I congratulate the KMail team for restoring that user option - I repeat, my only problem is that I don't know precisely how I did it. I have always argued that a user should have the option of either keeping the password either in the system or in the Wallet, and the option should be very clearly displayed. Assuming that the option to use or not use the Wallet has now been restored, KMail's absolute dependence on Akonadi to store its files remains the sole major problem as far as I personally am concerned. But for the rest, KMail remains a superb piece of software, settings complexity or not - I can live with that. And one last thing is that the 4-core 64bit laptop runs both KDE 4 and KMail very fast indeed and at least some of the problems noted in the earlier articles are now un-noticeable. So there we are.......I think I have managed to "bash" KMail 4.11.5 into a form that I can use comfortably. It's been a very steep learning curve and I wasn't sure I was going to win. To be honest, I think the KMail team would be perfectly justified in saying that I should have expected some sort of difficulty in trying to migrate emails from such an old/antique version into one of the latest versions. And I cannot help but agree - but in mitigation KMail team, I believe I used an "antique method" to get my files across (sorry, but that strikes me as funny). I have noted that the Accounts section in the setting up window has a "Local Mail" line......I'm not sure what it does, but it's of no use to me, and so I have left it strictly alone. Like other parts of KMail now, I am reluctant to try to modify or delete areas about which I lack information and whose change might disturb the smooth running of the software in some way.......What an absolute pain. But, thankyou once again KMail team for the Password/Wallet option alteration and the difficulties that were laid in my path (and I strongly emphasise that I am not being sarcastic at this point). Without those problems, I would not have explored and learned about the mbox concept - and best of all, it worked. Links to the Earlier Articles on openSUSE 13.1, KDE and KMail Here is a link to my earlier article discussing problems with KMail in these latest versions. I'd add here, that later events have "killed" the Patience option described here. The latest versions of KDE4 have been modified to the extent that the old version of Patience will no longer run. Sad. The new swinging and dancing version of KDE 4 KPat does NOT have the crispness and quality of the card decks available in the old KDE3.5 KPat. Well, that's my opinion. "KMail Complexity - and a Little Patience": http://lxer.com/module/newswire/lf/view/197664/ Readers might also like this other series on openSUSE, KDE and the semantic desktop. The links to both Part 1 and Part 2 are supplied. Removing/Disabling The Semantic Deskop in KDE4 (and firing up Thunderbird) Part 1 http://lxer.com/module/newswire/view/198081/index.html "Removing/Disabling The Semantic Deskop in KDE4 Running on openSUSE 13.1 Part 2" http://lxer.com/module/newswire/lf/view/198639/ |
Comments (37)
VLC and Xine in openSUSE 13.1
1 earlier comment in the full thread.
tony@linux-opzy:/usr/bin> vlc
...................
VLC media player 2.2.3 Weatherwax (revision 2.2.3) [000000000219c0b8] core libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
.....................
WARNING: QApplication was not created in the main() thread. Segmentation fault
....................
tony@linux-opzy:/usr/bin>
Post Script.......I have managed to get a copy of Xine running......I used the rpms that were available on this site:
http://cambuca.ldhs.cetuc.puc-rio.br/xine/
You need all three of the libxine, xine-ui and libdvdcss.........once all three are installed, xine runs perfectly - with one teensy, weensy problem - no sound.
Could you run that test once more with verbocity turned on please, and let's drill down one level little further.
Run in a terminal as:
vlc -v
tony@linux-opzy:/> /usr/bin/vlc -v VLC media player 2.2.3 Weatherwax (revision 2.2.3) [000000000105c0b8] core libvlc warning: cannot load module `/usr/lib64/vlc/plugins/meta_engine/libtaglib_plugin.so' (/usr/lib64/vlc/plugins/meta_engine/libtaglib_plugin.so: undefined symbol: _ZTIN6TagLib3Ogg4Opus4FileE) [000000000105c0b8] core libvlc warning: cannot load module `/usr/lib64/vlc/plugins/codec/libgstdecode_plugin.so' (/usr/lib64/vlc/plugins/codec/libgstdecode_plugin.so: undefined symbol: _gst_fraction_type) [000000000105c0b8] core libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. WARNING: QApplication was not created in the main() thread. Segmentation fault
Hope it means something to you.
This was back in 2008, so it may not be the same problem, but I'd give moving that directory to a backup a try.
Terminal messages will appear correctly if you use the 'code' tag in your post.
Like this:
[...code...]
xyz@workstation:~$cowsay Hello Ridcully! _________________ < Hello Ridcully! > ----------------- ^__^ (oo)_______ (__) )/ ||----w | || ||
Of course you will need to leave the ellipses out.
The 'code' tag is fairly equivalent to the html 'pre' tag... and allows one to display monospace text as intended preserving correct spacing as well as carriage returns.
Quoting: I removed the /root/.config/.vlc and everything started to work"
Actually Ridcully is probably not running vlc as root, so his configuration is probably in
/home/tony/.config/.vlc
Deleting (or renaming) that and restarting vlc is probably a good idea. vlc will recreate it, this time possibly correctly.
Y'know.........I could quite easily throw this whole openSUSE 13.1 into the trash can and try Linux Mint for the first time. I shall meditate on it. But this is getting to the ridiculous stage. VLC and Xine both run perfectly in openSUSE 11.4 in 32bit mode on that 64bit laptop.........Perhaps the other alternative is to "bite the bullet" and run the older OS.....but I am reluctant, even though it works perfectly on this older 32bit computer on which I am . One feels one is wasting available computing power. Whoever said computers save time ? On the other hand, they do provide rather nice puzzles for you to work out.
Duh. Correct.
> but of course, it isn't. VLC has never started and therefore it has never created its config file
Sigh. Oh well, it was worth checking. I wonder what vlc gets it's initial config from?
The only thing I can think of that might still be worth trying is running strace vlc from the command line. That might show what's causing the segfault.
This problem of software conflicts is (in my humble opinion) largely due to the fact that openSUSE will NOT package a working copy of VLC plus libdvdcss in its distribution, due to USA laws, but at least I think I am beginning to narrow the field down.......Wait for the next exciting episode of............wait for it, wait for it......... VLC and openSUSE 13.1.....LOL.
main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
I think you're probably on the right track about it being a problem that openSuSE doesn't package vlc with it's main distro. You might want to try obtaining an SRPM and building your own RPM package from that... Either that or use a "civilized" distribution,... ;)
Are you using this guide?: http://opensuse-guide.org/codecs.php This one also has more information: http://www.dedoimedo.com/computers/opensuse-pimp.html
Interestingly, I believe the opposite.......I know I had to search and find at one stage, a file called "libdvdcss-2.dll" while playing with VLC on a Win7 computer. Once installed in the appropriate directory, VLC ran, but there was NO way it would run without that .dll file, and it's still on this Linux computer in an archive file.
Whaddya mean "civilized" distribution, JaseP......? This means war. I demand a duel: loaded bananas at 20 paces. However, seriously, I have "flirted" with the idea as well....What do you use or would recommend ? I have never used a distribution based on ".deb" and all my files and backups of software are all ".rpm" based.
To check if libdvdcss is installed correctly with a searchable path:
$sudo ldconfig -p |grep libdvdcss
Oh yeah... you'll be able to see what libraries vlc is linked with by:
$ldd /usr/bin/vlc
I looked last night and found that I didn't have VLC installed on my current Windows 7 machine (which just goes to show how little I use it). I installed it and confirmed I could watch my Serenity DVD with no additional software installed. So I'm not sure why you had to install additional software.
The VLC directory on my Windows machine contains a folder access which contains the libdvdread and libdvdnav libraries. So I can't say for certain if vlc has it built in on Linux or not. So time for that research...
OK, from the VLC FAQ
I cannot read DVDs! ... If you are on Linux/Unix, did you install the '''''libdvdcss''''' package?
So yes, the Linux version of vlc requires libdvdcss. The howto's I linked to above give a procedure for installing it. Maybe you're using the wrong version?
Email Client Choice
http://sylpheed.sraoss.jp/en/
Just like you, I was unfamiliar with the general ideas behind and between maildir and mbox. And just like you, I discovered that mbox is the 'universal' export/import-able format. It just happens that sylpheed uses the mbox format directly, so this made the export/import tasks less complex.
In any case, I have about 15 different email accounts that I monitor throughout the day... Evolution was very slow in checking each and my system would sometimes strain if a given folder had many messages. I have no such problems with sylpheed. However, what I do have now is a problem with integrated calendars...
Without the Evolution or Kmail calendar function I have searched, without much success, for an acceptable stand-alone calendar...
BTW:
Quoting:The first is to use the "mbox" export method and keep that set of files as an "unreadable but savable" copy.
mbox is definitely readable. In fact, it's plain text... that's why the import function is so fast. The documentation in sylpheed contains a justification for the use of mbox due to speed considerations. So, if you have an old computer, it may be a good idea to use an email client which stores local email in mbox -- the speed of storage, retrieval, and search is much faster than maildir or the various DB methods.
As a side note: I really am unsure why 'heavy' email client developers are so enthralled with sorting all data through a single metadata 'engine'. It makes everything more difficult to unravel when workflows need to be adjusted.
http://serverfault.com/questions/564456/maildir-vs-mbox-what... http://www.linuxmail.info/mbox-maildir-mail-storage-formats/
Most people consider maildir to be a better format, and as far as technical reasons go, I'd have to agree. That said, unless I'm dealing with extremely large mail files, mbox seems to work fine for me, and it's the default for the mail clients I use .
Sylpheed does not use mbox. It does export and import mbox. However, the storage of local mail is one plain text file per message... similar to maildir.
My basic point was:
The 'heavy' email clients all seem to be rather slow and resource intensive, especially considering that most of email is plain text with no attachments.
sylpheed is very fast. I think 'Claws' is a 'heavier' version, and may include a calendar -- it's been awhile since I've looked.
I think it's important to remember that a 'preferred' application may not be appropriate for lower spec machines. And I would usually recommend sylpheed or claws on an older platform.
EDIT: to include simultaneous above post...
>so I assumed that the file as a whole was not directly readable.
Since I had to export everything to mbox... all my old emails are stored in mbox...
I've found this very convenient because I can use 'grep' to quickly find anything I want -- all the way back to emails from the '90s -- in just a few seconds.
However, I still am unsure why there seems to be a dearth of high quality stand alone calendar applications... one that uses caldav and does not use Google or assume that the end user has a gmail account... and other yada, yadas ...
* less diskspace, especially if you have lot's of small files.
* much faster to open and read by the mail client, as only one file needs to be opened
the downsides are:
* easier to corrupt. more likely to happen if you have multiple applications accessing the mbox file. (like maildelivery to mbox and your mailclient updating the mail status. i once lost a years worth of emails because of that)
* need to be reindexed every time mails are updated, because offsets change. again more likely to happen if accessed by multiple applications at the same time.
i am still using mbox on my inbox, but since i switched from mutt to sup, i no longer get the speed advantage because sup keeps a separate full-text index, it also doesn't like it at all when another process (like imap) messes up the offsets it has stored.
greetings, eMBee.
greetings, eMBee.
Dare I start a third thread?
Well... after reading the story, I had a look at Akonadi. I gotta say, it looks scary. The systemd folks over at Red Hat are behind the times when it comes to gobbling up everything. It looks like Akonadi got there first...
Here's someone's blog post about Akonadi:
http://www.dvratil.cz/2016/01/kde-pim-still-alive-and-rocking/
It's funny how much it parallels the systemd folks. It's definitely all about uniformity, conformity, and "my binary data stove pipe is better than yours" ... whatever happened to flat plain text files?
/end mini-rant
It's all about asserting control.
He who gains control of the most users wins.
With closed proprietary software the battle is already won (or lost depending on your perspective) since those users have never had an expectation of controlling their own systems.
The battle for control inside a Linux environment is a bit more difficult to win. Google does it by combining closed/secret software along with their open kernel, and by using vendor configured selinux to lock systems even to root users. KDE and systemd gain control by "gobbling", moving configurations to binary formats, and by cloaking secrets through complexity. What users don't see, they don't control.
Yeah -- I agree that seems to be the main objective. For myself, I like to know how everything works. I greatly dislike 'hidden' complexity. Unfortunately, many younger developers seem to be under the false impression that choice is bad and so try to hide the 'difficult' configuration items from users. I tend to think this is not the correct direction. What's the harm in leaving all the configuration items on the list and having an 'advanced' tab to reveal the less common choices?
But, then again, I'm just a lowly end-user for the most part... and like the current US political primaries... who cares about the end-user, 'we' don't need them, and they don't know what's good for them...
I like GNOME as a desktop environment but it also has to be said you can't really beat a well configured XFCE or LXDE.
Untitled
The removal of user choice is one of the worst possible charges you can lay against FOSS developers, but I personally would definitely make it against the KDE/KMail developers. There should have been a way for Akonadi to be available if required, but only operating if the user wished; this would have left KMail and the rest of the components of the Personal Information Management suite free to operate independently at the user's desire. Perhaps it was just too hard or time consuming for the KDE/KMail team to undertake such a development path, so they chose the easier way to force every body onto the simpler path they wanted - because I think it would take real developmental effort to retain the "use or not use" choice of Akonadi. But who knows ?
I've also made an oblique reference to another aspect of KDE/KMail/Akonadi with respect to speed. In my opinion, if you don't have a 4-core 64bit computer, my advice is not to even consider KDE/KMail/Akonadi......an older 32 bit computer simply cannot handle the software fast enough.
This seems to be because nearly all of the communication with email servers and storage and retrieval has been offloaded to Akonadi.
If you look at the Akonadi website:
https://community.kde.org/KDE_PIM/Akonadi
it's apparent that Akonadi is not so much of a 'dependency' of KMail... it's actually more than half the application. So, it's impossible to remove Akonadi from KMail... That would be like trying to boot an OS without a kernel.
And if you want a real eye opener, read the PDF report about the goals of Akonadi:
https://community.kde.org/images.community/e/ee/Robert_Zwerus_-_Storing_PIM_data.pdf
***
>an older 32 bit computer simply cannot handle the software fast enough.
I'm sure there are many other opinions, but it would seem that the latest KMail would not be a good choice for an older machine.
Again, I would recommend sylpheed for older machines.
Here is some realtime info from my machine:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20170 xyzjkl 20 0 520.0m 41.9m 24.6m S 0.0 0.2 0:06.75 sylpheed
As you can see my many open mailboxes, messages, and connections only use about 65MB of RAM and since I've had the email client open for about 12 hours, you can see it doesn't use many CPU cycles either.
sylpheed is awesome... as long as you like your email in plain text [no html, but does include images], which is a good security practice anyway.
It was purely my "bl...dy-minded" stubbornness that made me make the attempt to get those emails into the latest version of KMail and I succeeded; but it doesn't make me any the happier with the overall development of KDE which now has become a grotesque caricature of the elegant software it once was. This is being written on openSUSE 11.4, the last version of that software that still had a version of KDE that retained most of its elegance and simplicity.
Now that I have achieved my goals with that latest version of KMail, I will probably wipe the whole drive and see if I can find an archival copy of openSUSE 11.4 in 64 bit mode. Then experiment with that.....AS I remarked in my articles, the KDE/KMail team don't give a tinker's curse about the users, as long as they have done what they want to do. But one of my conclusions in my articles was that I could not recommend KDE in its current form to any beginner in Linux because of its Akonadi monolith......I am still of that opinion. I think it may be time for me to get very serious about openSUSE 13.1 running Xfce.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Sign up and post (it is free) or Log in and post
|
|

