tahrpup 6.0, 6.0.2 & 6.0.5 CE

[James C]

Apparently found a problem with the installer. Details here http://www.murga-linux.com/puppy/viewto ... 881#833881

Someone else with an similar installer problem

http://www.murga-linux.com/puppy/viewto ... 235#833235

[666philb]

Apparently found a problem with the installer. Details here http://www.murga-linux.com/puppy/viewto ... 881#833881

it's odd as full install to partition is working fine for me with the universal installer.

do you know the harddrive specs?

[bigpup]

Here is a bug with a solution fix.

Problem with Bulgarian keyboard layout variant
Subject description: Keyboard layout variant resets after reboot
http://www.murga-linux.com/puppy/viewtopic.php?t=98251

[James C]

Apparently found a problem with the installer. Details here http://www.murga-linux.com/puppy/viewto ... 881#833881

it's odd as full install to partition is working fine for me with the universal installer.

do you know the harddrive specs?

Referring to the box in the linked post, a single 40 gb Maxtor IDE hdd on a 733 mhz P3 w/ 256 mb of ram. I've since did a full install of the latest AntiX 15 Beta without incident.Same partition intended for Tahr actually.

Installer was in the process of probing the partitions when it offered to do a superfloppy install to the entire drive which it listed as only 6 Gb.No choice of any partition was offered so I aborted.Attempted three times in total before I moved on.

And yes,I chose the "full" install option in the installer.

Later did a full install on a dual-core box,same cd, no problem at all.

[keyboard]

path of all of header files in header files of glib and gtk are all mixed up, either change the path of header files in individual header files or make symlinks for folders. I normally don't compile my programs in puppy linux , since i am fixing the desktop so i tried to compile something today to test it out in my laptop puppy linux. I made appropriate symlinks but it seems that it is too much mixed up.

It may need both editing in header files and symlinks (editing the header files now)

errors(and while fixing):

Code: Select all

root# gcc dailog.c -o dailog -lm
In file included from dailog.c:3:0:
/usr/include/gtk-2.0/gtk/gtk.h:32:21: fatal error: gtk/gtk.h: No such file or directory
compilation terminated.
root# gcc dailog.c -o dailog -lm
In file included from /usr/include/gdk/gdk.h:32:0,
                 from /usr/include/gtk/gtk.h:32,
                 from dailog.c:3:
/usr/include/gdk/gdkapplaunchcontext.h:30:21: fatal error: gio/gio.h: No such file or directory
compilation terminated.
root# gcc dailog.c -o dailog -lm
In file included from /usr/include/gdk/gdk.h:32:0,
                 from /usr/include/gtk/gtk.h:32,
                 from dailog.c:3:
/usr/include/gdk/gdkapplaunchcontext.h:30:21: fatal error: gio/gio.h: No such file or directory
compilation terminated.
root# gcc dailog.c -o dailog -lm
In file included from /usr/include/gio/giotypes.h:28:0,
                 from /usr/include/gio/gio.h:26,
                 from /usr/include/gdk/gdkapplaunchcontext.h:30,
                 from /usr/include/gdk/gdk.h:32,
                 from /usr/include/gtk/gtk.h:32,
                 from dailog.c:3:
/usr/include/gio/gioenums.h:28:25: fatal error: glib-object.h: No such file or directory
compilation terminated.
root# gcc dailog.c -o dailog -lm
In file included from /usr/include/gio/giotypes.h:28:0,
                 from /usr/include/gio/gio.h:26,
                 from /usr/include/gdk/gdkapplaunchcontext.h:30,
                 from /usr/include/gdk/gdk.h:32,
                 from /usr/include/gtk/gtk.h:32,
                 from dailog.c:3:
/usr/include/gio/gioenums.h:28:25: fatal error: glib-object.h: No such file or directory
compilation terminated.
root# gcc dailog.c -o dailog -lm
In file included from /usr/include/gio/giotypes.h:28:0,
                 from /usr/include/gio/gio.h:26,
                 from /usr/include/gdk/gdkapplaunchcontext.h:30,
                 from /usr/include/gdk/gdk.h:32,
                 from /usr/include/gtk/gtk.h:32,
                 from dailog.c:3:
