01:32 <vd> cross-canadian.bbclass is resetting ABIEXTENSION/TARGET_OS for some reasons...

08:28 <RP> khem: seems very odd. Was that master-next?

09:01 <RP> khem: it could be the pclist change in master-next. I think gatlib may be doing something odd with pc files?

10:15 <RP> khem: it is that change. Looking into it

10:16 <RP> khem: the code is actually right. The .pc is in the main ${PN}, not ${PN}-dev :)

10:22 <RP> khem: patch sent

14:48 <override_> been trying to get this right for a while now. I need my image recipe to give out just the root filesystem compressed (bmap supported fomrat) along with the bmap file for it. How do i go about it? There doesnt seely appear to be class for bmap I can just append to IMAGE_FSTYPE

14:55 <RP> override_: bmap is an additional file to the base one so it is seen as a "compression" type for bitbake. Doesn't something IMAGE_FSTYPE = "tar.gz.bmap" work? I assume you just want a tarball for the base rootfs?

14:56 <RP> override_: which base format do you want the root filesystem in?

15:04 <whuang0389> is it normal for qt builds to look like it has hanged for few hours?

15:04 <whuang0389> and CPU usage is near 0%

15:04 <whuang0389> lol

15:05 <moto-timo> RP: welll spotted on gattlib, thank you

15:06 <RP> moto-timo: was nice my fixes were actually finding a real problem rather than breaking it :)

15:06 <moto-timo> RP: indeed!

15:30 <override_> RP: IMAGE_FSTYPES += "wic.bmap"

15:30 <override_> IMAGE_FSTYPES += "wic.bmap"

15:31 <override_> gives you the wiz.gz & the wic.bmap for it..

15:32 <override_> think thats all that I wanted

15:33 <override_> RP: have you used bmaptool much with python? Trying to see if I can add it to python as a python module, rather than calling it from a subprocess..

15:41 <ant__> RP: hi

15:41 <ant__> so I have about 20 @bb.utils.contains in one file...sincerely too many

15:42 <ant__> even converting to packageconfig seems futile

15:42 <ant__> (would need the same check)

15:43 <ant__> do you remember offhand one class processing these 'switch' procedures?

15:43 <ant__> as example?

15:45 <ant__> see https://tinyurl.com/3cvutj5v and again #180

15:46 <ant__> sorry the .bb not the .inc https://tinyurl.com/74rx649m

15:51 <ant__> is it worth to 'optimize'?

15:57 <ant__> hmm... contains_any ...reading

16:00 <ant__> no

16:11 <RP> ant__: doesn't look that bad to me. I'm not sure how you'd optimize it more

16:15 <JaMa> whuang0389: it's more normal to see 100% CPU for few hours (e.g. for qtwebruntime build), not 0%

16:16 <JaMa> tail -f the log.do_compile log to see if something is really happening or not (the linking can take very long)

16:27 <RP> Finally, only native differences in these two test builds

16:35 <whuang0389> JaMa yea nothing is going on when i tail any of the qt compile logs

17:49 <ant__> RP, ok, thanks

19:21 <vd1785> khem: hi -- .../meta-qt5/recipes-qt/qt5/qtwebengine_git.bb:do_install fails with sed: can't read .../build/tmp/work/armv7at2hf-neon-poky-linux-gnueabi/qtwebengine/5.15.2+gitAUTOINC+5537ff4437_f5a93d251c-r0/image/usr/lib/pkgconfig/Qt5WebEngineCore.pc: No such file or directory. Does that ring a bell to you?

19:29 <vd1785> Aren't patches like meta-qt5/bf2daefeb57ac4c3e4bc39af3ddbfa6719978931 supposed to be ported to branches like hardknott?

19:30 <vd1785> That new override syntax really made development a PITA these last weeks :-(

19:41 <vd1785> The main issue with OpenEmbedded/Yocto is that not all layers maintainers respect the branching models. Patches aren't backported and kept on top of incompatible features, many layers don't even bother creating the release branches. It'd be really helpful to enforce these policies at least on layers approved under the Yocto umbrella...

19:41 <vd1785> Cc: RP ^

21:53 <argonautx> hello out there, I just tried to build my sdk with populate_sdk_ext and got an error "undefined reference to `xdr_uint32'

21:53 <argonautx> Im building on Debian testing, is this fixable?

22:01 <RP> vd: we can't really force anyone to do anything

22:02 <RP> argonautx: had to know with just that to go on

22:20 <argonautx> RP: what do you need to know?

22:22 <RP> argonautx: which executable showed the undefined reference? which task failed? where in the task did it fail? did this used to work and you changed something which caused it to fail?

22:26 <RP> argonautx: the project release series you're trying to build would be good to know too. That sounds like some of the rpc/nis changes but if it were that, it would be rather old?

22:27 <vd> RP: backports cannot be track easily for sure but requiring release branches shouldn't be hard to check...

22:29 <RP> vd: Who is going to check and enforce this? We can't force anyone to do anything. Most people are also volunteers when it comes to a lot of the work

22:29 <argonautx> RP: of course, here is the log file http://codepad.org/kjYMgZuO

22:30 <RP> argonautx: so unfs3-native failed. If you're not using NFS in your SDK you could remove that dependency as a really easy work around

22:31 <vd> RP: what about a bitbake sanity class to ensure that git-fetched layers have a release branch? A check similar to the layer compat.

22:32 <RP> argonautx: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=f3ea5898cb915eaea7d8a32e30eb504820c71917 looks relevant

22:33 <RP> vd: we did add the LAYER_* series variables for this reason and that causes enough complaints, I don't think there is the interest in mandating branches

22:34 <argonautx> RP: thank you

22:50 <vd> RP: the problem is that because you "can't force anyone to do anything", applications like QtWebEngine cannot compile basically. Latest master branches are too unstable (especially when something like a new syntax arrives), and common release branches aren't present or badly maintained. This results in no known reference versions to build a project

22:50 <vd> and forcing the end user to tweak, revert, backport or cherry-pick changes here and there.

22:51 <moto-timo> Welcome to open source

22:52 <vd> moto-timo that is wrong. This is mainly a problem of distributed projects. Monolitic projects like the kernel or buildroot are less likely to break the compilation of know releases.

22:53 <vd> known*

23:06 <RP> vd: I think you should demand a refund ;-)

23:06 <RP> vd: seriously, whilst I do appreciate the pain points, this is an open source project and community. We rely on a lot of people's best efforts

23:07 <RP> vd: not all layers are going to be maintained to the same standard. I'm fairly sure some of them would welcome help maintaining stable branches

23:10 <RP> sadly https://autobuilder.yoctoproject.org/typhoon/#/builders/118/builds/742 appeared in a full from scratch build :/

23:14 <moto-timo> RP: a little suspicious they are ‘noarch’ or ‘all’

23:14 <moto-timo> RP: and font related?

23:24 <RP> moto-timo: yes, and fallback vs. correct timestamp changes only