PaDS 1.1.4 - updated version of 1.0.4

Miscellaneous tools
Message
Author
ITSMERSH

PaDS 1.1.4 - updated version of 1.0.4

#1 Post by ITSMERSH »

Hi.

So here is PaDS 1.1.4.

In version 1.1.4 I'm trying to fix what davids45 mentioned: the issue of the creation of unwanted extra lines in existing .desktop files.

It's not really an issue when the user is editing the entries by adding useful values. Though, in version 1.1.4 PaDS will pre-add some values to those empty entries ( e.g.: Name[en]= ). Those values pre-added are taken from default existing entry for EN users ( e.g.: Name= ).

Please test and report, thanks...



I will keep version 1.1.3 available to download for some period.



Info about previous versions:

PaDS 1.1.3.

It has now a GUI to edit .desktop files (and therefor gives time/break to edit content of the build-directory). Also there is additional option to create a .tcz module along with the .sfs. The md5 sum now is created for all the created files (.sfs, .pet, .tcz).

I will keep version 1.1.2 available to download for some period.



PaDS 1.1.2, a updated version of PaDS 1.0.4.

Due to a request/suggestion by mikeslr I had again a look at PaDS to make a updated version. It is a program to combine different archives/packages into a .sfs module.

As there is:

- .deb
- .pet
- .sfs
- .tar.gz
- .tazpkg
- .txz

To convert and combine such packages into a .sfs module is possible either by GUI (collecting the files from different sources) or just by right-clicking a directory (already containing all the files needed).

To work from GUI, PaDS 1.1.4 needs to have xdotool installed.

Thanks @mikeslr and @festus for testing and reporting issues/success.

Edit, 2018-07-17: a very small limitation on PaDS.
Attachments
PaDS-1.1.4.pet
Updated version, trying to fix the issue on the .desktop
files mentioned by davids45
(68.3 KiB) Downloaded 522 times
PaDS-1.1.3.pet
Updated version for testings
(68.02 KiB) Downloaded 296 times
PaDS-1.1.2.pet
Convert and combine different packages into SFS
(37.78 KiB) Downloaded 277 times
Last edited by ITSMERSH on Tue 14 Aug 2018, 21:22, edited 12 times in total.

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

#2 Post by musher0 »

Hi RSH.

We want to do these conversions because... it is more fun than basking in the sun
or doing nothing on a bright and hot summer day??!! :lol:

Or is it actually useful? Thanks for any insight.

I don't believe in automating conversion of packages from other distros. I believe the
way to do this properly is to unpack the external package "manually" and to TEST
IT thoroughly on Puppy before transforming it into an sfs.

Not sorry for the rain on the parade... I think incorporating validation is important in
such steps.

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

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

#3 Post by rockedge »

musher0 I need such capabilities....where I do very much agree with you... I will go through manually (try doing this with a working ZoneMinder and puppy) and extract and reassemble....but after that is done and tested it may reveal itself to be later very helpful to have a program like this..saves me HOURS. the other day I combined Ubuntu,Debian and Fedora packages to run something on Puppy Bionic 18.05+7

I am looking forward to working with this tool.

ITSMERSH

#4 Post by ITSMERSH »

I will go through manually ...snippet... but after that is done and tested it ...snippet... saves me HOURS.
That's how I do only on unknown programs. Mostly creating the .sfs for testings is that pretty fast and loading .sfs afterwards will save issues that may appear when installing.

Extracting all necessary packages manually to make some testing first may take much longer than just starting the creation of .sfs and loading it.

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

#5 Post by musher0 »

Hi, rockedge.

This tool encourages laziness and rounding corners, if you ask me.

SFR's UExtract takes 10 seconds max to unpack a big package. Then you browse
through the list of files, and remove whatever is typically slackware's or Debian's, etc.
Then you make a pet, and you test your app throroughly in your Pup. In particular you
check for missing or conflicting libs. Total time spent: probably 10 minutes.

If everything is fine, then you make an sfs out of it. It does not matter if you are doing
this for yourself only, but if you intend to share the app with other Puppyists, such
validation is how your respect your users, too.

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

User avatar
aaaaa
Posts: 39
Joined: Tue 22 May 2018, 14:57

#6 Post by aaaaa »

musher0 wrote:Jealousy is killing me
Nobody harasses you when post your oneliners with a wall of french text and copyright notice.

