05:24 <moto-timo> JPEW: kanavin: [WIP] https://github.com/moto-timo/meta-phosh/tree/timo/phosh-0.13.1

09:53 <kanavin> moto-timo, cool, but why not just maintain poky patches ;)

09:53 <kanavin> it will go in at some point, so might be as well prepared now

13:34 <JPEW> kanavin: it needs a lot from meta-gnome IIRC

15:49 <jaskij[m]> So, I need to build some things depending on postgresql. Since pg_config is a binary, it means either relying on a native variant, which I'm not sure would give correct results, or writing a script mocking pg_config and dropping it into recipe-sysroot-native. I was thinking of using the second solution. Probably as a separate recipe which the plugins would depend on then?

15:55 <RP> jaskij[m]: a lot probably depends on what pg_config returns but a script could work either as part of portgresgl or as a separate recipe

15:56 <jaskij[m]> RP: it outputs a number of variables to stdout, mostly paths, but also version number

15:57 <jaskij[m]> There's an old python-psycopg2 which simply disables the check, but that's not the way I want go about it. Yes, python3-psycopg2 is one of the recipes I intend to write

15:58 <RP> jaskij[m]: sometimes you can also use BUILD_CC inside the recipe to generate a "cross" version of the binary which you install into the sysroot instead of the target one

15:59 <jaskij[m]> That sounds... Hacky.

15:59 <RP> jaskij[m]: realities of cross compiling. Easier to maintain than the script if the output change

15:59 <RP> just mentioning the options

16:00 <jaskij[m]> Fair. And the script I believe is fairly stable - I'm no pgsql expert, but *a lot* of 3rd party code depends on it.

16:01 <RP> right, pros and cons each way

16:01 <jaskij[m]> Or rather pg_config output should be stable

16:02 <jaskij[m]> Oh, also, before I go digging through the manual: if a recipe sets a variable (without ?), the only ways to override it is either bbappend or forcevariable, right?

16:03 <RP> well, other overrides would probably work

16:07 <jaskij[m]> Why I'm asking is Fortran, was thinking about submitting a patch to use DISTRO_FEATURES to enable it. Right now the base recipe does allow for Fortran enabled, but the base recipe sets FORTRAN to empty and it's either bbappends in my layer or using forcevariable, least for the solutions I'm aware of.

16:07 <RP> jaskij[m]: distro override?

16:08 <jaskij[m]> That's an option too, once I figure out how to do it

16:08 <jaskij[m]> I'll have to properly read up on overrides it seems.

16:09 <RP> jaskij[m]: presumably you set DISTRO to something?

16:09 <jaskij[m]> Rolled my own distro, wanted to get read of the legacy stuff as far as possible

16:10 <RP> so XXX_<distroname>

16:10 <RP> just like forcevariable but nicer

16:10 <jaskij[m]> Where? Because that still requires a bbappend for gcc

16:10 <jaskij[m]> Or am I missing something?

16:10 <RP> how do you use forcevariable without a bbappend?

16:11 <jaskij[m]> https://github.com/tuxable-ltd/meta-scipy

16:11 <jaskij[m]> And I'm not using it

16:11 <jaskij[m]> I just set FORTRAN in a bbappend

16:11 <RP> jaskij[m]: you can do something like VAR_pn-XXX_mydistro from your distro config

16:14 <jaskij[m]> that works too I guess

17:07 <RP> possibly, maybe

17:21 <moto-timo> \o/

17:22 <RP> well, a way to reproduce it perhaps

17:22 <moto-timo> baby steps

17:22 <RP> it is amazing how may weird issues these patches are forcing out the woodwork :/

17:23 <moto-timo> ultimately I suppose that is a good thing.. despite some pain now

18:23 <moto-timo> JPEW: I misplaced your mod to build mutter-gsettings subpackage... also phosh now has an rdep of libcallaudio which we don't have a recipe for yet

20:30 <moto-timo> JPEW: added callaudiod recipe and it builds and boots on rpi4

20:34 <JPEW> moto-timo: awesome! Thanks! I need to get my CI up and running so I can keep that layer maintained

20:35 <moto-timo> JPEW: need to figure out how to set the passcode for the lockscreen

20:35 <JPEW> It's just the user password

20:35 <moto-timo> it's a number pad...

20:35 <moto-timo> but maybe I didn't set a password

20:35 <JPEW> Ya it can only be digits, but it's just plugging into pam

20:36 <JPEW> It doesn't allow an empty password (possible upstream improvement)

20:39 <JPEW> I just set the user password on the serial console when I was testing before

21:24 <marex> hey, I have a layer here and I build e.g. linux-yocto 5.13 for two different machines, they are almost identical aarch64 ones

21:24 <marex> I have a machine config for each, i.e. machine-1.conf and machine-2.conf , so they each have different MACHINE variable

21:25 <marex> now if building linux-yocto, that MACHINE variable is pulled into do_unpack task hash, and it changes, so sstate cache invalidates the task and rebuilds linux-yocto

21:25 <marex> is there a way to avoid it ?

21:25 <marex> I mean, the KMACHINE is the same for both, the kernel config is the same, all the scc files pulled in are the same

21:26 <marex> it should be identical kernel build

21:26 <marex> so , how do I avoid this rebuild ?

21:33 <RP> marex: how is it being included in do_unpack exactly?

21:36 <jaskij[m]> marex: multiconfig

21:37 <jaskij[m]> Also, is the device tree the same for both?

21:37 <jaskij[m]> Because (as annoying as it is), those are also part of the kernel recipe

21:38 <RP> jaskij[m]: I think the point is that it could reuse sstate for both

21:38 <marex> RP: yep

21:39 <RP> marex: Im sure it could be done. Whether it is worth it, not as sure as it will be complex :/

21:39 <marex> it does show up in bitbake-diffsigs for do_unpack after running .../work/OE/poky/scripts/sstate-diff-machines.sh

21:39 <RP> marex: right, but the question is where/how. I'm guessing it is because the package arch is machine specific

21:40 <RP> marex: so to make it work you'd need to create a shared package arch for those machines, maybe based on KAMCHINE

21:40 <marex> RP: shared machine arch ?

21:41 <marex> I suppose MACHINEOVERRIDES = . "shared-arch:" is not enough ?

21:41 <RP> marex: not even close

21:42 <marex> somehow I expected that kind of answer

21:42 <RP> marex: the real issue is the kernel is PACKAGE_ARCH = MACHINE_ARCH

21:46 <marex> RP: well that is kind-of true, except only for a subset of tasks

21:46 <marex> the do_unpack for linux-yocto shouldn't really be MACHINE_ARCH, should it ?

21:53 <RP> marex: the WORKDIR is machine specific so yes, it would be

21:55 <marex> ah ... of course it is

22:25 <ram> Hi, I'm trying to build a yocto project with a custom layer. I'm having the following error "Processing dependencies for protobuf==3.3.0 Searching for six>=1.9 ". I have checked for the external libraries available and I can see python-six available. Can anyone help me to identify the issue?

22:31 <marex> ram: try python3-six ?

22:36 <ram> @marex When I do "bitbake -s | grep ^python3", I can see that python3-six with version 1.11.0 is already available

22:40 <marex> ram: does your recipe DEPENDS on python3-six ?

22:45 <ram> @marex I tried to add python3-six in the bb file of the recipe and build it but still I get the same error

22:51 <marex> ram: is the search path for those python modules OK ?

22:57 <ram> @marex how do I verify that?

23:20 <marex> ram: try bitbake -e recipe, that will print all the build time variables and co.