antiX-23-beta1-runit-full (64bit) for testing

[Moderator Brian Masinick]

Helpful

Up

0

::

Robin wrote:

anticapitalista wrote:

This bug is a mystery.

No not a mystery. I’s because of desktop-menu is run by root, and hence it changes the permissions when rewriting the files so default user can’t access them anymore. The fix was simply to add a line to the script, making sure to restore the proper permissions always to the files when writing them. I’d suggest to backport the respective lines from the latest version @Dave is working on to a hot fix version for the older antiX versions, until the new version is ready for being used in antiX, this would fix this common issue many people have encountered.

Whoever is working on this matter should carefully examine what is happening. Though I’m not looking at the code, I can tell you that anything that is changing file permissions is also, in one way or another, manipulating either the file or the directory structure containing the file if the permission mask is being altered. I recommend not giving up on this until the root cause of the matter is determined, modified, tested, and verified. Hopefully this is not caused by a hack to our code and instead it’s just a simple, overlooked error; in any case, even if it’s an easy fix, it sounds potentially serious, so I’m hoping that a skilled engineer is investigating it.

I’m NOT a great coder but I do consider myself pretty competent when it comes to diagnosing odd behavior; this is definitely not normal behavior to have file and/or directory permissions altered by a seemingly innocent utility.

--
Brian Masinick

[Member Robin]

Helpful

Up

0

::

anticapitalista wrote:

I have installed apps via apt (xfe), package installer (filezilla) and synaptic (frozen-bubble)

Maybe this is the key to understanding the origin of this. Please try to install something with
sudo apt-get install ...
from within a rox terminal window.
I’m pretty sure this causes the issue to be triggered next time you try to use desktop-menu without sudo.

——————
Update:
No, have just tested this. The sudoed apt-get doesn’t trigger it. There must be some other reason for the miraculous change of file permission I don’t know, but desktop-menu should simply restore the expected and needed values anyway.

Windows is like a submarine. Open a window and serious problems will start.

[Member calciumsodium]

Helpful

Up

0

::

I wonder if this a related issue. When I make an isosnapshot of my individualized antiX23 beta1, and install from the snapshot, the applications menu of the newly installed system is gone.

I found that the file /usr/share/desktop-menu/.icewm/menu-applications file is not present in the freshly installed system.

To get around this, I had use to the command in terminal:

sudo desktop-menu –write-out-global

[Member marcelocripe]

Helpful

Up

0

::

Mostly @marcelocripe but I have just been playing with antiX-23 in Virtualbox (live) in pt_BR.
I have installed apps via apt (xfe), package installer (filezilla) and synaptic (frozen-bubble) and all automatically showed up in the menu without having to click on Refresh.

The problem occurs when the new menu is not displayed, when you have to click on the “Refresh” menu and even then the new menu is not displayed.
When we install a new application and it is displayed, there is no reason to click on the “Refresh” menu, because the command $ sudo desktop-menu –write-out-global has already been executed in end of the installation process and that’s why the new menus have been added successfully.

– – – – –

Mostly @marcelocripe but I have just been playing with antiX-23 in Virtualbox (live) in pt_BR.
I have installed apps via apt (xfe), package installer (filezilla) and synaptic (frozen-bubble) and all automatically showed up in the menu without having to click on Refresh.

O problema ocorre quando o novo menu não é exibido, quando é preciso clicar no menu “Refresh” e mesmo assim o novo menu não é exibido.
Quando fazemos a instalação de um novo aplicativo e ele é exibido, não tem motivo algum de clicar no menu “Refresh”, porque o comando $ sudo desktop-menu –write-out-global já foi executado no final do processo de instalação e é por isso que os novos menus foram adicionados com sucesso.

[Member PPC]

Helpful

Up

0

::

On the “refresh menu” menu entry – I’ve been reporting here, for a very long time that it never worked for me (probably because I manually install some .deb files right afetr any antiX install I do). I’m glad it seems that the reason for this bug was discovered and it’s being addressed.
It’s not a “critical” bug, far from it, and I’ve helped many people here in the forum, by advising to manually run the command with sudo.

I haven’t ran the beta in a long time, I’ll try to do it this afternoon and check out the changes…

P.

