Saluki, Puppy Remastered

[8-bit]

I see a lot of applications being tested, but I still do not know if a base for Saluki has been selected and the progress on an initial test version.
Has a base been selected and applications considered for inclusion?

[Iguleder]

Good to have you back, jemimah

I think we should open some file in a collaborative writing service and write a list of proposed features and ideas. I mean, jemimah can add "jemimah: netbook support" and I can add "iguleder: better power management" and so on, till we have a good list of proposed features and concepts.

Once we have that, each developer can pick areas to focus on and make some mockups or prototypes. Jemimah could edit the wiki page to list all developers and their contributions, to make it more organized.

Also, we could do it like major distros - have teams for everything. A "kernel team", a "desktop team", a "package management team", a big team of packagers, an "installer team" and so on. This method works well - each team has a leader and all teams are under the strict control of the dictator jemimah

2c

[Lobster]

I think we should open some file in a collaborative writing service

Any ideas?
Jemimah did mention about setting up a forum/wiki/blog etc

We have gobby in Lucid 5.2 ppm (puppy package manager)
We have used chatzy in the past
http://www.chatzy.com/
and developers can send an email to
post@puppysaluki.posterous.com
to appear on the Saluki blog
http://puppysaluki.posterous.com/

[Aitch]

Can I ask Techno.... is all the work done on 4.4 stalled, or will it be incorporated, where suitable, into Saluki, or picked up again, at some point?

I think it was March that it last got any attention?

It seemed to get off to such a good start....has an explanation been given, that I missed?

all/ an idea mooted by a noobie

.....it would be useful to have a package-converter or generator for at least one COMMON distribution format (e.g .deb packages), preferably integrated with Puppy Package Manager, so updates are easier.

Sounds good to me, but I haven't got past 4.31 so it may already be in

Do we have an ideas list, with agreed inclusion or not, with reasons?

Anyone good with tables?

Also someone asked about scan frontend? Peasyscan.pet/rcrsn51

http://www.murga-linux.com/puppy/viewtopic.php?t=61046

This network/file/print shares pet of his is worthy of consideration, too, IMHO

There are two programs: samba-login and samba-shares. In either case, you can login to a known network share without doing a search. Samba-shares lets you build a database of shares. For Windows shares, you can usually leave the username and password fields blank. Just enter the share name and server (the PC computer name).

http://www.murga-linux.com/puppy/viewtopic.php?t=60204

Aitch

[technosaurus]

With all of the other dev's working on pet (no pun intended) projects it stopped being a community project and turned into a puplet. (albeit an almost completely rebuilt puplet) There were 4 outstanding release critical issues: libxml2 broke after upgrading libz (solved), seamonkey2 broke too many things (could use 1.1.19+patches), gtk caused a different problem in every version (2.16.6 had the least), Out of the box experience was and is lacking (kb,lang,mouse,video - currently being worked by shinobar) Then there were another 50+ non-critical / feature request bugs. I still have most of the work, but I did finally wipe my ntfs partition to ext4 (mainly because it F'd up a bunch of file properties that were hard to track down - btw do NOT do dev work on an NTFS partition even if you are out of space elsewhere - just use it for storing tarballs or iso and sfs files) ... anyhow if I get a patch(es) to use shinobar's first run wizard I would feel comfortable releasing it (with gtk-2.16.6, seamonkey-1.1.19, fixed xml2 and upgrades to the P*.pets like DuDe, Pmusic, Pprocess...)

My attempt to fix the archaic dialog based first run implementation was a major reason I started working on bashbox... everything was scattered about, difficult to find and not well documented which caused a lot of code duplication and even old-school Pup's had no idea where a lot of things were. Shinobar's coding style is very clean (and bashbox compatible), so please support his work - I think it will be a great improvement to the user experience for all future versions of Puppy. http://www.murga-linux.com/puppy/viewtopic.php?t=60712

[jemimah]

I see a lot of applications being tested, but I still do not know if a base for Saluki has been selected and the progress on an initial test version.
Has a base been selected and applications considered for inclusion?

Personally I think Technosaurus' "mostly static" idea is the only one that is innovative enough to attract the majority of Puppy's devs and create enough momentum for something the community will be interested in supporting long term.

