Puppy Linux Discussion Forum

UPupEF32 is the latest version of UPup.
It is built from a combination of Ubuntu Eoan Ermine (STR 19.10) and Focal Fossa (LTS 20.04) components using Woof-CE.
The combination is required because Ubuntu have reduced their support for 32-bit components and Focal Fossa no longer has all the components needed to build UPup. For UPupEF, 239 components come from Eoan and 1066 components from Focal (see attachments - remove -false.gz).
Eoan Ermine reached EOL in July 2020 (end of life Short Term Release) and will receive no further updates.
Focal Fossa being LTS receives support until April 2025.
Groovy Gorilla (STR 20.10) will be released 22 October 2020 and will be supported until July 2021.

So the question to be discussed is "What should UPup be built from when Groovy Gorilla is released?"
Possibilities:
1. Do nothing - continue with UPupEF and ignore GG
2. Update Focal components to Groovy (if available) - UPupEG (but stay with Eoan)
3. Update to Groovy and replace as many unsupported Eoan components as possible from a "Deb" build that still provides 32-bit components (e.g. Debian or Devuan or Trisquel?) - but is there any logic to support such a mixed system? More sensible? to forget Ubuntu for 32-bit Pups and wait for the DPup developers to make the next DPup32.....
4. Something else?

Thoughts welcomed.... particularly which EE components will potentially cause problems from being unsupported.

5. Build from pure focal, (omitting Eoan debs), rebuild missing packages as pets, rebuild with pets filling the gaps.

Thats probably 4a. hadn't thought of that one!

Wow - 239 pets - huge amount of work..... would it be worth it? One of the reasons for using a mainstream distro's repo is that they do the keeping up-to-date for us..... and given that 32-bit seems to be deprecated.....

Groovy Gorilla as 64bit only - Slackware and bring back Devuan and Debian as bases and possibly Arch. I use your Archpup32 - damn good pup that.

Having said all that your EF/FF mixed Pup was very stable and worked well but I wonder how long that combo can last.

I'm a noob.
I have no idea of the work involved.
But since you are so good to ask..

I would forget 32bit upup and leave it to dpup.

Radky made very nice 32bit dpups, but seem to be elsewhere for now.
His dpupStretch is probably one of the most stable builds for older and not so old computers,
which are the target for 32bit puppys.
There is also a dpupBuster from radky.

But José still makes and maintains 32bit dpups (64bit as well).

Perhaps I'm wrong. But it doesn't appear that debian has discontinued 32-bit systems yet. There is a 32-bit debian 11. https://www.debian.org/releases/testing ... ase-notes/. I wonder how many of the 239 packages you've had to use in UpupEF32 from eoan could have been obtained instead from the debian 11?.

hi peebee

i use upupbb32 which is great
and i intend to keep using 32 bit systems because 64 bit systems seem to cause problems for me
hopefully i can continue to use the ones you develop

for what its worth from a non guru
my opinion is that if the distro stops fully supporting 32 bit
you should drop it and use one that does
like debian
why fight a losing battle
there are many distros that will continue to support 32 bit for the foreseeable future

wanderer

Or Devuan Wanderer - it is afterall a non-systemd distro and that makes it easier to build from. Other possibilities are void (man a void pup would be cool), Alpine and fedora32 and manjaro32 linux

yes devaun seems cool (no systemd)
i don't know about void etc

whatever makes it easiest for peebee

and a distro that has support for 32 bit as long term as possible
maybe less need to completely redo every single thing each time

for me a user the polish and functionality of the distro is paramount
i really am not aware of the underlying donor distro

wanderer

I like the sounds of Devuan. Does it have enough software to draw on?

greengeek wrote: ↑Fri Aug 14, 2020 8:09 am I like the sounds of Devuan. Does it have enough software to draw on?

Yes because they have to clean up a lot of debian stuff of systemd and fix some their botchups. Have their own repos.

Since I'm not the one one doing the work, another vote for Devuan.

i also vote for devuan

but what does peebee think about all this


wanderer

Hm, I don't get the point...

...why wasting time on short term distros anyway?

For older 32bit hardware, there should be enough Puppies already available.
New Puppies getting bigger and bigger, so they won't even fit into the available RAM of older 32bit computers.

I have an old 64bit computer, 2GB RAM with mainboard from 2009 where Puppies up to Tahr are running good.
Any Puppy beyond Tahr is not usable as it slows down very quickly and runs out of RAM.
Even playing Music only using Clementine slows the whole system down.

it is very nice for us that peebee is willing to build 32 bit puppies
his work is a great gift to the puppy community
it certainly is useful to me
i use upupbb32 as my main distro on all my computers
all 64 bit

in my experience 32 bit systems run much better than 64 bit systems
even on 64 bit hardware