[Forum Admin anticapitalista]

Helpful

Up

0

::

The question is why wouldn’t installing an app not automatically trigger the update-menu.
There should be no need to use Refresh menu manually.
In what situations do users have to refresh manually and why?
Thanks

Added: I’m asking so that I can try to reproduce the issue that others clearly have and I don’t have.

• This reply was modified 2 weeks, 4 days ago by anticapitalista.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Member PPC]

Helpful

Up

0

::

anticapitalista wrote:

In what situations do users have to refresh manually and why?

Most times, here in the forum? Some users complain the “Applications menu” is empty, and has to be regenerated (I’m not sure what causes that, but I seem to recall some cases when, at first boot, that menu is empty).
For me, personally, it’s when I manually create .desktop files, to appimages, or uncompressed binaries, and I want them on the menu…

P.

• This reply was modified 2 weeks, 4 days ago by PPC.

[Forum Admin anticapitalista]

Helpful

Up

0

::

So we need to find out what causes the Applications menu not to appear or appear empty.
I have seen this happen when I opened the menu immediately the desktop appeared.
There were no apps listed under Applications.
A couple of seconds later they appeared without me having to click Refresh.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Member Xunzi_23]

Helpful

Up

0

::

In my case I installed on an EEPC from a USB Stick, the one I am using now.
It was not freshly remastered, I use no persistence and remaster after updates
then immediately reboot and use for a while before a second stick can be
mirror imaged.

After install no errors.

First boot I waited a while as the desktop might not have fully loaded.
No Menu,
Logged out and back in again, no menu,
after a reboot and wait a moment, no menu.

Since write out global menu is ready once ICEWM is fully up.

I often have wondered why the refresh button is present.
When adding starters I always use the controll center add to personal menu
tool, guessing. as I have not looked at the script, that does a global write
out.

[Moderator Brian Masinick]

Helpful

Up

0

::

Prior to running an update, my current setup on antiX 23 Beta 1 has the following:

ls -l /usr/share/desktop-menu/.*/menu-applications
-rw-r--r-- 1 root root 16558 Apr 20 12:36 /usr/share/desktop-menu/.fluxbox/menu-applications
-rw-r--r-- 1 root root 15924 Apr 20 12:36 /usr/share/desktop-menu/.icewm/menu-applications
-rw-r--r-- 1 root root 19525 Apr 20 12:36 /usr/share/desktop-menu/.jwm/menu-applications

If I run –
desktop-menu –write-out-global
it results in –
(desktop-menu:13228): dbind-WARNING **: 12:44:22.570: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
Writing Menu: jwm
Traceback (most recent call last):
File “/usr/local/bin/desktop-menu”, line 457, in
build_menu()
File “/usr/local/bin/desktop-menu”, line 287, in build_menu
text = open((USER_HOME+”/”+Var.Conf_Dir+”/”+Var.App_File), “w”)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PermissionError: [Errno 13] Permission denied: ‘/usr/share/desktop-menu//.jwm/menu-applications’

and the permissions remain the same.

If I run –
sudo desktop-menu –write-out-global
it results in –

sudo desktop-menu –write-out-global

(desktop-menu:13965): dbind-WARNING **: 12:48:38.077: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
Writing Menu: jwm
Writing Menu: icewm
Writing Menu: fluxbox
[antixBeta-hp-14-fq-1025]/home/masinick/bin: > ls -l /usr/share/desktop-menu/.*/menu-applications
-rw-r–r– 1 root root 16558 Apr 20 12:48 /usr/share/desktop-menu/.fluxbox/menu-applications
-rw-r–r– 1 root root 15924 Apr 20 12:48 /usr/share/desktop-menu/.icewm/menu-applications
-rw-r–r– 1 root root 19525 Apr 20 12:48 /usr/share/desktop-menu/.jwm/menu-applications

So there are no changes in permissions with either of these commands.

That definitely suggests that something else happened. Have there been any new discoveries?

--
Brian Masinick

[Moderator Brian Masinick]

Helpful

Up

0

::

OK, NOW I see what everyone is talking about:

I DO see all of the various menus that are typically organized underneath Applications.
Now I do not see Applications listed at all in my antiX 23 Beta 1 instance;
instead I see Accessories, Games, Graphics, Internet, etc. listed directly when
I view the Menu.

