Forum member elroy seems to have run into a bug in the Puppy Package Manager:

elroy wrote:

I have a problem with a .pet I’ve created. It requires a version of java that’s greater than or equal to a said version; upon install (while downloading - trying to locate missing deps) it insists on downloading an earlier version.

A. PPM offers to install a version that does not meet the specification.
B. PPM doesn't offer to install a version that does meet the specification.

When I have tried this it offers to install both. So I do not know if problem B is a bug or something else. The remainder of this post concerns itself only with problem A.

Looking into this, I have found a few problems with the version checking code in dependencies.sh. Although I am running Racy 5.2.2, I'm reporting it here (in the 5.3 thread) because I've tried the current suite of petget scripts from Woof2 and the same problems arise.

1. The major problem seems to be that, although findmissingpkgs.sh creates the /tmp/petget_missingpkgs_patterns_with_versioning file, which contains the versioning requirements of the missing dependency packages, dependencies.sh never reads it.

2. The format of the entries in the /tmp/petget_missingpkgs_patterns_with_versioning file differs from what the code in dependencies.sh expects. The format in the file looks like this:

Code:

|udev|eq167-patched_t2-w5|

But the format expected by the code in dependencies.sh looks like this:

Code:

|udev&eq167-patched_t2-w5|

3. Repositories often have multiple versions of a package. Before the versioning code was added, a single grep could find all versions in a repo's database. But with the added need to check versioning, a loop is needed to individually compare the versions of each dependency package with the requirements of the package being installed. (Without the loop strange things happen: like comparing the required version string with a string that is a concatenation of the multiple versions in the repo, separated by newline characters.)

Looking over the code, I have come up with a few ideas on how to deal with these problems. There are certainly other, perhaps better, ways, but I'll submit these ideas as suggestions.