/usr/include/gio/gioenums.h:28:25: fatal error: glib-object.h: No such file or directory
compilation terminated.
root# gcc dailog.c -o dailog -lm
In file included from /usr/include/gio/giotypes.h:28:0,
                 from /usr/include/gio/gio.h:26,
                 from /usr/include/gdk/gdkapplaunchcontext.h:30,
                 from /usr/include/gdk/gdk.h:32,
                 from /usr/include/gtk/gtk.h:32,
                 from dailog.c:3:
/usr/include/gio/gioenums.h:28:25: fatal error: glib-object.h: No such file or directory
compilation terminated.
root# gcc dailog.c -o dailog -lm
In file included from /usr/include/gio/giotypes.h:28:0,
                 from /usr/include/gio/gio.h:26,
                 from /usr/include/gdk/gdkapplaunchcontext.h:30,
                 from /usr/include/gdk/gdk.h:32,
                 from /usr/include/gtk/gtk.h:32,
                 from dailog.c:3:
/usr/include/gio/gioenums.h:28:25: fatal error: glib-object.h: No such file or directory
compilation terminated.
root# gcc dailog.c -o dailog -lm
In file included from /usr/include/gio/giotypes.h:28:0,
                 from /usr/include/gio/gio.h:26,
                 from /usr/include/gdk/gdkapplaunchcontext.h:30,
                 from /usr/include/gdk/gdk.h:32,
                 from /usr/include/gtk/gtk.h:32,
                 from dailog.c:3:
/usr/include/gio/gioenums.h:28:25: fatal error: glib-object.h: No such file or directory
compilation terminated.
root# gcc dailog.c -o dailog -lm
In file included from /usr/include/gio/gioenums.h:28:0,
                 from /usr/include/gio/giotypes.h:28,
                 from /usr/include/gio/gio.h:26,
                 from /usr/include/gdk/gdkapplaunchcontext.h:30,
                 from /usr/include/gdk/gdk.h:32,
                 from /usr/include/gtk/gtk.h:32,
                 from dailog.c:3:
/usr/include/glib-object.h:23:30: fatal error: gobject/gbinding.h: No such file or directory
compilation terminated.
root# gcc dailog.c -o dailog -lm
In file included from /usr/include/glib-object.h:23:0,
                 from /usr/include/gio/gioenums.h:28,
                 from /usr/include/gio/giotypes.h:28,
                 from /usr/include/gio/gio.h:26,
                 from /usr/include/gdk/gdkapplaunchcontext.h:30,
                 from /usr/include/gdk/gdk.h:32,
                 from /usr/include/gtk/gtk.h:32,
                 from dailog.c:3:
/usr/include/gobject/gbinding.h:28:18: fatal error: glib.h: No such file or directory
compilation terminated.
root# gcc dailog.c -o dailog -lm
In file included from /usr/include/glib-object.h:23:0,
                 from /usr/include/gio/gioenums.h:28,
                 from /usr/include/gio/giotypes.h:28,
                 from /usr/include/gio/gio.h:26,
                 from /usr/include/gdk/gdkapplaunchcontext.h:30,
                 from /usr/include/gdk/gdk.h:32,
                 from /usr/include/gtk/gtk.h:32,
                 from dailog.c:3:
/usr/include/gobject/gbinding.h:28:18: fatal error: glib.h: No such file or directory
compilation terminated.
root# gcc dailog.c -o dailog -lm
In file included from /usr/include/glib-object.h:23:0,
                 from /usr/include/gio/gioenums.h:28,
                 from /usr/include/gio/giotypes.h:28,
                 from /usr/include/gio/gio.h:26,
                 from /usr/include/gdk/gdkapplaunchcontext.h:30,
                 from /usr/include/gdk/gdk.h:32,
                 from /usr/include/gtk/gtk.h:32,
                 from dailog.c:3:
