Another Jammy64pup

[Marv]

Maybe the problem is that USR_SYMLINKS=no rather than USR_SYMLINKS=yes.

OK, so maybe I need to be dragged, kicking and screaming, into the future. Anybody got a good debian compatible huge-kernel I can download?

I have changed the structure of @peebees LxPupSc64 6.1.10 kernel and run it in a USR_SYMLINKS=yes dpup. The changed zdrv is to big to attach but basically I just unsquashed it, moved the contents of /etc, /lib, and /sbin into /usr/ etc, lib, and sbin. Rude but it booted and ran fine. The symlinks required already exist in the main SFS. An analogous process would have to be done on the fdrv if used (I don't). Also, when @OscarTalks was still making kernels he would produce both flavors. I have been wondering how badly the primary build would break making the change: USR_SYMLINKS=yes.

Yep "kicking and screaming, into the future. "

When I was playing with one of the dpups of that flavor, I did manage to break the install with a 'traditional' pet but I knew what to expect wrt that. Could certainly upset the unwary user. We're really caught between worlds at this time. Support the tons of good pets out there or the ubuntu repos.

I've been using the 'traditional' upup A3 as my daily with no tears at all. I had a simple CLI theme switcher for my LXDE pups and updated it to handle the JWM based ones and switch both the gtk-3.0 and gtk-2.0 themes. Haven't put xfce in it as yet because I don't run any xfce pups but it makes playing with themes much easier.

Jim

[dimkr]

When I was playing with one of the dpups of that flavor, I did manage to break the install with a 'traditional' pet but I knew what to expect wrt that. Could certainly upset the unwary user. We're really caught between worlds at this time. Support the tons of good pets out there or the ubuntu repos.

Ubuntu 22.04 packages are not designed to use the old layout: you will run into issues if you break the assumption of Ubuntu developers, that /lib and /usr/lib contain the same files. Some applications installed via apt install (= not via PPM, which is super broken and flawed by design) don't work because they can't find their files.

Breaking some .pet packages (those that put files in /bin, /sbin, /lib and /lib64 instead of their /usr counterparts - a minority?) or breaking many Ubuntu packages ... I think the former is a more sensible default if you want a Puppy to support as many packages as possible out-of-the-box. If you want to build a "Puppy-compatible Puppy" and not an Ubuntu-compatible one, jammy64 is not the right way to do that.

Pick your battles.

[mikeslr]

"Pick your battles" vs. "Blessed are the peace-makers".

A pet converter would be nice.

taersh --a talented but AFAIK not classically trained programmer; occupation musician-- wrote a script to overcome Ubuntu's use of x86_64-linux-gnu folders [which Puppies couldn't find].

taersh's PaDS 1.1.7, https://www.forum.puppylinux.com/viewto ... 6355#p6355 --among other things-- deconstructs debs, moves the contents in folders named x86_64-linux-gnu into their parents' lib folders and creates symlinks named x86_64-linux-gnu to the latter; then repackes the application.

I'd create the aforesaid pet converter. But my scripting skills are at the kinder-garden level; and TBH not even sufficiently sophisticated to be able to follow the logic in taersh's application.

[jrb]

OK, New ISO at page 1 post 1
This one uses overlayfs, debian style symlinks, and kernel 5.15.56-jammy64. Everything seems to work, at least what I've tested. MPV for mediaplayer and DVDplayer, DeaDBeef for audioplayer, Alsaplayer for CDplayer (DeaDBeef too confusing on CD's, at least for me).

Blueman opens, tells me I don't have anything to connect to (true). Maybe someone out there can test it for me.

Try it and let me know what you think.

Cheers, J

[dimkr]

a script to overcome Ubuntu's use of x86_64-linux-gnu folders [which Puppies couldn't find].

Today's woof-CE doesn't force a broken ld.so.conf that requires this kind of hacks. In general, many Puppy hacks can be removed or skipped, making more Ubuntu packages "just work" (Barry's vision when he introduced the idea of a Puppy built from another distro's packages), when things are configured correctly in first place.

@jrb: next time you build, if you run ./3builddistro release, it will also build extras like bdrv (apt and Synaptic), docx and nlsx

[Marv]

@jrb ,

