Released: WDLGO_UbuntuFocal64 mini-apt/dpkg experimental system

[s243a]

This 'report' came quicker than I expected because I have sadly just discovered an incompatibility issue with BionicPups compared to official UbuntuBionic.

Good news is that I have now completed WDLGO_Bionic32 standalone distro. The build script I'm working on that produced this also automatically extracted all components required for a Puppy Bionic dpkg/apt addon (and auto-made two sfs files out of these).

Alas, bad news, had this addon been for FossaPup the dpkg/apt addon sfs files were instantly ready to use. But... to my horror, on going to try them out in the BionicPups I discover to my horror that none of these Bionic-based Puppy distros have adopted Ubuntu-compatible lib and /usr/lib arrangements - i.e. they have arranged these lib directories via symlinks rather than the original Ubuntu way, and are therefore not directly compatible. Hence the sfs files cannot simply be loaded. In particular, the directories /lib/i386-linux-gnu, and /usr/lib/i386-linux-gnu are symlinks in Puppy, whereas in UbuntuBionic official they are actual directories.

I discovered that last night also when trying to upgrade Xenai/Puli with WDLGO_Focal64 firstrib_rootfs (see thread). I also had this issue when I was building Tiny Puduan via woof-next. As happened before it breaks gdk-pixbuf-query-loaders because this tool expects the loaders to be in a very particular place. This meant in my recent experiment that the icons on rox were broken. I was going to post about it but wanted to sleep on it.

The issue was fist addressed in the following pull requrest:
get rid of the multiarch symlink #1224

but this pull request was closed because the work was instead first done in an experimental branch, which was presumably then merged into puppy but the link to the experimental branch no longer exists . Needles to say they eventually got rid of the multiarch symlink hack.

The sfs loading of WDLGO's firstrib_rootfs dpkg/apt component parts, which are absolutely compatible with upstream Ubuntu directory organisation will thus not work out-of-the-box. Of course, their contents 'could' be moved to the various places Puppy Bionic has chosen to arrange things - probably just need to copy all the libs across to /lib and /usr/lib rather than to i386-linux-gnu, but that is extra work and messy and any sfs would need rearranged accordingly. I will think about it, but probably leave such manipulations to anyone else who can be bothered...

I think if one wants dpkg support then the puppy files need to moved into the multi-arch directories because extracting via tar can break symlinks and dpkg probably does this. If one is using the core W_LGO suite, there is no package manager included and the symlinks can be kept. In this case the W_LGO could be merged into puppy in a way to preserve the symlinks.

However, I will of course be publishing the overall WDLGO_Bionic32 standalone distro iso, and, as I say, anyone who wants to take its component parts and merge it into the otherwise compatible (I hope) BionicPup32 is welcome to do so. Similarly with WDLGO_Bionic64.

I think if we are going as far back as bionic I'd be more interested in a 32bit system but I suppose you have build scripts for these things. I will note though that there is an extra step that one must take. The puppy package manager must also be fixed because in old versions of the ppm, the multi-arch symlink will be recreated by first moving the files and then making the symlink again.

Thank goodness, that the file-system structure adopted in FossaPup64 does seem to mirror that of official UbuntuFocal and hence compatible also with WDLGO_Focal64 structure making the dpkg/apt addon a breeze.

I agree. The multiarch symlink appears to have been a mistake.

[wiak]

Well, I'm not blaming Puppy (devs) for adopting the filesystem structure it has. For Puppy PPM use itself I presume it all works intended and since no dpkg/apt is part of Puppy design it wouldn't matter from that perspective. Just a pity from the addon apt via sfs perspective, which effectively changes single-user PPM Puppy into some-mongrel-thing else. Also, symlinking lib destinations like that tends to otherwise work very well in practical use when it comes to simpler lib paths. For example both Arch Linux and Void tend to symlink not only lib directories but also pretty much all exececutable file directories such that most all libs end up in /usr/lib and most all executables end up in /usr/bin. Certainly that means a lot of files in single directory locations, but works great in practice since not having to add much to PATH and the libs-related PATH (such as LD_LIBRARY_PATH) or changing their orders to achieve required precedence. Debian is old-school UNIX organisation I suppose, but, presumably the Puppy devs, similarly to myself, prefer more Arch-like filesystem organisation (but drawback is that lack of upstream compatibility issue).

However... I don't know about others out there but I often wake up with possible solution to things that disturbed me just as I went to an exhausted sleep and I'm hoping that is the case this morning. On waking my brain was immediately telling me (rather than sensibly thinking about breakfast) that it would actually not be particularly difficult for me to build a second WDLGO_Bionic32 that instead of current Ubuntu filesystem structure adopted PuppyBionic filesystem structure and thus make the chucked out dpkg/apt addon sfs compatible. This would be a special WDLGO build since I'm certainly keeping Debian filesystem as standard in official debian-distro-based WDLGO releases (so Puppy dpkg-apt-addon users should use the specially provided addon sfs and not the firstrib_rootfs of WDLGO in future). I'm going out just now, but will try that trick later to day... Yes, my main interest in WDLGO_Bionic is also for 32bit version - indeed I even consider an earlier than Bionic 32bit version. Of course I'm scripting all builds in WeeDog, though they are disorganized in the case of WDLGO builds at this early stage so won't be publishing these until in appropriate close to stable form since would need heavy documentation to accompany them as they stand.

