Quirky Sourcery: source-based Linux distro

Under development: PCMCIA, wireless, etc.
Message
Author
scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

#21 Post by scsijon »

nosystemdthanks wrote:please dont give up on void.

its one of the best things out there right now, they will be alright if enough people care about whats going on over there.
/cut/

keep it alive-- if void has a good tool, use it! for you and for void itself-- do both of you a favour.
I have no intention of giving void's xbps away. But until they sort themselves out I cannot justify the time to continue to work on ?puppyfying an interface. There is always the option of their top level guru (currently missing but legally still in control) saying no you can't use it because...., as Sourcerer's did to his group when he went commercial with it and that cost many thousands of hours free work by many people having to be scrapped before they started again at the last fully free version and built their clone from there.

However, I need to do something while time is available, as from the middle of July until some time in late October I am needed elsewhere most of the time again and won't have the free time needed to move this project on. I wan't the matrix of it sorted out from my mind and onto paper, otherwise it could just turn stagnent, die due to matrix complication levels, or just become useless for it's proposed purpose.

Oh, and i'm still (just) within the timeline I origonally wrote up back in January, although a little slippage will occur . I can and will give Void until I return in October to sort themselves out, as most of the pre-work for that has already been scoped out, just needing to be matrixed neatly on paper. Then I must make a decision to keep going or put it in mothballs until next year if Void looks like it will need just that amount of extra time. I can in the meantime play with the only alternative i've found with that's easy to convert, the old gpl version from Sourcerer, but that's going to take a lot of work to update to become usefull and I really don't want to go that path.

As you can guess from the above, for my sanity, I still need to do it all by myself at this point as it's mostly in my head (and a few hundreds of scraps of paper).

The following stage in either case, will be when I call for a few volunteers (scriptors and bacon-coders first please) to work with me to create a testable and somewhat functionable alpha. If you want to be involved from that point I can only request / suggest you go and learn / practice how to work with one of them.

EDIT1: 4 june 2018. It seems that the new void linux group are sorting things out and will have from approx 15 june2018 (or as soon as possible after that) a new website at voidlinux.org and the files at github.com/void-linux/. The old ones will work for now although they will not be updated. I consider therefore I will await until after then before looking and if possible progressing again using void's xbps and xbps-packages. It basically means I only have to work out if I use a musl base or not and i'm tempted 'not', at least for the test build as I'm considering using BarryK's Easy Pyro x86-64 for that.

scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

#22 Post by scsijon »

Just an update on what';s happening with this.

Yes, i'm going to use Void'a xbps and it's xbps-package sets

No, i'm not going to build a full system directly, at least for now or the near future. That's not an easy thing, even for them.

I am going to follow barryk's metodology as he is with early puppy through to oe and build a compiled packageset, then use woof to do the rest.

No, i'm not using systemd for those who asked for it, see the security forum for why not, I don't think it's safe enough.

On the other hand I may use runit, depending on how many packages come out with it needing it as it's void's standard and incorporated in the xbps package build system. I like it's methodology and it would help with security, even if running as root as you can have a number of control levels.

I may also add toybox as I do like some of it's features.

I "am" looking at building a selfbooting cd/dvd, and a "unpackable-to-parition" version where you as root unpack the compressed file to an empty partition and set your boot mechamism (grub or whatever) to start it, and off you go. Whether I do an image for a memory stick etc. will depend on my thoughts at the time as I think I would prefer the application (sorry the name escapes me for the minute) that allows you to start an iso on a memorystick.

I'll finish this later today.

User avatar
nosystemdthanks
Posts: 703
Joined: Thu 03 May 2018, 16:13
Contact:

#23 Post by nosystemdthanks »

scsijon wrote:No, i'm not using systemd for those who asked for it, see the security forum for why not, I don't think it's safe enough.
ive said it already, repeating it probably wont help here.
[color=green]The freedom to NOT run the software, to be free to avoid vendor lock-in through appropriate modularization/encapsulation and minimized dependencies; meaning any free software can be replaced with a user’s preferred alternatives.[/color]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#24 Post by BarryK »

