tahrpup64 6.0.5 CE

[Billtoo]

I did a new manual frugal installation to a 32gb usb-3.0 flash drive to
use on my HP desktop.
I found that some pets that I made for Wary64 work in tahrpup64 beta so
it's April-64/Wary-64 + many applications available in PPM, not bad

[watchdog]

Here is a patch

Code: Select all

--- init.orig	2015-08-25
+++ init	2015-09-09
@@ -585,12 +585,12 @@
     echo -e "\\033[1;36m" >/dev/console #aqua-blue
     echo -n "Password: " >/dev/console
     echo -en "\\033[0;39m" >/dev/console
-    if [ "$CRYPTO" = "-e aes" ];then #v3.98
-     read -s MYPASS
+    read -s MYPASS #< /dev/console v403
+    if [ "$CRYPTO" = "-e aes" ];then #v3.98     
      echo "$MYPASS" | losetup -p 0 -e aes /dev/loop1 /mnt/dev_save$PUPSAVEFILE
     else
      #losetup does not accept -p param for xor encryption... may not work...
-     losetup $CRYPTO /dev/loop1 /mnt/dev_save$PUPSAVEFILE
+     echo "$MYPASS" | losetup -p 0 $CRYPTO /dev/loop1 /mnt/dev_save$PUPSAVEFILE
     fi
 }
 

This patch also works with the 32bit Tahr 6.0.3
The -p argument may fail with older pupps and busybox versions so if anybody could test and report would be nice.

I did a fast test with wary 5.5. The wary init script is a previous version and so I don't know if your patch can apply. I don't know how to apply a patch What I did is to try the following code with my original patch:

Code: Select all

#v3.01 will take this out as a func later (similar code below)...
    #about to mount ${DISTRO_FILE_PREFIX}save.2fs, but before that check if need to resize it...
    if [ -f /mnt/dev_save/pupsaveresize.txt ];then #created by /usr/sbin/resizepfile.sh
     KILOBIG=`cat /mnt/dev_save/pupsaveresize.txt`
     rm -f /mnt/dev_save/pupsaveresize.txt
     echo > /dev/console
     echo -n "Increasing $PUPSAVEFILE by $KILOBIG Kbytes, please wait..." >/dev/console
     dd if=/dev/zero bs=1024 count=$KILOBIG >> /mnt/dev_save$PUPSAVEFILE
     sync
     if [ "$CRYPTO" = "-e aes" ];then #v3.98
      echo "NOTICE: As you type your password nothing will be displayed on the screen."  >/dev/console
      echo "This is a security measure. Just type it in then press ENTER key..." >/dev/console
      echo -e "\\033[1;36m" >/dev/console #aqua-blue
      echo -n "Password: " >/dev/console
      echo -en "\\033[0;39m" >/dev/console
      read -s MYPASS #< /dev/console v403
      echo "$MYPASS" | losetup -p 0 -e aes /dev/loop1 /mnt/dev_save$PUPSAVEFILE
     else
      echo -e "\\033[1;36m" >/dev/console #aqua-blue
      echo -n "Password: " >/dev/console
      echo -en "\\033[0;39m" >/dev/console
      #losetup does not accept -p param for xor encryption... may not work...
      read -s MYPASS #< /dev/console v403
      echo "$MYPASS" | losetup -p 0 -E 1 /dev/loop1 /mnt/dev_save$PUPSAVEFILE

(last two lines changed in two recurrences) It works with my old lightencrypted savefiles.

[gyro]

@666philb,

Thanks for 6.0.3.5, it seems a lot better than the previous version.

Just one thing:
It contains SFS-Load v2.0.8, could this be updated to at least v2.3, please?
The old SFS-Load contains an old bug we found with 32 bit Tahrpup; it is too aggressive in removing ".wh." files.
If "Startup Manager" is used to disable some "Startup Apps", after loading and unloading an SFS with SFS-Load, they reappear in both columns in the "Startup Apps" screen, because the ".wh." files in "/root/.config/autostart/" have been deleted.

gyro

[gyro]

Decided to just give it a go.
Installed the SFS-Load v2.3 pet, and it seems to work fine.
Successfully loaded and unloaded "devx_tahr64_6.0.3.5.sfs".
No more problem with ".wh." files.

gyro

[666philb]

that sfsload accidently crept in

i was thinking of adding ASRIs initrd and sfsload.... http://woof-ce.26403.n7.nabble.com/Allo ... td786.html so we can use more sfs files. maybe not 100 but say 40 like lighthouse

[Billtoo]

