(OLD) (ARCHIVED) Puppy Linux Discussion Forum Forum Index (OLD) (ARCHIVED) Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info

This forum can also be accessed as http://oldforum.puppylinux.com
It is now read-only and serves only as archives.

Please register over the NEW forum
https://forum.puppylinux.com
and continue your work there. Thank you.

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups    
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 01 Oct 2020, 00:24
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
alternative puppy build system
Moderators: Flash, JohnMurga
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
Page 25 of 30 [439 Posts]   Goto page: Previous 1, 2, 3, ..., 23, 24, 25, 26, 27, 28, 29, 30 Next
Author Message
wanderer

Joined: 20 Oct 2007
Posts: 1119

PostPosted: Sun 26 May 2019, 09:29    Post subject:  

hi s243a

yeah i dont want to distract you
very heavy work
i can follow along by your posts and the code

once again thanks
awesome work

wanderer
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Mon 27 May 2019, 03:59    Post subject:  

So previously, I was only syning the petspecs with the meta-data from dpkg. Now I'm also syncing the file lists:
Code:

    pkg_file_list="$DPKG_ADMIN/$pet_specs_PKG_NAME".list
    if [ $(wc -c <"$pkg_file_list") -gt 4 ] || [ SYNC_DUMMY -eq 1 ]; then
      if [ "$(basename "$PUPPY_ADMIN_LIST")" = builtin_files ]; then
        ln $DPKG_ADMIN/"$pet_specs_PKG_NAME".list "$PUPPY_ADMIN_LIST/$pet_specs_PKG_NAME"
      else
        ln $DPKG_ADMIN/"$pet_specs_PKG_NAME".list \
           "$PUPPY_ADMIN_LIST/$pet_specs_PKG_NAME"_"$pet_specs_VERSION".files
fi

https://github.com/puppylinux-woof-CE/woof-CE/blob/affed614ed77f8293d41e4e6c8911a1cefb890c6/woof-code/rootfs-packages/sync_pet_specs_fm_dpkg/usr/bin/sync_pet_specs_fm_dpkg.sh#L71

I started splitting up both the core of puppylinux

/woof-code/rootfs-packages/puppycore_Xstartup
/woof-code/rootfs-packages/puppycore_i386_strech
/woof-code/rootfs-packages/puppycore_noarch
/woof-code/rootfs-packages/puppycore_sysinit
/woof-next/woof-code/rootfs-packages/puppycore_sysinit_net
/woof-next/woof-code/rootfs-packages/puppycore_users

and the core of tinycore into seperate packages:

woof-next/woof-code/rootfs-packages/tinycore9_base_gz
/woof-code/rootfs-packages/tinycore9_base_gz_device_files
/woof-code/rootfs-packages/tinycore9_base_gz_startup
/woof-code/rootfs-packages/tinycore9_base_gz_users

I added the ability to re-install from a directory:

Code:

install_from_dir() {
   ...
   if [ -z "$4" ] || [ "$4" != "force" ]; then
     is_already_installed $pkgname && return 1
   elif is_already_installed $pkgname; then
     remove_pkg_status "${pkgname}"
   else
     IS_INSTALLED=0
        fi
        ...

/builders/deb-build.sh#L405

Which required removing metadata about a package from the status file:

Code:

remove_pkg_status() {
   pkg_name=$1
   status_new="$CHROOT_DIR$ADMIN_DIR/status.new.$$"
   echo "removing package status"
   while read line; do
     case "$line" in
      'Package: '*)
          set -- "$line"
          if [ "$pkg_name" = "$2" ]; then
            echo_line=0
          else
            echo_line=1
          fi
      ;;
      esac
     if [ $echo_line -eq 1 ]; then
       echo $line >> "$status_new"   
     fi
   done < $CHROOT_DIR$ADMIN_DIR/status
   rm "$CHROOT_DIR$ADMIN_DIR/status"
   mv "$status_new" "$CHROOT_DIR$ADMIN_DIR/status"
}

/builders/deb-build.sh#L349

