MintPup (Trusty LTS)

[saintless]

Hi Fred.

I cannot reproduce this from where I am now, logged in as puppy on openbox-jessie.
Very strange, btw, why can't it find fdisk? It's in PATH

Looking /etc/profile I guess it is because it exports the same path for user and root in OpenBox version:

Code: Select all

if [ "`id -u`" -eq 0 ]; then
PATH="/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"
else
PATH="/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"
fi

export PATH

This is the same section in Jwm version and in MintPup:

Code: Select all

PATH="/opt/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
[ "`id -u`" -eq 0 ]&& PATH="$PATH:/usr/local/sbin:/usr/sbin:/sbin"
export PATH

For user account sudo should export secure path in /etc/sudoers
For some reason ktsuss doesn't export secure path or doesn't use /etc/sudoers file.

Edit: Didn't see your Edit. Yes, it is the difference in /etc/profile
BTW I have some lines in /etc/environment needed for xdm and rox-filer fixes.

Toni

[mcewanw]

You do realize, Fred and Toni, that you've discussed the, somewhat major I feel, difference between openbox and jwm /etc/profile PATH handling before. I can't remember where exactly, but been long time ago I know.

I have to say, I don't think user and root 'should' have the same default PATH (why should a normal user have access to executables in /sbin, for example). But main thing is that this difference seems to come back to haunt developments in the sense that scripts developed on openbox version sometimes it seems have problems on jwm DD/MintPup etc.

I think you can tell my opinion - the scripts should be written on the basis of the user default PATH not having access to admin binaries, but easy for me to say. More generally, it appears from reading these repeating problems that the jwm and openbox versions would be easier to maintain if underlying system configs were kept identical (aside from wm configs etc). I use both jwm and openbox versions at home, and I do generally run as root user, but that's only because I'm being lazy - I keep intending moving over to normal user most of the time, if only because running as root user encourages poor use of access control rights (appropriate file/dir permissions included) which is certainly a big no no in professional circles, and bad from an app developer's point of view since what works as root may turn out not to work as a normal user on big Linux systems.

William