The normal WeeDogLinux build scripts are all long-ago published of course - since WeeDogLinux is primarily a keep-it-simple build script system with its own script-built initrd/init for overlayfs frugal install system control that thereafter utilises upstream official package managers and does not involve any remastering or manual/hack minimising of any upstream distro (though no harm in later minimising of course).

[wiak]

However... I don't know about others out there but I often wake up with possible solution to things that disturbed me just as I went to an exhausted sleep and I'm hoping that is the case this morning. On waking my brain was immediately telling me (rather than sensibly thinking about breakfast) that it would actually not be particularly difficult for me to [script-] build a second WDLGO_Bionic32 that instead of current Ubuntu filesystem structure adopted PuppyBionic filesystem structure and thus make the chucked out dpkg/apt addon sfs compatible. This would be a special WDLGO build since I'm certainly keeping Debian filesystem as standard in official debian-distro-based WDLGO releases

Okay, that worked with but the simplest of script mods for this one-off special build for BionicPup32 dpkg/apt/PAM addon. See attached screenshot where I have just installed nano as a simple test.

Note in the screenshot the adrv (adrv_upupbb_19.03.sfs) is actually the first part of the dpkg/apt addon (only 7.8 MiB in size). The main part of the dpkg/apt addon (apt_sfs_load_bionic_i386.sfs) is loaded after booting BionicDog32 via sfs-load and is 21.5MiB in size (both using normal gz mksquashfs compression, so could be smaller download with xz). The only thing the BionicDog32 user has to do is to rename the original adrv to ydrv_upupbb_19.03.sfs

The new adrv contains the coreutils /bin and /sbin directories part of the addon and appears in layer above puppy_upupbb_19.03.sfs and hence overwrites the busybox app links that otherwise appear in that puppy_upupbb_19.03.sfs. I expect that will work fine but further testing will be needed to ensure that. Also, I can't at this stage guarantee I have my addon filesystem structure absolutely correct for Puppy, but I think it is - easy to rebuild modified slightly if any problems are identified. I will need rockedge to test this addon soon (once published) using that testing zoneminder install - I'll likely preconfigure it with some of these zoneminder-related users and groups prior to publishing (hence a short delay before posting). On second thoughts I won't add the zoneminder-related users/groups since that wouldn't be required more generally.

EDIT: I'm more than sure now that I could make a similar dpkg_apt addon for EasyOS-Buster though I don't know when I'd get round to doing so - just the wrong time of year for me.

[wiak]

I'm now at that 'nice' stage, from a developing point of view, where I have scripts doing most of the work and apparently successfully, which allows me time to experiment. Once I have the 'product' it is a pleasant kind of development being able to merge some of the contents, to chop and change what is included and not included, what layers to arrange things in for best results in sfs addon files. That's how I was able to produce the first dpkg_apt addon for FossaPup64 and now I've produced the two addon sfs files (like I have done with similar BionicPup32 dpkg_apt addon), which makes usage with Puppy very simple to implement (just a couple of files to rename, a reboot, and a load addon via Puppy sfs-load utility).

Have the firstrib_rootfs built (and the addons automatically built by the script) I am happy to experiment at my leisure with chopping up the results in different ways into alternative sfs arrangements so I can use these alternative sfs forms to either lie under existing puppy files or to overwrite them (and thus provide upgrade solutions) - these are easy tasks at this stage and I'll provide any sfs addons of any such arrangement I find useful that might appeal also to others.

First will be to publish the latest WDLGO_Focal64 and WDLGO_Bionic32 standalone distro isos, along with the optional associated specially tailored two addon sfs files that can be instantly used to provide dpkg_apt_multiuserPAM capability to Puppy community distros FossaPup64 and BionicPup32. The dpkg_apt sfs addon(s) for BionicPup32 have been specially crafted to work with the older Puppy filesystem hierarchy (which deviates from standard Ubuntu/Debian approach). These could also be used experimentally with older pups that also use that older Puppy filesystem hierarchy to potentially provide upgraded libs (such as s243a has been experimenting with, via the first WDLGO_Focal64 firstrib_rootfs release, to use newer chromium in Puli/xenial distro I believe) alongside the dpkg_apt_multiuserPAM components, though for that upgrade I'd package the addons somewhat differently in that the files I want to upgrade the underlying Puppy host would be put into the adrv_addon (since that one overwrites the puppy_XXX.sfs filesystem). In the same way I already do with the apt_sfs_load_focal_amd64.sfs that one, as its file name suggests, is to be loaded by Puppy's sfs_load utility, the reason being that sfs files loaded by that mechanism do not overwrite already puppy_XXX.sfs loaded files, the main reason I did things that way being that I did not want the main addon to overwrite essential Puppy configuration files (such as these in /etc). Whether these experiments work without issue is another matter, but where there is a will there is indeed often a way...