the fact that there are still a lot of people using 32 bit systems
shows there must still be some value to them

but really we need to move on
why develop 64 bit systems they will soon be obsolete
we should only work on 128 bit systems or 256 bit systems
or quantum systems since one day that may be the only system used

but that day is not today

im not going to buy a new computer every time a new chip comes out
i use operating systems to run the computers i have
not the reverse

anyway its up to peebee
and i am interested in what he has to say about all this
since he asked the initial question

wanderer

As UPupEF shows pretty much, there's not much stuff to continue developing 32bit Puppies. Of course one can compile source codes to 32bit binaries, but that's much too much work to go on for. Otherwise Puppy could make a step back to the past where it wasn't built by the use of the binaries of major distros.

But I still don't get the point in developing Puppies based on short term major distro binaries - like e.g. Disco Dingo.

Btw.: I'm also not buying a new computer every time new hardware is available - that's not my purpose and will cost much more money than I have available. I'm also using operating systems for the computers I do own and/or being used by myself.

To claim 64bit operating systems will be obsolete soon is just crap. So, you must be kidding, as this wasn't anything I mentioned anyways. However, change is the only constant thingy in life and it seems to be that there's a change in supporting 32bit computers and/or building binaries for 32bit operating systems. Sometimes one just have to let old things go and move forwards.

And so it is for some programs and/or plugins. I'm doing music and videos using my own build of BionicPup64 which is called ArtStudio64. There's a lot of great software synthesizers for the use as plugins in programs like e.g. Qtractor - which is my main Audio-MIDI-Sequencer for composing music. But most of these great new synthesizer plugins do come as 64bit only. No matter if I want to use 32bit or not. I need to run a 64bit operating system to have these plugins available for composing music - and I don't want to miss these plugins anymore.

wanderer wrote: ↑Fri Aug 14, 2020 10:04 am i also vote for devuan

but what does peebee think about all this


wanderer

FYI fossapup64 was nearly a devuanpup64. It was only that at the start of the project, some of their repositories for the new unstable version were named wrongly and woofce didn't like it. so i carried on the ubuntu line.

taersh wrote: ↑Fri Aug 14, 2020 11:45 am Hm, I don't get the point...
...why wasting time on short term distros anyway?
For older 32bit hardware, there should be enough Puppies already available.
New Puppies getting bigger and bigger, so they won't even fit into the available RAM of older 32bit computers...

Fossa Focal is not a short-term distro.

The problem with older Puppies is that at some point one of the essential activities of computing, having access to websites, will be a challenge if not impossible.
I still boot into my modified Slacko 5.7. It hasn't been able to run a useful Chromium based browser for years; since Chrome 48. Like opera 12.16, you can run Chrome 48: but fewer and fewer Website will grant it access. To run mozilla based browsers required installing gtk3.
But the real stumbling block to maintaining old Puppies is openssl. Openssl is dependent on glibc, and every couple of iterations of openssl the creators upgrade which version of glibc is acceptable. Unlike gtk's, an operating system can only have one version of glibc. Watchdog showed how an acceptable version of glibc can be built into the web-browser, palemoon, with instructions (Import) that it only look within its own folder for glibc. However, I suspect that employing the technique approaches the difficulty of creating operating systems. Moreover, there appears to be a limit on how useful that technique is. No one has published a chromium using it [nor for that matter with builtin nss libs]. And, IIRC, the technique could not be used with palemoon beyond version 27.
Web-browsers are not the only applications dependent on openssl. I understand it to be the protocol used to connect any client software (wget, file-sharing, etc) with any web-based server.
With Google's claimed heightened concern for security (can firefox be far behind?) there will come a point when only the 'newest' web-browsers will be allowed access to the majority of websites.
[There are millions of Websites, but only a couple dozen (hundred?) Web-hosts. To access a website, you have to navigate the software of the web-host. Web-hosts have a commercial interest in excluding access by client software potentially carrying malware. With greater insight into economic reality than my President or his republican supporters, companies running websites appreciate that money does not flow into or thru dead web-servers].
It is true each new version of a major distros has included not only web-browsers which demand more RAM, but other RAM-hogging applications. Following the major distros in that way isn't required.

There's a project for someone: A Puppy capable of running the latest web-browser, but otherwise using applications based on gtk1.

At any rate, its not even just a question of what is practical. I believe it has something to do with the Human Spirit; or even the Nature of Life, itself. The twice given commandment "Be fruitful" is better translated as "Be creative". There is no more alternative to complying with that than to the physical commandment "Two masses will attract each other". We are driven to be creative. As a highly evolved, communicative social species, we each can try to find that individual outlet for the creative impulse where each of our unique training, experience, and interest can best be applied in our own social context. But none of us knows how beneficial any of our endeavors may be.