What is Flash waiting for to ban musher0 the TROLL?

ITSMERSH

#7 Post by ITSMERSH »

This tool encourages laziness
This is my main goal during my whole life, since I got better things to do than to manually unpack/pack/unpack/pack/unpack/pack...and so on. :wink:

As you might already know: to play the Drums like I do is a heavily time consumption task. And that way of playing drums has nothing to do with laziness. :D

It is similar to High-performance sports. 8) :twisted:

@musher0

Ever created a .sfs file manually from 52 .deb files? I did once. When I was faced to build again a .sfs from 26 .deb files, I decided to create PaDS. That's the whole story behind it - told the short way

Edit: btw. PaDS 1.0.4 was downloaded
1681 Time(s)
so there seems to be some need for some laziness... :wink:

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

#8 Post by rockedge »

@musher0 you didn't listen to what I said. I listened to you but you don't in return. First of all what does the first part of my response say? about manually extracting something like zoneminder which needs 3 different servers to run and 3 languages plus libs plus modules.

don't come at me with lazy anything...you're going to tell me I am lazy after doing all this testing and validating because if I didn't none of it would work and then, in that case, why would I make an sfs??

this tool will help me save hours to make this stuff so somebody just clicks once or loads an sfs and some complicated shit works for them because I did the work..so what you gonna say about that maestro ?

dancytron
Posts: 1519
Joined: Wed 18 Jul 2012, 19:20

#9 Post by dancytron »

Thanks for this. It will be very useful.

Don't let the naysayers get you down.

edit: Saying this encourages laziness is like saying that nail guns instead of hammers encourage laziness. People should use hammers instead because people will accidentally shoot nails through their hands if they use nail guns.

So everyone, please don't shoot nails through your hands.

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

#10 Post by mikeslr »

@ aaaaa, musher0 is not a troll. Many of his posts, even his critiques, have been thoughtful and informative; the things he's built and published, useful. In this instance, however, he's argued in favor of doing things his way. One way to do something may have advantages over another way. And disadvantages. Previous posts have pointed out both. One way of doing things only becomes a problem when it is mandated. This is Linux which exists to provide choice; and in particular, this is Puppy Linux which in one sense is mostly a group of "passengers" and "programming-semi-literates."

I am among the latter. For the last couple years PaDS has enabled me to build --as in a lego-block activity-- applications neither included by a Puppy's creator, nor otherwise available. I've done that under Slackos, but mostly under "Ubuntus". On several occasions building a functional application has required the incorporation of 50 or more packages; occasionally, I've included many packages only to discover that the build did not function and ldd revealed additional libraries were required. And on more than one occasion, I've run into a 'road-block': the still missing package could not be found on a binary compatible Distro (not even using a higher number with a symbolic link named as the missing package) while packages from other distros generated errors. In short, all my efforts came to naught.

If I had been limited to decompressing packages using UExtract -- one of Puppy's great tools-- and manually moving required files into their proper places creating applications would have taken days rather than hours. And in those instances where my efforts came to naught, I would have had hundreds of useless files scattered throughout my system. Frankly, I would never have tried to build some of the applications I later made available to others or explained how to build.

One great advantage of an SFS is that if it doesn't work it can simply be deleted and your system remains uncontaminated. Another is that if two applications conflict with each other, each can be loaded and unloaded as necessary.

I've mentioned one of the problems I encountered in building applications: that after the initial build it still wasn't functional and ldd revealed libraries were missing. After locating the library, it would have to be added as a source to the source files previously accumulated, and PaDS run again. At that time there was an application to combine SFS, but only SFSes, while PaDS could not include SFSes as source files. That limitation no longer exists. PaDS can now combine source debs (or pets, tgzes, txzes or tazpkges) with one or more SFSes. How often has some responder advised, "You can use the XYZ.sfs for Tarhpup (or Slacko or similar), but you'll have to include the ABC library?" Which means, of course, that if you have a need or desire to rebuilt your Puppy, you really don't have a functional XYZ.sfs.

My philosophy is to install as little as possible into a SaveFile/Folder --especially as I prefer the former. One exception is such "frame-work" applications as Qt whose presence will be required by other applications. Although I will test a Qt.SFS for completeness and functionality, my procedure has been to mount the functional Qt.SFS. copy its files to a folder named "Qt_xxx", and dir2pet that folder, then install the pet. Although I haven't tested the 1.1.2 revision yet, it is my understanding the such manual labor is no longer necessary as PaDS 1.1.2 can build a pet.

