site  contact  subhomenews

Keep on finding bugs

January 05, 2017 — BarryK
Bugs keep getting unearthed, even in code that has been working OK for years.

Desktop icons
First though, a mention of icon sets. Yesterday I installed the Oranchelo and Sarai icon set PETs. After selecting them, I discovered that there were no icons in the JWM menu.
This is because the developer renamed SVG icons with .png extensions.
I have sent a PM to the developer, with advise how to fix this. He will have to fix and re-upload those PETs.

Package installing
/usr/local/petget is where all the scripts are for the PPM (Package Manager).
Yesterday, I installed a PET that has /lib and /lib64 folders in it, where /lib64 is a symlink to /lib
Yikes, in my SlaQ Quirky, which has /lib64 NOT a symlink, it got wiped out and a symlink /lib64 to /lib created.

This is obviously dangerous behaviour! Yet the code has been there for years. In my woofQ, until yesterday anyway, and yep, still in woof-CE:
https://github.com/puppylinux-woof-CE/woof-CE/blob/testing/woof-code/rootfs-skeleton/usr/local/petget/installpkg.sh

...look at line 343 onwards, that is where the naughty code is. I don't know what my thinking was at the time. Anyway, i have deleted the entire if - else -fi, from lines 344 to 367.

The woof-CE and woofQ 'petget' scripts have changed a lot since forking from Woof2, my woofQ scripts are going in their own direction. However, they both have that section of offending code.

Comments

Good, mavrothal has implemented the fix in woof-CE:

https://github.com/puppylinux-woof-CE/woof-CE/commit/d340723b9867c54e51d0e58c864a2f9c3ef4744f

I have been trying to think what my original reasoning was, to allow that behaviour. Perhaps, when installing a Service Pack, to allow major changes to the f.s. directories. But generally, it seems a very bad idea, allows a rogue PET to mess up the f.s.

Tags: linux