Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy

[sunburnt]

Fred; That`s basically how AppDir & RoxApp works, both types have all files in a dir.
The main run file or link is AppRun and the dir`s icon is .DirIcon ( hidden ).
Other than these 2 items, AppDir can be setup by any method.
amigo made some AppDir that compile the app in the AppDir dir. and set it up to run.
# Rox-Filer supports AppDir, clicking on the AppDir runs it, and Rox-Filer shows the dir`s icon.
I can not figure out how to get Xfe to do these 2 things. Anyone know how.?

William; As Toni said, you have to pick a wallpaper, set the display mode type and then Apply.
If you want just one wallpaper for all desktops, just select one and it should show for all.
NOTE: Having multiple wallpapers should not take more memory, only one is in ram at a time.


### I just realized I made a mistake in desktop.ctrl, I don`t think it will switch desktops if run=off.
# Try the first one I posted, but I think this one is needed for it to work. ( Sorry about that... )
.

[mcewanw]

William; As Toni said, you have to pick a wallpaper, set the display mode type and then Apply.
If you want just one wallpaper for all desktops, just select one and it should show for all.
NOTE: Having multiple wallpapers should not take more memory, only one is in ram at a time.

Okay Terry, I understand it now. Thanks.

[mcewanw]

Guys, could you test epdfview is working properly for you. I find that out of the box I'm having to press Zoom to Fit to make it display first time. If I put it to zoom 100% value the output is blank again. I don't have that issue in Puppy Precise. Not sure if it depends on the size (LxB) of the original pdf. The one that gives problem is displayed landscape (has longside horizontal by default).

EDIT: actually any zoom factor other than 100% makes it display okay with the pdf I've tried.

EDIT2: Just tried a different pdf file and it displayed fine at any zoom setting. Weird... Don't know why first one displays okay other than 100% (and also for any setting using epdfview in Puppy precise). No big deal though.

[fredx181]

Hi Toni

/opt/bin/refresh-menus content:
Code:
#!/bin/sh

if [ -n $SUDO_USER ]; then
su - $SUDO_USER -c '/opt/bin/mk-jwm.menu && jwm -reload'
else
user=`echo $XAUTHORITY | sed -e 's,.*/home/,,' -e 's,/.Xauthority.*,,'`� �
su - $user -c '/opt/bin/mk-jwm.menu && jwm -reload'
fi

This will not depend on if the user's $HOME is in /home:

Code: Select all

#!/bin/sh

if [ -n $SUDO_USER ]; then
su - $SUDO_USER -c '/opt/bin/mk-jwm.menu && jwm -reload'
else
user=`echo $XAUTHORITY | sed -e 's,/[^/]*$,,' -e 's,.*/,,'`
su - $user -c '/opt/bin/mk-jwm.menu && jwm -reload'
fi

Changed the "user=.." line to extract the username in any case of where $HOME is.
Also when logged in as root the $user variable will be root.

Fred

[saintless]

This will not depend on if the user's $HOME is in /home:

Code: Select all

#!/bin/sh

if [ -n $SUDO_USER ]; then
su - $SUDO_USER -c '/opt/bin/mk-jwm.menu && jwm -reload'
else
user=`echo $XAUTHORITY | sed -e 's,/[^/]*$,,' -e 's,.*/,,'`
su - $user -c '/opt/bin/mk-jwm.menu && jwm -reload'
fi

Changed the "user=.." line to extract the username in any case of where $HOME is.
Also when logged in as root the $user variable will be root.

Thank you, Fred!
I will use this one.
Works for user after running sudo apt-get install. Not tested proper for Synaptic yet.

The problem is all configurations do not work for manual refres-menus for user account. It asks for user password and then asks again for root password and then gives failure message.
I can create separate manual refresh-menus option to run debmenu-changes and different menu-puppy and refresh-menus script for user account.

Or we can use the configuration that works for root and needs manual type refresh-menus for user account only after using sudo apt-get. It uses the same scripts for user and root for manual refresh and auto-refresh menus after installin/uninstalling programs. No need from two separate script lines for manual and autorefresh menus.

Much options to consider

Toni

[saintless]

Here's a different way of loading a sfs or squashfs module.
Not only activate the module but also run the corresponding apllication at the same time.
When running "portablesfs" a "application-portable" script will be created in the same folder as the module.

Thank you, Fred!
Added next to SFS-Loader-new and SFS-Loader-old menu items.

[saintless]

Hi, William.