I am attaching a revised dependencies.sh (based on the version that I grabbed from Woof2 fossil. I'm also attaching a diff file, but it is short, so I'll paste it here as well. I've split it up into three pieces and have added notes that I hope will explain my not too twisted logic.

The grep is now used to initialize a new variable, $DB_ENTRIES, which can have multiple entries, instead of $DB_ENTRY. The latter is now set to the individual entries as the while loop (that replaced the if block) progresses.

Another new variable, $FOUND_IN_DB, keeps track of whether or not a good package was found in this repo's database.

Previously, when a good package was found, the code would break out of the loop that looped through the various repo databases. But now those breaks would break out of the new loop that loops through the various versions of the dependency package in the current database. We don't want to do that, since we want to provide a list of all compatible versions in the current database, so we just set a flag to indicate that at least one was found in the current data base. Then after that loop finishes we test it, and if it is good we break out of the loop that loops through the various repo databases.

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

I hasten to add that I am not very familiar with the scripts in petget. Although my changes seem to be working okay in my preliminary testing, I am hoping that someone more familiar with the code (Hi Barry!) will look this over to ensure that it makes sense and doesn't add more bugs than it squashes.

EDIT, 2012-Sep-07: In fact, there was at least one bug in my code. By using petget_missingpkgs_patterns_with_versioning, I neglected any dependencies of the dependencies (and any dependencies of the dependencies of the dependencies, etc.) that were added to petget_missingpkgs_patterns by the code earlier in dependencies.sh. Thankfully, Barry noticed that and "re-implemented" the fix with code that works properly. (See Barry's blog: PPM: deps versioning re-fixed)

So the attached files are now obsolete. The latest dependencies.sh can be found in Woof2 fossil. [END OF EDIT]

Also, anyone testing this needs to be aware that just plugging my modified dependencies.sh into an old Puppy will probably not work. One also needs to get the current versions of the other files in /usr/local/petget/ from Woof2 fossil.

Although I don't notice strange characters, there seems to be an issue with missing charsets. This stops treewm window manager from loading at all (a fresh compile to racy's kernel also fails) - curious, I tried many different fonts and even the 'fallback' fixed font fails (they all are "missing charsets").

Was about to give it up as simply not doable (for me, anyway). Then fvwm (version 262) gave me some specific details about the missing charsets when I tried some changes relating to font customization in the fvwm ui. A snippet from xerrs.log:

I am trying to run puppy on an Acer Aspire 5734Z laptop. I downloaded and burnt to disk both puppy slacko and wary and tried to boot each up on my laptop but once either of them are completely booted all I get is a black screen. However, when I hit the power button to shut the system down just as the pc starts shutting down it looks like there are a few windows open on the desktop then the pc shuts down and thats it.
I do not have a hard drive cause the 1 that came with my laptop took a crap on me so I decided to use 1 of the puppy installs on my 32gb Microsd card from my phone till I can get a new hard drive. However, to free up the sd card so I can put it back in my phone I wanted to run puppy on a dvd but like I said, once fully booted all I get is a black screen till shut down which by that point its to late.
I do have puppy linux 5.2.8 running on the microsd card in my laptop and it runs good so far but wanted to install the newest linux. So you should know that i'm a complete noob when it comes to puppy linux os's. I still haven't figured out how to use the CMD commands so i'm pretty much lost when it comes to doing any kind of install to this OS.
Thank you anyone for any help you can give me.
TC

Forum member elroy seems to have run into a bug in the Puppy Package Manager:

elroy wrote:

I have a problem with a .pet I’ve created. It requires a version of java that’s greater than or equal to a said version; upon install (while downloading - trying to locate missing deps) it insists on downloading an earlier version.

A. PPM offers to install a version that does not meet the specification.
B. PPM doesn't offer to install a version that does meet the specification.

When I have tried this it offers to install both. So I do not know if problem B is a bug or something else. The remainder of this post concerns itself only with problem A.

Looking into this, I have found a few problems with the version checking code in dependencies.sh. Although I am running Racy 5.2.2, I'm reporting it here (in the 5.3 thread) because I've tried the current suite of petget scripts from Woof2 and the same problems arise.

1. The major problem seems to be that, although findmissingpkgs.sh creates the /tmp/petget_missingpkgs_patterns_with_versioning file, which contains the versioning requirements of the missing dependency packages, dependencies.sh never reads it.

2. The format of the entries in the /tmp/petget_missingpkgs_patterns_with_versioning file differs from what the code in dependencies.sh expects. The format in the file looks like this:

Code:

|udev|eq167-patched_t2-w5|

But the format expected by the code in dependencies.sh looks like this:

Code:

|udev&eq167-patched_t2-w5|

3. Repositories often have multiple versions of a package. Before the versioning code was added, a single grep could find all versions in a repo's database. But with the added need to check versioning, a loop is needed to individually compare the versions of each dependency package with the requirements of the package being installed. (Without the loop strange things happen: like comparing the required version string with a string that is a concatenation of the multiple versions in the repo, separated by newline characters.)

Looking over the code, I have come up with a few ideas on how to deal with these problems. There are certainly other, perhaps better, ways, but I'll submit these ideas as suggestions.

I am attaching a revised dependencies.sh (based on the version that I grabbed from Woof2 fossil. I'm also attaching a diff file, but it is short, so I'll paste it here as well. I've split it up into three pieces and have added notes that I hope will explain my not too twisted logic.

The grep is now used to initialize a new variable, $DB_ENTRIES, which can have multiple entries, instead of $DB_ENTRY. The latter is now set to the individual entries as the while loop (that replaced the if block) progresses.

Another new variable, $FOUND_IN_DB, keeps track of whether or not a good package was found in this repo's database.

Previously, when a good package was found, the code would break out of the loop that looped through the various repo databases. But now those breaks would break out of the new loop that loops through the various versions of the dependency package in the current database. We don't want to do that, since we want to provide a list of all compatible versions in the current database, so we just set a flag to indicate that at least one was found in the current data base. Then after that loop finishes we test it, and if it is good we break out of the loop that loops through the various repo databases.

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

I hasten to add that I am not very familiar with the scripts in petget. Although my changes seem to be working okay in my preliminary testing, I am hoping that someone more familiar with the code (Hi Barry!) will look this over to ensure that it makes sense and doesn't add more bugs than it squashes.

Also, anyone testing this needs to be aware that just plugging my modified dependencies.sh into an old Puppy will probably not work. One also needs to get the current versions of the other files in /usr/local/petget/ from Woof2 fossil.

Yes, this is a good solution, now implemented in Woof, so will be in future puppies:

Hi rcrsn51 !
Thanks for your help with printing problems .
Did what you advised me to do . Now working .
What was wrong ? ... instead of going to " Administration > find new printer "
i went to "Administration > add new printer " which did not work .
The HP drivers i installed are some from lucid pup.......scanner to .
Everything is working fine now .
Thanks for your help .

elroy, you're welcome. As it turned out, my suggested fix had at least one problem with it. But Barry looked at it and came up with a better fix that works properly. (See Barry's blog: PPM: deps versioning re-fixed)

I installed Wary 5.3 and devx on a PIII 700MHz 512MB ram 512 swap BX chipset pc. I'm currently working at an italian translation using Momanager. No .pets installed, just devx + my savefile. I did some translations, made a .pet (partial, only to back-up), shut down OK.
Everything went well until the time when I rebooted my pc (third or fourth day of translations). X failed to start. On console I typed:
fdisk -l
and got: unable to look in /proc/partitions : file doesn't exist
or similar.
df also gave me an error message complaining at some df_FULL-something.
I tried xorgwizard + xwin, X started BUT: many programs didn't work ( terminal; wizards; jwm tray icons, desktop drive icons etc.).
Rebooting with pfix=fschk didn't solve the problem.
Then I booted Akita, mounted wary savefile, backed-up momanager translations and deleted the savefile.
I started over, new savefile, no .pets, only devx sfs. To see my translations with momanager I had to install my language .pet created before. After installation JWM and rox acted weird (windows borders were flat gray and became red when focused; JWM menu also was flat gray, and tray bar had disappeared. The menus and other things got well translated, though! Restarting X fixed this. I Worked at Momanager, then created new partial .pet, rebooted and:
same issue that I had before: no X, no /proc/partitions, JWM screwed up etc.

I think I broke something when I translated menu entries and / or scripts, or is this a momanager bug?
How to check?
I can upload my language .pet for the geeks, if interested.

Ps: the first time things got screwed up I thought: 'I told momanager to translate initrd.gz scripts and something got bad'.
So when I started over with new savefile I left initrd.gz in english, with same bad result.

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