[SOLVED] Main menu submenu crashing issue

evnchn · 2021-01-02 02:01:18

To malm:

I'll do the testing and report to you. Afterwards, I'll reinstall BL after I check my USB stick for a correct hash to prevent corrupted installs and act as an end user to see whether the official updated version works. Also, I'm thinking about how to let the user know of the error more easily. Since as an end user you may not even know it is a segmentation error that causes this. Try and spell my name though, it is tricky for a reason I can't say

Test completed: No problems with original hover_delay. Please tell me if the official version is up, I'll install it

To rbh:

I was trying to change locale for testing only, so I didn't really look into the proper way of doing so. Thank you for reminding me though. The RAM really shows 1GB as max though, and I maybe know why since previously ASUS may have compiled a BIOS and used a Linux kernel in their Xandros OS that only reports 1GB as max (I heard that somewhere). I think it'll be no problem if I buy 2GB sticks. Yet, I can't buy from your website since I can really only access Taobao conveniently. Thank you for your suggestions though.

Note: current evidence points to 32-bit version is not good. Is it really that 64-bit version can install on my device given I'm running 32-bit? EDIT: nope, but I still wonder are there any other things missing for 32-bit installs

Last edited by evnchn (2021-01-02 02:39:11)

johnraff · 2021-01-02 06:25:27

ohnonot wrote:

...autostart (used to be in ~/.config/openbox, but I believe BL devs have found a "better" place for that)

BL's default autostart is ~/.config/bunsen/autostart (Menu: Preferences > BunsenLabs > Edit autostart )
Reasons for change:
1) Makes switch to other window manager much easier.
2) Allows vanilla OpenBox session to co-exist, continuing to use ~/.config/openbox/autostart.

( Each user is free to consider that "better" or otherwise. )

sleekmason · 2021-01-02 14:12:31

johnraff wrote:

ohnonot wrote:
...autostart (used to be in ~/.config/openbox, but I believe BL devs have found a "better" place for that)
BL's default autostart is ~/.config/bunsen/autostart (Menu: Preferences > BunsenLabs > Edit autostart )
Reasons for change:
1) Makes switch to other window manager much easier.
2) Allows vanilla OpenBox session to co-exist, continuing to use ~/.config/openbox/autostart.
( Each user is free to consider that "better" or otherwise. )

You have my interest up:)

You keep saying it is going to be easier, but I can't see how.

Menus come standard in any manager you would use, and changing over to jgmenu should be really simple at the build level.

Right now, it's kinda hard to find your way around in BL when used to standard paths for common items in Debian. (killall compton? vs. bl-compositor --stop) <-- Bad example but right idea.

Guess I don't get it, but that's okay too. No doubt Bunsenlabs is at the top of the list for outstanding distros. Really an incredible piece of work:)

damo · 2021-01-02 15:34:42

^ You can change WM at login and configure it to your liking. Or set the bunsenlabs-session to use a different WM, keeping your menu, keybinds and autostarted applications independent of it.

From ~/.config/bunsen/autostart

## WINDOW MANAGER
## Do not edit the next line unless you have also installed any
## necessary other programs for the different window manager,
## and edited the window-manager-dependent section later in this file.
## Use the window manager's actual command, not name:
window_manager=openbox

johnraff · 2021-01-03 05:04:11

^^ also have a look at

man bunsenlabs-session

evnchn · 2021-01-03 07:22:06

@malm

Sorry. I misunderstood. Apparently 4.3.0 jgmenu is up so we need to wait for all the repos to update. I'll report to you if BunsenLabs in particular is ready and the patch is working.

And to everyone else:

I am sorry for opening the can of worm of changing window manager or menus. Since jgmenu is the default I think it is better if we can can iron out the bugs here (it is the bug tracker after all) and make sure users can enjoy it or they may switch to other distros with an incomplete experience in BunsenLabs.

Please do open another topic regarding WM and menu comparisons since discussion and variety is always welcome. Personally I would like menus that use the least computational resources for my Eee PC. Give us the link to the topic you opened and we'll talk there. Thanks

Last edited by evnchn (2021-01-03 07:38:59)

evnchn · 2021-01-03 07:41:48

Props to everyone who helped. Thanks malm for his awesome work.

malm · 2021-01-03 08:55:48

^
Yep - should be in the repos shortly. Appreciate you helping us iron out this bug.
Just remember to uninstall what you installed in the $HOME directory.
Either just delete ~/bin/jgmenu and ~/bin/jgmenu_run manually; or run the following from the ~/jgmenu/ directory you created a couple of days ago:

make uninstall

evnchn · 2021-01-03 10:09:24

