[kde] Re: KDEPIM 4.6 prob^Wimpressions
On Wednesday, 2011-06-29, Duncan wrote: Kevin Krammer posted on Wed, 29 Jun 2011 10:53:11 +0200 as excerpted: On Wednesday, 2011-06-29, Duncan wrote: Here, I don't use the kontact suite (nor have kontact itself installed) at all, only some of the separate bits. No korganizer, tho it was a forced install with the update, no kalarm, no knode (I run pan instead). Sounds like a packaging problem, none of the other applications depend on Korganizer. korganizer is listed as a kmail-4.6.0 dependency, I didn't have it before. Keep in mind that gentoo is a from-sources distro, so it's possible that kmail requires it only for building. (gentoo does make the distinction between build-time and run-time deps, but I force build-time deps to remain installed after build, to avoid having to reinstall again for the next update.) It is not very common that two applications have a dependency on each other, but being in the same module that could have happened for some reason. It is just weird that this would be introduced now since the move to Akonadi is also about decoupling applications from some of their low level functionality, so e.g. KOrganizer can send mail without having to go through KMail or vice versa (KMail creating a calendar entry from a received invitation without having to go through KOrganizer). I'm guessing that it has to do with the same reason akonadi keeps complaining about my having nepomuk disabled, even tho as best I can see, it's mainly the organizer/alarms/etc functionality it wants, and I don't need that. kmail probably links against that same akonadi functionality, so it must be there at build-time and possibly run-time, even if it's not actually used. No, this is unrelated. Neither does the calendar/alarm support for Akonadi/Nepomuk integration depend on KOrganizer, nor is the Akonadi/Nepomuk cooperation limited to calendar/alarm. Actually the probably most used form of indirect Nepomuk usage is address book searches, e.g. for expanding distribution list or checking sender addresses against the addressbook in mail filters. With this new version of KMail it will also be of interest for people who want to search for email (search in folders or based on matching criteria, not for the quick filtering thing on top of the message list). Or it could be as you suggested a bad dep, tho it's newly and deliberately added, so there was evidently something in the deps that was failing without it, perhaps just because the gentoo/kde folks didn't figure out how to link it to a USE flag option just yet. It could indeed be a build dependency, though I am not sure if this would even be intentional. Maybe someone at Gentoo know why they had to add this. The problem, it seems, was that I had kmail (1) set to use a different directory for its mail. [It] couldn't do a /simple/ thing like read the old kmail config and see where the local mailstore was? Of course the migrator does exactly that. It reads the folders entry in section General of the KMail configuration and uses this location for local folders. If the entry is not present (normal KMail setup), it will use the same default value KMail does, e.g. $HOME/.kde/share/apps/kmail/mail What's the output of kreadconfig --file kmailrc --group General --key folders on your system? $kreadconfig --file kmailrc --group General --key folders ~/config/mail (It probably doesn't matter here but just in case, XDG_CONFIG_HOME points to ~/config and XDG_DATA_HOME to ~/config/local/share for my user. KDEHOME is ~/kde . The two XDG variables shouldn't matter at this point, this is a KDE internal procedure. And KDEHOME is handled by KDE's config framework internally (and correctly as your kdereadconfig output shows). FWIW, while you imply it's a system setting (you ask what the result is on my system, not for my (normal) user), it appears to be a user setting, as my admin user (which never runs kde) has it unset, while my normal user has the results above, ~/config/mail. I didn't mean to imply that it was a system setting, I meant what is the output you are getting when you execute the command. Of course, with KDE's config capabilities of merging config entries from different locations, this could actually be a global setting (e.g. $HOME/Mail), but in this case it is usually user local. And ~/config/mail is exactly where it was, too. As I said in the previous post it's no longer there as I moved it to my media/backup partition, but it there for the first, automatic, import attempt. I only moved it after the auto-convert/import failed and I was getting ready to try again, manually. If kreadconfig returned the correct value than this is what the migrator will read as well (same keys used with the same API). A cause of error could have been a stale kmail2rc from a previous attempt. So I wonder if it's possible, given the parallel access implications of both
[kde] Re: KDEPIM 4.6 prob^Wimpressions
On Wednesday, 2011-06-29, Duncan wrote: John Layt posted on Wed, 29 Jun 2011 19:39:40 +0100 as excerpted: On Wednesday 29 Jun 2011 18:40:32 Jerome Yuzyk wrote: All this talk about trashed mail and such isn't very encouraging. Is there somewhere that explains what changes are afoot for this new release? Right now it sounds like KMail is going to some big binary blob for all my mails a la Outlook, but that could be my own ignorance - perhaps someone could correct me on that. I'm looking at upgrading my Fedora to 15 and wonder if I'm going to get side-swiped with these hassles and should maybe start looking at another mailer that's free of all the Social Nonsense baggage KDE seems to be accumulating. No, that's a common misconception. Akonadi is a just common data access library that also caches data for efficiency, the underlying data storage remains unchaged, i.e. the usual maildir or ical files. IIRC it was Kevin that set me straight on that, some time ago. Unfortunately, the message that the database stuff is only cache hasn't really made it out as well as it should have, but it's the only reason I'm still on kmail at all. Otherwise I'd have been gone. The database use of Akonadi is basically just an implementation detail nobody other than Akonadi server itself should be concerned about (not even developers working on other parts like library, clients or agents/resources). Some people who obviously favor reimplementing stuff themselves all the time over using exsiting and proven code decided to single this particular detail out and complain about it. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: KDEPIM 4.6 prob^Wimpressions
On Wednesday, 2011-06-29, Alex Schuster wrote: Kevin Krammer writes: On Tuesday, 2011-06-28, Alex Schuster wrote: BTW, I have lots of resources named akonadi_ical_resource_0 to akonadi_ical_resource_20 (only number 19 is missing), all with no file name selected. You can delete those (kcmshell4 kcm_akonadi_resources or from KOrganizer), this is a hard to reproduce bug (timing related) when migrating calendars. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: KDEPIM 4.6 prob^Wimpressions
On Wednesday, 2011-06-29, Duncan wrote: The interesting thing about the log found in that dir, here, is that it lists the account migration, mostly pop3 but with one sysmail maildir account, but *NOT* the actual mail migration. Which matches my experience, it auto-migrated the accounts but not the existing mail, taking very little time to do so. Hmm, then only way no mention of local folders migration can happen if the path value read from config does not point to a directory. But what's weird is that the log contains no hint whatsoever about what might have gone wrong with the existing mail migration -- it doesn't mention any attempt to migrate that at all. Which of course explains why the migration went so fast, since for whatever reason, it detected and migrated the accounts, but not the existing mail. shrug The local folder migration is usually very fast. It only walks the folder structure and adjusts filters and similar settings. Usually only takes a couple of seconds (depending of course on how many folders you have and the current I/O load of the system). Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: kwin performance gets worse and worse with every release
On 06/30/2011 06:28 AM, Duncan wrote: Nikos Chantziaras posted on Wed, 29 Jun 2011 23:22:36 +0300 as excerpted: (I'm using a Radeon HD4870 with the open source drivers.) I was able to find a tweak that makes kwin usable again though. I had to create a ~/.drirc file and put this in there: driconf device screen=0 driver=dri2 application name=Default option name=vblank_mode value=0 / /application /device /driconf The driconf utility doesn't work; the above has to be created by hand. Also, the VSync option in System Settings must be unchecked. Both of these things must be performed; if only the .drirc file is created, or only the VSync checkbox is unchecked, then kwin will keep being slow. It should be noted that the desktop is still tear-free after doing the above. [...] Meanwhile, I'd be interested in your locked and unlocked glxgears framerate stats. If you're seeing 60 Hz even maximized (assuming you're not running dual 2560x1600 monitors or some such), then there's gotta be something wrong with your effects chain, somewhere, because as I said, AFAIK, your hd4870/rv780 should in theory be getting better stats than my hd4650/rv730. I'm getting about 7000 FPS windowed, and 4000FPS maximized (yes, that's thousands, not hundreds.) But I think glxgears is not pretty good as a benchmark these days. Next thing to try is OpenGL video playback. I wonder if the unlocked framerate will affect it any... If you have SwapbuffersWait disabled, then the effect will be ugly tearing and higher GPU temps. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: kwin performance gets worse and worse with every release
On Thursday 30 June 2011 12.49:28 Nikos Chantziaras wrote: I keep seeing this s/\/\g stuff around, but I still don't any idea what it means, lol man sed :) -- Georg C. F. Greve gr...@fsfe.org http://www.linkedin.com/in/GeorgGreve http://blogs.fsfe.org/greve/ http://identi.ca/greve ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: kwin performance gets worse and worse with every release
On Thursday, 2011-06-30, Georg C. F. Greve wrote: On Thursday 30 June 2011 12.49:28 Nikos Chantziaras wrote: I keep seeing this s/\/\g stuff around, but I still don't any idea what it means, lol man sed :) What Georg tries to tell you here in a geeky [1] way is that this is a way to specify searchreplace procedures based on a quite powerful system called regular expressions [2]. The s/dri\.conf/drirc/g quoted earlier basically boils down to Search for dri.conf and replace with drirc everwhere it is encountered in the input Cheers, Kevin [1] Having become a CEO means he needs to actively remind people that he's actually a geek and knows stuff ;) [2] http://en.wikipedia.org/wiki/Regular_expression -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: kwin performance gets worse and worse with every release
On Thursday 30 June 2011 12.38:02 Kevin Krammer wrote: [1] Having become a CEO means he needs to actively remind people that he's actually a geek and knows stuff So you're saying CEO does not stand for Chief Entertainment Officer? Damn. ;) Best regards, Georg -- Georg C. F. Greve gr...@fsfe.org http://www.linkedin.com/in/GeorgGreve http://blogs.fsfe.org/greve/ http://identi.ca/greve signature.asc Description: This is a digitally signed message part. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: KDEPIM 4.6 prob^Wimpressions
Kevin Krammer posted on Thu, 30 Jun 2011 09:00:45 +0200 as excerpted: On Wednesday, 2011-06-29, Duncan wrote: Kevin Krammer posted on Wed, 29 Jun 2011 10:53:11 +0200 as excerpted: On Wednesday, 2011-06-29, Duncan wrote: No korganizer, tho it was a forced install with the update Sounds like a packaging problem, none of the other applications depend on Korganizer. korganizer is listed as a kmail-4.6.0 dependency, I didn't have it before. Keep in mind that gentoo is a from-sources distro, so it's possible that kmail requires it only for building. It is not very common that two applications have a dependency on each other, but being in the same module that could have happened for some reason. It's not uncommon to see in a gentoo kde ebuild, that it must extract (not build, just extract) not only the package it's building from the big module tarball, but one or more others as well. This is common enough that the kde eclasses (eclasses are package or functionality specific procedure libraries common to a number of versions and possibly multiple packages, in this case kde specific) have special handling for this. In fact, they have KMEXTRACTONLY, which only extracts the listed subdirs in the module tarball, without compiling or installing, and KMCOMPILEONLY, which extracts and compiles but does not install. (KM is short for KDE module.) There's also KMEXTRA, which does the whole thing, extract, compile and install, as part of the package. And indeed, the kmail ebuild makes use of all three, with extract-only listing akonadi_next, calendarsupport, korganizer, kresources... Compile- only lists messagecomposer, messagecore... calendarsupport (they aren't supposed to list a subdir in both, but it appears they did with calendarsupport... I wonder if that's why they ended up depending on korganizer to get it to work??). Extra (full build) lists kmailcvt, ksendemail... ontologies... But here, for whatever reason (maybe the bug above, calendarsupport listed in both extractonly and compileonly?), they make korganizer a full dependency, thus forcing build and install of korganizer first, before kmail can be built and installed. FWIW, here if you want to take a look at the actual ebuild (tho it looks much nicer with syntax color hiliting, this isn't an implication that I expect it, only if you'd find it interesting to see what an actual implementation looks like). It's quite high-level and shouldn't be too complicated for an outsider to get a general picture from, anyway. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/kde-base/kmail/ kmail-4.6.0.ebuild And here's the first-level inherited eclass, kde4-meta.eclass, if you want, tho this has a lot more (basically bash) code. It does further inherits but you can change the link manually to get them, if desired. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kde4- meta.eclass It is just weird that this would be introduced now since the move to Akonadi is also about decoupling applications from some of their low level functionality, so e.g. KOrganizer can send mail without having to go through KMail or vice versa (KMail creating a calendar entry from a received invitation without having to go through KOrganizer). Indeed. But adding that ability means the code to create that calendar entry must be in kmail too, or borrowed from korganizer in the form of a dependency, which is how I'm interpreting this, assuming it's not the double-specified bug above or simply a mistake of some sort. Actually the probably most used form of indirect Nepomuk usage is address book searches, e.g. for expanding distribution list or checking sender addresses against the addressbook in mail filters. With this new version of KMail it will also be of interest for people who want to search for email (search in folders or based on matching criteria, not for the quick filtering thing on top of the message list). That's actually a question I had, but hadn't asked (or tried) yet, whether email searches, etc, now require nepomuk. I'll probably enable it for that at some point, but the basic functionality that I use normally, doesn't require it, and there's still a bit of weirdness going on (every time a mail comes in, I get a warning about two copies... I suspect I have two different resources pointed at the same place or something but haven't had a chance to investigate yet... but don't spend too much time on that unless you happen to have a simple solution or bug you can point me to, as I'll create a separate thread for it when I'm ready, given that it's really a separate topic and this thread's convoluted enough already), so I'm not worried about /extra/ functionality yet, just trying to keep it reasonably simple to deal with until I'm sure the basics are working correctly. Or it could be as you suggested a bad dep, tho it's newly and deliberately added, so there was evidently something
[kde] Re: KDEPIM 4.6 prob^Wimpressions
Kevin Krammer posted on Thu, 30 Jun 2011 09:24:05 +0200 as excerpted: On Wednesday, 2011-06-29, Duncan wrote: The interesting thing about the log found in that dir, here, is that it lists the account migration, mostly pop3 but with one sysmail maildir account, but *NOT* the actual mail migration. Which matches my experience, it auto-migrated the accounts but not the existing mail, taking very little time to do so. Hmm, then only way no mention of local folders migration can happen if the path value read from config does not point to a directory. Well, it did, and kmail(1) had been using it just fine, so /it/ could obviously see it. Which is why I suggested there might have been some obscure race condition (four CPU cores and four-spindle-kernel-raid-1, with quite heavy unrelated disk I/O at the same time, nice race condition territory indeed!) that caused the config lookup not to return the dir, once you disabused me of my notion that it only worked on the defaults as my possible explanation of choice. Whatever, maybe it was a cosmic ray hitting that bit of memory at the wrong time! =:^\ Actually more likely than a cosmic ray (the memory /is/ ecc) might be some obscure kernel vfs bug or the like, given I was/am running mainline linus git kernels, and was running something around 3.0- rc3 at the time. That's unlikely too as I've seen no other problems with the kernel this cycle, but everything at this point is unlikely, so... Probably just a one-off of some sort. Those things happen. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Adding Fonts
On 2011/06/30 14:35 (GMT-0500) Billie Walsh composed: KDE 4.6.2 Kubuntu 11.04 For some reason my method of adding my collection of True Type and Open Type Fonts doesn't work. Usually I can just add them to the usr/share/fonts directory someplace and they work. They show in applications like Gimp but default to just a simple block letter. In fact over half the fonts installed by the system also don't show. I've tried installing them with System Settings Font Manager and Kfontview but that doesn't work either. What am I missing? I don't know. However, if you only have one user configured that needs those fonts, just put them in ~./fonts. Simple. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: kwin performance gets worse and worse with every release
Nikos Chantziaras posted on Thu, 30 Jun 2011 12:45:54 +0300 as excerpted: On 06/30/2011 06:28 AM, Duncan wrote: Nikos Chantziaras posted on Wed, 29 Jun 2011 23:22:36 +0300 as excerpted: (I'm using a Radeon HD4870 with the open source drivers.) I was able to find a tweak that makes kwin usable again though. I had to create a ~/.drirc file Also, the VSync option in System Settings must be unchecked. Both of these things must be performed It should be noted that the desktop is still tear-free after doing the above. I'd be interested in your locked and unlocked glxgears framerate stats. [Y]our hd4870/rv780 should in theory be getting better stats than my hd4650/rv730. I'm getting about 7000 FPS windowed, and 4000FPS maximized (yes, that's thousands, not hundreds.) But I think glxgears is not pretty good as a benchmark these days. You are correct, but it's still useful at an extremely basic opengl functionality level (besides being interesting eye candy, like the cube, flip-windows effect, etc), and can be useful for comparisons within the same family (r7xx Radeon chips, in our case). And yes, your results DO show it as being vastly better than mine. Part of that may be that the chip is better, but I believe part of it is the bus, as well. AGP bus simply can't compare to 16x PCIE, no matter HOW you slice it! But I've long suspected that like a purebred race horse, the really top performing graphics hardware is more finicky and requires more careful handling than ordinary stock. So it may be that your card, being tuned for higher performance, was having trouble with a force-refresh-locked de-tuned configuration. (Caveat: My way of simplifying a subject that in detail is certainly well above my head.) Next thing to try is OpenGL video playback. I wonder if the unlocked framerate will affect it any... If you have SwapbuffersWait disabled, then the effect will be ugly tearing and higher GPU temps. I do, and I believe I saw some corruption on playback as a result (hard to tell without going back and playing the same video without swapbufferswait and/or without refresh-unlocking), but it wasn't as bad as I suspected it might be. Part of that, however, was probably because of the low-quality video I was testing with. Youtube higher (but not highest, generally only available on a few videos, often paid or at least interstitial-ad- supported, which I have trouble with as I won't do proprietary flash) quality, which might almost match SD, but is still a LONG way from hardware-challenging HD, even 720p. I'll have to try it with a DVD image or the like... -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: kwin performance gets worse and worse with every release
Kevin Krammer posted on Thu, 30 Jun 2011 12:38:02 +0200 as excerpted: The s/dri\.conf/drirc/g quoted earlier basically boils down to Search for dri.conf and replace with drirc everwhere it is encountered in the input Yes. And (I can say this since it's myself I'm putting down) to some extent, choosing to use the sed substitute, for dri.conf, drirc, globally (literal left-to-right translation of the clauses), instead of the plain English, Oops, make that drirc instead of dri.conf, is a way of saying Yes, I made this mistake, but I'm not /really/ as foolish as it makes me look, because see, I can use '133+ regex'! =:^P Of course, s/dri\.conf/drirc/g is also much shorter and cooler looking than a whole plain English sentence to the same effect, so it's not /entirely/ the above, there's a practical aspect to the conciseness as well (something regulars I'm sure will agree I can usually use more of, but that's the problem, when I try, it ends up /too/ much so and there's inevitably a subthread having to explain it!), so it's really a bit of both. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