The ability to re-install packages means I can install the core of a system (aka rootfs-skeleton) at the beginning to set up the environment then at the end of the configuration script to make sure nothing installed over-rode something important.

I did the over-riding by adding a --forced option:

Code:

         %addpkg)
             set -x
            shift # $1-pkgname, pkgname ...
            forced=0
            PKGSECTION="optional"
            while [ "$1" ]; do
               case "$1" in
               --forced)
                 forced=1
                 ;;
               --category=*)
                 PKGSECTION="${1#'--category='}";
                 ;;
               *)
                 ! [ -d $EXTRAPKG_PATH/$1 ] && shift && continue
                 echo Installing extra package "$1"  ...
                 if [ $forced -eq 1 ]; then
                   install_from_dir $EXTRAPKG_PATH/$1 $1 $PKGSECTION force
                 else
                   install_from_dir $EXTRAPKG_PATH/$1 $1 $PKGSECTION
                 fi
                 ;;
               esac
               shift
            done
            set +x
;;

/builders/deb-build.sh#L666

and the related lines on my configuration script look like:

Code:

%addpkg --forced tinycore9_base_gz
%addpkg --forced puppycore_noarch

#%addpkg --forced tinycore9_base_gz_users #Can use instead of puppycore_users
%addpkg --forced puppycore_users

%addpkg --forced puppycore_i386_strech

#Can use tinycore9_base_gz_startup instead of puppycore: _sysinit _sysinit_net _Xstartup
#%addpkg tinycore9_base_gz_startup

%addpkg --forced puppycore_sysinit
%addpkg --forced puppycore_sysinit_net
%addpkg --forced puppycore_Xstartup

%addpkg --forced debian-setup # specific debian setup, overriding puppy-base

#Dependencies for pkg (maybe create wrappers for these instead of installing them)
%reinstall findutils #Dependency of PKG
%reinstall sed       #Dependency of PKG
%reinstall grep      #Dependency of PKG
%reinstall wget #required for pkg

/woof-distro/x86/tiny_devuan/ascii/basesfs#L208

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
wiak

Joined: 11 Dec 2007
Posts: 2075
Location: not Bulgaria

PostPosted: Mon 27 May 2019, 05:21    Post subject:  

I'm just curious if the package manager (sc0ttman's?) has knowledge (keeps track of) any programs included in root-fs skeleton or does it just come into play after that (in your build system)? It would be good, especially for upgrade purposes, if it keeps track of 'every' script and package involved in the build, but maybe it does or maybe that isn't possible the way Puppy is traditionally put together (though I guess anything could be arranged?).

No doubt, a commandline, dependency resolving package manager is the way ahead to improve Puppy, though I realise, and can see from your efforts s243a, that there is a lot of complex work involved even with that now available.

Good to see your determined effort! End result will surely be much better than current woof-CE mechanism.

wiak

_________________
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Mon 27 May 2019, 12:34    Post subject:  

wiak wrote:
I'm just curious if the package manager (sc0ttman's?) has knowledge (keeps track of) any programs included in root-fs skeleton or does it just come into play after that (in your build system)? It would be good, especially for upgrade purposes, if it keeps track of 'every' script and package involved in the build, but maybe it does or maybe that isn't possible the way Puppy is traditionally put together (though I guess anything could be arranged?).

When you use the command (for the first time):
Code:

pkg --repo-update

pkg, will look for files in the /root/.pkgages folder to see what is installed.

This includes the petspecs that are stored in files of the form:
Code:

