Pets failing to install in Fossa9.6CE

[amethyst]

I've tried to install some of my pets I've published here on the forum in Fossa9.6CE but they all fail to install. Why? Don't have this problem with other Puppys (installs fine in Fossa9.5, Bookworm, etc.). Can't extract it with uextract either, get a gzip...tar not found failure message. It seems tar.gz is not installed/supported, which is strange since this is the most common of all....Is there a package for this?
Edit: gzip is either not installed or not correctly linked. Anyway - Attached the executable. Place it in /bin (remove the fake .gz extension). Uextract works for me after this and it looks like a script is automatically generated afterwards.

[ozsouth]

@amethyst - weird. Fossapup64-9.6CE-4 has tar & gzip in /bin. They are the same versions as in Fossapup64-9.5. I installed a .pet I gzipped - ok.
I ran tar -zxvf on a tar.gz file (a driver file from github) - expanded ok & repeated it with xarchiver (just clicked on file in ROXFiler). I downloaded nicOS-Package-Remover.pet & it installed by clicking on it in ROXFiler. Also ran tar -zxvf on it successfully. Is it a faulty install?

[amethyst]

@amethyst - weird. Fossapup64-9.6CE-4 has tar & gzip in /bin. They are the same versions as in Fossapup64-9.5. I installed a .pet I gzipped - ok.
I ran tar -zxvf on a tar.gz file (a driver file from github) - expanded ok & repeated it with xarchiver (just clicked on file in ROXFiler). I downloaded nicOS-Package-Remover.pet & it installed by clicking on it in ROXFiler. Also ran tar -zxvf on it successfully. Is it a faulty install?

My Fossa9.6 did not have the gzip executable in /bin (see attached image of /bin in base sfs). BTW - I've run into another problem with Fossa9.6CE. It seems to me there is a problem with the package managers. Could be related to names. I get very odd behaviour. For instance> I have a few utilities which start with the initial same characters (nicOS...) all install correctly (well initially it seems to install correctly) but what actually happens is that the first one installs then the second one replaces the first one (the previous pet installed is deleted automatically). Never seen this behaviour before. As for faulty install - don't think so, have been running it for a few months. However, it is installed to an ntfs partition (because this is the only way it works on this external harddrive for booting, etc). Some weird stuff can happen when Puppy is installed on an ntfs partition.
Edit: As far as the missing gzip is concerned: I see this is in the originally issued sfs. There must have been a mistake when I repacked it with gzip compression (first time this has happened to me).

[amethyst]

@rockedge Do you have any ideas about this package manager issues I have?

[rockedge]

@amethyst Looking over it now. I have also seen odd things happen involving installing and saving on NTFS formatted partitions with both KLV's and some woof-CE builds of Fossapup64.

Do the nicOS... variants have different version numbers in their names? Have you done the same package install using pkg on the command line (or GUI)?

[amethyst]

@amethyst Looking over it now. I have also seen odd things happen involving installing and saving on NTFS formatted partitions with both KLV's and some woof-CE builds of Fossapup64.

Do the nicOS... variants have different version numbers in their names? Have you done the same package install using pkg on the command line (or GUI)?

No but the names are all different (different applications but they all start with nicOS...). The applications are not in a repo. I'm not sure but I think I may have seen this behaviour before with another new Puppy (Bookworm perhaps) on another machine where Puppy is not installed on an ntfs partition. To replicate, try to install the following one after the other and check the results: download/file.php?id=16773, download/file.php?id=9741, download/file.php?id=13159, download/file.php?id=9463

[fr-ke]

@amethyst
in BW64_10.0.6:

I installed nicOS-Package-Remover.pet, nicOS-PowerTimeout.pet,nicOS-SFS-Editor.pet

nicOS Package Remover is briefly present in the menu, but disappears after a short time, fixmenus doesn't change anything

/usr/sbin does not contain any of the installed scripts

If you enter nicOS TAB TAB in the terminal, the scripts are not displayed
Nevertheless, nicOS Package Remover, for example, can be started with the full name in the terminal

Even after a Save2SFS, the scripts are not in the newly created e.g. adrv_.sfs

It is also noticeable that the .pet can be reinstalled after about a minute
Only if the same .pet is installed one after the other does the error message "...is already installed" appear?

EDIT: i run BW64_10.0.6 without savefile/folder

[fr-ke]

@amethyst

I can also confirm the behavior described here
viewtopic.php?p=114639#p114639 for Fossa64CE.
It seems that the .pet overwrite each other and can therefore be reinstalled alternately.

[amethyst]

@amethyst
in BW64_10.0.6:

I installed nicOS-Package-Remover.pet, nicOS-PowerTimeout.pet,nicOS-SFS-Editor.pet

nicOS Package Remover is briefly present in the menu, but disappears after a short time, fixmenus doesn't change anything

/usr/sbin does not contain any of the installed scripts

If you enter nicOS TAB TAB in the terminal, the scripts are not displayed
Nevertheless, nicOS Package Remover, for example, can be started with the full name in the terminal

Even after a Save2SFS, the scripts are not in the newly created e.g. adrv_.sfs

It is also noticeable that the .pet can be reinstalled after about a minute
Only if the same .pet is installed one after the other does the error message "...is already installed" appear?

EDIT: i run BW64_10.0.6 without savefile/folder

The Package-Remover and PowerTimeout should be in the menu after installation. The SFS-Editor should be in the Open With menu because it's a right click utility without a menu entry. You have confirmed having the same problem that I have, problem must be with the changed package managers.

[fr-ke]

@amethyst
Everything after the first hyphen appears to be interpreted as a version number in an .pet-file.
If you create a .pet it will appear in the pet.specs.
The program would then always be “nicOS” in different versions
Apparently there can only be 1 "nicOS" in user-installed packages

[fr-ke]

@amethyst

It appears that this problem can be avoided by appending a numeric value at the end.
nicOS-Power-Timeout-1.3.pet and nicOS-Package-Remover-1.3.pet then work as expected.
The hyphens in front of the numerical values ar then interpreted as part of the name.
I haven't found a nomenclature for creating pet files, although it would be interesting to know if it exists.

[amethyst]

@amethyst

It appears that this problem can be avoided by appending a numeric value at the end.
nicOS-Power-Timeout-1.3.pet and nicOS-Package-Remover-1.3.pet then work as expected.
The hyphens in front of the numerical values ar then interpreted as part of the name.
I haven't found a nomenclature for creating pet files, although it would be interesting to know if it exists.

Yes but very silly it seems because the applications have a very different, unique name in the first place.

[fr-ke]

@amethyst

in Bionic64_8 your .pets are processed as expected.

There are significant differences between the /usr/bin/dir2pet in Bionicpup64_8 and e.g. Fossa9-6CE which creates the .pet files (ends up in the pet.specs)

Workaround: In the GUI of dir2pet, change name-only: manually and version: if necessary, or leave it empty

[amethyst]

A perfect example of changing code for the worse. Newer is not always better, confirmed once more. Why change stuff when it is not broken?

[fr-ke]

@amethyst
I have carried out further tests.

I ran makepet from Bionicpup in Fossapup and that
makepet from Fossapup in Bionic.
As a result, the two nicOS pets can be installed at the same time in Bionicpup and not in Fossapup.

So, as they suspected, it could be due to changes in the package manager.