Wednesday, 2018-10-03

*** tgraydon <tgraydon!~textual@> has quit IRC00:04
*** nighty- <nighty-!> has joined #yocto00:07
*** JaMa <JaMa!~martin@> has joined #yocto00:09
*** Cbast <Cbast!~sfrigon@> has quit IRC00:36
*** Hooloovo0 <Hooloovo0!> has quit IRC00:55
*** chandana73 <chandana73!~ckalluri@> has quit IRC00:56
*** Hoolootwo <Hoolootwo!> has joined #yocto01:05
*** Hoolootwo <Hoolootwo!> has quit IRC01:17
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC01:18
*** Hoolootwo <Hoolootwo!> has joined #yocto01:25
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto01:29
*** Hoolootwo <Hoolootwo!> has quit IRC01:31
*** Hoolootwo <Hoolootwo!> has joined #yocto01:38
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC01:48
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto01:49
*** armpit <armpit!> has quit IRC01:56
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC01:58
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto02:18
*** Hoolootwo <Hoolootwo!> has quit IRC02:28
*** Hoolootwo <Hoolootwo!> has joined #yocto02:32
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC03:19
*** chandana73 <chandana73!~ckalluri@> has joined #yocto03:23
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto03:23
*** Hoolootwo <Hoolootwo!> has quit IRC03:30
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC03:35
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto03:39
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC03:49
*** armpit <armpit!~armpit@2601:202:4180:c33:387c:5729:e2c3:c506> has joined #yocto03:51
*** Hoolootwo <Hoolootwo!> has joined #yocto03:57
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC04:36
*** nighty- <nighty-!> has quit IRC04:47
*** nighty- <nighty-!> has joined #yocto04:47
*** nighty- <nighty-!> has quit IRC04:55
*** anujm <anujm!~anujm@> has joined #yocto05:02
*** nighty- <nighty-!> has joined #yocto05:12
*** seebs <seebs!~seebs@> has quit IRC05:31
*** rburton <rburton!> has quit IRC06:00
*** rburton <rburton!> has joined #yocto06:01
*** chandana73 <chandana73!~ckalluri@> has quit IRC06:13
*** chandana73 <chandana73!~ckalluri@> has joined #yocto06:14
*** geissonator <geissonator!~geissonat@> has joined #yocto06:24
*** geissonator <geissonator!~geissonat@> has quit IRC06:29
*** tprrt <tprrt!~tprrt@> has joined #yocto06:31
*** Hoolootwo <Hoolootwo!> has quit IRC06:39
*** Hoolootwo <Hoolootwo!> has joined #yocto06:54
*** varjag <varjag!> has joined #yocto07:00
*** Hoolootwo <Hoolootwo!> has quit IRC07:04
*** Hoolootwo <Hoolootwo!> has joined #yocto07:06
*** smartin_ <smartin_!> has joined #yocto07:14
*** armpit <armpit!~armpit@2601:202:4180:c33:387c:5729:e2c3:c506> has quit IRC07:19
*** fitzsim <fitzsim!> has quit IRC07:19
*** mixfix41 <mixfix41!~swr42@unaffiliated/mixfix41> has quit IRC07:19
*** quite <quite!quite@unaffiliated/quite> has quit IRC07:19
*** chrysh <chrysh!> has quit IRC07:19
*** smartin <smartin!> has quit IRC07:19
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC07:19
*** abelloni <abelloni!> has quit IRC07:19
*** seebs <seebs!~seebs@> has joined #yocto07:23
*** quite <quite!quite@unaffiliated/quite> has joined #yocto07:23
*** mixfix41 <mixfix41!~swr42@unaffiliated/mixfix41> has joined #yocto07:26
*** armpit <armpit!~armpit@2601:202:4180:c33:387c:5729:e2c3:c506> has joined #yocto07:32
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto07:32
*** anujm <anujm!~anujm@> has quit IRC07:33
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto07:47
*** zagor_ <zagor_!~zagor@rockbox/developer/Zagor> has joined #yocto07:49
*** zagor <zagor!~zagor@rockbox/developer/Zagor> has quit IRC07:49
*** rburton <rburton!> has quit IRC07:54
*** rburton <rburton!> has joined #yocto07:55
*** Hoolootwo <Hoolootwo!> has quit IRC07:59
*** armpit <armpit!~armpit@2601:202:4180:c33:387c:5729:e2c3:c506> has quit IRC08:13
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC08:13
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:6c8e:47b7:2e48:bb6c> has joined #yocto08:14
*** Hoolootwo <Hoolootwo!> has joined #yocto08:17
*** anujm <anujm!~anujm@> has joined #yocto08:18
*** abelal <abelal!~quassel@> has joined #yocto08:23
*** armpit <armpit!~armpit@2601:202:4180:c33:387c:5729:e2c3:c506> has joined #yocto08:27
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto08:27
*** Hoolootwo <Hoolootwo!> has quit IRC08:49
*** armpit <armpit!~armpit@2601:202:4180:c33:387c:5729:e2c3:c506> has quit IRC08:51
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC08:51
*** zagor_ is now known as zagor08:52
*** Hoolootwo <Hoolootwo!> has joined #yocto08:52
*** Bunio_FH <Bunio_FH!> has quit IRC09:03
*** armpit <armpit!~armpit@2601:202:4180:c33:387c:5729:e2c3:c506> has joined #yocto09:05
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto09:05
*** Bunio_FH <Bunio_FH!> has joined #yocto09:08
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:6c8e:47b7:2e48:bb6c> has left #yocto09:12
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:6c8e:47b7:2e48:bb6c> has joined #yocto09:12
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:13
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:17
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto09:24
*** kuzulis <kuzulis!~kuzulis@> has joined #yocto09:34
kuzulisHi guys, how I can remove 'matchbox-terminal' and 'matchbox-wm' from an image? It is in sources/poky/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb09:36
kuzulisI want to create an own customised image from my layer09:36
kuzulisSo, I don't midify that sources/poky/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb09:37
kuzulisPreviously U have removed 'xinput-calibrator' using RDEPENDS_packagegroup-core-x11-utils_remove_pn-packagegroup-core-x11 = "xinput-calibrator"09:38
kuzulisbut it is magic for me09:38
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto09:39
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto09:43
abelalkuzulis: you can use the same syntax to remove things from packagegroup-core-x11-base09:45
abelalyou'll have to use RDEPENDS_pn-packagegroup-core-x11-base_remove = "matchbox-terminal matchbox-wm"09:46
abelalyou'll have to do this in your local.conf or otherwise create an append in your layer for packagegroup-core-x11-base09:47
abelalthen use RDEPENDS_${PN}_remove = "matchbox-terminal matchbox-wm"09:47
abelalinside the append09:47
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC09:48
*** Hoolootwo <Hoolootwo!> has quit IRC09:48
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto09:48
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC09:50
kuzulisI tried this: RDEPENDS_packagegroup-core-x11-base_remove_pn-packagegroup-core-x11-base = "matchbox-terminal" seems it work09:51
rburtonkuzulis: all those packagegroups are there to be modified, copied, or just ignored.09:51
kuzulisabelal: What is more right way? use local.conf of .bbapend?09:51
kuzulisok, many thanks, I will try09:52
kuzulisIf I want to use .bbapend.. What is recipe name I need? recipes-graphics/packagegroups/packagegroup-core-x11-base/packagegroup-core-x11-base.bbapend ?09:55
kuzulisor: /recipes-graphics/packagegroups/packagegroup-core-x11-base.bbappend ?09:57
kuzulisok, many thanks :)09:58
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:6c8e:47b7:2e48:bb6c> has quit IRC09:58
kuzulisSo, as I understand, this path should reflect the source *.bb path? E.g. for example if source path is: sources/poky/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb09:59
kuzulisthen overriding path should be : recipes-graphics/packagegroups/packagegroup-core-x11-base.bbappend ?09:59
rburtonpath is actually irrelevant, its filename that counts09:59
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC09:59
kuzulisdo you mean that only 'packagegroup-core-x11-base.bbappend' makes sense?10:00
*** lukma <lukma!> has joined #yocto10:01
kuzulisthat it should be same as source '' ?10:01
rburtoni mean as long as it has that filename, it can be anywhere10:01
kuzulisso, is it enough just add .bbapend instead of .bb with same file name, and to plase a resulting .bbapend file to any location?10:04
kuzulisof my layer10:05
*** anujm <anujm!~anujm@> has quit IRC10:05
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto10:08
lukmaI do have a recipe, which provides10:09
lukmafoo, foo-test, foo-12310:09
lukmaAnd then I would like to use the "foo, foo-test and foo-123" with OVERRIDES10:10
lukmaunfortunately when I call bitbake foo or bitbake foo-12310:10
lukmaI only have pn-foo in OVERRIDES10:10
lukmais there a neat way to extend OVERRIDES with exact recipe name (foo, foo-123) passed to bitbake ?10:11
lukmaIs it recommended?10:11
lukma(The alternative would be to create a special machine, but this seems to me as an overkill)10:12
rburtonlukma: the override is the real recipe name, not the provides10:13
lukmarburton: But is there a way to "tie" provide "name" with the OVERRIDES?10:15
lukmarburton: And maybe the most important question - is it recommended (or do I something totally wrong)10:15
rburtonyou might want to step back and explain what you're trying to solve where the solution is being able to use PROVIDES in overrides10:17
*** Hoolootwo <Hoolootwo!> has joined #yocto10:17
lukmarburton: The problem is that I do have a recipe for u-boot10:17
lukmathis recipe uses SCR_URI_append_123 ..... for (123 version)10:18
lukmaSRC_URI = (default u-boot)10:18
lukmaand SRC_URI_append_foo ..... for foo10:18
lukmaaccording to SRC_URI it applies different set of patches in do_patch10:19
rburtonwhy not have different recipes that include the main one and then extend the SRC_URI10:19
rburtonthree actual recipes instead of one and a maze of overrides10:19
lukmarburton: Hmm......10:19
lukmarburton: It may work...... yes :)10:20
kuzulisrburton: I have created  recipes-graphics/packagegroups/packagegroup-core-x11-base.bbappend and add there RDEPENDS_${PN}_remove = "matchbox-terminal matchbox-wm".. But it does not work10:21
lukmarburton: Thanks for help :)10:21
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto10:23
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC10:26
kuzulisrburton: Ah.. I need in addition to add in my this: IMAGE_INSTALL += "... packagegroup-core-x11-base "10:27
*** tgoodwin <tgoodwin!> has joined #yocto10:38
*** Hoolootwo <Hoolootwo!> has quit IRC10:50
*** Hoolootwo <Hoolootwo!> has joined #yocto11:02
kuzulisGuys, anouther question. How I can add symlink: ln -s /lib/ ${D}/lib/ ?11:06
kuzulisI have created /recipes-core/glibc/glibc_%.bbappend with this content11:06
kuzulisdo_install_append() {11:07
kuzulis    ln -s /lib/ ${D}/lib/
kuzulisWhat I should do next?11:07
kuzulisOr I do wrong?11:08
*** Hoolootwo <Hoolootwo!> has quit IRC11:16
*** Hoolootwo <Hoolootwo!> has joined #yocto11:19
tgoodwinkuzulis: I'm just walking into this but it looks like you're trying to setup a link into the host /lib rather than your recipe's work area (i.e., like ${S}/lib/
tgoodwinall, is there something funny about trying to DEPENDS against base-files?  My recipe-sysroot isn't being populated with its files.  (rocko, 2.4.3)11:20
*** nighty- <nighty-!> has quit IRC11:20
*** Hoolootwo <Hoolootwo!> has quit IRC11:21
yoctiNew news from stackoverflow: Yocto development image with bbappend in multiple layers <>11:27
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto11:31
derRichardone of my packages fetches the latest source via git and the build script is using git describe to generate a version string. but it seems like bitbake fetches the git tree but then builds from a non-git copy.11:43
derRichardis there a way to build _within_ the git tree such that git describe can work?11:44
rburtonare you using inherit autotools?11:46
angelo_tsmistery: in a custom recipe, in do_install() i do "${OBJCOPY} -O binary vmlinux linux.bin". The linux.bin comes half of the expected size. If execute the same objcopy command in the build dir, i get the proper linux.bin size.11:48
derRichardrburton: no, cmake11:50
derRichardrburton: hmm, looks like cmake does not find git within bitbake ;-\11:52
derRichardthen i start -c devshell git is here (hosttools)11:52
rburtonderRichard: cmake also does a build inside a separate directory (out of tree build)11:53
rburtoni suspect the git call is just broken11:53
rburtontry doing an out-of-tree build yourself outside of OE where the build directory is *above* the clone11:53
derRichardrburton: yes, i fear you are right :)11:53
rburtonif the cmakelists is going to call git to find the version of the repo it should tell git where the clone is11:54
*** Hoolootwo <Hoolootwo!> has joined #yocto11:57
*** JaMa <JaMa!~martin@> has quit IRC11:59
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:08
derRichardrburton: ok, the cmakelists is b0rked. but dunno why. find_package(Git) fails when i build with bitbake12:09
rburtongit is in hosttools, so that's a question for cmake12:12
kuzulistgoodwin: No, seems it is not work nor with {S} nor with {D}..12:15
kuzulisGuys, how I can know that my custom do_install_append() was called?12:16
derRichardrburton: FWIW, OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "BOTH" did the trick12:16
tgoodwinkuzulis: where does that file exist?12:19
kuzulistgoodwin: In: meta-my-layer/recipes-core/glibc/glibc_%.bbappend12:20
kuzulistgoodwin: I use similar approach from:
tgoodwinkuzulis: no I mean the actual library you're trying to link (  Is it a product of your do_compile?12:21
tgoodwinkuzulis: that linking command in the reference and how you're using it is saying to link from your host operating system's /lib into your do_install destination (D).  That's very likely what you do not want to do since your host OS lib will not exist on the target.  I'm pretty sure a bitbake QA will pick that up and complain about contamination or something.12:24
kuzulistgoodwin: is a symlink to ld-2.25.so12:24
kuzulistgoodwin: On a target the (symlink) and (shared lib) are present12:27
angelo_tsabout the mistery above, finally found the u-boot layer compress the image (into half of the size) before the objcopy, btw, not clear why.12:27
kuzulistgoodwin: But I need in additional symlink to (aka
kuzulistgoodwin: I don't know how to do it at all12:29
tgoodwinkuzulis: I think what you're really trying to do is "ln -s ${D}/lib/ ${D}/lib/".12:29
tgoodwinkuzulis: sorry, I think I have that backwards if I'm understanding you right.  The real link you're trying to link to is the first argument, the new link you're trying to create is the second.12:31
kuzulistgoodwin: Yes, "ln -s <file> <symlink>"12:32
kuzulistgoodwin: But it does not work... :(12:32
kuzulistgoodwin: How I can see that my do_install_image() were called at all?12:33
tgoodwinkuzulis: but the fundamental thing is that you definitely do not want to link to _just_ /anything from your recipe since that leading / goes back to your host OS.12:33
kuzulistgoodwin: s/do_install_image()/do_install_append()12:33
tgoodwinkuzulis: check your package's working directory for "temp".  The logs are in there (you can also find the path probably in the error messages you're seeing).12:34
kuzulistgoodwin: ok, many thanks, I'll try12:34
tgoodwinkuzulis: so just to clarify, the line should be: ln -s ${D}/lib/ ${D}/lib/
tgoodwinI just tried it out in my glibc working area and it was fine.12:35
tgoodwinDoes anyone know of a reason why do_prepare_recipe_sysroot would skip unpacking a package in DEPENDS?12:36
tgoodwinkuzulis: you're welcome :) hope it works12:37
*** pohly <pohly!> has joined #yocto12:40
tgoodwinI have a recipe that only depends on base-files but only /etc/skel is being installed into the recipe-sysroot.12:45
*** lukma <lukma!> has left #yocto12:49
*** Hoolootwo <Hoolootwo!> has quit IRC12:52
*** pohly <pohly!> has quit IRC12:58
*** Hoolootwo <Hoolootwo!> has joined #yocto13:00
*** ant_work <ant_work!> has joined #yocto13:01
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto13:08
*** kuzulis <kuzulis!~kuzulis@> has quit IRC13:12
tgoodwinAh.  Found it.  Does anyone know the reasoning for why SYSROOT_DIRS wouldn't include sysconfdir by default?13:12
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC13:26
rburtontgoodwin: erm, no.  using D in the target is exactly the opposite of what you want13:31
rburtonthat will put a symlink on target to /the/path/to/the/build/paths13:31
tgoodwinkuzulis: ^^13:32
tgoodwinmy mistake13:33
JPEWhmm, populate-volatiles is *slow*.....13:34
tgoodwinI'm off in the weeds trying to figure out why adding my own base-files file to the recipe SYSROOT_DIRS didn't result in it being staged13:34
tgoodwinrburton: for kuzulis' sake, would it be better for him to have created that extra link as relative instead?13:39
CroftonJPEW, a watched build never finishes13:40
*** marka <marka!~masselst@> has joined #yocto13:45
*** abelloni <abelloni!> has joined #yocto13:52
*** comptroller <comptroller!> has quit IRC14:01
*** comptroller <comptroller!> has joined #yocto14:01
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto14:02
*** mrc3 <mrc3!mrc3@linaro/mrc3> has quit IRC14:04
*** mrc3 <mrc3!mrc3@linaro/mrc3> has joined #yocto14:05
*** thaytan <thaytan!> has quit IRC14:06
*** thaytan <thaytan!> has joined #yocto14:06
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:d907:d608:3bce:56e2> has joined #yocto14:09
RPJPEW: that sounds odd and something we should perhaps look at fixing14:11
JPEWRp: Yes, I traced it down: the requirements check (checking that the groups and users exist) against each volatile file is very expensive. When you have a lot of volatiles files and read-only rootfs you pay the penalty every boot.14:14
JPEWI was able to make it 80% faster by concatenating all the volatiles together into a single file14:15
*** Hoolootwo <Hoolootwo!> has quit IRC14:17
*** nighty- <nighty-!> has joined #yocto14:21
*** ntl <ntl!> has joined #yocto14:34
*** Hoolootwo <Hoolootwo!> has joined #yocto14:39
RPJPEW: ah, sounds like a good improvement14:41
* zeddii finally has his plane ticket to Edinburgh 14:47
*** Hoolootwo <Hoolootwo!> has quit IRC14:54
*** kuzulis <kuzulis!~kuzulis@> has joined #yocto14:57
yoctiNew news from stackoverflow: Yocto sumo, meta-virtualization with vmdk <>14:58
kuzulisGuys, why I can't remove 'xinput-calibrator' via my packagegroup-code-x11.bbappend.. It ignores at all.. But RDEPENDS_packagegroup-core-x11-utils_remove_pn-packagegroup-core-x11 = "xinput-calibrator"14:59
kuzulis does work.14:59
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC15:00
kuzulisI have created /recipes-graphics/packagegroups/packagegroup-core-x11.bbappend and add there +RDEPENDS_${PN}_remove = "xinput-calibrator"15:00
RPkuzulis: packagegroup-core-x11-utils != PN15:01
kuzulisand then register my .bbappend as IMAGE_INSTALL += ' packagegroup-core-x11 '15:01
RPand don't do that, you don't register bbappends15:01
kuzulisRP: So, how I can remove "xinput-calibrator" in right way?15:02
*** lusus <lusus!~lusus@> has quit IRC15:03
kuzulisPreviously in this chat I was told that the ..bbappend is a right way to remove the packages..15:03
*** tgoodwin <tgoodwin!> has quit IRC15:04
*** zagor <zagor!~zagor@rockbox/developer/Zagor> has quit IRC15:04
kuzulisRP: What do you mean about " and don't do that, you don't register bbappends" ?15:04
*** edcragg <edcragg!> has quit IRC15:05
*** zagor <zagor!~zagor@rockbox/developer/Zagor> has joined #yocto15:05
*** edcragg <edcragg!> has joined #yocto15:05
*** ant_work <ant_work!> has quit IRC15:05
RPkuzulis: using a bbappend is fine but you don't "register" it like that15:07
RPI don't know what "registering" a bbappend means15:07
RPkuzulis: keep in mind that each recipe has multiple packages, e.g. the packagegroup-core-x11 recipe has packagegroup-core-x11-utils and packagegroup-core-x11 packages15:08
kuzulisRP: Ok. But, how to remove 'xinput-calibrator' ? :)15:09
RPRDEPENDS_packagegroup-core-x11-utils_remove = "xinput-calibrator" in the bbappend?15:11
kuzulisRP: What is name of .bbappend then?15:12
kuzulisRP: packagegroup-core-x11.bbappend?15:12
kuzulisRP: It is magic...15:12
kuzulisRP: for me15:12
kuzulisRP: yocto is a 'blackbox'15:13
*** Hoolootwo <Hoolootwo!> has joined #yocto15:13
RPkuzulis: not entirely, it does have documentation, source code and a lot written about it...15:13
kergothbbappends are applied if your layer is in bblayers and its path is listed in the layer's bbfiles15:13
*** Hoolootwo <Hoolootwo!> has quit IRC15:15
kuzulisRP: I did not found a short/brief wiki how to append/remove required packages... :(15:15
kuzulisthere are a lot of conflicting information..15:16
kuzulisbut, many thanks anyway :)15:16
kuzuliskergoth: My layer is in BBLAYERS, but my .bbappend ignored, until I did'nt  IMAGE_INSTALL += ' packagegroup-foo '15:20
kergothIMAGE_INSTALL is irrelevent15:20
kergoththat controls what packages are installed in your image, not whether a bbappend is applied or not15:21
kuzuliskergoth: Then I has not any idea why .bbappend did not work15:21
kuzuliskergoth: Should bitbake "pick-up" any changes in .bbappend files and etc?15:24
kuzuliskergoth: Or I need to cleanup the build-bla-bla directory before?15:25
kergothyes. again, make sure the layer is in bblayers and the bbappend path matches the pattern listed in bbfiles in conf/layer.conf in your layer. beyond that, use bitbake -e packagegroup-core-x11|grep '^RDEPENDS' to check if the change was applied15:25
kergothno, no need to clean anything when changing recipes or appends15:25
Croftontry bitbake-layers show-appends15:25
Croftonmay need to run help to find exact syntax15:25
kergothyeah, good idea15:25
*** JaMa <JaMa!~martin@> has joined #yocto15:26
kuzulisahh... many thanks :)15:29
khemRP: you have older version of mesa/musl patch staged into master-next15:31
RPkhem: well spotted, the v3 is way way better too!15:32
RPkhem: fixed, thanks (you can blame rburton for it)15:32
rburtonkhem: huh, sorry!15:32
rburtonglad you noticed ,that's my pick script going wrong15:32
RPkhem: looking forward to getting rid of another orange box on the autobuilder :)15:33
*** tgoodwin <tgoodwin!> has joined #yocto15:36
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:43
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto15:44
*** varjag <varjag!> has quit IRC15:48
*** chandana73 <chandana73!~ckalluri@> has quit IRC15:48
*** chandana73 <chandana73!~ckalluri@> has joined #yocto15:48
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:49
*** chandana73 <chandana73!~ckalluri@> has quit IRC15:56
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:d907:d608:3bce:56e2> has left #yocto15:56
*** stephano <stephano!stephano@nat/intel/x-glvlzewbnldxewuj> has quit IRC15:56
kuzulisGuys, how I can remove the packages like 'sudo', 'rsync' and etc from '/packagegroup-self-hosted'? Because  bitbake -e packagegroup-self-hosted | grep '^RDEPENDS' says that nothing provides..15:56
*** AndersD <AndersD!~AndersD@> has joined #yocto15:57
rburtonkuzulis: easy fix: don't install that package group?15:59
kuzulisrburton: I did not install that group :)16:00
kuzulisrburton: How I can ignore this group?16:01
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto16:01
rburtonwell rsync is at meta/recipes-devtools/rsync/rsync_3.1.3.bb16:01
rburtonsudo is meta/recipes-extended/sudo/sudo_1.8.23.bb16:02
rburtonso they do exist16:02
rburtonso i don't see what the problem is16:02
kergothkuzulis: if you aren't installing the package group, what packages it includes is irrelevent16:02
kuzulisrburton: Do you mean a problem to remove them?16:02
rburtonkuzulis: no i mean what *your problem* is16:02
kuzulisrburton: I want to minimize an image16:03
rburtonso why is the content of packagegroup-self-hosted relevant?16:04
kergotha minimal image shouldn't be including self-hosted anyway16:04
kuzulisSo, what I need to do to remove the sudo and rsync from an image? because currently this utilities are present in image16:04
kergothjust create yourself a new image with only what you need installed16:04
rburtonkuzulis: find out where they're being pulled in from, instead of guessing.  it won't be self-hosted.16:05
kergothbitbake -g your-image; oe-depends-dot -w -k sudo recipe-depends.dot16:06
kergothshould do, iirc16:06
*** bezeee <bezeee!> has joined #yocto16:06
rburtonkergoth: need an easy way of getting that data from the pacakge manager16:06
kuzulisWhat is 'oe-depends-dot' ?16:08
rburton$ oe-depends-dot --help16:08
rburtonusage: oe-depends-dot [-h] [-k KEY] [-d] [-w] [-r] dotfile16:08
rburtonAnalyse generated by bitbake -g16:08
kergotha script in oe-core/poky16:08
kuzulisHmm.. in my case I have not this script16:09
kuzulisoe-depends-dot: command not found16:09
kuzulisI got: "miatech-embedded-qt5-x11-image" -> "sudo"16:11
kuzulis"packagegroup-core-x11-base" -> "sudo"16:11
kuzulis"mini-x-session" -> "sudo"16:11
kuzulisSo, hould I remove 'sudo' e.g. from packagegroup-core-x11-base.bbappend ?16:12
kuzulislike RDEPENDS_${PN}_remove = "sudo" ?16:13
rburtonare you building miatech-embedded-qt5-x11-image?16:15
*** fitzsim <fitzsim!> has joined #yocto16:15
kuzulisrburton: Yes16:16
kuzulisBut there are no any 'sudo' mention16:16
kuzulisand nowhere in my layer16:17
kuzulisno any explicitly mention16:17
kergothkuzulis: the info you just pasted indicates it's mini-x-session pulling it in directly16:19
kergoththe .dot shows both direct and indirect dependency16:19
kergothso bbappend mini-x-session16:19
kergotha quick grep shows that indeed, mini-x-session pulls it in16:19
kergoth16:RDEPENDS_${PN} = "sudo"16:19
kergothso either remove sudo there or stop using mini-x-session by removing that from the packagegroup16:20
kergothor better yet ,just create a custom image with exactly waht you want.16:20
kergothas mentioned before16:20
kuzulisok, many thanks for your time16:20
*** kuzulis <kuzulis!~kuzulis@> has quit IRC16:24
*** bezeee <bezeee!> has quit IRC16:29
*** AndersD <AndersD!~AndersD@> has quit IRC16:32
*** bezeee <bezeee!> has joined #yocto16:43
armpitRP, email sent to AB17:07
*** tprrt <tprrt!~tprrt@> has quit IRC17:45
*** tprrt <tprrt!> has joined #yocto18:08
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC18:25
*** mixfix41 <mixfix41!~swr42@unaffiliated/mixfix41> has left #yocto18:26
*** pohly <pohly!> has joined #yocto18:44
tgoodwinIs anyone else using systemd 234? (rocko) I'm having this weird problem where a service is only occasionally showing up in the startup list.  It's setup to come before on an initrd and it's very inconsistent.19:00
tgoodwinThere are usually a series of messages about "found ordering cycle" and then it ends with deleting a job (not mine or on the runs when my service fails to run.19:01
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:04
*** rcw <rcw!~rcw@> has joined #yocto19:07
*** AndersD <AndersD!> has joined #yocto19:12
*** AndersD_ <AndersD_!> has joined #yocto19:14
*** AndersD <AndersD!> has quit IRC19:16
*** chandana73 <chandana73!~ckalluri@> has joined #yocto19:31
*** angelo_ts <angelo_ts!~angelo_ts@mittelab/members/ziongate> has quit IRC19:32
*** angelo_ts <angelo_ts!~angelo_ts@unaffiliated/angelo-ts/x-4633355> has joined #yocto19:32
RParmpit: thanks19:41
*** georgem <georgem!~georgem@> has quit IRC19:43
*** georgem <georgem!~georgem@> has joined #yocto19:44
*** WillMiles <WillMiles!> has joined #yocto19:47
*** marka <marka!~masselst@> has quit IRC19:47
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto19:50
*** AndersD_ <AndersD_!> has quit IRC19:55
*** rcw <rcw!~rcw@> has quit IRC19:56
*** bezeee <bezeee!> has quit IRC20:00
*** tgoodwin <tgoodwin!> has quit IRC20:15
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto20:26
*** JaMa <JaMa!~martin@> has quit IRC20:35
*** adrianbunk <adrianbunk!> has quit IRC21:00
*** pohly <pohly!> has quit IRC21:01
*** Willy-- <Willy--!~william@> has quit IRC21:02
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC21:12
*** rburton <rburton!> has quit IRC21:34
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC21:34
*** WillMiles <WillMiles!> has quit IRC21:41
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC21:45
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto21:57
*** tprrt <tprrt!> has quit IRC22:06
*** rubdos_ <rubdos_!> has quit IRC22:10
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC22:18
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto22:19
*** rubdos_ <rubdos_!> has joined #yocto22:23
*** rubdos_ <rubdos_!> has quit IRC22:34
*** lukma <lukma!> has joined #yocto22:37
lukmaIs it possible to trick the do_fetch and use provided in DL_DIR repository ?22:52
lukmaI've found solution as in :
lukmaBut the solution doesn't seem correct..... :)22:53
*** rubdos_ <rubdos_!> has joined #yocto22:56
*** ntl <ntl!> has quit IRC23:06
kergothyou don't generally need to do that. rather than digging into the internal sturcture of DL_DIR, just do a —runall=fetch with your other path as a premirror, so it'll fetch from the local path into the DL_DIR and create the done stamp appropriately23:20
khemoh so thats what rain looks iike ...23:30
*** nighty- <nighty-!> has quit IRC23:46

Generated by 2.11.0 by Marius Gedminas - find it at!