Seven years ago, 01micko woofed Slacko 5.6 from Slackware binaries. I doubt whether at that time he had any idea that it would still be useful today; or be the progenitor of ScPup64.

mikeslr wrote: ↑Fri Aug 14, 2020 4:27 pmFossa Focal is not a short-term distro.

I didn't say anything about Focal Fossa Puppy. Also, I know it's based on the long term major distro from Ubuntu repositories.

I was talking about e.g. Disco Dingo which is not a long term distro. Also Eoan Ermine is not a long term distro - as far as I know. It's just my opinion, though I think peebee generally is wasting too much time on developing Puppies based on such short term major distro binaries.

Besides my own build of BionicPup64 which is called ArtStudio64 I do have and run a manually modified and optimized for composing music and doing videos N.E.M.E.S.I.S. version of peebee's UPupBB or BionicPup32 which is very fine. I named it ArtStudio32, as it is very similar setup like my ArtStudio64.

The equal version I have done from Disco Dingo however will run only on my main machine. It returns unsolvable problems as soon as I try to run it on another machine - even though it's an equal N.E.M.E.S.I.S. Puppy like done from peebee's BionicPup32.

I once tried to publish this N.E.M.E.S.I.S. Disco Dingo Puppy but another user experienced problems with it. That's how I found out it won't run even on my other machines. And that's also the reason why I removed this Puppy from my Google drive storage and asked rockedge to remove the whole topic from the German section of the forum. Later I made an announcement to publish the ArtStudio32 in the German section of the forum. Though, currently I'm too busy with different things like repairing/updating some of my Tape Decks. So, it still isn't uploaded yet. Probably in the beginning of September 2020...

... Denon DR 210 Tape Deck repairing ...

wasn't the original purpose of this thread
peebee asking where upup32 should go next
we are just making some suggestions as asked
it is up to peebee what he wants to do

upupbb32 works just fine for me
and im sure i will be able to use it for quite a while
since all i need is a browser and media player

so to each his own

wanderer

wanderer wrote: ↑Fri Aug 14, 2020 6:39 pm wasn't the original purpose of this thread peebee asking where upup32 should go next

In Germany we call this: Erbsenzählerei!

In answer to the question "Where upup32 should go next" I just made a suggestion plus a statement to not to waste much more time on 32bit distros based on short term major distros like Disco Dingo and/or Eoan Ermine. Also I mentioned that the new Puppies are almost too big for older computers with low RAM specs like my old 64bit/2GB RAM computer from 2009. This will be equal to older 32bit computers with low RAM specs.

It was you who came up with that shit of e.g.

but really we need to move on
why develop 64 bit systems they will soon be obsolete
we should only work on 128 bit systems or 256 bit systems
or quantum systems since one day that may be the only system used

So, initially it was you who started to gave this topic a different direction.

Sometimes it goes that way and if it's allowed and welcome to start several topics of financial support for the forum by the same person, it should be allowed also to offer opinions in a wide range based on the initial question.

So, I might give some good advice to you in German: fassen Sie sich erst mal an die eigene Nase, bevor Sie sich über die Nase anderer Menschen echauffieren.

yikes

relax my man


wanderer

Haha...

...do yourself a favor, please: follow your own advice and share the tolerance you claim for yourself and your posts/topics done!

You can change kernels with change_kernels - so you can use within limits a series 3 kernel.
e
Anyway getting to the point - Ubuntu made a decision, we have other bases such as slack - no reason why users can't still use ubuntu versions and update their kernel if needed so we don't have to follow ubuntu's release schedule we are Puppy not Ubuntu. But for future releases 64bit is the only realistic option when the Bionics, and upef/ff become to old.

My post may be slightly off-topic, but for a long time now I have avoided traditional repos.

I almost never use the PPM - if I want a package I prefer to get one from another puppian.

Some puppians specialise in portables, some puppians specialise in compiling etc etc. If I want a sip audio package for example I will probably go looking for an OscarTalks or Smokey01 pet - as I have come to trust their experience in that area.

So - I would be keen to see 32bit puppy built on a "big linux" code base, but not relying on their LTS support of pet (or apt-get etc etc) packages.

Let the big guys perfect the kernel and code base but lets build our own pet repos.

