Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 28 Aug 2016, 02:57
All times are UTC - 4
 Forum index » House Training » Bugs ( Submit bugs )
How do we test a Puppy or distro?
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 2 [18 Posts]   Goto page: 1, 2 Next
Author Message
musher0


Joined: 04 Jan 2009
Posts: 8432
Location: Gatineau (Qc), Canada

PostPosted: Mon 11 Nov 2013, 00:08    Post subject:  How do we test a Puppy or distro?
Subject description: Enabling ordinary users with simple tests and checklists
 

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/homepage/resources/checklist_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

_________________
musher0
~~~~~~~~~~
"The greatest of minds are the ones that never close." | "Les plus grands esprits sont ceux qui ne se ferment jamais."
(starhawk, Resident Philosopher | philosophe en résidence) Wink

Last edited by musher0 on Sat 16 Nov 2013, 16:37; edited 3 times in total
Back to top
View user's profile Send private message Visit poster's website 
Flash
Official Dog Handler


Joined: 04 May 2005
Posts: 12056
Location: Arizona USA

PostPosted: Mon 11 Nov 2013, 01:05    Post subject:  

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. Razz

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.
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 8432
Location: Gatineau (Qc), Canada

PostPosted: Fri 15 Nov 2013, 12:10    Post subject:  

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

_________________
musher0
~~~~~~~~~~
"The greatest of minds are the ones that never close." | "Les plus grands esprits sont ceux qui ne se ferment jamais."
(starhawk, Resident Philosopher | philosophe en résidence) Wink

Last edited by musher0 on Sun 17 Nov 2013, 15:00; edited 2 times in total
Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2532

PostPosted: Fri 15 Nov 2013, 12:31    Post subject:  

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.
Back to top
View user's profile Send private message 
gcmartin


Joined: 14 Oct 2005
Posts: 6609
Location: Earth

PostPosted: Fri 15 Nov 2013, 15:32    Post subject: A Puppy testbed  

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.

_________________
Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engines or use DogPile
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2532

PostPosted: Fri 15 Nov 2013, 16:54    Post subject:  

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:
#!/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'
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 8432
Location: Gatineau (Qc), Canada

PostPosted: Fri 15 Nov 2013, 17:02    Post subject:  

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
~~~~~~~~~~
"The greatest of minds are the ones that never close." | "Les plus grands esprits sont ceux qui ne se ferment jamais."
(starhawk, Resident Philosopher | philosophe en résidence) Wink
Back to top
View user's profile Send private message Visit poster's website 
musher0


Joined: 04 Jan 2009
Posts: 8432
Location: Gatineau (Qc), Canada

PostPosted: Fri 15 Nov 2013, 17:13    Post subject:  

Hi, amigo.

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

Thanks, and BFN.

musher0

_________________
musher0
~~~~~~~~~~
"The greatest of minds are the ones that never close." | "Les plus grands esprits sont ceux qui ne se ferment jamais."
(starhawk, Resident Philosopher | philosophe en résidence) Wink
Back to top
View user's profile Send private message Visit poster's website 
musher0


Joined: 04 Jan 2009
Posts: 8432
Location: Gatineau (Qc), Canada

PostPosted: Sat 16 Nov 2013, 15:07    Post subject:
Subject description: Checking links per folder.
 

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! Rolling Eyes
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:
#!/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
example-run.jpg
 Description   
 Filesize   46.08 KB
 Viewed   356 Time(s)

example-run.jpg


_________________
musher0
~~~~~~~~~~
"The greatest of minds are the ones that never close." | "Les plus grands esprits sont ceux qui ne se ferment jamais."
(starhawk, Resident Philosopher | philosophe en résidence) Wink

Last edited by musher0 on Sun 17 Nov 2013, 15:07; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
musher0


Joined: 04 Jan 2009
Posts: 8432
Location: Gatineau (Qc), Canada

PostPosted: Sat 16 Nov 2013, 16:31    Post subject:
Subject description: Check consistency between chosen keyboard type and
 

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:
#!/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
~~~~~~~~~~
"The greatest of minds are the ones that never close." | "Les plus grands esprits sont ceux qui ne se ferment jamais."
(starhawk, Resident Philosopher | philosophe en résidence) Wink

Last edited by musher0 on Sun 17 Nov 2013, 15:11; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
musher0


Joined: 04 Jan 2009
Posts: 8432
Location: Gatineau (Qc), Canada

PostPosted: Sat 16 Nov 2013, 21:46    Post subject:  

Hello again,people! Smile

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/desktop-file-utils_0.15-1ubuntu3_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.)
valide-desktop.sh.tar.bz2
Description 
bz2

 Download 
Filename  valide-desktop.sh.tar.bz2 
Filesize  1.12 KB 
Downloaded  196 Time(s) 
example-run(1).jpg
 Description   
 Filesize   42.71 KB
 Viewed   312 Time(s)

example-run(1).jpg


_________________
musher0
~~~~~~~~~~
"The greatest of minds are the ones that never close." | "Les plus grands esprits sont ceux qui ne se ferment jamais."
(starhawk, Resident Philosopher | philosophe en résidence) Wink

Last edited by musher0 on Sun 17 Nov 2013, 07:47; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
musher0


Joined: 04 Jan 2009
Posts: 8432
Location: Gatineau (Qc), Canada

PostPosted: Sat 16 Nov 2013, 22:37    Post subject:  

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

_________________
musher0
~~~~~~~~~~
"The greatest of minds are the ones that never close." | "Les plus grands esprits sont ceux qui ne se ferment jamais."
(starhawk, Resident Philosopher | philosophe en résidence) Wink
Back to top
View user's profile Send private message Visit poster's website 
Karl Godt


Joined: 20 Jun 2010
Posts: 4182
Location: Kiel,Germany

PostPosted: Sun 17 Nov 2013, 11:02    Post subject:  

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 ) .
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 8432
Location: Gatineau (Qc), Canada

PostPosted: Mon 18 Nov 2013, 19:31    Post subject:  

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:
ldd-check2.sh /usr/bin/

If you are already in folder /usr/bin, you can use
Code:
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.
ldd-check.zip
Description  Two scripts to view ldd results concerning the executables in one of the "bin" folders in your Puppy.
zip

 Download 
Filename  ldd-check.zip 
Filesize  1.51 KB 
Downloaded  204 Time(s) 
Missing-Libraries.jpg
 Description   This example is from my own very fattened-up wary-5.5. It should NOT be construed as showing missing libraries in the original wary-5.5 Puppy.
 Filesize   44.72 KB
 Viewed   251 Time(s)

Missing-Libraries.jpg


_________________
musher0
~~~~~~~~~~
"The greatest of minds are the ones that never close." | "Les plus grands esprits sont ceux qui ne se ferment jamais."
(starhawk, Resident Philosopher | philosophe en résidence) Wink
Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2532

PostPosted: Tue 19 Nov 2013, 04:50    Post subject:  

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.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 2 [18 Posts]   Goto page: 1, 2 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » Bugs ( Submit bugs )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1260s ][ Queries: 12 (0.0050s) ][ GZIP on ]