Puppy In-House Development

[nooby]

nooby - UEFI is supported.

Cool thanks

[01micko]

Sorry guys, just taking attention off spammer

[Ibidem]

Iguleder, you may wish to pull from my tinyxlib "blob" branch; it has a couple CVE fixes for libXfont on top of your changes.

[Iguleder]

Yep, saw these awful CVEs, I'll do this when I find a free moment.

[Ibidem]

Yep, saw these awful CVEs, I'll do this when I find a free moment.

That branch is called that because all the object files go into one big blob (libX11.a) . Other than CVE fixes and a couple old buildlogs disappearing, it's identical to your tree.
(The logs were confusing grep.)

On a related subject, I looked at your tinyxserver changes and cherry-picked a few changes (xinit and the amd64 stuff).
But when I realized that the fonts were about 30 MB, I figured it would be better to build fontutils and generate the localized fonts with ucs2any.
Long term, I'm thinking to have ~4 trees:
tinyxlib
tinyxserver
xutils
xfonts
and then set up something to build all of it at one go.

For xutils I'd like to have at least bdftopcf, ucs2any, xfontsel, xkill, xwininfo, xlsclients, xlsfonts, oclock or xclock, xcalc, xmag, xmore, and maybe pixmap, xman, and a couple other tools like sxpm.

[amigo]

Can I urge you all again to make these sources completely independent. All through the sources there are references to installed header files which break the build when doing it on a modern system. I started once to do this, but with several of you working independently it's too hard to keep up as I do other things. Just search for occurrences of '<X11/..> to see what I mean.

I applaud all your efforts -my original work of creating a working build of tinyX has really paid off for you fellows.

[Ibidem]

Can I urge you all again to make these sources completely independent. All through the sources there are references to installed header files which break the build when doing it on a modern system. I started once to do this, but with several of you working independently it's too hard to keep up as I do other things. Just search for occurrences of '<X11/..> to see what I mean.

I'm using tinyX as the only X on my own system, with the headers installed; while

Code: Select all

sed -e 's|<X11/\(.*\.h\)>|"\1"|g'

will make the change you refer to, the headers will not work when installed.
My guess is that specifying -Ipath/to/tinyxlib/include/ first thing is the only way to avoid the issue...
Oh, that's right, it might work to use symlinks:

Code: Select all

find * -name '*.c' -o -name '*.h' |xargs sed -e 's|<\(X11/.*\.h\)>|<tiny\1>|g' -i
cd include
mv X11 tinyX11
ln -s tinyX11 X11

I applaud all your efforts -my original work of creating a working build of tinyX has really paid off for you fellows.

Thanks!

[Iguleder]

Merged the fixes

EDIT: got ROX-Filer and gdk-pixbuf to build statically!

[linuxcbon]

Do you have a version with a windows manager which can use the mouse and the keyboard ?

[Iguleder]

Yes, with Ratpoison. I'm currently working on a new image, with a JWM/ROX-Filer desktop.

[technosaurus]

Can I urge you all again to make these sources completely independent. All through the sources there are references to installed header files which break the build when doing it on a modern system. I started once to do this, but with several of you working independently it's too hard to keep up as I do other things. Just search for occurrences of '<X11/..> to see what I mean.

chroot
(I use aboriginal as my rootfs)

[Iguleder]

Got ROX-Filer to work, but the pinboard is horrible - you cannot drag files to create icons.

[Ibidem]

Do you have a version with a windows manager which can use the mouse and the keyboard ?

Do you mean "a window manager which takes advantage of the mouse as well as the keyboard" (ie, "not ratpoison")?

I'm using mwm from Motif, which definitely qualifies.
I don't have any window managers integrated into the build.

...
For now, I should push my xutils tree somewhere. It's got a few of the more useful standard X programs: xcalc, xmessage, xfontsel, xlsfonts, xkill, xprop, xwininfo, and fontutils (bdftopcf, bdftruncate, and ucs2any + the map files). I want to add xclock or oclock, and perhaps xmag and xclipbard. (I'm thinking of using oclock because it's the smaller clock, plus I like the transparency.)

[Ibidem]

A couple things that came to mind due to looking over tinyxserver and tinyxlib:
-The reason makefiles use "rm -f" for clean is that it does not fail when the file to be removed does not exist. As a result, you can use rm -f on targets that frequently won't be built (such as Xvesa).

-git can work with multiple servers and branches. If I were merging the CVE fixes that I mentioned into "master" from a branch that had changes I wasn't sure about, I would have done it like so:

Code: Select all