The functionality works fine, but if we do want all of these categories
as subcategories under the Applications menu, that’s not happening with antiX 23

I’ll check antiX 22 next and see if it’s the same or different.

I didn’t realize this distinction until just now because the overall approach
is clean and works fine.

--
Brian Masinick

[Moderator Brian Masinick]

Helpful

Up

0

::

antiX 22 and antiX 23 have the same behavior so it’s consistent.

I do have some old menu files from the past and their organization and content is different than the current menu-applications file in
/usr/share/desktop-menu/.*/menu-applications

--
Brian Masinick

[Forum Admin anticapitalista]

Helpful

Up

0

::

I found a way to reproduce this bug by reinstalling desktop-menu-antix.
This changed all /usr/share/desktop-menu/.*/menu-applications to root;root ownership.
Menu still showed Applications and clicking on Refresh caused a ‘spike’ in conky to show it had been run (I assumed incorrectly that it had run successfully).
I then ran desktop-menu –write-out-global in a terminal and now see all the errors as regards permissions and menu.
I applied the fix that @Robin linked to and now everything is back to normal.

So we’ll apply a fix to desktop-menu-antix and whatever is used on antiX-19.

However, we still need to find out why the Applications sub-menu fails to show sometimes.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Member marcelocripe]

Helpful

Up

0

::

There should be no need to use Refresh menu manually.
In what situations do users have to refresh manually and why?

I can cite some examples that I saw happening:

antiX 19, 21 or 22 (in the official ISOs) was started on an old video card (Via, SIS, Intel, NVidia, etc) and for some reason the submenus of the Applications menu are all misaligned or out of their correct position. Clicking on the “Refresh” menu should fix them, but it doesn’t fix the submenus. When I apply the command $ sudo desktop-menu –write-out-global the submenus are adjusted and return to their correct position (I don’t know how to explain the reason).

At topic of the unofficial ISO that Xecure kindly built, it was mentioned some examples of the submenus of the Applications menu that were all misaligned or out of their correct position, but were not corrected by clicking on the “Refresh” menu. After those tests, or during those tests (I don’t remember exactly), Xecure instructed me to apply the command $ sudo desktop-menu –write-out-global so that the submenus were adjusted and returned to their correct position. (I hope I’m not confusing the moments of events, as they were situations that occurred in the year 2020)

Besides, PPC has been reporting this problem for a long time.

– – – – –

There should be no need to use Refresh menu manually.
In what situations do users have to refresh manually and why?

Eu posso citar alguns exemplos que eu vi acontecendo:

O antiX 19, 21 ou 22 (nas ISOs oficiais) foi iniciado em uma placa de vídeo antiga (Via, SIS, Intel, NVidia, etc) e por algum motivo os submenus do menu Aplicativos estão todos desajustados ou fora da sua posição correta. Com o clique no menu “Refresh” deveria corrigi-los, mas não corrige os submenus. Quando eu aplico o comando $ sudo desktop-menu –write-out-global os submenus são ajustados e voltam para a sua posição correta (eu não sei explicar o motivo).

No tópico da ISO não oficial que o Xecure gentilmente construiu, foi citado alguns exemplos dos submenus do menu Aplicativos que ficavam todos desajustados ou fora da sua posição correta, mas não eram corrigidos com o clique no menu “Refresh”. Posteriormente aqueles testes, ou durante aqueles testes (eu não me lembro bem), o Xecure me instruiu a aplicar o comando $ sudo desktop-menu –write-out-global para os submenus serem ajustados e voltarem para a sua posição correta. (Eu espero não estar confundindo os momentos dos acontecimentos, pois foram situações que ocorreram no ano de 2020)

Além de que, o PPC vem relatando este problema há muito tempo.

[Moderator Brian Masinick]

Helpful

Up

0

::

I’ve tried every suggestion so far and none of them make any difference.

I did force a failure by manually changing the menu-applications file, then I changed it back to get it functioning and the same behavior returned.

I might be able to create different menus by putting in my own file but at best, that will help diagnosis; at worst it won’t accomplish anything.

--
Brian Masinick

[Author]

Posts