Posted: Wed 01 Jan 2014, 16:53
Cool thanksIguleder wrote:nooby - UEFI is supported.
READ-ONLY Archive
https://oldforum.puppylinux.com/
Cool thanksIguleder wrote:nooby - UEFI is supported.
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.Iguleder wrote:Yep, saw these awful CVEs, I'll do this when I find a free moment.
I'm using tinyX as the only X on my own system, with the headers installed; whileamigo wrote: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.
Code: Select all
sed -e 's|<X11/\(.*\.h\)>|"\1"|g'
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
Thanks!I applaud all your efforts -my original work of creating a working build of tinyX has really paid off for you fellows.
chrootamigo wrote: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.
Do you mean "a window manager which takes advantage of the mouse as well as the keyboard" (ie, "not ratpoison")?linuxcbon wrote:Do you have a version with a windows manager which can use the mouse and the keyboard ?
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.
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
It's too big , mwm sources are 9Mb, in comparison to jwm 0.3Mb.Ibidem wrote:I'm using mwm from Motif,
I use a few pieces of Motif software, like xpdf, xmmix, Ted, nebula, xephem, xplore, and several others.linuxcbon wrote:It's too big , mwm sources are 9Mb, in comparison to jwm 0.3Mb.Ibidem wrote:I'm using mwm from Motif,
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)Ibidem wrote: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...
Thanks for mentioning that. (I stumbled over mazewm in the proces, which is more interesting because it appears to have some awareness of colors.)technosaurus wrote: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)Ibidem wrote: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...
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