Having our own 32bit pet repo would make me feel more confident in our long term future. (That is not dissing 64bit - it's just an attempt to honour our Puppy history of supporting and developing the systems we already have).

Whatever code base is used we can commit to making pets for it for the next ten years. Not every pup has to morph in lock-step with Google browsers.

at the risk of getting jumped on again

i think i agree

i am not even aware of all the cool stuff developed by puppy guys
its hidden all around the forum
it would be nice to have a puppy repository
so we could build puppies from puppy parts
(not that i could do it but i can watch and benefit)

it might make it easier for the devs
the parts would be already finished
and we would be less dependent on changes in the other distros
and this thread is an indication of the problems resulting from that

the amount of creativity in this community is awesome
and should be used and showcased

what big linux code base would you choose
debian devuan ???

as to 32 vs 64 bit
everything may eventually have to be 64 bit
but as of now i think 32 bit still has a lot of life left in it

wanderer

keep it alive !

Puppy was born as 32 bit, so keep it.

Sure, I see also, that the "great" Linuxes stop 32bit-Support,
so do all for 'can compiling things himself' with upup32.
That way, there's a great chance, that 32 will survive,
until nothing of additional sources will work in 32bit.
and maybe also a good Idea, keep it small and modular,
give additional software in separate pets, that anyone can
build his Puppy with the things he want.

additional Hints:
Had tried to compile with upupEF (tried manualy compile rox), but got errors like "Gtk" not found.
Changed compilecommand to show all errors gives missing things, for which Gtk is looking for.
After added these missing Files (from ubuntu.packages), compiling works.
You can see / use the files from the archivex appended to this Post,
had to divide it up in 2 Archives, because of sizelimit here in Forum.
The files are taken out of followin debs:
libfreetype6_2.10.1-2_i386.deb
libfreetype-dev_2.10.1-2_i386.deb
libpcre2-dev_10.34-7_i386.deb
libselinux1-dev_3.0-1build2_i386.deb

Please check, if I am right, maybe the error comes from my 'experiments' with UpupEF

aannndd again, Thanks for your great workk

Fossa + buster:

This is just a 'fleshing out' of my suggestion to use debian packages in place of those 32-bit packages which aren't available for fossa. It's not an original idea. [The last original idea I had was 'there are no original ideas'. But then I realized that Ecclesiastes had that idea 2500 years ago. ] It's just a variation of what Linux Mint has been doing for years: combining (what they consider) the best of Ubuntu and debian.

Ubuntu, itself, doesn't compile all its packages from scratch. They use many debian packages. What distinguishes Ubuntu from debian is that debian's update philosophy is more conservative [perhaps not so much as slackware] than Ubuntu. One of those differences is that debian buster still supports 32-bit architecture even for UEFI. See https://linuxinsider.com/story/debian-l ... 86120.html in general for an overview of fossa & buster. Buster will be supported at least until July 2024. https://www.debian.org/News/2019/20190706

I don't compile. But you probably know I do package applications. While often the opinion I post is a conclusion based solely on research, that is not the case regarding the utility of debian '.debs' when Ubuntu '.debs' are not available. I've put that idea to use on several occasions.

this is just a question
since i know nothing and am able to do nothing
just a user

why not use pure buster (just one whole system) with puppy
puppy + buster

just asking

wanderer

wanderer wrote: ↑Sat Aug 15, 2020 6:31 pm why not use pure buster (just one whole system) with puppy
puppy + buster
just asking
wanderer

That's actually a very good question. The thing is that there already are a couple of Buster Puppies, and a BusterDog. And while there's nothing which says Peebee can't work on his own version, perhaps he's interested in working in an area others aren't.

In theory, Puppies can be binary compatible with any other distro. In practice, I suspect you have a significant struggle to modify woof to generate a Puppy which is not debian, ubuntu, or slacko compatible. [FatDog is woofed, but uses a distinct woof-variant and the FatDog team compiles their own binaries which are 64-bit, albeit FatDog64 is --IIRC-- capable of running 32-bit software OOTB. A 32-bit FatDog would be a great addition. But (a) I suspect a lot of work; and (b) raise the same questions I have about a 32-bit Fossa].

Everything is ultimately a trade-off. Ubuntu Fossa trades off debian Buster's stability and range of target architecture in order to support newer versions of applications on the architecture it does support. But if there were a 32-bit Fossa (utilizing some Buster debs) would the packages available to a 32-bit Fossa be any newer than those of 32-bit Buster?

Maybe the idea I tossed-off earlier has some merit. The only applications which have to be current are Web-browsers (and other web-clients). So you'd need a bare-bones Fossa or Buster with a recent kernel and recent glibc. But how many of the less-computer-resource-demanding applications from the tahr or even precise era could such Puppy support? I know, for example, that gimp-painter, developed for precise, http://www.murga-linux.com/puppy/viewto ... 998#745578 can function under Bionicpup64 (with 32-bit compatibility), and performs everything I could ask of gimp.

What complications would there be? Would a unique repo solve them for the majority of users who, after all, are only attempting to get the most out of what they have to acknowledge is a computer past its prime?