(old)Puppy Linux Discussion Forum

rerwin wrote:01micko has been after me to clean up the /tmp directory permisions in my frisbee-1.0 packages, because it created situtaion that jeopardizes puppy stablity/rebustness. I have corrected that problem in the 20130228 version now available in the usual places.

Here is his patient explanation to me:

Here is the problem.. I wish i could find the link.

If permissions on /tmp are not drwxrwxrwt (or 1777) some cups drivers do not work. We found this problem occurring time and time again in Lupu, and it was mainly because of bad DEB packages with 755 or drwxr-xr-x. A package that contains those permissions will change the permissions on /tmp on the system. Some debs were so bad that they weren't even owned by root! They would default to users:500.

I know you delete the file directly but the damage is done. As soon as the pet gets extracted to it's path the permissions change, check your /tmp, permissions will likely be wrong.

It also affects users who want to use the universal installer to install to a USB drive, I don't know why but it is reported in the slacko-5.4 bug thread, I can find that link.. http://murga-linux.com/puppy/viewtopic. ... 630#677630

I hope this gives you some understanding. I had problems with zigbert's Pmusic too, as he was using /tmp as a temporary location to install other stuff, rox right clicks I think, that don't work in woof.

It's not for me, because woof changes the permissions to 1777 when the build is almost complete. it's for the users out there installing and testing. They may find later on that printing has failed or they can't get their USB stick to work. These problems are difficult to debug. If I see a post like that I'll ask for the output of ls -l /

NOTE: You only need to change the permissions on /tmp and no other directory in your package tree.
. . .
In rox, if you select "properties" you get the checkboxes, all on the left (9 of them) should be checked and on the right the bottom one.. "sticky" is the label.

The link points to this conversation:

Master_wrong
. . .
during install into usb flashdisk there is syslinux error
Quote:
possibly unsafe /tmp/ permissions

fix
Quote:
chmod 1777 /tmp

then run installer
_________________

01micko

Perms are already 1777 on /tmp. You may have installed a bad package.
_________________

SFR

@Master_wrong & @01micko

That's strange, but in my case /tmp sometimes has 1777 and sometimes 777.
Eg. in my install (pmedia=ataflash on internal SATA HDD) it had 777 by default and I couldn't make it to preserve 1777 after reboot.
(/initrd/pup_ro2/tmp has 777 as well, perhaps that's why?)
I simply added chmod 1777 /tmp to rc.sysinit to achieve this.

On the other hand, when I switch to pmedia=atahd, /tmp suddenly becomes 1777 and, in addition, it appears as a mount point.
(I checked this a few minutes ago in VBox, 5.4-PAE)

Also, pristine boot without a savefile also gives /tmp 777.

IIRC I noticed this also in 5.3.3, but I didn't report it, because usually I have "luck" of experiencing "it's_just_me" kind of issues...

Attached are small mods to dir2pet and installpkg.sh to ensure correct permissions in a .pet and after installation of any package. Here are the difference listings:

Code: Select all

--- dir2pet-5492	2013-01-13 19:09:21.000000000 -0500
+++ dir2pet	2013-03-02 16:33:48.000000000 -0500
@@ -13,6 +13,7 @@
 #w482 if preexisting pet.specs, read fields from it.
 #100201 improve reading of pet.specs
 #100303 fix bug detection arch-dependent pkg.
+#130302 ensure package tmp directory, if any, has all permissions.
 
 if [ ! $1 ];then
  echo "It is required to invoke this script like this:
@@ -347,6 +348,8 @@
  exit
 fi
 
+[ -d $DIRPKG/$BASEPKG/tmp ] && chmod 1777 $DIRPKG/$BASEPKG/tmp #130302
+
 cat /tmp/petspec_db_entry | tail -n 1 > $DIRPKG/$BASEPKG/pet.specs
 
 echo



--- installpkg-5492.sh	2013-02-19 08:35:15.000000000 -0500
+++ installpkg.sh	2013-03-02 16:31:22.000000000 -0500
@@ -47,6 +47,7 @@
 #130114 revert 130112 "multiarch symlinks now optional".
 #130126 'categories.dat' format changed.
 #130219 grep, ignore case.
+#130302 ensure tmp directory has all permissions after package expansion.
 
 #information from 'labrador', to expand a .pet directly to '/':
 #NAME="a52dec-0.7.4"
@@ -358,6 +359,8 @@
 mv /*.xpm /usr/local/lib/X11/mini-icons/ 2>/dev/null
 mv /*.png /usr/local/lib/X11/mini-icons/ 2>/dev/null
 
+ls -dl /tmp | grep -q '^drwxrwxrwt' || chmod 1777 /tmp #130302
+
 #post-install script?...
 if [ -f /pinstall.sh ];then #pet pkgs.
  chmod +x /pinstall.sh

mchabez wrote:2. Package deps like "upstart-job" aren't resolved in PPM. There is no such package name "upstart-job" in the Ubuntu Precise repos, as it's a virtual package provided by "upstart". One such package dependent on upstart-job is "binfmt-support".

BarryK wrote:

mchabez wrote:2. Package deps like "upstart-job" aren't resolved in PPM. There is no such package name "upstart-job" in the Ubuntu Precise repos, as it's a virtual package provided by "upstart". One such package dependent on upstart-job is "binfmt-support".

Yes, I see. OK, I will have a go at fixing that.

anikin wrote:An attempt to remaster precise-4.5.93 (no CD drive, but the ISO is mounted) ends with this error warning - see attached image. The one-line fix suggested in wary/racy thread doesn't help. Any ideas?

PS: this was initially posted in a wrong thread, sorry.

edit: a quick test - remaster doesn't stumble on this ISO in dpup exprimo-3.6.2. Something must have changed in the script. See another attached image.

rerwin wrote:Thanks to mavrothal and peebee keeping after me, I think I have solved the issue of frisbee not running correctly in racy and wary, and now also in precise. Frisbee, all along, has used the wpa_supplicant "-f" option to specify a "debug" log file. That is apparently configurable when compiling wpa_supplicant. Now, it is rejected, preventing wpa_supplicant from starting. Since the same output goes to stdout, the fix simply redirects the output from the startup of wpa_supplicant, to the log file. I feel it is important that this fix be included in the next beta release, assuming the testing of it goes well.

Barry, please hold off until we get confirmation that my fix works. For anyone who is willing to test it, the package is here:
http://murga-linux.com/puppy/viewtopic. ... 092#684092

EDIT early 3/5/2013: I have verified that the 20130304 frisbee package restores frisbee's normal functionality with wireless networks, on precise 5.4.92. Mavrothal is testing, too, probably on Racy 5.5.
Richard

Did not get to desktop. Only have black screen.