How do we test a Puppy or distro?

[musher0]

Hello, all.

It occurred to me that a unified methodology to test a Puppy (or any
distro) would help testers work more efficiently -- and hopefully create
better Puppies.

As well, it might broaden the pool of testers by making testing easier.

Templates and checklists are widely used by text editors (I mean the real
people working in the publishing field who revise actual texts, not the
software!), proof-readers, managing editors and the like.

For example :
http://www.jeanweber.com/newsite/?page_id=59
http://www.editorialmanager.com/homepag ... editor.pdf

Project managers also use similar checklists.

So, the question again:
* Do you know of any existing methodology or checklist to use to
test a Puppy or more generally any distro?. Preferably they should
be easy to use and accessible to a wider audience.

Any lead will be greatly appreciated.

Thanks in advance and best regards.

musher0

[Flash]

I think a checklist is a damn good idea, and before the developers appropriate it I'd like to suggest that it be written from the user's point of view.

Perhaps a list of applications can be the beginning of the checklist. Let's consider what most people use their computer for these days. They're in the cloud a lot, which means they're using a browser much of the time. They watch movies and listen to audio CDs, both of which require a media player. They play games, simple and complex. Some people actually do work with their computers; they'll be using word processors and spreadsheets.

[musher0]

Hi, Flash.

Checking if a number of good applications are present is certainly a good
place to start. Also, checking if a distro offers your language, if you can
use your printer with it, that sort of thing. That's more at the user level.

At the other extreme, I see that mavrothal, pemasu and others have
decided to start a "git-hub" for Puppy -- for community Puppy
development. There is certainly a lot of good methodology involved in
git-hubs, but that approach is generally beyond the abiliity and/or
understanding of the average user.

I mean something in the middle. If the tester looks in the Send_To
directory are any links flagged in red? Do all *.desktop files in
/usr/share/applications have the proper syntax? What kind of menu
does this Puppy have? Does it show all the programs it should?
How does the user check if his/her non-standard keyboard works
as expected in Puppy? I mean this type of questions.

Is there a ready-made check-list -- something with some consensus
around it -- that I can use when developer X asks me to test Puppy Y?

I should have been clearer in the initial post, eh?

Bye for now.

musher0

[amigo]

I think you'd need to develop a framework for testing individual packages -and then use that info plus any distro-wide or installation-wide info to perform checks of a 'finished' product.

However, the scope of the problem is absolutely enormous -with some individual programs requiring hundreds of unit tests.

A more general check like what musher0 describes could still be quite a challenge -you'll probably need some way to take exceptions into account, account for orphaned files and other such actions. If there is no package-specific info available, the exceptions and criteria are gonna be very complicated and usefulness would be limited.

I'd say ,start off small and try to figure out how to check all the options of a single, small console-only program. Once you've got a handle on that, then you'll see how nearly-impossible it would be to design such tests for *any* gui tool. Those sorts of checks need to be done by hords of testers who really know the software and are running the latest testing-branch of the distro.

[gcmartin]

This is a very very good question. This is the kind of thing that Puppy maturity leads us to.

Methodology:
This could be structured, IFF there is concensus to what constitutes a Puppy. There are so many approaches used by PUP distro developers where it leads to an inconsistent mix. Since there is "NO Standard" mix, the ability to build a testbed that would be universal in Puppyland is near impossible.

But, in the interest of what you raise our attention to, it would be nice, if Barry or someone can set forth a platform standard which defines a Puppy as a base implementation. If so, a component, subsystem, system testbed could be constructed which could be used by developers and tester, alike, to make for all PUPs to measure against....not performance measure, rather functionality-stability measure.

If Barry's base is the measure, then constructing a testbed has a good chance for testbed construction. And, anyone wishing to build something called a Puppy would present itself to the scrutiny of the testers using a Puppy Test tool to insure proper activity on each's individual hardware/PC.

Hope this make sense.

[amigo]

I have a script which examines individual package content -either before or after package creation. It can check most any kind of package -including pets. *BUT*, it uses common-sense, traditional criteria which apply everywhere. So, it will throw warnings for every pet I have ever seen! That is to say, there is no such thing as a sane *.pet package -they all break at least one sensible criteria and most will break a dozen of them...

But, the only level to approach the problem is on a package level. There can be no workable consensus as to what constitutes a functionally-compatible whole -not even for a base. There is no getting around package-level accounting for auditing or creating packages. And every single item contained within a release should be part of a package -even if it simply an action taken on installing/de-installing a package.

Just for good-measure, I'll post my 'pkg-check' script if anyone is really interested in achieving such a level of conformity. The problem with pets is that there is no reliable and repeatable way to create packages. That means there is no way to ensure conformity with a package specification, no way to orderly integrate package upgrade/rebuilds/fixes into the scheme.