The key thing is to have the LGO (lego-like) components, for remoulding per the experimenter's needs, which is what WeeDogLinux system was basically designed for - as well as being able to build full desktop systems to the recipe's of anyone willing to put in the time building the associated FirstRib build plugin, or modifying existing FR build plugin(s). Such versatility, flexibility, and relative simplicity, is the name of the game when it comes to WeeDogLinux system design, which differentiates it from most build systems out there. Nothing is set in stone, or inaccessible to anyone who aspires to system development activities, with WDL or its subdivision WDLGO - most anyone with basic shell scripting abilities can easily learn and use it - so make what you will with it.

There is plenty of scope and and more than I could ever try or test out on my own - be it for upstream flavour Void Linux (the original upstream package manager employed in FirstRib WeeDogLinux) or the Debian-based distros (Debian, Ubuntu, Devuan), Slitaz, or now, for providing addons for Puppy. Furthermore build_weedog_initrd can also be used with the Puppy rootfs underneath to provide overlayfs weedog init-driven capability (upper_changes with 'rollback' capability, raw or sfs layers and so on), rather than Puppy's normal PUPMODES and aufs. So much to do, so little time to try. Main thing for me soon is to concentrate on further documentation (though most all WeeDogLinux scripts have reasonably detailed documentation built in to their help/usage internal text, though it is difficult to cover all facilities/tricks in there).

Anyway, typing that was me basically relaxing/procrastinating - back to work... albeit the nice, simple, re-packaging/experimentation phase that I personally enjoy most...

[wiak]

I'm continuing to basically use the following earlier post notes in my attempts to install zoneminder (not configure it - that's for rockedge...):

viewtopic.php?p=15747#p15747

EDIT1: But major difference is that with new double-sfs file addon the original puppyXXXX.sfs is used and not modified in any way.

EDIT2: With FossaPup64, using the new addon sfs files I'm testing, installing zoneminder gave me this issue again:

Oh, how stupid of me! Considering I built/use WDL_Arch64, which uses systemd, I should have thought/noticed that zoneminder install changed /sbin/init to point to systemd. I prob just need to revert that to busybox init (well, actually Puppy /sbin/init script which does various other important Puppy configurations) and all will be fine. Late just now, will try tomorrow.

/sbin/init is the first thing I should have checked... oh well, just hoping it is as simple as that and if so then this new apt facility for FossaPup64 could be very useful if not revolutionary.

Zoneminder install from Ubuntu via apt seems to (not surprisingly I suppose) result in /sbin/init being overwritten to become a symlink to systemd init rather than the essential Puppy's /sbin/init shell script... though previously the problem mysteriously went away on its own and didn't happen on installing zoneminder that I remember - maybe I did something in different order or forget... Fix is to delete the symlink in the pupsave file, just prior to rebooting, and then the original puppy init script will correctly be used.

EDIT4: Fortunately, the problem 'mysteriously disappeared' again on a second try. As long as I follow the instructions in the previous howto link carefully (and remember, puppy_XXX.sfs should not be modified with this new double-sfs addon arrangement), systemd does not try to take over on installing zoneminder.

viewtopic.php?p=15747#p15747

Zoneminder installed without issue on this second attempt and reboot via Puppy Start Menu also worked fine (no systemd accidental install issues whatsoever...).

Just as well since the above 'fix' isn't enough since if systemd does get installed it overwrites much more than that. Worth bearing that in mind - danger with using apt from Debian would be risk of systemd ever accidentally getting installed. Okay, on this occasion but only time will tell if that might accidentally happen on other installs - still useful for most installs though - just keep the risk in mind. Fortunately it is always easy to re-install a new Puppy system (and even one with backed up savefile).

I will likely be publishing the new dpkg_apt_multiuserPAM double-sfs FossaPup64 addon probably tomorrow along with similar for BionicPup32. Hopefully get round to also building/publishing the WDLGO_Focal64 and WDLGO_Bionic32 standalone bootable WeeDogLinux tiny distros too.

