(old)Puppy Linux Discussion Forum

Well, thanks for looking into it. As jemimah would agree, touchscreens and puppy are always a diffcult combination.

Jake

manpage for xinput_calibrator: http://www.linuxcertif.com/man/1/xinput_calibrator/

http://www.linuxcertif.com/man/1/xinput_calibrator/

The scripts/ directory constains scripts to get calibration from hal or use a pointercal file to reapply xinput commands across reboots

Those scripts were not included into the pet. Attached here. Remove the phony.gz. Give the executable permissions.

Also you can turn the verbose on:
If something goes wrong, or not as expected, turn on verbose messages:
xinput_calibrator -v

For some reason, copies of files for the following packages are in /root/.packages/builtin_files, wasting 292K. I don't know if this occurs for anyone else. All the other deb listings are empty.

libgutenprintui2-1_5.2.6-1_i386.deb
rsync_3.0.7-2_i386.deb
xserver-xorg-core_1.7.7-13_i386.deb

Thanks for those scripts. Running them in console, from ~/Downloads, I get "no calibratable devices found,"

I wonder if modprobe hid-multitouch doesn't register the touch screen for xinput.

Jake

jakfish. Yes...it could be that there should be some udev rules or some other missing framework for device detection. That is unfortunately over my capacity.

Googling tells me that hid-multitouch has replaced hid-cando. There's a way to jerry-rig the xorg file with manually-inserted calibration specs, but I can't get that to work.

I appreciate your help, and maybe another version of the kernel will allow easier touch screen functions.

Congratulations again on a good-looking OS,
Jake

jakfish. You could test 5.X.3.2.9 build....with 3.2.9 kernel...found also under Derivatives...or saluki which has my build kernel 3.2.8 and you would get jemimah to help you for finding solution. It has also newer xorg.

I don't know if this has been fixed yet, but http://www.iguleder.info/puppy/dpup/pet_packages-dpup, listed in the ppak repo-list, doesn't exist.

The repo exists. There is almost 400 packages. But the Packages-puppy-dpup-official does not exist anymore. It was Iguleder's dpup repo but it vanished. And Iguleder didnt have back up. Luckily I had almost everything downloaded and so I created the new repo. Usually I remove that database file....but it seems I have forgotten this time.
But the stuff is still there. Nobody has so far opened every pet and created new database file from them.

http://www.smokey01.com/pemasu/pet_packages-dpup/

Thanks, I didn't know where it was.

Also, ppack uses "http://distro.ibiblio.org/quirky/pet_packages-common", which doesn't appear to be the database used in the ppm.

debian-squeeze-main from the PPM doesn't seem to match anything in the repo-list either.

edit: I guess the ppm just mirrors packages.debian.org ?

I noticed my Thunar pet had missing icon in the menu entry..oops. It is now fixed. thunar-1.0.2-dpup.pet

Jpeps. Puppy package manager has restrictions hardcoded to the scripts. PPM just dont let you download something which isnt meant to your puppy version. Database files are there and they are right.
But you cant for example download from pet_packages-common repo. That repo is meant for puppy building using woof and it has those generic enough packages to use for puppy building.

The way to go with PPM is what Jemimah has done with Saluki. The outlook and repo - dependency handling has been improved radically. I dont know how easily Jemimah`s work could be transferred to the Exprimo but that is the way I would like the things to be.
And I should start to add dependency lists to my apps. I have been lazy.

Squeeze-main repo and all the squeeze repos works just fine from PPM. I suppose you have tinkered with repos too much.

Ppack manager, created by stu90 is another thing. You can download stuff from any repo. But the database file names are hardcoded, so there is also empty repositories because I havent included the Packages-puppy-something-official database file to the build.

You are right, I need to dive to the code and remove those repositories I dont use. Otherwise it is great small repository downloader.
It is about time that I start new 5.X. build. I will change the naming convention to reflect the used kernel.
So next build in this thread will be 5.X.3.1.10.1
I know...it is horrible but it helps me to understand feedback, when the name tells what kernel it uses.

Barry has fixed the woof for new firmwares. I would like to test latest woof. I will download new woof today and I will check the Ppack manager code.

For coders....and Ppack manager...it would be nice if the script could check what database files are in /root/.packages and the app would show only those repositories. I am not so able with coding that I will start the improving...but is someone...stu90 included would like to comment....the speech is free.

Tman....thank you....do you mind if I upload your Thunar to the exprimo repo ?

Thanks Pemasu; I was just trying to find where everything is. The naming convention from the PPM is exact, so easy to script, the arg being the name listed in the PPM up to the "_"
The package files are the same. What's different is the dependencies. I thought maybe that the PPM was more accurate, but it was listing deps already installed, and omitting others. It's clear that I don't want automatic installs...everything needs to be downloaded first and checked.

I hope I can implement in the future the improvements Jemimah has done to the PPM. I really think that is the way to go. I have asked already from Jemimah what it would require to get her improvements to work in Dpup Exprimo. The dependency handling is far better in Saluki.

It would be interesting if the Saluki version accurately checks for deps already installed. This PPM lists packages not only with different names, but with the same name.

pemasu wrote: Tman....thank you....do you mind if I upload your Thunar to the exprimo repo ?

By all means, upload whatever you wish.

pemasu wrote:I hope I can implement in the future the improvements Jemimah has done to the PPM. I really think that is the way to go. I have asked already from Jemimah what it would require to get her improvements to work in Dpup Exprimo. The dependency handling is far better in Saluki.

It would help if you could get a PPM-saluki pet from Jemimah - otherwise, you'd need to track down all of the needed files in Saluki - hopefully, everything needed would be in /usr/local/petget. Since Jemimah's version already has dependency-handling code built-in, you would only need to change the code that checks for the saluki repo and replace it with the exprimo repo. ( and the code for the location of your sfs files).
I might be able to help you with this, but from analyzing jpeps code of gnewpet, I know that he understands shell scripts better than I..so he would be a better candidate.

The tedius part would be repackaging all of your dpup pets to include the needed dependencies in the pet.specs file.

Jemimah posted that she will download latest Exprimo and she will take a look.
So...lets see.....

pemasu wrote:Jemimah posted that she will download latest Exprimo and she will take a look.
So...lets see.....

Maybe I'm not understanding, but I don't see how anyone can determine what the needed deps are while downloading binaries from the debian repository. If I compile something in exprimo, I can try it after pfix-ram.

The main complaint I see, is that many people want everything to work after clicking on something. I don't see that ever happening in a small distro. Try playing with keepnotes, for example. Load all the deps, and then you need pygtk. Version 2.6.1 compiles in Slacko, but not in exprimo. The package works (almost) in exprimo, but you have to copy pygtk files to a different folder. The point is, how much can be automated by the PPM without having your own database where everything is compiled and checked in your own environment ? (which thus defeats the beauty of woof)

Jemimah has improved dependency checking for pets. When you download app pet which has dependencies....it checks after installation the dependencies which are unmet...then it informs it and asks if you want to download them...if yes...then it launches the PPM again and downloads and installs....and then again...
It also informs if the pet will overwrite existing files and gives you possiblity to not install it. At least you see what files will be overwritten.

About debs...I dont know how much it will benefit them.

Anyway...I have got frequently questions...what I need to download to get abiword or gnumeric working.

Jemimah improvements handle them better...when I update my pet.specs files.

I am not going after perfect package manager. Just better PPM. I have now several package manager for different needs. If I want the whole lot of debs to be inspected...I use GonGetIt.