dpup OS 1 Rolling

[dimkr]

"dpup OS" is a minimalistic Puppy derivative built from Debian Bullseye packages and packages built from source by woof-CE, with zero PET packages used during the build. It contains commonly used applications like a browser and a text editor, but some things, like a word processor are omitted.

dpup OS is beta quality, I'd say, and it can break at any moment. At this moment, only tinkerers will find it interesting. It has all the innovations that went into Slacko 8.x, plus more experimental stuff. Technically, dpup OS is built from a fork of woof-CE that follows it very closely, and almost all features in dpup OS are integrated into woof-CE, available for use in any other Puppy.

The latest release is available at https://github.com/dpupos/woof-CE/releases, and a new release is built every 3 days. The version number is always 1, and it's the first (?) "rolling release" Puppy.

The x86/x86_64 releases contain dpupos-1-ext4-2gb-uefi.img.gz (for regular PCs with UEFI and secure boot disabled) , dpupos-1-ext4-2gb-legacy.img.gz (for regular PCs with BIOS/legacy boot enabled) and dpupos-1-ext4-2gb.img.gz (for Chromebooks). Decompress the image, write it to a flash drive and you're good to go.

The ARM release targets the Asus C201 Chromebook, and other models or other ARM based devices might be added in the future.

At the moment, there is no a super basic installer that can be used to install dpup OS to disk, and there's no support for booting off optical media.

Partial list of features:

• The new PUPMODE 6 boot mode, using frugalify and overlayfs - no initrd, no aufs

• To load a SFS on boot, just add put it in the boot partition

• Inspired by @666philb's Fossapup64 and expanding on this idea, dpup OS consists of a main SFS, adrv, zdrv, fdrv, devx, nlsx and docx - you can delete adrv to get a barebones Puppy that boots to a JWM/ROX-Filer desktop without applications, delete docx and nlsx if you don't need documentation and speak English, etc'

• A new release every 3 days, all built automatically on GitHub, and a system update tool that supports fast delta updates

• Latest kernel 5.10.x on x86_64/x86 with the same driver selection as Debian, and latest 5.4.x on ARM + latest firmware

• The merged /usr directory layout - /lib, /bin, /sbin, etc' are symlinks to their counterparts under /usr, as in other distros

• Tear-free, GPU-accelerated rendering using Cage and Xwayland

• Firefox, Sylpheed and Transmission running as spot, for increased security

• Special tuning to reduce RAM consumption by about 10%

• The firewall is enabled by default, for increased security

• Removable internationalization and documentation modules, included by default

• Ad-blocking, enabled by default for faster and safer browsing by default

• DNS cache for faster browsing

• GTK+ 3 upgrade of almost all applications and improved tray icons

• Multiple, complete theme packs that cover both GTK+ 2 and GTK+ 3 applications and have matching window borders

• Firefox, with privacy-oriented default settings and lower resource consumption

• Improved font rendering - websites look as they look on other distros

• Keyboard shorcuts to maximize, minimize and snap windows, open a terminal and more

• Preinstalled PulseAudio with support for applications running as spot

• Preinstalled Blueman, with Bluetooth audio for applications running as either root or spot

[s243a]

It sounds pretty cool. I'll try to find time to give it a try. Have you considered building a 32bit version?

[amethyst]

Yes, a 32-bit version will be nice seeing that it will be 'pure' with debian only components. Peebees, new "Ubuntu" releases are a bit of a mixed bag if I understand it correctly.

[dimkr]

It sounds pretty cool. I'll try to find time to give it a try. Have you considered building a 32bit version?

Should be fairly easy. Will do.

Yes, a 32-bit version will be nice seeing that it will be 'pure' with debian only components. Peebees, new "Ubuntu" releases are a bit of a mixed bag if I understand it correctly.

I don't see the need for this mix n' match thing, it can only make Puppy less compatible with Debian and Ubuntu. And having a fully automated build process is super important, because I want dpup OS to be a good 'barebones' base for puplets that's reproducible by anyone.

EDIT: in progress, in https://github.com/puppylinux-woof-CE/woof-CE/pull/2187.

dpup OS is basically the dpup Bullseye template in woof-CE, but with PUPMODE=6 and the update mechanism. Once the 32-bit dpup is in, I'll add automated builds for a 32-bit dpup OS.

[TerryH]

First few runs look very good. Initial first run set up completed and connected to wifi successfully. I did notice shutdown/reboot is intermittently not completing successfully and ending up at a tty1. Typing poweroff, just returned to tty1 and a hard shutdown is necessary. This seems to be OK with no apparent negative effect doing this as follow up boots seem OK.

