wt., 25 cze 2019 o 17:21 Bernhard Rosenkraenzer <b...@lindev.ch> napisał(a):
> > > 2. Disable debuginfo generation > > While I agree that debuginfo packages aren't as useful as they could be > (would be nice if the kde crash dialog could automatically download them > and generate a more useful backtrace, for example), I don't think they're > entirely useless, and outside of build time generating them doesn't have > any drawbacks. While our infrastructure can deal with it, I don't see much > of a reason to disable it. > > Are we sure that rpms are _REALLY_ stripped of debug information ? > 3. Use BFD > > 4. Use LD.lld > > Agreed about both of those -- gold was a nice try (and bfd still hasn't > caught up with some things like ICF), but lately it hasn't been maintained > and is more trouble than it's worth. > I'm leaning towards trying to use lld for everything (faster and can keep > ICF) with exceptions for where it breaks, but haven't gotten around to > checking how well lld works these days. I'll definitely run some checks > when 9.0 is in the tree (lld is making progress fast). > +1 > > 5. Toybox > > Toybox works really well and would certainly be a good replacement inside > initramfs at least -- not sure if we want to do it in the whole system > though (keep in mind that people [and Makefiles] will run scripts written > on other distributions, and that hardcode flags to coreutils tools). Even > switching to libarchive tar wasn't as 100% painless as it ought to be. > Also, toybox can replace more than just coreutils - awk, grep, sed, find, > kmod, procps, psmisc, which, util-linux and a few more are all in there. > I'm not sure how complete those tools are and whether or not we could end > up replacing some of those as well. The fewer tools are replaced, the less > likely it is to have any benefit... > > If we never give it a research and try then we will never know how complete these tools are. IIRC android uses toybox, right? > > 7. Get rid of GCC > > Try to start a reserch how GCC can be stripped out of builds with > > LLVM/clang > > One big issue there is libstdc++ -- while clang has libc++ (which is > actually better in many ways), if we care about binary compatibility with > other distributions, we can't use it because otherwise we'd run into > situations where e.g. a binary-only game built on some other distro links > to Qt and libstdc++ (that would crash instantly on trying to runtime link > to Qt built with libc++). > clang also uses the gcc command line tool to locate headers for intrinsics > (/usr/lib64/gcc/x86_64-openmandriva-linux-gnu/9.1.0/include etc.) - that > could probably be changed. > > What distribution may benefit from chaning to libstdc++ ? Well i guess that stuff that rely on glibc and gcc may fail, like proprietary software - steam, nvidia blob drivers etc, right ? > > and use compiler-rt by default > > We tried that before -- while it worked great for most stuff, we ran into > binary compatibility problems in some weird situations (e.g. firefox built > with compiler-rt crashing when loading the Flash plugin because of clashes > with statically linked libgcc bits in there). > Fortunately almost nothing cares about Flash anymore, but that sort of BS > is something we still need to look out for. > Probably it's safe to build most applications with compiler-rt -- but > there's some potential for it getting messy as soon as something starts > dlopening stuff built with something else. For normal libraries, > fortunately it's easy to test (e.g. see if a Qt application built with > libgcc will keep running if Qt is linked with compiler-rt). > Just swapping out Qt should give us a good impression, given that will > also show us if plasma can still load plugins built with libgcc. > > +1 > 8. PGO > > Type a list of packages that may benefit form PGO (i.e firefox, webkit, > > kernel http://coolypf.com/kpgo.htm) > > Well llvm/clang can be build with PGO. > > > > 10. AutoFDO/BOLT > > Try to start research on post-link optimizations > > http://perl11.org/blog/bolt.html > > Good idea. > > If i understand right, we need to run distro on real hardware for example x86_64, gather run various scripts that will bench python, libc whatever, gather bolt data and then use bolt.fdata to compile stuff on ABF ? > > *Other*: > > > > 1. Use github issues as bug tracker > > AFAIK QA people prefer bugzilla (and there's the issue of github being > owned by M$ -- so far they've done well, but can we trust them forever?) - > but now is the right time to look at possible options again... > > > 2. Enforce control for PR to other branches > > Integrate "travis-like" tool into our github repo to allow merging > changes > > between branches. > > Enforce PR approval process - i.e. Release Manager or QA accepts PR for > > other branches. > > +1, I wonder if we can somehow merge this into the QA tool... > PR (or something like it) to non-cooker branch --> triggers build to see > if it compiles, notifies QA and RM, starts voting process > > Yes something like that. > Here's a few more things I've been thinking of -- not necessarily for 4.1: > > Cooker: > - Early move to LLVM/Clang 9 -- there's finally patches adding RISC-V > hardfloat support, and LLD has made a lot of progress > +1 - Reduce the duplication of binutils tools (binutils, elfutils, llvm). > Chances are the LLVM tools are good enough to handle debuginfo generation > these days (main reason for elfutils to be in the default build environment > right now) > +1 - Check if using Polly can speed up some libraries -- it should be possible > to at least somewhat parallelize libjpeg and friends (but the tools for > doing that automatically may not be up to the task yet) > Speaking of llvm-polly i did some tests and compared results of -O3 build against polly build https://github.com/OpenMandrivaAssociation/openssl/commit/b77dbe18c6d6602c3d496118128dc4e41e417049 polly build was slightly faster than O3. If i understand right polly is good for optimizations where polyhedrons are used. This means llvm-polly should be used on all 2D/3D graphics tools like krita, gimp, blender... maybe mesa ? Doubt it has any positive impact on polynomials. - Plasma customization tool in OM Welcome that allows people to quickly get > to something they feel at home in, e.g. "Act like [*] OpenMandriva [ ] > Windows [ ] MacOS" (where OpenMandriva is what we think is best, Windows > does things like double-clicks, MacOS does stuff like global menu bar on > top of screen) > +1 Maybe as a calamares module ? - Allow running Android apps (I have Anbox sort of working, but we can do > better than the Brokenbuntu crowd...) > +1 That would be a really nice feature - Add OnlyOffice as an alternative to LO (this is a bit painful because > they use a load of nonstandard tools, including some prehistoric stuff) > - Text mode/server installer > > - An experimental build that does what could be done if we didn't care > about binary compatibility (glibc -> musl, libstdc++ -> libc++, libgcc -> > compiler-rt) that doesn't replace the existing OS, but would be rather > interesting to benchmark -- if only to see how much binary compatibility is > costing us. > Sounds like a lot of work to be done. - Possibly replace firewalld with ufw (because the latter has a proper > plasma interface). (Build the [fire]wall! Make Linux great again!) > -1 It's boontoo centric, and last updated in 2016. That does not sound like it is actievly maintained. This looks promising https://github.com/nx-desktop/nx-firewall > And probably the most controversial one: > - Change the filesystem layout for multilib. Some distributions have > started going for stuff like /usr/x86_64-linux-gnu/lib instead of > /usr/lib64, /usr/i686-linux-gnu/lib instead of /usr/lib etc., and that's a > really good idea because it allows installing compat libraries for more > than just one 64bit and one 32bit architecture. This is useful especially > now that qemu binfmt-misc stuff is working well and transparently launches > stuff built for other architectures (think wine on ARM being able to run > x86 Windows binaries because it has access to qemu and i686/x86_64 > libraries). With the current lib64/lib FS layout, e.g. a user on aarch64 > may want to install an x86_64 libjpeg to please whatever binary-only > application and an i686 libjpeg to please wine -- but they can't go to > /usr/lib64 (where aarch64 stuff lives) nor /usr/lib (where armv7hnl stuff > lives). > We don't have to break compatibility with anything to do this -- > /usr/lib64 and /usr/lib could be symlinks to the native 64 and 32 bit > arches, so stuff hardcoding /usr/lib64 or /usr/lib would still find what > it's looking for and install to the right place. > > Sounds interesting. > ABF: > - Better handling of errors that usually go away by trying again, such as > "[MIRROR] kauth-5.59.0-1-omv4000.znver1.rpm: Interrupted by header > callback: Server reports Content-Length: 148 but expected size is: 65492 > [FAILED] kauth-5.59.0-1-omv4000.znver1.rpm: No more mirrors to try - All > mirrors were already tried without success > Failed to set locale, defaulting to C > Error: Error downloading packages: > Cannot download kauth-5.59.0-1-omv4000.znver1.rpm: All mirrors were > tried" > - Better handling of interrupted chain builds (e.g. when building KDE > Frameworks and a build somewhere in the middle fails on one arch, allow > resuming the chain build when the failed package is fixed) > - Easier way to publish a load of interdependent packages at the same time > (e.g. build updated KDE Frameworks and rebuild Plasma against it, then > publish all at the same time so people updating in between don't end up > with a system that is part 5.58, part 5.59 and unlikely to work properly) > > I'd suggest to add support for odered mass builds. So you can easily build whole KDE frameworks in a give order :)
