[opensuse-kde] Updating to KDE SC 4.13 from KDE:Current
In the next hours KDE:Current will publish KDE 4.13 SC. As that this release comes with a big change (Nepomuk -> Baloo), we would like some simple steps in order to perform the right upgrade. Before the upgrade In order to migrate data automatically from the Nepomuk store to the new format (used by Baloo), you will need Nepomuk up and running, and just for the time needed for the migration. Ensure that Nepomuk is running before the update (in System Settings > Desktop Search). This is only necessary in case Nepomuk is in use on the system. The upgrade itself * If you are already using KDE:Current then the upgrade should be a simple "zypper up" or upgrade packages through YaST Software Management. * If you are not yet using KDE:Current, then please follow the instructions on https://en.opensuse.org/KDE_repositories#Current_KDE_SC_release on how to add the necessary repositories. After adding them, a zypper dup is required to ensure that all the KDE packages are coming from KDE:Current. Please do not remove nepomuk, as that otherwise the migration to baloo will fail !! Also after the upgrade please make sure that the following package is installed "baloo-file". After this check, log off and back on. The migrator will then run and move all the data that can be migrated to the new system. It will also turn off Nepomuk at the end of the migration. At this moment it would be safe to remove the nepomuk related packages like nepomuk-core, libnepomukwidgets, soprano*, strigi, virtuoso and shared- desktop-ontologies. There are only a few packages left that are still requiring the nepomuk-framework (like bangarang, kweshtunotes, etc). Using Baloo Unlike the 'include folders to be indexed', Baloo prefers to index everything and exclude unwanted folders explicitly. With the standard setup, Baloo will index all files and directories below the home-directory. All other filesystems are indicated as omitted. This can be changed by deleting the respective entries. Unfortunately it is not possible to switch baloo off through systemsettings. If baloo is not wanted on the system, then the package "baloo-file" needs to be removed to prevent files being indexed. The package "baloo-pim" (only present when kdepim is installed) can be removed if no search capabilities are required for kmail. The only search client currently available for baloo, is the package called milou. Milou can be placed in the panel for easy access and the usage is quite simple. The search term is indicated and search results are shown for files, emails, etc. In the Milou settings, the categories from which results are shown can be selected. Milou can NOT be placed in the systray, as that this would cause the plasma desktop to crash upon login. Tags on files are no longer stored inside the database, but stored in the extended file attributes (xattr), which are stored in separate files on the filesystem. Known issues with KDE 4.13 - The initial indexing can be heavy on I/O especially if there are large text files: either one waits till the indexing is complete (this step is done only once), or the folder containing such files is excluded using System Settings. - Some data will be lost during the migration: in particular, emails will have to be re-indexed, and file<->activity associations, if used, will not be preserved. - Milou causes the Plasma-desktop to crash if it is placed in the systray !! Regards openSUSE KDE Community Team -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Thu, 24 Apr 2014 21:02:09 +0100, Raymond Wooninck <tittiatcoke@gmail.com> wrote:
In the next hours KDE:Current will publish KDE 4.13 SC. As that this release comes with a big change (Nepomuk -> Baloo), we would like some simple steps in order to perform the right upgrade.
Before the upgrade
In order to migrate data automatically from the Nepomuk store to the new format (used by Baloo), you will need Nepomuk up and running, and just for the time needed for the migration. Ensure that Nepomuk is running before the update (in System Settings > Desktop Search). This is only necessary in case Nepomuk is in use on the system.
The upgrade itself
* If you are already using KDE:Current then the upgrade should be a simple "zypper up" or upgrade packages through YaST Software Management. * If you are not yet using KDE:Current, then please follow the instructions on https://en.opensuse.org/KDE_repositories#Current_KDE_SC_release on how to add the necessary repositories. After adding them, a zypper dup is required to ensure that all the KDE packages are coming from KDE:Current.
Please do not remove nepomuk, as that otherwise the migration to baloo will fail !! Also after the upgrade please make sure that the following package is installed "baloo-file". After this check, log off and back on. The migrator will then run and move all the data that can be migrated to the new system. It will also turn off Nepomuk at the end of the migration.
At this moment it would be safe to remove the nepomuk related packages like nepomuk-core, libnepomukwidgets, soprano*, strigi, virtuoso and shared- desktop-ontologies. There are only a few packages left that are still requiring the nepomuk-framework (like bangarang, kweshtunotes, etc).
Using Baloo
Unlike the 'include folders to be indexed', Baloo prefers to index everything and exclude unwanted folders explicitly. With the standard setup, Baloo will index all files and directories below the home-directory. All other filesystems are indicated as omitted. This can be changed by deleting the respective entries. Unfortunately it is not possible to switch baloo off through systemsettings. If baloo is not wanted on the system, then the package "baloo-file" needs to be removed to prevent files being indexed. The package "baloo-pim" (only present when kdepim is installed) can be removed if no search capabilities are required for kmail.
The only search client currently available for baloo, is the package called milou. Milou can be placed in the panel for easy access and the usage is quite simple. The search term is indicated and search results are shown for files, emails, etc. In the Milou settings, the categories from which results are shown can be selected. Milou can NOT be placed in the systray, as that this would cause the plasma desktop to crash upon login.
Tags on files are no longer stored inside the database, but stored in the extended file attributes (xattr), which are stored in separate files on the filesystem.
Known issues with KDE 4.13
- The initial indexing can be heavy on I/O especially if there are large text files: either one waits till the indexing is complete (this step is done only once), or the folder containing such files is excluded using System Settings. - Some data will be lost during the migration: in particular, emails will have to be re-indexed, and file<->activity associations, if used, will not be preserved. - Milou causes the Plasma-desktop to crash if it is placed in the systray !!
Regards openSUSE KDE Community Team
Thanks Seems to be working fine, except for knotes? Is there a known issue there? -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Friday 25 April 2014 05:17:45 Carl Fletcher wrote:
Thanks
Seems to be working fine, except for knotes? Is there a known issue there?
Hi Carl, Can you shed a little more light on the issue with knotes ? There is no known issue, so I would like to know a little more about what kind of error messages you get, etc. Thanks Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Thu, 24 Apr 2014 21:02:09 +0100, Raymond Wooninck <tittiatcoke@gmail.com> wrote:
In the next hours KDE:Current will publish KDE 4.13 SC. As that this release comes with a big change (Nepomuk -> Baloo), we would like some simple steps in order to perform the right upgrade.
Before the upgrade
In order to migrate data automatically from the Nepomuk store to the new format (used by Baloo), you will need Nepomuk up and running, and just for the time needed for the migration. Ensure that Nepomuk is running before the update (in System Settings > Desktop Search). This is only necessary in case Nepomuk is in use on the system.
The upgrade itself
* If you are already using KDE:Current then the upgrade should be a simple "zypper up" or upgrade packages through YaST Software Management. * If you are not yet using KDE:Current, then please follow the instructions on https://en.opensuse.org/KDE_repositories#Current_KDE_SC_release on how to add the necessary repositories. After adding them, a zypper dup is required to ensure that all the KDE packages are coming from KDE:Current.
Please do not remove nepomuk, as that otherwise the migration to baloo will fail !! Also after the upgrade please make sure that the following package is installed "baloo-file". After this check, log off and back on. The migrator will then run and move all the data that can be migrated to the new system. It will also turn off Nepomuk at the end of the migration.
At this moment it would be safe to remove the nepomuk related packages like nepomuk-core, libnepomukwidgets, soprano*, strigi, virtuoso and shared- desktop-ontologies. There are only a few packages left that are still requiring the nepomuk-framework (like bangarang, kweshtunotes, etc).
Using Baloo
Unlike the 'include folders to be indexed', Baloo prefers to index everything and exclude unwanted folders explicitly. With the standard setup, Baloo will index all files and directories below the home-directory. All other filesystems are indicated as omitted. This can be changed by deleting the respective entries. Unfortunately it is not possible to switch baloo off through systemsettings. If baloo is not wanted on the system, then the package "baloo-file" needs to be removed to prevent files being indexed. The package "baloo-pim" (only present when kdepim is installed) can be removed if no search capabilities are required for kmail.
The only search client currently available for baloo, is the package called milou. Milou can be placed in the panel for easy access and the usage is quite simple. The search term is indicated and search results are shown for files, emails, etc. In the Milou settings, the categories from which results are shown can be selected. Milou can NOT be placed in the systray, as that this would cause the plasma desktop to crash upon login.
Tags on files are no longer stored inside the database, but stored in the extended file attributes (xattr), which are stored in separate files on the filesystem.
Known issues with KDE 4.13
- The initial indexing can be heavy on I/O especially if there are large text files: either one waits till the indexing is complete (this step is done only once), or the folder containing such files is excluded using System Settings. - Some data will be lost during the migration: in particular, emails will have to be re-indexed, and file<->activity associations, if used, will not be preserved. - Milou causes the Plasma-desktop to crash if it is placed in the systray !!
Regards openSUSE KDE Community Team
Ray kernelcruncher@kernelcruncher:~> knotes knotes: symbol lookup error: /usr/lib64/libpimcommon.so.4: undefined symbol: _ZTIN6KGAPI25Drive4FileE -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Friday 25 April 2014 07:19:45 Carl Fletcher wrote:
Ray
kernelcruncher@kernelcruncher:~> knotes knotes: symbol lookup error: /usr/lib64/libpimcommon.so.4: undefined symbol: _ZTIN6KGAPI25Drive4FileE
Hi Carl, :) This is fortunately easy to resolve. Can you perform either a zypper dup again or install the package libkgapi2. The package libkgapi2 would enable google drive integration. Regards Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Fri, 25 Apr 2014 07:33:31 +0100, Raymond Wooninck <tittiatcoke@gmail.com> wrote:
On Friday 25 April 2014 07:19:45 Carl Fletcher wrote:
Ray
kernelcruncher@kernelcruncher:~> knotes knotes: symbol lookup error: /usr/lib64/libpimcommon.so.4: undefined symbol: _ZTIN6KGAPI25Drive4FileE
Hi Carl,
:) This is fortunately easy to resolve. Can you perform either a zypper dup again or install the package libkgapi2. The package libkgapi2 would enable google drive integration.
Regards
Raymond
Thanks Solved It was installed but for some reason the switch was to OSS -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Friday, April 25, 2014 07:49:51 AM Carl Fletcher wrote:
On Fri, 25 Apr 2014 07:33:31 +0100, Raymond Wooninck
<tittiatcoke@gmail.com> wrote:
On Friday 25 April 2014 07:19:45 Carl Fletcher wrote:
Ray
kernelcruncher@kernelcruncher:~> knotes knotes: symbol lookup error: /usr/lib64/libpimcommon.so.4: undefined symbol: _ZTIN6KGAPI25Drive4FileE
Hi Carl,
:) This is fortunately easy to resolve. Can you perform either a zypper
dup again or install the package libkgapi2. The package libkgapi2 would enable google drive integration.
Regards
Raymond
Thanks Solved It was installed but for some reason the switch was to OSS
I solved by switching and replace system packages to install all packages from KDE:Current on YaST (zypper up gave too many options (e.g. break, downgrade, keep) for many packages. So, no more KMail, KAddress, KOrganizer, ToDo List, Journal, KNotes complaining about
knotes: symbol lookup error: /usr/lib64/libpimcommon.so.4: undefined symbol: _ZTIN6KGAPI25Drive4FileE
or other messages like above. At the end, a KNotes Migration Tool will pop up to choose where your Notes will be stored. No hassle at all. Hopefully useful for you. Regards, Rick Chung -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Hi, thank You for that! Dne Čt 24. dubna 2014 22:02:09, Raymond Wooninck napsal(a):
In the next hours KDE:Current will publish KDE 4.13 SC. As that this release comes with a big change (Nepomuk -> Baloo), we would like some simple steps in order to perform the right upgrade.
Before the upgrade
In order to migrate data automatically from the Nepomuk store to the new format (used by Baloo), you will need Nepomuk up and running, and just for the time needed for the migration. Ensure that Nepomuk is running before the update (in System Settings > Desktop Search). This is only necessary in case Nepomuk is in use on the system.
The upgrade itself
* If you are already using KDE:Current then the upgrade should be a simple "zypper up" or upgrade packages through YaST Software Management. * If you are not yet using KDE:Current, then please follow the instructions on https://en.opensuse.org/KDE_repositories#Current_KDE_SC_release on how to add the necessary repositories. After adding them, a zypper dup is required to ensure that all the KDE packages are coming from KDE:Current.
Please do not remove nepomuk, as that otherwise the migration to baloo will fail !! Also after the upgrade please make sure that the following package is installed "baloo-file". After this check, log off and back on. The migrator will then run and move all the data that can be migrated to the new system. It will also turn off Nepomuk at the end of the migration.
At this moment it would be safe to remove the nepomuk related packages like nepomuk-core, libnepomukwidgets, soprano*, strigi, virtuoso and shared- desktop-ontologies. There are only a few packages left that are still requiring the nepomuk-framework (like bangarang, kweshtunotes, etc). [...] Recently I reinstalled the system because of exchange of hard drive and even I copied all files from ~ to backup and back and I installed same packages in same versions, after the reinstall, some thinks related to Nepomuk and Akonadi were not working properly, so that I deleted them and set them up again. Now indexing of my big disk and a lot of e-mails etc. is still running (virtuoso-t fully consumes one CPU core). The question is if this matter for the migration. I'd guess it shouldn't, but still... All the best, Vojtěch
-- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux http://www.opensuse.org/ http://trapa.cz/
In data venerdì 25 aprile 2014 09:25:27, Vojtěch Zeisek ha scritto: Hello,
running (virtuoso-t fully consumes one CPU core). The question is if this matter for the migration. I'd guess it shouldn't, but still...
Aside a possible impact on system resources, no, it shouldn't affect the migration at all. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
I have also faced a glitch after update to 4.13 Lokalize does not show files in project overview anymore. Seems like it was using some of the nepomuk/indexing functionality, cause everything else is working fine. Life is pain. 2014-04-25 11:36 GMT+04:00 Luca Beltrame <lbeltrame@kde.org>:
In data venerdì 25 aprile 2014 09:25:27, Vojtěch Zeisek ha scritto:
Hello,
running (virtuoso-t fully consumes one CPU core). The question is if this matter for the migration. I'd guess it shouldn't, but still...
Aside a possible impact on system resources, no, it shouldn't affect the migration at all.
-- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
-- Regards, Minton. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Fri, 25 Apr 2014, Alexander Melentev wrote:
I have also faced a glitch after update to 4.13 Lokalize does not show files in project overview anymore. Seems like it was using some of the nepomuk/indexing functionality, cause everything else is working fine.
Same problem here: lokalize does not show files in project overview (the progress widget remains at 0% forever). I updated to 4.13 using YaST. All seems ok, except knotes (and lokalize). -- Eloy Cuadra -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Dne Pá 25. dubna 2014 09:36:03, Luca Beltrame napsal(a):
In data venerdì 25 aprile 2014 09:25:27, Vojtěch Zeisek ha scritto:
Hello,
running (virtuoso-t fully consumes one CPU core). The question is if this matter for the migration. I'd guess it shouldn't, but still...
Aside a possible impact on system resources, no, it shouldn't affect the migration at all.
Yes, it was smooth and everything seems to work fine. Good job! :-) V. -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux http://www.opensuse.org/ http://trapa.cz/
On Friday, April 25, 2014 02:04:33 PM Vojtěch Zeisek wrote:
Dne Pá 25. dubna 2014 09:36:03, Luca Beltrame napsal(a):
In data venerdì 25 aprile 2014 09:25:27, Vojtěch Zeisek ha scritto:
Hello,
running (virtuoso-t fully consumes one CPU core). The question is if this matter for the migration. I'd guess it shouldn't, but still...
Aside a possible impact on system resources, no, it shouldn't affect the migration at all.
Yes, it was smooth and everything seems to work fine. Good job! :-) V.
And when do we see 4.13 in Tumbleweed? -- Linux User 183145 using KDE4 and LXDE on a Pentium IV , powered by openSUSE 13.1 (i586) Kernel: 3.14.1-24.geafcebd-default KDE Development Platform: 4.12.4 19:33pm up 19:52, 5 users, load average: 0.85, 1.13, 1.07 -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Fri, Apr 25, 2014 at 09:04:17PM +0700, Constant Brouerius van Nidek wrote:
On Friday, April 25, 2014 02:04:33 PM Vojtěch Zeisek wrote:
Dne Pá 25. dubna 2014 09:36:03, Luca Beltrame napsal(a):
In data venerdì 25 aprile 2014 09:25:27, Vojtěch Zeisek ha scritto:
Hello,
running (virtuoso-t fully consumes one CPU core). The question is if this matter for the migration. I'd guess it shouldn't, but still...
Aside a possible impact on system resources, no, it shouldn't affect the migration at all.
Yes, it was smooth and everything seems to work fine. Good job! :-) V.
And when do we see 4.13 in Tumbleweed?
When I get GNOME 3.12 merged into it (it's currently building.) Although, with the upgrade instructions that seem to be needed for KDE 4.13, I'm pretty leary of not doing the upgrade in Tumbleweed, odds are people will not be able to do the "hot update" properly. How is that going to work for people running FACTORY? greg k-h -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Friday 25 April 2014 08:37:53 Greg KH wrote:
Although, with the upgrade instructions that seem to be needed for KDE 4.13, I'm pretty leary of not doing the upgrade in Tumbleweed, odds are people will not be able to do the "hot update" properly. How is that going to work for people running FACTORY?
Hi Greg, Can you elaborate a little on your reasoning here ? I don't quite follow it. KDE 4.13 brings a different search and tagging framework and therefore a migration is required. Therefore we gave some instructions on how to ensure that the migration will run. Factory already received KDE 4.13 with the first Beta which is about 1 month ago and also a number of oS 13.1 users switched to KDE:Distro:Factory to help testing the new KDE release and based on their experience, we gave these instructions. If you feel that these instructions are too much for the Tumbleweed users, then I guess Tumbleweed will remain on KDE 4.12.4 until it switches to oS 13.2 Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Fri, Apr 25, 2014 at 05:47:52PM +0200, Raymond Wooninck wrote:
On Friday 25 April 2014 08:37:53 Greg KH wrote:
Although, with the upgrade instructions that seem to be needed for KDE 4.13, I'm pretty leary of not doing the upgrade in Tumbleweed, odds are people will not be able to do the "hot update" properly. How is that going to work for people running FACTORY?
Hi Greg,
Can you elaborate a little on your reasoning here ? I don't quite follow it. KDE 4.13 brings a different search and tagging framework and therefore a migration is required. Therefore we gave some instructions on how to ensure that the migration will run.
I understand that, it's just something that users are not used to doing when doing a "normal" 'zypper dup' update.
Factory already received KDE 4.13 with the first Beta which is about 1 month ago and also a number of oS 13.1 users switched to KDE:Distro:Factory to help testing the new KDE release and based on their experience, we gave these instructions.
If you feel that these instructions are too much for the Tumbleweed users, then I guess Tumbleweed will remain on KDE 4.12.4 until it switches to oS 13.2
How will you do an update in 13.2 if you require the upgrade to happen while a user is logged in? That update needs to happen "like normal" without any additional steps required, right? Same thing for Tumbleweed. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Friday 25 April 2014 08:57:13 Greg KH wrote:
I understand that, it's just something that users are not used to doing when doing a "normal" 'zypper dup' update.
Ok, then I guess the only way is (as I indicated already) that Tumbleweed remains on KDE 4.12.4 as that the migration to Baloo doesn't fall under a normal zypper dup update. It is strange for me that this migration has been done by people that are running oS 12.3 and oS 13.1, but that we can not ask this from Tumbleweed users. But Tumbleweed is your baby, so you have the right to reject a possible upgrade of KDE. If Tumbleweed users would be happy with this, I don't know. But as agreed before KDE:Current will NOT be build against Tumbleweed as that this would clash with the ideas behind Tumbleweed. Regards Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Fri, Apr 25, 2014 at 06:12:15PM +0200, Raymond Wooninck wrote:
On Friday 25 April 2014 08:57:13 Greg KH wrote:
I understand that, it's just something that users are not used to doing when doing a "normal" 'zypper dup' update.
Ok, then I guess the only way is (as I indicated already) that Tumbleweed remains on KDE 4.12.4 as that the migration to Baloo doesn't fall under a normal zypper dup update.
Then how are you going to handle the update for users when they move to the next openSUSE release?
It is strange for me that this migration has been done by people that are running oS 12.3 and oS 13.1, but that we can not ask this from Tumbleweed users.
Again, how are 13.1 users going to handle this? How are 12.3 users going to handle it? Tumbleweed should not be any different, right?
But Tumbleweed is your baby, so you have the right to reject a possible upgrade of KDE. If Tumbleweed users would be happy with this, I don't know. But as agreed before KDE:Current will NOT be build against Tumbleweed as that this would clash with the ideas behind Tumbleweed.
I want to update to the latest KDE, I just don't want to see people with broken machines because they did not know the "special" upgrade steps. Because really, almost no Tumbleweed user reads the Factory mailing list... thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Friday 25 April 2014 09:28:15 Greg KH wrote:
Then how are you going to handle the update for users when they move to the next openSUSE release?
Euh ? I think that we have a misunderstanding here ? These few steps are only required when switching to KDE 4.13. For the first time we gave some kind of upfront information to our KDE:Current users (indicated on opensuse-kde, opensuse mailinglist, facebook and google+ communities). This information contained some best practices on how to ensure that the migration of Nepomuk data to baloo works and what the prerequisites are. Also we outlined what they can expect from baloo, how to set it up, etc. Also we listed what issues are known with this release. So all in all more like release notes, similar to what is being drafted for a new openSUSE release. The actual installation prerequisite is that Nepomuk must be running (otherwise no data is migrated). The upgrade is performed normally with a zypper dup for the best result. Once the upgrade is finished the user should logout and login again to start the migration process.
Again, how are 13.1 users going to handle this? How are 12.3 users going to handle it? Tumbleweed should not be any different, right?
And I am telling you that KDE:Current contains KDE 4.13 and that 13.1 and 12.3 users have been upgrading to KDE 4.13 successfully using the KDE:Current repository. I hope that people have read my email/posts regarding some additional information, but so far we haven't gotten any complaints.
I want to update to the latest KDE, I just don't want to see people with broken machines because they did not know the "special" upgrade steps. Because really, almost no Tumbleweed user reads the Factory mailing list...
And I am wonder what kind of "special" upgrade steps you are talking about ? I wonder if you actually read my email on this mailinglist regarding the upgrade to KDE 4.13 or that you just saw the email and concluded on its length. Regards Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Fri, Apr 25, 2014 at 06:59:55PM +0200, Raymond Wooninck wrote:
On Friday 25 April 2014 09:28:15 Greg KH wrote:
Then how are you going to handle the update for users when they move to the next openSUSE release?
Euh ? I think that we have a misunderstanding here ? These few steps are only required when switching to KDE 4.13. For the first time we gave some kind of upfront information to our KDE:Current users (indicated on opensuse-kde, opensuse mailinglist, facebook and google+ communities). This information contained some best practices on how to ensure that the migration of Nepomuk data to baloo works and what the prerequisites are. Also we outlined what they can expect from baloo, how to set it up, etc. Also we listed what issues are known with this release. So all in all more like release notes, similar to what is being drafted for a new openSUSE release.
The actual installation prerequisite is that Nepomuk must be running (otherwise no data is migrated). The upgrade is performed normally with a zypper dup for the best result. Once the upgrade is finished the user should logout and login again to start the migration process.
Ok, I misunderstood, thinking that a "normal" zypper dup would not work properly for user data. If that's not the case then I have no problem doing the kde update in Tumbleweed. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Friday 25 April 2014 11:29:39 Greg KH wrote:
Ok, I misunderstood, thinking that a "normal" zypper dup would not work properly for user data. If that's not the case then I have no problem doing the kde update in Tumbleweed.
Ok :) As indicated a normal zypper dup would work fine. Let me know when you need help with the update itself. Regards Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data venerdì 25 aprile 2014 09:28:15, Greg KH ha scritto: Hello Greg,
Then how are you going to handle the update for users when they move to the next openSUSE release?
This "update" merely involves the user data, and not packages / system data. We posted this message to ensure that people knew what to do in case they had data stored in the Nepomuk store and wanted to use them after the change. If people do not have data there, the process is just a series of updates / obsoletes. Nothing unlike a normal update. That was the point of the text. For what it concerns TW, IMO it's just an update like any other. For the next openSUSE release, a simple text in the release notes should suffice. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
On Fri, Apr 25, 2014 at 07:33:03PM +0200, Luca Beltrame wrote:
In data venerdì 25 aprile 2014 09:28:15, Greg KH ha scritto:
Hello Greg,
Then how are you going to handle the update for users when they move to the next openSUSE release?
This "update" merely involves the user data, and not packages / system data. We posted this message to ensure that people knew what to do in case they had data stored in the Nepomuk store and wanted to use them after the change.
If people do not have data there, the process is just a series of updates / obsoletes. Nothing unlike a normal update. That was the point of the text. For what it concerns TW, IMO it's just an update like any other.
For the next openSUSE release, a simple text in the release notes should suffice.
Ok, I misunderstood then, sorry about that. I'll look into the kde update in tumbleweed once the gnome stuff settles down, so sometime next week, hopefully. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
* Greg KH <gregkh@linux.com> [04-25-14 12:26]: [...]
I want to update to the latest KDE, I just don't want to see people with broken machines because they did not know the "special" upgrade steps. Because really, almost no Tumbleweed user reads the Factory mailing list...
No, "factory" is *the* place to discuss tw and users posing questions in "opensuse" are directed/incouraged to post to "factory". tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Fri, 25 Apr 2014 16:47:52 +0100, Raymond Wooninck <tittiatcoke@gmail.com> wrote:
Tumbleweed will remain on KDE 4.12.4 until it switches to oS 13.2
Thinking of 13.2 What are the plans for kde there? Great work on this current update though Raymond. * For folks watching this thread - It's OK to loose the network management stuff during the upgrade. It made me take a second look! But the changes are a great improvement. I'd just like to see a slightly better implementation of the multi screens arrangement with mirroring. It's much easier in Gnome. Still haven't really figured it in kde... -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data venerdì 25 aprile 2014 18:08:24, Carl Fletcher ha scritto: Hello Carl,
Thinking of 13.2 What are the plans for kde there?
The current plan is to use the latest 4.x series available from KDE at the time. For the corageous and people who *know what they are doing* we'll offer KF5 / Plasma Next as an *option* (and not as default). -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
On Fri, 25 Apr 2014 18:20:16 +0100, Luca Beltrame <lbeltrame@kde.org> wrote:
The current plan is to use the latest 4.x series available from KDE at the time. For the corageous and people who *know what they are doing* we'll offer KF5 / Plasma Next as an *option* (and not as default).
Right OK I'll probably sandbox KF5 at some point -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Friday 25 April 2014 19:08:24 Carl Fletcher wrote:
I'd just like to see a slightly better implementation of the multi screens arrangement with mirroring. It's much easier in Gnome. Still haven't really figured it in kde...
See https://bugs.kde.org/333216 Christoph Feck (kdepepo) -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
https://xkcd.com/349/ -- "Politics is the art of appearing candid and completely open, while concealing as much as possible." -- Brian Herbert, -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
participants (13)
-
Alexander Melentev -
Anton Aylward -
Carl Fletcher -
Christoph Feck -
Constant Brouerius van Nidek -
Eloy Cuadra -
Greg KH -
Greg KH -
Luca Beltrame -
Patrick Shanahan -
Raymond Wooninck -
Rick Chung -
Vojtěch Zeisek