Up and running B1. In a way, using the ydrv for all my configurations is more flexible than a savefile. I moved the appropriate directories from / to /usr in it, added the bit of firmware I need for the one of my laptops that doesn't have an Atheros wifi card, and resquashed it.

First look pretty good, a bit more fan use than I usually hear so I need to check the idle resource use, video driver, intel_pstate governor etc.

Clean boot, panel, pcmanfm looks ok, panel, overall look'n'feel all ok, connman connection survived, portable Sylpheed and Brave OK, posting in Brave now. A very few things need looking at, parcellite not in tray and sda2 wasn't mounted at boot, looks like theme changed, Not much! I'll daily it, check dmesg etc. and chase those things.

I may cobble a pet library libmover script, @mikeslr linked the PaDS-1.1.7 script, probably useful for ideas...

Not a bad leap as they go, thanks!

Jim

[mikeslr]

@ Marv,

Might be easier to 'start from scratch'. As I wrote, I couldn't follow PaDS' logic. But all that should be necessary, I think:

1) Create a temp folder with an appropriate name.
2) Mount the deb.
3) Copy the deb's contents into the temp folder.
4) Copy the files from where they are to where you want them to be
5) delete the original files
6) create a symbolic link at the old location to the location where the files are now
7) dir2pet the appropriately named temp folder.

Coding the above --especially with a GUI-- is above my pay-grade. The GUI should enable the User to choose the location for the temp folder, its name and maybe the location for the output folder if other than adjacent to the temp folder is desired.

'Should' is one of the iffy words.

[Marv]

@jrb , Themes and parcellite back. I was just trying to be too clever by half in my ydrv. Resource use at idle is just fine with the intel_pstate schedutil governor, what I usually use. Just using the new pup at the moment and that's good.

Update: Created a test savefile. My usual toggles work and the structure looks correct for the overlayfs scheme. Again, basically a lazy way to save and move changes into my ydrv. And:

@ozsouths 6.1.6 kernel from viewtopic.php?p=78729&hilit=overlayfs+kernel#p78729 works fine with the /lib and /sbin contents moved to /usr/lib and /usr/sbin and the /lib and /sbin directories removed in the zdrv.

Code: Select all

root@puppypc18099:~$ uname -a
Linux puppypc18099 6.1.6-64oz-ao-PRE #1 SMP PREEMPT_DYNAMIC Mon Jan 16 17:58:29 AEDT 2023 x86_64 x86_64 x86_64 GNU/Linux

Edit: I should have mentioned that if you are using a kernel that supports both AUFS and overlayfs like the 6.1.6 above, pass punionfs=overlay as a kernel parameter to force the use of overlayfs.

@mikeslr If I do write a libfixer it'll be pretty much as you outlined. The PaDS was mostly for possible ideas. I crib a lot when I write my little helper scripts Actually, I never install anything from a deb or pet before I look at it and the manual library move is pretty simple. I 've done it for my ydrv and the 6.1.10 kernel so It is getting faster.

Cheers -and SNOW here now-

Jim

Still SNOWING so:

In upup with overlayfs, iso B1, CDs play correctly in all options. DVD plays correctly with mpv --player-operation-mode=pseudo-gui set as default. Sound checked with youtube on Brave, Slimjet, and un-googled chromium. All portables, all current versions, no tweaking done at all to pulse/sound settings on these i5 based all intel laptops circa 2012.

Quick CUPS/printer setup test. CUPS .desktop missing in /usr/share/applications but it started correctly directly from a browser. CUPS .desktop added, menufix run and restarted graphical server then used it from the menu to set up my networked Brother W2170 laser printer. Firewall working wrt utp anyway. turned it off, CUPS found both that laser and my HP4500. added the Brother, I run it as a HP PCL4/PCL5 laser so no drivers needed that aren't already on-board. The standard line in /etc/hosts, 192.168.10.31 BRN008077ECF5D2, firewall back on and it's good to go. I haven't checked the HPLIP pet for library structure yet so that printer saved for later.

HPLIP library structure was fine, @rcrsn51 latest I think, so installed that as a pet and set up the HP4500 all-in-one. Prints fine, as slick as CUPS and HP can be

