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 Wed 13 Nov 2019, 19:57
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
XenialDog (Ubuntu 16.04 'Xenial Xerus' LTS, 32-bit)
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 35 of 69 [1024 Posts]   Goto page: Previous 1, 2, 3, ..., 33, 34, 35, 36, 37, ..., 67, 68, 69 Next
Author Message
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Thu 06 Apr 2017, 05:52    Post subject: ShellCheck to improve scripts (also helps avoid bashisms)  

mcewanw wrote:
Fred,

I've sent you a modded pet2deb via PM for testing. Works with absolute or relative dotpet filenames - a bit more testing would be good, but seems fine - left most of the existing script untouched; just look for lines with mcewanw at end of them.

The mod makes pet2deb more intuitive IMO for commandline use and better for associating files with some filemanagers (fluff on tinycore, in my case, which otherwise needed a `pwd'/filename construct in making right-click file association commands, which was a bit of a pain that this mod cures).

William


I will be running through this script again, to remove bashisms (such as [[...]] construct) and to fix, for example, some double quotes I already visually noticed still missing round variables (which gives potential problems with file/dir names with spaces in them, for example).

I might also avoid yad since don't want to force that on dCore. Like gtkdialog, I prefer yad to be optional rather than core. Xdialog is available by default in most systems, I believe, and if not, then dialog, and worst case can simply give reports to defaultterminal.

As in Toni's recent re-write of pet2deb script, it would, I'm sure, indeed be good to try and avoid gsu and also include ability to work with pets compressed with xv as well as gz.

There is a very nice program/project called ShellCheck, which can be installed with apt-get or used online, which can indicate most of the required 'fixing/improving" and also the bashism-checking. I recommend we always use this (or similar, though ShellCheck is much better than old checkbashisms program, albeit much bigger). To use it to check for bashisms, just make the Shebang at top of scripts #!/bin/sh.

http://www.shellcheck.net/

EDIT: http://net-hope.blogspot.co.nz/2016/07/til-geany-and-shellcheck.html
I haven't myself used it with geany, so don't know if extra required to get it working with that (in my XenialDog32, the Build -> Build, submenu is greyed out).

EDIT2: Yeah works well with newer geany 1.27 Build -> Lint submenu (used apt to fetch geany from ubuntu repo).

Hope that is useful information, if not already known.

William

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Sun 09 Apr 2017, 08:13    Post subject:  

Hi Fred,

I'm still mulling over the pet2deb situation. I note that you store all the converted binaries in /usr/local hierarchy. But I remember in earlier DebianDog /opt hierarchy was used instead, apparently to remove possibility of such files as converted dotpets clashing with Debian files of same name? Could you clarify that and explain why you prefer /usr/local hierarchy for the converted files to /opt?

Main reason I ask is that tiny core dCore actually takes the official Debian binaries and transfers them to /usr/local hierarchy - then I see a real danger of clashes if dotpets converted to debs were also put into that same area. So for pet2deb use in dCore it seems to me that /opt will be better, though I'm not sure of the DebianDog situation in terms of clashes or not.

Cheers, William

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
fredx181


Joined: 11 Dec 2013
Posts: 4157
Location: holland

PostPosted: Sun 09 Apr 2017, 11:55    Post subject:  

William wrote:
I'm still mulling over the pet2deb situation. I note that you store all the converted binaries in /usr/local hierarchy. But I remember in earlier DebianDog /opt hierarchy was used instead, apparently to remove possibility of such files as converted dotpets clashing with Debian files of same name? Could you clarify that and explain why you prefer /usr/local hierarchy for the converted files to /opt?


Well, not really a big reason, I changed to /usr/local/bin (and removed /opt/bin from PATH) just to stay as close as possible to "official" (/usr/local/bin is already in PATH by default)
So that PATH change resulted in needing to modify pet2deb also.
EDIT: Also a reason was to have most custom scripts (not-official-Debian) in one place: /usr/local/bin rather than in two places

You can change the PATH of course on Dcore (and pet2deb accordingly) but that would mean that you need to modify standard system config files e.g. /etc/profile.


Not sure to understand what you mean by "clashing". Replacing files accidentally in /usr/local/bin ?
If a script with the same name would be in /opt/bin and suppose /opt/bin is the first in PATH it would "clash" also IMO.

Fred

_________________
Dog Linux website
Tinylinux blog by wiak
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Mon 10 Apr 2017, 18:28    Post subject: opt hierarchy and setting PATH more generally  

fredx181 wrote:
William wrote:
I'm still mulling over the pet2deb situation. I note that you store all the converted binaries in /usr/local hierarchy. But I remember in earlier DebianDog /opt hierarchy was used instead, apparently to remove possibility of such files as converted dotpets clashing with Debian files of same name? Could you clarify that and explain why you prefer /usr/local hierarchy for the converted files to /opt?


Well, not really a big reason, I changed to /usr/local/bin (and removed /opt/bin from PATH) just to stay as close as possible to "official" (/usr/local/bin is already in PATH by default)
So that PATH change resulted in needing to modify pet2deb also.
EDIT: Also a reason was to have most custom scripts (not-official-Debian) in one place: /usr/local/bin rather than in two places

You can change the PATH of course on Dcore (and pet2deb accordingly) but that would mean that you need to modify standard system config files e.g. /etc/profile.


Not sure to understand what you mean by "clashing". Replacing files accidentally in /usr/local/bin ?
If a script with the same name would be in /opt/bin and suppose /opt/bin is the first in PATH it would "clash" also IMO.

Fred


Hi Fred,

You have put XenialDog together, so it is up to you, but personally I think the PATH issue needs to be revisited so this is a long answer.

Short answer, I think pet2deb would be best using /opt and that should be added to end of PATH (for lowest priority) and with /opt/local coming first in that opt-related list. Of course a relatively minor mod to pet2deb could have the directory (/usr/local or /opt) as a variable near the top for installer to modify if wanted.
---------------------------

The problem with a utility like pet2deb is that we do not know beforehand if the dotpet is self-contained (i.e. having libraries included, and not being standardised different dotpets could include different compiles of same libraries). Basically a dotpet is a tar.gz file, so on the whole would normally be installed into /opt (despite us repackaging it in a 'non-official' deb).

Certainly, official debs will store into the main hierarchy of /, /usr, /usr/lib, /usr/bin, /usr/sbin, /lib, /bin, /sbin etc., so should be okay in terms of not overwriting apps in /local, /usr/local etc hierarchy. But since these are in the PATH and /local, /usr/local hierarchy may well have higher priority (more local, nearer to the user, the more likely to be given higher priority by system designer - same with config files). /opt on the other hand is usually not in PATH by default and, according to my researches, usually added with least priority using:

Code:
PATH=$PATH:~/opt/bin


i.e. at the end of PATH.

Actually, If using opt, I would add /opt hierarch (most local parts first. e.g. /opt/local/sbin:/opt/local/bin:/opt/sbin:/opt/bin) to the end of that.

Best community agreed answer I could find was here:

http://askubuntu.com/questions/34880/use-of-opt-and-usr-local-directories-in-the-context-of-a-pc

Quote:
/opt is for third-party applications that don't rely on any dependencies outside the scope of said package. /usr/local is for packages installed on this machine outside the scope of the distribution package manager.

An example:

An open source sip-client supplied as a .deb would install into /usr. If it was built with the Qt framework, apt would pull it in as a dependency.

The same open source sip-client built from source would reside in /usr/localso it would not be messed up by apt if you later installed a .deb package for the same application. You could either build its dependencies from source, or get them from the package manager.

A third-party application in /opt is supposed to be self-contained. For instance, a proprietary sip-client using Qt would not rely on the version from apt, but would have it bundled or statically linked in.

For more information, take a look at the Filesystem Hierarchy Standard

--------------------------


Also, the PATH for 'all users' is 'normally' put in /etc/environment but that is read by PAM system (pam_env.so), which I don't think DebianDog uses? (I'm in tinycore at the moment). Tiny Core does set PATH in /etc/profile. However, I think, if no PAM available, it would be nicer to do it from /etc/profile the way I saw on superuser.com by contributor Daniel Beck, which still reads it from /etc/environment:

https://superuser.com/questions/339617/how-to-reload-etc-environment-without-rebooting

Code:
For the current shell session, you can use for line in $( cat /etc/environment ) ; do export $line ; done, if the file format is key=value. – Daniel Beck♦ Sep 25 '11 at 11:38


Should also take sudo into account though as described here:
http://askubuntu.com/questions/128413/setting-the-path-so-it-applies-to-all-users-including-root-sudo

Since sudo by itself is generally configured to give a limited higher-security PATH, you sometimes need to use sudo su - to get root user's PATH with it.


In tiny core dCore, most main (official debian-sourced) apps are stored in /, /bin, /usr/bin etc hierarchy and cat /etc/environment contains:

In tiny core (dCore) it ends up having the following in /etc/profile for Bourne-type shells:

Code:
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games


and then in ~/.profile tiny core (dCore) has:

Code:
# ~/.profile: Executed by Bourne-compatible login SHells.
#
# Path to personal scripts and executables (~/.local/bin).
[ -d "$HOME/.local/bin" ] || mkdir -p "$HOME/.local/bin"
export PATH=$HOME/.local/bin:$PATH



It is common to set the user's own bin directory with highest priority by means of their default-provided ~/.profile as follows (e.g. from Linux Mint .profile), which will not be read at all if .bash_profile is created:

Code:
if [ -d "$HOME/bin" ] ; then
  PATH="$HOME/bin:$PATH"
fi


Cheers, William

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Tue 11 Apr 2017, 02:51    Post subject:  

Fred,

Note that in your pet2deb:

Code:
ifpet=`echo "${FILE##*.}"`


can be more simply written as:

Code:
ifpet="${FILE##*.}"


Actually, I'm too busy re-writing pet2deb for my own tinycore dCore needs to test the above...

William

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
fredx181


Joined: 11 Dec 2013
Posts: 4157
Location: holland

PostPosted: Tue 11 Apr 2017, 05:17    Post subject:  

Hi William,

Quote:
Short answer, I think pet2deb would be best using /opt and that should be added to end of PATH (for lowest priority) and with /opt/local coming first in that opt-related list. Of course a relatively minor mod to pet2deb could have the directory (/usr/local or /opt) as a variable near the top for installer to modify if wanted.


Apart from pet2deb, you mean also it's better to change the PATH system-wide and that the custom packages (non-Debian) like: pburn, weX, apt2sfs etc... are all installed to /opt, right?

If so, what's the advantage then, or can you give example of what can go wrong in the situation how the PATH is setup now?

The pet2deb scripts (which are Toni's, btw) can be useful, but to be honest I only used a couple of times.
Probably half of the times it doesn't work out of the box, e.g. more dependencies need to be set (in DEBIAN/control file) or doesn't match with the GLIB version.
So I see it as a handy way to try a .pet, and , as it's converted to .deb, to be able to uninstall it.
There's a risk of using pet2deb-converted packages, I'm mostly concerned about conflicting libraries (in /usr/local/lib) with already existing in /lib or /usr/lib , I wouldn't recommend it for average users (and it may even be best not to use at all, so not include anymore in next releases, because AFAIK most pets are not self-contained btw (see below).

Quote:
/opt is for third-party applications that don't rely on any dependencies outside the scope of said package. /usr/local is for packages installed on this machine outside the scope of the distribution package manager.


A good example of 'self-contained' is google-chrome, it installs in /opt/google and the executable script google-chrome sets its own PATH in the script to $HERE:$PATH (HERE variable is same directory) (also for setting LD_LIBRARY_PATH)
Another example is the 'Trinity-Desktop', (installed in /opt/trinity) I nocided that /opt/trinity/bin is in PATH when logged in in Trinity, but when logged in openbox-session or JWM the PATH is normal again (as set in /etc/profile). That's what's self-contained IMO

As I said, I'd like to keep the system configs as they are in the (Debian/Ubuntu) original , e.g. /etc/profile, unless there's a good reason to change it drastically (btw, you realize?, almost all packages from custom repo need to be repacked in case switching to /opt (and also some modified, e.g. postinst, postrm scripts in DEBIAN dir)

PS: I see now that in XenialDog /opt/bin is still in PATH, but /opt/lib is not in library path anymore (in older DD versions it is)

EDIT:
Fred wrote:
Apart from pet2deb, you mean also it's better to change the PATH system-wide and that the custom packages (non-Debian) like: pburn, weX, apt2sfs etc... are all installed to /opt, right?

Sorry, reading your post again, I think you just mean to add /opt hierarchy to PATH and modify pet2deb to using /opt
Then what about library-path, add e.g. /opt/lib or keep /usr/local/lib ?

Fred

_________________
Dog Linux website
Tinylinux blog by wiak
Back to top
View user's profile Send private message 
mikeslr


Joined: 16 Jun 2008
Posts: 3470
Location: 500 seconds from Sol

PostPosted: Tue 11 Apr 2017, 09:02    Post subject: Two other uses of pet2deb: Linking to AppImages
Subject description: and Program Folders
 

Hi guys,

While you're working on pet2deb, I just wanted to mention another possible use. You'll probably recall that I multi-boot various Puppies and debiandogs, especially while exploring new ones, and that when I can I use "program folders". These are fully self-contained applications extracted to a folder on /mnt/home and, thus, are outside of the operating system proper. That situation is analogous to installing the application to /opt, with the added advantages of keeping a SaveFile, under Puppies, or the /live or /casper folder under "Dogs" small, and using the same instance of an application under several operating systems.

To facilitate their employment in Puppies, I create pets which consist of a bash script "on the path" which calls the application's executable, an icon and a desktop file to create a menu entry. None of those files is likely to conflict with any file installed by a debiandog's creator, or subsequently installed using apt or synaptic. The worst case scenarios under debiandogs are that the application won't run unless some libraries are installed via apt (and perhaps symlinks to deal with version differences); or won't ever run, in which case, I'd want a simple way to remove the 3 files.

Essentially, and perhaps of more general value, the same technique can be used to employ AppImages, https://bintray.com/probono/AppImages now finding their way into Puppies. http://murga-linux.com/puppy/viewtopic.php?p=949732#949732. AppImages are intended to run under any Linux OS ['though "any" at this stage of development is still more a goal than a reality]. The ability to use them under DebianDogs would alleviate the difficulty of having to compile applications not then available via apt-get from repos. And if AppImages become more commonplace, the inability of DebianDogs to make use of them would detract from the general utility of DebianDogs as an operating system.

Puppies don't really care where on the path the script is located, and the icon can be placed anywhere icons are usually found. So, in the future, I can modify such pets to comply with whatever arrangement debiandogs require. But, it would be useful to me if there was a simple application for converting such pets to debs.

mikesLr
Back to top
View user's profile Send private message 
backi

Joined: 27 Feb 2011
Posts: 1817
Location: GERMANY

PostPosted: Tue 11 Apr 2017, 12:02    Post subject:  

Hi mikeslr !

Quote:
You'll probably recall that I multi-boot various Puppies and debiandogs, especially while exploring new ones, and that when I can I use "program folders". These are fully self-contained applications extracted to a folder on /mnt/home and, thus, are outside of the operating system proper. That situation is analogous to installing the application to /opt, with the added advantages of keeping a SaveFile, under Puppies, or the /live or /casper folder under "Dogs" small, and using the same instance of an application under several operating systems.


This is what i prefer to do when possible .........keep Programms outside the Save-File/Folder ...for Example ....Palemoon.....Smplayer......or using sfs/squashfs Applications .No conflicts with other Programms .....
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 4157
Location: holland

PostPosted: Tue 11 Apr 2017, 15:51    Post subject:  

Hi Mike, backi,

Already a while back I have put together an app for creating portable image : 'create-portable' 32-bit only.
Some of the code I took from "AppImageAssistant" by Simon Peter (probono), known from http://portablelinuxapps.org
Didn't share yet because I didn't take the time yet to test on different puppies (works ok for me on 32-bit DebianDog and XenialDog) (maybe I'll open new thread later in Additional Software after more testing)
So since you mentioned about portable-apps you may be interested in this.

Assumed is that you have prepared already the "app-root" directory, this can be an directory from extracted SFS, .deb or .pet file or just manually put together directory structure with inside e.g. usr/bin usr/share etc... Extracted SFS probably has the best chance to make the portable app work properly (e.g. created with apt2sfs).
The application will create 'AppRun' script in this "app-root" directory and create the portable-image.
There are 2 modes to choose from: "Chroot Mode" and "Portablelinuxapps Mode"
The Chroot Mode is the best IMO because it doesn't depend on relative paths (works pretty much the same as loading an SFS, (overlay)), but may be a bit slower (starting the app) because of more complex code.
Also there's choice (checkbox) for to create self-extracting-script instead portable-image
For more info, click on Info button.

https://dl.dropboxusercontent.com/s/wzixvammcygk8b0/create-portable.tar.gz

Extract create-portable.tar.gz and run 'create-portable'

EDIT: Here it is also for 64-bit, appimage: "create-portable64" :
https://dl.dropboxusercontent.com/s/xxz9na3qh8optnr/create-portable64.tar.gz

EDIT2: 2017-04-14 New versions uploaded of create-portable (32-bit) and create-portable64 (64-bit): Changed:
- added (GUI) info about which libraries are missing in case the program won't run.
Just download again from same url links above for the new versions.

EDIT3: 2017-04-15 Again new versions uploaded of create-portable (32-bit) and create-portable64 (64-bit):
Small change:
- Replace AppRun script (overwrite) when running 'create-portable' again on same folder (<appdir-root>) earlier used (but don't use"Skip" button) , could be useful e.g. when running again using other "Mode" as chosen earlier (or when the program had been changed, e.g. fix, adding info about which libraries are missing (to AppRun), then the AppRun script needs updated/overwritten) .

Fred
create-portable.jpg
 Description   create portable application from directory: <appdir-root>
 Filesize   115.36 KB
 Viewed   635 Time(s)

create-portable.jpg


_________________
Dog Linux website
Tinylinux blog by wiak

Last edited by fredx181 on Sat 15 Apr 2017, 14:44; edited 6 times in total
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Tue 11 Apr 2017, 17:57    Post subject:  

fredx181 wrote:
I think you just mean to add /opt hierarchy to PATH and modify pet2deb to using /opt
Then what about library-path, add e.g. /opt/lib or keep /usr/local/lib ?

Fred


Yes, for my needs in tinycore I will add /opt hierarchy to the end of the PATH and modify pet2deb to use /opt. For most apps I realise it doesn't really matter if run from /usr/local/bin, /usr/bin or from /opt hierarchy. Problem with weX, for example, would might only occur if some official app became available in Debian repositories called 'weX'. Also, if a utility is specially made or tested for a particular distribution then /usr/local/bin is the customary place for the system builder to put it. That's exactly what is done in dCore - tiny core development team apps are put into /usr/local hierarchy and official Debian/Ubuntu apps go into /usr hierarchy.

I do myself feel that 'other' apps/utilities are best put elsewhere in the filesystem hierarchy, if only (mainly) to not pollute main system bins. I don't want to mess with tinycore /usr/local/bin area by putting alien dotpet apps in there if I can avoid it, though it isn't probably a serious issue if I did (unless there was an application name-clash in the PATH somewhere - but that would be rare).

Library issues are certainly much more of a worry, which is main reason why I feel external/alien/dotpet type apps should be put in /opt so if they do contain any libs at least they will not pollute the main /lib, /usr/lib etc areas. By default LD_LIBRARY_PATH is unlikely to be set since lib search is better left dynamic (along with /etc/ld.so.conf related includes). Most of the time library search path will be determined by the app binary as far as I know (via the -rpath set in compiling) - most all official apps will not be searching /opt (unless self-contained app, such as Chrome, has been configured that way rather than via LD_LIBRARY_PATH).

(EDIT: I'm not sure what happens if the ld.so.conf related search path includes libs of the same name in terms of if and how one gets prioritised over the other - I suppose I should read up on that...
EDIT2: Tons of info out there about overall lib search path priority (rpath, then LD_LIBRARY_PATH etc) but couldn't find much official about priority concerning ld.so.conf itself but here is one claim:
https://www.monperrus.net/martin/notes-on-shared-libraries-with-ld
Quote:
The priority order is: 1) /etc/ld.so.conf 2) files in /etc/ld.so.conf.d/* by alphabetical order, 3) pre-configured directories.

).

As I said, PAM would usually be used to set the system-wide PATH via /etc/environment string. But otherwise it has to be done somewhere else. I agree that official config files are better left in pristine/unmodified condition (though seems /opt/bin was added in /etc/profile?). However, any scripts placed in /etc/profile.d are read by /etc/profile, so /etc/profile itself doesn't need to be changed anyway.

But no big deal and I did say that I wasn't suggesting you change how you want to do things - it is your work so I don't see it as a community project in that community-decides sense. I am writing my own pet2deb mce version, so thought it was polite to discuss the changes I envision. I want it because I find the facility handy for dCore though I also only use it for special quick deb-making and for small utilities I understand the contents of.

My testing version works with yad or alternatives (such as Xdialog or dialog) depending what's on the system - not saying anyone else should or better use my version! It will never be an official dCore provided app, so don't have that decision to make anyway.

Sorry, I didn't realise it was Toni's app. I am surprised he would use /usr/local hierarchy since from the very outset he was determined 'alien' apps would be in opt area (I remember preparing my modded xhippo for that location).

William

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
fredx181


Joined: 11 Dec 2013
Posts: 4157
Location: holland

PostPosted: Wed 12 Apr 2017, 13:10    Post subject:  

William wrote:
Sorry, I didn't realise it was Toni's app. I am surprised he would use /usr/local hierarchy since from the very outset he was determined 'alien' apps would be in opt area (I remember preparing my modded xhippo for that location).


Well, again I learned that it's important to add comments to what I changed in scripts from somebody else, to avoid confusion. Embarassed
Originally (by Toni) it had /opt/bin and /opt/lib (in earlier DebianDogs) but I modified later to /usr/local...

For info, setting LD_LIBRARY_PATH=..... in /etc/environment works well in XenialDog

Fred

_________________
Dog Linux website
Tinylinux blog by wiak
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 4157
Location: holland

PostPosted: Wed 12 Apr 2017, 13:12    Post subject:  

Made also 64-bit version of 'create-portable' see EDIT here:
http://www.murga-linux.com/puppy/viewtopic.php?p=950975#950975

Fred

_________________
Dog Linux website
Tinylinux blog by wiak
Back to top
View user's profile Send private message 
Pelo

Joined: 10 Sep 2011
Posts: 12591
Location: Mer méditerrannée (1 kms°)

PostPosted: Wed 12 Apr 2017, 13:56    Post subject: to clarify things, about outdoor , laptops and XenialDog  

People want to give an opinion, here joined Shocked
wlan.jpg
 Description   Model
 Filesize   36.82 KB
 Viewed   369 Time(s)

wlan.jpg

People.tar.gz
Description  Speach with espeak
gz

 Download 
Filename  People.tar.gz 
Filesize  203.03 KB 
Downloaded  89 Time(s) 
CSL300Mb.jpg
 Description   I bought it, i Need an OS fot it, Puppy slaxen 6.3.2 recognize it and makes it work
 Filesize   9.89 KB
 Viewed   383 Time(s)

CSL300Mb.jpg


_________________
Passenger Pelo ! don't ask him to repair the aircraft. Don't use him as a demining dog .... pleeease.

Last edited by Pelo on Thu 13 Apr 2017, 07:08; edited 4 times in total
Back to top
View user's profile Send private message Yahoo Messenger 
backi

Joined: 27 Feb 2011
Posts: 1817
Location: GERMANY

PostPosted: Wed 12 Apr 2017, 15:23    Post subject:  

Hi fred !

Will going to test your "create-portable" script .

I am also using your - SFS-Portable Tool ( in Menu > Applications> Module Tools ) a lot .
Quite handy !

https://dl.dropboxusercontent.com/s/wzixvammcygk8b0/create-portable.tar.gz

Extract create-portable.tar.gz and run 'create-portable'

Here it is also for 64-bit, appimage: "create-portable64" :
https://dl.dropboxusercontent.com/s/xxz9na3qh8optnr/create-portable64.tar.gz


Cheers !
Back to top
View user's profile Send private message 
backi

Joined: 27 Feb 2011
Posts: 1817
Location: GERMANY

PostPosted: Thu 13 Apr 2017, 09:58    Post subject:  

Hi fred and all the Rest !

Just fiddled a bit with this " create-portable " ...what shall i say.....cooooooollll... Idea Laughing Very Happy Very Happy

Looks really, really promising !!!! Very Happy Idea

More later .....Cheers !
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 35 of 69 [1024 Posts]   Goto page: Previous 1, 2, 3, ..., 33, 34, 35, 36, 37, ..., 67, 68, 69 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
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.1617s ][ Queries: 12 (0.0496s) ][ GZIP on ]