/usr/include/gobject/gbinding.h:28:18: fatal error: glib.h: No such file or directory
compilation terminated.
root# gcc dailog.c -o dailog -lm
In file included from /usr/include/glib-object.h:23:0,
                 from /usr/include/gio/gioenums.h:28,
                 from /usr/include/gio/giotypes.h:28,
                 from /usr/include/gio/gio.h:26,
                 from /usr/include/gdk/gdkapplaunchcontext.h:30,
                 from /usr/include/gdk/gdk.h:32,
                 from /usr/include/gtk/gtk.h:32,
                 from dailog.c:3:
/usr/include/gobject/gbinding.h:28:18: fatal error: glib.h: No such file or directory
compilation terminated.

or there is another way to compile in puppy linux ?

[mavrothal]

or there is another way to compile in puppy linux ?

Not sure what you try to do but I downloaded ftp://ftp.us.debian.org/debian/pool/mai ... rig.tar.gz and then I did

Code: Select all

./configure --prefix=/usr
make

and got no errors

[keyboard]

well, i compiled a program with glade in c/c++, which i usually do, and yes I wrote the program myself. As a developer, I asked that is there another way to compile puppy linux?? because the package provided in the devx sfs of tahr has all the header files mixed up. (As in the path of header files in other header files is mixed up with the original location of header files)

or there is another way to compile in puppy linux ?

Not sure what you try to do but I downloaded ftp://ftp.us.debian.org/debian/pool/mai ... rig.tar.gz and then I did

Code: Select all

./configure --prefix=/usr
make

and got no errors

That is not the package I am compiling , I am compiling my own software but glade, gtk cairo and other header files are mixed up.

And no I can't put it in better words than this , a developer would understand this i presume.

[rerwin]

mavrothal,
Although I experienced this problem with tahrpup, I am now encountering it in my effort to integrate save-to-directroy into lucid pup 5.2.8.7. The drive space available for my pupsave files is less than 400 MB -- when I try to create a new pupsave file after first bootup, tahrpup and my test-lupu simply state that nothing was saved and terminate! I use very small pupsaves that would fit easily into the space available.

My guess is that you have a test somewhere for a minimal amount of free space before saving to a directory there. But that test should not apply until it is determined that the save is to a directory instead of a file.

I worked around this in tahrpup by saving to another partition with more free space and then moving the pupsave file to the intended partition. But for space-limited systems, that would be inadequate.

Would you please address that issue, or would you like me to look into it?

One other item: when I examined shutdownconfig I saw some code that set many puppy variables, surrounded by a commented-out "echo" command and a target file name. Is that still correct, or is it leftover debug code? Before I experiment with uncommenting that text, I thought I would mention it to you first.

Thanks for checking into this.
Richard

[01micko]

Richard,

I think Karl_Godt put most of those echoes in there for debugging purposes, so feel free to use them and add more and of course comment them out when up to release stage.

Cheers.

[rerwin]

Thanks, Mick. However this does not look like the usual debug-type code:

Code: Select all

 #record all variables to a file...
 #echo "
PUPMODE=128
SAVEPART=${SAVEPART}
SAVEFS=${SAVEFS}
PUPSAVE=${PUPSAVE}
SAVEFILE=${SAVEFILE}
NAMEONLY=${NAMEONLY}
SAVEPATH=${SAVEPATH}
MYPASSWORD=''
SFEXT=''
xPDEV=${PDEV1}
xDEVFS=${DEV1FS}
xPSUBDIR=${PSUBDIR}
SMNTPT=${SMNTPT}
CRYPTO=''
expBOOTDRV=${expBOOTDRV}	#" > /tmp/shutdownconfig_results

I suspect it is intended to pass back information to rc.shutdown and others, but is disabled, for some unknown reason. Without the echo and file, those variables are set for the current execution, with possibly unintended consequences, whereas the original intent appears to be to pass them to the caller without affecting their local settings.

Here is how rc.shutdown uses that file:

Code: Select all

 if [ ! -f /tmp/shutdownconfig_results ];then
  shutdownconfig
 fi
 if [ -s /tmp/shutdownconfig_results ];then