CUPS-PDF printing checked also. It's fine, that's not always been the case in several newer pups for me.

[dimkr]

If we go overlay and 6.1.x, maybe we should change jammy64 to use kernels from https://github.com/puppylinux-woof-CE/w ... kernel.yml. The dpup bookworm kernel is 6.1.x, but it's built with a newer GCC, so some out-of-tree drivers won't compile on jammy64.

Maybe I can add an automated bi-weekly/monthly pipeline that rebuilds the Ubuntu 22.04 kernel (plus all security updates and bug fixes to date) with slight Puppy modifications (see https://github.com/puppylinux-woof-CE/w ... s/bullseye) and make it the default for jammy64. But if we go this way, this means no aufs, because aufs will lose support for this kernel version long before the 22.04 EOL.

(Alternatively, I can rebuild linux-image-generic-hwe-22.04 and not linux-image-generic - that's the kernel from latest Ubuntu, backported to 22.04. It's newer and bigger, so it's bad for stability and can lose support for some old hardware.)

@Marv, @jrb, what do you think?

[mikeslr]

Hi dimkr,

You didn't include me among those you've asked. But as perhaps the most vocal opponent to entirely dropping aufs even I would withdraw my objections if using overlays the flexibility aufs provides can be met. These consist of:

1) The existence of tools enabling the creation of SFSes, so that
2) SFSes can be loaded/unloaded on the fly. AFAIK, fredx181's recently published application appears to provide this 2nd ability.
3) Something like amethysts's Utility Suite's Save2SFS which makes it easy to replace a SaveFile/Folder [its user installed applications, settings and customizations] with an automatically loaded at boot-up SFS.
4) A functional and user-friendly remaster tool by which the wasted space and (albeit minimal) RAM usage of applications that are not wanted or have updated versions in a SaveFile/Folder can be eliminated.

Perhaps the foregoing already exist. I've been meaning to run some tests but keep finding more pressing projects.

[dimkr]

woof-CE supports a limited form of dynamic SFS loading with overlay, under PUPMODE 5 (= live boot) or 13 (= pmedia=usbflash) only.

I agree with you, @mikeslr, that the Puppy ecosystem needs to make more adjustments to build an "official" Puppy without aufs, beyond the basic support in woof-CE. However, maybe it will be easier to get that developer attention if we build the jammy64 everybody wants and establish concensus around it.

