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?
<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
<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