malm wrote:

Just remember to uninstall what you installed in the $HOME directory.

Reinstalled BL and ran bl-welcome to simulate a user who is going to update jgmenu via apt. Used another tool to make the USB bootable stick to make sure my installation is not corrupted. Thanks for your guidance anyways.

rbh · 2021-01-03 16:35:34

evnchn wrote:

Reinstalled BL

So now, if jgmenu works for you, we do not know if malm's patch, fixed so jgmenu would work in spite of your rare misconfigured locales, jgmenu should have managed...

and ran bl-welcome to simulate a user who is going to update jgmenu via apt.

??? apt update/upgrade, is to upgrade all available packages, including jgmenu. Updating config settings (not upgrading), is done with script "bl-user-setup", which runs whenever new version of bl-configs is installed.

Used another tool to make the USB bootable stick to make sure my installation is not corrupted.

I don't unserstand that.

evnchn · 2021-01-03 18:10:15

Firstly, I reinstalled BL to roll back all changes to jgmenu and act as an end user to install the patch of jgmenu as soon as it comes out and report to malm asap. As a result, my jgmenu is currently left in a broken state. I do not believe my locales are misconfigured. I configured it according to the text-based setup like any other Hongkonger would. I didn't do anything special or strange. I ran bl-welcome just because it is said to be recommended, although it is not made clear in the script that running it is what you should do, given the massive DontBreakDebian warning. Updating all packages is something a normal user should do, and I just follow the steps. Thank you for mentioning the usages of other bl- scripts. It sure is welcome. For the USB though, I just use some other tools to make the USB for this fresh install to make sure the USB imaging tool isn't causing trouble, since people have once reported that some USB imaging tools especially on windows are troublesome and that they cause loads of undocumented issues. I am sorry if my messages are unclear. Feel free to clarify.

malm · 2021-01-03 19:24:36

rbh wrote:

evnchn wrote:
Reinstalled BL
So now, if jgmenu works for you, we do not know if malm's patch, fixed so jgmenu would work in spite of your rare misconfigured locales, jgmenu should have managed...

@rbh - @evnchn confirmed it worked before re-installing BL. Besides, I was able to reproduce both issues, so am confident they're fixed.
Also, @evnchn's locale is quite legit - no need to pick on it.

rbh · 2021-01-03 19:56:01

evnchn wrote:

Firstly, I reinstalled BL to roll back all changes to jgmenu