(That's not the only brave decision we need to make; GTK+ 3, PipeWire and other shiny new things bring their own opportunities and problems. Considering the number of problems it caused in the last year or two, I think now is the right time to teach Puppy to live without aufs.)

[mikeslr]

That are upteen Linux Distros available. If you have a reasonably modern computer you can run any of them AS-IS. What distinguishes Puppy Linux from the pack is that it is designed to be portable, being capable of running from even older computers and still be fleshed out to provide a User's specific needs. AUFS has to a large extent been the mechanism by which that uniqueness was achieved.

Without those characteristics there is no real reason for Puppy's continued existence. What 'market-share' --adoption by new users-- Puppy has will be lost. And with the loss of new users --some of whom bring coding ability and new ideas-- Puppy will suffer the fate of other under-staffed projects. "I remember that. It was good for its time."

While 'necessity is the Mother of invention' if Puppy could only use overlays hopefully someone will provide the inventions necessary for Puppy to maintain its current capabilities. Overlays is a well established and known system. I have no doubt that the utilities I cataloged could be created for it if the necessity is timely realized. But 'Death is nature's way of telling you that you've done something wrong.' My fear is this: there are few of us, even fewer who actually can code, and each of us has his or her own objectives and priorities.

Since Overlays is a known system, I would rather see the tools needed by Puppy developed before AUFS is abandoned rather than incur the risk of throwing the baby out with the bathwater.

[dimkr]

Since Overlays is a known system, I would rather see the tools needed by Puppy developed before AUFS is abandoned rather than incur the risk of throwing the baby out with the bathwater.

I understand. My fear is that Puppy will die before its overlay support matures, because GTK+ 2, X.Org and other hard dependencies of Puppy are on their way out of this world

I'm leaving it for somebody else to decide if we should convince all Puppy contributors to help drop this dependency on aufs right now, to secure Puppy's future, or keep overlay as a second-class citizen and cross fingers. With my dpup series, my intention is to build a low-maintenance Puppy that can receive critical security and bug fixes for several years (even if "official" Puppy dies), so I went with overlay despite the reasons not to. But whoever wins the competition and releases the first "official" Puppy not based on Ubuntu <=20.04 should be the one to decide if it's a one-time release or a long-term project.

[mikeslr]

Thank you, dimkr, for identifying the pitfall I hadn't realized was present. If jrb is willing, this Jammy64pup could serve as a pioneer. Built only to employ Overlays, it could provide the test-bed for the development of the tools I mentioned. If not, well it's fairly easy not to swap in an overlay kernel. Someone could experiment with a different puppy.

[Marv]

Thank you, dimkr, for identifying the pitfall I hadn't realized was present. If jrb is willing, this Jammy64pup could serve as a pioneer. Built only to employ Overlays, it could provide the test-bed for the development of the tools I mentioned. If not, well it's fairly easy not to swap in an overlay kernel. Someone could experiment with a different puppy.

Thanks , I was chewing over @dimkr question and trying to formulate a reply and you just did it perfectly for me. My dime is on @jrb jammypup64 at this point. It's remarkably mature and well balanced, and I think perhaps it might be the driver for wider overlayfs use -and tools- in puppyland. I see your #4, a good viable remaster tool as the furthest out but remastering has always been 'in development' anyway in my (humble) view.

[jrb]

@jrb: next time you build, if you run ./3builddistro release, it will also build extras like bdrv (apt and Synaptic), docx and nlsx

Let me get this a bit more polished and then I'll start the next adventure.

[jrb]

Thanks for the thorough testing Marv. It's much appreciated.

CUPS .desktop missing in /usr/share/applications but it started correctly directly from a browser. CUPS .desktop added, menufix run and restarted graphical server then used it from the menu to set up my networked Brother W2170 laser printer. Firewall working wrt utp anyway. turned it off, CUPS found both that laser and my HP4500. added the Brother, I run it as a HP PCL4/PCL5 laser so no drivers needed that aren't already on-board. The standard line in /etc/hosts, 192.168.10.31 BRN008077ECF5D2, firewall back on and it's good to go. I haven't checked the HPLIP pet for library structure yet so that printer saved for later.

Wow, I've got a Brother HL-2370DW and, with the recommended downloaded Brother driver, it's fought me on every install trying to get PDF's to print. Just used your recommended HP PCL4/5 and it was good to go right out of the box. So easy! Thanks so much!

Missing Cups.desktop? Guess I'll have to do another build. Anything else you want included please let me know.

[Marv]

Missing Cups.desktop? Guess I'll have to do another build. Anything else you want included please let me know.

Not worth a build for just that, just add it to the list and wait for some more things to surface -if they do -

Cheers,

[dimkr]

The CUPS admin page menu entry is probably missing because of https://github.com/puppylinux-woof-CE/w ... .conf#L162.

This line removes the menu entries for the various "wizards" that can be accessed via the buttons in Setup -> Puppy Setup. I can remove this line if you want, although I think long menus are terrible with the 16:9 screens most of us have, and multiple ways to reach the same thing under different names can be confusing.

[Marv]

The CUPS admin page menu entry is probably missing because of https://github.com/puppylinux-woof-CE/w ... .conf#L162.

This line removes the menu entries for the various "wizards" that can be accessed via the buttons in Setup -> Puppy Setup. I can remove this line if you want, although I think long menus are terrible with the 16:9 screens most of us have, and multiple ways to reach the same thing under different names can be confusing.

My personal preference is to access it from the menu. No disagreement about long menus! I use the menu manager to prune and customize the main menu depending on who is using the particular laptop.

@jrb , Continuing to try out this and that. Used Puppy installer to Bootflash to put my install of B1 on a rather elderly 4GB USB2 stick. Install just worked, rebooted to the USB stick and since my install is totally in RAM, used GParted to shrink the fat32 partition and format the balance as EXT2. Put my portables and shared profiles on that partition and rebooted. All good, did it the stone age way intentionally. What took the longest was coming up with a few lines in rc.local to mount my /dev/sda2 as the data partition if available and /dev/sdb2 otherwise and export the correct data partition for my portable symlinks/.desktops. Posting from Brave portable in that now. I'll play with another stick with one of the newer installers at some point, probably from F96-CE_1. In general, daily use with B1 is fine, lidsuspend (to s2idle on these laptops), copy/paste with my add of Parcellite, terminal plonking, un and resquashing, continues good. Another thing to do is to set up Claws Mail and see if I use it in liu of Sylpheed.

[mikeslr]

...My personal preference is to access it from the menu. No disagreement about long menus! I use the menu manager to prune and customize the main menu depending on who is using the particular laptop...

I do the same. But sometimes I install radky's Pup-Control, https://www.smokey01.com/radky/PupMates.html.

PupControl.png (73.4 KiB) Viewed 18501 times

After a Puppy's initial Setup and customization, configuration files are rarely used. Pup-Control will provide access to them when needed. Them and a lot of other applications rarely used. And specific menu entries, other than to Pup-Control, can be pruned from the menu.

[jrb]

The CUPS admin page menu entry is probably missing because of https://github.com/puppylinux-woof-CE/w ... .conf#L162.

This line removes the menu entries for the various "wizards" that can be accessed via the buttons in Setup -> Puppy Setup.

And PuppySetup is right there on the top jwm-tray. Oh well, "Old dog, new tricks".

[jrb]

Just adapting "Another Jammy64pup" to the latest local WoofCE. It has some nice improvements, MPV petbuild now plays DVD's if you add css libs, libblas.so.3 and liblapack.so.3. Figured out how to get DeaDBeef more user friendly playing CD's, still doesn't autostart but click the play button and it starts. Palemoon petbuild has quit working, seems like the download source has disappeared, I can hack in the latest Palemoon if need be. Don't have to worry about the Cups.desktop now.

[Marv]

Grub2 configured USB stick also boots and runs fine. Both boot and Data partitions are EXT2, set up with GParted. boot directory top level with the other upup files, grub.conf copied from inside boot to the top level, grub2config run on it (in f96-CE_1). punionfs=overlay (I'm running an AUFS and overlayfs kernel) added to grub.conf and it's up and running. At this point I've sucessfully passed that kernel parameter in grub4dos, syslinux, and grub2 boots. Mostly just testing as I only use a USB stick boot when I've done something really really bad.

Palemoon not missed here. My rc.local addition continues to do what I want to access my portables. Since /dev/sda2 existed, it was mounted and my portable shortcuts aimed at it. MUCH faster than launching them from the old slow USB2 stick but that's automatic if I'm on a computer without the data drive & portables.. I thought about putting a Brave portable in /opt for the USB sticks but the little bit in rc.local can actually be in all my ydrvs so one size fits all there.

This old dog can probably live accessing CUPS from Menu>Setup>Puppy Setup. If not I can easily carry the .desktop in my ydrv.

Next Claws Mail.

Update:That was quick, This version of Claws Mail built without imap support.

Cheers,

[Clarity]

Hi @jrb This is a really nice WoofCE PUP advancing with the polish you are providing. Thanks

Here's my stanza for successful booting your latest version.

Code: Select all

qemu-system-x86_64 -enable-kvm -vga std -m 2G -smp 2 -device AC97 -name "Jammy by JRB via QEMU" -cdrom upup-22.04-jrb-B1.iso

P.S. Will this PUP's name ever advance to a 2023 year naming? I am using v22.04B1

Screenshot.png (194.27 KiB) Viewed 18424 times

Maybe something with a "yymmdd" naming of sort...or is the naming for benefit of Ubuntu convention

[dimkr]

Just adapting "Another Jammy64pup" to the latest local WoofCE. It has some nice improvements, MPV petbuild now plays DVD's if you add css libs, libblas.so.3 and liblapack.so.3. Figured out how to get DeaDBeef more user friendly playing CD's, still doesn't autostart but click the play button and it starts. Palemoon petbuild has quit working, seems like the download source has disappeared, I can hack in the latest Palemoon if need be. Don't have to worry about the Cups.desktop now.

Fixed:

https://github.com/puppylinux-woof-CE/woof-CE/pull/3925
https://github.com/puppylinux-woof-CE/woof-CE/pull/3941

(and the mpv library issue won't happen if you ./3builddistro release instead of ./3builddistro)

@Marv I pushed https://github.com/puppylinux-woof-CE/woof-CE/pull/3946 into woof-CE, to restore all menu entries including duplicates. Let me know if you regret this

And I'll see what I can do about IMAP support in Claws Mail. Sylpheed still uses GTK+ 2 and it will go away one day. EDIT: testing https://github.com/puppylinux-woof-CE/woof-CE/pull/3947, will merge if it works EDIT 2: merged

[Marv]

@dimkr Thanks for the Claws Mail imap. I'll test it when it pops out. As for the menu duplicates, I'll look at the menu 'with duplicates' but as I posted above I don't have any real problem without them. The only one I missed so far -old habits- was the CUPS and that was easily added to my ydrv.

@peebees kernel kit produced LTS 6.1.13 kernel has both AUFS and overlayfs support and with the kernel-modules structure tweaked appropriately is running fine in the overlayfs jammypup64 iso B1. About 100MB higher memory use in overlayfs than in F96-CE_1, a pretty comparable AUFS install, 326MB vs 230MB. These days, that's a gnat. Idle CPU use equal and very low in both.

Edit: Bold my thoughts on the 100MB delta. Cheapskate that I am, all of my laptops have only 4 to 6 GB RAM each

[dimkr]

About 100MB higher memory use in overlayfs than in F96-CE_1

That's the price you pay for replacing Ubuntu 20.04 packages with newer and bigger ones from 22.04, plus bumping the kernel to 6.1.x

I hope people won't refuse to use jammy64 only because it's slightly heavier, because many things are just so much faster (for example, zstd compressed SFSs are much faster to decompress, and openssl 3.0.x supports ktls).

I see something similar in dpup: I ran two equivalent builds (same selection of applications), based on Debian 11 and Debian 12 packages (kernel 5.10.x and 6.1.x, respectively). The latter is ~2 years newer in terms of package versions, 123 MB (16%) bigger, and this translates into extra 123 MB of RAM in use when SFSs are copied. On top of that, the new kernel and other packages consume more memory (about 50 MB more, in a quick glance).

(And by the way, memory usage is generally higher with overlay because save2flash can't delete files from pup_rw - deletion triggers undefined behavior in overlay and eventually leads to data loss or corruption)

[mikeslr]

Just a follow-up to my concern about going entirely-overlay before some tools aren't developed. One I mentioned was
"3) Something like amethysts's Utility Suite's Save2SFS which makes it easy to replace a SaveFile/Folder [its user installed applications, settings and customizations] with an automatically loaded at boot-up SFS."
Well, such tool isn't necessary as the overlays already provides that capability. Save2SFS's effect is more easily implemented with overlays.
I've been reading the KLV-Airedale's thread to re-familiarize (or TBH learn). Didn't get far before I discovered wiak had already advised of the following, viewtopic.php?p=50302#p50302:
In part summarizing, providing a 'boot-menu' entry with the argument 'w_changes=RAM2 mode ...causes that external upper_changes folder to simply be mounted as top read-only layer on next boot (so not being written to at all in that mode). That's, as I've said, like PUPMODE13"

But I had forgotten that he also advised:
"prior to reboot if you rename the existing upper_changes with a 2-digit number in front of the name (e.g. 50upper_changes, on next boot that will be loaded at layer 50 as a read-only layer..."
If I've understood that, it provides an easier to implement equivalent of creating an adrv or ydrv. Plus, it avoids the 'which SFS/contained applications/files have priority' problem. The number you assign determines priority.

[jrb]

@dimkr - Have written a small script

Code: Select all

#!/bin/sh
cd /usr/lib
for i in `ls *.so*`; do ln -s /usr/lib/$i /usr/lib/x86_64-linux-gnu; done
cd /usr/lib64
for i in `ls *.so*`; do ln -s /usr/lib64/$i /usr/lib/x86_64-linux-gnu; done

When tacked onto the end of /usr/local/petget/petget I think it will allow the use of most Puppy .pets in modern debian without modification. Preliminary tests look good. Feel free to improve (or reject) it.