Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sat 21 Oct 2017, 04:45
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Derivatives
Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 275 of 283 [4236 Posts]   Goto page: Previous 1, 2, 3, ..., 273, 274, 275, 276, 277, ..., 281, 282, 283 Next
Author Message
fredx181


Joined: 11 Dec 2013
Posts: 2521
Location: holland

PostPosted: Fri 02 Jan 2015, 14:07    Post subject:  

bobc wrote:
I'm sorry, I don't know the script language yet even well enough to read and understand things like the squash files.


No need to say sorry Smile
And thanks again for testing!

Fred
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 3882
Location: Bulgaria

PostPosted: Fri 02 Jan 2015, 14:08    Post subject:  

Hi, Fred.

I agree with the posted changes and all are good improvements for me.
I will need some time to test it on a machine with several different formatted partitions.

Toni
Back to top
View user's profile Send private message MSN Messenger 
fredx181


Joined: 11 Dec 2013
Posts: 2521
Location: holland

PostPosted: Fri 02 Jan 2015, 16:22    Post subject:  

Hi Toni,

I've been experimenting with replacement for the gsu line on top of terminal-only scripts.

It's much more complicated but this turned out the best IMO:
For flashplayerchoice for example:

Code:
TITLE=flashplayerchoice

   if [ -z `which gsu` ]; then
   if [ "`whoami`" != "root" ]; then
   tty -s; if [ $? -ne 0 ]; then exec gksu xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; else exec sudo "$0" "$@"; exit; fi
   else
   tty -s; if [ $? -ne 0 ]; then exec xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; fi
   fi
   else
   if [ "`whoami`" != "root" ]; then
   tty -s; if [ $? -ne 0 ]; then exec gsu xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; else exec sudo "$0" "$@"; exit; fi
   else
   tty -s; if [ $? -ne 0 ]; then exec xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; fi
   fi
   fi


From what I tested this works for root and normal user and includes gksu option also.
What I proposed a while back didn't work (had to do a hard shutdown because around 100 xterm windows appeared Smile )
Also this way the .desktop file can be unchanged and the script in /opt/bin works fine when just clicking on it.
And when running in terminal as user it just asks for password as it does normally from terminal.

But maybe you have more simple solution in mind?

Edit: Not sure about things like compatibility but this works as well:
Code:
[ "`whoami`" != "root" ] && exec gsu-xterm ${0} "$@"


Btw, I can't remember, do we have to add gksu option in all scripts that needs admin rights? Or maybe only in the scripts that are part of a .deb package.
I mean such as in frisbee:

Code:
if [ -z `which gsu` ]; then
[ "`whoami`" != "root" ] && exec gksu ${0} "$@"
else
[ "`whoami`" != "root" ] && exec gsu ${0} "$@"
fi


Edit: and can you tell me which terminal-only-scripts we have? I may forget a few.

Fred
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 3882
Location: Bulgaria

PostPosted: Fri 02 Jan 2015, 17:21    Post subject:  

Hi, Fred.
fredx181 wrote:
I've been experimenting with replacement for the gsu line on top of terminal-only scripts.

It's much more complicated but this turned out the best IMO:
For flashplayerchoice for example:

Code:
TITLE=flashplayerchoice

   if [ -z `which gsu` ]; then
   if [ "`whoami`" != "root" ]; then
   tty -s; if [ $? -ne 0 ]; then exec gksu xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; else exec sudo "$0" "$@"; exit; fi
   else
   tty -s; if [ $? -ne 0 ]; then exec xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; fi
   fi
   else
   if [ "`whoami`" != "root" ]; then
   tty -s; if [ $? -ne 0 ]; then exec gsu xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; else exec sudo "$0" "$@"; exit; fi
   else
   tty -s; if [ $? -ne 0 ]; then exec xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; fi
   fi
   fi


From what I tested this works for root and normal user and includes gksu option also.

It seems very complicated in my opinion.

Quote:
What I proposed a while back didn't work (had to do a hard shutdown because around 100 xterm windows appeared Smile )

Can you give me an example? I don't have such problem in Jwm version changing xterm scripts to work with new gsu-notimeout.

Quote:
But maybe you have more simple solution in mind?