One of the problems I encountered using PaDS 1.0.4 is that 64-bit "ubuntu" Puppies' structure differs from the Ubuntus to which they are binary compatible. Applications built for 64-bit Ubuntus may place files in three folders which Puppies can't even find. See http://murga-linux.com/puppy/viewtopic. ... 945#960945. Essentially, the files assigned to those folders had to be manually moved to folders which Puppies recognized. PaDS now manages this automatically during the build process.

PaDS 1.0.4 built the SFS in /root, a significant limitation if you are working with limited RAM. Using PaDS 1.1.2, you can select the build location to be on your hard(or USB)-drive.

As ITSMERSH mentioned, there are two ways to run PaDS 1.1.2: (1) place all source files in a named folder, right-click it, and select Combine-to-SFS; or (2) browse to each location where a source file is located, select it, then browse to other locations. Under PaDS 1.0.4. the first method could not be used with X-Puppies or Lx-Puppies, as it depended on Rox-Right-click functionality. PaDS 1.1.2 overcame that limitation. You may find that each method has its advantages. When you are accumulating source packages, placing them in one location may suggest the use of the first method. While adding a missing package to an already built SFS may suggest use of the second method.

TIP: Using the GUI (second) method, after you've selected one file in a folder for inclusion, pressing Ctrl-a will select all the other files in that folder. Then click Add to add all to the build-list which will appear in the middle-panel. If some of the files in the source folder aren't needed, you can then individually remove them from the build-list.

As ITMERSH mentioned, to employ the 2nd method will require that xdotool be installed. This is a small application (44-64 Kbs) best selected from your Puppies Repos, but as far as I can tell, any version can be used as long as it is of your Puppies architecture (i.e., 32 or 64 bit).

I have reason to believe that PaDS will prove to be an invaluable tool under TazPup. As I understand mistfire's vision, TazPup seeks to combine the best of Slitaz and Puppies. Unlike Puppies, Slitaz is a rolling release; and its built- in programing language is dash rather than "bash". Consequently, Tazpup will be constructed with Slitaz as its 'core/foundation' while applying Puppy's aufs and some other structures to create SaveFiles/Folders and some other Puppy niceties. Although pets can be installed, not all will function as those pets may expect "bash". [I've generalized, a lot using "bash" in a very broad sense but hope I've 'caught the essence'. To be more specific, it has to do with Puppy's use of bash as /bin/sh apparently to accommodate gtkdialog. See the posts by wiak and s243a on the Tazpup thread].

At any rate, the ability to convert pets to SFS for testing under Tazpup, or building SFSes from tazpkges which might still be functional after an upgrade of Slitaz core packages should prove useful.

mikesLr

ITSMERSH

#11 Post by ITSMERSH »

I think, I should mention a very small limitation of PaDS 1.1.2 along with the nice new features, @mikeslr kindly pointed out in his above post.

This limitation is present on right-click action and by the use of the GUI.

E.g.:

One would use PaDS 1.1.2 to build a ALSA Player .sfs from e.g. alsaplayer-alsa_0.99.80-5.1ubuntu1_i386.deb. The name of the .sfs to be created needs to be different to alsaplayer-alsa_0.99.80-5.1ubuntu1_i386.

In fact, the name of the .sfs to be built needs to be different to all names of packages used. This is also for the directory, wherein .deb, .pet etc. may be collected, to build the .sfs by right-click action.

I do solve this by removing the ubuntu part for the name of the new .sfs: e.g. alsaplayer-alsa_0.99.80-5.1 or even e.g. alsaplayer-alsa_0.99.80-5.1-tahr etc.

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

#12 Post by rockedge »

if this tool could only as an addition to it's capabilities...be able to combine corepup (tinycore) .tcz packages and or sfs files to tcz ... just a thought..I use it as it is..Good work.

backi
Posts: 1922
Joined: Sun 27 Feb 2011, 22:00
Location: GERMANY

#13 Post by backi »

Hi !
This is one of the slick/cool Tools which me and the World was waiting for all the Time .......
Applause ,Applause ,Applause .......... :D :D :D :D :) :)

Thank you very much ITSMERSH.......
Keep on rocking.....!

ITSMERSH