The version I downloaded from github was version 9. The update process appears to have updated to the same version. Maybe some extra messages as it is updating would be helpful for users, as it was doing this update , which took a while, I wasn't sure if it was doing anything. Booting after the update was successful.

Edit: I just noticed that the update process updated to the same version, was because it has actually created a whole new directory. The original image has a directory dpupos-x86_64-1rolling9. I now have a second directory created dpupos-x86_64-1-rolling9. The original symlinks have been recreated and pointing to the new directory, as shown in the screenshot attached. The original directory is now redundant.

Edit 2: when I now run the System Updater I now get the message that indicates that there are no new updates. It would be nice if the final messages displayed bu the updater indicated that the processing is finished and the window can be closed.

[TerryH]

I tried using PPM to install audacious . I went to do step by step to see what was going to be installed. The number of missing dependencies kept growing, the last count displayed was about 238 missing, then PPM advised cancelling and manually installing deps first. I cancelled the install.

Edit: I have an audacious.squashfs I had created in busterdog64, I decided to see if it would run if included in dpupos. I copied and renamed changing squashfs to sfs. On boot it was loaded. I had noticed that previously there was no Multimedia category in the menu, this was now listed. audacious ran but wouldn't play local mp3 files, giving file type unknown error. To check I installed via PPM libmp3lame... but still get unknown error. I stopped at this point, as presumably lots of dependencies missing. It was however encouraging to see that the sfs's loaded at boot will run.

I will now restore my original save file backup and try other sfs's and installing software via ppm.

[wiak]

The latest release is available at https://github.com/dimkr/woof-CE/releases, and a new release is built every 3 days. The version number is always 1, and it's the first (?) "rolling release" Puppy.

I haven't tried this github build facility, but I'm curious because I thought github had a filesize limit of 100MB? What is the space availability nowadays for large binary files such as these Puppy builds?

EDIT: useful since keeps the Puppy woof-CE changes up to date in new releases.

[wanderer]

hi dimkr and wiak

using dpup0S now
posting this from it

looks great

william

[wanderer]

hi dimkr

same problem with shutdown
goes to prompt has to be hard shutdowm

if i delete adrv
it will kernel panic on boot

edit
also had to delete symlink to adrv
then worked fine
booting to jwm-rox no applications

all else ok so far

william

[wanderer]

hi dimkr

now that you have made dpupOS

there is no longer any reason
for me to work on (annoy people about)
a modular puppy system
since dpupOS is such as system

i will continue to work on my minimal modular system
which is based on a tinycore/dcore initrd not the puppy initrd

and the simple build system

1. a repository of modules
2. a module make script
3. an iso builder script
4. and text templates for each iso

that i have come up with

but i no longer have to tear my hair out trying to minimize the fossapup64 main.sfs file

so i would like to thank you
for doing all this work
and for creating dpupOS

i will continue to follow along
and test as best i can

thanks again

william

[wanderer]

hi dimkr

with adrv removed
system shuts down normally
no need for hard shutdown

william

[dimkr]

EDIT: useful since keeps the Puppy woof-CE changes up to date in new releases.

Automatic builds with updates not only sync Puppy with latest woof-CE, but also with Debian. For example, if Debian's OpenSSL gets patched to fix https://security-tracker.debian.org/tra ... -2021-3450, Puppy's OpenSSL gets updated to the version with the fix. Same for bugs - if a Debian package receives a bug fix, this bug fix propagates to Puppy.

It's good for both security and stability.

there is no longer any reason
for me to work on (annoy people about)
a modular puppy system
since dpupOS is such as system

It's not the same. dpup OS is not exactly the modular Puppy you're looking for.