Yes, using gsu-xterm as default gsu is much more safe and acceptable choice for me. Adding all this lines in each xterm depending script just because gsu-yad looks better... Why do we need all this troubles changing something already working fine?

Quote:
Btw, I can't remember, do we have to add gksu option in all scripts that needs admin rights? Or maybe only in the scripts that are part of a .deb package.
I mean such as in frisbee:

For included already scripts only the scripts that are part of deb packge.
For new made scripts (debs or not) it is better to use this as standard from now:

Code:
if [ -z `which gsu` ]; then
[ "`whoami`" != "root" ] && exec gksu ${0} "$@"
else
[ "`whoami`" != "root" ] && exec gsu ${0} "$@"
fi


Quote:
and can you tell me which terminal-only-scripts we have? I may forget a few.

Attached archive with the scripts and menu files I made so far regarding changing gsu-xterm with gsu-notimeout. move-in-crypt has desktop file using "xterm -e" and makes terminal popup two times for user account. this is because the menu does not accept Terminal=true option which should work in Openbox version.
snap-make is included because it has gsu line moved up. It was appearing two times from user account.

Edit: The deb packages in temp repo have gsu-gksu line and we must reinstall them anyway because the dependencies are changed. Scripts that are not in the temp repo do not need adding gksu line.

Edit2: Fred, what ever solution works for openBox version is fine as long the xterm scrits work for user and root. I'm working on Squeeze and Wheezy version together and I do not like to change and start testing again the xterm scripts setup.

Toni
xterm-scripts.tar.gz
Description 
gz

 Download 
Filename  xterm-scripts.tar.gz 
Filesize  15.41 KB 
Downloaded  170 Time(s) 

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
fredx181


Joined: 11 Dec 2013
Posts: 2521
Location: holland

PostPosted: Fri 02 Jan 2015, 18:32    Post subject:  

Hi Toni,
Quote:
It seems very complicated in my opinion.

Quote:
What I proposed a while back didn't work (had to do a hard shutdown because around 100 xterm windows appeared Smile )

Can you give me an example? I don't have such problem in Jwm version changing xterm scripts to work with new gsu-notimeout.

Quote:
But maybe you have more simple solution in mind?

Yes, using gsu-xterm as default gsu is much more safe and acceptable choice for me. Adding all this lines in each xterm depending script just because gsu-yad looks better... Why do we need all this troubles changing something already working fine?


It was not my intention to make it more complicated than needed, I just did a stupid thing when experimenting Embarassed
At the top of flashplayerchoice I tried this:
Code:
 if [ "`whoami`" != "root" ]; then
exec gsu xterm -e ${0} "$@"
   else
exec xterm -e ${0} "$@"
   fi

