corepup

[nosystemdthanks]

very sophisticated and powerful

arguably powerful, i wouldnt say "sophisticated" but thanks for the compliment.

as soon as time allows i will make tc9 into corepups

i will try copying mcorepup 0.5 to 0.6 and throwing the tc9 url in there, and tell you what happens.

obviously i will not change its core to the corepup 6 core, but if you create a core for tc9 then that can be added too.

if it works, it will be a fun corepup 9 "alpha" version.

by the way, the entire tc 6 repo is 2.6 gb to download. it is 6.8 gb if you open each tcz.

keep up the good work.

[nosystemdthanks]

here is mcorepup 0.6, it is tc-9 based.

has wanderers corepup.tcz but not his custom core.gz (if its tc-9 based he needs to make a core.gz for that version, this does everything else)

i didnt have to change much to make it tc-9 based. i had to change the url of coreplus to the newer one. i had to change the places that asked for 6.x to 9.x so they would download the right packages. until theres a custom core.gz i had to change core.gz to tinycore.gz

the background is there, the gui works-- though i havent tried booting without the usual grub setup yet.

http://murga-linux.com/puppy/viewtopic. ... &id=118090

[wanderer]

hi nosystemdthanks

thanks a lot for this latest mcorepup

when time allows
I am going to change my build system
so that it is compatible with mcorepup

I will continue to use and develop my manual build system
in parallel with mcorepup
since I can use it to come up with new combinations

but over time I see mcorepup
being the primary build system for corepup
and I will begin to use it more and more

thank you for all your work
and great ideas

wanderer

[rockedge]

Corepup-7 (iso = 65 megs)
created from mcorepup06.fig on Puppy Linux Bionic 18.05+8

ran it using the stock settings

[nosystemdthanks]

as an alternative to manual changes and automatic builders, i would like more people to create "recipes" for puppy and for distros in general.

for example, i know that xenial pup ce exists. i dont know what its features are, but i have tools that can take it apart and examine it and spit out a report.

those tools to examine contents eventually turned into tools to manipulate the contents, which you know as mcorepup and mxencore.

recipes are a different idea-- they simply describe the existing distro in terms of what features it has, by naming as many parts of it as possible. so for example, a recipe for corepup 6 might look like:

based on tinycore/coreplus 6.x
jwm default, wbar
icewm fluxbox optional
xvesa
dillo browser
tc/tce/tcz package management



it could be longer and more detailed, but you learn a lot from the recipe.

a xenial pup ce recipe would be longer than that:

based on ubuntu xenial
jwm default, rox
xorg
pale moon browser
petget/pet package management



the tools i created to examine the contents of puppy isos were ultimately going to produce output like this in a large html table-- and to some extent, they can.

the advantage of this simpler way is twofold:

1. people could create a large thread of such recipes, to help document existing versions of puppy (probably no interest, but it would be cool.)

2. people could use recipes to talk about features they want and like and prefer, which would assist people trying to make pups or dogs or distros that are different



there are people who cant (at least, not yet) create a puppy version that does what they want. there are many tools to help them, so most people probably could.

one capability of mcorepup that isnt being used yet, is the ability to create minor modifications.

for example, you give it puppy xenial and a slightly different puppy xenial comes out-- with a few different packages.

yes, there are puppy remaster tools that let you do that. they might even be better, although if youre making minor changes than an automatic remaster script would perhaps be more practical to redistribute than a slightly modified bootable iso.

for corepup fans, some recipes could translate very easily to mcorepup profiles. so if no one else uses this recipe idea, we can if it sounds good to anybody.

"how do i write a recipe?"

just look at a description of any distro or pup, and remove everything but the ingredients and the simplest details.

really, thats all it is. i would clarify further if the need presented itself.

recipe for mcorepup 0.6:

automatically remastered
based on tc9 with corepup changes
includes corepup.tcz but not core.gz (not yet, needs tc9-compatible core.gz)
otherwise, same recipe as corepup 6

thats really all it is.

[rockedge]

posting at the moment from Corepup-7 using palemoon 27.9.3 and it is responsive and quick.
I have been trying out the SCM packages and installed XAMPP 1.8.1 via the App SCM but I can not get the web server or mysql to start. Always a file not found error when using the control script. both the python control panel and the Bash script fail.

the persistence feature is not fully functioning or it just lacks flexibility. I am going to be looking at what is not doing that it could.

some examples of recipes and configurations that are possible to set in the mcorepup06.fig would be helpful to get a good start using it.
. I will look over the documentation a little closer to find some cool features and possibilities.

a clear cut instruction how to use the fig46.py and use FIG in general to create a mcorepup06.fig.py to finally get to the finished ISO.

the entire process is quick on my test machines.

[rockedge]

just to mention.... I set up a corepup construct directory on my prevoiusly built Corepup-7 system and with python 2.7 installed as tcz package was able to successfully make a new Corepup-7.iso at 65 megs using fig46.py and mcorepup06.fig

