07:36 <vermaete> Is there a kind of policy not to have a versioned and a git bb file anymore of the same recipe?

07:36 <vermaete> I thought that this happened more in the past.

07:37 <vermaete> Now, I don't see this so often anymore.

08:55 <manuel__> `bitbake -e libsdl2-native` fails with

08:55 <manuel__> File "/home/manuel/bora-proj/poky/bitbake/lib/bb/event.py", line 133, in print_ui_queue

08:56 <manuel__> sys.stdout.flush()

08:56 <manuel__> BrokenPipeError: [Errno 32] Broken pipe

08:56 <manuel__> Is there a known bug or is it on my machine?

08:56 <manuel__> Am on dunfell branch tip from Oct 14th.

12:35 <RP> manuel__: are you piping the bitbake output to some other process?

15:57 <JaMa> RP: looks like that libfortran patch was useful, now I see cortexa7t2hf-neon-vfpv4-oe-linux-gnueabi/libgfortran/11.2.0-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/../../libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/11.2.0/ld: error: .libs/libgfortran.so.5.0.0 uses VFP register arguments, .libs/_tan_r8.o does not

15:58 <RP> JaMa: hmm, right. I wonder what I need to reproduce that. We need to better document what these patches are doing then we might stand a better chance of getting them upstream

15:59 <RP> JaMa: can you check the compile log and see if it was using gfortran from somewhere instead of XXX-gfortran ?

15:59 <JaMa> in my case it was vfp=hard from raspberrypi4 tune

15:59 <RP> or vice versa I guess

16:00 <JaMa> the build is already gone from tmpfs, will check if nodistro build with rpi4 and fortran enabled reproduces this as well

16:01 <RP> JaMa: Do have the machine/tune options needed for that just to save me guessing how you're doing it incorrectly? :)

16:02 <RP> JaMa: I suspect the real issue is some flags are going missing somewhere rather than the compiler being used

16:06 <JaMa> https://github.com/agherzan/meta-raspberrypi/blob/master/conf/machine/raspberrypi4.conf#L5 says cortexa7thf-neon-vfpv4

16:11 <agherzan> JaMa that was always the case for rpi

16:11 <JaMa> agherzan: yes, but it was building libgfortran fine until today

16:12 <agherzan> That is strange...

16:12 <JaMa> agherzan: https://git.openembedded.org/openembedded-core/commit/?id=bc5209aa5f07cea00416852532b90aba044defd5

16:12 <JaMa> and it's reproducible with nodistro as well

16:13 <JaMa> with FORTRAN:forcevariable = ",fortran" in local.conf

16:14 <agherzan> Does the patch fix the build on RPI?

16:15 <RP> agherzan: appears so

16:16 <agherzan> That is also unexpected. Looking at the patch again.

16:19 <RP> JaMa: I powered up the build machine and set a build away. Not sure I'll get to it today but at least there should be something ready to look at

16:19 <agherzan> Can you check the GFORTAN variable when it breaks and when it succeeds? JaMa

16:20 <JaMa> reverting the oe-core commit which removed the patch allows to build libfortran again

16:20 <RP> then at least we can better document it

16:21 <JaMa> well, I'm the one doing it incorrectly, so I'll use my spare CPU cycles back to autonomous cars

16:24 <RP> JaMa: "incorrectly"?

16:24 <RP> JaMa: oh, the commit message

16:25 <JaMa> 17:01 < RP> JaMa: Do have the machine/tune options needed for that just to save me guessing how you're doing it incorrectly? :)

16:25 <RP> JaMa: I meant I'd guess incorrectly, not that you are doing it that way

16:25 <RP> that was badly worded, sorry

16:28 <JaMa> ah, no problem, I'm just sick and in bad mood

16:33 <RP> JaMa: hope you feel better soon!

16:33 <RP> FWIW it is losing the CFLAGS somewhere along the way. Why changing that variable does this, not sure

16:37 <agherzan> I also agree that removing the patch is not a bad idea. We should just fix passing the right GFORTAN. This seems to have an impact on CFLAGS somehow. Which is mysterious.

16:38 <RP> agherzan, JaMa: Just confirmed http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=517418791fc2aea673cdc7c2d6a0962866bc0e60 makes it build again

16:38 <RP> agherzan: the environment sets FC and that patch allowed FC to make it to the build. Instead we can pass it though GFORTRAN (FC has the flags we're missing)

16:39 <agherzan> Right. Nice.

16:39 <agherzan> JaMa get well soon.

16:40 <JaMa> RP: agherzan: thanks

17:28 <marex> hmmm, weston no longer starts in dunfell after e0cb0077e2 ("weston: Use systemd notify,")

17:31 <marex> or rather, it does start and runs for a bit ... and then is zap'd by systemd it seems

17:31 <marex> as if the notification(?) didn't work somehow

17:31 <marex> Just removing this part from weston@.service file is enough to "fix"^W"workaround" it

17:31 <marex> +Type=notify

17:31 <marex> +NotifyAccess=all

18:48 <manuel__> RP: Initially, yes, I was piping it to less, but then the problem showed also when not piping the output into somewhere.

22:10 <JaMa> anyone else seeing ca-certificates do_fetch failures with latest honister?

22:15 <dvorkindmitry> I am building image X for target T. I need to build image Y for target t too at the same time. Is it corrct to write this like: do_install[mcdepends] += "mc:T:t:X:do_image_complete" ?