Thinking wrong that it was needed to add the 'else....' for in case the script is run as root.
So that created the endless display of new xterm windows. (don't try this at home Very Happy )
That lead me in the wrong direction to further exploring for a working solution.
I see now that it works fine the simple way.
Code:
 [ "`whoami`" != "root" ] && exec gsu xterm -e ${0} "$@"


Thanks for the archive! It's OK for me like that.
What's the difference for ffmpeg2sfs?, btw.

From your above comment it seems as you like better to include gsu-xterm in new release instead of gsu-yad.
Or is it only about the terminal-scripts?
Don't like the idea that somehow you feel like being forced to use yad-gsu.
We can also decide to have different gsu in Jwm or Openbox version. Should be Ok as long as it works the same way.
Edit: On further thought, maybe better not, it will give compatibility problems and so on.......

Fred
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 3882
Location: Bulgaria

PostPosted: Sat 03 Jan 2015, 03:52    Post subject:  

Hi, Fred.
fredx181 wrote:
Thanks for the archive! It's OK for me like that.
What's the difference for ffmpeg2sfs?, btw.

Thanks, then lets keep it this way since it works for you too.
ffmpeg - sorry, added by mistake in the archive. It is just the latest version from you. No gsu changes in ffpmeg2sfs.

Quote:
From your above comment it seems as you like better to include gsu-xterm in new release instead of gsu-yad.
Or is it only about the terminal-scripts?
Don't like the idea that somehow you feel like being forced to use yad-gsu.

It is not like forcing me, Fred. The reason is we get much complications just from using by default gsu-yad. I know with sure we have someone using DD-Wheezy, someone using DD-Jessie, someone using DD-Sid version. Maybe more reading the post from Andres using DD on several computers.

Then you have the idea about DD packages repository. Great idea, but we should make the packages as good as possible and universal as possible preventing dpkg conflicts. This repository will be added in sources list in next DD version.
Now what happens if one of these 3 DD users with older version adds this repository and start installing packages? First auto-installed dependency will be gsu. If gsu-xterm is auto-replaced with yad-gsu atleast flashplayerchoice, change-frisbee2sns and move-in-crypt will not start from user account. Maybe we will find more scripts later.
We can prevent this by using:

Fix.1. Use /opt/bin/gsu (based on xterm with this code):
Code:
if [ "`whoami`" != "root" ]; then
xterm -T "RemasterCow" -si -sb -fg white -bg SkyBlue4 -geometry 65x14 -e sudo "$@"
else
"$@"
fi

Done. We have compatibility with ald DD versions and all scripts in OpenBox and Jwm version will work without any changes.

Fix 2. Or we can use gsu-yad (because it looks nicer). OK, but not yet.
Problem 1. Some scripts based on xterm do not work with yad-gsu.
Solution 1. Changing the gsu line in the script and inside the desktop file (depending how the script will work). Done.
Problem 2. gsu-yad does not ask for password running second time the same program (as gsu-xterm does it).
Solution 2. Make gsu-timeot and gsu-notimeout scripts. Done.
Problem 3. New gsu.deb will not work in older DD version for xterm-scripts.
Solution 3. Include in the deb all 3 gsu and make it search for DD new version and change gsu-xterm by default for old DD versions. Done.

All is fine and we have nicer looking gsu for new DD and the safe gsu-xterm choice for older DD and standard Debian.

Fix 1. is stupid simple and safe and 100 working for all DD versions + standard Debian.

Fix 2. is much more complicated and all this work just to have nice looking gsu-yad. But now we have it solved and we get the best for new version keeping compatibility with old version.

Then you suggets to fix Problem 1. different way by adding 18 lines of code on top of each xterm-depending script.
This means I will need to start again testing the new solution for Wheezy and Squeeze for possible problems after it is alreday fixed by changing the gsu line in some and desktop file content in others.
It seems too much work for no good reason to me, Fred. If I have to start testing again this xterm-scripts and gsu-yad problem I can't resist to look at Fix 1. and ask why we need all this complications at first place instead using gsu-xterm.

In next DD version lets use as we plan Fix 2. (new gsu deb with gsu-notimeot as default in new DD).

I see nothing wrong if you use different solution for xterm-scripts if you prefer this new code added in OpenBox. It is only in the scripts for new DD version.
The new gsu.deb package is the compatibility solution for old DD versions.
But the default /opt/bin/gsu is best to be the same for both versions in my opinion.

Toni

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
saintless


Joined: 11 Jun 2011
Posts: 3882
Location: Bulgaria

PostPosted: Sat 03 Jan 2015, 06:00    Post subject:  

Hi, Fred.

Two more scripts depending on xterm found. I think they are not included in OpenBox version and the change is needed only for Jwm.
/opt/bin/automount-start and automount-stop

One problem with obshutdown found. Similar to yad--splash and gtkdialog-splash problem. I get sometimes /tmp/obshutdown.lock in use message as puppy user and logout menu does not work untill I do:
Code:
sudo rm -f /tmp/obshutdown*

I think it is because the /tmp file is owned by root or still in use by root. I will test it more to confirm. Edit: added screenshot. It is not root permissions problem because the attached screenshot is from root account. I can easy reproduce it with click on Logout and then Ctrl+Alt+Backspace to exit X. But I think /tmp/obshutdown.lock stays active also in other situations for some reason preventing root or user to use Logout menu. It could be the 'killall jwm icewm" or "pkill X" line in .obshutdown.rc in Jwm version that makes obshutdown not to remove the temp file. I don't know if it could be prevented somehow but we can add script in /opt/bin to remove /tmp/obshutdown.lock when needed by manually running the script.

Edit: One more problem:
/opt/bin/portablesfs does not work from user account in both versions when executing name-portable script. Seems like /opt/lib path is not found but I'm not sure this is the only problem yet. Works fine from root account. Messages from terminal as user:
Code:
puppy@debian:~$ /mnt/home/FTP-Last/DebianDog/Extra-modules/abiword-portable
SUCCESS: Module '023-abiword-2.8.2-docx.squashfs' activated
ACTION: updating mimeinfo cache
abiword: error while loading shared libraries: libxslt.so.1: cannot open shared object file: No such file or directory
SUCCESS: Module '023-abiword-2.8.2-docx.squashfs' deactivated
ACTION: updating mimeinfo cache

============================

puppy@dog:/$ /live/image/FTP-Last/DebianDog/Extra-modules/abiword-portable
mount: warning: /mnt/live/memory/images/023-abiword-2.8.2-docx.squashfs seems to be mounted read-only.
SUCCESS: Module '023-abiword-2.8.2-docx.squashfs' activated
ACTION: updating mimeinfo cache
abiword: error while loading shared libraries: libxslt.so.1: cannot open shared object file: No such file or directory
SUCCESS: Module '023-abiword-2.8.2-docx.squashfs' deactivated
ACTION: updating mimeinfo cache


Edit 2: debdog-full installer seems to work well for me. I will try to test it more in the next days.

Edit 3: Fred, alternative gsu_1.0.0_i386.deb made from gksu may need adding ldconfig in postinst script because of /usr/local/lib files. It may not work in standard Debian without ldconfig I think. Also installed on older DD version I think it will break xterm depending scripts because does not include and set by default gsu-xterm for older DD. Do you like to keep it as it is?

Edit 4: /opt/bin/mnt-all needs adding "$@" in gsu line or umount (mnt-all -u) does not work from user account:
Code:
[ "`whoami`" != "root" ] && exec gsu ${0} "$@"


Toni
obshutdown.jpg
 Description   
 Filesize   26.18 KB
 Viewed   305 Time(s)

obshutdown.jpg

Back to top
View user's profile Send private message MSN Messenger 
fredx181


Joined: 11 Dec 2013
Posts: 2521
Location: holland

PostPosted: Sat 03 Jan 2015, 15:10    Post subject:  

Hi Toni,

Quote:

.....
.....
It seems too much work for no good reason to me, Fred. If I have to start testing again this xterm-scripts and gsu-yad problem I can't resist to look at Fix 1. and ask why we need all this complications at first place instead using gsu-xterm.


I didn't realize you made fixes already with simple solution and, again, the proposal of the 18 lines was just because of a mistake (couldn't find simple working solution)