installed frugally to a HDD using Grub4Dos

[nosystemdthanks]

a clear cut instruction how to use the fig46.py and use FIG in general to create a mcorepup06.fig.py to finally get to the finished ISO.

the entire process is quick on my test machines.

i dont know if this is a question, mcorepup 0.6 seems to be working for you and the instructions posted for using the latest version do not differ from the ones posted earlier on, or the ones youve used before.

hopefully (i want to guarantee, but instead i will say almost definitely) if i changed that i would mention it. when i count out the things you couldnt be asking, i dont know whats left that you could be.

certainly im happy to explain any aspect of fig that you like-- its a programming language i designed specifically around being easier to explain, ask me anything. ask me 20 questions or 100, i will do my very best. but sincere apologies, its not always obvious to me just what the question is. i wrote a book about fig, which i tweaked just for mcorepup users. i assume your question is more specific than what it answers (most questions are.)

when someone fails to convey a request in a way i understand, probably the best shortcut is an example of what would help, stated as "just for example" etc.

note that im still learning new aspects of tinycore. one thing i wonder about is how to reliably get packages to load on boot. the key word is reliably.

i think copy2fs is going to be more what i want as well as what puppy users want. onload.lst is more tc-like, i think-- copy2fs is more puppy like, i think.

whether wanderer agrees (he might at some point, i dont know if he has a position on this) id recommend we all move towards copy2fs as the primary convention--

with the obvious point that people should feel free to load packages in any way that suits them, though we should at least (as maintainers or pseudomaintainers) be able to offer a reliable way to load them.

and i think until that is more predictable, we are going to be at the mercy of a system that is a little mysterious at times. thats not really want you want from a boot process. i think populating the copy2fs is the best way to move towards reliability-- but its something i plan to check out.

i know that its not what wanderer wants from corepup, nor really what i want either, but the most reliable way to put stuff in corepup is actually to put it all in a single package. does that defeat the whole purpose of it? yes, so im not really suggesting that.

"learning how to use tc properly" is probably the better solution for us. whether thats actually going to happen as we deliberately try to change it to suit our whims is another matter.

tc isnt a ufo or even a rocketship, but its different than most distros-- some things that are trivial (through common experience) are simply done in a different way with tc.

i recently moved from debian to void linux, and in that move i went from everything in sfs to everything in ext3 in sfs, but thats still just an extra mount. tc is weirder than that, if only a little. its different enough to mention.

[rockedge]

the documentation and some code examples to set up mcorepup and to be able to boot the OS because there is some interest out there in Corepup. there is someone looking for an OS in the bare minimum that will allow Chromium to run. The OS needs only what it takes to run the browser and connect to the network.

here is the thread : http://murga-linux.com/puppy/viewtopic. ... 49#1000749

I mention it so that there is one place to send somebody to for the info needed to get corepup going.

I am already able on various systems to build and install corepup and now mxencore.....

yes tc and corepup do some mysterious things for sure

[nosystemdthanks]

do you really think that a thread on this forum is the best place for documentation? if you do, i am willing to play along.

wanderers philosophy of everything in a single thread is something i honour as much as i possibly can, because im sympathetic to his preferences and goals. but for documenting what youre talking about, i doubt this thread is the place.

loosely translated: lets find a place for such documentation. be it a webpage, notabug repo, a dedicated thread on the corepup subforum, or even its own thread here. lets not ask people from outside the puppy community to start reading in the middle of a 50-page thread on a forum theyre not familiar with and just "figure it out."

id like your help with this, because (funny as it sounds) you have more experience running mcorepup than i do. sure, i run it. i have a hard drive currently dedicated to running the output of mcorepup.

ive also got corepup running qemu, so i can boot isos directly to find out if they go to gui without my custom /tce folder and grub setup. as to which one of us is more qualified to write a "getting started" guide, its actually you. thus im not asking you to do it, only to assist me a little bit. it will be a far more useful guide to your friend/associate if you do.

[wanderer]

hi nosystemdthanks and rockedge

why don't you guys just open whatever threads or links you need

and just post a reference to the work on this thread

that way people reading this thread can follow what is going on
but other people don't have to feel there is a need
to wade through this whole thread

I try to tell people to go to the end of the thread
but its human nature to try to read the whole thing

I am following what you are doing with awe
I can also just follow the links

thanks for all your work

wanderer

[wanderer]

hi nosystemdthanks

I intend to keep up with the various new versions of tinycore
going to tc 9 next
however I will also keep playing with tc 6.4.1
because it works well on older hardware

the specifics of turning tinycore into corepup
are not important

this thread is just about merging
the tinycore and puppy concepts
(and whatever else anyone can think of)
into an improved system

feel free to use your system
to build whatever version of tc you want

in the end it will all become one thing

thanks again

wanderer

[nosystemdthanks]

I intend to keep up with the various new versions of tinycore
going to tc 9 next

