Page 16 of 22
Porteus 5.0 RC2 bug reports
Posted: 10 Dec 2020, 06:22
by donald
@Rava
regarding plugin-registry
What happens because of the plugin-registry file supplied if you boot porteus
on this or that PC?
Nobody had known beforehand with which hardware porteus will be used.
So which settings were selected in this file doesn't really matter, does it?
If you just want to have the GTK-Gui as default, delete the plugin-registry file,
open/close audacious and you get a new "default" plugin-registry file.
IMO it doesn't matter if you change the settings afterwards and boot a different PC.
Porteus 5.0 RC2 bug reports
Posted: 10 Dec 2020, 08:10
by fulalas
@Rava, I tried here and I could replicate your issue. Running this fixed the problem:
You probably should save the cache module and get it from /tmp then put it in your module or base folder
Since this is a nice finding, I'll add this package to Xfce and LXDE so it'll work out of the box.
Thanks!
Porteus 5.0 RC2 bug reports
Posted: 10 Dec 2020, 12:14
by Rava
donald wrote: ↑10 Dec 2020, 06:22
If you just want to have the GTK-Gui as default, delete the plugin-registry file,
open/close audacious and you get a new "default" plugin-registry file.
I just want audacious using the GTK interface from the start.
I look into what kind of generic setup audacious comes with, maybe it ships with a minimal plugin-registry file where I can set the GUI to GTK…
It must have the GUI interface preference stored somehow.
______________________________________
fulalas wrote: ↑10 Dec 2020, 08:10
You probably should save the cache module and get it from /tmp then put it in your module or base folder
Never manually used cache-module. Got me intrigued… nice what
tells me.
Porteus 5.0 RC2 bug reports
Posted: 10 Dec 2020, 21:25
by fulalas
Porteus 5.0 RC2 bug reports
Posted: 10 Dec 2020, 22:58
by donald
Rava, unpack the module containing the plugin-registry file -- should be 003-xfce i think,
adjust the values - I told you which - and repack the module...done.
Porteus 5.0 RC2 bug reports
Posted: 11 Dec 2020, 05:46
by Rava
^ will do.
Once again my lsxzmgrep comes in handy:
Code: Select all
root@porteus:/mnt/sdb/Porteus_5.0rc2/porteus/base# lsxzmgrep . plugin-registry
./003-xfce-4.12-20201108.xzm
/home/guest/.config/audacious/plugin-registry
./003-xfce-4.12-20201108.xzm
/root/.config/audacious/plugin-registry
_________________________________________
What's the difference? Is
Xfce 4.12 for RC2 (for performance maniacs like you and me 
) just coloured Ferrari yellow?
_________________________________________
besides
XFCE's standard editor mousepad I also have geany and leafpad activated, and good so:
Code: Select all
root@porteus:~# touch dummy.txt
root@porteus:~# l dummy.txt
-rw-r--r-- 1 root 0 2020-12-11 06:18 dummy.txt
root@porteus:~# leafpad dummy.txt
root@porteus:~# cat dummy.txt
leafpad was here!
root@porteus:~# mousepad dummy.txt
Failed to initialize xfconfroot@porteus:~# cat dummy.txt
leafpad was here!
root@porteus:~# geany dummy.txt
root@porteus:~# cat dummy.txt
leafpad was here!
geany was here!
My versions of geany and leafpad are the unaltered ones in use for ages since some years old 5.0-pre-rc1 version:
Code: Select all
root 3227648 2015-01-05 09:29 021-geany-1.23.1-x86_64-1gv.xzm
root 94208 2019-05-22 07:19 030-leafpad-0.8.18.1-x86_64-2ponce.xzm
Is there a quick fix to get mousepad running as root?
This time cache-module is no help.
Porteus 5.0 RC2 bug reports
Posted: 11 Dec 2020, 07:24
by fulalas
Rava wrote: ↑11 Dec 2020, 05:46
Is there a quick fix to get mousepad running as root?
Yes. Always Fresh mode
Porteus 5.0 RC2 bug reports
Posted: 11 Dec 2020, 10:30
by Rava
fulalas wrote: ↑11 Dec 2020, 07:24
Rava wrote: ↑11 Dec 2020, 05:46
Is there a quick fix to get mousepad running as root?
Yes. Always Fresh mode
Umm I always run my Porteus in Always Fresh Mode - no changes saved , only manual selected few settings saved via rootcopy/ or rootcopy.xzm.
So, mousepad should be running as root okay, then why is it not?
Porteus 5.0 RC2 bug reports
Posted: 11 Dec 2020, 18:13
by roadie
fulalas wrote: ↑11 Dec 2020, 07:24
Rava wrote: ↑11 Dec 2020, 05:46
Is there a quick fix to get mousepad running as root?
Yes. Always Fresh mode
I was getting the error in Always Fresh mode.....base_only, norootcopy, as well as Standard mode. I fixed it by adding /etc/machine-id, or /var/lib/dbus/machine-id.
It now works fine with rootcopy and modules enabled. Thunar will give the same error if that file is not in place.
EDIT:
Running the following generates the file.
Code: Select all
dbus-uuidgen --ensure=/etc/machine-id
Porteus 5.0 RC2 bug reports
Posted: 11 Dec 2020, 20:39
by Rava
roadie wrote: ↑11 Dec 2020, 18:13
Running the following generates the file.
Code: Select all
dbus-uuidgen --ensure=/etc/machine-id
Did create it:
Code: Select all
root@porteus:/mnt/live/memory/images# dbus-uuidgen --ensure=/etc/machine-id
root@porteus:/mnt/live/memory/images# cd
root@porteus:~# mousepad dummy.txt
Failed to initialize xfconfroot@porteus:~# l /etc/machine-id
-rw-r--r-- 1 root 33 2020-12-11 21:29 /etc/machine-id
root@porteus:~# file /etc/machine-id
/etc/machine-id: ASCII text
root@porteus:~# thunar
Thunar: Failed to initialize Xfconf: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
(thunar:31834): GLib-GObject-WARNING **: 21:31:14.008: invalid (NULL) pointer instance
(thunar:31834): GLib-GObject-CRITICAL **: 21:31:14.009: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
thunar works, mousepad not.
I copy my 5.0rc2 files with old kernel for my Nvidia driver to a 2nd USB stick and check out 5.0rc2 on a different machine, either tomorrow or Sunday.
And report if there is also the mousepad as root issue.
Porteus 5.0 RC2 bug reports
Posted: 11 Dec 2020, 21:11
by roadie
Rava,
I don't now think the issue is the lack of that file as /etc/rc.messagebus runs that command when starting dbus. It places the file in /var/lib/dbus and applications look there or /etc......it should already be in place.
Porteus 5.0 RC2 bug reports
Posted: 11 Dec 2020, 21:58
by ncmprhnsbl
in order to launch a mousepad instance from a root terminal in a guest x session you need to:
Code: Select all
# dbus-launch --exit-with-session mousepad dummy.txt
--
with a root thunar instance( in a guest x session), mousepad just works..
Porteus 5.0 RC2 bug reports
Posted: 12 Dec 2020, 00:17
by Rava
roadie wrote: ↑11 Dec 2020, 21:11
I don't now think the issue is the lack of that file as /etc/rc.messagebus runs that command when starting dbus. It places the file in /var/lib/dbus and applications look there or /etc......it should already be in place.
Thanks, I was unaware of these details.
ncmprhnsbl wrote: ↑11 Dec 2020, 21:58
in order to launch a mousepad instance from a root terminal in a guest x session you need to:
Code: Select all
# dbus-launch --exit-with-session mousepad dummy.txt
--
with a root thunar instance( in a guest x session), mousepad just works..
Code: Select all
root@porteus:~# dbus-launch --exit-with-session mousepad dummy.txt
dbus[17508]: Unable to set up transient service directory: XDG_RUNTIME_DIR "/var/run/user/1000" is owned by uid 1000, not our uid 0
root@porteus:~# cat dummy.txt
leafpad was here!
geany was here!
mousepad was here!
Thanks ncmprhnsbl, that does the trick.
I am wondering… one could replace mousepad binary with a script also called mousepad? While leaving the original /usr/bin/mousepad as it is.
Code: Select all
root@porteus:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin
root@porteus:~# fw mousepad
/usr/bin/mousepad: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, stripped
root@porteus:~# fw fw
/usr/local/bin/fw: Bourne-Again shell script, ASCII text executable
root@porteus:~# cat /usr/local/bin/fw
#!/bin/bash
VERSION="0.3"
MYNAME="fw (file-which)"
test ! "$ECHO_COLORS"x = "x" && test -f $ECHO_COLORS && . $ECHO_COLORS
if [ $# -ne 1 ]; then
echo -e $yel$bld$MYNAME$off$yel V$VERSION$off
echo -e $bld${red}"You must specify *one* filename for which!"$off
exit 1
else
file `which "$1"` 2>/dev/null
errorcode=$?
if [ $errorcode -ne 0 ]; then
echo -e $yel$bld$MYNAME$off$yel V$VERSION$off
echo -e $bld$red"Errorcode $errorcode returned!
(Errormessage of \`file\` is suppressed)"$off
exit 2
fi
fi
exit 0
Since roots $PATH starts with /usr/local/sbin - wouldn't a script called /usr/local/sbin/mousepad not be the one being executed when a user just tries executing "mousepad" in a root xterminal?
Code: Select all
root@porteus:~# touch /usr/local/sbin/mousepad
root@porteus:~# chmod u+x /usr/local/sbin/mousepad
root@porteus:~# l /usr/local/sbin/mousepad
-rwxr--r-- 1 root 0 2020-12-12 00:53 /usr/local/sbin/mousepad
root@porteus:~# leafpad /usr/local/sbin/mousepad
root@porteus:~# cat /usr/local/sbin/mousepad
#!/bin/sh
echo I am $0
As you can see, I created /usr/local/sbin/mousepad as dummy script with a debug output.
should be replaced with
Code: Select all
dbus-launch --exit-with-session /usr/bin/mousepad $*
but…
Code: Select all
root@porteus:~# mousepad
Failed to initialize xfconfroot@porteus:~#
my system still tries executing /usr/bin/mousepad and not /usr/local/sbin/mousepad .
I presume some kind of caching of already known locations of programs are to be blamed for that.
I do not recall how to reset such info, so when root xterm tries to execute a mere "mousepad" /usr/local/sbin/mousepad gets executed and not /usr/bin/mousepad .
Any ideas how to get bash into doing so?
Porteus 5.0 RC2 bug reports
Posted: 12 Dec 2020, 00:30
by ncmprhnsbl
Rava wrote: ↑12 Dec 2020, 00:17
Any ideas how to get bash into doing so?
why not just use an alias in roots .bashrc ?
alias mpad=dbus-launch --exit-with-session /usr/bin/mousepad
EDIT
and looking into this a bit further has revealed that this happens only with su, but not with sudo (or sudo su)
eg.
Code: Select all
guest@porteus:~$ su
Password:
root@porteus:/home/guest# mousepad test.txt
Failed to initialize xfconf
or even
Code: Select all
guest@porteus:~$ su -c mousepad test.txt
Password:
Failed to initialize xfconf
but
Code: Select all
guest@porteus:~$ sudo su
Password:
root@porteus:/home/guest# mousepad test.txt
works without issue
also
Code: Select all
guest@porteus:~$ sudo su -c "mousepad test.txt"
works too..
Porteus 5.0 RC2 bug reports
Posted: 12 Dec 2020, 04:04
by Rava
ncmprhnsbl wrote: ↑12 Dec 2020, 00:30
why not just use an alias in roots .bashrc ?
alias mpad=dbus-launch --exit-with-session /usr/bin/mousepad
I use both users (root + guest) .bashrc to load my extensive alias and function file… so I will not put the mousepad alias in my file but like you suggest: an extra line only in /root/.bashrc