I moved my flash drive once again to a pc with an ati graphics card.
With an earlier installation I was unable to compile the proprietary
ati driver but this time I loaded the devx and kernel sources sfs when
prompted after rebooting to create a save file instead of using sfs
load-on-the-fly.

Display
Resolution 3840x1080 pixels
OpenGL Renderer AMD Radeon HD 5570
X11 Vendor The X.Org Foundation

Monitors
Monitor 0 1920x1080 pixels
Monitor 1 1920x1080 pixels

OpenGL
Vendor Advanced Micro Devices, Inc.
Renderer AMD Radeon HD 5570
Version 4.5.13397 Compatibility Profile Context 15.20.1046
Direct Rendering Y_es

[ETP]

Hi 666philb,

Tahr 64 6.03.5 is looking very good and I hope when finalised that it becomes the next official Pup.
It is swift and a pleasure to use.

One very minor issue:

In tahrpup and tahr64 there is an error that causes the FirewallState icon to fail to restart.
It caused by an error in /usr/share/applications/firewallstate.desktop.
The executable line is Exec=/usr/local/firewallstate/firewallstaterestart, but should be Exec=/usr/local/firewallstate/firewallstaterun.

One probably silly question:

What is the purpose in Startup of the "disabled" folder containing a symlink back to Startup?

[gcmartin]

Instantaneous file-folder search results would really be enabled if some of the following is included in the base, OOTB

Code: Select all

root# locate
bash: locate: command not found
root# slocate
bash: slocate: command not found
root# updatedb
bash: updatedb: command not found
root# 

Then command-line, @Musher0's, or @Stemsee's utilities enabling instantaneous results would work for any searches with no penalty in system's performance when used to find files.

Please evaluate its benefit to both developers and users.

[musher0]

Hi, gcmartin.

Thanks for mentioning my slocate wrapper script.

Indeed, after slocate has updated its db (which takes only a few seconds every 2-3 hours
[you can specify the delay]), the results of your search are displayed almost instantly.

BFN.

musher0

[gyro]

@666philb,

The following patch to "rc.shutdow" seems to be missing:

Code: Select all

--- rc.shutdown.orig	2015-09-06 23:44:07.453319000 +1000
+++ rc.shutdown	2015-09-07 00:36:12.458990092 +1000
@@ -676,8 +676,12 @@
    sync
   fi
  fi
- busybox mount -t $SAVEFS -o remount,ro $SAVEDEV /initrd${SAVE_LAYER} 2>/dev/null
- umount-FULL -i -n -l /initrd${SAVE_LAYER} 2>/dev/null #-l is lazy unmount.
+ if [ "$SAVEDEV" ]; then
+  busybox mount -t $SAVEFS -o remount,ro $SAVEDEV /initrd${SAVE_LAYER} 2>/dev/null
+  umount-FULL -i -n -l /initrd${SAVE_LAYER} 2>/dev/null #-l is lazy unmount.
+ else
+  [ -L "/initrd${SAVE_LAYER}" ] && rm "/initrd${SAVE_LAYER}"
+ fi
 fi
 
 #v2.16 try one more thing for ntfs... lazy unmount, suggested by GuestToo...

Without it, if a savefolder is used in pupmode=12, and then the boot is changed to pupmode=13, puppy gets confused during the pupmode=13 boot process because both "pup_rw" and "pup_ro1" are symlinks to the save_layer.
The patch causes the "pup_rw" link to be deleted on shutdown.
Also the "mount" statements are simply useless if save_layer is a link.

gyro

[gyro]

@666philb,

I meant to say earlier, that I appreciate the inclusion of "fstrim" in busybox.
My current computer has all software installed on an SSD.

gyro

[666philb]

The chromium64 sfs is built to install into /usr/lib64.

It works fine on Slacko64 and also on TahrPup64-6.0.2

TahrPup64-6.0.3.5 implements /usr/lib64 as a link to /usr/lib and this seems to cause a problem with loading sfs's that try to install into /usr/lib64 - i.e. they don't

Does the sfs loading mechanism need to be "adjusted" to take account of this system architecture and its associated problem??

Cheers
peebee

hi peebee,

yes at the moment lib64 is a link to lib and causes problems with some .sfs packages ... same as the i386-linux-gnu folder in /lib & /usr/lib in precise & tahr.

at the moment i'm just getting all the packages and build system nailed down so it all works, but eventually if we want to have 32bit compatibility the /lib64 , /lib/ i386-linux-gnu , /lib/x86_64-linux-gnu & the same folders in /usr may have to be actual folders instead of symlinks.

this will require some hacking of woof and probably some help

i'll be happy when i get steam (which is 32bit) running 64bit games on tahrpup64

[666philb]

@666philb

Gcc 4.9 is in the PPM ...

