Hi wanderer.
Please read my reaction to your proposal here.
TIA. BFN.
alternative puppy build system
Hi wanderer
I see you have made a new topic for work on woof ce next.
It has already been busy there
I will move to the other thread with report/comments about woof ce next from now.
I am not sure I really want all of woof ce next.
I explain.
What I want to find out is what is really core puppy.
I do not want that core to be debian or slackware or ubuntu or bsd, but Puppy.
It should not be minimal, but it should not have apps.
It should boot to X and it should have the Puppy wm (jwm+rox)
and internet connection
and terminal
and maybe some other puppy utilities
and package installer/manager and sfs load.
The PM is crucial
I don't know whether that should be sc0ttsman's Pkg or the one from mistfire's xslacko slim or a combination.
Then you can choose to assemble a spup, dpup, upup or a hybrid.
You could make a desktop Puppy or a server or ...
Wanderer, you will say now "that is dcorepup".
Yes, almost,
except I would like to build the Puppy core in Puppy with 'woof ce next core'
I see you have made a new topic for work on woof ce next.
It has already been busy there
I will move to the other thread with report/comments about woof ce next from now.
I am not sure I really want all of woof ce next.
I explain.
What I want to find out is what is really core puppy.
I do not want that core to be debian or slackware or ubuntu or bsd, but Puppy.
It should not be minimal, but it should not have apps.
It should boot to X and it should have the Puppy wm (jwm+rox)
and internet connection
and terminal
and maybe some other puppy utilities
and package installer/manager and sfs load.
The PM is crucial
The PM should be versatile enough to install packages from a lot of different repositories on the Puppy core.s243a wrote:I suspect that schotsmann 'pkg" is more fault tolerant.
I don't know whether that should be sc0ttsman's Pkg or the one from mistfire's xslacko slim or a combination.
Then you can choose to assemble a spup, dpup, upup or a hybrid.
You could make a desktop Puppy or a server or ...
Wanderer, you will say now "that is dcorepup".
Yes, almost,
except I would like to build the Puppy core in Puppy with 'woof ce next core'
I posted this elsewhere, but I think it is worth repeating my comment about woof-next here:
That is a philosophical question. I know you have tried Fatdog, do you consider Fatdog as "Puppy"? Why or why not? How about DebianDog? How about Lxpup?
@foxpup: I do not want that core to be debian or slackware or ubuntu or bsd, but Puppy.
The last Puppy that wasn't based on others is Puppy Racy (and Puppy Wary for older machine). These were puppies where the package was compiled from source by Barry himself, using T2-SDE. There is no other Puppies like that ever since. The closest one you have is Fatdog; we compiled our own packages from source too; not even using T2-SDE but we use our own system (fatdog-pkgbuild).
@foxpup: It should not be minimal, but it should not have apps.
This is difficult question. Is "bash" an app or not? For someone who uses "busybox ash" as a shell, he/she will consider "bash" as superflous and therefore is an "app" and should not be in the core. But others (like musher0) will say that busybox is an abomination, we need "the real deal" like "bash" and therefore it is __core__.
I'm exxegerating but I hope you see my point - what is considered as "apps" by one, may be considered as "core" by others ...
@foxpup: It should boot to X and it should have the Puppy wm (jwm+rox)
wanderer will say that X is not core and should be in a separate SFS ...
----------
Anyway the point of a having a build system, is so that __you__ can easily specify exactly what goes into the system.
----------
@foxpup: The PM should be versatile enough to install packages from a lot of different repositories on the Puppy core.
This has been said too many times. I did not comment on that previously, but I'd say what I think; and this comment is not specifically addressed at you foxpup, but to everyone who thinks that "oh this is such a great idea!".
A counter example: Lets run Ubuntu Bionic (the real stuff, not BionicDog or Bionicpup, but the real deal). Then try to install a package from Ubuntu Xenial (for example, you can take any other versions other than Bionic). See if you can get it to run.
Case in fact: a change in openssl alone will make a lot of Fatdog 721 packages (that uses openssl) to fail to run on Fatdog 800. Even though all of these packages are compiled by ourselves!
Now you want to pick and choose packages from slackware, ubuntu, debian, devuan, tcore, redhat, opensuse ...
Don't get distracted by packages like "firefox" or VirtualBox that can be downloaded and run on many different distros. These packages are built in a special way, with special tricks, that most distro packages aren't.
Can an Ubuntu package runs on Slackware-based pup (or vice versa)? Of course. Under certain conditions. But if you expect that you can mix and matches packages freely from different distros will cause you a lot of grief.
"Pkg" helps you to install packages from different distro; and it does it well. But it doesn't guarantee that the installed package will run.
and also(this was a response to wanderer).
Be my guest. As I said, look at it, test it, learn from it, take it to pieces and use anything useful from it, fork it, improve it ... do anything you want to do with it.
My original intention when I wrote the post about woof-next is because you said "you wish there is a smallish woof-ce build system" so I want to say "well here we are, a 600-lines build system" which should be easy to learn (and perhaps adapt).
You __do not__ have to use it for anything if you don't like it; if you can learn from it to improve your own stuff that it has achieved its objective. But if you do want to improve it and use it as a base, of couse that's welcome too.
@foxpup: What I want to find out is what is really core puppy.(response to s243a)
But remember: the value of woof-next is its build system. Its "puppy essence scripts" which I extracted from Woof-CE is now very dated; and it does not include the new stuff; because I did not spend the effort to sync it from Woof-CE anymore.
Also, even back in 2014/2015 when it was still alive, woof-next did not build a __finished__ system. Look at my original posts; I offered woof-next for puppy developers who were interested in alternative build system, alternative package management (using parent distro's package manager instead of PPM), and interested in building barebones system. I was offering a __build system__ that can easily be customised; I was no offering a __alternative finished puppy__. Now "barebones" means minimal amount of packages; and this means some puppy scripts will not work because the dependencies were not included. These was meant to be fixed by the puppy devs: either by fixing the puppy scripts; or installing more dependencies that is needed to make it run.
That is a philosophical question. I know you have tried Fatdog, do you consider Fatdog as "Puppy"? Why or why not? How about DebianDog? How about Lxpup?
@foxpup: I do not want that core to be debian or slackware or ubuntu or bsd, but Puppy.
The last Puppy that wasn't based on others is Puppy Racy (and Puppy Wary for older machine). These were puppies where the package was compiled from source by Barry himself, using T2-SDE. There is no other Puppies like that ever since. The closest one you have is Fatdog; we compiled our own packages from source too; not even using T2-SDE but we use our own system (fatdog-pkgbuild).
@foxpup: It should not be minimal, but it should not have apps.
This is difficult question. Is "bash" an app or not? For someone who uses "busybox ash" as a shell, he/she will consider "bash" as superflous and therefore is an "app" and should not be in the core. But others (like musher0) will say that busybox is an abomination, we need "the real deal" like "bash" and therefore it is __core__.
I'm exxegerating but I hope you see my point - what is considered as "apps" by one, may be considered as "core" by others ...
@foxpup: It should boot to X and it should have the Puppy wm (jwm+rox)
wanderer will say that X is not core and should be in a separate SFS ...
----------
Anyway the point of a having a build system, is so that __you__ can easily specify exactly what goes into the system.
----------
@foxpup: The PM should be versatile enough to install packages from a lot of different repositories on the Puppy core.
This has been said too many times. I did not comment on that previously, but I'd say what I think; and this comment is not specifically addressed at you foxpup, but to everyone who thinks that "oh this is such a great idea!".
A counter example: Lets run Ubuntu Bionic (the real stuff, not BionicDog or Bionicpup, but the real deal). Then try to install a package from Ubuntu Xenial (for example, you can take any other versions other than Bionic). See if you can get it to run.
Case in fact: a change in openssl alone will make a lot of Fatdog 721 packages (that uses openssl) to fail to run on Fatdog 800. Even though all of these packages are compiled by ourselves!
Now you want to pick and choose packages from slackware, ubuntu, debian, devuan, tcore, redhat, opensuse ...
Don't get distracted by packages like "firefox" or VirtualBox that can be downloaded and run on many different distros. These packages are built in a special way, with special tricks, that most distro packages aren't.
Can an Ubuntu package runs on Slackware-based pup (or vice versa)? Of course. Under certain conditions. But if you expect that you can mix and matches packages freely from different distros will cause you a lot of grief.
"Pkg" helps you to install packages from different distro; and it does it well. But it doesn't guarantee that the installed package will run.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
My rule of thumb here is that if the package was built on a system that has the same version (or slightly older) of the base libraries (e.g. glibc) then it will likely work, however one might have to do a few things such as:jamesbond wrote: @foxpup: The PM should be versatile enough to install packages from a lot of different repositories on the Puppy core.
This has been said too many times. I did not comment on that previously, but I'd say what I think; and this comment is not specifically addressed at you foxpup, but to everyone who thinks that "oh this is such a great idea!".
A counter example: Lets run Ubuntu Bionic (the real stuff, not BionicDog or Bionicpup, but the real deal). Then try to install a package from Ubuntu Xenial (for example, you can take any other versions other than Bionic). See if you can get it to run.
Case in fact: a change in openssl alone will make a lot of Fatdog 721 packages (that uses openssl) to fail to run on Fatdog 800. Even though all of these packages are compiled by ourselves!
Now you want to pick and choose packages from slackware, ubuntu, debian, devuan, tcore, redhat, opensuse ...
Don't get distracted by packages like "firefox" or VirtualBox that can be downloaded and run on many different distros. These packages are built in a special way, with special tricks, that most distro packages aren't.
Can an Ubuntu package runs on Slackware-based pup (or vice versa)? Of course. Under certain conditions. But if you expect that you can mix and matches packages freely from different distros will cause you a lot of grief.
"Pkg" helps you to install packages from different distro; and it does it well. But it doesn't guarantee that the installed package will run.
1. Create symlinks when the version doesn't exactly match; in some cases one can adjust LD_LIBRARY_PATH instead of creating symlinks. For example debians LD_LIBRARY path has the architecture name in the path.
2. Possibly modify configuration scripts, and other state information
3. Possibly modify startup scripts
4. Possibly modify post Install scripts
mistfires version of the puppy package manager is nice in its ability to download packages from a large diversity of places but I worry that this might create problems with dependency resolution.
Different versions of Linux name their packages differently and the pet.specs info used In puppies package manager doesn't specify a minimum version like the control file does in a .deb package.
P.S. the things above that I say one might have to do are when things go well. When thing go very Wong on might have to deal with segmentation faults or missing and/or incompatible symbol. Perhaps changing the directory permissions might help with segmentation faults and one might be able to deal with incomparable symbols by using a symbol stripper or loading the application in a non standard way (e.g. LD_PRELOAD or chroot) but normally these kinds of errors aren't worth troubleshooting!
I don't usually feed the troll. But today is a good day, and I can use some amusement. Sorry wanderer - I hope this does not distract you too much
2. In fact, I am not a developer at all.
3. As I said here: http://murga-linux.com/puppy/viewtopic. ... 43#1027143, and if you do read that and follow the linked page, you will arrive at here: http://murga-linux.com/puppy/viewtopic.php?t=94101, which, among other things, says:
Nobody expects you to find bugs. Just like not all people like puzzles. In fact, I never play jigsaw puzzles with 1000 pieces. I find that a complete waste of time. Yet I don't go to all shops telling them that they should not sell 1000-pieces jigsaw puzzles because "it will require me to hunt for a solution to the puzzle for days on end; it is not OK".
woof-next is a __build system__. To make it into a fair comparison, you should compare that with another build-system that our beloved founder Barry released. What is it? Oh, it's Woof2 (which is the predcessor of Woof-CE), the very system that you continously mock day in and day out.
I also said why debian sid build will no longer work; and again you say I'm just blaming upstream. You know that "debian sid" is "debian-next", right, which is just a tad behind "debian-experimental"? Unlike other debian releases, which is frozen in time after they're released, "debian-sid" is a rolling release and changes everyday. You expect to use puppy scripts and patches from 5 years ago to work against build against today's debian packages?
Whatever it is you've been drinking, I certainly want some
1. I am not a Woof-CE developer.The devs at woof-CE have the knowledge: they would readily know what to correct in
their product,
while we common mortals will hunt for a solution to their bugs for days
on end. That is not ok.
2. In fact, I am not a developer at all.
3. As I said here: http://murga-linux.com/puppy/viewtopic. ... 43#1027143, and if you do read that and follow the linked page, you will arrive at here: http://murga-linux.com/puppy/viewtopic.php?t=94101, which, among other things, says:
I put all the disclaimers there. If you don't like it, you don't have to participate. But if you don't participate, then your comment is as good as arm-chair sports commentator.jamesbond wrote: The iso will boot to a command line (pfix=nox). There is only minimal packages included in the ISO, they are mainly shell, command line utilities, Xorg, jwm, rox-filer, urxvt and mtpaint for testing.
...
...
Important Note:
1. This is meant for puppy builders.
2. It does *NOT* build a working puppy as you know it. Still needs work in terms of adding the correct packages, minimising the build (deleting unnecessary stuff), and obviously, fix the brokenness.
Nobody expects you to find bugs. Just like not all people like puzzles. In fact, I never play jigsaw puzzles with 1000 pieces. I find that a complete waste of time. Yet I don't go to all shops telling them that they should not sell 1000-pieces jigsaw puzzles because "it will require me to hunt for a solution to the puzzle for days on end; it is not OK".
Did I release a Pup?Our founder BarryK never did that. When he published a Pup it was usable OOTB.
With maybe a few details to adjust, but that was it.
woof-next is a __build system__. To make it into a fair comparison, you should compare that with another build-system that our beloved founder Barry released. What is it? Oh, it's Woof2 (which is the predcessor of Woof-CE), the very system that you continously mock day in and day out.
Hahaha. I already said that in my linked post why the ubuntu build will fail, and you blame me for blaming upstream. Now tell me, where can I find URL of a working, original ubuntu trusty thar repository. (not just an archive of debs, but real dpkg repository).Comment on your 1st sentence:
It is unfortunately very human to blame the guy upstream...
I also said why debian sid build will no longer work; and again you say I'm just blaming upstream. You know that "debian sid" is "debian-next", right, which is just a tad behind "debian-experimental"? Unlike other debian releases, which is frozen in time after they're released, "debian-sid" is a rolling release and changes everyday. You expect to use puppy scripts and patches from 5 years ago to work against build against today's debian packages?
Whatever it is you've been drinking, I certainly want some
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
hi foxpup
dcorepup (and the other puppy inspired systems) are not puppy
and that has always been the problem
that is why i set up this thread
now no one can say we are not making a "real puppy"
the other reason is that puppy can be improved and expanded
i agree that using puppy components
is the way to go to make a real puppy
but i also want a more general system
that can take components from all sources
the unique parts will have to be done individually
not a general download
that is why woof-ce-next
and hopefully my modular system
will be useful
they are small enough to be modified to do many things
so puppy will be able to evolve
woof-ce-next could build a general puppy
say from devuan
and then things could be added to it from other sources
they could be kept in a small repository
so they could be accessed
whenever one wanted them in a build
you could build a minimal puppy
or a big puppy
or anything in between
the core of puppy
is the initrd image
(which is a few basic components)
and the init file
they could stay relatively static and minimal
and the variation is just what is linked with them
my modular system will even have one form
where the main system is symlinked directly to the initrd
so i think this is the way to go
thanks for all your help everyone
wanderer
dcorepup (and the other puppy inspired systems) are not puppy
and that has always been the problem
that is why i set up this thread
now no one can say we are not making a "real puppy"
the other reason is that puppy can be improved and expanded
i agree that using puppy components
is the way to go to make a real puppy
but i also want a more general system
that can take components from all sources
the unique parts will have to be done individually
not a general download
that is why woof-ce-next
and hopefully my modular system
will be useful
they are small enough to be modified to do many things
so puppy will be able to evolve
woof-ce-next could build a general puppy
say from devuan
and then things could be added to it from other sources
they could be kept in a small repository
so they could be accessed
whenever one wanted them in a build
you could build a minimal puppy
or a big puppy
or anything in between
the core of puppy
is the initrd image
(which is a few basic components)
and the init file
they could stay relatively static and minimal
and the variation is just what is linked with them
my modular system will even have one form
where the main system is symlinked directly to the initrd
so i think this is the way to go
thanks for all your help everyone
wanderer
hi all
i only use
a few basic apps
and i actually like a lot of the old ones
jwm
xterm
leafpad
geany
emelfm
rox-filer
viewnior
vlc
dillo
and firefox
maybe i will try the portable chrome someday
so my distro can be relatively unchanging
once the main things are built
pretty much its just keeping firefox and vlc up to date
and firefox will do that automatically if you let it
if you want a new look you can change the wallpaper
my point is making a basic system and maintaining it
should be manageable if we dont overreach
and that goes in line with the minimal system idea
wanderer
i only use
a few basic apps
and i actually like a lot of the old ones
jwm
xterm
leafpad
geany
emelfm
rox-filer
viewnior
vlc
dillo
and firefox
maybe i will try the portable chrome someday
so my distro can be relatively unchanging
once the main things are built
pretty much its just keeping firefox and vlc up to date
and firefox will do that automatically if you let it
if you want a new look you can change the wallpaper
my point is making a basic system and maintaining it
should be manageable if we dont overreach
and that goes in line with the minimal system idea
wanderer
May I recommend netsurf over Dillo?wanderer wrote:hi all
i only use
a few basic apps
and i actually like a lot of the old ones
jwm
xterm
leafpad
geany
emelfm
rox-filer
viewnior
vlc
dillo
and firefox
maybe i will try the portable chrome someday
so my distro can be relatively unchanging
once the main things are built
pretty much its just keeping firefox and vlc up to date
and firefox will do that automatically if you let it
if you want a new look you can change the wallpaper
my point is making a basic system and maintaining it
should be manageable if we dont overreach
and that goes in line with the minimal system idea
wanderer
Last edited by s243a on Wed 08 May 2019, 17:00, edited 1 time in total.
woof-next: added support to build from 32-bit devuan ascii.
Changes:
1. One line change in setup.sh
2. Symlink deb-build.sh to devuan-build.sh
3. Add devuan distro spec, by copying ubuntu's distro spec and editing repo-url to point to devuan; and editing basesfs pkglist to use "eudev" instead of "udev".
Builds 177MB iso, with 343 packages installed (including gtk3). I used the 3.4.94 huge kernel. Boots to desktop (in qemu).
Not bad for a supposedly dead project.
Changes:
1. One line change in setup.sh
2. Symlink deb-build.sh to devuan-build.sh
3. Add devuan distro spec, by copying ubuntu's distro spec and editing repo-url to point to devuan; and editing basesfs pkglist to use "eudev" instead of "udev".
Builds 177MB iso, with 343 packages installed (including gtk3). I used the 3.4.94 huge kernel. Boots to desktop (in qemu).
Not bad for a supposedly dead project.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Sweetjamesbond wrote:woof-next: added support to build from 32-bit devuan ascii.
Changes:
1. One line change in setup.sh
2. Symlink deb-build.sh to devuan-build.sh
3. Add devuan distro spec, by copying ubuntu's distro spec and editing repo-url to point to devuan; and editing basesfs pkglist to use "eudev" instead of "udev".
Builds 177MB iso, with 343 packages installed (including gtk3). I used the 3.4.94 huge kernel. Boots to desktop (in qemu).
Not bad for a supposedly dead project.
This make more more tempted to try it 
Very surprised how quick it was. Tried the as-is to build a slacko version, put the kettle on and returned to the desk to see it has already built the sfs. Built the iso that also ran through quickly and opended/frugal installed that (grub4dos) and it booted to jwm/rox style gui desktop (with what looked like a early days Fatdog seagull wallpaper). Was expecting the touchpad to not work, but it did.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
hi all
@jamesbond
Thank you for your big response!
You gave me a lot to think about.
Yes I consider Fatdog Puppy, maybe not in some details, but yes.
And LxPup too.
I consider the dogs almost Puppy. But they begin from the other build.
I have never used one btw.
I'm glad you mention Wary. It was my first Puppy. And really, this is what I want again.
I know it is not easy to use another distro's repository, let alone to combine.
For Wary I used Squeeze iirc. I had to try things and some things broke. But it was fun.
I could have chosen another distro's repository, I suppose. I could have tried slackware or fedora or ...
I could try compiling in Wary.
I probably did/tried all of that at some time.
I had to do much more to make Tahr suitable for the old PC I used back then. Something like Pkg could have been helpful.
What do we get when we do not use what comes from debian in dpup Stretch or from slackware in slacko6.9.9.9?
Is it the same thing in both cases? and what does it need to work, to be able?
You understand why I do not consider the Dogs almost Puppy now?
@jamesbond
Thank you for your big response!
You gave me a lot to think about.
Yes I consider Fatdog Puppy, maybe not in some details, but yes.
And LxPup too.
I consider the dogs almost Puppy. But they begin from the other build.
I have never used one btw.
I'm glad you mention Wary. It was my first Puppy. And really, this is what I want again.
I know it is not easy to use another distro's repository, let alone to combine.
For Wary I used Squeeze iirc. I had to try things and some things broke. But it was fun.
I could have chosen another distro's repository, I suppose. I could have tried slackware or fedora or ...
I could try compiling in Wary.
I probably did/tried all of that at some time.
I had to do much more to make Tahr suitable for the old PC I used back then. Something like Pkg could have been helpful.
Let me rephrase that:foxpup wrote:I do not want that core to be debian or slackware or ubuntu or bsd, but Puppy.
What do we get when we do not use what comes from debian in dpup Stretch or from slackware in slacko6.9.9.9?
Is it the same thing in both cases? and what does it need to work, to be able?
You understand why I do not consider the Dogs almost Puppy now?