/root/.packages/*--installed-packages

e.g. "woof-installed-packages"
and it will look for file lists in one of the following forms:
Code:

/root/.packages/"$pkgname_$pkgversion".files
/root/.packages/builtin_files/"$pkgname"


Since the deb-build.sh component of woof-next uses dpkg to build the rootfs, I covert the dpkg meta data into the "puppy package manager" (i.e. petget) equivalent using the function:
sync_pet_specs_fm_dpkg.sh

As for keeping tracking of packages in "root-fs skeleton", woof-next will treat "root-fs skeleton" (aka puppybase) as a complete package. As I noted in my previous post I started breaking up puppies "rootfs skeleton" into seperate packages. The reason to do this is that if we start mixing the core parts of different versions of "linux", then files in the core/base/skeleton (for each version of "linux") might conflict.

Quote:

No doubt, a commandline, dependency resolving package manager is the way ahead to improve Puppy, though I realise, and can see from your efforts s243a, that there is a lot of complex work involved even with that now available.

Good to see your determined effort! End result will surely be much better than current woof-CE mechanism.

wiak


The biggest issue that I have with "pkg" is that it doesn't fail gracefully, if you are missing dependencies: sed, tar, findutils, grep. I think that pkg should detect if you have the full versions and try to use the best busybox equivalent of the command if you are missing the full version.

For instance the devaun repo doesn't like the --spider option if it is both the case that:
1. you are referring to a specific file and,
2. you are using using the busybox version of wget.

Therefore, if you are using the busybox version of wget you should try to download the file rather than testing if it exists with the --spider option. Also if pkg, can't work without a given dependency then it should throw an error rather than going into an infinite loop.

The other thing that might be challenging for some people is to configure a given repo for pkg. Fortunately, there was a puppy version of devaun that I could copy these files from. If these files don't exist then pkg should try to supply fallbacks for these files.

As a final issue with pkg, pkg should match the shortest matching name of a pkg. It doesn't always behave this way.

P.S. package also seems to use the cut command in places where either grep or awk would be faster.

Edit: pkg seems to also require "sort" from coreutils.
Code:

sort: unrecognized option '--field-separator=-'

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Tue 28 May 2019, 04:12    Post subject:  

s243a wrote:


Edit: pkg seems to also require "sort" from coreutils.
Code:

sort: unrecognized option '--field-separator=-'


I think that installing coreutils overwrites /bin/df which is a puppy specific version of df that might be required for startup. The full version (non puppy spedific) has the name df-FULL in puppy linux. There are a few utilities like this on puppylinux. I created a script a post insall script that will rename these files. Here is part of that script:
Code:

       #TODO maybe do a more in depth check before removing this.
       if [ -e "$full_util_dir/$a_util-FULL" ]; then
         rm "$full_util_dir/$a_util-FULL"
       fi
       mv "$full_util_dir/$a_util" "$full_util_dir/$a_util-FULL"
mv "$puppy_util_dir/$a_util.new" "$puppy_util_dir/$a_util"

/woof-code/rootfs-packages/puppycore_utils/pinstall.sh#L48

This postinstall script is for the package puppycore_utils. It contains the following files:
Code:

/bin/df.new
/bin/mount.new
/bin/bs.new
/bin/umount.new
/sbin/losetup.new


The post install script removes the .new suffix after the full version has the "-FULL" fufix added to it. Since the files in the final system differ than in the package, I created a file list for the packge called "files" and I modified the function install_from_dir() in deb-build.sh so that it will use the supplied file list when it exists.

Code:

rm "$CHROOT_DIR$ADMIN_DIR/info/${pkgname}.list"
cp "${1}"/files "$CHROOT_DIR$ADMIN_DIR/info/${pkgname}.list"

/builders/deb-build.sh#L418

This code isn't completly tested yet.

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
sc0ttman


Joined: 16 Sep 2009
Posts: 2806
Location: UK

PostPosted: Tue 28 May 2019, 18:31    Post subject:  

I'm happy to look at any pull requests or diffs (etc) that help remove dependencies in Pkg or make it's installation easier, or whatever other changes/improvements you can think of/need..
_________________
Pkg, mdsh, Woofy, Akita, VLC-GTK, Search
Back to top
View user's profile Send private message 
wanderer

Joined: 20 Oct 2007
Posts: 1119

PostPosted: Tue 28 May 2019, 20:58    Post subject:  

hi s243a

you might check out dcores import-sce (and related scripts)
if you have not already
it downloads debs and makes sces
which are combined sfs files
with the app and its dependencies
in the same sfs file

it resolves a lot of dependency issues
and may be interesting to you
and apply to the work you are doing with woof-next

by the way thanks for doing all this
i have been following your posts and reading your code
its awesome

wanderer
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3475
Location: The Blue Marble

PostPosted: Wed 29 May 2019, 01:38    Post subject:  

@s243a: Before you get too engrossed with "fixing" puppy-base code in woof-next, please remember that code is five (5) years old. A lot has changed since then. I think it would be better if you grab the latest/current puppy-base from Woof-CE proper and work from there.
_________________
Fatdog64 forum links: Latest version | Contributed packages | ISO builder
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Wed 29 May 2019, 02:22    Post subject:  

wanderer wrote:
hi s243a

you might check out dcores import-sce (and related scripts)
if you have not already
it downloads debs and makes sces
which are combined sfs files
with the app and its dependencies
in the same sfs file


it resolves a lot of dependency issues
and may be interesting to you
and apply to the work you are doing with woof-next

These scripts could be a pacakge that one could install.

Related to tinycore though, I would like to use some more tinycore libraries as base libraries (e.g. the tc equivalent of libglib2.0-0 ). Maybe I could do this with tinycores package manager.
Quote:

by the way thanks for doing all this
i have been following your posts and reading your code
its awesome

wanderer


Thankyou Smile

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Wed 29 May 2019, 02:25    Post subject:  

jamesbond wrote:
@s243a: Before you get too engrossed with "fixing" puppy-base code in woof-next, please remember that code is five (5) years old. A lot has changed since then. I think it would be better if you grab the latest/current puppy-base from Woof-CE proper and work from there.


I already did that a while ago. The puppy base I copied was the rootfs-skeleton of the master branch.
/woof-CE/tree/master/woof-code/rootfs-skeleton

Today, I also copied into my woof-next branch the following folder:

https://github.com/puppylinux-woof-CE/woof-CE/tree/master/initrd-progs

I did this because I thought that the lastest woof-CE boot code might be easier to troubleshoot. I made some modifications to get this working which I'll describe shortly.

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Wed 29 May 2019, 03:11    Post subject:  

As I noted above, I copied the more recent boot code from woof-CE
/puppylinux-woof-CE/woof-CE/.../initrd-progs/0initrd/init
/s243a/woof-CE/.../initrd-progs/0initrd/init

To use this newer initrd boot code one must make the following change in build.conf
Code:

#INITRD_CODE="$WOOFCE/woof-code/boot/initrd-tree0"
INITRD_CODE="$WOOFCE/initrd-progs/0initrd"


Also since I'm using the following kernal:
https://distro.ibiblio.org/puppylinux/huge_kernels/
https://distro.ibiblio.org/puppylinux/huge_kernels/huge-4.9.163-lxpup.tar.bz2
https://distro.ibiblio.org/puppylinux/huge_kernels/huge-4.9.163-lxpup.tar.bz2.md5.txt
https://distro.ibiblio.org/puppylinux/huge_kernels/huge-4.9.163-lxpup-readme.txt
***See Previous post.

I also need an fdrv. To get the fdrv to work you must modify the DISTRO_SPEC file that goes into the ISO. On jamesbond's repo this is defined at:
builders/build-iso.sh#L81

I modified it to look like:
Code:

   > $initrdtmp/DISTRO_SPECS cat << EOF
DISTRO_NAME='$SOURCE Puppy'
DISTRO_VERSION='$DISTRO_VERSION'
DISTRO_BINARY_COMPAT='$SOURCE'
DISTRO_FILE_PREFIX='$SOURCE'
DISTRO_COMPAT_VERSION='$SOURCE'
DISTRO_XORG_AUTO='yes'
DISTRO_TARGETARCH='$TARGET_ARCH'
DISTRO_DB_SUBNAME='$SOURCE'
DISTRO_PUPPYSFS=$PUPPY_SFS
$(echo_sfs_drvs)
EOF

/builders/build-iso.sh#L105
Where the "$(echo_sfs_drvs)" at the end of the heardoc inserts info about other sfs files of the type (adrv ydrv zdrv fdrv) into /initrd/DISTRO_SPECS.

The function that inserts this additional info is defined as follows:
Code:

_(){
  eval "echo \"$1\""
}

echo_sfs_drvs(){
  #DISTRO_ZDRVSFS=kernel-modules.sfs
 for A_DRV in F Z Y A; do
  a_drv=$(echo $A_DRV | tr '[:upper:]' '[:lower:]')
  if [ ! -z "$(_ "\$${A_DRV}DRV_SFS")" ]; then
    echo DISTRO_${A_DRV}DRVSFS="$(_ "\$${A_DRV}DRV_SFS")";   
  elif [ -f $ISO_ROOT/"$a_drv"drv_sfs.sfs ]; then
    echo DISTRO_${A_DRV}DRVSFS="$a_drv"drv_sfs.sfs;
  elif [ -f $ISO_ROOT/"$a_drv"drv_"$SFS_SUFIX".sfs ]; then
    echo DISTRO_${A_DRV}DRVSFS="$a_drv"drv_"$SFS_SUFIX".sfs;
  elif [ -f $ISO_ROOT/"$a_drv"drv.sfs ]; then
    echo DISTRO_${A_DRV}DRVSFS="$a_drv"drv.sfs   
  fi
 done
}

/builders/build-iso.sh#L73

Now this code is a bit cryptic. So In words (taking the adrv as an example), first we look to see if the variable ADRV_SFS is defined and if it is that gives the name of the adrv. If not we look to see if there is something in the iso-root folder that looks like the adrv and if there is then we base the petspec on this name.

The final thing that I did here was to copy bb-create-symlinks into the initrd if it doesn't exist.

Code:

[ ! -e "$initrdtmp/bin/bb-create-symlinks" ] && \
  cp -f "$WOOFCE/initrd-progs/pkg/busybox_static/bb-create-symlinks" \
  "$initrdtmp/bin/bb-create-symlinks"

/builders/build-iso.sh#L100

This wasn't an issue with the initrd that woof next original linked to but the latest puppycode doesn't include this file directly in the initrd code and without it the kernal will not be able to find the interpreter for the init script and as a consequence will tell you that init is not found.

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Wed 29 May 2019, 04:09    Post subject:  

On a debugging note, I tried the newer boot code because I started getting stuck on 'switch root'

I have the same problem with the newer boot code. I dumped the debugging output to the screen as follows:

Code:

#[ ! "$LOGLEVEL" ] && exec 1>/tmp/bootinit.log 2>&1 #remove o/p from console. v2.22 loglevel added.
exec 1>/dev/console 2>&1 #s243a

I had to do this because supplying loglevel=3 as a boot paramater didn't work.


and I'm getting lots of errors of the form
Code:

can't open /dev/tty1: No such file or director


I think that I need to copy the device files into initrd. Now to hunt for them.

Edit 1: hmmmmm....I wonder if these are the device files that I was looking for:
/woof-next/woof-arch/woof-code_rootfs-skeleton_DEVDIR.tar.gz

I found these in a previous post.

Edit 2: On another note, there are a lot of packages in:
/woof-CE/tree/testing/initrd-progs/pkg

that I think are for the initrd. I wonder which ones might be needed, which aren't in:

/woof-next/woof-arch/x86/target/boot/initrd-tree0/bin

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Wed 29 May 2019, 14:42    Post subject:  

So after adding debugging code to /initrd/init I was able to get more troubleshooting info from the console.

I got the errors:
Code:

/etc/rc.d/rc.sysinit: line 101: can't open 'etc/DISTRO_SPECS

and then a bunch of
Code:

can't open /dev/tty1: No such file or directory


The first error tells me that we probably suceeded in the switch root. I'm wondering if DISTRO_SPECS was included in one of the puppy base files and I removed it. I think though it would be better if we had a distribution specific version of DISTRO_SPECS rather than using a generic one from "puppycore".

Also if this file is missing then I think (in rc.sysinit) we could copy it from /etc/initrd/DISTRO_SPECS but I need to first verify that the intent of these two files is the same.

I also see that I'm missing device files in the new root (i.e. after the switch root). I think these files can be created by either edev or udev (or did jamesbond include them in puppycore?) but I also think that if neither of these packages are installed then we could copy them from:
/woof-next/woof-arch/woof-code_rootfs-skeleton_DEVDIR.tar.gz

We might be able to extract these into the basesfs and if that doesn't work we could copy the .tar.gz file into intird and then in the init script extract these into the new root if either edev or udev isn't installed.

I most cases we will probably have eudev or udev installed (tinycore being a probable excretion), so we might want to add some functional control structures (e.g. a functional if) to the base sfs configuration file. I'm thinking it might look like this
Code:

%if( %isInstalled eudev %, %devSekeleton %)


and I don't think that simple control strctures like this will be that hard to implement. The advantage here is that we can add and remove things like edev and udev without worrying about breaking the configuration file.

P.S. I'm assuming that we will need only lazy functional logic. If there is a reason for a "non function if", then we could call the functional iff %iff.

Edit: I just checked and I had eudev installed in my base sfs. I'm wondering if I could have avoided this error by starting this service prior to rc.sysinit looking for ttyl1 or alternatively if we need some minimum amount of device files regardless of whether or not we have eudev or udev installed.

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
wiak

Joined: 11 Dec 2007
Posts: 2075
Location: not Bulgaria

PostPosted: Wed 29 May 2019, 18:03    Post subject:  

With great respect s243a, I can't help but wonder from your many posts about your attempted woof-next developments if you have placed yourself in some very deep water? Clearly from what your write there are some great issues/complexities involved, including pkg issues and device files missing and so on. That is the trouble with taking over someone elses complex system many years after it was originally written too I feel. Personally I wouldn't myself try.

My main point is that, you are clearly trying your very best to get a good outcome here and it certainly would be great if you manage, but please don't be afraid to ever throw in the towel if the issues you come across proves to be insurmountable (which can sometimes be the case). It's not worth the stress and effort sometimes and you were doing very well with your 64-bit TazPup dev work and I miss seeing you completing that.

I didn't want to say anything because of course it would be great if woof-next could be resurrected as an alternative Puppy build system, and maybe you are close (I don't know) - just hoping you take stock and make sure you don't tire yourself out on anything that proves impossible.

I am particularly concerned if it is the case that pkg has any issues that prevent your success - any package manager, as you know, is a complex beast and despite pkg being a much-needed kind of commandline driven package manager for Puppy, I don't think it has been given a great deal of community testing as yet (of course you are helping with that). That could prove to be a road-block, for now, that you cannot reasonably pass?

So if you do hit any such roadblock, which it is unreasonable for you to shift yourself, please do not be afraid to freeze your woof-next project if you have to. 64-bit TazPup also beckons and results there were looking very positive.

wiak

_________________
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Wed 29 May 2019, 18:39    Post subject:  

wiak wrote:
With great respect s243a, I can't help but wonder from your many posts about your attempted woof-next developments if you have placed yourself in some very deep water? Clearly from what your write there are some great issues/complexities involved, including pkg issues and device files missing and so on.


Yes but at the same time you can learn a lot by reviewing someone else's code. I also think that woof-next can evolve beyond a distribution builder. I think that it can become a full fledged interpreter that can also be used as a package manager.

Quote:
That is the trouble with taking over someone elses complex system many years after it was originally written too I feel. Personally I wouldn't myself try.


I understand this but I was looking at woof-next because it has fewer lines of code than woof-CE. It also lets me learn about woof-CE because there are components of woof-CE incorporated into woof-Next.

Quote:
My main point is that, you are clearly trying your very best to get a good outcome here and it certainly would be great if you manage, but please don't be afraid to ever throw in the towel if the issues you come across proves to be insurmountable (which can sometimes be the case).

This is a fair comment but I know that woof-next can successfully build a debian or slackware distribution. Therefore, if the goal is only to build slackware and debian based distributions than it isn't that far behind woof-CE...albiet with older code.

Jamesbond claims it can also build fatdog like distributions but i need to see more info on this.

I do question though whether or not woof-next can "as is" build a devaun based distro. It appears from some peoples report that it has but due to some issues that I've encounter, I am somewhat skeptical...the device file issue being the top issue on my the list of why I'm skeptical about whether or not the official woof-next can produce a devaun distro.

P.S. I was actually able to boot into a tinycore like system using woof-next but it wasn't really tinycore. It was puppy calling tinycore's init scripts. I also (regarding devaun builds) got past rc.sysinit to where qemu was looking for plogin...so it is possible that I broke some things along the way but hopefully in the end this will create a better system.

Quote:
It's not worth the stress and effort sometimes and you were doing very well with your 64-bit TazPup dev work and I miss seeing you completing that.

Thanks for the compliment Smile I wasn't aware there was much interest in TazPup64 but I have been using it daily. I do think that TazPup64 is a good project because most newer 64bit puppies (in my opinion) don't preform well on older machines. I do know that this is somewhat of a hardware specific issue because I know that some people do have old hardware that runs newer 64 bit pupps well.

Quote:
I didn't want to say anything because of course it would be great if woof-next could be resurrected as an alternative Puppy build system, and maybe you are close (I don't know) - just hoping you take stock and make sure you don't tire yourself out on anything that proves impossible.


I don't think it's impossible and I do think that I'll learn a lot.

Quote:
I am particularly concerned if it is the case that pkg has any issues that prevent your success - any package manager, as you know, is a complex beast and despite pkg being a much-needed kind of commandline driven package manager for Puppy, I don't think it has been given a great deal of community testing as yet (of course you are helping with that). That could prove to be a road-block, for now, that you cannot reasonably pass?


Woof-Next does have the option of using the native package manager (or even the official puppy package manager). To me this is unsatisfying because in my opinion dpkg/apt complains too much if things aren't perfect and petget doesn't support the command line.

I think that if I create a distro (/derivative distro) that is functional and uses Sc0tmann's pkg as the package manager then this will create interest in the distro and help Sc0tmann's package manger progress.

I don't think that pkg has to work perfectly in the first release of the distro and having something that works well enough will be enough to help spur further development/testing of pkg.

Quote:
So if you do hit any such roadblock, which it is unreasonable for you to shift yourself, please do not be afraid to freeze your woof-next project if you have to. 64-bit TazPup also beckons and results there were looking very positive.

wiak


I'm glad you think so. My intent wasn't to completely freeze TazPup64 but I did want to get woof-next far enough a long so that I could better split my time. On my upstairs floor I have a 64bit computer running TazPup64, on the lower floor I have a 32bit computer running dpup strech. So in theory being able to develop woof-next on the 32 bit computer gives me more development time.

The problem of course is the amount of mental energy that it takes to be able to balance two complex projects becasue some times troubleshooting requires a large mental roadmap of where in the code various things are done and not everyone can do this kind of multitasking.

p.s. 1 I hope that my error reports of either pkg or woof-next don't misrepresent these two systems. As with any system, user error is always a possibility.

That said, sometimes it is essential to use system in the way that the author didn't intend in order for the system to progress.

p.s. 2 Development on woof-next may help me with TazPup64 because both systems use components of woof-CE, so the resulting knowledge gained is likely helpful. Also sometimes scripts developed on one system can be reused on another. Also I may create a config file to build a TazPup64 like system on woof-next. If I do so then there will be more cross-fertilization between what I do on woof-next vs TazPup64.

ps. 3: Some issues that I'm experience might be due to me using a different puppycore (aka rootfs-skeleton) than provided by jamesbond. I'm doing this so that I'm using newer woof-CE code and also because greater modularity is required to make woof-next more flexible in the type of systems that it can build.

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 25 of 30 [439 Posts]   Goto page: Previous 1, 2, 3, ..., 23, 24, 25, 26, 27, 28, 29, 30 Next
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
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.2927s ][ Queries: 13 (0.0747s) ][ GZIP on ]