. /tmp/shutdownconfig_results #supplies variables PUPMODE SAVEFS PUPSAVE SAVEPART SAVEFILE NAMEONLY SAVEPATH MYPASSWORD SFEXT
  rm -f /tmp/shutdownconfig_results #precaution.
 fi

[rerwin]

OK, got more info. I see that the debug code above does not appear to have any bad consequences. It just wasted my time checking the suspicious-looking code.

I dug deeper into the "not saved" issue and found that I am wrong about the free-space explanation for failure to save. I traced the activities of shutdownconfig and found that it is misled by the way I boot the PC having the problem (not the one that has sufficient space).

I always boot from a CD but rely on matching puppy main files on hard-drive. Three partitions are available for pupsave files, FS types ntfs, vfat and ext2. For this command:

Code: Select all

PARTSLIST="`probepart -m 2> /dev/null | grep '^/dev/' | grep "$expBOOTDRV" | grep -E 'f2fs|ext2|ext3|ext4|reiserfs|msdos|vfat|minix|ntfs|btrfs' | cut -f 1-3 -d '|' | sed -e 's/msdos/vfat/g'`"

$expBOOTDRV is "/dev/sr". Its file system type is iso9660, so is disqualified as a target partition. The hard drive partitions are ignored, including the one containing the puppy main file being used!

Shouldn't there be further searching for a place to put the pupsave file, as has always been done?

This explains why there has been no report of the problem, because it requires my type of boot arrangement, which is necessary to avoid adding dual booting to a Vista PC. But it appears to be more complicated than I suspected.

Where do we go from here, to fix it?
Richard

[LazY Puppy]

Hi.

I have a general question regarding building Puppy from Woof/WoofCE.

If you finished a first version and published it how is that to be continued when users gave information about bugs and issues of the first build?

Do you again a Woof/WoofCE build or is any further fixed version just a remaster after the first build?

Thanks.

[mavrothal]

Where do we go from here, to fix it?
Richard

Good catch Richard.
Indeed the presence of a subdir with the puppy files trips the logic.
Assuming that you indeed you have a folder with the sfs and (older) savefiles check this patch to see if it fixes it.

Code: Select all

--- a/usr/sbin/shutdownconfig	2015-01-11 17:05:26.000000000 +0800
+++ b/usr/sbin/shutdownconfig	2015-03-29 04:45:53.143279555 +0800
@@ -136,7 +136,7 @@
   expBOOTDRV="/dev/`echo ${PDEV1} | sed -e 's%[0-9]*$%%'`"
   PCHOOSE="yes"
  fi
- if [ "$xPSUBDIR" ];then #if pup installed in a sub-directory, allow save-file in another partition (in same drive)...
+ if [ "$xPSUBDIR" -a "$PMEDIA" != "cd" ];then #if pup installed in a sub-directory, allow save-file in another partition (in same drive)...
   expBOOTDRV="/dev/`echo ${PDEV1} | sed -e 's%[0-9]*$%%'`"
   PCHOOSE="yes"
  fi

(now in woof-CE)

[Hesse James]

Hello
I just found out that the used JWM-976 cannot display additional vertical trays correctly like:

<Tray autohide="true" border="0" y="40" halign="left" width="100" layout="vertical">

A switch back to JWM-905 from Slacko solved this issue.
Have a nice day.

Christian

[rerwin]

mavrothal,
Thank you for the fix. It restores the capability to save from a boot from CD with the main file already on hard drive.

Somewhat related to this, in that it involves rebooting the first time with the new pupsave file, is the apparent inability to retain the selection of the VESA video driver. To recover from booting with pfix=ram (or pupsave number 0) to a blank screen that gradually becomes lighter, I have to ctrl-alt-bksp and run xorgwizard to select "vesa" and then enter "xwin".

When I reboot the the newly created pupsave file, I have to repeat that sequence, suggesting that my previous selection of vesa was not retained in the new pupsave. Not a showstopper, but maybe something easy to fix by someone knowledgeable of the video stuff.
Richard