#14 Post by ITSMERSH »

rockedge wrote:if this tool could only as an addition to it's capabilities...be able to combine corepup (tinycore) .tcz packages and or sfs files to tcz ... just a thought..I use it as it is..Good work.
Hi rockedge.

Is .sfs usable in tiny core?

I could include a option to build .sfs from .tcz also into a next version. And then -in addition like the .pet option- a option to create a .tcz package along with the .sfs. Though, I don't want to turn it into a package creator in general.

However: I don't have any idea how to pack/unpack .tcz files.

Any code example of how to do this?

@backi

Thanks!

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

#15 Post by musher0 »

Hello, friends and foes !!!

Thanks mikeslr for coming to my defense.

My point basically is this: in this PaDS-1.1.2 -- or any other automated conversion of
archives -- this is not personal against *RSH -- WHERE IS THE VALIDATION before the
conversion ?

Explain to me how good validation is done before transformation to sfs and I will
shut up.
(And aaaaa can levitate all the way to heaven!!!)

More often than not in this kind of tranformation, the end result in the sfs contains
unwanted slag: e.g., the "install" directory coming from slack packages OR the "control"
file from ubuntu deb archives, found in plain sight in /, by golly! :roll: And because they
are in a sfs, they cannot be erased permanently !!! :cry:

Plus when one transforms libraries form deb archives, the /usr/lib/package/*.pc file is
missing. You have to find and install the corresponding "dev" archive to get this
identification file. Now this omission makes compilation of a program that needs this
identification file go bonk. I had this problem just this morning !!!

When one does such conversions manually, one notices these things and corrects them
as they happen. When it is done automatically, maybe yes, maybe no.

Thanks in advance for responding to my concern for good validation.

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

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

#16 Post by musher0 »

ITSMERSH wrote:
rockedge wrote:if this tool could only as an addition to it's capabilities...be able to combine corepup (tinycore) .tcz packages and or sfs files to tcz ... just a thought..I use it as it is..Good work.
Hi rockedge.

Is .sfs usable in tiny core?

I could include a option to build .sfs from .tcz also into a next version. And then -in addition like the .pet option- a option to create a .tcz package along with the .sfs. Though, I don't want to turn it into a package creator in general.

However: I don't have any idea how to pack/unpack .tcz files.

Any code example of how to do this?

@backi

Thanks!
Hi RSH.

It's no big mystery. Just change the extension from tcz to sfs. Because tcz archives
are squashed archives, you can open them with the unsquashfs utility. Q.v.
http://forum.tinycorelinux.net/index.php?topic=7130.0

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

ITSMERSH

#17 Post by ITSMERSH »

the "control" file from ubuntu deb archives, found in plain sight in /
At least the Slacko install directory and its doinstall script is executed and it is removed afterwards, so it doesn't appear in the .sfs.

Also the pet.specs from Puppies .pet files. Can't recall the control file and am not sure about the pinstall script, though.
It's no big mystery. Just change the extension from tcz to sfs. Because tcz archives are squashed archives, you can open them with the unsquashfs utility.
Ok, I see. 8) Thanks.

ITSMERSH

#18 Post by ITSMERSH »

@musher0

Re the control file.

Would you please post a link to a .deb file that includes that control file, so I can examine this?

Few minutes ago I unpacked some .deb files, but none of them included such control file (assuming it is named: control).

Thanks

ITSMERSH

#19 Post by ITSMERSH »

Ok, I can recall the control file by now.

I had once created a program: make-deb-package.

For this I had created code to make the control file, which is in: /DEBIAN/control. So, next version of PaDS will remove that /DEBIAN/control directory and file.

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

#20 Post by musher0 »

ITSMERSH wrote:@musher0

Re the control file.

Would you please post a link to a .deb file that includes that control file, so I can examine this?

Few minutes ago I unpacked some .deb files, but none of them included such control file (assuming it is named: control).

Thanks
Hi, RSH.

Gladly:
https://ubuntu.pkgs.org/16.04/ubuntu-ma ... 6.deb.html
On that page, please go down to the "Download" section. That is where the
ubuntu deb archive is. I was trying to compile the "alltray" utility yesterday
morning, and the libgtop library is required: all the parts of it! ;)

I can't remember if the Debian deb archives have similar "guide" files,
but ubuntu's sure are a pain in the neck when creating a pet of sfs.

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

Post Reply