Tim, Darrell, All,
Quick update. I removed 3.5.12 and replaced it with R 14.0.0 on one of my boxes. (configured with tmd as the DM) Everything launched fine. (though the default tdm theme had the ugly XDG login instead of the normal tde gradient one)
All has worked really well.
However, I did hit a bug right off the bat. After configuring panels (menu checkbox to show settings submenu in kmenu) I tried to launch kcontrol from kmenu->Settings->Control Center -- Nothing happened. I ended up having to launch it with Alt+F2 -> kcontrol.
Has this been seen before? If not, I'll file it, but it seems I remember this supposedly being 'fixed' already. This is from last nights build.
Quick update. I removed 3.5.12 and replaced it with R 14.0.0 on one of my boxes. (configured with tmd as the DM) Everything launched fine. (though the default tdm theme had the ugly XDG login instead of the normal tde gradient one)
All has worked really well.
However, I did hit a bug right off the bat. After configuring panels (menu checkbox to show settings submenu in kmenu) I tried to launch kcontrol from kmenu->Settings->Control Center -- Nothing happened. I ended up having to launch it with Alt+F2 -> kcontrol.
Has this been seen before? If not, I'll file it, but it seems I remember this supposedly being 'fixed' already. This is from last nights build.
I haven't seen that bug before. :-( When I rebuild my package set I uninstall all TDE packages and then install the new packages. I don't use my package manager. In other words, I'm basically installing fresh each time.
So we start with some basics:
Does this happen with a fresh $HOME/.trinity profile or an existing profile?
Did you install R14 fresh like I do or as an "upgrade" with your package manager?
Can you start other apps through the TDE menu?
Is kcontrol the only app that won't start through the menu?
Can you start individual kcontrol modules through the menu?
Do you have KDE3 installed concurrently with Trinity?
Do you have KDE4 installed concurrently with Trinity?
The default TDe menu is installed to /etc/trinity/xdg/menus and is named applications.menu. There is an optional menu installed in the same location named applications.menu-no-kde. That optional menu will prevent KDE# or KDE4 apps from appearing in the TDe menu when either is installed concurrently with TDE. Otherwise the default menu will show KDE3/KDE4 apps with a "[KDE]" appendage in the menu item.
So ensure the file date stamps of those files look correct and that you are not using an old menu. The applications.menu file should be 25,875 bytes in size and applications.menu-no-kde should be 16,182.
With that all said, as you updated to R14 from 3.5.12 rather than from 3.5.13, quite possibly there are some remaining corner cases that the r14-xdg-update script does not cover in your profile that might cause this problem.
Darrell
On 07/17/2012 03:16 PM, Darrell Anderson wrote:
Quick update. I removed 3.5.12 and replaced it with R 14.0.0 on one of my boxes. (configured with tmd as the DM) Everything launched fine. (though the default tdm theme had the ugly XDG login instead of the normal tde gradient one)
All has worked really well.
However, I did hit a bug right off the bat. After configuring panels (menu checkbox to show settings submenu in kmenu) I tried to launch kcontrol from kmenu->Settings->Control Center -- Nothing happened. I ended up having to launch it with Alt+F2 -> kcontrol.
Has this been seen before? If not, I'll file it, but it seems I remember this supposedly being 'fixed' already. This is from last nights build.
I haven't seen that bug before. :-( When I rebuild my package set I uninstall all TDE packages and then install the new packages. I don't use my package manager. In other words, I'm basically installing fresh each time.
So we start with some basics:
Does this happen with a fresh $HOME/.trinity profile or an existing profile?
Yes. Everything was ~/.kdemod with 3.5.12.
Did you install R14 fresh like I do or as an "upgrade" with your package manager?
Complete fresh install. Manually removed everything that was kdemod3 (3.5.12) including qt3, dbus-qt3, python2-dbus, blah, blah... everything with any dependency related to kde or qt3.
Can you start other apps through the TDE menu?
Yes. They work fine. But, now that you mention it I do still have a few stray menu entries that crawled in through ~/.config/menus. But that is the only stray config file that was left on the box :)
Is kcontrol the only app that won't start through the menu?
Yes, kmenu->Settings->Peripherals->Mouse for example launches the config right away. It is just the top 'Control Center' entry that does nothing.
Can you start individual kcontrol modules through the menu?
Yes.
Do you have KDE3 installed concurrently with Trinity?
No - bare box. The only other desktop installed is fluxbox. (twm is also installed)
Do you have KDE4 installed concurrently with Trinity?
Nope.
The default TDe menu is installed to /etc/trinity/xdg/menus and is named applications.menu. There is an optional menu installed in the same location named applications.menu-no-kde. That optional menu will prevent KDE# or KDE4 apps from appearing in the TDe menu when either is installed concurrently with TDE. Otherwise the default menu will show KDE3/KDE4 apps with a "[KDE]" appendage in the menu item.
So ensure the file date stamps of those files look correct and that you are not using an old menu. The applications.menu file should be 25,875 bytes in size and applications.menu-no-kde should be 16,182.
drwxr-xr-x 2 root root 4096 Jul 17 14:04 applications-merged -rw-r--r-- 1 root root 4124 May 15 05:40 applications.menu -rw-r--r-- 1 root root 11357 Jun 30 09:45 kde-applications.menu -rw-r--r-- 1 root root 279 Jun 8 19:10 tde-information.menu -rw-r--r-- 1 root root 288 Jun 8 19:10 tde-screensavers.menu -rw-r--r-- 1 root root 2304 Jun 8 19:10 tde-settings.menu
All menus on my box are in /etc/xdg.
With that all said, as you updated to R14 from 3.5.12 rather than from 3.5.13, quite possibly there are some remaining corner cases that the r14-xdg-update script does not cover in your profile that might cause this problem.
Darrell
I'm keeping track of them, but there are more than a few.
o kcontrol locks up after entering Security & Privacy -> Password & User Account info,
o kmix,
o taskbar -> Quicklaunch is now added to panel with 'Malformed URL' for 'Home' file manager,
etc.. I'll have a list later today or tomorrow.
So ensure the file date stamps of those files look
correct and that you are
not using an old menu. The applications.menu file
should be 25,875 bytes in
size and applications.menu-no-kde should be 16,182.
drwxr-xr-x 2 root root 4096 Jul 17 14:04 applications-merged -rw-r--r-- 1 root root 4124 May 15 05:40 applications.menu -rw-r--r-- 1 root root 11357 Jun 30 09:45 kde-applications.menu -rw-r--r-- 1 root root 279 Jun 8 19:10 tde-information.menu -rw-r--r-- 1 root root 288 Jun 8 19:10 tde-screensavers.menu -rw-r--r-- 1 root root 2304 Jun 8 19:10 tde-settings.menu
Those are not the latest menus from tdebase?
All menus on my box are in /etc/xdg.
I don't know that that location makes any difference. Is that where you always have installed the Trinity menus? Do you use /etc/trinity/xdg?
o taskbar -> Quicklaunch is now added to panel with 'Malformed URL' for 'Home' file manager,
The quicklaunch bug was fixed in commit c839bb9a, Thursday July 12. Make sure you are building with tdebase pulled to date.
Do you have a backup copy of your 3.5.12 profile before moving to R14? If you do then we can methodically troubleshoot our way through this. I just now found a corner case of some files that need to be updated related to Input Actions, although not related to the other bugs you report. Regardless, looks like we both stumbled across some corner cases that need to be addressed in the r14-xdg-update script.
In parallel hopefully you can figure out why you don't have the latest menus?
Darrell
On 07/17/2012 05:31 PM, Darrell Anderson wrote: <snip>
drwxr-xr-x 2 root root 4096 Jul 17 14:04 applications-merged -rw-r--r-- 1 root root 4124 May 15 05:40 applications.menu -rw-r--r-- 1 root root 11357 Jun 30 09:45 kde-applications.menu -rw-r--r-- 1 root root 279 Jun 8 19:10 tde-information.menu -rw-r--r-- 1 root root 288 Jun 8 19:10 tde-screensavers.menu -rw-r--r-- 1 root root 2304 Jun 8 19:10 tde-settings.menu
Those are not the latest menus from tdebase?
All menus on my box are in /etc/xdg.
I don't know that that location makes any difference. Is that where you always have installed the Trinity menus? Do you use /etc/trinity/xdg?
Yes, this is where the menus have always gone. They are totally FUBAR. All apps are dumped in 'Lost & Found'. There are menu folders that are moved around in the menu tree. 'Terminal Applications' is now under 'Internet'?? It used to be under System. Something must have 'blown up' regarding the menu. I've never seen such a mess. Now the questions becomes how do we figure out what happened?
Can I just delete all the menus and have them regenerated somehow?
o taskbar -> Quicklaunch is now added to panel with 'Malformed URL' for 'Home' file manager,
The quicklaunch bug was fixed in commit c839bb9a, Thursday July 12. Make sure you are building with tdebase pulled to date.
The GIT pull was from 7/15.
Do you have a backup copy of your 3.5.12 profile before moving to R14? If you do then we can methodically troubleshoot our way through this.
Yes. I have both
~/.kdemod3 (3.5.12) ~/.trinity (R14)
I just now
found a corner case of some files that need to be updated related to Input Actions, although not related to the other bugs you report. Regardless, looks like we both stumbled across some corner cases that need to be addressed in the r14-xdg-update script.
Yep,
This is exactly why we need a "Code Freeze" and 10 days to identify and fix.
In parallel hopefully you can figure out why you don't have the latest menus?
Darrell
I'm in. I have the install and several recent package sets we can work from. I'll have a list together soon and let's start putting our heads together.
Do you want to start a new etherpad?
Yes, this is where the menus have always gone. They are totally FUBAR. All apps are dumped in 'Lost & Found'. There are menu folders that are moved around in the menu tree. 'Terminal Applications' is now under 'Internet'?? It used to be under System. Something must have 'blown up' regarding the menu. I've never seen such a mess. Now the questions becomes how do we figure out what happened?
Can I just delete all the menus and have them regenerated somehow?
We need to figure out why your tdelibs package does not include the menus from the sources. Or why they did not install correctly. In GIT the menus are located in tdelibs/kded. There are only two menus there we are concerned about. In a pinch you can just copy those. You should not need to restart TDE, but you will need to use the menu once or twice to force TDE to update the menu on its own.
o taskbar -> Quicklaunch is now added to
panel with 'Malformed URL' for
'Home' file manager,
The quicklaunch bug was fixed in commit c839bb9a,
Thursday July 12. Make sure
you are building with tdebase pulled to date.
The GIT pull was from 7/15.
Okay. Open your quick launch config file with a text editor or viewer. The file name is goofy, like this:
$TDEHOME/share/config/launcher_panelapplet_dyrwtplrzeqcrk4kmi9m_rc
Look for any occurences of kde-.
If you see that, then exit TDE and run the r14-xdg-update script using the 'force' parameter.
By the way, have you ever run the r14-xdg-update script against your 3.5.12 profile? If you don't know or are uncertain, open $TDEHOME/share/config/kdeglobals and look for the following:
[R14 XDG Updates] Updated=true
If you find that in your 3.5.12 profile, then change the key value to anything other than true or exit Trinity and run the r14-xdg-update script with the 'force' parameter.
This is exactly why we need a "Code Freeze" and 10 days to identify and fix.
Until about a dozen usability bugs and numerous build issue bugs are resolved I think we are a ways off from a freeze. Just my opinion. The problems you are experiencing are growing pains of somebody moving from 3.5.12, which I don't think anybody has done yet. You're the guinea pig. :-)
I'm in. I have the install and several recent package sets we can work from. I'll have a list together soon and let's start putting our heads together.
Do you want to start a new etherpad?
Nah, we can keep things going here.
I have a feeling the problems you are seeing are 1) the menus and 2) corner cases with the r14-xdg-update or migratekde3 scripts. I don't have a 3.5.12 setup. I doubt I could create one that would replicate your setup. So we go one step at a time. The good news is I have been using R14 for several weeks. Everything works. We simply need to learn what breaks with a 3.5.12 migration and we'll be okay.
Darrell
Does this happen with a fresh $HOME/.trinity profile or
an existing profile?
Yes. Everything was ~/.kdemod with 3.5.12.
David,
I just pushed a patch to fix some text strings in KControl Input Actions and related changes to the r14-xdg-update script.
If you can, rebuild tdebase and then if you have a backup of your 3.5.12 profile, try again. I really hope you have a backup of your 3.5.12 profile because that will help us further debug remaining problems. The closest I can approach that is to use the migratekde3 script to convert a KDE3 profile. Regardless, the latest patch does fix a few things more, although they won't fix the menu or print screen problems.
Darrell
On 07/17/2012 06:22 PM, Darrell Anderson wrote:
David,
I just pushed a patch to fix some text strings in KControl Input Actions and related changes to the r14-xdg-update script.
If you can, rebuild tdebase and then if you have a backup of your 3.5.12 profile, try again. I really hope you have a backup of your 3.5.12 profile because that will help us further debug remaining problems. The closest I can approach that is to use the migratekde3 script to convert a KDE3 profile. Regardless, the latest patch does fix a few things more, although they won't fix the menu or print screen problems.
Darrell
OK, I'm on the rebuild and I do have the _complete_ 3.5.12 profile :)
OK, I'm on the rebuild and I do have the _complete_ 3.5.12 profile :)
Okay. I expect to be close to my computer this evening.
The basic test method we want to use each time we try anything:
* Ensure your original 3.5.12 profile is always safe or restorable from backups. :-) * Restore/copy the 3.5.12 profile as $HOME/.trinity. * Start Trinity. * See what breaks: one thing at a time.
I see a potential snag. Your 3.5.12 profile directory is named $HOME/.kdemod3. I believe Arch had started KDE3 mod before Trinity started. The migratekde3 script does not look for that specific name because I never knew about that name, but I'll update the script. I think a 3.5.12 profile is essentially a KDE3 profile. If true then I'll do some testing here copying a $HOME/.kde3 profile to $HOME/.trinity and see what breaks.
I always ran the migratekde3 script and you probably never have. I'm wondering what happens when you run the migratekde3 script against your 3.5.12 profile. Perhaps that fixes a lot, some of which the r14-xdg-update script does not touch. If you want to test the migratekde3 script you can temporarily edit the script to look for $HOME/.kdemod3 rather than $HOME/.kde3.
Darrell
I see a potential snag. Your 3.5.12 profile directory is named $HOME/.kdemod3. I believe Arch had started KDE3 mod before Trinity started. The migratekde3 script does not look for that specific name because I never knew about that name, but I'll update the script. I think a 3.5.12 profile is essentially a KDE3 profile. If true then I'll do some testing here copying a $HOME/.kde3 profile to $HOME/.trinity and see what breaks.
I always ran the migratekde3 script and you probably never have. I'm wondering what happens when you run the migratekde3 script against your 3.5.12 profile. Perhaps that fixes a lot, some of which the r14-xdg-update script does not touch. If you want to test the migratekde3 script you can temporarily edit the script to look for $HOME/.kdemod3 rather than $HOME/.kde3.
David,
I pushed a patch to update the migratekde3 script to include $HOME/.kdemod3 as a KDE3 profile directory. You don't need to rebuild tdebase. Just 'git pull' tdebase and then copy the file from the sources to $PREFIX/bin/.
Because no renaming changes occurred until 3.5.13 and thereafter, I am treating 3.5.12 profile directories as essentially KDE3 profiles. Therefore you might want to test the migratekde3 script against your $HOME/.kdemod3 profile. The script will create a $HOME/.trinity profile along with appropriate scrubbing. The r14-xdg-update script is run once from within starttde and performs a different set of scrubbing.
Make sure your kdeglobals does not contain an [R14 XDG Updates] key group or r14-xdg-update won't run when you start TDE.
If the migratekde3 script helps you, then we will need to figure out how to automate running migratekde3 against pre 3.5.13 profiles. The challenge is the script is not designed to run against an existing Trinity profile. I started to look into that and things got messy.
Darrell
On 07/17/2012 08:03 PM, Darrell Anderson wrote:
I see a potential snag. Your 3.5.12 profile directory is named $HOME/.kdemod3. I believe Arch had started KDE3 mod before Trinity started. The migratekde3 script does not look for that specific name because I never knew about that name, but I'll update the script. I think a 3.5.12 profile is essentially a KDE3 profile. If true then I'll do some testing here copying a $HOME/.kde3 profile to $HOME/.trinity and see what breaks.
I always ran the migratekde3 script and you probably never have. I'm wondering what happens when you run the migratekde3 script against your 3.5.12 profile. Perhaps that fixes a lot, some of which the r14-xdg-update script does not touch. If you want to test the migratekde3 script you can temporarily edit the script to look for $HOME/.kdemod3 rather than $HOME/.kde3.
David,
I pushed a patch to update the migratekde3 script to include $HOME/.kdemod3 as a KDE3 profile directory. You don't need to rebuild tdebase. Just 'git pull' tdebase and then copy the file from the sources to $PREFIX/bin/.
Because no renaming changes occurred until 3.5.13 and thereafter, I am treating 3.5.12 profile directories as essentially KDE3 profiles. Therefore you might want to test the migratekde3 script against your $HOME/.kdemod3 profile. The script will create a $HOME/.trinity profile along with appropriate scrubbing. The r14-xdg-update script is run once from within starttde and performs a different set of scrubbing.
Make sure your kdeglobals does not contain an [R14 XDG Updates] key group or r14-xdg-update won't run when you start TDE.
If the migratekde3 script helps you, then we will need to figure out how to automate running migratekde3 against pre 3.5.13 profiles. The challenge is the script is not designed to run against an existing Trinity profile. I started to look into that and things got messy.
Darrell
Ah, that explains a lot. I'll give it a try and report back. The migratekde3 script should be _optional_ for the user to run. Lots of times I DO NOT WANT the old .kde settings migrated and just want to start with a clean slate. This is one area where I don't want magic scripts outthinking the user. We should provide NOTICE of the migratekde3 script but let the user CHOOSE whether to run it :)
Ah, that explains a lot. I'll give it a try and report back. The migratekde3 script should be _optional_ for the user to run. Lots of times I DO NOT WANT the old .kde settings migrated and just want to start with a clean slate. This is one area where I don't want magic scripts outthinking the user. We should provide NOTICE of the migratekde3 script but let the user CHOOSE whether to run it :)
The updated FAQ in the help handbook index references the migratekde3 script (question 4.15).
Unlike the r14-xdg-update script, which is necessary, we don't want to automate using the migratekde3 script anywhere. There is no way to predict whether a person is migrating from an old KDE3 profile. I have tested the migratekde3 script fairly well, but like any software, only through my perspective. I don't use other distros and I don't know what quirks or corner cases might exist with other distros. The latest version now recognizes ~/.kdemod3 as a KDE3 profile, thanks to your help. As I mentioned, We should consider treating Trinity <= 3.5.12 as a KDE3 profile because we did not start serious or massive renaming until 3.5.13. But I don't have a 3.5.12 or 3.5.11 setup to test migratekde3. Thus far, you're the only person who can help with that. :)
Darrell
On 07/18/2012 03:52 PM, Darrell Anderson wrote:
Ah, that explains a lot. I'll give it a try and report back. The migratekde3 script should be _optional_ for the user to run. Lots of times I DO NOT WANT the old .kde settings migrated and just want to start with a clean slate. This is one area where I don't want magic scripts outthinking the user. We should provide NOTICE of the migratekde3 script but let the user CHOOSE whether to run it :)
The updated FAQ in the help handbook index references the migratekde3 script (question 4.15).
Unlike the r14-xdg-update script, which is necessary, we don't want to automate using the migratekde3 script anywhere. There is no way to predict whether a person is migrating from an old KDE3 profile. I have tested the migratekde3 script fairly well, but like any software, only through my perspective. I don't use other distros and I don't know what quirks or corner cases might exist with other distros. The latest version now recognizes ~/.kdemod3 as a KDE3 profile, thanks to your help. As I mentioned, We should consider treating Trinity <= 3.5.12 as a KDE3 profile because we did not start serious or massive renaming until 3.5.13. But I don't have a 3.5.12 or 3.5.11 setup to test migratekde3. Thus far, you're the only person who can help with that. :)
Darrell
Darrell,
Here is another data-point on the menu issue. On the test boxes in virtualbox that have only had R14 on them and have been updated since February with each build, the menus and quicklaunch URLs are OK. The only box that got terribly hosed was the actual non-virtual box that I removed my TDE 3.5.12 install and replaced it with R14. That is the box that had the menus scattered and the quicklaunch malformed URL problem.
Recall on the problem box, the 3.5.12 install was in /opt/kde3 and the profile was ~/.kdemod3. All 3.5.12 packages were removed before installing R14, and the ksyscoca in /var/tmp was removed. There was no migration script run, so the main culprit appears to be handling of the menu files in ~/.config/menus and /etc/xdg/menus. The new profile went in ~/.trinity, so the only issue I can see is the old menu files.
I have not wiped the problem box yet to do another fresh R14 install. So let me know if you want anything else off it. Also, let me know if you think the /etc/xdg/menus files will cause issues on reinstall. I have deleted the ~/.config/menus files. Thanks.
Here is another data-point on the menu issue. On the test boxes in virtualbox that have only had R14 on them and have been updated since February with each build, the menus and quicklaunch URLs are OK. The only box that got terribly hosed was the actual non-virtual box that I removed my TDE 3.5.12 install and replaced it with R14. That is the box that had the menus scattered and the quicklaunch malformed URL problem.
Recall on the problem box, the 3.5.12 install was in /opt/kde3 and the profile was ~/.kdemod3. All 3.5.12 packages were removed before installing R14, and the ksyscoca in /var/tmp was removed. There was no migration script run, so the main culprit appears to be handling of the menu files in ~/.config/menus and /etc/xdg/menus. The new profile went in ~/.trinity, so the only issue I can see is the old menu files.
I have not wiped the problem box yet to do another fresh R14 install. So let me know if you want anything else off it. Also, let me know if you think the /etc/xdg/menus files will cause issues on reinstall. I have deleted the ~/.config/menus files. Thanks.
Short answer, yes, I remain interested in case we are not covering some kind of corner case. Especially if there are many 3.5.12/3.5.11/3.5.10 users who will be updating to R14.
Long answer:
There are two scripts we use to massage an existing profile directory into compliance with R14. One script is called migratekde3, which is used to migrate an existing KDE3 profile to Trinity. The second script is r14-xdg-update, which is used to tweak an existing Trinity profile with various XDG changes we have made since 3.5.13. The two scripts do not address the same territory.
The migratekde3 script is optional and must be run intentionally. The migratekde3 script can run somewhat automated but only in the case when the r14-xdg-update script discovers that ~/.trinity is a sym link to ~/.kde3 (~/.kdemod3). In that case (not yet robustly tested) the script offers the user the option to break the sym link and migrate the KDE3 profile to Trinity. Otherwise the migratekde3 script has to be run directly by the user at the command line.
The r14-xdg-update script runs from within the starttde script, hopefully only once. Recently we added some dialogs and error messages should the script fail to run successfully the first time. We also have no mechanism in place to update profile files that are administratively locked or owned by root. At the moment we only offer a reminder message to check permissions.
The migratekde3 script knows the locations of ~/.kdemod3 and /opt/kde3. You did not run the script, however.
Users cannot use a previous KDE3 profile in Trinity without experiencing various problems. Based upon what I have seen of various 3.5.12 config files, a 3.5.12 profile is essentially a KDE3 profile. To continue using that profile means needing to use the migratekde3 script. Look at the migratekde3 script to see what kinds of changes are made to fix the profile.
The r14-xdg-update script attempts to scrub an existing $HOME/.config/menus/applications-kmenuedit.menu file. You wrote that you deleted that file and the system menu remained broken. Therefore we need to look at those system menu files.
The primary system menu file is named applications.menu.
Neither script attempts to fix existing system menus, nor should they. Check that your package management tools are removing the 3.5.12 system menus from /etc/xdg/menus. Then verify that your latest tdelibs package is installing applications.menu to your expected location of /etc/xdg/menus.
The latest applications.menu will contain references to TDE *.desktop file key names. If your 3.5.12 profile is not updated correctly, then your profile will be referencing KDE3 *.desktop key names and that would cause havoc in your menu.
To return to the original discussion, we have two areas in your case to understand. One, is your profile still essentially a KDE3 profile? When I looked at some of the files I concluded yes. Therefore you need to run the migratekde3 script.
The second area is whether your system is using the correct system menu. I don't know your build scripts or your system configuration. If you have more than one applications.menu on your system then that could cause havoc too.
We have no mechanism to validate how the system menu is created. The XDG_CONFIG_DIRS environment variable does get set in starttde and that variable controls where to look for menu files. Check that variable on your system and then check each of those paths for potentially conflicting menus.
At the moment we have no mechanism to warn users when they try to use an existing KDE3 profile in Trinity. We probably should. I haven't thought much about how we should do that. I could open a bug report, but preliminary discussion is welcomed.
I want to ensure we have 3.5.12/3.5.11/3.5.10 users covered. I have tested both scripts against a 3.5.10 profile and I am content the scripts wrok well. Yet I can't conceive of all corner cases. Thus far, you're the only additional test case where we can unravel any bugs unless some others volunteer too. If you can keep a copy of that 3.5.12 profile safely stored then we can keep testing. But we also need to determine whether the problem you describe is the profile or the system menus.
Darrell
On 07/27/2012 11:27 AM, Darrell Anderson wrote:
I want to ensure we have 3.5.12/3.5.11/3.5.10 users covered. I have tested both scripts against a 3.5.10 profile and I am content the scripts wrok well. Yet I can't conceive of all corner cases. Thus far, you're the only additional test case where we can unravel any bugs unless some others volunteer too. If you can keep a copy of that 3.5.12 profile safely stored then we can keep testing. But we also need to determine whether the problem you describe is the profile or the system menus.
I'll get a longer answer later. I'll work with the conversion script and see if we can tease out where the issue is. On Arch, you have XDG_CONFIG_DIRS=/etc/xdg:/opt/trinity/etc/xdg. It is set from:
/etc/profile.d/xorg.sh /etc/profile.d/trinity.sh
Hmm, I wonder how the interplay between these two scripts could impact the menu generation? e.g.:
~/bld/david/opt> cat /etc/profile.d/xorg.sh export XDG_DATA_HOME=$HOME/.local/share export XDG_CONFIG_HOME=$HOME/.config export XDG_CACHE_HOME=$HOME/.cache
if [ -z $XDG_DATA_DIRS ]; then export XDG_DATA_DIRS=/usr/local/share/:/usr/share/ else export XDG_DATA_DIRS=/usr/local/share/:/usr/share/:$XDG_DATA_DIRS fi
if [ -z $XDG_CONFIG_DIRS ]; then export XDG_CONFIG_DIRS=/etc/xdg else export XDG_CONFIG_DIRS=/etc/xdg:$XDG_CONFIG_DIRS fi
~/bld/david/opt> cat /etc/profile.d/trinity.sh export TDEDIR=/opt/trinity export TDEDIRS=$TDEDIR export PATH=$PATH:$TDEDIR/bin export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$TDEDIR/lib/pkgconfig if [ ! -z $XDG_DATA_DIRS ]; then export XDG_DATA_DIRS=$XDG_DATA_DIRS:$TDEDIR/share else export XDG_DATA_DIRS=$TDEDIR/share fi if [ ! -z $XDG_CONFIG_DIRS ]; then export XDG_CONFIG_DIRS=$XDG_CONFIG_DIRS:$TDEDIR/etc/xdg else export XDG_CONFIG_DIRS=$TDEDIR/etc/xdg
It looks like this shouldn't be an issue as long as the migration scripts are not called until after the /etc/profile.d/trinity.sh script is run (should be run on X start. However, when I install packages, I install from runlevel 3, so I'm not sure if the environment from either is set when the packages are installed/upgraded. I know this isn't an issue for R14->R14 updates, but the 3.5.12 -> R14 update done in runlevel 3 would not have XDG_CONFIG_DIRS set, but it would if run from runlevel 5.
Will have more time later. I'll also do a cheat sheet for the 3.5.13-sru build and pass that along.
I'll get a longer answer later. I'll work with the conversion script and see if we can tease out where the issue is. On Arch, you have XDG_CONFIG_DIRS=/etc/xdg:/opt/trinity/etc/xdg. It is set from:
/etc/profile.d/xorg.sh /etc/profile.d/trinity.sh
Please be sure to download the latest of both scripts. I pushed updates today.
Darrell
On 07/27/2012 05:44 PM, Darrell Anderson wrote:
Please be sure to download the latest of both scripts. I pushed updates today.
Darrell
Will do.
Also, if you do look at 3.5.13, the only change noted so far is the tdm/kdm config location. Just build with Qt3, and kick-off your normal build from there on. I'm happy to see that GIT provides a manageable way to preserve a Qt3 based build.
-
Darrell Anderson -
David C. Rankin