00:08 <sotaoverride> RP: I guess the explanation in my head for PACKAGECONFIG (after going over the manual now) is its just a mechanism for selectively adding EXTRA_OECONF, dependencies and a few other things to a recipe?!

00:31 <alefir> Is there a mechanism to make my tasks more verbose? I've got a do_compile thats taking a lot longer than expected and I'd like to take a peek at whats happening

02:37 <roussinm> sotaoverride: PACKAGECONFIG from my understanding is a list of configuration that you can modify or not. The declaration of a PACKAGECONFIG[gtk]... just means it's configuration that can be active. The first value before the comma is present when the configuration is active, 2nd value when value is not present, and I think after that it's DEPENDS and RDEPENDS, don't remember the exact order. So in

02:37 <roussinm> your local.conf, distro, bbappend, etc. you can modify a recipe PACKAGECONFIG by adding a value to the list or by removing a value from the list.

02:38 <roussinm> sotaoverride: if a recipe declares PACKAGECONFIG =? "gtk gtk+", by default gtk and gtk+ will be active.

02:39 <roussinm> if other options are available to the PACKAGECONFIG, those won't be active and will use the 2nd value from the declaration at configure time.

02:42 <sotaoverride> Thank you so much for that clarification roussinm: . Took me a little bit to figure that out tonight, but very glad you chimed in!

02:43 <roussinm> sotaoverride: np. Yocto a steep learning curve.

02:44 <roussinm> has a*

02:47 <roussinm> alefir: I think you can execute the job manually with the the run.do_compile job inside the temp directory of the recipe. From there you can add verbose flags. There may have many other ways.

02:52 <sotaoverride> where did the manual go ? https://gyazo.com/9c6c4d2cf1621e7d1a27bc422eac3b6a

02:53 <sotaoverride> was trying to see how RRECOMMENDS_${PN}-python worked

02:57 <sotaoverride> guess its the runtime recommended python package

02:58 <roussinm> sotaoverride: https://docs.yoctoproject.org/singleindex.html

09:32 <RP> sotaoverride: we need a mechanism where we can capture configuration information about recipes. PACKAGECONFIG is that allowing the option to enable, and disable something to be specified along with dependency information

10:34 <rburton> alefir: depends on how it builds. If it uses automake or cmake then it will already be verbose in the task log

11:53 <sotaoverride> RP: Thnaks. Get the whole design around PACKAGECONFIG, finally.

12:38 <sotaoverride> with regards to DISTRO_FEATURES, especially this phrase from the manual "For example, specifying "x11" in DISTRO_FEATURES, causes every piece of software built for the target that can optionally support X11 to have its X11 support enabled." Does every package that can possibly provide support for X11 just automagically does it when x11 is added to DISTRO_FEATURES, or do we have to add something like

12:38 <sotaoverride> DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'libx11 libxrandr', '', d)}" to recipes?

13:05 <smurray> sotaoverride: the latter, but it's more typical to have an x11 PACKAGECONFIG option in the recipes that care that gets added based on DISTRO_FEATURES instead of adding to DEPENDS directly like that

13:06 <smurray> sotaoverride: look at meta/recipes-gnome/gtk+/gtk+3.inc for one example

13:11 <vmeson> sotaoverride: are you saying that the documentation should be more explicit about the mechanism and stipulate that some software packages may have x11 features which do not get enabled with DF += x11 ? If so would you like to send a docs patch?

13:19 <sotaoverride> vmeson:, well yeah, DISTRO_FEATURES, the term does get one feeling that all software packages would be keeping an eye out for them and adjust their PACKAGECONFIG automatically.. like i dont know through a common .inc or some yocto trickery

13:33 <sotaoverride> is this the docs repo https://github.com/ndechesne/yocto-docs ??

13:34 <sotaoverride> last commit on that one was a couple years ago

13:46 <sotaoverride> vmeson: link me to the current docs repo, and the commit guidelines etc, and I can rephrase that DISTRO_FEATURES example to "specifying "x11" in DISTRO_FEATURES, will cause all recipes setup to track DISTRO_FEATURES to have X11 support enabled."

13:48 <sotaoverride> vmeson: or more like "specifying "x11" in DISTRO_FEATURES, will cause all recipes setup to track DISTRO_FEATURES to build software packages with X11 support enabled."

13:49 <sotaoverride> anyhow time to hit the beach for me any way. do link me to the repo/commit guide line when u get a chance. Dont wana be thrown off by the df docs when I go back to them couple of years from now ..

15:09 <sotaoverride> query roussinm

15:10 <sotaoverride> roussinm: could you point me to the right repo for yocto docs please?

15:10 <sotaoverride> and also the patch guidelines etc for it?

15:21 <roussinm> sotaoverride: patch guideline are probably the same as yocto in general. I think the documentation is inside the poky repository.

15:22 <roussinm> https://wiki.yoctoproject.org/wiki/Poky_Contributions

15:46 <sotaoverride> roussinm: thanks, sent an email to that help desk address with my public key (to get write access)

16:45 <RP> sotaoverride: https://git.yoctoproject.org/yocto-docs is the docs repo

19:52 <vmeson> sotaoverride: https://www.yoctoproject.org/community/ is a good starting point. There's a link to "Source Repos" and email lists and how to submit a patch. If you think something's missing there to get started, please let me know.

19:53 <vmeson> docs repo is: https://git.yoctoproject.org/yocto-docs/

19:55 <vmeson> sotaoverride: you can also just send patches to this list rather than getting an account: https://lists.yoctoproject.org/g/docs

20:40 <roussinm> on hardknott meta-oe/meta-oe/recipes-devtools/input-utils/input-utils_1.1.bb this recipe doesn't build anymore. HOMEPAGE is not reachable anymore. https://www.kraxel.org/releases/input/ looks likes new versions are up. If it's broken I assume no one is building it? Looks like it's gone from master too.

20:53 <roussinm> wait... nevermind looks like some previous employee added the recipe to meta-oe but never submitted upstream...