scsijon wrote:I am going to follow barryk's metodology as he is with early puppy through to oe and build a compiled packageset, then use woof to do the rest.
I have been "quiet" for the past week, not posting to my blog. Reason, have been working on my OE port:

https://github.com/bkauler/oe-qky-src

What I have been attempting is to introduce Qt5 and apps. OpenEmbedded/Yocto have a 'meta-qt5' layer:

https://github.com/meta-qt5/meta-qt5

It works, however, it had a ripple-through affect and broke the building of many of my packages. I found it too difficult to fix.

So, I have been investigation building qt5 myself, creating a recipe from scratch, without using meta-qt5 at all.

I discovered that qt5 can be compiled without qmake, just using autotools. It worked for x86_64 host and x86_64 target, but not for a aarch64 target.

I am now on the track of fixing aarch64 build.

After getting qt5 built, I then want to see if can build apps, such as Audacious and Scribus.

I hope to upload to github in a couple of days. It has been slow going, OE is complex, qt is complex!
[url]https://bkhome.org/news/[/url]

oui

#25 Post by oui »

bravo scsijon!

I remember a long dialog with an helping devoloper of NuTyx at the time where Thierry Nuttens (the creator of NuTyx and long year along de facto only one developer of the core of NuTyx, where Pierre did add the KDE each time where NUttensThierry did publish a new linux tYX core) (*1 did give us the desire to build by compilation each release of NuTyx ourself on each PC where NuTyx get installed... Working versions of Sourcery etc. were yet available at some repositories. Only one were not ideal: The origin of the used sources (LFS / BLFS) I did say to that friend.

As the future of Slackware were not known and not previsible, and not so much of sources were ported to LFS / BLFS (at that time less as today!), I did find that LFS is not really the best idea. With LFS sources, NuTyx did build a big core, the compilation time were terribly long (is documented on the forum of NuTyx, Thierry itself did explain how long it was with his own high performance PC...) (*2 .

The second and third approach I did know at this time were Puppy from Scratch out the time of the first stable Puppy version and the SliTaz from Scratch being especially interesting because all sources of the first SliTaz version are (yet until now, I suppose) on line and the SliTaz from Scratch book an help (in my own language, (*3 :wink: ). Second force of the SliTaz method: Christophe, the at this time French only speaking creator of SliTaz did explicitly name the places where he did download all sources of his small system: always as far as available at the depository of the creator/actual official head maintainer of each application (it makes more activity to get all sources at a different places, but as the system were and continue to be so small, it was not a main problem or difficulty if you did want to rebuild somewhat like that core system but with other stuff (later, in SliTaz 4.0, but SliTaz 4.0 has no book "SliTaz 4.0" from Scratch, it did become a bit easier because of the splitting of the initrd in 4 parts, Russian doll initrd, each part for a next stage of the end stage core! As it is completely easy to list the installed packages, you can easily grown your system...). The process were entirely manually but the way was especially clear because of the compact SliTaz from scratch book (*4 . Aleksej, the actual main developper in end of version 4. and new version 5. / soon version "next" or perhaps lxqt, did begin to modernise that SliTaz from scratch book for the field of his own work. It is not a real book any more but a part in the new English based SliTaz wiki (it would be wrong to see for important details in the French version: SliTaz is now an English distribution). I don't know if he wants continue his scratch book for the awaiting "next" / lxqt version.

But the main problem stay to be the same: You can only get fast a collection of sources at the central depository from Debian/Devuan (depending of the starting system you prefer): it is the reality and the only one way to build a distribution from source without limit. It is exactly the way that Devuan goes but it is easier as Devuan will to be a clone of Debian without systemd and not change the content, not strip and not preserve some old libraries to shrink the new system. but Devuan will do that for the complete Debian stuff, perhaps!

Ideal would be the system from Thierry Nuttens building each package really from sources, they are no binaries from LFS/BLFS, no way to procede differently... but adding a build receipt to do that in automatic as the differences from version to version of LFS are often not giant: available old receipts are a good start position. The only one detail not optimal is, that he uses the LFS sources, as a lot a packages are not offered by LFS / BLFS: for no freaks but users of Linux having real need of special software it is not good, because you often only can to renounce because of the amount of new dependencies required by those softwares. not only in case of professional software but also software for all people like "gramps" (genealogy based on python, you need a lot of python extensions, and modern genealogy require stuff like geo position etc.), or, comparable "merkaartor" (needs today also a lot of extensions), etc.

good would be a system using Debian/Devuan sources directly, because it is not rolling (*5 and it is de facto without limit! more: you can get easily DVD collections of each main stable release (and sometime of the last subrelease, so Jessie, with the sources! so you can easily instead "pinning" integrate if you want your goodies of old Debian versions killed by Debian in the new stables :wink: !

you will not be confronted with your discover with sourcery:the stuff is not available any more! or the stuff is retired because of commercial use!

sourcery did not disappear yesterday but years ago (I have probably a version on an old HD, I have all my old HD. But as it is complicate to reactive them, I have to say it would be very difficult to find on which one today...).

NuTyx does about the same... and more,

as it can manage as well building from sources as installing from binaries about in automatic processing (see http://nutyx.org/en/documentation#3 ) with his new administration software named "cards", an achronym for that what it does. But you will get only the stuff of LSF / BLSF, excellent if you want all that: LXQt, MATE, LXDE, KDE5 and XFCE! For me JWM is always enough (*6 , but not enough if you needs special applications...

Adds from 14.7.:

(*1 yes, about 10 years along did NuTyx be the work from only 2 men and include a full Linux LFS, only available as book, with the content of the KDE base! It is possible an both people find over that time to discuss problems extensively just in time at the NuTyx IRC channel and in the NuTyx forum. Over that the documentation were always updated, and Nuttens did modernize his site and create and maintain his git ... And no stress. I suppose that, if it was possible, that the method is powerfull :idea: . The main job were always get the new stuff out the LFS book, a book, not a ready to use sources package, to compile the new stuff and set and debug the system, exactly like in Sourcery. The profit to do that using the LFS book is that the LFS community is since years ago a very large community (The Sourcery community were always a small and splitted community, you did describe it correctly at the Puppy wiki!)

(*2 as the core of NuTyx (LFS) itself is absolutely not small! This is the reason, why it is important to see what small distributions like Crux and/or SliTaz offer to arrive to the point to be just sufficient core distribution.

(*3 I can only write what I will, because I use only MY selection of English vocabulary in the method of BASIC English (you want impose English? Also help the rest of the world to adopt it!!!) from C. K. Ogden and I.A. Richards , also in a bad English and read short texts like separate forum messages, because I never did learn English, exactly like a lot of African or Asiatic people (speaking more than one language each day. SliTaz did be created by a Swiss man living in a split country and immediately confronted with this difficulty. More languages were never a problem for the most little of the great stable Linux distributions and 4 languages were always build in in that most little Linux although it were the most little distro :wink: ... It continue to be a problem in Puppy! No way to select the US INTernational, yes, international says the "INT" in Puppy. Yet in SliTaz 1.0 stable it was possible to use each official language of Switzerland (except Romansh... but I suppose the Romansh people prefer it so to economize the job to translate as all speak an other of the 3 other Swiss languages German, French, or Italian).

(*4 as well as the 3 great administration's applications Tazpkg, Tazlito (LIveTOol), Tazwok entirely written in bash and completely explained in the SliTaz Handbook...

(*5 we did all see what did happen with the wonderful Arch puppy's : short months after they was published no way any more to use the new Arch stuff: You have to publish new version only to maintain the wheel round and avoid it become quadratish!

(*6 I prefer very much functionality, like Puppy did always offer with his complete environment, as eye candy... Eye candy can be offered as extensions packages (Sourcery, her derivates, or Mandragora Linux were not especially some Eye candy distributions :lol: )

My considerations:

- revitalize the idea of Sourcery, YES
- with the machine of Sourcery, No
- which environment?
- tools from SliTaz in pure bash (and, in the background, remembering the SliTaz uncommon installation's methods) AS WELL AS
- machine from NuTyx
- adapted for Debian source packages
- plus one added receipt (like NuTyx did do for the LFS sources)!

(you can get all sources packages of a in one of your partition preinstalled Debian version using only a short line of bash (idem for the Debian binaries... ! Install the image of your goal in a conventional Debian or Devuan installation eventually with more stuff you will use after stripping to remplace stuff from Debian, like Devuan does with systemd, stripp, but don't stripp all foreign languages: the Linux system is actually a silly dilly system, the language as to be a separate core being able to be exchanged 1:1 through an other each time and to stay resident in a system with other as long as needing! And let the NuTyx script modified for Debian source do the rest in some kind of Sourcery would do it! Remember: to install Debian from binary packages, you need only 5 elements: a depository, wget, ar, yes, only ar, debootstrap and good setting up manual or software! Debian installer is only needing to install a "political" configuration favorising some kind of software like Commercial Mozilla, or some great inventions like systemd or from the windows world like mono... you are not free any more! The same has to be realized from sources packages, and after that you are really completely free...)

scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

just an update

#26 Post by scsijon »

I'm building on an ?old? i5 I was given.

I'm using barry's quirky beaver 8.7.1 as the basis and already found a problem of a couple of missing packages http://www.murga-linux.com/puppy/viewto ... 31#1006531 if anyone's interested.

Already built and installed the main xbps ok, now to add the xbps-packages, sort paths out and build a bootstrap set to test with.

I intend to remain using woofq for building the basic system (been building long enough that for most of it I don't need my notes anymore) and ppm remains as the main package installer, but when I have sorted out xbps to work from Quirky Sourcery it will be available (I hope) to update and add packages from the void-linux system.

OH YES, can I please make clear AGAIN, that I DO NOT INTEND TO BUILD WITH SYSTEM-D, so don't ask me to build one with it, the answer is NO.

scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

temporary halted

#27 Post by scsijon »

In full agreement with the responsable team currently running the Void-linux system, Quirky Sourcery will not at present continue to attempt to use their system software!
It doesn't mean that it won't be used or worked at a later date, it just means they have problems to sort out and need a number of outside groups (like me) not to 'rock-the-boat' in the meantime.

NO FURTHER COMMENTS ON THIS (END OF DISCUSSION) PLEASE.

On the otherhand, it means I can go back and re-look at two others I started looking at earlier too see if they are as possable as at least one seemed.

EDIT: They have a few legal issues to deal with, and a number of people have been asked to stop until it's sorted out. Shame about that, but it does ocassionally happen, even when the gpl is involved. As I like their system and had a basic puppy'd system running I will be back on it if possible when it's cleared.

In the meantime i've written off both other contenders as too many changes to puppy's format to do.

I'm also using the time to help Georgp with nano-x. The thread's on easyos if anyone's interested. I may build a sfs for bever, in which case i'll start a thread here. I'm also wondering if it could be an alternative to x11.

User avatar
nosystemdthanks
Posts: 703
Joined: Thu 03 May 2018, 16:13
Contact:

Re: temporary halted

#28 Post by nosystemdthanks »

ive actually been using xbps for binaries for months now, as my primary setup, and its pretty broken.

im actually far more reassured by your note that its not where it needs to be-- than i could possibly be by someone insisting that it is working as it should. because i finally had to install qemu from the tinycore repos (i couldve used debian, thats a bigger pita...) just so i could run things in a vm again!

other than the package management, void linux is delightful. please dont give up what youre doing, whatever tools you need. i waited 10 years for something like librepup, and this is the coolest thing since that.
[color=green]The freedom to NOT run the software, to be free to avoid vendor lock-in through appropriate modularization/encapsulation and minimized dependencies; meaning any free software can be replaced with a user’s preferred alternatives.[/color]

Post Reply