My src2pkg will build 'pretty good' pets without much work, but the pet package format can't take advantage of *any* of the advanced capabilities of src2pkg -the installer (PPM) would not know what to do with a decent package...

I've been using a self-created package spec for a couple of years now -of course src2pkg knows how to create them -for every package in my distro(well over 1000). Still, with time I have found weaknesses with the package spec, so I am redesigning it from the ground up. Very interesting work -but no place for the timid. The new design will provide an insane amount of info about each package -at a minimum. The most way-out stuff will be optional -keeping a history of package transactions, keeping a very detailed manifest of each package (even with md5sums for every file),
keeping info about dependencies(slackers prefer to struggle even for dependency information)

I've been working out the ideas and specs for the new format for months and still have to test some before nailing it down. Once the specification is established it will be pretty easy to have src2pkg produce packages in the new format -it already creates several kinds of packages. The point is that the package specification has to come first -but the tool to create conforming packages is the most important. Actually managing the packages is much easier than building them -I mean building them with src2pkg -not hand-made. Making them by hand should maybe be so hard that it completely discourages doing so.

The package manager doesn't need *all* the possible information about a package, so it doesn't use the manifests. I'll probably even make the dependency info optional -at the installation level. Packages will still include manifests and depends info, but these may be dis-regarded and discarded at install-time. However, *creating* conformant packages may require that some of the depends info to be kept.

The database is a flat-file & directory structure with database file formats designed for fast search and queries. It takes a big search, for instance, to find out which other installed packages need a certain package, or to find orphaned packages which nothing else needs.

Enough, already! Here's pkg-check:

Code: Select all

#!/bin/bash
# pkg-check
# Copyright 2013-2014 Gilbert Ashley <amigo@ibiblio.org>

# This program checks package content for any unusual conditions,
# It can be run using the name of a compressed package or the name
# of a directory which contains package content. Valid package
# types are slackware-style *.txz, *.rpm or *.deb archives.

# A bunch of neat ideas for the name of this program were given here:
# http://www.linuxquestions.org/questions/slackware-14/help-me-brainstorm-a-name-for-a-program-4175451639/
# Thanks to everyone for their suggestions.

# Version=0.5
# added support for rpm archives using 7z compression
# detect files, dirs or links with spaces in their names

Version=0.6

show_help() {
	echo "${0##*/}: Check for unusual package content"
	echo "Syntax:"
	echo $'\t'"${0##*/} [OPTIONS] file-or-dir-name"
	echo "Options:"
	echo $'\t'"--help		Show this help page."
	echo $'\t'"--version	Show the program version number."
	echo $'\t'"--debug		Preserve temporary ananlysis files."
	echo
	#echo "${0##*/} checks package content and reports any 'unusual' conditions."
	echo "'unusual' package content means:"
	echo $'\t'"any files or directories which are not chowned root:root"
	echo $'\t'"any files or directories which are hidden"
	echo $'\t'"any links contained in the content"
	echo $'\t'"any directories which are not chmodded 755"
	echo $'\t'"any files which are empty"
	echo $'\t'"any scripts or binaries which are not chomdded 755 (unless in documents)"
	echo $'\t'"any 'regular files' which are not chmodded 644"
	echo $'\t'"any unusual locations, such as:/share, /include, /usr/etc, /usr/var,"
	echo $'\t'"    /usr/local, /root or /home"
	echo $'\t'"any static libraries in /lib"
	echo $'\t'"any missing package description file (for Slackware-type packages)"
	echo
	echo "The program output is meant to be informative and notifications"
	echo "should not necessarily be considered as warnings."
	echo "${0##*/} can be used to check Slackware-style *.txz, *.rpm or *.deb"
	echo "package archives or a directory where package content is located."
	exit
}

show_version() {
	echo $Version
	exit
}

is_script_2() {
	local IFS=
	read -r -n 2 CHUNK < $1
	case "$CHUNK" in
		'') return 1 ;;
		\#!) return 0 ;;
		*) return 1 ;;
	esac
}

is_elf() {
	local IFS=
	read -r -n 4 CHUNK < $1
	case "$CHUNK" in
		'') return 1 ;;
		?ELF) return 0 ;;
		*) return 1 ;;
	esac
}

