Page 4 of 8

Porteus-v4.0rc4 bug reports

Posted: 02 Mar 2018, 19:37
by M. Eerie
Sorry being late...

In MATE DE the locale modules generated via Porteus Centre seems to be mixed/uncomplete. I.E. Brisk Menu shows locale strings correctly, but desktop menu (RightMouseButton) is showing in english.

Also, some settings (power-management sleep display, fonts settings, etc.), remain unchanged despite saving changes while some others are kept.

The keyboard behaviour operates as in version 3.2.2: Whenever the desktop is alive, the us layout is back into bussiness no matter what cheatcode was chosen at startup (cheatcode keyb=es in my case). Clicking on the country tray icon switches to the desired one, althought it changes from time to time, and depending on which tasks are executed. The only valid solution I've found is to click in the systray and set it manually _just after_ login in.

Thanks.

Porteus-v4.0rc4 bug reports

Posted: 02 Mar 2018, 20:12
by jssouza
M. Eerie, thanks for your feedback, currently the locales are not fully implemented, and would be handled properly once we reach Porteus v4.0 final.
M. Eerie wrote:
02 Mar 2018, 19:37
cheatcode keyb=es in my case
I think the cheatcode would be kmap=es. Could you verify please? Thanks.

Porteus-v4.0rc4 bug reports

Posted: 02 Mar 2018, 22:23
by M. Eerie
jssouza wrote:
02 Mar 2018, 20:12
the cheatcode would be kmap=es.
Yes you're right. The cheatcode I'm using is kmap=es

:)

Porteus-v4.0rc4 bug reports

Posted: 03 Mar 2018, 13:09
by Philip
fulalas

LXDE 32-bit
I can now confirm that the Porteus settings centre does start from the menu. But for some unknown reason it didn't work at the time of the test.

Porteus-v4.0rc4 bug reports

Posted: 04 Mar 2018, 12:26
by Philip
Openbox 32-bit

epdf viewer: If a pdf document contains .jpg images, they are not shown in the viewer.

Cannot get kmap=gb to work. Even setting the keymap in porteus-settings-centre does not retain the setting between boots.

Porteus-v4.0rc4 bug reports

Posted: 04 Mar 2018, 20:30
by fulalas
@Philip, this was already fixed. It's going public on the next release :)

Porteus-v4.0rc4 bug reports

Posted: 05 Mar 2018, 15:13
by Jack
Philip wrote:
04 Mar 2018, 12:26
Openbox 32-bit

epdf viewer: If a pdf document contains .jpg images, they are not shown in the viewer.

Cannot get kmap=gb to work. Even setting the keymap in porteus-settings-centre does not retain the setting between boots.
Thanks for the test file with the 4 images and with my builds I can see all 4 images when I open your pdf file. Thanks for your test pdf file.

Porteus-v4.0rc4 bug reports

Posted: 08 Mar 2018, 12:26
by jssouza
If cheatcodes like changes=, volume=, kmap= etc. are added in the new porteus-v4.0-x86_64.cfg instead of passing through the bootloader, then these cheatcodes will not be present in /proc/cmdline. Hence porteus scripts that check only /proc/cmdline for cheatcodes would fail to implement the cheatcodes.

Code: Select all