I need your help on this one. I remember you wrote you have some experience with XDM in the past.
XDM changes the PATH when is active and do not allow the system to read /etc/profile export lines. Not only for user but also for root.
I thought this is the only problem and adding the export lines from /etc/profile to /etc/environment will fix it. It did but it gives also secure bin paths for user account which is not right.
Unfortunately this is not the only problem. When XDM is active Synaptic does not work anymore with sudo. It needs su-to-root if xdm is active.
Reading XDM man pages it really changes the paths but I don't know why it creates this sudo not working issue.

Code: Select all

puppy@debian:~$ sudo synaptic
[sudo] password for puppy: 
No protocol specified

(synaptic:10524): Gtk-WARNING **: cannot open display: :0
puppy@debian:~$ 

We need to fix this problems for the beta.

What I have tested is full install of XDM and it behaves the same way.
There is /etc/init.d/xdm file which has PATH= line inside but changing the PATH there does not change anything. It seems something has to be configured for user and root paths in the files in /etc/X11/xdm folder.

You can test this problem with the last 01-v7.squashfs. Just use save file and delete the lines in /etc/envioronment
Check out then the path for user and root with echo $PATH to see the difference.

/opt/bin/xdm-stop will stop xdm and restore autologin as root after reboot. And everything is back to normal for user and root.
/opt/bin/xdm-start will activate xdm after reboot.

i also tried installing SLIM and it works OK without changing the PATH and /etc/profile is in use for user and root. Tested with empty /etc/environment
The problem with SLIM is after stopping SLIM and trying to autologin as root I can't get to X for user and root. I still think SLIM is unreliable and we should not use it but may be we I should try to make it work in separate sfs module to be tested as replacement of xdm.
BTW removing most of the themes for slim makes it two times smaller.

Toni

[saintless]

Hi, Terry.
Installing e3 text editor makes 9 desktop files from this menu file content:

Code: Select all

?package(e3):needs="text" section="Applications/Editors"\
  title="e3em" command="/usr/bin/e3em"

?package(e3):needs="text" section="Applications/Editors"\
  title="e3vi" command="/usr/bin/e3vi"

?package(e3):needs="text" section="Applications/Editors"\
  title="e3pi" command="/usr/bin/e3pi"

?package(e3):needs="text" section="Applications/Editors"\
  title="e3ws" command="/usr/bin/e3ws"

?package(e3):needs="text" section="Applications/Editors"\
  title="e3ne" command="/usr/bin/e3ne"

e3ne is only one e3ne.desktop.
All others have .desktop working file + .desktop.desktop file which does not appear in the menu with this content inside for example e3ws.desktop.desktop:

Code: Select all

[Desktop Entry]
Type=Application

And e3ws.desktop:

Code: Select all

[Desktop Entry]
Type=Application
Terminal=true
Categories=Applications;Editors;
Name=e3ws
Exec=default_virtual-terminal -e /usr/bin/e3ws

Toni

[fredx181]

Hi Toni

i also tried installing SLIM and it works OK without changing the PATH and /etc/profile is in use for user and root. Tested with empty /etc/environment
The problem with SLIM is after stopping SLIM and trying to autologin as root I can't get to X for user and root. I still think SLIM is unreliable and we should not use it but may be we I should try to make it work in separate sfs module to be tested as replacement of xdm.

I've been struggling with this also, the only thing that seemed to work was uninstalling slim to get working startx back.
But now after some experimenting I found workaround:
Simular to your xdm-stop, slim-stop:

Code: Select all

#!/bin/bash

[ "`whoami`" != "root" ] && exec gsu ${0}

insserv -r slim
mv /etc/X11/Xsession.d/20slim_locale /etc 2> /dev/null
cp -fr /etc/inittab-auto /etc/inittab

And slim-start:

Code: Select all

#!/bin/bash

[ "`whoami`" != "root" ] && exec gsu ${0}

insserv slim
#mv /etc/20slim_locale /etc/X11/Xsession.d # better leave this commented out
cp -fr /etc/inittab-noauto /etc/inittab
#service slim start # uncomment if you want slim started instantly

You'd expect in slim-start the copying back of 20slim_locale but better don't because startx stops working by that (in current session), slim works without that file AFAIK.
BTW, A great advantage of slim is that it has autologin supported.

Fred

[saintless]

Thank you, Fred!
If I can make it work well I will add it to DebianDog. I edited slim.deb to be less than 200 K from 1,2Mb. It has only one theme now with Linux-Village background. + dependencies it will add less than 1Mb uncompressed this way.
Here is the edited deb if you are interested:
http://smokey01.com/saintless/Fredx181/ ... 2_i386.deb
It will be nice to have SLIM working also.

