persistence bug (aufs .. plnk)
The bug I reported against the"antix 14 alpha" build is still present.
As a reminder:
aufs author stated, in mailing list, that files should NOT accumulate in the plnk directory... and any accumulated files there may be safely deleted.
After an apt dist-upgrade operation yesterday (40 packages) I checked
/live/aufs-ram/.wh..wh.plnk
and found 2,864 files, totalling 181.4Mb
Following shutdown (persist-save) + reboot, those files are still present.
Persist-save is obviously not excluding (would be my preference) or deleting contents of the"plnk" directory.
(To be clear,"as shipped" it isn't dealing with plnk dir. Simple fix may be to manually add an exclude file entry, but I haven't done so.)
-
skidooPosts: 1,444
- Joined: 09 Feb 2012
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#107
It will be beneficial to simplify the matter by dealing separately with each of the menu handlers.
Try the following which uses only Menu Manager to create an example item in the Personal menu section. The intention of testing in this way is to create a known state that can be reproduced by other people. It also restricts the number of variable elements to just a single app and thereby is a way of eliminating, or confirming, the app as contributing to the matters you have reported.
TEST 1
Step 1
Boot the shipped 15-b3 ISO using live without any form of persistence. This will provide a clean testing environment.
Step 2
Control Center-->Edit Menus
Select Personal when asked which menu to change
Select Add when asked whether to add or remove an item
Select Gcolor2 when asked to select an item to add
Change the name to Colour Picker when asked for the name to display in the menu
Leave all other items in the Optional cutomisation window at their default setting
Select Refresh when asked whether to refresh the menu or make another change
A window reports the update has been done.
Step 3
antiX Main Menu-->Personal
The section now contains an item named Colour Picker
Click on it and the Gcolor2 app opens as expected
Once this position is established go on to the next test
TEST 2
Step 1
Boot your usual 15-b3 working environment i.e. the one you have been posting about previously
Step 2
Delete all files in the directory ~/.local/share/applications/TCM/
This will give an unpolluted area and avoid confusion from previous creation attempts.
Step 3
Repeat steps 2 and 3 from test 1
OUTCOME
Post the results of both the above tests.
skidoo wrote:The {MenuManager} program does not do a menu refresh at the moment so that will need to be manually done.
If it is not showing up after a menu update then try looking at ~/.local/share/applications to see if the files you tried to make are there.
dolphin_oracle wrote:The Add Menu Item (not the same app as MenuManager) app that you are describing does not and the update must be done manually. Unfortunatnly the Update Menus app in the top level of the menu does not update the personal menu
Your posts on this matter are very difficult to understand and follow. As mentioned by dolphin_oracle there are 2 new independent apps that you might be including, Add Menu Item, and Menu Manager, plus a 3rd, the long standing Update Menu that has been a part of previous antiX releases. Your reports seem to be a mix of these under the umbrella of Menu Manager. Additional confusion is created as the items you are trying to add to the Personal section of the antiX main menu are evidently not the product of Menu Manager .skidoo wrote:At this point, I have the following"custom" .desktops files present
and zero custom entries displayed to Personal, zero custom entries displayed to the Applications submenus.
[...]
/home/demo/.local/share/applications/TCM/my-app.desktop
(not displayed to menus, AFAICT)Code: Select all
[Desktop Entry] Encoding=UTF-8 Type=Application Name=test6 nixme Icon=/usr/share/pixmaps Categories=X-Personal; Exec=geany Terminal=false
It will be beneficial to simplify the matter by dealing separately with each of the menu handlers.
Try the following which uses only Menu Manager to create an example item in the Personal menu section. The intention of testing in this way is to create a known state that can be reproduced by other people. It also restricts the number of variable elements to just a single app and thereby is a way of eliminating, or confirming, the app as contributing to the matters you have reported.
TEST 1
Step 1
Boot the shipped 15-b3 ISO using live without any form of persistence. This will provide a clean testing environment.
Step 2
Control Center-->Edit Menus
Select Personal when asked which menu to change
Select Add when asked whether to add or remove an item
Select Gcolor2 when asked to select an item to add
Change the name to Colour Picker when asked for the name to display in the menu
Leave all other items in the Optional cutomisation window at their default setting
Select Refresh when asked whether to refresh the menu or make another change
A window reports the update has been done.
Step 3
antiX Main Menu-->Personal
The section now contains an item named Colour Picker
Click on it and the Gcolor2 app opens as expected
Once this position is established go on to the next test
TEST 2
Step 1
Boot your usual 15-b3 working environment i.e. the one you have been posting about previously
Step 2
Delete all files in the directory ~/.local/share/applications/TCM/
This will give an unpolluted area and avoid confusion from previous creation attempts.
Step 3
Repeat steps 2 and 3 from test 1
OUTCOME
Post the results of both the above tests.
-
BitJamPosts: 1,308
- Joined: 31 Aug 2009
#108
Thanks! This should be fixed in the next update to the persist-scripts. It should already be fixed when static root persistence is enabled.skidoo wrote:persistence bug (aufs .. plnk)
The bug I reported against the"antix 14 alpha" build is still present.
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#109
Yes, some scripts and configuration files were inadvertantly left out. Should be OK in the next round.dolphin_oracle wrote:antix 15 beta 3"bugs"
[...]
10. wingrid keys defined in the window manager key files, but wingrid itself is not installed.
11. there is an equalizer in the control center, but it doesn't seem to actually modify the sound output. there is likely a asound.conf file missing from /etc to link the equalizer to hardware.
-
skidooPosts: 1,444
- Joined: 09 Feb 2012
#110
Testing in a non-persistent live session. This portion of my earlier feedback stands unchanged (blue edits added for clarity)
After dozens more failed attempts to create"items" using this tool:
-- it seems to me it's silently failing any time user selects a"by name, not already in use" Applications submenu.
(choosing Item Category="Application" or"Utility", neither of which already display in the desktop menu... always results in failure)
-- related to the above, some of the menu (sub)categories which currently ARE displayed... are absent from the selectable targets
(earlier I stated"some"; during _nonpersistent-session_ only"Accessories" is missing, vs subcats currently displayed in desktop menu)
-- it allows creation of an entry (silent fail, no error prompt. SHOULD it fail, or apply a default/fallback iconfile target) having unchosen icon
-- it doesn't notice/alert in the case where user's item submission will overwrite an existing same-named file
-- Although it's Item Location: offers a Personal target,"Menu Manager" seems to be blind to .desktop
files residing in the custom paths populated by the"add-desktop" script ( Menu --} Applications --} Preferences --} Add Menu Item )
? By design, is"MenuManager" blind to .desktop files residing in the custom paths populated by the"add-desktop" script ( Menu --} Applications --} Preferences --} Add Menu Item )
and
? Is"Update Menus" also blind to .desktop files residing in the custom paths populated by
the"add-desktop" script ( Menu --} Applications --} Preferences --} Add Menu Item )
Polluted?
Each time an add-desktop attempt chokes/fails, forevermore-ignored .desktop files accumulate in the local/share..TCM path?
The"add-desktop" script ( Menu --} Applications --} Preferences --} Add Menu Item ) is still problematic in non-persistent session.As is, the"Menu Manager" launcher is initially displayed under"Personal" submenu (first-run, and until an item is added to"Personal").
problem: it's counter-intuitive to click a launcher labeled MenuManager pathed under"personal" when user really wishes to amend"applications" submenu
problem (bug): after adding an item (ANY item) to personal, then deciding to remove it, user is presented with a do-nothing item under"personal", labeled"retry".
item labeled MenuManager pathed under"personal" is not restored if/when Personal submenu becomes empty
edit: onHover.... fluxbox menu displays"retry"; JWM menu displays nothing (no flyout for empty submenu); IceWM shows a thin glitchy rectangle
. . .
wishlist feature: dialogbox displaying static text"just a moment, searching available items..." during the awkward startup delay
wishlist feature: On the"ADD to Applications menu" screen (MenuManager fullscreen dialogbox), I would appreciate seeing in advance which category(ies) an item will be added into
After dozens more failed attempts to create"items" using this tool:
-- it seems to me it's silently failing any time user selects a"by name, not already in use" Applications submenu.
(choosing Item Category="Application" or"Utility", neither of which already display in the desktop menu... always results in failure)
-- related to the above, some of the menu (sub)categories which currently ARE displayed... are absent from the selectable targets
(earlier I stated"some"; during _nonpersistent-session_ only"Accessories" is missing, vs subcats currently displayed in desktop menu)
-- it allows creation of an entry (silent fail, no error prompt. SHOULD it fail, or apply a default/fallback iconfile target) having unchosen icon
-- it doesn't notice/alert in the case where user's item submission will overwrite an existing same-named file
-- Although it's Item Location: offers a Personal target,"Menu Manager" seems to be blind to .desktop
files residing in the custom paths populated by the"add-desktop" script ( Menu --} Applications --} Preferences --} Add Menu Item )
Yes, confused. Confused by reading"is a product of". I had not considered:Additional confusion is created as the items you are trying to add to the Personal section of the antiX main menu are evidently not the product of Menu Manager.
? By design, is"MenuManager" blind to .desktop files residing in the custom paths populated by the"add-desktop" script ( Menu --} Applications --} Preferences --} Add Menu Item )
and
? Is"Update Menus" also blind to .desktop files residing in the custom paths populated by
the"add-desktop" script ( Menu --} Applications --} Preferences --} Add Menu Item )
Polluted?
Each time an add-desktop attempt chokes/fails, forevermore-ignored .desktop files accumulate in the local/share..TCM path?
-
dolphin_oraclePosts: 2,238
- Joined: 16 Dec 2007
#111
I think the refresh functions in MenuManager are looking everywhere. I just made a few custom entries with"Add Menu Item" that didn't show up anywhere. Then I used MenuManager to"hide" claws-mail. at the end of the routine it asks to refresh the menu, which I did. all the custom entries I had made with"Add Menu Item", as long as they had a valid category (and I don't thing"Applications" is one) show up in the regular menu.
this is the command that runs with Update Menus:
And this is the terminal output I get. Looks like some kind of permissions problem.
at least on my system, and probably skidoo's as well, the Update Menus function is apparently nerfed somehow.
***Ok, so this is weird, I cannot reproduce this on my virtualbox machine at work. Update Menus is working fine for the application menu (doesn't do anything for the personal).
this is the command that runs with Update Menus:
Code: Select all
$ desktop-menu --write-out-global
Code: Select all
Traceback (most recent call last):
File"/usr/local/bin/desktop-menu", line 285, in <module>
open((USER_HOME+"/"+Var.Conf_Dir+"/"+Var.App_File), 'w').close()
IOError: [Errno 13] Permission denied: '/home/dolphin/.icewm/menu-applications'
***Ok, so this is weird, I cannot reproduce this on my virtualbox machine at work. Update Menus is working fine for the application menu (doesn't do anything for the personal).
Last edited by dolphin_oracle on 09 Jun 2015, 12:50, edited 1 time in total.
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#112
From post41013.html?#p41013
Your desire to provide information to help address the matters you report is entirely understandable. When that information omits requested feedback, it does not optimise attempts to assist you.skidoo wrote:Testing in a non-persistent live session. This portion of my earlier feedback stands unchanged...
From post41013.html?#p41013
If you are unsure what is wanted, the following will be helpful, particularly when booted live with no persistence.SamK wrote:OUTCOME
Post the results of both the above tests.
- Did the test procedure produce the outcome described in the list of steps?
- If the the test procedure failed to produce the outcome, describe which step or step-part fails and what occurs
- Optional but useful
ls -1 ~/.local/share/applications/TCM/
cat ~/.local/share/applications/TCM/file_created_by_Menu_Manager
-
dolphin_oraclePosts: 2,238
- Joined: 16 Dec 2007
#113
metapackage-installer:
the network>samba line does not actually install samba. the bm file needs modified to include samba (and depends if necessary).
the network>samba line does not actually install samba. the bm file needs modified to include samba (and depends if necessary).
-
anticapitalista
Posts: 5,955
- Site Admin
- Joined: 11 Sep 2007
#114
d_o presently it has this:
FLL_PACKAGES=(
pyneighborhood
smbclient
#smbfs
cifs-utils
)
What else needs installing?
FLL_PACKAGES=(
pyneighborhood
smbclient
#smbfs
cifs-utils
)
What else needs installing?
-
dolphin_oraclePosts: 2,238
- Joined: 16 Dec 2007
#115
the samba package itself is required for hosting a share. cifs-utils (which is installed by default already I think) is for accessing shares hosted on other machines.
-
skidooPosts: 1,444
- Joined: 09 Feb 2012
#116
(create ColourPicker entry under Personal, via MenuManager)
Sam, both the"Test 1" (no persistence) and"Test 2" (persistence, empty TCM directory) produce the correct/expected result.
============
followup regarding add-desktop aka Preferences -- } Add Menu Item
(re)tested in non-persistent live session
When adding an item and"Item Location = 1) Application Menu", failure only when Category is set to"Application".
Any other Category selection succeeds ~~ after"Update Menu", items are correctly displayed to corresponding menu subcategories.
When attempting to add an item and"Item Location = 2) Desktop", every attempt (dozens of variations tried) fails.
When attempting to add an item and"Item Location = 3) Personal",
.desktop files are generated, but menu entries for them remain NOT displayed after"Update Menu" is run (and run a second time, for good measure. and logout/login. and change desktop)
The following is a new discovery from retesting:
The undisplayed"Personal" entries later showed up (they displayed in the Personal submenu)
after I used MenuManager"ControlCentre--}EditMenus--}Personal--}Add--}Refresh"
to add an unrelated item.
Tonight I also discovered the importance of MenuManager"countdown to finished progressbar dialogbox".
Following several of my"Edit menus" attempts, (add-desktop aka"Edit menus" lacks a similar delay timer)
I"clicked too quickly" and wound up opening the partially-populated desktop menu before the refresh/update had fully run.
Sam, both the"Test 1" (no persistence) and"Test 2" (persistence, empty TCM directory) produce the correct/expected result.
============
followup regarding add-desktop aka Preferences -- } Add Menu Item
(re)tested in non-persistent live session
When adding an item and"Item Location = 1) Application Menu", failure only when Category is set to"Application".
Any other Category selection succeeds ~~ after"Update Menu", items are correctly displayed to corresponding menu subcategories.
When attempting to add an item and"Item Location = 2) Desktop", every attempt (dozens of variations tried) fails.
When attempting to add an item and"Item Location = 3) Personal",
.desktop files are generated, but menu entries for them remain NOT displayed after"Update Menu" is run (and run a second time, for good measure. and logout/login. and change desktop)
The following is a new discovery from retesting:
The undisplayed"Personal" entries later showed up (they displayed in the Personal submenu)
after I used MenuManager"ControlCentre--}EditMenus--}Personal--}Add--}Refresh"
to add an unrelated item.
Tonight I also discovered the importance of MenuManager"countdown to finished progressbar dialogbox".
Following several of my"Edit menus" attempts, (add-desktop aka"Edit menus" lacks a similar delay timer)
I"clicked too quickly" and wound up opening the partially-populated desktop menu before the refresh/update had fully run.
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#117
You have previously indicated problems removing created menu items
TEST 3
Step 1
Repeat steps 1, 2 and 3 of test 1 (live no persistence)
Step 2
Control Center-->Edit Menus
Select Personal when asked which menu to change
Select Remove when asked whether to add or remove an item
Select Colour Picker item created in step 1
Select Refresh when asked whether to refresh the menu or make another change
A window reports the update has been done.
Step 3
antiX Main Menu-->Personal
The section no longer contains an item named Colour Picker
Verify the corresponding .desktop file is deleted ls -1 ~/.local/share/applications/TCM/
OUTCOME
Post the results of test 3.
OK you have confirmed Menu Manager has been eliminated as a potential source of problems of creating menu items in your earlier reports.skidoo wrote:"Test 1" (no persistence) and"Test 2" (persistence, empty TCM directory) produce the correct/expected result.
You have previously indicated problems removing created menu items
So same process again to confirm or eliminate Menu Manager in this respect.skidoo wrote:...forevermore-ignored .desktop files accumulate in the local/share..TCM path?
TEST 3
Step 1
Repeat steps 1, 2 and 3 of test 1 (live no persistence)
Step 2
Control Center-->Edit Menus
Select Personal when asked which menu to change
Select Remove when asked whether to add or remove an item
Select Colour Picker item created in step 1
Select Refresh when asked whether to refresh the menu or make another change
A window reports the update has been done.
Step 3
antiX Main Menu-->Personal
The section no longer contains an item named Colour Picker
Verify the corresponding .desktop file is deleted ls -1 ~/.local/share/applications/TCM/
OUTCOME
Post the results of test 3.
-
Posts: 1,028
SamK - Joined: 21 Aug 2011
#118
Re: fbxkb
Previously reported and remains unaddressed
Boot Live with root persistence
After boot up the system always shows an incorrect national flag icon.
When the UK has been selected in the boot screen, the GUI (X) consistently starts with the flag of the USA an remains in this state.
Seems to requires escalation of privileges in GUI i.e. entering root password before automatically changing to correct flag.
Previously reported and remains unaddressed
Boot Live with root persistence
After boot up the system always shows an incorrect national flag icon.
When the UK has been selected in the boot screen, the GUI (X) consistently starts with the flag of the USA an remains in this state.
Seems to requires escalation of privileges in GUI i.e. entering root password before automatically changing to correct flag.
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#119
Default Theme and Icon Set
Big thumbs up for the new look. I realise this is sometimes seen purely as a subject of personal taste, however it is much more practical and usable straight-from-the-box than the previous implementations in the development cycle.
Big thumbs up for the new look. I realise this is sometimes seen purely as a subject of personal taste, however it is much more practical and usable straight-from-the-box than the previous implementations in the development cycle.
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#120
Re: Diasappearing Window Buttons
post39391.html#p39391
post40365.html#p40365
Ref note 2.
Happy to confirm other reports this is fixed.
post39391.html#p39391
post40365.html#p40365
Ref note 2.
Happy to confirm other reports this is fixed.