First, not every application is a module. Second, the main SFS contains JWM, ROX-Filer, the tray icons, basically a barbones Puppy desktop without applications, and I understand that you want to have the Puppy desktop (JWM, ROX-Filer, etc') in one SFS, and the X server in another. Third, it still uses the idea of "SFS loading" and not Tiny Core style symlinking, albeit without the use of sfs_load, Puppy's initrd, etc'.

Whatever you're doing - keep doing it, we probably can learn from each other.

[dimkr]

It sounds pretty cool. I'll try to find time to give it a try. Have you considered building a 32bit version?

A 32-bit build is cooking at https://github.com/dimkr/woof-CE/runs/2216258334

[dimkr]

Edit: I just noticed that the update process updated to the same version, was because it has actually created a whole new directory. The original image has a directory dpupos-x86_64-1rolling9. I now have a second directory created dpupos-x86_64-1-rolling9. The original symlinks have been recreated and pointing to the new directory, as shown in the screenshot attached. The original directory is now redundant.

Yes, @TerryH, every time you update, the new version is downloaded to a new directory and the symlinks at the boot partition root are updated to point to it.

It's impossible to delete the old version while it's still running, and having the old version around allows rollback (maybe I'll implement this feature in the future). The symlinks make the update of a single SFS 'atomic', in the sense that there's no need to copy the entire SFS to the partition root, just change the symlink. Also, at boot time, the symlinks are resolved, so version y of a SFS file is written to a different location and the mounted version x can still be used without corruption, until reboot.

I had a bug there that made version x update to version x, and I fixed it. I'll see if it's back again, once the next build after 9 is out.

Also, I'll see if I can implement some cleanup mechanism of old versions (keep just the last 2 or something).

EDIT: fixed 9->9 update bug in https://github.com/dimkr/woof-CE/actions/runs/697086623.

[amethyst]

A question - This being a rolling release, what steps are taken to address possible stability issues. Have changes thoroughly been tested before applying. Does this mean that one basically have to use the latest off the conveyor belt for the best results?

[dimkr]

A question - This being a rolling release, what steps are taken to address possible stability issues. Have changes thoroughly been tested before applying. Does this mean that one basically have to use the latest off the conveyor belt for the best results

The assumption is that woof-CE changes are tested by their author, and shouldn't cause issues. Most of the time, this is true.

Other than this, because we stick to Debian Bullseye (as opposed to, Debian testing/sid), the only changes are bug and security fixes, so nothing should break.

Does this mean that one basically have to use the latest off the conveyor belt for the best results

Some things can break or cause issues, especially woof-CE changes.

With all that said, dpup OS had automated tests that boot it in QEMU, start a terminal, run the browser and open a tab, etc'. They ran for every build, and every build where the tests failed was discarded.

The tests were slow and failed very often, even if nothing has changed. I'll re-implement them, and then dpup OS will be much more unlikely to break.

Another option is to have two release streams of dpup OS: "stable" and "rolling", where stable is derived from the "rolling" release, say, twice a year, and receives only cherry-picked woof-CE bug fixes (sometimes, it's not trivial to do this cherry-picking from a new woof-CE to an old woof-CE) and Debian updates. The mechanism to allow this is already in place - /etc/pm6_updater.conf specifies a "release channel" and every "rolling release" build is a beta.

[amethyst]

Thanks, I think an additional, "stable" production and release line is a good idea. Should give the more cautious users some peace of mind.

[dimkr]

Thanks, I think an additional, "stable" production and release line is a good idea. Should give the more cautious users some peace of mind.

I opened https://github.com/puppylinux-woof-CE/w ... ssues/2191. A "stable" dpup OS release channel is definitely possible if woof-CE has a "stable" branch.

[amethyst]

Thanks, I think an additional, "stable" production and release line is a good idea. Should give the more cautious users some peace of mind.

I opened https://github.com/puppylinux-woof-CE/w ... ssues/2191. A "stable" dpup OS release channel is definitely possible if woof-CE has a "stable" branch.

[wiak]

Third, it still uses the idea of "SFS loading" and not Tiny Core style symlinking, albeit without the use of sfs_load, Puppy's initrd, etc'.

So does it also include sfs_load 'on-the-fly' after boot, and if so, do these overwrite the main puppyXXX.sfs files when same names? I noted you are now using overlayfs rather than aufs - is that correct?

[wiak]

I haven't tried this github build facility, but I'm curious because I thought github had a filesize limit of 100MB? What is the space availability nowadays for large binary files such as these Puppy builds?

I'm still curious regarding this github autobuild and any storage limitations in case I try that sometime?

[dimkr]

So does it also include sfs_load 'on-the-fly' after boot

Nope.

these overwrite the main puppyXXX.sfs files when same names?

Nope. Every dpup OS version has a directory under boot partition, and every SFS has a symlink on the partition root:

dpup-os-1-x/1.sfs
dpup-os-1-x/2.sfs
1.sfs -> dpup-os-1-x/1.sfs
2.sfs -> dpup-os-1-x/2.sfs

During update, the new version is unpacked to a directory:

dpup-os-1-x/1.sfs
dpup-os-1-x/2.sfs
1.sfs -> dpup-os-1-x/1.sfs
2.sfs -> dpup-os-1-x/2.sfs
dpup-os-1-y/1.sfs
dpup-os-1-y/2.sfs

Then, the symlinks are updated to point to the new version:

dpup-os-1-x/1.sfs
dpup-os-1-x/2.sfs
1.sfs -> dpup-os-1-y/1.sfs
2.sfs -> dpup-os-1-y/2.sfs
dpup-os-1-y/1.sfs
dpup-os-1-y/2.sfs

Overwriting the SFS while mounted will result in issues, like inability to read /bin/busybox and reboot may not work, or X may crash, applications may not start, and so on.

But replacing the symlinks is safe, because the symlinks are resolved before the SFS files are mounted (https://github.com/dimkr/frugalify/blob ... ify.c#L181), so the mounted SFS is not modified on disk.

I noted you are now using overlayfs rather than aufs - is that correct?

Yes.

[BarryK]

Fascinating!
I wrote it to a Flash drive and booted up.

Was most curious about the /init executable, got the source:

https://github.com/dimkr/frugalify

Quite simple. Is there any reason why a script wouldn't work, if uses ash and applets from busybox compiled statically?

And of course, there would have to be busybox executable in the partition, alongside init.

It would be slower, but just scanning through the code, it seems that a shell script could do all of that.

Hmmm, but the C init is a much simpler and smaller way of doing it.

[dimkr]

Quite simple. Is there any reason why a script wouldn't work, if uses ash and applets from busybox compiled statically?

And of course, there would have to be busybox executable in the partition, alongside init.

It would be slower, but just scanning through the code, it seems that a shell script could do all of that.

Hmmm, but the C init is a much simpler and smaller way of doing it.

Yep, a small, single executable is ... a small, single executable. Doing it in C has the advantages of not having to put busybox with ash, losetup, mount, etc' on the boot partition, and the advantage of not having to build two busybox binaries, one for the "initramfs" part and another to put inside the main SFS.

[wanderer]

hi dimkr

what kind of compression do you use for the main.sfs
i could not open it with uextract

thanks

william

[TerryH]

hi dimkr

what kind of compression do you use for the main.sfs
i could not open it with uextract

thanks

william

Opened without issue here using uextract. I did it twice, it even opened when I used the symlink, rather than the direct sfs.

[dimkr]

what kind of compression do you use for the main.sfs

Zstd, and you can use unsquashfs instead.

[dimkr]

Build 14 is faulty: the fdrv is missing. It shouldn't be a problem for those who upgrade to it from a build that has a fdrv.

https://github.com/puppylinux-woof-CE/woof-CE/pull/2192 should fix it, and https://github.com/dimkr/woof-CE/actions/runs/700301006 (build 16) contains the fix + a safeguard against successful builds without a fdrv.

[wiak]

I haven't tried this github build facility, but I'm curious because I thought github had a filesize limit of 100MB? What is the space availability nowadays for large binary files such as these Puppy builds?

I'm still curious regarding this github autobuild and any storage limitations in case I try that sometime?

Why is this question not getting answered?

It would be certainly be useful for other distros discussed on this forum to be able to run the likes of Github Actions to build isos in the cloud, but I can't see how to do that without expensive paid plan? Otherwise this forum community would be breaking the github terms of service, which would hardly be professional or reasonable to other github users:

https://docs.github.com/en/github/site- ... ions-usage

for example, don't use Actions as a content delivery network or as part of a serverless application

https://github.com/pricing

https://docs.github.com/en/github/manag ... disk-quota

https://docs.github.com/en/github/setti ... ub-actions

Is then our community paying from forum member contributions to large storage on GitHub? If so, that storage could also be useful to other distros that this forum community draws contributions from. What contributions are being used for should be declared to our forum members.

Since free plans (personal or organisation) only allow 500MB storage with file size limits of 100MB this new Puppy build at github using their CI Github Actions suggests at least Team (2GB storage) or Enterprise (50GB storage) paid github use.

Otherwise, how do you manage it - am I missing something that would be useful more generally for our other forum-discussed distros such as the various Dogs?
https://lab.github.com/githubtraining/g ... ntegration

I only asked this question about 'how?' and repeated it thereafter, because I wanted to try similar for WeeDogLinux builds but didn't see how to do that within such file storage restrictions, but I can't but wonder why my simple question for help about this is being ignored (twice prior to this) as if something wrong with it.

[dimkr]

This quota is for files stored in the repo, not releases.

This use of GitHub Actions is not "any other activity unrelated to the production, testing, deployment, or publication of the software project associated with the repository where GitHub Actions are used", and the "2,000 Actions minutes/month" quota of Actions should be enough for dpup OS (assuming every build is 2.5 hours, there are two builds a week, and every month is 4 weeks, 60*2.5*2*4 = 1200 minutes).