its a goal of mcorepup to run parallel to corepup where possible and reasonable.

i figured the idea of starting with 6.x was for older hardware. it was a good starting place, and so far mcorepup works pretty well if you set 6.x or 9.x in calls to addpackages.

its also good to know that corepup is moving to tc 9 and running a little more parallel to tc. i understand that for you, moving to tc 9 doesnt mean entirely closing the door on 6.x.

this thread is just about merging
the tinycore and puppy concepts
(and whatever else anyone can think of)
into an improved system

understood, thanks.

[wanderer]

hi nosystemdthanks and rockedge

could you please post a short overview of mcorepup on this thread
you guys are moving so fast its hard to keep up

thanks

wanderer

[nosystemdthanks]

i will ask rockedge to guide on what i leave out, or if he prefers, fill it in using his words.

mcorepup is a script to create corepup automatically.

it presently consists of two branches: mcorepup and mxencore. it is written in a language designed for beginners and non-coders, which compiles to python. it makes a lot of calls to bash code too, which arent reasonable or practical to avoid.

mcorepup is the basic / introductory system that has profiles to allow for different people to make different contributions. that wont scale to 1000 contributors, but thats not how it was designed anyway. at that scale, there would be more than one branch. woof doesnt have that many maintainers either.

mxencore is the personal side branch to incorporate more of fig os and xenial pup into the same system that mcorepup is designed around.

both mcorepup and mxencore (which is based on mcorepup 0.5) are capable of producing tcz packages in a way that is fairly convenient and can be as simple as you want it to be. there are some extra tcz-related features in both versions, that can be used optionally.

mxencore incorporates and manages additional files from xenial pup. this is a work in progress, and will actually slow down mcorepup progress a little in the short run-- but ultimately it will probably be merged with mcorepup to help achieve one of corepups main goals-- to mix tc with puppy linux.

the tcz packages mxencore creates can be used directly in corepup or mcorepup.

more to the point, the code from mxencore that creates packages from xenial can be used in mcorepup. its just a bit early to complicate mcorepup with all that, so mxencore is a branch where that can be worked on without making mcorepup too complex.

fig os and mcorepup and mxencore are all part of the distro-libre project, an effort to make distros in general more amenable to user control and automated (rather than manual) remastering and distro building.

[rockedge]

nosystemdthanks

that is an excellent explanation of the entire project....well done!

I am still pushing forward exploring, breaking and fixing....... I do read all messages and documentation.

[wanderer]

hi nosystemdthanks and rockedge

yes thanks for the great overview
it is much appreciated

if you can please post at least updates/notes/links to this thread
so that people (me) reading this thread can follow what is going on

thanks again for all your work and creativity
it definitely is the future of this project

wanderer

[wanderer]

hi nosystemdthanks

my corepup is made up of 4 basic parts

the menu syslinux.cfg and isolinux.cfg
the core.gz with a mod in tc-config
the corepup.tcz with corepup-jwm and the logo and
the corepup-mods directory with everything else

the menu system does not need to be static
because other people use different systems like grub etc

the core.gz does not need to be modified
because the change to tc-config is not used
it was just a demonstration of adding boot codes

so a simple way to make my corepup and your script compatible
is to move the info on the menu and tc-config to the mods directory
and you are then left with the
corepup.tcz and the corepup-mods directory
which can added as components by your script

this is what i will do for tc 9 and above

i will probably build my versions as well
and post them on the smokey01 site
but they will not affect you builds

once again thanks for all your work and genius
i look forward to following the plot

wanderer

[nosystemdthanks]

the stage where you try to merge two entire distros together is the most tedious part: http://murga-linux.com/puppy/viewtopic. ... 94#1001394

and especially when the two distros use different means of organisation.

refracta (devuan based) and puppy tahr are actually really easy to mix together. xenial and tc are equally possible to mix, though more tedious-- there are simply more differences to resolve, which is less fun.

any time its way too tedious and boring, its time to make a little tool for it. even if its a sucky tool that does a very good job and is unmaintainable and pointless to distribute.

for example, i spent more than 45 minutes going through 5000 lines of stuff. then i spent 10 more minutes making a tool with fig (slightly more, not a lot more than a nice bash one-liner, processing arrays and reversing strings more cleanly than rev does.)

10 minutes of custom code saved hours, then i started spending 30 more minutes-- instead i finally spent 10 more minutes adding half a feature to the existing tool i made, total of 20 minutes of fiddling with code saved 2 or 3 hours of drudgery.

but if you dont make the right decisions, you take longer to do boring stuff. thats why this part is not very much fun. its sort of worth it, it gets better as you do it, but only after you do it.

[wanderer]

hi nosystemdthanks

i certainly appreciate all your doing

by making your scripts
you not only allow tasks to be automated
(which may be the only thing
that allows some very tedious tasks
to be done at all)
but they allow others less knowledgeable
to use tools that you invented

like it said i will continue to follow the plot

thanks again

wanderer