(old)Puppy Linux Discussion Forum

I agree with Keef
" incorporating iguleder's excellent experiments"
and suggest
DSDLS
DesertDogLives

DieSeL is a great name, but it's a well-known brand. I want something unique. DSDLS isn't catchy enough, because it has multiple Ds.

So far, I like RDSL the best. It's short and I'm not aware of any product or company called "RDSL".

LSD

DSLR it is. I put it in GitHub, in its current, alpha quality form.

It builds perfectly on Ubuntu 14.04 x86_64, within 1.5-2 hours on my chromebook. I'll upload a testing image soon - at the moment it's 101 MB, without any kind of trimming (i.e with tons of documentation, static libraries, headers, etc').

Any luck building seamonkey 1.1.19-gtk1-static (see lamarelle. org for .config)
It had issues building with glibc, so would be a good test for musl-libc and uclibc++ or ustl.

DSLR has another meaning which might obscure your project when searching for it: Digital Single Lens Reflex (camera).

I was very close to getting Seamonkey to build, but it forces some shared libraries, like libmozjs. I want a single binary without these. Any workaround for this?

Iguleder wrote:I was very close to getting Seamonkey to build, but it forces some shared libraries, like libmozjs. I want a single binary without these. Any workaround for this?

I think you can use a --with-system-* flag for it ... just build it as a static lib on the system
I use this one, as it is the last C-only version:
http://ftp.mozilla.org/pub/mozilla.org/ ... rc1.tar.gz

Could you provide your building instructions? As far as I can see, both Firefox 1.5.x and Seamonkey 1.1.19 don't have the option to build against a system libjs.

EDIT: I just set up a website for DSLR. At the moment, there's no ready image - you'll have to build it (automatically, of course).

I'm experimenting with cross-compiling a 32-bit variant from the same build environment - I think it would be nice to have a "hybrid" flavor with a 64-bit kernel and 32-bit user mode.

umm, yeah forgot about that...
https://bugzilla.mozilla.org/show_bug.cgi?id=331776

iirc I did get it to build once with some sed trickery on every single makefile ... it was easier than trying to navigate the 2nd most poorly organized source ever.

"2nd most poorly organized source" -I can hardly wait to hear who holds the first place...

amigo wrote:"2nd most poorly organized source" -I can hardly wait to hear who holds the first place...

me ... with open/libre-office coming in 3rd (though it seems the libre folks may have done some house cleaning) but chrome gives them a run for their money ... followed by any company.java.project.multiplatform.large (I just don't like languages that _requires_ a full IDE to be somewhat productive)

Speaking of IDEs, I tried out the geany plugins that Puppy always leaves out and I must say its nice ... It makes updating projects to github much easier, especially if geany is built with the builtin vte terminal

Good news! At last, all applications in DSLR launch without crashing. I fixed gtkdiskfree and gcalendar.

Now it's time to add SANE, xsane and CUPS

I found the source for nanogtk @ microwindows it is based on 1.2.7 but we could diff it vs 1.2.7 and apply it to our patched version. Another thing I am interested in doing is building our static builds with ffunction-sections fdata-sections and linking with gc-sections print-gc-sections to a log. That will help figure out what garbage we can remove from our shared libs (just put the actual functions in the header files for the least common ones like gtk's rulers etc...) @iguleder, do you think you can add those cflags/ldflags to your build scripts and keep a log on your next full build (specifically the output from linking with gc-sections, print-gc-sections)

That's the plan, once I finish a short round of cleanup.

I tried this once and some packages failed to build.

Added these flags and built some of DSLR's packages - with GCC 4.2.1, the difference is extremely small - 200-300K binaries are smaller by ~10K now.

That sounds about right. The useful part is the output. You can run the list of garbage collected functions through sort with the count flag set (or is it uniq) to find least used function list ... if there are 99 links and a function occurs in over 90 then it can likely be moved to the header and out of the shared library... or removed altogether if it is unused in all 99.

uniq -c is what you're after; ISTR that uniq wants the output of sort...

Among the Fedora patches is one related to theme reloading; it will add bloat and break xdialog.

In one of the screenshots, I saw "wifi manager" or some such name...
Does anyone have a wireless manager that
(a) uses a single instance of wpa_supplicant running as a daemon to handle connecting;
(b) uses the wpa_cli -a /path/to/script trick rather than "sleep N; dhcp $IFACE" ;
(c) uses a daemon/service that can be started via init, without X; AND
(d) has a separate configuration interface based on gtk+-1.2?
(I'm aware of xdialog and gtkdialog1 being options for this.)

wicd broke (a); it starts up a separate instance per network, with its own config file.
I've seen several networking setups get (b) wrong.
A number of the puppy scripts get (c) wrong.
And I've not found reference to a gtkdialog1 network wizard yet.

If someone's working on one, I'll mention that forgetting to add -D... to the wpa_supplicant options can keep wireless from working at all.

And I see a patch in DSLR to excise freetype from mkfontscale...yum yum.

Upgrading the kernel from the 3.10 to 3.12 at the moment, since this is the most recent LTS.

I rebuilt the entire DSLR with -Os -fomit-frame-pointer -ffunction-sections -fdata-sections and -Wl,-gc-sections. It seems all packages were built just fine - there's a reduction of ~100K in the bigger packages (1-2 MB).

Once the kernel is ready as well, I'll upload everything to my repository.

EDIT: --gc-sections breaks iw. The Android build rule removes this flag, so I did the same. Besides this, everything looks sane so far, even the kernel.

Iguleder wrote:Upgrading the kernel from the 3.10 to 3.12 at the moment, since this is the most recent LTS.

I rebuilt the entire DSLR with -Os -fomit-frame-pointer -ffunction-sections -fqdata-sections and -Wl,-gc-sections. It seems all packages were built just fine - there's a reduction of ~100K in the bigger packages (1-2 MB).

Once the kernel is ready as well, I'll upload everything to my repository.

EDIT: --gc-sections breaks iw. The Android build rule removes this flag, so I did the same. Besides this, everything looks sane so far, even the kernel.

-Wl,-gc-sections,-print-gc-sections tells us what gets removed. Packages that use dlopen/dlsym _will_ break with -gc-sections, but dlopen with musl is pointless because musl doesn't bother to actually unload libs, so it may as well be modified to either be ifdef'd as a dependency or omitted (similar to gdk-pixbuf when doing static builds in gtk2 IIRC) ... btw the dlclose behavior of musl is my only real gripe about it ... It looks like a hacky way to fix musl to unload libs would be to use musl's threads to dlopen and use the thread's mechanisms to garbage collect, but I'm not sure