I'm not sure when Technosaurus will be ready to post it, or if he's hit a roadblock, but I prefer it to be done right rather than done quickly.

One we have a base, I'd like to take a look a big_bass' slackbuild ideas to see if we can build something easier for the community to support than woof is.

Updates, Technosaurus?

(my new job was cut short, so I have time again now - I'm working on Puppeee/Fluppy until Saluki gets interesting).

[Lobster]

Updates, Technosaurus?

?
Talk to us.

Do we have alternative strategies?
For example using:
'Linux from Scratch'
The t2 build system
Reverse engineering (starting with a working Puppy and continually moving backwards as we await those moving forward from the beginning and then meeting in the middle . . .

[technosaurus]

I got a working build system this weeking using a snapshot of the 4.5 branch and the latest snapshot of binutils - it seems to be working great so far in i486 mode (you can always specify -march=XXXXX in CFLAGS to override higher or lower architectures) ... the dev tools are actually compiled with -march=i586 for compile speed but set up to build for 486 by default

I also used libelf with gcc to enable the new link time optimizations support that is supposed to reduce size by 30% on average (similar to using -f{function,data}-sections and --gc-sections), but with (hopefully) more predictable outcomes (like losing plugin support)

compared to the 4.2 series (as in puppy 4.x) the tools are quite a bit larger due to adding mpc, gmp, mpfr and libelf library dependencies (I also built them in statically so they won't add extra dependencies to userland apps, but the size difference compared to using shared libraries wasn't really that noticable)

I got gnulibc-2.12-1 down to ~1Mb by patching (stat.h) to enable compiling with -Os (and enabling some new optimizations that make it smaller and/or faster without increasing size) It works fine and speedy with Wary-094.

I did not build gcc with cloog-ppl for a couple of reasons:
It failed 20 different ways trying to do an in tree (LFS-style) build.

I am writing a small compile wrapper (similar to Pcompile, but simpler syntax) that will make it easier for new developers to build various types of programs with the best safe optimization levels.

before I move on to desktop libraries...
Has anyone noticed ANY real improvement by using xcb? and Can gtk2 be built with only xcb (no xlib)?

png-1.4.X (latest) or 1.2.X (more stable)? -both with apng patch

expat or xml2 for gtk's xml support? (I can get xml2 down to about the same size and many things -rox included - require xml2 explicitly anyways, but not vice versa for expat AFAIK - except maybe gtkdialog? - need to check it specifically )

Would someone be able to patch Pango-1.24.5? - It is the last version that works without adding libstdc++ dependency and most of the commits since then seem to be related to fixing that merge, but if someone is good at these things it would be extremely helpful.

Does Seamonkey 2.0.10+ still crash on insert if gtk is compiled without debugging? If so I think can disable the gtk cast checks in the seamonkey with a CFLAG that wjaguar pointed out - maybe even have it as a default CFLAG. If not I may be able to just compile the affected gtk code with debugging. (Debugging adds several 100kb to the size)

Any thoughts on compressed binaries with upx and compressed libraries with zlibc?

a small version of tcl? http://jim.berlios.de/

[Iguleder]

Got Calf Linux smaller and better. The initramfs now has just Busybox and the file system hierarchy. The init scripts run the wonderful "mdev -s" to create device nodes, then goes the code that searches for the main SFS. The SFS contains udev and the kernel modules, so after the SFS loading the init script calls udev

This also allows it to boot in "mini-mode", without the main SFS. Just imagine, a basic environment without any networking support in 2-5 MB, ideal for editing corrupt /etc stuff.

I also added a boot code named "live", which prevents Calf Linux from loading any extensions or save files. It boots within 2-3 seconds on my modest netbook, totally insane

Now I think I can compile Busybox statically to save some initramfs size, since it contains the glibc dependencies of Busybox and they're quite big. The next stage is adding things like hal and dbus, one-by-one ... X will follow

I also started working on a tool similar to Woof. I want to integrate my skeleton as as something similar to "rootfs-skeleton". The text processing parts are written in Perl and it works fine, dependency resolution is 100% percise but slower than the former Bash code, because it's recursive - Perl runs Perl which runs another Perl ... it's heavier than the Busybox ash. I still need to figure out how to get X to run - I tried this code with the "xorg" package from Debian Squeeze and stuffed all packages in the main SFS - x didn't start and complained about something missing in /etc. I'll try this again with packages from Debian sid, maybe it's because of the missing automatic detection and cool stuff present in later X versions, after all it's xorg-server 1.7.7.

This thing definitely has lots of potential

[technosaurus]

I have a static uclibc Xvesa and jwm if you want to have some fun with them (I got them to start up with a oneliner but rxvt seemed to need some more environment parameters... or maybe getty running?) - see the pupngo thread for the one-liner I used to start X+jwm - I can post the 2 binaries later if you are interested.

[Iguleder]

Of course I am

Just compiled 2.6.36 and it has the same issue I had with previous kernels, blank screen with KMS ... gotta compile DRI into the kernel for some reason. Then I'll probably continue with the X experiment.

EDIT: I think I'll try to mess with Buildroot, maybe I can build a uClibc toolchain with it and use it for static compilation work. I want Busybox and maybe some tiny X server but not a xfree86 one ... maybe xorg with vesa with all drivers available as a sfs.

EDIT 2: your xvesa doesn't work, it needs fonts and stuff ... dang. Tried the Tiny Core xvesa and it just outputs some error in hexa-english

[technosaurus]

I didn't get a recent xvesa to compile all the way but goingnuts found a static version that I used (did have a couple fonts but I think they can be built in and then upx'd) ... the last version I was able to build with patches for dietlibc was xfree86-4.2.0 ... I have forgotten the nuance of building it properly (all the various config files) or I would have finished building the static uclibc version - I always seem to be able to clear like 20 build errors in 5 minutes and get stuck on one or two little things. (btw to build jwm statically against Rob's toolchain only took an hour or two including X11,au,dmcp all the protos jpeg and png - its not in buildroot though)

[Iguleder]

Trying to re-learn how to use Buildroot, I want to build a toolchain with it - versions don't matter, I just want to produce the smallest static Busybox possible. No locales and stuff, 100% functionality.

Anyway, now I have to face another design decision - if the initramfs has just a static Busybox, it means the main SFS must contain glibc ...

[jemimah]

I didn't have much luck building a recent Xvesa either. Usually the mouse and keyboard don't work when I try to build it.

I did experiment with Xfbdev, but had similar mouse/keyboard issues.

I have been playing around with the xorg fbdev combined with uvesafb and getting good results with my gma500 netbook, which has major performance problems with both the vesa driver and Xvesa. I'll be dumping Xvesa from Puppeee, and maybe Fluppy if I get good results on a wider array of hardware.

[scsijon]

http://dev.gentoo.org/~spock/projects/uvesafb/

may be what you guys want, sent to barry some time ago though and may be out of date.

regards
scsijon

[big_bass]

I havent changed my opinions about having something rebuildable
following some established linux standards
I am not focused on some micro embedded system
although keeping things modular one could build small or large
for various computers as I stated earlier source is packages in the raw

build the packages and you build the system
you maintain the system by having build scripts
this is the developer side that the basic end user doesnt have to worry about but sharing work with different kernels and configurable packages is a must for any support or you have to start over from scratch every time you want to update

anyway I havent posted here for awhile the main focus is sharing work or I feel it should be across the linux world not a one man /woman show
trying to fix the world thats an un real expectation for anyone

so if you would like to help out and test a program I wrote
to automount drives it should work for any "puppy version"
I will write another for a non puppy build not using a puppypin
http://www.murga-linux.com/puppy/viewtopic.php?t=61262

thanks feedback welcome and needed
Joe

[Iguleder]

I agree with you, big_bass (for the first time ), we need something rebuildable. A build system that allows us to take a bunch of source packages, press enter and it's show time. A tool that allows us to build Puppy for any architecture with any package selection.

Of course, nothing is perfect and the human factor exists, some patching and problem tracing will still be needed, but you get my point

I'm focusing on low-level stuff at the moment, I find it fun and interesting. So far it's 100% architecture independent, the two things my work depends on are Busybox (static, dynamic, doesn't matter as long as it works) and a kernel (and now it also doesn't need Aufs, the only requirements are SCSI, USB and Squashfs compiled into the kernel).

Now I need some source for ready packages that I can use to build the distro. The kernel and Busybox are independent with the new design, all packages go to the main SFS.

The question is, what base to use? Slackware seems the best choice but it has no dependencies in its repo and if I use the Salix repo X won't start. Of course, I tried this just once and with my old Pdebthing, not with my new Woof-like thing which has perfect dependency resolution at the cost of performance.

I could use T2, but ... it's not ideal for Puppy and it takes a day. I think we should start writing some sort of build system, something simple without any silly tricks and unneeded stuff like cmake. Maybe a Bash script for each package with exit codes and a main script that calls all build scripts and stops if finds any error. I remember I did some experiment once, I took all commands from LFS and put them in scripts and made one script that executes them one-by-one and automated nearly half of the process successfully.

[Iguleder]

I just built an i486-unknown-linux-uclibc cross-toolchain with crosstool-ng and used it to compile Busybox statically - the result is a ~600 KB Busybox with everything from coreutils/util-linux-ng/module-init-tools/etc and even more. The initramfs is 608 KB ( ) and this thing boots even faster. Cool stuff!

Now I have a plan to write my own tool for the construction of uClibc cross-toolchains ... and I still need to learn how to compile statically so I can do the same with udev. I also want to try the trick technosaurus did, all Busybox daemons in one binary.

[jemimah]

The linker will compile statically automatically if you build only the static libraries.

So you just compile the dependencies with "--enable-static --disabled-shared" then build, you'll get a static binary.

It seems a lot of developers never test this though, so sometimes you need to modify the makefile or pkgconfig file to get it to link.

[technosaurus]

The linker will compile statically automatically if you build only the static libraries.

So you just compile the dependencies with "--enable-static --disabled-shared" then build, you'll get a static binary.

It seems a lot of developers never test this though, so sometimes you need to modify the makefile or pkgconfig file to get it to link.

... I test it all the time and I highly recommend this for most apps. Really, will you ever need libbobsfungame.so for other programs? not likely. To force the linker to use the static version of an already installed system library, you only need to remove the symlink that ends in .so (provided you have the archive of the object files lib*.a - sometimes know as static "libraries")

That reminded me of an experiment that I did for gtk2... to combine all of the gtk2 dependencies into a single shared libgtk-x11-2.0 library that provided the rest of its dependencies using symlinks. I did this by dumping each library's object files into corresponding folders and using those to build a single shared library. (It only worked if I enabled -z muldefs for the final link - thereby eliminating one of the main sources of optimization) It would have worked fine if developers talked to each other and submit/accepted patches so that they could properly use the upstream functions - or at least renamed theirs. (good google SoC project maybe)

I was finally able to get a good build by eleminating entire objects, but this would sometimes eliminate other necessary functions from the same object (unlike dietlibc, most devs use multiple functions in each c file/object - which is why the -ffunction-sections and --gc-sections optimizations now exist - they help eliminate these unused functions where only one or two functions in an object file are used)

@Iguleder - sorry, I crashed as soon as I got home last night and had to be at work early today -I will post the Xvesa and static uclibc, upx'd jwm (only png and jpeg support) and the init script variants here but PM me with an email address & I'll email some of the variants (my <2mb initrd.lzma may not work on other systems because I used the zdrv cutter to eliminate all extra modules and deleted a couple others that I didn't want .... anyway you may have better luck with the earlier implementations unless we just happen to have the exact same hardware)

Code: Select all

#!/bin/ash
export PATH="/bin" HOME="/root" TERM="xterm /bin/ash"
other_stuff(){
	mount proc /proc -t proc
	mount sysfs /sys -t sysfs
	ln -sf /proc/mounts /etc/mtab
	mount devpts /dev/pts -t devpts
	mount -t tmpfs -o size=1024k shmfs /dev/shm
	mdev -s
	echo /sbin/mdev > /proc/sys/kernel/hotplug
	mount -a
}
	

autologinroot
other_stuff &
loadkmap < /usr/share/kmap/us.kmap
Xvesa -screen `Xvesa -listmodes 2>&1 |grep 0x[123][246] |sort -r |tr "\n" " "|cut -d " " -f 2` -mouse /dev/mouse -nolisten tcp -tst -I & jwm -display :0 && killall Xvesa