Toni

[fredx181]

Hi Toni
Thanks for the slim deb.
I found a better solution IMO
The key is :

Code: Select all

touch /etc/default/locale

Then whatever you want (I use "insserv -r slim" to disable slim service) like:
slim-stop:

Code: Select all

#!/bin/bash

[ "`whoami`" != "root" ] && exec gsu ${0}

insserv -r slim
cp -fr /etc/inittab-auto /etc/inittab

slim-start:

Code: Select all

#!/bin/bash

[ "`whoami`" != "root" ] && exec gsu ${0}

insserv slim
cp -fr /etc/inittab-noauto /etc/inittab

Fred

[mcewanw]

Hi, William.

I need your help on this one. I remember you wrote you have some experience with XDM in the past.
XDM changes the PATH when is active and do not allow the system to read /etc/profile export lines. Not only for user but also for root.
I thought this is the only problem and adding the export lines from /etc/profile to /etc/environment will fix it. It did but it gives also secure bin paths for user account which is not right.
Unfortunately this is not the only problem. When XDM is active Synaptic does not work anymore with sudo.

Hi Toni, I haven't checked Synaptic yet, but I think the PATH for xdm sessions should be set in /etc/X11/xdm/xdm-config

So comment out your PATH line in /etc/environment and in xdm-config try adding immediately after:

Code: Select all

DisplayManager.willing:		su nobody -s /bin/sh -c /etc/X11/xdm/Xwilling

the following:

Code: Select all

DisplayManager*userPath: /opt/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
DisplayManager*systemPath: /opt/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/sbin:/usr/sbin:/sbin

and reboot. That seems to fix the PATH's appropriately for root and normal user for me.

There are lots of info about setting up xdm. For example, the PATH change above is mentioned near the beginning of chapter 9.1 XDM of the following downloadable pdf:

http://www.tldp.org/HOWTO/pdf/Path.pdf

[saintless]

Thank you, William!
I also found this pdf an hour ago and testing the same.
The path works on the top above this line also.

Code: Select all

DisplayManager.authDir:	/var/lib/xdm

And I read it is good to add /usr/bin/x11
I have this now as paths:

Code: Select all

DisplayManager*userPath: /opt/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/bin/x11
DisplayManager*systemPath: /opt/bin:/usr/local/bin:/usr/bin:/usr/bin/X11:/bin:/usr/local/games:/usr/games:/usr/local/sbin:/usr/sbin:/sbin"

The path works in but it does not solve the sudo issue with sinaptic.

Toni

[mcewanw]

Toni, I don't know if there is some trick for xdm configs to export DISPLAY and Xauthority, however:

Exporting DISPLAY and Xauthority environment variables followed by changing sudoers file to keep DISPLAY and Xauthority might do the trick per the links below, Tony. I am just going out so don't have time to test it:

http://blog.edwards-research.com/2012/0 ... with-sudo/

http://dev-loki.blogspot.co.nz/2009/01/using-sudo.html

First of all, edit /etc/sudoers (which one should always do using the command visudo as it validates the configuration before saving it) and allow the environment variables DISPLAY and XAUTHORITY to be forwarded when using sudo, by adding the following line:

Code: Select all

Defaults env_keep += "DISPLAY XAUTHORITY"

The second step is to set and export the environment variable XAUTHORITY. The simplest option is to add the following line to your ~/.bashrc or add it to /etc/bash.bashrc.local, the latter being for all users on your host:

Code: Select all

[ -n "$DISPLAY" -a -e "$HOME/.Xauthority" ] && export XAUTHORITY="$HOME/.Xauthority"

http://unix.stackexchange.com/questions ... forwarding

http://ubuntuforums.org/archive/index.p ... 52811.html

[mcewanw]

Yes, my above post about xdm and modify sudoers with visudo seems to work. Following the sudo config change, I had synaptic working from puppy user quicky via:

Code: Select all

puppy@debian:~$ export DISPLAY
puppy@debian:~$ export XAUTHORITY=".Xauthority"
puppy@debian:~$ sudo synaptic

Still, I imagine there 'might' be a variable in xdm configs that could set it all up automatically somehow. I just don't know what.

Further info in Section 9.4.12 onwards of:

http://qref.sourceforge.net/Debian/refe ... ne.en.html

THE ABOVE LINK LOOKS PARTICULARLY USEFUL. Provides an alternative trick to run sudo gui commands from normal user login:

9.4.12 Getting root in X