EDIT: For the sake of balance, please let me also say that in terms of look and feel and pleasure in usage, the DD-openbox is the nicest, IMO... That is probably because openbox allied with xfdesktop and Thunar is such a pleasant combination - so no surprise to me that a non-technical user such as my partner likes that one the best. I'm a bit different though - I'm really into low resource usage at the expense of some of the 'niceties' and I also think JWM isn't too bad once tweaked a bit (I just haven't bothered since what is there is fine for me). And Rox is also very efficient (running several Rox filers doesn't seem to increase overall Rox resource usage much at all - basically once Rox pinboard is running, that seems to pretty much determine most all resources Rox ever uses... amazing really). But most modern systems have 'tons' of resources, so worrying about a few MB RAM here and there isn't probably very important to most people (even my 'newer' machines, the HP elitebooks, are from 2009 and have 2GB RAM for example - plenty for most of the junk I do no matter which of the DD or MintPup systems I'm running :-) But keeping normal user access controls as tight as big brother Debian/Ubuntu/Mint seems pretty important to me (despite the oft-discussed views of the Puppy Linux world more generally).

[saintless]

You do realize, Fred and Toni, that you've discussed the, somewhat major I feel, difference between openbox and jwm /etc/profile PATH handling before. I can't remember where exactly, but been long time ago I know.

Hi William.
I agree user should not have /sbin and /usr/sbin in path without using sudo. And I remember we had similar discussion before. In general this difference is not so important because using sudo (gsu) doesn't have problem to add secure path for user account.
But this difference makes impossible for Fred to find problems like ktsuss not exporting secure path while testing script changes.
Just for info in case Fred likes to do the same in OpenBox I have also this in /etc/environment:

Code: Select all

GDK_NATIVE_WINDOWS=true #fix for rox-filer focus problem.
LD_LIBRARY_PATH="/opt/lib:/usr/local/lib" #xdm can't use libs from /opr/lib and /usr/local/lib without this.

I think we don't have other path differences.

Fred,
After some more testing and making deb packages for remaster scripts I agree it will be best to change inside gsu-root to use sudo. This will save us some ktsuss troubles in the future. BTW I can't remember why I had to make /opt/bin/blkid link but I guess it is also because the ktsuss problem we found yesterday.

Edit: Yes, /opt/bin/blkid link is needed because of the ktsuss problem. I will remove the blkid link after changing ktsuss with gsu.

Edit2: I think it is better to remove ktsuss and /opt/bin/ktsuss2 from the system and from dd/mintpup repository. If it is available in official Debian?Ubuntu repository it is user choice to install it. No need to have it inside the system since it doesn't work well in MintPup and DebianDog.

Toni

[fredx181]

Edit2: I think it is better to remove ktsuss and /opt/bin/ktsuss2 from the system and from dd/mintpup repository. If it is available in official Debian?Ubuntu repository it is user choice to install it. No need to have it inside the system since it doesn't work well in MintPup and DebianDog.

Yes, I agree with that, it's not working as it should, all other su commands give correct PATH (for root id), except ktsuss.
That's probably the reason that I changed /etc/profile, as a workaround to make ktsuss work properly.
I will change /etc/profile to the same as it is on JWM version.

Edit: Because of the changed PATH in /etc/profile 'obshutdown' isn't found when logged in as user, I think I'll solve that by creating symlink in /opt/bin.
Hopefully obshutdown is the only problem in Openbox version.

Edit2: Trying to make the change from ktsuss to 'sudo -E', I found that just this in /opt/bin/remastercow-start works fine:

Code: Select all

xterm -T "RemasterCow" -si -sb -fg white -bg SkyBlue4 -geometry 65x14 -e sudo -E /opt/bin/remastercow

The 'sudo -E' will be ignored when running as root.
Can be similar for remasterdog.
Just first idea, maybe there is a better solution.

Fred

[saintless]

Hi Fred.
I prefer to change less as possible. Changing the content of one file only ( /opt/bin/gsu-root) is the best way to go. Attached gsu-root in archive if you like to continue the testing with this script. It is gsu-notimeout with added -E.
When I'm ready with the testing I will upload new remaster-scripts with /opt/bin/gsu-root included and new install scripts package.

BTW I had one situation when remasterdog and remastercow do not work because some process from previous remasterdog or remastercow is still active. There was error about /dev/sda1 is already mounted according the information in /etc/mtab. The error message is visible after removing 2> /dev/null from mount /dev/$DRV /mnt/$DRV 2> /dev/null line. I'm not sure yet if this could be a problem but I think you can reproduce it by opening second remasterdog while the first one is still active copying files. I will test this situation more.

Edit: It works for me starting remasterdog and remastercow at the same time now. Maybe I did something else to cause this error. I will try to reproduce it later.

Toni

[fredx181]

I prefer to change less as possible. Changing the content of one file only ( /opt/bin/gsu-root) is the best way to go. Attached gsu-root in archive if you like to continue the testing with this script. It is gsu-notimeout with added -E.

Yes, it's good solution, works ok for me from quick test.

Fred

[fredx181]

Hi everyone,

*** New openbox-mintpup light setup ***

Thanks to the suggestions from William for using rox-pinboard!.
There's choice now to use rox-pinboard or tint2 left-panel for providing the desktop (see below and screenshots)

As I didn't want to change any existing settings for rox, there's one annoying thing:
The iconified windows from rox-pinboard are (for a part) under the conky window.
To disable iconified windows go in rox options and uncheck "Show iconified windows"

Info:
(see also README-setup in the extracted openbox-mintpup_setup-0.0.2.tar.gz)
-------------------
Openbox-mintpup setup, version 0.0.2.

Changes:
- Very much improved menu, it reads now from /etc/xdg/menus/mintpup-ob-applications.menu.
It's a modified /etc/xdg/menus/xfce-applications.menu
It looks similar to the menu in DebianDog Openbox_xfce version.

- Choice of 2 desktop types:
-- Rox pinboard, desktop provided by rox, with launcher icons, tranparent conky, tint2 bottom panel.
-- Tint2 transparant left-panel with launcher icons, tranparent conky, tint2 bottom panel.
To switch between them: Menu > Desktop Manager
Wallpaper chooser (Menu > Set Wallpaper) is different for Rox pinboard and Tint2 transparant left panel;
for tint2 panel it's nitrogen, for rox-pinboard it's the wallpaper gui program from Terry, just like on JWM.

To install: (can be installed over previous version 0.0.1, will overwrite old configuration in ~/.config/openbox when running 'Start Openbox' from menu):

After apt-get update :

FIRST: Install tint2_0.11+svn20121014-3_i386.deb:
This tint2 version is from Debian Jessie, the Ubuntu Trusty tint2 version is to old.

From terminal in this directory:
dpkg -i tint2_0.11+svn20121014-3_i386.deb
And:
apt-get -f install

THEN:
Install openbox-mintpup_0.0.2_i386.deb:

From terminal in this directory:
dpkg -i openbox-mintpup_0.0.2_i386.deb
And:
apt-get -f install

Total install size: around 9 MB

To start: Jwm menu > System > Start Openbox
To get back to Jwm from Openbox: Menu > Settings > Start Jwm

When installing from previous version installed while inside Openbox-mintpup session, upgrade to 0.0.2 by running Menu > Settings > Start Openbox.
Warning: this will overwrite the configuration in ~/.config/openbox
--------------------------
Download:

Edit: Link to openbox-mintpup_setup-0.0.2 removed, since it conflicts with new package jwm-obmenu (Menu Openbox for Jwm) if openbox-menu is activated.
Replaced by version 0.0.3, conflicting has been fixed.
https://googledrive.com/host/0ByBgCDlZZ ... 0.3.tar.gz

Toni, I really didn't want not interfere with JWM session, and I think I succeeded with that. except one thing:
In ~/.config/rox.sourceforge.net/ROX-Filer/globicons some icon paths are added (e.g. for conkytoggle), it doesn't show anything from that on JWM or Icewm though.

Edit2:
openbox-mintpup is now part of the mintpup repository, so to easy install, just in terminal:

Code: Select all

apt-get update # might be required to update the package lists
apt-get install openbox-mintpup

Or install it from Synaptic package manager.

Fred

[saintless]

Hi Fred.

The link in the first post changed to your new openbox setup.

DebDog repositories updated with mpv, youtube-viewer, debdoginstallscripts_1.0.5_i386.deb, remaster-scripts_1.0.4_i386.deb with latest progressbar fixes and changed gsu-root. I will make updated packages for MintPup later. Fixes post for Wheezy and Jessie updated.

I can't reproduce again the problem I had with not working remastercow and remasterdog after the message sda1 already mounted. If it happens again in the future (it was with live-boot-3 no persistence) I will try to get more information before reboot.
I don't think the testing is enough yet for remastering and install scripts changes but all looks OK so far testing with all boot methods on my machine.

Toni

[futwerk]

some new backgrounds.

[saintless]

some new backgrounds.

Thanks futwerk!
All mirrored here:
http://kazzascorner.com.au/saintless/Mi ... reenshots/

Toni

[mcewanw]

Hi everyone,

*** New openbox-mintpup light setup ***

Looking good Fred. One small issue I've noticed when checking resource usage:

When starting htop or top from Menu, a background xterm also appears. That hasn't happened in other versions of DD or MintPup as far as I recall.

William

[mcewanw]

I don't myself have any particular favourite desktop, but I'm trying a psychological experiment by using the following on my partner's machine. I am testing my theory that it is not openbox or jwm differences that makes her like DD_openbox_wheezy look and feel the most. Rather, I suspect it is simply the wallpaper used and desktop icons placed vertically and horizontally rather than the Puppy-like traditional triangular desktop icon placing, which I also find somewhat ugly. We shall see ;-)

Note in my screenshot below (using MintPup jwm) I've not only adopted Fred's openbox_wheezy wallpaper but also made the taskbar icons a max of 32 bits (to look similar to Fred's current MintPup_openbox). i.e. I've modified the following ~/.jwmrc line 186 from:

Code: Select all

<TaskList maxwidth="256"/>

to

<TaskList maxwidth="32"/>

because I like the effect. However, all this is just a matter of taste of course but shows how easy it is to change the look of the jwm version too.

I do note that, according to htop, the jwm version does use a few tens of MB less RAM though, even with conky disabled on openbox version, but that smallish difference probably doesn't matter much in practice on most machines or to most users.

William

Wow, PicDrop is so handy for quickly rescaling images. I used SCReen-shOT for the screen capture and just dropped the result into PicDrop to scale the image to 600 px wide max since I prefer that for forum use. Makes the displayed resolution a bit rough of course...

[saintless]

When starting htop or top from Menu, a background xterm also appears. That hasn't happened in other versions of DD or MintPup as far as I recall.

Hi William.

This is because Terry's makejwm.menu doesn't read the line "Terminal=true". To make terminal programs work in Jwm version (and MintPup) I use "xterm -e" where it is needed inside .desktop file.
I guess OpenBox menu reads the "Terminal=true" line and second terminal appears because of "xterm -e".

I've modified the following ~/.jwmrc line 186 from:

Code: Select all

<TaskList maxwidth="256"/>

to

<TaskList maxwidth="32"/>

because I like the effect. However, all this is just a matter of taste of course but shows how easy it is to change the look of the jwm version too.

I'm sure every user will like to change something, but changing ~/.jwmrc doesn't keep the changes after updating the menus.
You need to change ~/.jwm/jwm.tail and run Menu-Puppy.
~/.jwmrc is generated from the files in ~/.jwm after installing/uninstalling packages.
If you like to change the theme later ~/jwm/jwm.tail will be replaced with file from /opt/docs/jwm-themes so it is better to add the change in all files there too (or make the change again in ~/.jwm/jwm.tail after changing the theme).

Toni

[mcewanw]

Ah, thanks Toni for explaining how jwm menu gets processed. Now that
you've mentioned it I think I recall similar arrangement in Puppy itself. Anyway, modified jwm.tail now with same code change and all fine following my running menu-puppy and restarting jwm.

I imagine Fred will tackle the extra xterm issue for openbox version - I guess the 'proper' solution would be to change one of Terry's scripts (or a new intermediate script) to honour the exec from terminal line, but maybe a bit tricky.

William

EDIT: without having checked the source, I currently presume mk-jwm.main is the main menu creation script, which I guess is in BaCon.

[saintless]

EDIT: without having checked the source, I currently presume mk-jwm.main is the main menu creation script, which I guess is in BACON.

Yes
And unfortunately I can't do anything to fix this problem.
It also doesn't read files in ~/.local/share/applications
This was the reason to add Menu-MJWM as third menu option (which generates the menus much slower btw).
And we also have the official Menu-Debian (/usr/bin/update-menus method) generated from /usr/share/menu files.
I prefer not to touch the menu system. It was difficult to get it work well.
But it can be removed easy by uninstalling mkjwmmenu.
Then only the official update-menus method will be available for generating menus.

Toni

[mcewanw]

EDIT: But I do think it is good to have a menu that can be generated from desktop files, rather than just the debian method. BaCon syntax looks relatively easy (compared to bash even).

I haven't tried this (yet), since I am no longer familiar with BASIC (like alone BaCon) but after a quick look at the syntax I think 'something' like the following modification to mk-jwm.main.bac should add the xterm -e only when specified in desktop file. The only change (2 or 3 lines of code) is the use of variable termi$ and an extra CASE followed by concatenation in exe$. Most of the following is identical to original lines 35 onwards in the source:

Code: Select all

												'#####  LOOP:  Make raw menu.
FOR i = 0 TO DtSz-1
	name$ = "" : genname$ = ""
	exe$ = "" : ico$ = "" : cat$ = "" : termi$ = ""

	'###	This assumes the "Exec=" line has ONLY [/path/]file, no extra crap.
	OPEN DT$[i] FOR READING AS file_
		WHILE NOT(ENDFILE(file_)) DO
			IF ENDFILE(file_) THEN BREAK
			READLN txt$ FROM file_
			sep = INSTR(txt$, "=")
			Var$ = MID$(txt$, sep+1)

			SELECT LEFT$(txt$, sep)
				CASE "Name=" : name$ = Var$
				CASE "GenericName=" : genname$ = Var$
				CASE "Terminal=" : IF Var$ = "true" THEN termi$ = "xterm -e "
				CASE "Exec="
					exe$ = termi$ & Var$
					termi$ = ""
				CASE "Icon=" : ico$ = Var$

But at this exact moment I have never even tried compiling BaCon program...

Also, the hard-coded 'xterm -e' above wouldn't be the best either.

If I can get it working I'll let you know anyway.

William

EDIT2: I'm sure Terry could fix this in ten seconds...
EDIT3: I note that /usr/share/applications dir is hardcoded in existing implementation.
EDIT4: Instead of hardcoding xterm -e above should, if possible, use default terminal command really (in case some other terminal rather than xterm is installed). That may be tricky though since other terminals may use different option that -e to run executables.

[mcewanw]

Hi again Toni,

I see it is all pretty complicated and note that the program /usr/bin/mjwm is an executable for creating JWM menu from desktop files by Chirantan Mitra. Is there a problem with that method that made it better to invent a new wheel (method)?

EDIT: From what you said, I presume Terry's scripts end up being faster at generating a suitable menu? Might be worth trying to develop them if so (particularly since the core of it all seems to be that one script of only around 170 lines of code total - mk-jwm.main.bac).

William

[saintless]

Hi William.

EDIT: But I do think it is good to have a menu that can be generated from desktop files, rather than just the debian method.

I don't see problem using the official debian update-menus method and it is the only working method if you change Jwm with IceWM. For example rox-filer package in ubuntu doesn't include .desktop file but only /usr/share/menu file.
BTW my vote was for the official debian method from the start and I don't care if it doesn't support main categories different icons or adds more sub-menus. It is well tested over the years and supports localization.

Also, the hard-coded 'xterm -e' above wouldn't be the best either.

It is not solution in my opinion. we have one more script from Terry for converting /usr/share/menu files in /usr/share/applications desktop files and it was auto-running in first DD-Jwm versions but didn't work well using apt-get upgrade command and some desktop files were removed while updating the menus. I don't think adding option to auto-edit desktop files adding "xterm -e" is good idea. We have menumaker and desktop-file-editor for this.

I see it is all pretty complicated and note that the program /usr/bin/mjwm is an executable for creating JWM menu from desktop files by Chirantan Mitra. Is there a problem with that method that made it better to invent a new wheel (method)?

Click System - Menu-MJWM and you have it as default menu.
I added this menu system because it reads the files in ~/.local/share/applications
It generates the menu much slower (test and you will see the difference).
I'm not sure if it reads "Terminal=true" line. Didn't make such test and I already had "xterm -e" in some desktop files.

EDIT: From what you said, I presume Terry's scripts end up being faster at generating a suitable menu? Might be worth trying to develop them if so (particularly since the core of it all seems to be that one script of only around 170 lines of code total - mk-jwm.main.bac).

If you like to try you are welcome. But it will need much testing after any change to confirm the menu system works well.
Also both methods (Terry's and Mitra's) don't support changing localization for the main menu categories (as all special DD scripts don't support localization changes).

I prefer to keep the menu system as it is. If I have to test again the menu systems after making changes I prefer to restore the official debian update-menus method and remove all others.

If you or anyone else likes to change and improve Terry's script and test properly the changes (especially with apt-get upgrade and apt-get dist-upgrade) we can update the repository with new deb package anytime.

Toni

[mcewanw]

I don't think adding option to auto-edit desktop files adding "xterm -e" is good idea. We have menumaker and desktop-file-editor for this.

Hi Toni,

Actually, what I was proposing was to not modify the desktop files at all (then openbox menu should work properly) - by which I mean: not having the added xterm -e in the desktop file itself but instead having the menu generator script detecting "Terminal=true" and more correctly (I feel) having the jwm menu generating program adding xterm -e to the jwm menu itself. But I confess to not having studied the (Terry-version) menu system sufficiently to see if that part is as simple as it seems to me on first glance.

Anyway, I don't myself like debian standard menu, so I might give modification a go, since that change 'seems' to be a tiny one (yes, I understand how tricky the menu generating has been...).

Not so easy maybe to include search for desktop files in other locations (though, I'm hopeful, maybe just a couple of lines of extra code to include $HOME/.local/share/applications - I'm not sure). I'll let you know if I come up with anything that works but otherwise I'm also happy with how things are anyway.

William

[saintless]

Actually, what I was proposing was to not modify the desktop files at all (then openbox menu should work properly) - by which I mean: not having the added xterm -e in the desktop file itself but instead having the menu generator script detecting "Terminal=true" and more correctly (I feel) having the jwm menu generating program adding xterm -e to the jwm menu itself.

Sorry, William, my mistake. Looks better this way.

If you decide to work on this here is the deb package with Terry's menu system:
http://www.smokey01.com/saintless/Debia ... 1_i386.deb
And depending on the above package here is Mitra's mjwm menu system:
http://www.smokey01.com/saintless/Debia ... 1_i386.deb
All DD-Jwm and MintPup have the same packages installed.
It will be easier to explore the content of the debs instead searching the files inside the system.

Toni