EDIT5: I tried installing systemd via 'apt install' just to see if it would break Puppy (i.e. overwrite Puppy files, which I imagined it would, but didn't seem to - I'm not sure, I'll have to try again). But then I rebooted and installed lxterminal via 'apt install' and this time the systemd menace has appeared so BE CAREFUL - I'm not sure if installing lxterminal was the issue or my earlier attempt to install systemd itself. Nothing I can do about such issues arising - up to the user to avoid, hence my big DISCLAIMER - maybe a very useful multiuser Puppy addition but USE AT YOUR OWN EXPERIMENTAL RISK... as always...

NOTE: I expect the above systemd-related accidental install risk can be protected against via suitable apt 'pinning' - I leave that up to the users to find and do. There may of course be someone who actually wants to install systemd in Puppy (okay, so not many!!!) but by default it would be better to prevent the 'danger' so such pinning or whatever method prevents accidental installation of systemd (if possible) can be added by default to the addon later - just experimental use stage at the moment... At that experimental stage, you could instead arrange to run the Puppy rootfilesystem as a WeeDog under weedog initrd/init control, rather than Puppy's own initrd/init. That way you would be using WeeDog's upper_changes instead of Puppy's savefile. The advantage is that you can simply renumber the upper_changes folder between reboots and then when and if something goes wrong rollback to previous upper_changes. However, most puppians are not familiar with that and so one alternative would be to always check /sbin/init to make sure it hasn't become a pointer to systemd prior to rebooting and merging the changes into your savefile...

[wiak]

Puppy apt addons being published via Puppy Projects ( downloads being at weedoglinux forum):

viewtopic.php?p=16601#p16601

[wiak]

Though I haven't published anything 'new' for a while, I'm currently polishing up (fixing) the latest build_firstrib_rootfs script. As part of the testing I've just built a minbase Firstrib Devuan64 firstrib_rootfs, which I'll convert into a WDL_Devuan64 standalone bootable system tomorrow via build_weedog_initrd. Aside from the getting these newer build scripts into full working order, I have it in mind to create a WDLGO_Devuan64 system along with dpkg_apt_PAM addons for Puppy Devuan64 release I noticed recently (advantage being no systemd-related issues with that distro).

Alas that my dev system is running out of space again; a constant battle - the system is old and only has a 64GB SSD in it, and I keep doing dev builds and am slow to tidy up thereafter (especially since I'm scared to delete anything I might need again later - I should be using git, but sometimes I can't be bothered organising what I'm doing, but suffer later...).

wiak

[rockedge]

I am putting together a NoteCase document on how to set up a Fossapup64 with the apt add-on SFS and install a LAMP and Zoneminder.

I've done it now more than a several times and am working on writing it down since I've noticed my notes on doing these things are lacking.

The system I am building and writing about is right now at the stage that this Fossapup64 has all the proper SFS files loaded, has three package managers that work, has a fully operational LAMP and with option to switch from Apache to a Hiawatha web server and back again.
Also so far the systemd changes that break Fossapup64's have not appeared. This I expect to happen during the Zoneminder installation phase. I am constructing a simple script that will check for the change and change it back but the real fix will be to have be somehow limiting the systemd integration of those changes to /sbin/init and /sbin/poweroff during the install process.

[Clarity]

Timing is everything @rockedge : I was just about to write you on that topic. I have a couple RTMP cameras that I want to understand setup for capture.

Thank in advance for what you've announced.

[wiak]

I am putting together a NoteCase document on how to set up a Fossapup64 with the apt add-on SFS and install a LAMP and Zoneminder.

I've done it now more than a several times and am working on writing it down since I've noticed my notes on doing these things are lacking.

A question that just today comes to my mind is whether you arrange for zoneminder (and LAMP and so on) to run as root user or can it also be run as non-root, such as spot in the case of Puppy Linux?

The reason I suddenly ask is because I personally am about to change my habit of over a decade, in that I plan in future to autologin as non-root user and work from there. As you know, @rockedge, my usual desktop distro is WDL_Arch64, which can autologin by default as either root or weedog user. To change is a simple matter of running StartMenu -> userswitch. That will continue to be the case, as far as WDL_Arch64 is concerned - just that I am choosing to autologin personally as 'weedog' user from now on. Basically, I am going with the flow (mainline Linux distros) for various reasons: it has become complicated to run many apps if logged in as root user (for example: many browsers, including those that are chromium-based, Microsoft Teams and Skype - Arch AUR versions); despite never having been hacked whilst using Puppy or DebianDog or WDL_Arch64 when auto-logged-in as user root, I personally do not doubt it is safer to use any OS as non-root user.

It's true that it is wonderfully easy/convenient to pretty much always be user root... permission issues never arise and no need to type that word 'sudo' (though it is fair to say that using sudo in WDL_Arch64 is easy - unlike using sudo under the likes of, say, full Ubuntu, which is a horrible experience since Ubuntu seem to do everything to make that painful...). However, for those occasions when I really want to be root all the time, with WDL_Arch64, it is as I said a simple userswitch (which does not involve any reboot) to become so. Also, I can easily create a folder anywhere on my system (outside the save changes area) that can be owned by weedog user and group and contain as many sub-directories as I like - that way, for most of the dev work I do I don't even need to resort to 'sudo'.

Truth to tell, the reason this change of flow has come about is:

1. I noticed my two kids (8 and 15 years old) had independently adopted the habit of autologin as weedog (following an initial userswitch). This, it turns out, occurred naturally because they self-discovered that some large games and various animation software apps were only working out-of-the-box if run as normal user. And also because a lot of what they install comes from Arch AUR repo, which also only allows installations by non-root user; I think that's the main reason actually for their adopting 'weedog' user autoboot as their preference.

2. My partner uses WDL_Arch64 for all her business needs and, as I said, neither Skype nor Microsoft Teams would work out-of-the-box unless logged in as non-root user. Also, running business-critical software as root user does somewhat worry me in the ever-more-dangerous online world - particularly with web-browsers - more and more exploits out there now. She has been running as user root for a long time, so the issue is that her saved work is all owned by user/group root. Again, however, it was simple enough to create a /mnt/home/weedog directory owned by user/group weedog and copied all her previous work directories into that and recursively changed their user/group ownership from root:root to weedog:weedog. That /mnt/home/weedog folder can of course be shared with any other distro I use (albeit with the caveat that the user/group is best being weedog:weedog (which would be a problem to arrange for Puppy installs of course, but for the most part it is easier for me to work around that Puppy issue via chown root:root to weedog:weedog whenever I finish using Pups with that 'shared' weedog directory).

May sound complex, but actually simplicity itself. Much harder in practice to arrange Msoft Teams, Skype, ChromXXX browser, etc etc to run as user root.

Admittedly, I am also a fan of pulseaudio...

and I find that systemd works very well and is less messy to configure and administer than old SysVinit, though I actually 'really' like runit alternative too (as used in Void Linux, and thus by default in WeeDog Void variants). Though, therefore, I am not against systemd, I nevertheless do like choice, so very happy not every distro uses systemd (though runit a far better alternative than old messy sysvinit to be frank).

So, despite my distro designs being far from conventional and weedog overlayfs being independent and unique, I am becoming almost embarrassingly conventional when it comes to my preference for non-root login, pulseaudio, and (when not using runit) systemd. As we know, it is tricky to use the likes of apt on non-systemd machines - though of course that can be done and improved upon via appropriate dummy package apt pinning.

Of course there is nothing to stop WeeDog distro users choosing to autologin as root user and use the various established mechanisms for running apps such as chromium-based browsers from that --no-sandbox or special non-root-user perspective and so on... just that it is easier, I feel, to go with the conventional non-root user flow in this case IMO. An alternative approach is to use 'containers', such as in EasyOS. Void Linux provides a lean/lightweight container implementation (as a Void package)

https://github.com/void-linux/void-pack ... s/template
https://github.com/arachsys/containers

in addition to the alternative of using LXC or Docker (and also, therefore can be adopted by WeeDogLinux Void variants) though I've never tried it since that additional layer of complexity is more than I personally feel the need for.

wiak

[rockedge]

I am going to go get new tires for the automobile, so I will add more later, but I've been working a lot with the www-data:root or spot:root model. This way I can have the many packages that will only run as non-root user yet still be able to access as the root user those files at the group level that belong to the user other than root.

Also to note, most of the Puppy Linux installations of Zoneminder do not use root but use the www-data:www-data and mysql:mysql users for the LAMP or LHMP. OR another combination that satisfies ZM preference to operate as any other user rather than root, is to use the built in webuser:webgroup for the web server plus ZM and mysql:mysql for the database server.

Zoneminder is not set up to run well as root since it is mainly controlled from a web console and is built to stream video and receive data from a network. With the APT plugin and the PAM it is even more in-line with ZM's prefrence of running as user www-data, webuser, weedog or daemon

Every Puppy Linux web server I set up does not use root as the primary user for web server connections. Apache and Hiawatha don't like it.

[wiak]

Threw together a quick WDL_Devuan64 (beowulf) using the dev version of build_firstrib_rootfs and build_weedog_initrd scripts and it connected fine via wiakwifi and posting from it now (using installed chromium). Currently also just has jwm, lxterminal, mtpaint, and scrot. Using WeeDog initrd with overlayfs frugal install functionality of course. Currently using uncompressed 01firstrib_rootfs since easy to hack during dev work.

I'm not really interested in WDL_Devuan64 itself (though works fine and also allows me to fix up build_firstrib_rootfs for Ubuntu and Debian future builds) but wanted it because its the host system I need for now producing a small WDLGO_Devuan64 system along with dpkg_apt_PAM addons as a side-production that can be used with Devuan beowulf Puppy productions.

wiak

[rockedge]

@wiak
Nice!

[wiak]

Once I have the dev versions of all the build scripts finalised and checked out I'll upload them to git. Then, once I'm not playing with them myself, I'm thinking of writing a "Build WeeDogLinux Tutorial/Booklet" with examples for some of the various 'flavours'.

The fact is, that FirstRib WeeDog is really quite a simple toolkit for building frugal installable distros of now tons of different types with no limit to how big or small or what user wants to include. The point I'd like to get across, which being somewhat busy I've probably not managed to convince anyone about yet(!), is that it is really a simple process to build a WeeDogLinux distro and no-one should be afraid to try, whatever their experience with Linux more generally - you don't even need to really know how to write shell scripts, though that's useful of course. If a person ever uses the commandline, then basically, they should be able to build a WDL distro - just need an empty folder, download the build script or scripts, run that, wait for the build to complete, and adjust your grub3dos menu.lst or grub2 grub.conf configuration and all should work. Want to add to the build (prior to building) then simply add some extra entries to the build plugin (extra app installs, applications or desktop configurations, or whatever).

Of course, we all end up with some issue or another (missing firmware or grub syntax wrong, or ...) but help always available here. What's particularly useful about WeeDog (apart from its pretty flexible overlayfs-based initrd) is that a user can start with a very small limited build (just to see how it works) and then incrementally expand to a full desktop, piece by piece, and it's thus also a very educational experience (and that is the case for myself too - I learn a lot just by building systems using WeeDog build scripts and adding stuff via the build plugin). The end result is as good (or bad) as you make it... and you can always polish it up later (and expand it or slim it down). The critical core build scripts themselves are more slowly developed, and carefully tested by myself before their release, but I'm always open to ideas for new features though no guarantee about what I'd adopt - having said that, all the core build scripts contain quite flexible user-plugin expansion capability, which is the preferred method of build system expansion more generally. Outside of the core build script creation most of the hard work in practice (and for me too) is the main build recipe which is pretty much entirely a user-created plugin (f_whatever.plug) - that plugin provides the overall distro design and it is entirely created by users (which could include myself of course). I wrote the f_XXX.plug for WDL_Arch64 but the WDL_Void32 f_XXX.plug is written by rockedge.

Easier of course to concentrate on one WDL build system type (be it Void, Arch, Ubuntu, Debian, or Devuan) but because the basic build process is much the same for all of these it becomes pretty easy to build vastly different systems without feeling it is over-powering to master so many distro flavours. Good to have someone become the 'expert' on each build type/flavour though since all upstream repos have their own package management methodologies to master, though it is also important to have resident 'experts' on particular desktop managers - for example, I know a fair amount about setting up openbox (the Arch Linux way anyway) but next to nothing personally about setting up JWM...

In terms of developing WeeDogLinux systems, the more 'developers' the better of course ('developer' for WeeDogLinux meaning ANYONE willing to try/modify any build), since we all benefit from any and all new creations/systems/knowledge-sharing, though once again I stress that you don't need to be a guru to work on the build of your own WeeDogLinux creation - most anyone using the Puppy forum is perfectly able to develop a new WeeDog either by modifying or extending existing build plugins, which are often not much more than a list of package manager install app commands, plus any useful configurations you learn/duckduckgo about on the way (which is basically how I do it, and via Arch Linux wiki and similar, along with, as I've previously mentioned, cherrytree hierarchical notetaker as my brain/memory - notecase would similarly do for that really). I do use git, but usually only commit new stuff to that after a lot of hacking around - so knowledge of git is not at all required for WeeDog development, without denying I like git for final result updates, but my overall dev approach is much less formal so you don't need to know anything about git at all to develop WeeDogLinux distros. In fact I do not want git pushes/issues and so on (I simply wouldn't read these since I'm hardly ever 'there') - I prefer just discussing matters on this main forum since everyone can then be involved.

Anyway, back to my dev build script polishing alongside the WDLGO_Devuan64 current project...

wiak

[wiak]

I received a PM from Clarity asking if WDL systems could be provided in iso format. I explained that some already are (e.g. rockedge's WDL_Void32 and the expanding WDLGO series) but that WDL_Arch64 is not only rather large (around 1.5GB) but also a rolling distro (hence iso becomes stale almost as soon as it is produced resulting in pacman update redownloading all packages anyway). However I added the following note, which may end up being a way of conveniently providing a full desktop system, which is booted via the originally provided small iso:

@Clarity:

It is perfectly possible to build a distro even smaller than a traditional Pup or DebianDog by starting with a WDLGO (iso-provided) system, such as WDLGO_Focal64. Once I have all my latest build scripts in order and pushed up to WeeDogLinux gitlab, and finished a dpkg_apt_multiuserPAM addon for recent DevuanPup, I may therefore first concentrate on WDLGO_Focal64 (and Hirsute Hippo thereafter), building it up to a usable desktop in tutorial fashion. That way, the user can start with the extremely small WDLGO_Focal64 iso (which is bootable per the method you prefer) and then, following an instructional tutorial, easily build it up to full desktop status (allowing them to customise it on the way); furthermore, for those who don't want to bother entering lists of simple commands, or following a tutorial, I will be able to also provide small downloadable scripts (simpler even than a delta) to build the simple WDLGO_Focal64 automatically up to full desktop status - could even make that a one-quick operation (so rather like a QuickPet but for more than one app/configuration). People like rockedge would certainly be able to usefully help out with the details (e.g. JWM/Rox configurations - though alternatives such as Openbox/tint2/pcmanfm could also be discussed/provided). One again, iso contents soon become dated, but since only a small initial iso (which is easy to regularly update as a download anyway) the save folder update to that will be equally small and I really should also work on a similar WDLGO_Arch64, and so on.

Note that with such a small initial system, it would be relatively straightforward to also work on a modified initrd version that uses symlink sfs loading mechanisms (instead of overlayfs or in addition to it), such as the tinycorelinux mechanism preferred by wanderer, though looks like, for a while at least, I'd be too busy overall to dabble with that personally.

[wiak]

So after that WDL_DevuanBeowulf64 build I made, I've also made Ubuntu Focal and Debian Buster firstrib_rootfs builds - simply because I'm checking latest build_firstrib_rootfs script prior to uploading to gitlab. That's all going fine, but, I don't know if I'm misleading myself somehow because its so late at night here at the moment, and I'm tired, but the debootstrap-based Ubuntu Focal and Debian Buster both have an unexpected filesystem hierarchy compared to what I was expecting. Basically, both turned out a bit like Arch Linux with /bin now being a symlink to /usr/bin, and /lib a symlink to /usr/lib. That's great in many ways if it is true since makes PATH handling much simpler, but it is different to what I was expecting (different from the FossaPup and FossaDog distros that I have isos of, for example). I'll have to double-check and, if they have adopted that new filesystem hierarchy, I'll have to think what, if any changes, that makes concerning other matters handled by FirstRib WeeDog build scripts. I previously arranged WDLGO_Focal64 to use same FS hierarchy as the versions of FossaDog and FossaPup I have, assuming the former was same as upstream Ubuntu Focal since I think fredx181 uses debootstrap as a starting point too.

For making the dpkg_apt_PAM addon for FossaPup, it is important I use same FS hierarchy, but overall I want WDLGO_Focal64 to be same as upstream FS hierarchy, so I'll have to double check the situation overall.

I'm also planning to look into EFI boot capability for next WDLGO iso releases (I have access to a newer laptop so is a good time for me to do that).

[wiak]

A bit off topic, so I'll probably rename the topic later since I'm using it simply as a blog of updates I'm doing:

Currently, basically translating my f_00_Arch_amd64-openboxFull.plug to create almost identical version of same for Ubuntu, Debian, Devuan, and Void. I'm hoping the overall structural/configuration parts of that end up being basically identical since will make future development of these multiple distros much easier. Things going well so far. Have Ubuntu, Debian, and Devuan up to boot to commandline stage and beginning to merge in the f_00_Arch... extras, but first now checking Void flavour build up to same commandline stage and then try to build all of these up to the f_00_Arch_amd64-openboxFull.plug full desktop status.

Since the build for all of these uses the same build_firstrib_rootfs script, these ongoing build developments are also part of developing/testing that overall build script and then I run build_weedog_initrd on resulting firstrib_rootfs/ to produce the bootable systems for each of the above, which thus also allows me to tweak/develop/test that build_weedog_initrd script so that it works correctly with all above WDL distro variants.

Somewhat in parallel, I'm also further testing new build_firstrib_rootfs_lgo script, which is the WDLGO ultra slim distro builder script. It is a specially modified version of main build_firstrib_rootfs script, made for special WDLGO (lego-like) distro production. In practice I expect to be able to create f_ plugins for these simpler WDLGO systems that also allows them to be built up, in a finer grained manner, to full f_00_Arch_amd64-openboxFull.plug desktop status. Main difference overall being the ability to more easily produce cutdown versions of WeeDogLinux variants, an option that I feel is particularly useful for use in virtual machines and/or containers and similar. The WDLGO build is also what is used to produce, as an optional side-product, dpkg_apt_multiuserPAM sfs addons for some Puppy systems.

A lot of work going on in the background therefore, and it will be some time before next products are released, and probably not everything at once... First will come the latest build_firstrib_rootfs and build_weedog_initrd scripts probably, and possibly some of the WDLGO variants, such as a WDLGO_Devuan64 will follow thereafter (along perhaps with dpkg_apt sfs addon for DevuanPup. So when... I don't know yet since I prefer to do a lot of testing on my own prior to initial release.

wiak

[rockedge]

@wiak excellent progress. Meanwhile I've been putting the Fossapup64 apt addon through as much stress as can think of. So far so good and the system still surprises me with it's resilience.
It is something else being able to install packages with 3 different package managers. Some stuff is just easier with the PPM some much better being installed with Pkg and then there is APT to make things simple when following recipes for Ubuntu or Debian.

I am in the process of renaming all of my WeeDog -Void plug files to the new naming format so they will work. The systems the plugs produce you have seen and are not that complex. The original idea was to make a couple of plug files that actually make a system that works, but also was an example of how it works. A template for some more serious creations. So I will name the existing plug files to make them usable by the Build scripts.

The potential of these OS's as virtual machines and chroot'ed or containerized is big.

All of my plug files will be available on github.

Looking forward to building a Void variant with your recent advances in technology.

[wiak]

In yesterday's tests, commandline builds for Ubuntu, Debian and Devuan worked fine using the new build_firstrib_rootfs and build_weedog_initrd scripts.

Have just completed an WDL_Arch64 build (and booted it) using the same new scripts, so all seems fine thus far.

Currently working on commandline WDL_Void64 build. Assuming that works with no issues I should be at the stage of uploading these new build scripts (version 3.0.0 -rc1) up to WeeDogLinux gitlab. Only truly major change is for build_weedog_initrd being that firmware/modules can be provided as separate 00fw_mods sfs file or as an uncompressed directory - previously that particular resource could only be in sfs format. Also fixed errors in previous build_firstrib_rootfs that prevented builds of Ubuntu, Debian, and Devuan working properly.

I've also fixed the f_build_plugins for Ubuntu, Debian, and Devuan such that no manual tweaks are required to login as root/root and use the bootable result (and connect via wiakwifi).

I'll try to make the Void f_plugin as similar in content and form to the Debian-based WDL distros as possible. Thereafter, as I said, I'll expand these all these variant plugins to try and clone the overall structure, content, and configuration as the existing full desktop WDL_Arch64 f_XXX.plug. I expect that last stage will take a while. Thereafter I'll get back to the separate build_firstrib_rootfs_lgo script, which is for the special WDLGO systems.

I have a feeling this could be a very productive year for WeeDogLinux. Once all the above are created I may well produce iso versions to help anyone interested try out WDL as a pre-configured system (I'll have to look into EFI boot capability as part of that). Finally, I'll look into producing some userland utilities that leverage the functionality available from WeeDogLinux initrd/init in terms of utilising upper_changes to best effect (e.g. for rollback or merging of a series of upper_changes sessions). And perhaps also some sfs-load on the fly facility via tinycorelinux-type symlink sfs loading mechanism.

[wiak]

Continuing to polish up latest build scripts for gitlab release.

Then will get back to considering EFI boot possibilities, and

planning to release WDL_Arch64 as an iso (and perhaps Ubuntu Focal version of much the same once ready), but will check first with rockedge for iso storage space since these are full desktop with latest full inkscape, gimp, libre-office+java, Chromium, and more 1.5GB distros. I 'could' remove some of these larger apps, but main reason the isos are bigger than typical cut-down distros is the fuller firmware provided. Cutting down no longer so worthwhile IMO (considering how big hard drives and usb sticks are nowadays) and in my experience WDL_Arch64 runs at least as fast (and at least as little RAM consumed) as all the rest aside from maybe WDL_Void creations. I like Arch base since well-tested rolling release provides nicely up-to-date apps, kernel, and libs, but that far works very efficiently on my old HP Elitebook 2530P core2duo machine of vintage circa 2008.

For those interested in very slimmed down (but full official package manager systems) then I'd recommend working on provided WDLGO systems (around 20MiB download). I will be providing alternative distro flavours/versions of these later later (currently UbuntuFocal64 only) and will keep them up-to-date. Later I'll think about user tools for creating even more flexibility in terms of merging upper_changes save folders/remastering/managing-rollback-saves etc - should also be able (or anyone so interested) to work on tools for creating slimmed down versions of the larger isos. Rather a lot to do though so contributors welcome as usual.

[rockedge]

@wiak,
A quick report during an extended run of the WDLGO_UbuntuFocal64 mini-apt/dpkg experimental system built into a Fossapup64.

The add on SFS module and small modifications have been working solidly since first inception of blending a Fossapup64 to run a full version of the APT package manager. I just completed a complete system update/upgrade, including bringing the ZoneMinder installation to version 1.37.21 master and the process appears to have completed successfully.

Overall the experimental WDLGO_UbuntuFocal64 mini-apt/dpkg add-on has been a complete success

[wiak]

Good to hear that is still working okay - the supplied dpkg/apt related files within it are pretty old versions now of course, however, presumably able to upgrade themselves!

I had thought there would be a Phil version of JammyPup that I would end up providing an dpkg/apt addon for (as part of a very small WDL_Jammy release, however haven't seen that Pup appear. Neither has small WDL_Jammy release, the making of which automatically creates that dpkg/apt addon as a side-effect of the way I produce such, but there is a fair chance it will eventually (including the newest WDL initrd of course).

My opinion was, that it was appropriate Puppy design to leave it to contain its own cross-Puppy package manager (be that PPM, pkg, or whatever) and to only include the upstream repo official package managers via an optional addon. Having said that, I feel a bit differently about VoidPup since xbps as a package manager seems to fit in many ways into what was Puppy approach to packaging in smaller pieces (with Debian I think the dependencies tend to be larger - not so optional, but maybe I'm wrong about that). I also feel that VoidPup is a very different beast from say KLV-Airedale, so very useful in its own right.