Quote:
In next DD version lets use as we plan Fix 2. (new gsu deb with gsu-notimeot as default in new DD).

Ok, hopefully there aren't any issues anymore, if there are we can always go back to fix 1.

Quote:
Edit 3: Fred, alternative gsu_1.0.0_i386.deb made from gksu may need adding ldconfig in postinst script because of /usr/local/lib files. It may not work in standard Debian without ldconfig I think. Also installed on older DD version I think it will break xterm depending scripts because does not include and set by default gsu-xterm for older DD. Do you like to keep it as it is?


No, do you mind adding what is required?

Quote:
One problem with obshutdown found. Similar to yad--splash and gtkdialog-splash problem. I get sometimes /tmp/obshutdown.lock in use message as puppy user and logout menu does not work untill I do:
Code:
sudo rm -f /tmp/obshutdown*


I don't think it's permissions problem (well at least not only)
The only way I could reproduce on Jwm version:
- Click from menu on logout, obshutdown dialog displays, don't do anything with it.
- Click on JWM menu button, then for me everything freezes, only way out is Ctrl+Alt+Backspace

Then when logged back in again there's the /tmp/obshutdown.lock exist message.
If this is the same for you maybe it's best to use other way for shutdown instead of obshutdown.
On openbox version there's no problem, btw

Quote:
Edit: One more problem:
/opt/bin/portablesfs does not work from user account in both versions when executing name-portable script. Seems like /opt/lib path is not found but I'm not sure this is the only problem yet. Works fine from root account. Messages from terminal as user:


