The (unofficial) 64-bit Jammy Puppy thread

[amethyst]

Strange as it may seem, there is no official thread for this as far as I can see on this forum. Strange in the sense that Jammy is the latest LTS Ubuntu line which has been going for a while. Delving around lead me to a few attempts that have been made but it seems dimkr's efforts at github is "spearheading" the project (or at least looks like a genuine attempt to establish a community version of this Puppy). However with little information available, I have a few questions with regards to the compiled version on github:
Is this a traditional Puppy? I know it's being compiled with woof-ce but does it work like the traditional Puppys? dimkr's Vanilla Pups are a bit different as far as I know (haven't used it myself so not sure). Just asking as a matter of interest.
In general, what makes this different from what we are used to with say older Puppys, things like: overlays vs aufs, etc.
Which of the traditional applications are included?
Printing/Scanning/networking components included?
What can be done to make this a community version (let's say that it can be listed in the "Mainline" category of this forum)? I know that when dimkr started off some of his projects there were talks about rolling releases, releases once a month, etc.
Need guidance and input here unless nobody is really interested...

Has someone downloaded this version from github, what is your experience, etc?

[rockedge]

@amethyst Today we have completed the F96-CE_RC project for release. It will be offered as a Mainline Puppy Linux release at some point this morning (New York City time). It is a Fossapup64 which was woof-CE generated and then bug-fixed, fine tuned and polished. @radky has done excellent work on this distro to bring it to it's release. F96--RC_CE weighs in at 493 mb ISO.

This is the point we have been working towards and now that we've reached the goal with F96 all new efforts are going to go towards a new Jammypup64 that features the latest in technology learned from making F96.

The question is now which methods will be used to build Jammypup64?

Do we work solely on a woof-CE solution or like F96, generate a base Jammy with the existing Jammy recipe and work up from there using the remaster technique?

All in all I believe that work on a solid community edition of a Jammypup64 can commence starting today.

[Grey]

generate a base Jammy with the existing Jammy recipe and work up from there using the remaster technique?

And what, so it was possible?! And I, like a complete fool, edited the confs so that everything gathered locally and immediately in pure woof-ce without revision (so that everything is considered "according to the rules"). If I knew, I would have taken a bare ready-made system and added all the software and design through PowerISO. Everything would have been ready long ago.

And now I'm "washing my hands". If necessary, take my desktop picture and ASCII graphics for the terminal for Jammy. Well, maybe sometimes I will compile something from the soft (mostly emulators) and post it on the forum.

[Jasper]

@amethyst

I did download a development ISO of Jammy from GitHub.

So not all the applications etc are fully functional.

The menu layout is as follows:

Desktop
Desktop settings
Xlock Setup
Choose locale
Font Viewer

System
Hardinfo
IPinfo
Task Manager
Event Manager
Htop
pSchedule
Gparted
Login Manager
Xlock

Setup
Dependency checker
Package manager
Puppy Setup
Quick Setup
SFS Load
Set default apps
Synaptic Package Manager
Menu manager
Puppy Installer
Remaster Puppy
Remove built-in packages

Utility
GTKHash
Xarchiver
Xdelta
Mo Manager
Grsync
PUDD
Pupsave Backup
Resize personal storage
pMirror
Gexec
LX terminal
Document Viewer

Filesystem
Graphical Disk Map
Rox Filer
pMount
pFind
Partview

Graphic
mtPaint
Xournal++
Viewnior
GColor2

Document
Abiword
Geany
Leafpad
puppyPDF

Business
Gnumeric
Homebank
Galculator
Gmeasures

Personal
Figaro's Password Manager
XPad
Osmo
pClock
pTiming

Network
Bluetooth Manager
Firewall setup

Internet
Palemonn
WeeChat
Clawsmail
Transmission
Pup-Advert-Blocker

Multimedia
DeaDBeeF
mpv
PulseAudio Volume Control

[rockedge]

And what, so it was possible?! And I, like a complete fool, edited the confs so that everything gathered locally and immediately in pure woof-ce without revision (so that everything is considered "according to the rules"). If I knew, I would have taken a bare ready-made system and added all the software and design through PowerISO. Everything would have been ready long ago.

And now I'm "washing my hands". If necessary, take my desktop picture and ASCII graphics for the terminal for Jammy. Well, maybe sometimes I will compile something from the soft (mostly emulators) and post it on the forum.

Your work is very important. The ultimate goal would be to have a Jammypup recipe completed so that woof-CE could build the Jammy! Nothing you have achieved so far should be wasted!

I recommend that you continue to work on the Jammy woof-CE recipe and also if it would be easy enough, work on a Jammy base - remaster version.

No washing hands! Your work will probably be the point we all start from!

[amethyst]

@amethyst Today we have completed the F96-CE_RC project for release. It will be offered as a Mainline Puppy Linux release at some point this morning (New York City time). It is a Fossapup64 which was woof-CE generated and then bug-fixed, fine tuned and polished. @radky has done excellent work on this distro to bring it to it's release. F96--RC_CE weighs in at 493 mb ISO.

This is the point we have been working towards and now that we've reached the goal with F96 all new efforts are going to go towards a new Jammypup64 that features the latest in technology learned from making F96.

The question is now which methods will be used to build Jammypup64?

Do we work solely on a woof-CE solution or like F96, generate a base Jammy with the existing Jammy recipe and work up from there using the remaster technique?

All in all I believe that work on a solid community edition of a Jammypup64 can commence starting today.

Thanks appreciated. My position is that I have data constraints so won't be downloading iso's just for testing. I also want to go 64-bit so may as well go with the latest possible Puppy on offer but it must be a well-tested community version. This is why I'm interested in Jammy in this regard (since I've generally used ubuntu versions all the time). I would be happy with a well-tested version but do have an affinity for the traditional way of how Puppy's were put together and how it operated. Things like aufs retained and so on...

[Grey]

I also want to go 64-bit
Things like aufs retained and so on...

The other day I talked with the developer of one Russian OS. There are also Aufs. He said that he switched to 64 bits only when they became more stable than 32. He switched to PulseAudio only when it became more convenient and better than Alsa (not so long ago). And Overlay is not a competitor to Aufs at all. And he added that "that Japanese guy" (the author of Aufs) did more ten years ago than Torvalds has done so far (in terms of Overlay)

[rockedge]

@amethyst F96-CE operates in the same manner as previous Puppy Linux distro's. Using AUFS and the same save file/save folder mechanisms.
The differences are the bug fixes and application package versions. With some improvements to the existing Puppy Linux methods and a series 6 kernel.

Jammypup64 as far as I am concerned, will also function in the same traditional way and use AUFS for layering the system.

[tosim]

Thanks to y'all for the above posts. I, for one, am gld to read that work will be commencing on JammyPup.

[dimkr]

So not all the applications etc are fully functional.

Which ones?

[Firefly]

great project as puppy has fallen behind and some new hardware and software cannot be installed I can do some testing but cannot find the iso on git.

[Clarity]

BAck at home and saw this thread along with some very important work this past weekend by many members.

On this thread, there is currently discussions toward 3 completely different methods.

Couple month back, @Grey with what appeared to be some input from @dimkr showed a very vialble WoofCE generation. I tested and have used that generation by that collaboration.

ON this thread, it appears that we have 3 (yes three) different approached spoken to.

• @Grey - @dimkr months old approach

• @rockedge visions

• @Jasper's approach

IT is hope that the community can orgnaize in such a way to take a viable base and agree if the recipe for a 'Jammy' PUP can be built in WoofCE such that it generates a "complete" representation of what a traditional PUP should be, OOTB with stability and fixes...if possible.

These people are our premiers contributors and I am in favor of asking each to put aside any differences and choose which of the 3 offerings would be the simplest and easiest generations such that the outcome is not only one of our finest, but also can be structured with instructionz for a user to take the valid recipe of this release and regenerate a PUP identical to our final version, once completed.

There are too many good minds here; to gather for a great production recipe for a Jammy, OOTB...if possible.

[Clarity]

@Jasper , if you add @SAMBA from WoofCE, I will test your creation.

[Clarity]

This is the WRONG THREAD to ask this: But, please move appropriately for PUP and WoofCE developers to see!

One of the problems we have is when a Major release of any PUP is made available, PUP members will take that release and use its REMASTER program to make a version consistent with the Member's feeling of completeness. That member then makes his work available to the forum community.

There are some EXCELLENT remasters in the wild, here.

Problem; The Remaster generates a session-save that has the EXACT name of the original PUP it is copied from. THIS IS A PROBLEM AND many here understand the dilemma that arises when booting the base OR booting the remaster as when a list of sessions are listed using the same name as the base distro.

Request, there should be something in the Remaster that fingerprints (renames) it as a remaster with the sessions it saves VERSUS the original distro and the sessions it saves.

Yes I know we all want users to be savvy, but most of us know ....

And yes I know any user can, at pristine, name the remaster with some personalized name, but it would be better if the remaster has a naming that identifies it as a "remaster" of the ORIGINAL Author's base distro.

Edit: Added 'ORIGINAL Author's base distro' to improve understanding

[mikeslr]

...
Problem; The Remaster generates a session-save that has the EXACT name of the original PUP it is copied from. THIS IS A PROBLEM AND many here understand the dilemma that arises when booting the base OR booting the remaster as when a list of sessions are listed using the same name as the base distro.

Request, there should be something in the Remaster that fingerprints (renames) it as a remaster with the sessions it saves VERSUS the original distro and the sessions it saves...

Someone should examine the code which shinobar used in his remaster-x, https://oldforum.puppylinux.com/viewtop ... c8#p780345. I used it to create Slacko_5.7.2CE. It's GUI included the option to change that the version number, maybe also name (don't recall). I didn't know how it worked. But now I think it edits initrd.

[amethyst]

...
Problem; The Remaster generates a session-save that has the EXACT name of the original PUP it is copied from. THIS IS A PROBLEM AND many here understand the dilemma that arises when booting the base OR booting the remaster as when a list of sessions are listed using the same name as the base distro.

Request, there should be something in the Remaster that fingerprints (renames) it as a remaster with the sessions it saves VERSUS the original distro and the sessions it saves...

Someone should examine the code which shinobar used in his remaster-x, https://oldforum.puppylinux.com/viewtop ... c8#p780345. I used it to create Slacko_5.7.2CE. It's GUI included the option to change that the version number, maybe also name (don't recall). I didn't know how it worked. But now I think it edits initrd.

DISTRO_SPECS in initrd.gz is changed. You can change this to anything you want at anytime by editing initrd.gz. There are initrd editors available. Relatively easy to do. I changed the distribution name of precise_5.7.1. to precise_performer for example (and renamed the Puppy files accordingly). Next week I may want to change it to perfectprecise_performer_version1_2023 or whatever. You have more options when doing it manually.

[Clarity]

@mikeslr your idea seems a good direction. Upon completion of the distro Remaster program it should automatically offer a system generated rename or an option to allow the user to rename it different from the base distro.

Example if the base distro name in the remaster process is FossaPup64, the last function-step of the remaster program would allow a name selection/change; say FossaPUP64_random-name or FossaPUP64_user-choice-name. This way when a session is saved from a pristine boot, the remaster distro will name the save "FossaPUP64_user-choice_save..." (folder/file). This distinguishes it from the original distro which I think some/many/most will agree is important distinction for lots of good reasons.

Just a thought (This is not a bug/fix, thus its priority does NOT address the main distro of this thread's direction. It only addresses the remaster program/process)

[amethyst]

@mikeslr your idea seems a good direction. Upon completion of the distro Remaster program it should automatically offer a system generated rename or an option to allow the user to rename if different from the base distro.

Example if the base distro name in the remaster process is FossaPup64, the last function-step of the remaster program would allow a name selection/change; say FossaPUP64_random-name or FossaPUP64_user-choice-name. This way when a session is saved from a pristine boot, the remaster distro will name the save "FossaPUP64_user-choice_save..." (folder/file). This distinguishes it from the original distro which I think some/many/most will agree is important distinction for lots of good reasons.

Just a thought

No, the remaster script is build for speed. You have more options to change it to whatever afterwards doing it manually. Besides, in most cases only the bases sfs is remastered and the initrd.gz not rebuild or copied like when making an iso.

[Clarity]

The members who do remasters and submit their work to the forum for use and review, build ISOs....not SFSs. Their creations are good but it would be important if those remasters sessions show up as remasters by some indicator in their name.

I do recognize that for the more advanced users they might only be interested in a singular part that the remaster offers. But all offerings probably should have a distinguishing fingerprint.

Again, this is something to consider. If plausible, it will, in the future show up to offer such to those who remaster and who present their offering(s) to the general forum.

This would have to be, of course, a WoofCE addition-adoption to the PUPPY Remaster program

[amethyst]

BTW - As far as the Puppy sfs names are concerned the Puppy init script is only concerned what follows puppy.., adrv.., etc. in the names. You can change to puppy_poof_poop, adrv_poof_poop or whatever. I think you can even have a puppy_poof_poop.sfs and adrv_willy_wonker.sfs for the same distribution. So in general, you only have to change the names of the puppy drives to your liking at the bottom of the DISTRO_SPECS file in initrd.gz and the options are legio when you do it manually. We are going off-topic here...

[rockedge]

The Fossapup64 initrd.gz has the SFS drive name suffix hard coded. We would have named the alphabet drives differently and perhaps now that might happen. But because it involves changing the hard coded naming convention by decompressing the initrd.gz modifying it and the compressing it again properly it doesn't happen that often.

The naming restrictions of the alphabet drives has been a weak point for a while.

The members who do remasters and submit their work to the forum for use and review, build ISOs....not SFSs

I know 3 or 4 of the dev's definitely un-squash and squash SFS files regularly when making a distro with the "remaster" technique. Remember one can completely remaster a Puppy Linux without any script / utility. The root_fs and the alphabet drives usually all need to be adjusted in a complex remaster. Can't make the ISO without the SFS's first.

[Grey]

The main thing is not to forget that any task in the operating system can be achieved in several different ways.
Well, I can't resist telling a 30-year-old anecdote on this topic :

Late 80's. Gorbachev flew to Reagan's ranch to California. And Reagan is wearing some kind of fantastic suit and there are three buttons on his sleeve.
Gorbachev: "Listen, Ronald, what have you got?!"
Reagan: "Oh, this is the latest invention of American scientists! When I'm hot, I press the first button and the suit cools me down. When I'm cold, I press the second button and the suit warms me up. And when I get tired at the end of the working day, I press the third button; the suit gives me a massage, I relax and it becomes easier for me".

The following year, Reagan flew to Gorbachev's country house in the Moscow region. Reagan looks at Gorbachev, and he has some kind of door tied to his back, ass and neck behind him.
Reagan: "Wow, Mikhail, what have you got there?!"
Gorbachev: "Oh, this is the latest invention of Soviet scientists. When I'm hot, I open the door. When I'm cold, I close the door. And when I get tired at the end of the working day, I untie the door and take it off and I relax and it becomes easier for me"
----------|
Okay, Gorbachev actually flew to Reagan's ranch once. But there were no suits and doors, and there were hats :

Reagan_and_Gorbachev_in_western_hats_1992.jpg (21.03 KiB) Viewed 1515 times

[mikeslr]

FWIW, the link from shinobar's remasterX post is broken. But it can still be found here, http://shinobar.server-on.net/puppy/opt/. So can another app he mentioned in that post, mkdist. He explains it here, https://oldforum.puppylinux.com/viewtopic.php?t=94034

AFAICT, both applications extract the original initrd and provide a gui for the user to change the name it provides to a different one in the new version. mkdist is a much simpler application so might be easier to adapt. I don't know whether there have been changes in woof rendering the code unusable. The last remaster I did with remasterX was a Xenialpup64, but being for personal use I didn't bother to change the name of the finished remaster.

[rockedge]

@mikeslr I almost forgot about these tools! Might be what I am looking for...testing needed!

[mikeslr]

On second thought, IIRC the last time I used Remaster-X was with fossapup64. I wasn't happy with 666philb's having packed a lot into the adrv so (after after temporarily removing zdrv, I renamed adrv to zdrv) used Remaster-x to combine everything into the base.sfs (then returned the 'real' zdrv). But I didn't use remaster-X's change name option.