I just took devx_tahr64_6.0.3.5.sfs and think it would be good to directly update it.

wbar says it's missing a font

In thar32, it readily works

More problematic are missing browser support, see
https://www.youtube.com/html5

you can select the font in wbars options

testing gcc-4.8 in the build now

browser support won't be included OTB but will be able to be enabled by installing some gstreamer stuff in the next iso (coming soon)

[666philb]

Hi

I did install xxxterm

hi oui,

i would ask on xonbrero forum (if there is one) or file a bug report

[666philb]

Hi 666philb,

Tahr 64 6.03.5 is looking very good and I hope when finalised that it becomes the next official Pup.
It is swift and a pleasure to use.

One very minor issue:

In tahrpup and tahr64 there is an error that causes the FirewallState icon to fail to restart.
It caused by an error in /usr/share/applications/firewallstate.desktop.
The executable line is Exec=/usr/local/firewallstate/firewallstaterestart, but should be Exec=/usr/local/firewallstate/firewallstaterun.

One probably silly question:

What is the purpose in Startup of the "disabled" folder containing a symlink back to Startup?

thanks ... firewallstate package updated for next build

the /root/Startup/disabled folder with link back was in the old 32bit lighthouse pup and is just for easy disabling and enabling startup items.

[666philb]

Instantaneous file-folder search results would really be enabled if some of the following is included in the base, OOTB

Code: Select all

root# locate
bash: locate: command not found
root# slocate
bash: slocate: command not found
root# updatedb
bash: updatedb: command not found
root# 

Then command-line, @Musher0's, or @Stemsee's utilities enabling instantaneous results would work for any searches with no penalty in system's performance when used to find files.

Please evaluate its benefit to both developers and users.

cheers ...added musher0's slocate wrapper to next iso

[666philb]

@666philb,

The following patch to "rc.shutdow" seems to be missing:

Code: Select all

--- rc.shutdown.orig	2015-09-06 23:44:07.453319000 +1000
+++ rc.shutdown	2015-09-07 00:36:12.458990092 +1000
@@ -676,8 +676,12 @@
    sync
   fi
  fi
- busybox mount -t $SAVEFS -o remount,ro $SAVEDEV /initrd${SAVE_LAYER} 2>/dev/null
- umount-FULL -i -n -l /initrd${SAVE_LAYER} 2>/dev/null #-l is lazy unmount.
+ if [ "$SAVEDEV" ]; then
+  busybox mount -t $SAVEFS -o remount,ro $SAVEDEV /initrd${SAVE_LAYER} 2>/dev/null
+  umount-FULL -i -n -l /initrd${SAVE_LAYER} 2>/dev/null #-l is lazy unmount.
+ else
+  [ -L "/initrd${SAVE_LAYER}" ] && rm "/initrd${SAVE_LAYER}"
+ fi
 fi
 
 #v2.16 try one more thing for ntfs... lazy unmount, suggested by GuestToo...

Without it, if a savefolder is used in pupmode=12, and then the boot is changed to pupmode=13, puppy gets confused during the pupmode=13 boot process because both "pup_rw" and "pup_ro1" are symlinks to the save_layer.
The patch causes the "pup_rw" link to be deleted on shutdown.
Also the "mount" statements are simply useless if save_layer is a link.

gyro

thanks .... old tahr32 version was sneaking in.
now with woof current

[gyro]

Soon became tired of ROX-Filer clobbering without asking, so see this topic for PCManFm compiled on Tahrpup64. http://www.murga-linux.com/puppy/viewtopic.php?t=101006

gyro

[mikeslr]

Hi All,

Is there any easy way to obtain a 32-bit compatibility pet or SFS for Tahrpup64. If tried all the Slacko64 and Fatdog64 SFSes, which aren't effective.

It's great to have 64-bit operating systems. But currently, especially in the Video editing area, applications are slim to none.

mikesLr

[666philb]

new iso uploaded ... tahrpup64-6.0.3.7

libs mismatch hopefully fixed, roxfiler fixed & lots of packaged have been compiled in tahrpup...as opposed to pinching them from slacko64 and appril (still a load pinched though).

added latest pburn & ffmpeg, slocate, getjava from fatdog, mydbox installer, gnugcc gcc switcher, new retrovol, geany pastebin plugin & splitwindow active, deadbeef album art, ASRI's init to allow loading more than 6 sfs ( i set it at 30 but not tested)
plus lots of other bits & bobs.

forgot to fix the jwmrc template errors will do in the next build.
mtpaint help link missing.
wallpaper selector needs devx or open /usr/bin/wallpaper & wallslide in geany and change #!/bin/dash to !/bin/sh

link on first page