Closed dimkr closed 6 months ago
"Doesn't add JwmDesk and PupControl: they seem to conflict with jwm_config and wizardwizard - I don't know where to find the magic glue that makes them work OOTB"
In _F96-CE4 both are offered but only one system can be used at a time and there is a script GUI that changes to the choice made as to which system to use. JWMDesk handles the configuration files differently so to prevent conflict the selector wizard script is used. In _F96-CE4 it is not possible to use both JWM config methods simultaneously, but can be selected as to which one the user wants. Once JWMDesk is selected though it does a conversion of the config files and their locations and going back to the original style is not possible. This is how the Internet connection wizard and the Puppy Linux network connection utilities can co-exist with Connman, by using a selector switch script, and carrying 3-4 different connection tools. Same for JWM config, all of the original ptheme tools and the JWMDesk tools are on board. Lots of redundancy but that was what the audience demanded at the time.
I think this would be a good merge at this time.
Once JWMDesk is selected
In BookwormPup64, it's the default, but I don't see the post-installation script that makes it the default (non-interactively) during the build - maybe because I'm stupid or tired, I don't know. And somehow BookwormPup64 seems to be built without jwm_config (which it conflicts with), although it's auto-included in every woof-CE build, together with ptheme or some bits of ptheme.
BookwormPup64 has this line in its _00build.conf:
../../../fix-dpup
I suspect this magic fix-dpup
script, which we don't have, takes care of these things.
suspect this magic fix-dpup script, which we don't have, takes care of these things.
I think I can get this for us from Radky.
I think this would be a good merge at this time.
Small warning if we proceed with this PR: I didn't review all the changes line by line - only some. Some changes look hacky to me and can be cleaned up (some have whitespace changes), and it won't be easy to ensure that none of them affect other build configurations negatively.
Can we make a branch that can build one without modifying the master branch? Could set up a frugal install and boot on up to see if any glaring problems jump out.
After some up time then merge the commit to the master
Can we make a branch that can build one without modifying the master branch? Could set up a frugal install and boot on up to see if any glaring problems jump out.
Yes, no problem. Just fork this branch and follow https://github.com/puppylinux-woof-CE/woof-CE/wiki/Building-a-Puppy-on-GitHub. That's what I did to test this PR.
@techrockedge To build quickly:
git clone https://github.com/techrockedge/woof-CE
cd woof-CE
git remote add f https://github.com/dimkr/woof-CE
git fetch f bw64
git checkout bw64
git push origin bw64
(Then, you have a copy of this branch in your fork and can build from there)
ran into an error running ./3builddistro
busybox-1.36.1.tar.bz2: OK
busybox-guess_fstype.patch: OK
Building busybox
mount-FULL: /root/Build2/woof-out_x86_64_x86_64_debian_bookworm64/sandbox3/petbuild-rootfs-complete-busybox: wrong fs type, bad option, bad superblock on petbuild, missing codepage or helper program, or other error.
chroot: can't execute 'bash': No such file or directory
umount-FULL: petbuild-rootfs-complete-busybox: not mounted.
rmdir: failed to remove 'petbuild-rootfs-complete-busybox': Directory not empty
ERROR: failed to build busybox
UPDATE: Error fixed. Ran build on a partition root on HDD and looks like the build and assembly are going to complete.
suspect this magic fix-dpup script, which we don't have, takes care of these things.
I think I can get this for us from Radky.
That would be great because we're not far from a reproducible BookwormPup64.
This PR:
This brings stock dpup, as built by unmodified woof-CE, much closer to BookwormPup64 (but not identical).