Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: kOrganizer stuck on UTC time, bug not acted on, 42.2 is going EOL

  1. #1
    Join Date
    Nov 2013
    Location
    Kamloops, BC, Canada
    Posts
    4,029

    Default kOrganizer stuck on UTC time, bug not acted on, 42.2 is going EOL

    Note that this has to do with the XFCE desktop without full KDE/Plasma installed:

    With 42.2 coming to EOL in 3 more days, I still have this problem, despite this bug (and a few similar) that have still not been acted upon:
    https://bugs.kde.org/show_bug.cgi?id=373988

    Part in red in the following quote is not in my original report, added it here in case it helps clarify the problem.
    I also cannot remove UTC timezone from the calendar, the option to delete it is greyed out.

    I also can add other time zones, and can remove the ones I added, but cannot remove the UTC time zone and the calendar stays locked to it.

    All appointments are shifted (7 or 8? not looking at the moment) hours
    ... in my displayed calendar.

    This only happens on 42.3, did not happen in my earlier installed versions. On my current 42.2, it does not do this.

    There was a switch from 4 to 5 between 42.2 and 42.3.

    There is some dependency that kOrganizer does not pull in. Or, at least, in my books it is a dependency, because kOrganizer depends on something to set the kOrganizer calendar's time zone and allow it to be changed.

    The workaround is to install the Plasma desktop, which brings with it the necessary dependency and kOrganizer than works as expected.

    However, I would much rather pull in just the required part(s) to fix this problem without having to pull in the entire Plasma desktop.

    It is probably only going to be ignored over at kde.org, as to them it is not important that people such as I cannot use kOrganizer in XFCE (or another non-kde desktop). And, that is probably just fine.

    However, I would like it if someone here at openSUSE can find out what that dependency(ies?) is, so I -- and others like me -- can simply just pull those in without the whole desktop.

    Of course, I am hoping Wolfi sees this, as he is usually about the sharpest at getting to the root of a kde problem.
    "Take a Walk on a Sunny Day, Greet everyone along the way, and Make Somebody Smile, Today"
    Gerry Jack Macks"Walk On A Sunny Day" GerryJackMacks.net

  2. #2

    Default Re: kOrganizer stuck on UTC time, bug not acted on, 42.2 is going EOL

    Quote Originally Posted by Fraser_Bell View Post
    There was a switch from 4 to 5 between 42.2 and 42.3.
    That's not completely true.

    42.2 shipped with both KDEPIM4 and KDEPIM5, but installed KDEPIM5 by default.
    KDEPIM4 has been dropped in 42.3 though, yes.

    There is some dependency that kOrganizer does not pull in. Or, at least, in my books it is a dependency, because kOrganizer depends on something to set the kOrganizer calendar's time zone and allow it to be changed.
    As I already mentioned, it should just use the standard locale settings.

    The workaround is to install the Plasma desktop, which brings with it the necessary dependency and kOrganizer than works as expected.
    You mean, it works in XFCE as expected too if you just install the Plasma desktop?

    Of course, I am hoping Wolfi sees this, as he is usually about the sharpest at getting to the root of a kde problem.
    Sure I see it, but what should I do about it?

    There have been fixes/improvements to the timezone handling recently, IIRC, I'm not sure if they would fix your problem though.
    And it would be impossible to backport them to 42.3 anyway because the libraries (kcalcore in particular) have seen major reworks too that make them incompatible with earlier versions (they have been ported away from kdelibs4support and use Qt5's classes now, which also caused API changes).

    That said, and considering that the calendar classes still use kdelibs4support in 42.3's KDEPIM, maybe the "missing" dependency is the package kdelibs4support?
    This does contain some locale related files (in /usr/share/kf5/locale/countries/), and is not installed by default... (if Plasma is not installed)
    Last edited by wolfi323; 24-Jan-2018 at 04:12.

  3. #3
    Join Date
    Nov 2013
    Location
    Kamloops, BC, Canada
    Posts
    4,029

    Default Re: kOrganizer stuck on UTC time, bug not acted on, 42.2 is going EOL

    Quote Originally Posted by wolfi323 View Post
    As I already mentioned, it should just use the standard locale settings.
    Yes, I agree, it should.
    But, as far as I can see, it doesn't. My locale settings check out issuing the commands you gave me in a previous thread last September, but kOrganizer in 42.3 Xfce is locked to UTC.

    You mean, it works in XFCE as expected too if you just install the Plasma desktop?
    Yes, exactly. On my test machine, I installed only the Plasma 5 Desktop Pattern, did not bother with the KDE Desktop Environment Pattern, and kOrganizer immediately started working as expected.

    Sure I see it, but what should I do about it?
    Heh. I was just hoping you could point to whatever specific particle or particles get pulled in that causes that to be fixed. Perhaps then I could just pull those one or two pieces in.

    Or, perhaps I could get them added as kOrganizer dependencies upstream?

    I do not want you spending any additional time fixing it, was not asking that, as I know your plate is already overflowing.

    I am not yet good at isolating such things, hope to become so some day in order to start helping out with bug fixing and maintaining in openSUSE. In the meantime, I need to ask the brilliant coders and fixers, such as you, for help.

    There have been fixes/improvements to the timezone handling recently, IIRC, I'm not sure if they would fix your problem though.
    And it would be impossible to backport them to 42.3 anyway because the libraries (kcalcore in particular) have seen major reworks too that make them incompatible with earlier versions (they have been ported away from kdelibs4support and use Qt5's classes now, which also caused API changes).
    Yes, that would be unnecessary work for something this small, as we are approaching 15 not too far down the road now.

    That said, and considering that the calendar classes still use kdelibs4support in 42.3's KDEPIM, maybe the "missing" dependency is the package kdelibs4support?
    This does contain some locale related files (in /usr/share/kf5/locale/countries/), and is not installed by default... (if Plasma is not installed)
    Okay, when I upgrade this PC from 42.2 to 42.3 within the next couple days, I will test that to see if it is the answer. I will report back when I find out.

    Thanks for taking the time to give me some guidance, Wolfi.
    "Take a Walk on a Sunny Day, Greet everyone along the way, and Make Somebody Smile, Today"
    Gerry Jack Macks"Walk On A Sunny Day" GerryJackMacks.net

  4. #4

    Default Re: kOrganizer stuck on UTC time, bug not acted on, 42.2 is going EOL

    Quote Originally Posted by Fraser_Bell View Post
    Or, perhaps I could get them added as kOrganizer dependencies upstream?
    Package dependencies are specified by the rpm package (in the specfile), not by upstream's source code.
    So, a missing package dependency is solely a downstream/distribution problem.

    If it's really kdelibs4support that's missing, then that doesn't only affect korganizer though.
    Without it, other things are not working properly either, e.g. gwenview and kolourpaint can't open (or write) certain image files.
    https://bugzilla.opensuse.org/show_bug.cgi?id=1001276
    https://bugzilla.opensuse.org/show_bug.cgi?id=1055759

    The gwenview bug has been fixed for 42.2 by adding a requirement to gwenview, but that got lost in a later update.
    (and it's not the proper solution anyway IMHO, as it's actually libKF5KDELibs4Support5 that uses/needs those files, not the applications...)

    I plan to add a dependency to libKF5KDELibs4Support5 anyway (just haven't gotten round to do that yet, but in my defense, there hasn't been any response in the kolourpaint bug report either... ).

  5. #5
    Join Date
    Nov 2013
    Location
    Kamloops, BC, Canada
    Posts
    4,029

    Default Re: kOrganizer stuck on UTC time, bug not acted on, 42.2 is going EOL

    Quote Originally Posted by wolfi323 View Post
    Package dependencies are specified by the rpm package (in the specfile), not by upstream's source code.
    So, a missing package dependency is solely a downstream/distribution problem.
    Okay, so then if I was up to speed, so to speak, I would have been able to supply the fix, make myself usefull for once.

    Someday, I hope...

    I just need to find a "first steps" coach who has time to walk me through isolating and identifying a bug or two, then how to fix it and submit the fix.

    After that, I can get myself up and running.

    If it's really kdelibs4support that's missing, then that doesn't only affect korganizer though.
    Without it, other things are not working properly either, e.g. gwenview and kolourpaint can't open (or write) certain image files.
    https://bugzilla.opensuse.org/show_bug.cgi?id=1001276
    https://bugzilla.opensuse.org/show_bug.cgi?id=1055759

    The gwenview bug has been fixed for 42.2 by adding a requirement to gwenview, but that got lost in a later update.
    (and it's not the proper solution anyway IMHO, as it's actually libKF5KDELibs4Support5 that uses/needs those files, not the applications...)

    I plan to add a dependency to libKF5KDELibs4Support5 anyway (just haven't gotten round to do that yet, but in my defense, there hasn't been any response in the kolourpaint bug report either... ).
    Okay, thanks for the info.

    As for gwenview and kolourpaint, I do not use either, so I cannot comment. I use digiKam and showFoto for my photos and the GIMP for advanced photo work. They all work as expected.

    Any artwork I do is done in OpenOffice Draw.

    When I update to 42.3 on this laptop, I will pull in and test the kdelibs4support and will let you know right away what the result is.

    Or, would libKF5KDELibs4Support5 be the answer, once the dependency is added? If you would like, I could wait until you get around to that, then test it, if it is applicable. I can use Lightning in Thunderbird as a temporary calendar in the meantime.

    I know I could pull in the Plasma desktop to get kOrganizer working, but in the interests of tying up loose ends, I would be willing to wait as long as needed.

    If you wish, I could also test kolourpaint and gwenview for you at that time.

    ... and, no need to rush, because also in your defence is the fact that you are already super busy doing a lot for us. Which we are deeply gratefull for.
    "Take a Walk on a Sunny Day, Greet everyone along the way, and Make Somebody Smile, Today"
    Gerry Jack Macks"Walk On A Sunny Day" GerryJackMacks.net

  6. #6

    Default Re: kOrganizer stuck on UTC time, bug not acted on, 42.2 is going EOL

    Quote Originally Posted by Fraser_Bell View Post
    Someday, I hope...
    I just need to find a "first steps" coach who has time to walk me through isolating and identifying a bug or two, then how to fix it and submit the fix.

    After that, I can get myself up and running.
    Maybe this would help?
    https://en.opensuse.org/Portal:Packaging

    The first thing you need to know is how an RPM specfile is structured.

    It's not really rocket science though.
    Most importantly, the header describes meta information like package name/version and (build) requirements, the %prep section prepares the sources for the compilation (e.g. unpacking the source tarball and applying patches, in the easiest case this just contains a call to %setup which extracts the source code automatically), the %build section contains the commands to compile the code, the %install section installs the files.
    And then there's the %files section that specifies what files are actually part of the package.

    It's probably a good idea to look at an existing package/specfile (a simple one preferaby... ) and try to to understand it.
    Then you can just branch a package on OBS and try to do some changes.

    To fix a bug (and sometimes also to identify a bug), you'd need (some) programming knowledge though.
    KDE software is written in C++ for the most part.

    When I update to 42.3 on this laptop, I will pull in and test the kdelibs4support and will let you know right away what the result is.

    Or, would libKF5KDELibs4Support5 be the answer, once the dependency is added? If you would like, I could wait until you get around to that, then test it, if it is applicable. I can use Lightning in Thunderbird as a temporary calendar in the meantime.
    No, you need to install kdelibs4support.
    This is currently not installed by default, only plasma5-workspace requires it.

    Adding a requirement to libKF5KDELibs4Support5 (which is what I plan to do, probably this weekend) will pull it in automatically whenever any application using libKF5KDELibs4Support5 is installed.
    But there's no need to wait for that update. Just install kdelibs4support manually.

    If you wish, I could also test kolourpaint and gwenview for you at that time.
    No need.
    The gwenview issue was examined and fixed back then, so it's clear that installing kdelibs4support (adding a dependency) will fix it.
    I am quite sure about kolourpaint as well, and could easily test that myself too.
    Last edited by wolfi323; 26-Jan-2018 at 01:45.

  7. #7
    Join Date
    Nov 2013
    Location
    Kamloops, BC, Canada
    Posts
    4,029

    Default Re: kOrganizer stuck on UTC time, bug not acted on, 42.2 is going EOL

    Quote Originally Posted by wolfi323 View Post
    ... yep, been there a few times. Easy to understand for someone who already knows all that.

    Not so easy to understand if you are trying to learn from it.

    The first thing you need to know is how an RPM specfile is structured.

    It's not really rocket science though.
    Most importantly, the header describes meta information like package name/version and (build) requirements, the %prep section prepares the sources for the compilation (e.g. unpacking the source tarball and applying patches, in the easiest case this just contains a call to %setup which extracts the source code automatically), the %build section contains the commands to compile the code, the %install section installs the files.
    And then there's the %files section that specifies what files are actually part of the package.
    Thanks, actually helps.

    It's probably a good idea to look at an existing package/specfile (a simple one preferaby... ) and try to to understand it.
    Then you can just branch a package on OBS and try to do some changes.
    Not a bad idea at all, I will do just that.

    I have been fiddling with OBS and OSC.

    To fix a bug (and sometimes also to identify a bug), you'd need (some) programming knowledge though.
    KDE software is written in C++ for the most part.
    I have some, mostly long time ago and mostly Pascal, but the ideas are the same.

    However, I do know there are enough similarities between Pascal and C that tends to make certain mistakes common, such as Assignment vs. Comparison, omitting parentheses on function calls, the difference between character arrays and character pointers, and trying to remember that C is case sensitive when it comes to identifiers, and more.

    But, I am working on it.

    What mostly makes a difference, though, is how well the programmer documents the code (or, doesn't).

    No, you need to install kdelibs4support.
    This is currently not installed by default, only plasma5-workspace requires it.

    Adding a requirement to libKF5KDELibs4Support5 (which is what I plan to do, probably this weekend) will pull it in automatically whenever any application using libKF5KDELibs4Support5 is installed.
    But there's no need to wait for that update. Just install kdelibs4support manually.
    Okay, thanks.
    "Take a Walk on a Sunny Day, Greet everyone along the way, and Make Somebody Smile, Today"
    Gerry Jack Macks"Walk On A Sunny Day" GerryJackMacks.net

  8. #8
    Join Date
    Nov 2013
    Location
    Kamloops, BC, Canada
    Posts
    4,029

    Default Re: kOrganizer stuck on UTC time, bug not acted on, 42.2 is going EOL

    Quote Originally Posted by wolfi323 View Post
    No, you need to install kdelibs4support.
    This is currently not installed by default, only plasma5-workspace requires it.
    Okay, installed 42.3, installed kOrganizer, pulled kdelibs4support in, and this did not solve the problem.

    The UTC problem persisted.

    So, I then pulled in the KDE Plasma 5 Desktop pattern.

    UTC problem gone.

    So, it is something else in that pattern that solves the UTC problem in kOrganizer.
    "Take a Walk on a Sunny Day, Greet everyone along the way, and Make Somebody Smile, Today"
    Gerry Jack Macks"Walk On A Sunny Day" GerryJackMacks.net

  9. #9

    Default Re: kOrganizer stuck on UTC time, bug not acted on, 42.2 is going EOL

    Quote Originally Posted by Fraser_Bell View Post
    So, it is something else in that pattern that solves the UTC problem in kOrganizer.
    Well, you could check what packages got installed, and then try to install them one-by-one.

    I don't see anything immediately obvious when looking at the pattern's requires and recommends...

  10. #10
    Join Date
    Nov 2013
    Location
    Kamloops, BC, Canada
    Posts
    4,029

    Default Re: kOrganizer stuck on UTC time, bug not acted on, 42.2 is going EOL

    Quote Originally Posted by wolfi323 View Post
    Well, you could check what packages got installed, and then try to install them one-by-one.
    I might do that, someday, but of course that will be on a test machine, and it will take a long time because there are a lot of packages.

    Of course, some can probably be eliminated for obvious reasons. And, I would start with what *might* be most likely, first.

    I don't see anything immediately obvious when looking at the pattern's requires and recommends...[/QUOTE]

    I don't, either. Except, maybe, something to do with Akonadi.

    ... but, it is not necessary for my day-to-day operations, as the Plasma5 pattern solves the immediate problem.

    In regards to that, I have a follow-up question:

    Since I am running exclusively in Xfce, is there any possible reason why I would not want to pull in the Plasma5 pattern?

    As far as I understand it -- and you can correct me if I am wrong -- all that does about resources is that it takes up a bit more of my disk space, which is a complete non-issue, as I have plenty to spare in / and /home.

    If I am not logged in to KDE/Plasma, the only parts running are those that are being used for the KDE apps I am running in Xfce.

    Is that correct?
    "Take a Walk on a Sunny Day, Greet everyone along the way, and Make Somebody Smile, Today"
    Gerry Jack Macks"Walk On A Sunny Day" GerryJackMacks.net

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •