I'm not sure why, but there is some binary bloat simply by rebuilding the packages in the Diablo SDK
Update: after a lot of experimentation with various more exotic flags (that was a waste of a perfectly good Sunday afternoon!) it seems the only difference in the case of busybox is -mthumb. I'll treat this as a packaging bug in and set it explicitly in this case.
However it's becoming apparent that the Nokia build machine applies different compiler flags on different packages (outside of what is defined in the packages themselves).
For example, xorg-server needs DEB_BUILD_OPTIONS=vfp to even compile, and an SDK osso-pdf-viewer build of the original unmodified package (without -mthumb) produces a binary that is significantly smaller than the Nokia package: 938972 vs 1162620 bytes. I suspect this case may be some vfp optimisation, but really don't feel like spending any more time tracking down this sort of thing - these discrepancies have come to light after touching just 8 source packages, and there's a lot more to go. Also, size differences in executables are relatively harmless, but there may be more tricky issues with libraries and such.
Stskeeps: any chance you can "liberate" the internal per-package build flags so we can apply them properly to the packaging metadata?
Hey Lma, I figure the problems I've been having are my own since noone else is reporting desktop reseting to defaults. So I am considering doing a reinstall on my external. If I re-add the community SSU repository after the reinstall will I be able to get caught up again?
Sorry I haven't sent any reports yet, everytime I try I just keep running into problems, or having to do something else with my time. But I am ready for a fresh install anyway.
Not without breaking dependencies and missing the other busybox fixes :-(
I just pushed an updated version that makes the df fix conditional on having filesystem arguments on the command line (eg "df /"). This should make it bug-compatible with the official version in the general case, but let me know if it's still causing problems.
This fixed things for me. Thanks. Still plugging away.
Do you have everything you need for the DSP underclock patch? It doesn't appear to be in the current version. I understand you may just need time but if there's anything that you need help with, please let me know and I'll try.
No objections to making it tunable, as long as it defaults to the previous behaviour (ie, no surprises to users who don't know/care about it). Anyone feel like isolating that specific patch?