If a GUI program needs to be run with root privilege, use the following procedures to display program output on a user's X server. Never attempt to start an X server directly from the root account in order to avoid possible security risks.

Start the X server as a normal user and open an xterm console. Then:

$ XAUTHORITY=$HOME/.Xauthority
$ export XAUTHORITY
$ su root
Password:*****
# printtool &

When using this trick to su to a non-root user, make sure ~/.Xauthority is group readable by this non-root user.

To automate this command sequence, create a file ~/.xsession from the user's account, containing the following lines:

# This makes X work when I su to the root account.
if [ -z "$XAUTHORITY" ]; then
XAUTHORITY=$HOME/.Xauthority
export XAUTHORITY
fi
unset XSTARTUP
# If a particular window/session manager is desired, uncomment
# the following and edit it to fit your needs.
#XSTARTUP=/usr/bin/blackbox
# This starts x-window/session-manager program
if [ -z "$XSTARTUP" ]; then
if [ -x /usr/bin/x-session-manager ]; then
XSTARTUP=x-session-manager
elif [ -x /usr/bin/x-window-manager ]; then
XSTARTUP=x-window-manager
elif [ -x /usr/bin/x-terminal-emulator ]; then
XSTARTUP=x-terminal-emulator
fi
fi
# execute auto selected X window/session manager
exec $XSTARTUP

Then run su (not su -) in an xterm window of the user. Now GUI programs started from this xterm can display output on this user's X window while running with root privilege. This trick works as long as the default /etc/X11/Xsession is executed. If a user set up his customization using ~/.xinitrc or ~/.xsession, the above mentioned environment variable XAUTHORITY needs to be set similarly in those scripts.

Alternatively, sudo can be used to automate the command sequence:

$ sudo xterm
... or
$ sudo -H -s

Here /root/.bashrc should contain:

if [ $SUDO_USER ]; then
sudo -H -u $SUDO_USER xauth extract - $DISPLAY | xauth merge -
fi

This works fine even with the home directory of the user on an NFS mount, because root does not read the .Xauthority file.

There are also several specialized packages for this purpose: kdesu, gksu, gksudo, gnome-sudo, and xsu. Some other methods can be used to achieve similar results: creating a symlink from /root/.Xauthority to the user's corresponding one; use of the script sux; or putting "xauth merge ~USER_RUNNING_X/.Xauthority" in the root initialization script.

So the following seems to work:

1. Don't bother altering /etc/sudoers. Instead:

2. Add the following code to the bottom of /root/.bashrc

Code: Select all

if [ $SUDO_USER ]; then
sudo -H -u $SUDO_USER xauth extract - $DISPLAY | xauth merge -
fi

3. And add the following to the beginning of both ~/startup=jwm and ~/startup-icewm (where ~ is home directory of normal user such as puppy):

Code: Select all

if [ -z "$XAUTHORITY" ]; then
XAUTHORITY=$HOME/.Xauthority
export XAUTHORITY
fi

Then, when logged in as normal user, sudo 'command' seems able to open the GUI in the user's X display. I expect it works with su also.

EDIT: works using sudo from user's xterm anyway, but I seem to have missed something cos didn't work from JWM menu and I'm going out so can't test further just now.

I don't understand, Toni, how you were able to use su as a normal user and then run synaptics without this trick.

[sunburnt]

# Trying to detect USB device type, H.D., CD-DVD, Flash, SD, etc.
It seems impossible to do this. It`s even very hard to detect if sdxx is removable or not.
dmesg and /var/log/messages is only way to detect a USB event. Difficult to parse them.
What a horrible mess Linux/Unix is... Getting info is a scattered and sketchy affair.
# Trying to write a USB installer for DebDog. Looks like it`s going to be ultra simple.


# Toni; Fixed I believe. Odd that only the e3 menu file caused it.

[sunburnt]

# Toni & Fred; Do we have a way to use a dir. for the live-rw.? How about a partition.?
I read that Fred had a live-rw dir. working in PorteusDog.

# If partition is just Deb/PorteusDog + live-rw dir., then the partition can be 1-2 GB in size.
And so a fsck of the partition is quick, and at the same time the O.S. files get checked too.

# Thinking of a USB setup like this:

| Windows FAT partition | Boot partition 1-2GB | Extra O.S. partitions 1-2GB | Swap |