explode_rpm() {
  # this is a cut-down version from the exploderpm script
  # with only the '-x' archive extraction routine
  local pkg o sigsize gz
  pkg=$1
  o=104
  set -- $(od -j $o -N 8 -t u1 -- "$pkg")
  sigsize=$((8 + 16 *
      (256 * (256 * (256 * $2 + $3) + $4) + $5) +
      (256 * (256 * (256 * $6 + $7) + $8) + $9)))
  o=$((o + sigsize + (8 - (sigsize % 8)) % 8 + 8))
  set -- $(od -j $o -N 8 -t u1 -- "$pkg")
  o=$((o + 8 + 16 *
      (256 * (256 * (256 * $2 + $3) + $4) + $5) +
      (256 * (256 * (256 * $6 + $7) + $8) + $9)))
  comp=$(dd if="$pkg" ibs=$o skip=1 count=1 2>/dev/null \
      | dd bs=3 count=1 2> /dev/null)
  gz="$(echo -en '\037\0213')"
  #xz="$(echo -en '\0fd\037\07a\058\05a\000')"
  case "$comp" in
	BZh)      dd if="$pkg" ibs=$o skip=1 2>/dev/null | bunzip2 | cpio --quiet -ivdm ;;
	"$gz"*)   dd if="$pkg" ibs=$o skip=1 2>/dev/null | gunzip | cpio --quiet -ivdm ;;
	"]"*|?"7z"*)     dd if="$pkg" ibs=$o skip=1 2>/dev/null | unxz | cpio --quiet -ivdm ;;
	*)        echo "Unrecognized rpm file: $pkg"; return 1 ;;
  esac
	
  [ $? != 0 ] && return 1
  
  return 0
}

# convert human-readable permissions (rwxr-x-r-x) to octal (0755)
human_to_octal() {
    N=0000
	P=${1}
	[[ "${P}" = r???????? ]] && N=$(( N + 400 ))
    [[ "${P}" = ?w??????? ]] && N=$(( N + 200 ))
    [[ "${P}" = ??x?????? ]] && N=$(( N + 100 ))
	[[ "${P}" = ??s?????? ]] && N=$(( N + 4100 ))
	[[ "${P}" = ??S?????? ]] && N=$(( N + 4000 ))
	
    [[ "${P}" = ???r????? ]] && N=$(( N + 40 ))
    [[ "${P}" = ????w???? ]] && N=$(( N + 20 ))
    [[ "${P}" = ?????x??? ]] && N=$(( N + 10 ))
	[[ "${P}" = ?????s??? ]] && N=$(( N + 2010 ))
	[[ "${P}" = ?????S??? ]] && N=$(( N + 2000 ))
	
    [[ "${P}" = ??????r?? ]] && N=$(( N + 4 ))
    [[ "${P}" = ???????w? ]] && N=$(( N + 2 ))
    [[ "${P}" = ????????x ]] && N=$(( N + 1 ))
	[[ "${P}" = ????????t ]] && N=$(( N + 1001 ))
	[[ "${P}" = ????????T ]] && N=$(( N + 1000 ))
	
    printf %04d $N
	echo
}

# execution starts here
# examine command-line arguments
case $1 in
	'') show_help ;;
esac

while [[ $1 ]] ; do
	case $1 in
		--version) show_version ;;
		--help) show_help ;;
		--debug) DEBUG=1 ; shift ;;
		--slackware) PKG_TYPE=slackware ; shift ;;
		--kiss) PKG_TYPE=kiss ; shift ;;
		--fedora) PKG_TYPE=fedora ; shift ;;
		--suse) PKG_TYPE=suse ; shift ;;
		--debian) PKG_TYPE=debian ; shift ;;
		--puppy) PKG_TYPE=puppy ; shift ;;
		--archlinux) PKG_TYPE=archlinux ; shift ;;
		*)
			if [[ -d $1 ]] ; then
				Workdir=$1
			elif [[ -e $1 ]] ; then 
				Object=$1
			else
				show_help
			fi
			shift
		;;
	esac

done