I will look at it , btw in case of abiword: libxslt.so.1 I don't see in /opt/lib or /usr/local/lib

Fred
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 3882
Location: Bulgaria

PostPosted: Sat 03 Jan 2015, 16:24    Post subject:  

Hi, Fred.
Quote:
No, do you mind adding what is required?

OK, I will make it like the other gsu deb.
Quote:
I don't think it's permissions problem (well at least not only)
The only way I could reproduce on Jwm version:
- Click from menu on logout, obshutdown dialog displays, don't do anything with it.
- Click on JWM menu button, then for me everything freezes, only way out is Ctrl+Alt+Backspace

Then when logged back in again there's the /tmp/obshutdown.lock exist message.
If this is the same for you maybe it's best to use other way for shutdown instead of obshutdown.

Yes, just tested and it does the same in Jwm version. I will find some replacement or fix for it.

Quote:
I will look at it , btw in case of abiword: libxslt.so.1 I don't see in /opt/lib or /usr/local/lib

libxslt.so.1.1.26 and libxslt.so.1 are in /opt/lib in the abiword module:
http://smokey01.com/saintless/DebianDog/Extra-modules/023-abiword-2.8.2-docx.squashfs
From user account using sfs-load same module abiword starts the program.
From user account the script from portablesfs can't find the libs in /opt/lib
From root account all works - load-sfs and starting the script made with potablesfs.
It is the same with the other 2 abiword modules and gnumeric here:
http://smokey01.com/saintless/DebianDog/Extra-modules/
All can't find the included in /opt/lib libs from user account using modulename-portable script.

Toni

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
fredx181


Joined: 11 Dec 2013
Posts: 2521
Location: holland

PostPosted: Sat 03 Jan 2015, 17:41    Post subject:  

Hi Toni,

Quote:
It is the same with the other 2 abiword modules and gnumeric here:
http://smokey01.com/saintless/DebianDog/Extra-modules/
All can't find the included in /opt/lib libs from user account using modulename-portable script.


Yes, same on OpenBox version.
It seems that it has to do with the fact that a script is not in PATH
You can test by running any script from outside PATH as user (using sudo) with this line inside:
Code:
echo librarypath=$LD_LIBRARY_PATH
librarypath=

It's empty.

Can't figure out why yet, I'll search for it tomorrow.

Fred
Back to top
View user's profile Send private message 
Keisha

Joined: 18 Nov 2014
Posts: 449

PostPosted: Sat 03 Jan 2015, 18:08    Post subject: some Puppies lack LD_LIBRARY_PATH  

fredx181 wrote:

Code:
echo librarypath=$LD_LIBRARY_PATH
librarypath=

It's empty.

Can't figure out why yet, I'll search for it tomorrow.

Fred

Some recent Puppies do not have an LD_LIBRARY_PATH. For example, these lines are in /etc/.profile in Quirky Unicorn 6.21, full install to hard disk partition:

Code:
#140204 no longer exporting LD_LIBRARY_PATH. see also /usr/local/petget/installpkg.sh, removepreview.sh
#140206 remove LD_LIBRARY_PATH completely.


Might have something to do with the fact that most libs in Quirky Unicorn are in /usr/lib/i386-linux-gnu --I suspect that whatever program does the library-loading-and-linking is nowadays hard-coded to look there first.
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 2521
Location: holland

PostPosted: Sun 04 Jan 2015, 09:32    Post subject:  

Keisha wrote:
Some recent Puppies do not have an LD_LIBRARY_PATH. For example, these lines are in /etc/.profile in Quirky Unicorn 6.21, full install to hard disk partition:


Thanks, yes, but for standard Debian it's the same, this is about custom LD_LIBRARY_PATH we have set in DebianDog (/opt/lib and /usr/local/lib)
Without using sudo it's not empty.

I found that this is default behaviour for sudo to not preserve custom library path, see here for example:
http://final-world-domination.blogspot.nl/2011/02/sudo-doesnt-export-ldlibrarypath.html

Try on DD as normal user
Code:
sudo printenv

and LD_LIBRARY_PATH does not show.
Without sudo it does show.

Fred
Back to top
View user's profile Send private message 
Keisha