Most USBs would only have 2 partitions, "Windows FAT", and "Boot + Deb-Live".
FAT for the main storage area is okay, it can hold anything except Linux files. Better than NTFS.
And FAT dosen`t care if it`s mounted while doing a fsck, making it easy to maintain.
Most USBs won`t have other O.S.s, and a swap file/partition on a Flash device is a bad idea.
If the PC is low on ram, then using a second "expendable" 1-2GB Flash drive is a good solution.
I`m guessing a "swap" Flash drive will last about 6 months of normal daily use. So a cheap one...
Sadly buying more ram for old PCs is just a bad idea, DDR-3 costs less than older ram does.
.

[saintless]

Further info in Section 9.4.12 onwards of:

http://qref.sourceforge.net/Debian/refe ... ne.en.html

THE ABOVE LINK LOOKS PARTICULARLY USEFUL. Provides an alternative trick to run sudo gui commands from normal user login:

Thank you, William!
I will test this today.

I don't understand, Toni, how you were able to use su as a normal user and then run synaptics without this trick.

I see nothing strange since Debian Live Standard CD also doesn't need to use tricks like that. It has active user account and after installing X you get straight to X from login prompt. After sudo apt-get install synaptic all it needs is to type sudo synaptic and it starts. Nothing from your post above is needed.

The strange thing for me is XDM is the only Display manager that needs this operations to make Synaptic work.
LightDM and Slim does not need this to make Synaptic work for user.

EDIT: works using sudo from user's xterm anyway, but I seem to have missed something cos didn't work from JWM menu and I'm going out so can't test further just now.

The script which starts Synaptic from menu is /opt/bin/synaptic-start:

Code: Select all

#!/bin/bash

if [ "`whoami`" != "root" ]; then
xterm -e sudo synaptic
exit 0
fi

synaptic

It works for user when autologin is active and with LightDM and Slim without changing anything.
I guess the changes you posted make the user account to run direct the synaptic line in the script without sudo? Need to test this first to confirm.

Toni

[saintless]

# Trying to write a USB installer for DebDog. Looks like it`s going to be ultra simple.


# Toni; Fixed I believe. Odd that only the e3 menu file caused it.

Thank you, Terry!

# Toni & Fred; Do we have a way to use a dir. for the live-rw.? How about a partition.?

We can use folder only if DebianDog boots with porteus-boot-initrd. It will be available boot option in the beta iso version.
With debian live-boot which we use now and is default for DebianDog we can not use folder but we can use save partition. Haven't tested this myself but I think all we need is to make ext partition and label it live-rw.

# Thinking of a USB setup like this:

| Windows FAT partition | Boot partition 1-2GB | Extra O.S. partitions 1-2GB | Swap |

I also think SWAP partition on flash drive is not needed.
Terry, the structure of DebianDog beta iso will be this one:
http://smokey01.com/saintless/Light-Whe ... g-test.iso
It has two initrd files and more files and folders in /live
It is needed to make it boot both ways - debian and porteus.
What about if the flash drive is only 1Gb or less? Will it be possible to install DebianDog on smaller flash drive?
DebianDog beta iso will be around 110 Mb with porteus-initrd and debian-initrd included.

Toni

[sunburnt]

So I assume it`s a bit of code in Porteus initrd that does the alternate live-rw setup.

# Q... Will DebDog boot with Porteus initrd with Wheezy kernel.? Is there a Porteus kernel.?

I don`t know differences, but if Fred put up lots of effort, then the initrd has some advantages.
# Could make 2 partitions, 1 for DebDog and 1 for live-rw. But both in 1 has advantages.

Toni; Didn`t mention, if USB < 8GB, then 1 Linux partition. Why make small even smaller.?


# Here`s "drive-info", it`s for the USB installer.
You can see the USB removable "rem" drive:

Code: Select all

Part Type F/R Boot        Sizes            Drv.Label
=====================================================
sda1 ext3 fix boot 6.320-GiB 6786383872 
sda2 swap fix      1.953-GiB 2097152000 
sda3 ext3 fix      103.5-GiB 111148007424 
sdb1 vfat rem boot 7.216-GiB 7747895808 Red-8gb

# What a pain it was getting just this info., 5 different sources were needed.!
/proc/partitions, dmesg, disktype, fdisk, and blkid
The best part is that all this info can be gotten with the partition un-mounted.

# The parted tools can do all of this and make and manipulate partitions.

# Makes me think of having env variables to hold each line of this info.
$PART_SDA1, $PART_SDA3, $PART_SDB1, etc.
Then no files to read and very little parsing to get the needed info.
At the very least, we should have a system info. file to "source" to get info.

# I`ll post the whole installer when it`s ready.
# Please give a test try with USBs in & out and let me know...

### UPDATE: Now has "Boot" column added ( See output above )..