PaDS 1.1.4 - updated version of 1.0.4

Miscellaneous tools
Message
Author
ITSMERSH

#31 Post by ITSMERSH »

musher0 wrote:Plus when one transforms libraries form deb archives, the /usr/lib/package/*.pc file is missing.
Checked multiple different Puppies and its devx files.

None of them included a directory /usr/lib/package.

However, directories like /usr aren't touched in any manner, so everything from a .deb file should appear inside the new created .sfs. I don't think there are extraction tools used, that will exclude stuff in /usr on extraction like it is done with /DEBIAN/control.

The /usr/bin/undeb definitely doesn't.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#32 Post by musher0 »

Hi *RSH.

That is when one wishes to compile an app that needs a library, and that
library needs to be identified with such a *.pc file during the compilation
process.

Probably it is not needed in your context of building an sfs with already
compiled applications. It would be nice to have, though, since it would
perhaps, eventually, save some developer "a trip" to pkgs.org just to get
this little file! ;)
(These *.pc files are like index cards for libraries. They have no function
in themselves, they are not executable. They only describe the library a
little bit, what it does and what other library it may need. Some have just
a couple of lines. Some are longer.

Their only value is to be there, in the /usr/lib/package directory, when the
compilation process for an executable looks for them.

The funny thing is, I should say: "the frustrating thing is", the compiler is
lazy. The library can very well be in the Puppy, but if this little index card
is not there, the compiler says: "no-no, that library is not there" -- when it
may actually be there. The compiler does not look for the lib, it looks for
this "index card".

Now these "index cards" need to be in a special format. One cannot just
write anything in a text file and put the required file name on it.)
BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

ITSMERSH

#33 Post by ITSMERSH »

Ok, I see. Thanks.

In the end -at least to me- that means this stuff should go into the devx or any devx-extension .sfs, since the devx is needed for compiling.

PaDS is not intended to create devx .sfs modules or even .sfs modules needed for compiling or related to compiling.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#34 Post by musher0 »

ITSMERSH wrote:Ok, I see. Thanks.

In the end -at least to me- that means this stuff should go into the devx or any devx-extension .sfs, since the devx is needed for compiling.
(...)
That is a brilliant idea !!! It would save Puppy developers a lot of grief.
I hope one of the Superior Powers at Woof-CE is listening !!! :)

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

Combining 64-bit SFS?

#35 Post by davids45 »

G'tag RSH,

I'm slowly setting up some 64-bit Frugal Pups and want to use a combined 64-bit sfs to boot-load my applications, profiles, etc. so each new 64-bit Pup uses the same single sfs.

In 32-bit, I have the SFS-Combiner from MU but this excellent but old combiner doesn't run in 64-bit Pups. So I've been looking around for a new combiner.

PaDS-1.1.3 reads to me that it can merge SFS so I'm hoping to replace the old combiner with your package that will run in both 32 and 64 bit.

In a 32-bit Pup (on sda1), PaDS stalled when I tried to select files to add/use in my data directory on my sdb3 data partition (where I archive my 64-bit sfs - my 64-bit Pups are all on sdb6).
I could select a directory on sdb3 to use to put the new sfs but could not get past the sdb3 root to reach the directory with the sfs to merge - these were greyed out (screenshot).

I did a quick test in a 64-bit Pup and PaDS113 complained of a missing file or something but going past that, still gave a greyed out add-file option.

Am I wrong in trying to use PaDS to combine sfs files?
If so, can you suggest a package that will do this in both 32-bit and 64-bit Pups?
If not, am I doing something wrong in trying to select-to-add files in a different partition?

Thanks for any help or ideas.

David S.
Attachments
PaDS113-starting.jpg
PaDS113 starts OK in a 32-bit Pup and can choose sdb3 to store the newly merged file
(83.03 KiB) Downloaded 278 times
PaDS113-stalled.jpg
trying to add files in a sub-directory on sdb3 but it is greyed?
(64.39 KiB) Downloaded 275 times

ITSMERSH

#36 Post by ITSMERSH »

Hi David.

What's the 32bit / 64bit Puppies you've been using on that?

Edit:

What's the versions of gtkdialog in these Puppies?
Last edited by ITSMERSH on Wed 01 Aug 2018, 19:53, edited 1 time in total.

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

#37 Post by mikeslr »

Hi davids45,

Being able to use SFSes as sources for creating a combined SFS was the first addition ITSMERSH made to the previously published PaDS. I was certain that while testing I was able to choose a working directory on a partition OTHER THAN the partition on which the Puppy running PaDS was located, But I double-checked.

Although the screenshot doesn't show it, I'm running PaDS under Xenialpup64 which is on sda4. Before running PaDS, xdotool was installed, and sdb1 was mounted. To reach the Temp1 folder on sdb1, I clicked the folder icon below the Title "Choose working directory..." then starting on the Left-most pane selected Filesystem> then from the middle pane successively mnt>sdb1>Temp1.

None of the folders on sdb1 had been greyed out. Assuming you followed steps like the above, something else must be interfering with PaDS' ability. A permission problem?

mikesLr
Attachments
SelectionUnderPaDS.png
Selecting a Working Directory
(114.6 KiB) Downloaded 252 times

ITSMERSH

#38 Post by ITSMERSH »

Suddenly I can recall entering that issue described by davids45 exactly one time while developing the new version of PaDS. Though, it was gone after I added '*.*' being the default filter for files.

There's a good chance just changing that filter to 'All Files' will enable the directories and files to be entered/selected.

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

Merging sfs in 64-bit Pups

#39 Post by davids45 »

G'day mikeslr and G'tag RSH,

Thanks for your replies :) .

Mike,
If I've quickly read your post correctly, it was the next step where I went 'grey' - I could pick the working directory but not then select sfs files to add to do the merge.

RSH,
I'll see if I can find the filter that you noted may need an edit.
Unfortunately, it will probably be a 'boy look' so I fear I'll miss it for being too easy to see, like pairs of socks in my sock drawer :oops: .

I'll report back on the Pups I try in response to your earlier reply-post to help sort out my problem if needed.

David S.

ITSMERSH

#40 Post by ITSMERSH »

File /usr/local/pd2sfsgui/petsNdebs2sfsgui, Line 326.
I could pick the working directory but not then select sfs files to add to do the merge.
I think there's something wrong.

The working directory is different to the directory from where to add files (.deb, .sfs etc.).

If you want to select files to be added into the new .sfs you just choose a directory and exit the file selector by Ok. All files from this directory will be present then in the left frame of files.

From that frame you will select the files that should go to the right frame of files (or mid frame as mikeslr called it) by clicking the Add button after all files are selected/chosen.

Hope that helps somehow (my bad English, sorry)
Last edited by ITSMERSH on Thu 02 Aug 2018, 01:28, edited 2 times in total.

ITSMERSH

#41 Post by ITSMERSH »

There's a good chance just changing that filter to 'All Files' will enable the directories and files to be entered/selected.
This was meant to NOT to change it to 'All Files' within the code, but to change it in the file selector. Sorry, if there was any misunderstanding.

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

#42 Post by davids45 »

G'tag RSH,

Thank you for the instant replies :shock: .

Here is my line 326 in the script you noted:
<action>my_RSH_gtk_fileselect_workaround "Load" "$(cat /tmp/my_return_file_containing_the_results.txt)" "*.*|*.deb|*.pet|*.tar.gz|*.sfs|*.txz|*.tazpkg" "directory" "/tmp/my_return_file_containing_the_results.txt"</action>
With the PaDS pet I'd downloaded, I tried again in a Stretch7.5-k3.16.45 (same result as yesterday) and now in a Bionicpup-18.05-k4.9.96 (both frugal Pups on sda1).
In Bionic just now, I was prompted to install the tools debs on first running PaDS and did this (2 .debs installed).

I ran PaDS (second screenshot), but again, in the 'Add files...' step, I could not select a sub-directory in sdb3 - I tried to double-click on the Puppy_Archive sub-directory of sdb3 (first screenshot) but nothing happened.

The sfs files I want to merge into one sfs are several more sub-directories down in my Puppy_Archive on sdb3.

I could try again by moving these sfs to a /root location in a Pup to see if that is a work-around?
The sfs are all quite small as they are all made of symlinks so I can run these programs in new Pups on my frugal partitions while having the full-sized programs on my large data partitions.
This is working well with my many 32-bit Pups but I lack a sfs-combiner in the 64-bit Pups. I can combine the 64-bit sfs with the 32-bit combiner in a 32-bit Pup then drop the resulting sfs into the 64-bit Pup partition's root but I was hoping to find a tidier method using just the 64-bit Pups for the merging/combining.

Thanks again for your help and patience.

And your English is much better than my hochschule Deutsch (one year, about 50 years ago!).

David S.
Attachments
select-subdirectory-in-sdb3-fail.jpg
clicking on PuppyArchive sub-directory doesn't open this sub-directory
(80.35 KiB) Downloaded 193 times
pads113-bionic-start.jpg
starting PaDS in a BionicPup
(127.38 KiB) Downloaded 191 times

ITSMERSH

#43 Post by ITSMERSH »

Ok,

for my N.E.M.E.S.I.S. developments I have permanently installed Bionic Pup 18.05. So I booted into that Puppy, installed PaDS 1.1.3 and could reproduce the issue.

Seems to be caused by newer version of gtkdialog, as it works well in Puppies pre Bionic Pup (Tahr, Xenial).

Now there's two ways to solve this for some period until I will be able to upload a updated version.

1. When choosing the directory to select .sfs (or any other) files, just click the butten on the lower right corner and select 'All Files'. Change the location in that file selector once (to /root/ for example) and then back to the file system.

All directories shold now allow to be entered.

2. Change the code in file /usr/local/pd2sfsgui/petsNdebs2sfsgui at line 326 from:

Code: Select all

"*.*|*.deb|*.pet|*.tar.gz|*.sfs|*.txz|*.tazpkg"
to:

Code: Select all

""
Yes, only keeping the double-quotes with no spaces within !!! :!:
Attachments
Screenshot.jpg
(94.9 KiB) Downloaded 181 times

ITSMERSH

#44 Post by ITSMERSH »

Any results?

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

A few quick tests yesterday

#45 Post by davids45 »

G'tag RSH,

I've tried PaDS in a few 32-bit and 64-bit Pups with little success. Firstly as a pet (+.debs), but then I tried to make an sfs of Pads and the two extra deb packages so I could easily unload it from a Pup if PaDS did not run as hoped. I have a PaDS sfs with the 32-bit debs and another with the 64bit/amd debs.

Test results
No slacko-based pup (2) got past selecting the working directory; the Pup freezes with a gtk panel appearing on the task bar. The extra files needed for the gui being .deb files may have been part of this failing?

A Stretch Pup also stopped at the selecting the 'Load' directory that has the sfs to merge = the original problem I had.

A Bionic 32-bit and 64-bit Pup did not work, freezing the Pup or stopping at the 'Load'.

But I found a Xenial Pup (xenial75-k4.4.95) was good and I made a combined sfs as I had hoped :D :D .
I haven't tried my all-in-one PaDS sfs in this Pup to check my sfs is OK - I'll delete the pet files and re-do this test with the sfs.

Other thoughts
I was wondering if Muppy-Filer (which I install (sfs) in every 32-bit Pup as it is such a useful little program) is conflicting in someway with PaDS?
I manually deleted PaDS in one Pup (via the .packages files list), including deleting a couple of 2012-dated lib files (which seemed a bit old?) and later found Muppy-Filer had stopped running.
So I thought of a possible conflict if these lib files were part of Muppy-Filer as well as PaDS?

Is there a quick way to find the gtk version in a Pup - you did say this could be important?

I apologise that my testing has been very brief and a bit random so far, but with your extra feedback (your last post suggestions), I will try to be a bit organised from now on :oops: .

I will concentrate on my 64-bit Pups as these do not have a sfs-combiner as far as I know and do not have Muppy-Filer.

Thanks again.

David S.

ITSMERSH

#46 Post by ITSMERSH »

PaDS doesn't come with any libs to install. So, there's nothing that could cause conflicts between PaDS and the Muppy Filer.

Could you make some testings (using those Puppies where PaDS failed) after applied/used the changes/instructions I suggested in my last post?

I need to have the results, to make sure, what to change in next version of PaDS.

What's the two extra deb packages you are talking about?
but then I tried to make an sfs of Pads
Should work from .sfs loaded as far as I can see (if it works in general)...

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

libs for xdotool

#47 Post by davids45 »

G'day RSH,

I'm a little bit further with my problems/tests.

Only trying 64-bit Pups since my last post.

For easy testing in a range of my Pups, I made a sfs of PaDS-1.1.3 and then one using links to PaDS files on my data partition. Loading and unloading an sfs is far better than removing pets for me. And when PaDS is ready, I will be using it as a sfs shared around my Pups.

During making these sfs, I had problems with the different library directories in different Pups - lib, lib32, lib64 and odder ones with i386 or gnu or other confusing-to-me words in their names. Much simpler with 32-bit Pups with everything in /usr/lib. This confusion of lib directories for 64-bit Pups was why I gave up with these 64-bit Pups in past explorations in the 64-bit world.

When PaDS did not work....
The problems seemed to be in the xdotool part?
The GUI was fine to start and then to pick a working directory, but then stopped with the 'Load' and a gtk 'message' on the task bar (but no dialog box).
After failures with Slacko Pups and the sfs made with the 64-bit .deb versions of the xdotool files (2 needed according to the repository), I made another PaDS sfs using the Slacko repository of xdotool (only one file needed). And the lib directories were simpler (just lib and lib64) in Slacko.

PaDS successes.....
My PaDS-slacko sfs is working with some of my Slacko64 Pups (including a LxPupSc64), sometimes I need to do the 'All files' selection during the 'Load' stage if it looks like a frozen 'Load' window.
So your 'All files' recommendation has been useful.

I haven't tried my slacko-PaDS sfs in a non-slacko Pup yet.

My original .deb PaDS links-sfs has now worked in two Xenial64 Pups with the 'All files' step. And I had a success with a Slacko64-630 Pup but not with the newer ones on my 64-bit frugals partition.

Next I will make your suggested edit:
2. Change the code in file /usr/local/pd2sfsgui/petsNdebs2sfsgui at line 326 from:
Code:
"*.*|*.deb|*.pet|*.tar.gz|*.sfs|*.txz|*.tazpkg"

to:
Code:
""
and see how this goes in both my PaDS-sfs and various Pup breeds.

My problems with libraries in the sfs may be just my problem in navigating the 64-bit differences when creating my sfs.
So there may be no difference because of where the xdotool library file comes from - just where I put it?

I agree that the older 64-bit Pups are better with PaDS at present, and hope you have a gtk magic wand to bring newer Pups into line.

I think I can see 'light at the end of my tunnel' of PaDS difficulties - after all, I have now made combined 64-bit sfses from my many individual application sfs for my Slacko and Xenial 64-bit Pups.

So thanks for your continued tolerance and good advice.

David S.

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

update of tests as sfs-combiner

#48 Post by davids45 »

G'day RSH,

I've been using PaDS with the edit to line 326 you suggested and I have not had any problem of freezing or making selections in any 64-bit Pup I have run PaDS in, using it as my 'home-made' links-sfs from your .pet and the 64-bit xdotool lib.

One small comment.
In a made-today 64-bit LxPupSc64-18.06+3, I ran the PaDS sfs to merge all my applications sfses into a single all-applications-sfs to load into each Xenial64 Pup. I'd already made a slacko all-apps-links-sfs with MU's 32-bit SFS-Combiner in an old 32-bit Pup for the LxPupSc64s.

First screenshot shows the PaDS window - no problem choosing a working directory nor a 'Load' directory (next screenshot shows these directories to be merged).

PaDS then made the wanted Xenial-all-sfs sfs plus its md5 check-file in the working directory.

I had made the working directory the directory where I store my all-links.sfses for each Puppy type. So I needed to delete the now unwanted copies of the single app sfses that were copied here during the marge process (third screenshot).

I wonder if a third dialog box (optional?) could be "easily" included in PaDS to tell PaDS where to put the merged sfs rather than in the working directory. Saves me copying it from the working directory to where I store it, or having to delete the working file copies when I made the working directory my sfs-storing directory.
If not "easily" done, or would be too complicated for the user, that's OK. I just need to get used to how to use PaDS the way it is.

Thanks once again for this useful package as my SFS-Combiner replacement in 64-bit Pups

David S.
Attachments
PaDS-setup-to-merge-sfs.jpg
PaDS window successfully set up to merge sfs files
(110.43 KiB) Downloaded 432 times
directory-of-selected-sfs-to-merge.jpg
directory of 17 sfs to be merged into one all-links-sfs
(89.01 KiB) Downloaded 413 times
new-sfs-but-all-copied-also.jpg
everything in working directory
(104.04 KiB) Downloaded 411 times
preferred-result-combinedsfs.jpg
putting the result in a particular directory?
(25.68 KiB) Downloaded 413 times

ITSMERSH

#49 Post by ITSMERSH »

Hi davids45.

I never combined several .sfs into a single one.

Though, I know PaDS is copying the .sfs to a different location to extract. Probably there's just a variable not setup or even wrong values in it. This could have happened, as I took code from my X-PaDS to update PaDS.

Going to check this and fix it in next version.

Thanks for the report.

Edit:

In the images you attached I can not read the paths used in complete.

Could you post the full paths used, please?

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#50 Post by rockedge »

Code: Select all

I wonder if a third dialog box (optional?) could be "easily" included in PaDS to tell PaDS where to put the merged sfs rather than in the working directory. Saves me copying it from the working directory to where I store it, or having to delete the working file copies when I made the working directory my sfs-storing directory.
I agree that would be a great little option.

Thanks RSH for the work...it's a nice little package

Post Reply