Joined: 18 Nov 2014
Posts: 449

PostPosted: Sun 04 Jan 2015, 13:54    Post subject:  

Aha.

I just discovered this distro or set of distro's. Trying both the jwm-rtai and the openbox spins now, on an i5-3570k desktop.

I have never used Debian, and I have a year of thread to catch up on!
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 2521
Location: holland

PostPosted: Sun 04 Jan 2015, 15:50    Post subject:  

Hi Toni,

Quote:
It is the same with the other 2 abiword modules and gnumeric here:
http://smokey01.com/saintless/DebianDog/Extra-modules/
All can't find the included in /opt/lib libs from user account using modulename-portable script.


From what I've read from a web search there are a few solutions possible:
- From as you can read here to set an alias for sudo in ~/.bashrc:
http://final-world-domination.blogspot.nl/2011/02/sudo-doesnt-export-ldlibrarypath.html
But this will change the default sudo behaviour.
- Put an export line for LD_LIBRARY_PATH on top in portable-sfs (template) script.
This will cover only portable-sfs of course.
- Or change gsu scripts with env LD_LIBRARY_PATH added to sudo commandline.
This will change gsu "sudo" behaviour and works without having to change portable-sfs and works also for other scripts (with gsu line) depending on /opt/lib or /usr/local/lib
I'd like to know your opinion (of course Smile) but anyway here's attached gsu-notimeout_gsu-timeout_gsu-xterm.tar.gz.

Edit: I have my doubts btw about how it works to run a program created with portable-sfs as a user:
For example abiword, it runs as root, I think it should be as user, what do you think?

Edit: Sorry, Re-uploaded atachment gsu-notimeout_gsu-timeout_gsu-xterm.tar.gz
Needs quotes around $cmd as this :
Code:
echo "$pass" | sudo -S env LD_LIBRARY_PATH=/opt/lib:/usr/local/lib sh -c "$cmd"

It can take multiple arguments now.

Fred
gsu-notimeout_gsu-timeout_gsu-xterm.tar.gz
Description  re uploaded gsu scripts with added LD_LIBRARY_PATH for /opt/lib and /usr/local/lib
gz

 Download 
Filename  gsu-notimeout_gsu-timeout_gsu-xterm.tar.gz 
Filesize  812 Bytes 
Downloaded  95 Time(s) 

Last edited by fredx181 on Sun 04 Jan 2015, 19:26; edited 1 time in total
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 3882
Location: Bulgaria

PostPosted: Sun 04 Jan 2015, 17:05    Post subject:  

fredx181 wrote:
This will change gsu "sudo" behaviour and works without having to change portable-sfs and works also for other scripts (with gsu line) depending on /opt/lib or /usr/local/lib
I'd like to know your opinion (of course Smile) but anyway here's attached gsu-notimeout_gsu-timeout_gsu-xterm.tar.gz.

Thanks, Fred! I think adding env LD_LIBRARY_PATH in gsu is fine. I will rebuild the packages in the next days.
BTW take a look when you have time at gsu-gksu deb if you see something wrong with it:
http://smokey01.com/saintless/DebianDog/Packages/Testing/tmp/gsu_1.0.0_i386.deb

Quote:
Edit: I have my doubts btw about how it works to run a program created with portable-sfs as a user:
For example abiword, it runs as root, I think it should be as user, what do you think?

It is difficult to answer. It is better to run abiword and other similar programs that do not need sudo as user but what is the point to have portablesfs if it only loads the module, then the user runs manually the program and manually unloads the module. Maybe we should keep portablesfs only for root account without menu entry for user... or just leave it as it is. It is not big problem.

I'm working on removing obshutdown from jwm-porteus-boot and I think I'm almost ready. 021-apps-porteus will be removed for next version. I will need only the scripts from /usr/bin and /usr/local/bin included in the main module. When I'm ready I will update the changes post with the information we discuss now.

Toni

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
Display posts from previous:   Sort by:   
Page 275 of 283 [4236 Posts]   Goto page: Previous 1, 2, 3, ..., 273, 274, 275, 276, 277, ..., 281, 282, 283 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Derivatives
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1291s ][ Queries: 13 (0.0440s) ][ GZIP on ]