git checkout master
git checkout -b cve-merge
#pull repo branch
git pull git://github.com/idunham/tinyxlib blob
#Now review changes
git log
#See what files have changed
git diff master cve-merge |grep -e '^---' -e '^+++'
#Review the diff; to view the diffs for a directory, do:
#git diff master cve-merge libXfont/
git diff master cve-merge
#Since it matches your tree for the most part, you can either adopt it in full:
#git checkout master; git merge cve-merge
#or cherry-pick the commits.
#I prefer to avoid experiments in master, and cherry-picking sometimes calls for caution.
#So I cherry-pick like this:
git checkout master
git checkout -b cvefix
#Now, record the commit numbers of the commits of interest.
git log cve-merge -- libXfont/
#review them:
git show 453d28
git show c20a19
#and cherry-pick them:
git cherry-pick 453d28
git cherry-pick c20a19
#In this case, there aren't any conflicts. So we can continue by testing that it builds.
#If there were conflicts, git should let you know about it very loudly.
#You would check what conflicts (usually "both modified"):
#git status
#then edit each file, searching for '<<<<<<'
#which marks the HEAD side of an unmergeable area; from ====== to >>>>>> is the remote branch side.
#Once you figure out what changes to make, be sure to delete the markers and the unmerged code!
#After editing each file, do
#git add file
#At this point you can continue.
make clean; make
#Now merge it into master:
git checkout master
git merge cvefix
#and that's it.

But that's the long way. My comment that it was ready for you to merge, with your buildsystem, was saying that you could do it the short way:

Code: Select all

git checkout master; git checkout -b cve-merge
git pull git://github.com/idunham/tinyxlib blob
make clean; make
make clean
git checkout master; git merge cve-merge

[linuxcbon]

I'm using mwm from Motif,

It's too big , mwm sources are 9Mb, in comparison to jwm 0.3Mb.

[Iguleder]

Just wrote a dead-simple union file system using FUSE.

I want to use it for package mangement - it doesn't support COW, so it can only be used to add files to the OS (i.e install new packages). I think this makes the whole thing more secure keeps the distro robust.

Now, I'm going to write some super-fast init script which finds the "home partition" and mounts a Squashfs image placed inside it.

[Ibidem]

I'm using mwm from Motif,

It's too big , mwm sources are 9Mb, in comparison to jwm 0.3Mb.

I use a few pieces of Motif software, like xpdf, xmmix, Ted, nebula, xephem, xplore, and several others.

Anyhow...my main reason for not using JWM is the config file. I agree with Linus on XML (http://mail.bitmover.com/pipermail/lmbe ... 00076.html), and much prefer a plain-text config file...

[technosaurus]

Anyhow...my main reason for not using JWM is the config file. I agree with Linus on XML (http://mail.bitmover.com/pipermail/lmbe ... 00076.html), and much prefer a plain-text config file...

Normally I would agree; however, jwm's xml is not just a config file, but also a layout description (for menus, toolbars, etc...). Any meaningful layout language is going to resemble XML or JSON to some extent and jwm's XML engine is pretty light (no expat/libxml dependency)

NOTE: Hazewm does layout menus via flat files, is pretty close to jwm's style and has a permissive license. Currently it only does XPM images, but I'd like to see if stb_image could be used to add gif, png, jpeg and others.

Edit: found a light getty/login/xinit implementation here:
https://github.com/msharov/loginx

[Ibidem]

Anyhow...my main reason for not using JWM is the config file. I agree with Linus on XML (http://mail.bitmover.com/pipermail/lmbe ... 00076.html), and much prefer a plain-text config file...

Normally I would agree; however, jwm's xml is not just a config file, but also a layout description (for menus, toolbars, etc...). Any meaningful layout language is going to resemble XML or JSON to some extent and jwm's XML engine is pretty light (no expat/libxml dependency)

NOTE: Hazewm does layout menus via flat files, is pretty close to jwm's style and has a permissive license. Currently it only does XPM images, but I'd like to see if stb_image could be used to add gif, png, jpeg and others.

Edit: found a light getty/login/xinit implementation here:
https://github.com/msharov/loginx

Thanks for mentioning that. (I stumbled over mazewm in the proces, which is more interesting because it appears to have some awareness of colors.)
My own favorites are IceWM and Dtwm, the CDE window manager.
But CDE takes Motif, RPC, and a few other things besides. mwm is a bit plainer, but pleasant...
And IceWM is very nice, but it's LGPL, C++, and needs imlib/gdk-pixpuf. Not a major isue, but I do like plain MIT C/X11/Xpm.
BTW, those two have my preferred config file format.

[Iguleder]

I just downloaded Slacko and replaced its applications (mtPaint, ROX-Filer, etc') with the static versions built against tinyxlib, GTK1 and musl - they work extremely well!

ROX-Filer 1.2.2 lacks the backdrop feature, so I set the desktop background using JWM. Besides this, everything seems fine - even custom icons and the pinboard (!).

Also, I got GTK See to work - I had to patch it to support libpng 1.5 and above. Now, I have a big collection of applications that is comprehensive enough for an ultra-lightweight GTK1 Puppy remix