HERE=$PWD
Temp=/tmp/${0##*/}$$

rm -rf $Temp
mkdir -p $Temp


if [[ -d $Workdir ]] ; then
	cd $Workdir
	tar -cf - . |tar -tv > $Temp/full.list
	case $Workdir in
		/*) WD=$Workdir ;;
		*) WD=.;;
	esac
elif [[ -e $Object ]] ; then
	case $Object in
		/*) OBJECT=$Object ;;
		*) OBJECT=$PWD/$Object ;;
	esac
	case $Object in
		*.txz|*.tar.xz|*.tpkg) TAR_COMP=xz ;;
		*.tgz|*.tar.gz|*.pet) TAR_COMP=gzip ;;
		*.tbz|*.tar.bz2|*.tbz2) TAR_COMP=bzip2 ;;
	esac
	
	if [[ -z $PKG_TYPE ]] ; then
		case $Object in
			*.txz) PKG_TYPE=slackware ;;
			*.tpkg) PKG_TYPE=kiss ;;
			*.pet) PKG_TYPE=puppy ;;
			*.rpm) PKG_TYPE=fedora ;;
			*.deb) PKG_TYPE=debian ;;
			*.pkg.tar.gz) PKG_TYPE=archlinux ;;
		esac
	fi
	
	mkdir -p $Temp/PKG
	cd $Temp/PKG
	WD=$PWD
	case $TAR_COMP in
		xz|gzip|bzip2)
			tar --use-compress-program=$TAR_COMP -xf $OBJECT
			# create a long listing of the archive content
			tar -cf - . |tar -tv > $Temp/full.list
		;;
		*)
			case $Object in
				*.deb)
					ar x $OBJECT &>/dev/null
					rm debian-binary control.tar.?z*
					# unpack and remove the remaining data archive
					tar -xf *.?z*
					rm -f data.tar.?z*
					# create the long listing
					tar -cf - . |tar -tv > $Temp/full.list
				;;
				*.rpm)
					explode_rpm $OBJECT &>/dev/null
					# create the long listing
					tar -cf - . |tar -tv > $Temp/full.list
				;;
				*) echo "Unidentified  object..." ; exit 1 ;;
			esac
		;;
	esac
fi

if [[ ! -s $Temp/full.list ]] ; then
	echo "No files found in: $Workdir"
	exit 1
fi

# Read the long listing from tar -tv from $Temp/full.list
# $1=perms $2=owner/group $3=size $4=date $5=time $6=filename
while read LINE ; do
	set -- $(echo $LINE)
	PERMS=$1
	OWNGRP=$2
	SIZE=$3
	# everything to the right of the 5th field is the file/dir name or link/target 
	FILE=$(shift 5 ; echo "$@")
	#echo FILE="$FILE"
	case "$FILE" in
		'./') continue ;;
		'./'*) FILE="${FILE:2}" ;;
		#*) FILE="${6}" ;;
	esac
	
	# search for spaces in filenames
	LINK= TARGET=
	case "$FILE" in 
		# symlinks have ' -> '
		*' -> '*) LINK="${FILE%%' ->'*}" ; TARGET="${FILE##*\-\> }"
			case "$LINK" in
				*' '*) echo "$FILE" >> $Temp/spaces-in-path.list ;;
				*)	case "$TARGET" in
						*' '*) echo "$FILE" >> $Temp/spaces-in-path.list ;;
					esac
				;;
			esac
		;;
		# hard links have ' link to '
		*' link to '*) LINK="${FILE%%' link to'*}" ; TARGET="${FILE##*'link to' }"
			case "$LINK" in
				*' '*) echo "$FILE" >> $Temp/spaces-in-path.list ;;
				*)	case "$TARGET" in
						*' '*) echo "$FILE" >> $Temp/spaces-in-path.list ;;
					esac
				;;
			esac
		;;
		# otherwise there are spaces in the name
		*' '*) echo "$FILE" >> $Temp/spaces-in-path.list
		;;
	esac
	
	# if the file basename starts with '.' it is hidden
	case "${FILE##*/}" in
		.*) echo "$FILE" >> $Temp/hidden-item.list ;;
		*)
			case "${TARGET##*/}" in
				.*) echo "$FILE" >> $Temp/hidden-item.list ;;
			esac
		;;
	esac
	
	case "$PERMS" in
		l*) echo "$FILE" >> $Temp/symlink.list
		;;
		h*) echo "$FILE" >> $Temp/hard-link.list
		;;
		d*) 
			case "$PERMS" in
				drwxr-xr-x) : ;; # dir is chmod 755
				*) echo "${PERMS:1}" "$FILE" >> $Temp/dir-perm.list
			esac
			case "$OWNGRP" in
				root/root) : ;; # dir belongs to root
				*) echo "$OWNGRP" "$FILE" >> $Temp/dir-owner.list
			esac
			# check for unusual top-level dirs??
		;;
		b*|c*) echo "$FILE" >> $Temp/device-file.list ;; # block or character device files -no comment for now
		-*)
			case "$OWNGRP" in
				root/root) : ;; # file belongs to root:root
				*) echo "$OWNGRP" "$FILE" >> $Temp/file-owner.list ;;
			esac
			#Handle empty files
			case "$SIZE" in
				0) echo "$FILE" >> $Temp/empty-file.list
				;;
			esac
			if $(is_elf "$FILE") || $(is_script_2 "$FILE") ; then
				#echo $6
				case "$PERMS" in
					-rwxr-xr-x) : ;; # file is chmod 755
					# -HMMM -what about 555 (perl scripts)? and scripts in docs
					*) 
						case "$FILE" in
							*'/doc/'*) : ;; #ignore example scripts in docs
							install/*) : ;; #ignore installer scripts
							*)
								echo "${PERMS:1}" "$FILE" >> $Temp/exe-perm.list
							;;
						esac
					;;
				esac
			else
				#echo $6
				case "$PERMS" in
					-rw-r--r--) : ;; # file is chmod 644
					*) echo "${PERMS:1}" "$FILE" >> $Temp/file-perm.list ;;
				esac
				
			fi
		;;
	esac
	case "$FILE" in
		# clearly out-of-place
		run/|share/|include/|root/|home/) echo "$FILE" >> $Temp/location.list ;;
		tmp/|media/|mnt/|proc/|sys/) echo "$FILE" >> $Temp/location.list ;;
		# possibly out-of-place
		usr/etc/|usr/var/|usr/local/) echo "$FILE" >> $Temp/location.list ;;
		boot/|dev/|www/|srv/) echo "$FILE" >> $Temp/location.list ;;
		lib/*.a|lib64/*.a|lib32/*.a) echo "$FILE" >> $Temp/location.list ;;
		# OK top-level
		bin/*|etc/*|lib/*|lib64/*|lib32/*|opt/*|sbin/*|usr/*|var/*) : ;; # all okay
		# otherwise we have an illegal top-level object
		*) echo "$FILE" >> $Temp/location.list ;;
		# boot?
	esac
	
done < $Temp/full.list

# Now examine unpacked content
# if it was a Slackware or KISS package, it should contain a description file
case "$PKG_TYPE" in
	slackware|kiss)
		if [[ -s install/slack-desc ]] || [[ -s install/pkg-desc ]] ; then
			Have_desc=1
		else
			echo -e $'\t'"Package does not include a description file"
		fi
	;;
esac

if [[ -s $Temp/location.list ]] ; then
	echo "Unusual locations:"
	while read LINE ; do
		case $LINE in
			share/*|include/*) echo $'\t'"$LINE"$'\t\t'"Maybe use prefix=/usr, execprefix=/ ??" ;;
			home/*) echo $'\t'"$LINE"$'\t\t'"Somebodies HOME dir??" ;;
			root/*) echo $'\t'"$LINE"$'\t\t'"roots\' HOME dir??" ;;
			usr/etc/*) echo $'\t'"$LINE"$'\t'"Possibly should be --sysconfdir=/etc" ;;
			usr/var/*) echo $'\t'"$LINE"$'\t'"Possibly should be --localstatedir=/var" ;;
			usr/local/*) echo $'\t'"$LINE"$'\t'"Possible faulty install prefix" ;;
			tmp/*|run/*)echo $'\t'"$LINE"$'\t'"Possible faulty installation in temporary directories" ;;
			www/*|srv/*|dev/*|media*/|mnt/*|proc/*|sys/*)
				echo $'\t'"$LINE"$'\t'"Possible faulty installation in system directories" ;;
			lib/*.a|lib64/*.a|lib32/*.a) echo $'\t'"$LINE"$'\t\t'"Static library in toplevel lib directory:" ;;
			# HMMM what about var/tmp
			install/*) :
				case "$PKG_TYPE" in
					slackware|kiss) : ;;
					*) echo $'\t'"$LINE"$'\t'"Possible 'illegal' item in top-level directory" ;;
				esac
			;;
			*) echo $'\t'"$LINE"$'\t'"Possible 'illegal' item in top-level directory" ;;
		esac
	done < $Temp/location.list
fi

if [[ -s $Temp/dir-perm.list ]] ; then
	echo "Directories with unusual permissions:"
	while read PERM FILE ; do
		#Perms=$(stat -c %a $WD/$LINE)
		Perms=$(human_to_octal ${PERM})
		echo -e $'\t'"$Perms"$'\t' "$FILE"
	done < $Temp/dir-perm.list
	echo
fi

if [[ -s $Temp/dir-owner.list ]] ; then
	echo "Directories with unusual owner and/or group:"
	while read OWNGRP DIR ; do
		echo -e $'\t'"$OWNGRP"$'\t' "$DIR"
	done < $Temp/dir-owner.list
	echo
fi

if [[ -s $Temp/exe-perm.list ]] ; then
	echo "Executables with unusual permissions:"
	while read PERM FILE ; do
		Perms=$(human_to_octal $PERM)
		echo -e $'\t'"$Perms"$'\t'"$FILE"
	done < $Temp/exe-perm.list
	echo
fi

if [[ -s $Temp/file-perm.list ]] ; then
	echo "Non-executables with unusual permissions:"
	while read PERM FILE ; do
		Perms=$(human_to_octal $PERM)
		echo -e $'\t'"$Perms"$'\t' "$FILE"
	done < $Temp/file-perm.list
	echo
fi

if [[ -s $Temp/file-owner.list ]] ; then
	echo "Files with unusual owner and/or group:"
	while read OWNGRP FILE ; do
		echo -e $'\t'"$OWNGRP"$'\t' "$FILE"
	done < $Temp/file-owner.list
	echo
fi

if [[ -s $Temp/symlink.list ]] ; then
	echo "Symbolic links:"
	# we could verify these links, but then we'd want to also
	# run any doinst.sh script and check any links created there.
	# leave it for now  -running doinst.sh is iffy anyway.
	while read LINE ; do
		echo -e $'\t'"$LINE"
	done < $Temp/symlink.list
	echo
fi

if [[ -s $Temp/hard-link.list ]] ; then
	echo "Hard links:"
	while read LINE ; do
		echo -e $'\t'"$LINE"
	done < $Temp/hard-link.list
	echo
fi

if [[ -s $Temp/hidden-item.list ]] ; then
	echo "Hidden items:"
	while read LINE ; do
		echo -e $'\t'"$LINE"
	done < $Temp/hidden-item.list
	echo
fi

if [[ -s $Temp/empty-file.list ]] ; then
	echo "Empty files:"
	while read LINE ; do
		echo -e $'\t'"$LINE"
	done < $Temp/empty-file.list
	echo
fi

if [[ -s $Temp/spaces-in-path.list ]] ; then
	echo "Objects with spaces in file name:"
	while read LINE ; do
		echo -e $'\t'"$LINE"
	done < $Temp/spaces-in-path.list
	echo
fi

if [[ -s $Temp/device-file.list ]] ; then
	echo "Special device files:"
	while read LINE ; do
		echo -e $'\t'"$LINE"
	done < $Temp/device-file.list
	echo
fi

if [[ $DEBUG -ne 1 ]] ; then
	cd $HERE
	rm -rf $Temp
fi

You can run-package check like this:
'pkg-check name-of-package-archive'
Or, if checking raw package content (already uncompressed):
'pkg-check name-of-dir-with-package-content'

[musher0]

Thanks amigo and gcmartin.

Both your approaches can be fruitful I think: starting small, going round a small program and working our way up step by step; as well as asking for a more general map of things to check in a Puppy, from BK (obviously, since Puppy is his baby) or failing that from a senior contributor to Puppy.

Or maybe even borrow a list already used in another distro. Generally speaking, a Linux is a Linux, no?

I doubt that I have the skills to be a project manager for such a project, but certainly it is my hope that this thread can act a starting point. And who knows, maybe someone will rise to the task.

We have had in the past some "platitudes" in some Puppies, such as quitting scripts that didn't close said Puppy, or some burning software (for CD/DVD operation of Puppy) that were present in one Puppy and forgotten in the next. Puppy A gets advertised on distrowatch, and the next day, oops, someone finds an oversight. A very sad situation... sad more than embarrassing, in my view.

You often see in the threads of newly published Puppies questions from users such as: I can't connect with device so-and-so, does this Puppy have the driver? Or device Y works only partially with Puppy X, how can I get the full functionality?

I don't know if the following idea has any merit, but perhaps we could collect small items like that and gradually build some sort of simple tick-off list, with context, such as

I am using Puppy Z, my username is so-and-so,
my computer is such-and-such and this is where I ticked on the page.

Work empirically. Leave the broad generalizations for later.

Just a few thoughts thrown out there.

And again, thanks, guys.

BFN.

[musher0]

Hi, amigo.

Just saved your script. Now to find an unsuspecting package to try it on...

Thanks, and BFN.

musher0

[musher0]

Hello, all.

Here's something I just found. I edited it for EN-FR localization and to
add the option to remove invalid links.

Many thanks to the original author, Christian Volker, a centos user from
Ireland, I believe. Full source is mentioned in the script.

This script works per folder, and it's slow, even using ash instead of bash.
That said, slow but sure is ok by me. The idea of checking per folder is
to not break anything. Still, use this script with the utmost caution,
since some links exist by themselves, such as the "options" link in the
~/.wmx folder of the wmx window manager, or in the case of some
devices and inodes, etc. If you are unsure, call rox, open the folder
under examination by the script and double-check that the link
is not essential and really a dud. If really in doubt, do nothing!
Use at your own risk.

I tested this script in the ~/.config/rox.sourceforge.net/OpenWith/ and
the ~ proper folders and it worked fine. (Please see illustration.)

Concerning the localization, if the first two letters of the $LANG language
variable are "fr", the messages will be displayed in French; otherwise the
messages appear in English. Other localizations are easy to do following
the same pattern, and welcome, of course. Any improvements to the
script are welcome as well: I'm just a power user, not a programmer.

Enjoy!

musher0

~~~~~~~~~~~~~~

Code: Select all

#!/bin/ash
# Original ran under bash, not ash. / Original tournait sous bash, pas ash. # musher0
# 
# Source : Christian Volker, Technical Support Engineer,
# Parnell House, Barrack Square, Ballincollig, Co. Cork, Ireland
# http://www.linux-archive.org/centos/43732-locating-broken-links.html
#
# Found Saturday, Nov. 16, 2013, 1:15 p.m. by musher0. /
# Trouvé le samedi 16 nov. 2013 à 13 h 15 par musher0.
####
# The command line parameter would be the directory to search. /
# Le paramètre de la ligne de commande serait le dossier où chercher.
# (Trad. par musher0)
####
# Localized variables added by musher0. / Variables localisées ajoutées par musher0.
BRKN="Broken link"
BRISE="Lien brisé"
NOMOR="There are no more broken links to show in this directory."
PLUSRIEN="Il n'y a plus de liens brisés à afficher dans ce dossier."
if [ ${LANG:0:2} = "fr" ];then
	BR="$BRISE" 
	MSGFNL="$PLUSRIEN"
	else
		BR="$BRKN"
		MSGFNL="$NOMOR"
fi
# End of edit by musher0
#
for i in ` find $1 -type l `; do
# German original: Feststellen, ob der link noch gueltig ist oder nicht.
# Added by musher0:
# Approx. translation: Determines if the link is valid or not.
# Traduction approx. : Détermine si le lien est valide ou non.
# End of edit by musher0
file $i | grep -q broken
   if [ $? -eq 0 ] ; then
	 echo "$BR $i"
# Added by musher0 :
	 rm -i "$i"
# End of edit by musher0
   fi
done
# Added by musher0 :
echo
echo "     > $MSGFNL <"
echo
# End of edit by musher0

[musher0]

Hello, all.

The following script will show you if the keyboard type chosen with the
help of Puppy's Keyboard/Mouse Wizard is really the one active in your
Puppy system.

This check is useful if you have a non-standard keyboard, such as an
MS or a Logiteck keyboard, and you find that some control or optional
keys or buttons are not operating as expected.

Unfortunately, this little script will only tell you if you have a keyboard
type problem, it does not solve it...

BFN.

musher0
~~~~~~~~~~~~~~~

Code: Select all

#!/bin/ash
# $MBINS/CheckKeyboardType.sh
# Purpose : validate a keyboard type
# Objectif : valider un type de clavier
# musher0, 16 nov. 2013; rév. 17 nov. 2013, 14 h 25.
####
clear
echo "     ~~~~~~~~~~"
echo "This script checks that the keyboard type chosen in the Wizard is valid in xorg.conf."
echo "/ Ce script vérifie que le type de clavier choisi est valide dans xorg.conf."
echo "     ~~~~~~~~~~"
echo
grep -B 5 -A 3 XkbLayout /etc/X11/xorg.conf
sleep 2s
echo "     ~~~~~~~~~~"
echo "   Compare(r) with / avec"
echo "     ~~~~~~~~~~"
echo
setxkbmap -print
echo
echo "     ~~~~~~~~~~"
echo "The two types should correspond. /" 
echo "Les deux types devraient correspondre."
echo "     ~~~~~~~~~~"
echo

[musher0]

Hello again,people!

This script is meant to test the general syntax of *.desktop files.
These files are very important since menu builders from a number
of window managers use them to create their menu. "*.desktop" files
are also important because of the localization and mime type, etc.
information they may contain.

~~~~~~~~
(Paragraph edited Sunday, Nov. 17, 7 a.m.)
There are three dependencies:
http://launchpadlibrarian.net/13600299/ ... 3_i386.deb
This ubuntu package must be installed before using the attached script.
Also, awk and replaceit.
~~~~~~~~

The supporting executable having been designed for an ubuntu distro,
this script removes any "errors" not relevant to a Puppy. I suspect that
you, as a tester, will be left with perhaps a dozen *.desktop files to
suggest improvements on. And then, it's still up to you. Use your good
judgment. If the *.desktop file in question does work, IMO, the only
reason why you should perfect it is if the program does not show in the
menu of your window manager. That said, some *.desktop files provided
with packaged applications are really skimpy and/or bare-minimum, and
need some serious fattening-up to be meaningful.

Again, this is the work of power user, not of a programmer. Please be
indulgent, and of course do not hesitate to suggest needed improvements.
Thanks in advance.

The script is commented enough, I think. Please read. If you need more
clarifications, please ask. I'll do my best to explain.

A screen capture of an example run is attached.

BFN.

musher0
~~~~~~~~
(Edit, Sunday, Nov. 17, 7 a.m.: Draft script in "code" panel replaced with
attached archive of revised script.)

[musher0]

I wish we had something like this...
https://wiki.ubuntu.com/ErrorTracker

[Karl Godt]

Interesting approach.

Have not read much of it though .

Lot's of interesting scripts, but I would like the idea to post links to the cutting edge section for each individual script ( after posting scripts there first - each script with it's own topic ) .

[musher0]

Hello, all.

Here are two scripts that process the results given by ldd over the
executables in a "bin" folder in your Puppy.

One lists only the missing libraries, the other lists all the "non-dynamic" 1
libraries. Please see illustration. You would cross-reference the missing
libraries list with the full listing, looking for the expression "not found" in
the latter, to know which executable is missing what.

The attached archive should be unpacked in /root/my-applications/bin.
As usual, to work, the scripts must also be made executable.

Usage is as follows: <script> <folder>. For example,

Code: Select all

ldd-check2.sh /usr/bin/

If you are already in folder /usr/bin, you can use

Code: Select all

ldd-check2.sh .

Dependencies:
* ldd (included in all Puppies);
* the real less executable (found on recent Puppies),
___not the stripped-down busybox version;
* highly suggested: a "Mono" font. These scripts are set to use the
__ Liberation Mono font to display the results. (A DejaVu Mono or
__ similar font will do fine if you edit the "-fnt" parameter in the
__ urxvt line accordingly.)

Use these results wisely. These scripts are provided for information and
detective work only. Never remove or add a Linux library on a whim. If
you do not know what you are doing or what the results will be, refrain
from doing anything.

Again, this is the work of a power user, not of a programmer. Any
constructive comments as to how to improve these scripts are welcome.

Best regards.

musher0

~~~~~~~~~~~~
1 Expression used in the ldd verbose results.

[amigo]

I'm afraid that creating these things with an integrated GUI will make them useless for a developer. When creating or correcting the release of something, you need to be able to do sanity checks and correct them as part of a process which is script driven. Hence, a GUI only gets in the way -in fact scripts for creating/updating/fixing/sanitizing packages or even whole-enchilada objects, should not require any interaction whatsoever.

I know you guys love your GUI's, but keep them separate from the working part of the code. Design the output of the underlying script code so that it provides good input for your GUI. And, keep in mind the great distinction between simply identifying (and reporting) possible errors, and correcting those errors. What I'm saying is that there should be three parts to such programs:
1. routines that find and report possible errors.
2. routines that correct errors -receives input from #1
3. routines which build a GUI to display the output of #1 and #2

As I mentioned before, sanity checks and especially corrections, should be done at the package level, otherwise the fixes get lost the next time around. A system-wide tool for correcting things is not really a good idea -except as a last-ditch repair tool for someone who has accidentally messed things up. Properly, one should get notification of a problem, then fix the problem with that one package -not manually fix it, but fix it in the build script used to create that package. Bump the package release or version number, rebuild the package and upgrade/replace the faulty one in the disk image or whatever is being built(iso, SFS or whatever).

Building a script which checks for certain software being installed, etc, are gonna quickly become large, unwieldy, hard-to-maintain and inflexible. To check a list of software, simply use an external list which can be specified on the command-line. That way you can use the same tool for more than one type of final installation.

[Volhout]

It is a good start to automate testing as much as possible, so a script file to check for missing libraries (dependencies) is perfect. But I recall something like that is already in Puppy (I've seen it in a menu somewhere).

The real test is the "user test". That is something you cannot capture in a script. What do users do? Except for using the distribution as designed, they basically make every fault there is to make, and they combine features that are not intended to be combined.

A good start would be to as developers responsible for specific area's to write down what they do to test validity of their creations (i. e. Zigbert, rcscn51...), put that (for a start) in a extend-able list, and let it grow through time with entries from end other testers.

Some maintenance (responsible person) may be needed.

Regards,

[musher0]

It is a good start to automate testing as much as possible, so a script file to check for missing libraries (dependencies) is perfect. But I recall something like that is already in Puppy (I've seen it in a menu somewhere).(...)

Regards,

Hello, Volhout.

Yes, ldd can be activated from the menu, but it will test only one particular
program. If you test per program, you may get an incomplete picture. My
scripts are designed to give a general picture for the entire distro.

I agree that users will combine all sorts of programs and report all sorts
of errors the dev never thought possible.

Nevertheless, I think it is wiser -- and better for the reputation of the
distro -- to test as thoroughly as possible. Some users will never report
an error, they'll just throw the CD in the trash bin and try another until
they find one that works completely. More importantly, they'll say to
their friends: "Oh, don't use that distro, it has errors." It may be untrue,
perhaps the user is overly clumsy, but (s)he'll say "errors" anyway.

Best regards.

musher0

[musher0]

Hello all.

It's important, I think, to bring this thread back in the mainstream!

BFN.