00:08 <paulg> heh. serves emacs users right.

00:09 <paulg> In fairness, and joking aside - one thing that has always drove me nuts about Ubuntu is absolutely indefensible dependency chains.

00:10 <paulg> e.g. some evolution package (which I never use) -- try and remove it, and it wants to remove all of gnome in turn.

00:11 <paulg> I've seen similar for bluez (bluetooth) and cups (printing) packages.

00:12 <paulg> And the most hateful of all -- "trackerd". Most "normal" people would never notice, but if you are one of those people who like to prune crap to limit the number of unused daemons running and speed up boot, you'll run into such frustrations...

05:23 <khem> paulg: yeah those rdeps run deep and wild, perhaps too granular packaging in yore, rust and go has pushed the dependency hell to build time, which is better than runtime deps to manage but still hell

05:27 <paulg> khem, agreed - gets to the point where you just feel defeated and give up trying to untangle it ; stoop to hacks like rc.local clobbering all trackerd binaries and replacing them with links to /bin/true

05:29 <khem> people get their distros wedged often by installing something simple looking and uninstalling it, which in effect does not restore it to prior state

05:31 <khem> emacs is an editor why would it need to install a gcc devel package. one would wonder

05:34 <khem> now think of such a system, you are building a C/C++ project natively using llvm/clang and you are going to use emacs to edit your project and you install it, next time you build your project it will link to different gcc runtime !

05:34 <khem> people use containers etc. to hide this pain

05:35 <khem> oh well

08:58 <phako_> hello... Say I'd need to backport a newer GCC version to an older release - Naïvely I thought I can just copy the corresponding recipes-devtools/gcc folder into my layer and set GCCVERSION, but I end up with "ERROR: Nothing PROVIDES 'virtual/x86_64-pokysdk-linux-binutils'" and I am not sure whether that's because I forgot to copy something or

08:58 <phako_> something has changed between the two releases :-/

09:23 <mcfrisk> phako_: can be done but a lot more changes and adaptations are needed if the version jump is big.

09:26 <phako_> GCC would be 12 -> 13, I took the recipes from scarthgap into langdale (yes, I know, I know, can't do much about it other then complaining internally)  - probably should have taken it from nanbield?

09:51 <phako_> think I found it, sorry.  /me starts a build and sees what explodes

11:18 <phako_> narrator: everything. everything exploded

11:37 <RP> phako_: gives you an idea of the work that goes on in core just to keep things updated!

11:39 <phako_> yeah... trying strategy 2 now: convincing people to update

11:44 <mcfrisk> phako_: it may be easier to keep some old SW versions, e.g. BSP layer, while updating most of the open source stack to new yocto version. security and bug fixes come as by product. though disk, CPU and RAM usage may slightly increase due to new features, though often there are relatively easy ways to get the old storage, CPU and/or RAM usage state back with some tweaks, e.g. reduce features and compile

11:44 <mcfrisk> with size optimizations

11:51 <phako_> we are somehow bound to the xilinx tooling version

11:54 <mcfrisk> it possible to keep that while update the rest

12:28 <phako_> yeah but the recommendation is otherwise, and people do not want to stray from that. Anyway, we have just decided to not support anything < scarthgap anymore. \o/

17:10 <khem> some layers try to be compatible across releases, some of them are application layers e.g. meta-qt6 but its quite a task to do so. Assess the amount of work for backporting and maintaining things like gcc versions, its non-trivial amount of time and you are forking away from community and depriving yourself of any little support you might rely on community for

19:35 <alperak> I want to add a flag to CXXFLAGS if the recipe is built with clang instead of gcc. I did something like this:

19:35 <alperak> CXXFLAGS:append = "${@bb.utils.contains('TOOLCHAIN', 'clang', ' -Wno-error=vla-cxx-extension', '', d)}"

19:35 <alperak> but I'm not sure if this is the proper way. I have to do it something like that because GCC doesn't have this flag. I sent a fix to upstream about the error caused by the flag, but I have to do this workaround for now.

19:37 <alperak> Why don't I just use grep and look at the recipes ???!!!!??? looks like the proper way is like this:

19:37 <alperak> Sorry for the noise.

19:37 <alperak> CXXFLAGS:append:toolchain-clang