Bug 3077

Hi Maciej, 
what version of TDE have you upgraded to?
Since R14.0.0 TDE uses a separate .trinity folder and comes with an import script that reads the KDE3 settings and replicate/update them into the trinity settings. No changes to the KDE3 folder are done, so going back to KDE3 should always be possible.

Regarding point 2 and 3, perhaps those settings are not migrated, we will have to double check on that.

Hello Michele,

> what version of TDE have you upgraded to?

R14 for openSUSE Tumbleweed.

> No changes to the KDE3 folder are
> done,

Well, I believe in intension, but I report what I witnessed (and I now there is always some surprise in code :-) ). Those data were removed from KDE3.

> so going back to KDE3 should always be possible. 

If the files are just moved from one directory (KDE3) to the other (Trinity) then moving back of course should be possible. But "moving" should not happen in the first place, after all it could be shared home partition (my case).

> Regarding point 2 and 3, perhaps those settings are not migrated,
> we will have to double check on that.

I am not reporting problem of not migrating those settings, please look (not very good example, but stay with me) -- you have to copy CD disc and you would like to burn a copy in double disc drive. After copying the original disc was stuck, overheated and in result damaged, and the destination disc was not fully burnt because of some drive malfuction.

This report is NOT abot the target disc not being copied properly, this report IS about the original disc being damaged.

I wrote this to be 200% crystal clear what I am reporting, and to avoid unecessary checking. I am not testing Trininity for successul migration (for now), I am checking if Trininy didn't damage the original KDE3 files -- and since it did, here is this report.

If this would be of any help, but I hope we could avoid it, I could undo migration, install Trinity again paying closer attention where something is changed. But I hope at least KWallet issue is easier to track in scripts, because it is single file/directory.

Hi Maciej, 
thanks for your reporting and please do not misunderstand me. I am NOT doubting what you said, just explaining what normally should be happening.

During the first startup, the script r14-xdg-update is called and from there a migratekde3 script is called. This makes a copy of the kde3 folder into .trinity and then all subsequent updates should be happening there, not in the kde3 folder.

https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/src/branch/master/migratekde3#L95

Of course bugs and mistakes are always there, so it is possible you could have run into a new problem. If you have the time and the will to retry the migration and look out for problems, that would be certainly appreciated and if we can find where the problem is we can later fix it in time for the next release.

You could add additional log messages to these scritps before your first login, so to better trace what is happening in the code.
/opt/trinity/bin/starttde
/opt/trinity/bin/r14-xdg-update
/opt/trinity/bin/migratekde3

To repeat the process quickly, it should be sufficient to delete your ~/.trinity folder and restore a copy of your ~/kde3 folder from CLI, then login in TDE.

Damaging kde3 settings is definitely a blocker, so if this is a new bug we should definitely give him a detailed look.

Hello Michele,

> You could add additional log messages to these scritps before your
> first login, so to better trace what is happening in the code.
> /opt/trinity/bin/starttde
> /opt/trinity/bin/r14-xdg-update
> /opt/trinity/bin/migratekde3

I looked into 3 of them and I didn't find anything suspicious, but since r14... makes most changes I executed it, with no data loss. Hmm...

> To repeat the process quickly, it should be sufficient to delete
> your ~/.trinity folder and restore a copy of your ~/kde3 folder
> from CLI, then login in TDE.

Here is interesting thing. I don't have .trinity folder at all, just .kde and now I can see there are several apps which landed in the .kde folder, like tdewallet. Maybe it could be the reason for alteration of KDE, if TDE apps thoughts it is legal to change .kde folder (because it somehow became TDE folder)...

Apart from this all I can add for now, that so far I logged into TDE twice, first time just right after initial install (of TDE) and restart -- there was no background in desktop, and pretty much everything looked pretty barebone.
The second time (15 minutes ago) I had TDE login manager kicked in, after starting TDE (it took some time, second migration?) I had proper TDE background in the desktop, so it looked like some things "ticked" into their places.

I will run some virtual machine and do future tests with it, because as for today I can see each run in a bit different and I am more and more afraid that at some point it might break (with my help too :-) ).

Hi Maciej,
if you don't have the .trinity folder, something is not working as it should during the first run process.
.trinity folder is created by the "disk_space_test" function, so if you don't have such folder it means it is not getting called. Assuming the migratekde3 script is being called (you can add some log messages to help making sure of that if needed), then I guess the reason has something to do with your .kde folder.

If the folder was called .kde3, it would be called, see here:
https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/src/branch/master/migratekde3#L205

But since your folder is called .kde, there are additional checks to make sure the folder refers to a kde3 installation. See here and following lanes.
https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/src/branch/master/migratekde3#L213

I suggest you check in details if the migratekde3 script is called and what path of execution is followed inside that script. Perhaps we are able to identify a new bug that went unnoticed so far :-)

I am simply puzzled what happened, magic? ;-) I hate those moments.

I opt for closing this report simply because I am unable to recreate the issues I described. I.e. I am sure that it happened but I cannot nail it, what was the trigger.

So unless I found something new, let's keep it out of active reports.

Ok, sounds good.
Feel free to reopen the bug if you are able to reproduce it again :-)