[root:/opt/porteus-scripts]# grep -R cmdline
xorg/gui-autostart:VOLUME=`egrep -o " volume=[^ ]+" /proc/cmdline | cut -d= -f2`
xorg/gui-autostart:KMAP=`egrep -o " kmap=[^ ]+" /proc/cmdline | cut -d= -f2`
xorg/gui-autostart:for cmd in `egrep -o " guiexec=[^ ]+" /proc/cmdline | cut -d= -f2- | tr ";" " "`; do
gtk-porteus-timeconfig:grep "changes=" /proc/cmdline && export using_changes=1 || unset using_changes
make-changes:## Check if changes file was used in cmdline
make-changes:changeline=`grep -o -P 'changes=/.*.dat' /proc/cmdline`
pinstaller:             export cmdline=`</proc/cmdline`
pinstaller:#export cchanges=`cat /proc/cmdline|grep -o "[^ ]*changes[^ ]*"`
pinstaller:if [ `grep -o copy2ram /proc/cmdline` ]; then
porteus-settings-centre:[[ `grep -o "changes=" /proc/cmdline` ]] && using_changes=1
xpsinfo:cat /proc/cmdline >> $info
psinfo:cat /proc/cmdline >> $info
pxe-server:storage=`egrep -o " storage=[^ ]+" /proc/cmdline | cut -d= -f2 | sed s@^/dev/@/mnt/@`
update-porteus:if [ `egrep -o " from=[^ ]+" /proc/cmdline | cut -d= -f2 | grep "\.iso"` ]; then
Also looks like some cheatcodes (noeject, changes-ro etc.) are only checked in /proc/cmdline by linuxrc.

Porteus-v4.0rc4 bug reports

Posted: 08 Mar 2018, 14:47
by jssouza
M. Eerie wrote:
02 Mar 2018, 19:37
The keyboard behaviour operates as in version 3.2.2: Whenever the desktop is alive, the us layout is back into bussiness no matter what cheatcode was chosen at startup
M. Eerie, can you execute the following command and then check if keyboard layout stays in es layout and does not jump to us layout after that from time to time?

Code: Select all

guest@porteus:~$ gsettings set org.mate.peripherals-keyboard-xkb.kbd layouts "['es', 'us']"
Thanks

Porteus-v4.0rc4 bug reports

Posted: 08 Mar 2018, 14:56
by Ed_P
:shock: Nice catch jssouza.

Porteus-v4.0rc4 bug reports

Posted: 09 Mar 2018, 00:02
by brokenman
Thanks jssouza,

I know there are many cheatcodes that won`t work. It`s a matter of me tracking them all down and adding the extra check. Thanks for the list.

Porteus-v4.0rc4 bug reports

Posted: 09 Mar 2018, 00:19
by M. Eerie
jssouza wrote:
08 Mar 2018, 14:47
M. Eerie, can you execute the following command...
Done. And yes, the layout seems to be fixed now. ;)

However, in dconf-editor, the real path seems to be: /org/mate/desktop/peripherals/keyboard/kbd/layouts

Perhaps this schema was missing. I'll check it out booting again, prior to save my ~/.config/dconf/user file.

Thanks!

Edit: This was my previous setup. Not sure this makes a big change.

Image

Edit2: Sorry... :pulpfiction: :Oops:

Porteus-v4.0rc4 bug reports

Posted: 09 Mar 2018, 05:20
by Ed_P
brokenman wrote:
09 Mar 2018, 00:02
I know there are many cheatcodes that won`t work. It`s a matter of me tracking them all down and adding the extra check.
Maybe an early run routine that merges the .cfg file cheatcodes into the cmdline ones would be an easier approach. :happy62:
M. Eerie wrote:
09 Mar 2018, 00:19
Edit: This was my previous setup. Not sure this makes a big change.

Image
:%) Anyone able to read this image?

Porteus-v4.0rc4 bug reports

Posted: 09 Mar 2018, 12:27
by Rava
Ed_P wrote:
09 Mar 2018, 05:20
:%) Anyone able to read this image?
Nope, seems the image is just a preview? M. Eerie, you need to upload a higher quality image...

Porteus-v4.0rc4 bug reports

Posted: 09 Mar 2018, 16:58
by M. Eerie
Fixed image above.

Digging up a bit more, I've found that keyboard reverts back to 'us' as before.

I'd swear this is happening whenever a system updating script fires up (i.e. a module gets activated, etc.). Then the layout can't get swapped by simply clicking system tray icon. You have to right-click on it, then select Layouts --> English (US), and only then, you are able to select another layout. :%)

Cheers!