alternative puppy build system
So previously, I was only syning the petspecs with the meta-data from dpkg. Now I'm also syncing the file lists:
https://github.com/puppylinux-woof-CE/w ... pkg.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:
/builders/deb-build.sh#L405
Which required removing metadata about a package from the status file:
/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:
/builders/deb-build.sh#L666
and the related lines on my configuration script look like:
/woof-distro/x86/tiny_devuan/ascii/basesfs#L208
Code: Select all
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
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: Select all
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
...
Which required removing metadata about a package from the status file:
Code: Select all
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"
}
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: Select all
%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
;;
and the related lines on my configuration script look like:
Code: Select all
%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
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
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
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
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
When you use the command (for the first time):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?).
Code: Select all
pkg --repo-update
This includes the petspecs that are stored in files of the form:
Code: Select all
/root/.packages/*--installed-packages
and it will look for file lists in one of the following forms:
Code: Select all
/root/.packages/"$pkgname_$pkgversion".files
/root/.packages/builtin_files/"$pkgname"
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.
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.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
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: Select all
sort: unrecognized option '--field-separator=-'
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
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:s243a wrote:
Edit: pkg seems to also require "sort" from coreutils.Code: Select all
sort: unrecognized option '--field-separator=-'
Code: Select all
#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"
This postinstall script is for the package puppycore_utils. It contains the following files:
Code: Select all
/bin/df.new
/bin/mount.new
/bin/bs.new
/bin/umount.new
/sbin/losetup.new
Code: Select all
rm "$CHROOT_DIR$ADMIN_DIR/info/${pkgname}.list"
cp "${1}"/files "$CHROOT_DIR$ADMIN_DIR/info/${pkgname}.list"
This code isn't completly tested yet.
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
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..
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]
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
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
@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: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
These scripts could be a pacakge that one could install.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
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.
Thankyouby the way thanks for doing all this
i have been following your posts and reading your code
its awesome
wanderer
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
I already did that a while ago. The puppy base I copied was the rootfs-skeleton of the master branch.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.
/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/w ... itrd-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 [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
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
Also since I'm using the following kernal:
https://distro.ibiblio.org/puppylinux/huge_kernels/
https://distro.ibiblio.org/puppylinux/h ... up.tar.bz2
https://distro.ibiblio.org/puppylinux/h ... z2.md5.txt
https://distro.ibiblio.org/puppylinux/h ... 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:
/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:
/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.
/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.
/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: Select all
#INITRD_CODE="$WOOFCE/woof-code/boot/initrd-tree0"
INITRD_CODE="$WOOFCE/initrd-progs/0initrd"
https://distro.ibiblio.org/puppylinux/huge_kernels/
https://distro.ibiblio.org/puppylinux/h ... up.tar.bz2
https://distro.ibiblio.org/puppylinux/h ... z2.md5.txt
https://distro.ibiblio.org/puppylinux/h ... 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: Select all
> $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
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: Select all
_(){
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
}
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: Select all
[ ! -e "$initrdtmp/bin/bb-create-symlinks" ] && \
cp -f "$WOOFCE/initrd-progs/pkg/busybox_static/bb-create-symlinks" \
"$initrdtmp/bin/bb-create-symlinks"
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 [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
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:
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
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
I have the same problem with the newer boot code. I dumped the debugging output to the screen as follows:
Code: Select all
#[ ! "$LOGLEVEL" ] && exec 1>/tmp/bootinit.log 2>&1 #remove o/p from console. v2.22 loglevel added.
exec 1>/dev/console 2>&1 #s243a
and I'm getting lots of errors of the form
Code: Select all
can't open /dev/tty1: No such file or director
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 [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
So after adding debugging code to /initrd/init I was able to get more troubleshooting info from the console.
I got the errors:
and then a bunch of
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
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.
I got the errors:
Code: Select all
/etc/rc.d/rc.sysinit: line 101: can't open 'etc/DISTRO_SPECS
Code: Select all
can't open /dev/tty1: No such file or directory
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: Select all
%if( %isInstalled eudev %, %devSekeleton %)
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 [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
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
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
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
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.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.
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.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.
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.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).
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.
Thanks for the compliment 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.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 don't think it's impossible and I do think that I'll learn a lot.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.
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 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?
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.
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.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
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 [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
I think the missing device files might be created by the kernal and accessed by mounting devtmpfss243a wrote:...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.
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.
...
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.
https://blog.csdn.net/longwang155069/ar ... s/52757592Devtmpfs lets the kernel create a tmpfs very early at kernel initialization, before any driver core device is registered. Every device with a major/minor will have a device node created in this tmpfs instance. After the rootfs is mounted by the kernel, the populated tmpfs is mounted at /dev. In initramfs, it can be moved to the manually mounted root filesystem before /sbin/init is executed.
The following occurs before the boot scripts look for tty1
Code: Select all
#================================================================
# MAIN
#================================================================
# mount devtmpfs early
mount -t devtmpfs devtmpfs /dev 2>/dev/null
It's possible that I could be missing a dependency for mount (or maybe a kernal module isn't loaded that is needed for tmpfs?).
I also noticed some differences in /etc/fstab. Here is what I have in dpup stretch:
Code: Select all
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
none /dev/pts devpts gid=2,mode=620 0 0
/dev/fd0 /mnt/floppy auto noauto,rw 0 0
Code: Select all
# /etc/fstab
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
devpts /dev/pts devpts defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
Regarding the device files I see that there was a change about a year ago in woof-CE on how they were created in the initrd boot scripts.
** This was done in commit 54ef39153265bc8e032179f188c172d15b5f02f0
Previously these files were created by extracting a tar.gz archive and now it looks like they are created by mounting devtmpfs.
Anyway here are some code exerpts:
/initrd-progs/0initrd/init#L60]
/initrd-progs/0initrd/sbin/usablefs#L7
/0initrd/init#L1417
/0initrd/init#L1426
** This was done in commit 54ef39153265bc8e032179f188c172d15b5f02f0
Previously these files were created by extracting a tar.gz archive and now it looks like they are created by mounting devtmpfs.
Anyway here are some code exerpts:
Code: Select all
/sbin/usablefs # mount: /proc /sys /dev / (proc sysfs devtmpfs rootfs)
Code: Select all
mount -t devtmpfs devtmpfs /dev 2>/dev/null
Code: Select all
cp -a bin sbin etc dev lib locale usr var /pup_new${TMPFS} 2>/dev/null
Code: Select all
umount /sys
umount /dev
umount /proc
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
hi s243a
like wiak has posted
i also am worried about you working too hard
can you just make a simple system
that builds to completion
and then add to it when you get the time
i have been following your posts and code
and i do think that you are breaking new ground
and will accomplish your very ambitious goals
but i am afraid that you will exhaust yourself
remember we just want to have fun
i intend to continue to learn and use the system you are creating
ad infinitum
and i could just build isos
and solicit your opinion as things go along
and develop the system step by step
regards
wanderer
like wiak has posted
i also am worried about you working too hard
can you just make a simple system
that builds to completion
and then add to it when you get the time
i have been following your posts and code
and i do think that you are breaking new ground
and will accomplish your very ambitious goals
but i am afraid that you will exhaust yourself
remember we just want to have fun
i intend to continue to learn and use the system you are creating
ad infinitum
and i could just build isos
and solicit your opinion as things go along
and develop the system step by step
regards
wanderer
hi s243a
i agree (with at least what i think is your opinion)
i think that you doing all this work on woof-next
actually spurs interest and understanding of woof-ce
but i am hoping for something that a non guru can use
once again thanks for all your work
but take it easy we all worry about you
regards
wanderer
i agree (with at least what i think is your opinion)
i think that you doing all this work on woof-next
actually spurs interest and understanding of woof-ce
but i am hoping for something that a non guru can use
once again thanks for all your work
but take it easy we all worry about you
regards
wanderer