[mavrothal]

Somewhat related to this, in that it involves rebooting the first time with the new pupsave file, is the apparent inability to retain the selection of the VESA video driver.

I can not reproduce that in tahr. Is it with both savefile and savefolder?
If you boot another puppy in the same machine, how the /etc/X11/xorg.conf looks in the newly created savefile/folder?

[rerwin]

mavrothal,
Thanks for the quick response. After posting it, I remembered that my test is on my updated test version of lupu 5.2.8.7, not tahrpup. I do not have the video problem with tahrpup, so canot reproduce it myself, either.

I should not have mentioned it here, since the problem is probably in the lupu version of rc.shutdown, which is much different that tahr's.

But thanks for the suggestion, so I can pursue it on my own.

I tested your fix on tahrpup, too, with the same positive result.
R

A few minutes later: The new pupsave file is empty except for an empty "lost+found" directory, which explains why I have to re-do the vesa selection. As that pertains only to the special luci version of the save-to-directory upgrade, I will take any discussion of this problem over to the lupu 5.2.8.7 thread.
R

[mavrothal]

A few minutes later: The new pupsave file is empty except for an empty "lost+found" directory, which explains why I have to re-do the vesa selection. As that pertains only to the special luci version of the save-to-directory upgrade, I will take any discussion of this problem over to the lupu 5.2.8.7 thread.
R

Are you using the Luci_SaveDir-6.pet as base or something else?

[rerwin]

Yes, Luci_SaveDir-6.pet. I am taking its content (and that of the tarball, but not the savefolder creation code) as the base of my integrated update to 5.2.8.7. I need to update it for the 20141203 release and merge a petget script with that of the "petget rewrite" package. All of that will go into my "zz_...update" package that makes the puppy basic infrastructure changes.

One thing I am adding that you did not (although the history comment is there) is the inclusion of whiteout files in the new pupsave. That would seem to be appropriate for woof-CE -- but I have just not gotten around to submitting it, among other fixes to lupu that might port to woof-CE. The patch to rc.shutdown for lupu is:

Code: Select all

--- rc.shutdown-lucisavedir	2015-03-29 17:00:36.080211101 -0400
+++ rc.shutdown	2015-03-29 12:55:23.000000000 -0400
@@ -52,6 +52,7 @@
 #111208 rerwin: add user flash-drive save-control option
 #120103 karl godt: error unmounting stray partitions. 120103 karl godt: more tweaks.
 #120220 unmount network shares before taking down the network
+#120408 Retain deletions by copying whiteout files.
 
 clear
 exec 1> /dev/null 2>&1
@@ -417,7 +418,11 @@
     touch "/tmp/save1stpup/${BASENAME}" --reference="$ONEDIR"
    fi
    cp -a $ONEDIR/* /tmp/save1stpup/${BASENAME}/ #v2.16exp3
-   [ "$BASENAME" = "root" ] && cp -a $ONEDIR/.[0-9a-zA-Z]* /tmp/save1stpup/${BASENAME}/ #v2.16exp4
+   if [ "$BASENAME" = "root" ];then #120408...
+    cp -a $ONEDIR/.[0-9a-zA-Z]* /tmp/save1stpup/${BASENAME}/ #v2.16exp4
+   else
+    cp -a $ONEDIR/.wh.* /tmp/save1stpup/${BASENAME}/
+   fi #120408 end
   done
   sync
   [ -L /tmp/save1stpup ] || umount /tmp/save1stpup

That should fit easily into the mainstream version of rc.shutdown.
R

Two hours later: I reran my conversion of the content of Luci_SaveDir-6 plus the "cd" fix, with the result that the new pupsave does contain the appropriate directories. So, I need to fix my original version. Sorry for the false alarm.
Richard

[666philb]

Here is a bug with a solution fix.

Problem with Bulgarian keyboard layout variant
Subject description: Keyboard layout variant resets after reboot
http://www.murga-linux.com/puppy/viewtopic.php?t=98251

thanks ...i've added the fix .... hope it doesn't break anything