ChanServ changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2021.11) Nov 30 - Dec 2, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec
sakoman has joined #yocto
Guest40 has quit [Quit: Client closed]
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #yocto
RobertBerger has joined #yocto
<vd> cross-canadian.bbclass is resetting ABIEXTENSION/TARGET_OS for some reasons...
rber|res has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
sakoman has quit [Quit: Leaving.]
Vonter has joined #yocto
sakoman has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
pgowda_ has joined #yocto
sakoman has quit [Quit: Leaving.]
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
RobertBerger has quit [Remote host closed the connection]
RobertBerger has joined #yocto
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
RobertBerger has quit [Remote host closed the connection]
RobertBerger has joined #yocto
ant__ has joined #yocto
RobertBerger has quit [Ping timeout: 246 seconds]
RobertBerger has joined #yocto
vd17 has joined #yocto
vd has quit [Ping timeout: 256 seconds]
<RP> khem: seems very odd. Was that master-next?
RobertBerger has quit [Ping timeout: 252 seconds]
RobertBerger has joined #yocto
vd1785 has joined #yocto
RobertBerger has quit [Ping timeout: 252 seconds]
vd17 has quit [Ping timeout: 256 seconds]
<RP> khem: it could be the pclist change in master-next. I think gatlib may be doing something odd with pc files?
goliath has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
nerdboy has quit [Ping timeout: 252 seconds]
<RP> khem: it is that change. Looking into it
<RP> khem: the code is actually right. The .pc is in the main ${PN}, not ${PN}-dev :)
<RP> khem: patch sent
zyga-mbp has quit [Quit: Textual IRC Client: www.textualapp.com]
florian has joined #yocto
florian has quit [Ping timeout: 252 seconds]
amitk_ has quit [Quit: leaving]
florian has joined #yocto
jwillikers has joined #yocto
Debate2021 has joined #yocto
Debate2021 has left #yocto [#yocto]
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
florian has quit [Ping timeout: 252 seconds]
florian has joined #yocto
amitk has joined #yocto
amitk has quit [Client Quit]
amitk has joined #yocto
xmn has joined #yocto
<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
<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?
<RP> override_: which base format do you want the root filesystem in?
whuang0389 has joined #yocto
<whuang0389> is it normal for qt builds to look like it has hanged for few hours?
<whuang0389> and CPU usage is near 0%
<whuang0389> lol
<moto-timo> RP: welll spotted on gattlib, thank you
<RP> moto-timo: was nice my fixes were actually finding a real problem rather than breaking it :)
<moto-timo> RP: indeed!
* RP thinks he is chasing phantoms in the autobuilder sstate. Time to change to a new version number I think
<override_> RP: IMAGE_FSTYPES += "wic.bmap"
<override_> IMAGE_FSTYPES += "wic.bmap"
<override_> gives you the wiz.gz & the wic.bmap for it..
<override_> think thats all that I wanted
<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..
jwillikers has quit [Quit: jwillikers]
jwillikers has joined #yocto
<ant__> RP: hi
<ant__> so I have about 20 @bb.utils.contains in one file...sincerely too many
<ant__> even converting to packageconfig seems futile
<ant__> (would need the same check)
<ant__> do you remember offhand one class processing these 'switch' procedures?
<ant__> as example?
<ant__> see https://tinyurl.com/3cvutj5v and again #180
<ant__> sorry the .bb not the .inc https://tinyurl.com/74rx649m
<ant__> is it worth to 'optimize'?
<ant__> hmm... contains_any ...reading
<ant__> no
xmn has quit [Quit: ZZZzzz…]
sakoman has joined #yocto
bblob has quit [Ping timeout: 250 seconds]
<RP> ant__: doesn't look that bad to me. I'm not sure how you'd optimize it more
<JaMa> whuang0389: it's more normal to see 100% CPU for few hours (e.g. for qtwebruntime build), not 0%
<JaMa> tail -f the log.do_compile log to see if something is really happening or not (the linking can take very long)
<RP> Finally, only native differences in these two test builds
<whuang0389> JaMa yea nothing is going on when i tail any of the qt compile logs
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
wwilly has joined #yocto
<ant__> RP, ok, thanks
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
zyga-mbp has joined #yocto
ant__ has quit [Remote host closed the connection]
<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?
tangofoxtrot has quit [Remote host closed the connection]
tangofoxtrot has joined #yocto
<vd1785> Aren't patches like meta-qt5/bf2daefeb57ac4c3e4bc39af3ddbfa6719978931 supposed to be ported to branches like hardknott?
<vd1785> That new override syntax really made development a PITA these last weeks :-(
<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...
<vd1785> Cc: RP ^
mranostaj has quit [Quit: leaving]
xmn has joined #yocto
vd178565 has joined #yocto
vd178565 is now known as vd
vd1785 has quit [Ping timeout: 256 seconds]
mranostaj has joined #yocto
sakoman has quit [Quit: Leaving.]
m4ho has quit [Ping timeout: 246 seconds]
sakoman has joined #yocto
m4ho has joined #yocto
sakoman has quit [Client Quit]
florian has quit [Ping timeout: 252 seconds]
sakoman has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
argonautx has joined #yocto
<argonautx> hello out there, I just tried to build my sdk with populate_sdk_ext and got an error "undefined reference to `xdr_uint32'
<argonautx> Im building on Debian testing, is this fixable?
florian has joined #yocto
<RP> vd: we can't really force anyone to do anything
<RP> argonautx: had to know with just that to go on
<argonautx> RP: what do you need to know?
<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?
<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?
florian has quit [Ping timeout: 252 seconds]
<vd> RP: backports cannot be track easily for sure but requiring release branches shouldn't be hard to check...
<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
<argonautx> RP: of course, here is the log file http://codepad.org/kjYMgZuO
<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
<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.
<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
<argonautx> RP: thank you
<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
<vd> and forcing the end user to tweak, revert, backport or cherry-pick changes here and there.
<moto-timo> Welcome to open source
<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.
<vd> known*
florian has joined #yocto
<RP> vd: I think you should demand a refund ;-)
<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
<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
<RP> sadly https://autobuilder.yoctoproject.org/typhoon/#/builders/118/builds/742 appeared in a full from scratch build :/
* RP has no idea why that is breaking
<moto-timo> RP: a little suspicious they are ‘noarch’ or ‘all’
<moto-timo> RP: and font related?
Tokamak_ has quit [Read error: Connection reset by peer]
<RP> moto-timo: yes, and fallback vs. correct timestamp changes only
Tokamak has joined #yocto
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
* RP tried to sleep but had an idea, may as well test that overnight
argonautx has quit [Quit: Leaving]