To roll back changes in your jgmenu user configs, you just rename ~/.config/jgmenu and run script "bl-user-setup". Defult settings from /usr/share/bunsen/skel/*, will be copied to ~/ if you allow them to.
Have you done systemwide changes, you just reinstall package.

and act as an end user to install the patch of jgmenu as soon as it comes out and report to malm asap.

Malm asked you to aply fix before he roll out the fix to the repository!

As a result, my jgmenu is currently left in a broken state.

you have made a new fresh installation and jgmenu is still broken? Can you apply malms fix from post https://forums.bunsenlabs.org/viewtopic … 87#p109687:

I do not believe my locales are misconfigured. I configured it according to the text-based setup like any other Hongkonger would.

After a standard installation, you should not need to install locales, the should be in place!

I didn't do anything special or strange.

If you after debian-installer done its jobb, you do not have correct locales, you have done something strange. If you have done a cli-installation or by accident broken your locales, then the information on https://wiki.debian.org/Locale, is applicable.

I ran bl-welcome just because it is said to be recommended, although it is not made clear in the script that running it is what you should do,

It is auto-started and gives you:
"This is an optional post-installation script, designed to help you configure your new Linux installation [...]" It is for me quite clear the script should be run after installation.
You do not need to run the skript, but then you should manualley do what the script does, or run it on a later time.

For the USB though, I just use some other tools to make the USB for this fresh install to make sure the USB imaging tool isn't causing trouble, since people have once reported that some USB imaging tools especially on windows are troublesome and that they cause loads of undocumented issues.

Ok, so it was about the install media. You have read the installation instructions? why not use recomended method?

I am sorry if my messages are unclear.

I think you need to glance through the Debian Handbook and Debian Refrence on the Help menu.

Last edited by rbh (2021-01-03 19:57:44)

johnraff · 2021-01-04 02:46:19

Hi @evnchn thanks for trying BunsenLabs, and also for your user feedback, which is always helpful regardless of whether there is a bug in our setup or a deficiency in our documentation!

evnchn wrote:

I ran bl-welcome just because it is said to be recommended, although it is not made clear in the script that running it is what you should do, given the massive DontBreakDebian warning.

That warning is not intended to mean "don't upgrade packages" and certainly not "don't run this script" but "don't add third-party repositories, or upgrade packages from a different repo than your own". Maybe we need to think about rewriting the message to make that clearer?

@all Please don't forget that the 32-bit CD iso is missing some packages that usually come with BL by default. This causes some inconvenience, but was necessary to squeeze the iso file down to 700MB to fit on a CD. (Every other trick we could find was also applied. )
Here's the current 32-bit package list - note compton (but not locales) is missing:

alsa-utils
anacron
apt-transport-https
arandr
at
at-spi2-core
bash-completion
btrfs-progs
chntpw
clipit
conky-all
cpufrequtils
cryptsetup
curl
crda
dbus-x11
dillo
dmz-cursor-theme
dosfstools
efibootmgr
eject
evince
f2fs-tools
fbxkb
file-roller
firmware-b43-installer
firmware-b43legacy-installer
firmware-linux
firmware-realtek
firmware-iwlwifi
fonts-inconsolata
fonts-liberation
fuse
galculator
galternatives
gddrescue
gdebi
gigolo
gmrun
gnome-keyring
gparted
gsimplecal
gtk2-engines-pixbuf
gvfs
gvfs-backends
gvfs-fuse
hardinfo
haveged
hdparm
hddtemp
hfsprogs
htop
hwdata
i965-va-driver
intel-microcode
inxi
jgmenu
less
libexo-1-0
libinput-tools
libpam-gnome-keyring
libnotify-bin
libqt5svg5
lightdm
lightdm-gtk-greeter
lightdm-gtk-greeter-settings
light-locker
locales
lsb-release
lshw
lvm2
lxappearance
mlocate
modemmanager
mousepad
mpv
network-manager
network-manager-gnome
nitrogen
ntfs-3g
ntp
obconf
openbox
p7zip-full
pavucontrol
pciutils
pcmciautils
pnmixer
policykit-1
policykit-1-gnome
pulseaudio
python
python-keybinder
python-notify
python-xdg
qt5-style-plugins
rfkill
ristretto
rsync
rxvt-unicode
scrot
smartmontools
suckless-tools
sudo
synaptic
thunar
thunar-archive-plugin
thunar-gtkhash
thunar-volman
tint2
unar
unrar
unzip
update-inetd
usb-modeswitch
usbutils
user-setup
uuid-runtime
va-driver-all
vdpau-va-driver
wireless-tools
xbindkeys
xcape
xdg-user-dirs
xdg-utils
xfce4-notifyd
xfce4-power-manager
xfsprogs
xinput
xorg
xserver-xorg-input-all
xserver-xorg-input-synaptics
xserver-xorg-input-evdev
xserver-xorg-input-wacom
xserver-xorg-video-all
xserver-xorg-video-intel
xserver-xorg-video-qxl
xsel
xz-utils
yad
zip

evnchn · 2021-01-04 03:58:24

@johnraff: A proposed new version of bl-welcome warning

NOTEWORTHY WARNING
----------

Although this script does not harm your system, it is worth mentioning that, although FOSS is primarily about freedom and choice, certain choices are known to carry an increased risk of breaking things.

...

To reduce the chance of bricked installs, please type "I understand" to continue with this script and finish your BunsenLabs install.

I think that is nicer

Also, maybe add a page {

SCRIPT PROCEDURE

The script will
1. update packages
2. ...
3. ...

} and show this script to the user before asking their password? Because if you ask something like a password from the user before telling them what to do, probably they won't give the password and leave the bl-welcome prematurely. Also, to me, "optional" means "opt-in and choose to install it" to me. Perhaps remove the "optional" keyword and just leave "You can skip this script and run it later by 'bl-welcome'" as an opt-out mode to bias more users to run it.

@rbh Thanks for telling me how to rollback changes without reinstall. Malm and I have tested out a fix for jgmenu on the latest version on github already and it works (the post #20 you linked to is exactly what I have done (@malm have already released 4.3.0 in fact)), and I am just waiting for the patch to come to the repo for a final double-check just to be safe. I made a fresh install and of course, jgmenu is broken. I am leaving it in a broken state intentionally now, to test the official release. I did not do anything special with the locales, no install anything. I just selected the languages as a Hongkonger would. Btw, is the text-based debian-installer leaving people with broken locales? That is a serious bug and I'll get to investigating asap. But I don't think so as my locales aren't broken but somehow the XSetLocaleModifiers() and XSupportsLocale() functions related to locales (and that jgmenu use) are broken.

Last edited by evnchn (2021-01-04 04:01:49)

johnraff · 2021-01-04 04:09:50

@evnchn thanks for the suggestions!

rbh · 2021-01-04 11:30:08

evnchn wrote:

I have tested out a fix for jgmenu on the latest version on github already and it works (the post #20 you linked to is exactly what I have done (@malm have already released 4.3.0 in fact)),

"Released", for me, is when a package is pushed to the repository. Still in repo is version 4.2.1+bl10-1 (5/22/2020) https://www.bunsenlabs.org/repoidx.html … ium-jgmenu

I made a fresh install and of course, jgmenu is broken. I am leaving it in a broken state intentionally now, to test the official release.

I'm very confused. Jgmenu was broken, was patched with malms fix and leaved broken awating final release...
Most often there is no problem with jgemnu, so it is not expeted that jgmenu will breake after installation... You are the first one here to report that problem and malm had heard about three more cases. Compared with al thousands of 32 bits install of Lithium, that problem is rare.

I did not do anything special with the locales, no install anything. I just selected the languages as a Hongkonger would.

You wrote, that you after installation had followed instructions on https://wiki.debian.org/Locale...

But, nevermind, I can live with not understanding.

I have done 4 32 bit installations with Lithium iso, without noticing any problems regarding jgmenu or locales.
But, John informed that the 32 bit iso does not contain the locales packages. That is why some installations get the problem below:

my locales aren't broken but somehow the XSetLocaleModifiers() and XSupportsLocale() functions related to locales (and that jgmenu use) are broken.

And a new jgmenu package will soon be released.

damo · 2021-01-04 13:08:10

rbh wrote:

...
But, John informed that the 32 bit iso does not contain the locales packages. ....

Not quite He said compton is not included, but locales is (and it appears on the package list)

evnchn · 2021-01-04 13:29:45

rbh wrote:

"Released", for me, is when a package is pushed to the repository. Still in repo is version 4.2.1+bl10-1 (5/22/2020) https://www.bunsenlabs.org/repoidx.html … ium-jgmenu

There is a release (noun) on GitHub but it isn't released (verb) on BunsenLabs repo. Do tell me how I can phrase it better. Technical terms can be inconsistent between us, and it is always good to clear things up.

Yes. I am awaiting final release, so as to safeguard the final release with one more precautionary step. I have NOT followed the Debian guide for locales as it is NOT a typical end-user would do. I repeat that I act as an end user for this patching process as best as I can. For whether this problem is rare, perhaps install your own BunsenLabs with Hong Kong locales. Interesting to see if this problem occurs.

rbh · 2021-01-04 15:10:09

damo wrote:

rbh wrote:
...
But, John informed that the 32 bit iso does not contain the locales packages. ....
Not quite He said compton is not included, but locales is (and it appears on the package list)

Sorry, sloppy reading.

#21 2021-01-02 02:01:18

Re: [SOLVED] Main menu submenu crashing issue

#22 2021-01-02 06:25:27

Re: [SOLVED] Main menu submenu crashing issue

#23 2021-01-02 14:12:31

Re: [SOLVED] Main menu submenu crashing issue

#24 2021-01-02 15:34:42

Re: [SOLVED] Main menu submenu crashing issue

#25 2021-01-03 05:04:11

Re: [SOLVED] Main menu submenu crashing issue

#26 2021-01-03 07:22:06

Re: [SOLVED] Main menu submenu crashing issue

#27 2021-01-03 07:41:48

Re: [SOLVED] Main menu submenu crashing issue

#28 2021-01-03 08:55:48

Re: [SOLVED] Main menu submenu crashing issue

#29 2021-01-03 10:09:24

Re: [SOLVED] Main menu submenu crashing issue

#30 2021-01-03 16:35:34

Re: [SOLVED] Main menu submenu crashing issue

#31 2021-01-03 18:10:15

Re: [SOLVED] Main menu submenu crashing issue

#32 2021-01-03 19:24:36

Re: [SOLVED] Main menu submenu crashing issue

#33 2021-01-03 19:56:01

Re: [SOLVED] Main menu submenu crashing issue

#34 2021-01-04 02:46:19

Re: [SOLVED] Main menu submenu crashing issue

#35 2021-01-04 03:58:24

Re: [SOLVED] Main menu submenu crashing issue

#36 2021-01-04 04:09:50

Re: [SOLVED] Main menu submenu crashing issue

#37 2021-01-04 11:30:08

Re: [SOLVED] Main menu submenu crashing issue

#38 2021-01-04 13:08:10

Re: [SOLVED] Main menu submenu crashing issue

#39 2021-01-04 13:29:45

Re: [SOLVED] Main menu submenu crashing issue

#40 2021-01-04 15:10:09

Re: [SOLVED] Main menu submenu crashing issue

Board footer