Wednesday, 2018-01-31

*** stephano <stephano!~stephano@> has quit IRC00:01
*** stephano <stephano!~stephano@> has joined #yocto00:01
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto00:06
*** armpit <armpit!~armpit@2601:202:4000:1184:9532:f483:52ba:8822> has joined #yocto00:07
*** edgar444 <edgar444!uid214381@gateway/web/> has quit IRC00:08
*** martinkelly1 <martinkelly1!> has joined #yocto00:11
*** martinkelly1 <martinkelly1!> has joined #yocto00:13
*** brianm_ <brianm_!b8178784@gateway/web/freenode/ip.> has joined #yocto00:25
*** agust <agust!> has quit IRC00:34
brianm_I have a line like "addtask foo before do_install"00:42
brianm_Is it possible to only run that line depending on the value of "d.getVar('RELEASE')"?00:43
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto00:43
*** sgw <sgw!swold@nat/intel/x-qslqnplswegsuubc> has quit IRC00:50
clsullivbrianm_: a bit messy but in a python block would work I think00:50
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC00:53
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto00:54
*** adelcast <adelcast!> has joined #yocto00:54
*** msvb-mob <msvb-mob!> has quit IRC00:58
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC00:58
*** Willy-- <Willy--!~william@> has joined #yocto01:10
brianm_clsulliv: Couldn't quite figure out the arguments, but I got something similar working: `"if d.getVar('RELEASE'): d.appendVarFlag('do_install', 'depends', ' ${PN}:foo')`01:11
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto01:14
*** batman_ <batman_!95c73efe@gateway/web/freenode/ip.> has joined #yocto01:20
batman_Does eventhandler honor COMPATIBLE_MACHINE?01:21
batman_I have a event handler registered in a recipe which should be run only for specific machine. But, the event handler is getting triggered for any machine01:22
batman_Does anyone know how to make sure my eventhandler does not get triggered for machines outside COMPATIBLE_MACHINES?01:23
*** nighty- <nighty-!> has joined #yocto01:23
*** bemo <bemo!68840555@gateway/web/freenode/ip.> has joined #yocto01:24
*** martinkelly1 <martinkelly1!> has quit IRC01:26
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC01:43
*** stephano <stephano!~stephano@> has quit IRC01:44
*** adelcast <adelcast!> has quit IRC01:46
*** bemo <bemo!68840555@gateway/web/freenode/ip.> has quit IRC01:49
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto01:50
*** bemo <bemo!68840555@gateway/web/freenode/ip.> has joined #yocto01:56
yoctiNew news from stackoverflow: AM3703 based chip not boot <>01:57
*** sgw <sgw!> has joined #yocto02:02
*** sgw <sgw!> has quit IRC02:14
*** batman_ <batman_!95c73efe@gateway/web/freenode/ip.> has quit IRC02:33
*** Willy-- <Willy--!~william@> has quit IRC02:43
*** sgw <sgw!~swold@> has joined #yocto02:45
*** sgw <sgw!~swold@> has quit IRC02:48
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC02:48
*** fitzsim <fitzsim!> has quit IRC03:42
*** bodangly <bodangly!> has joined #yocto03:43
*** dreyna <dreyna!> has quit IRC04:08
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC04:13
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto04:24
*** bodangly_ <bodangly_!bodangly@gateway/vpn/privateinternetaccess/bodangly> has joined #yocto04:43
*** bodangly <bodangly!> has quit IRC04:45
*** dreyna <dreyna!> has joined #yocto04:48
yoctiNew news from stackoverflow: PHP in Yocto using Apache2 <>04:57
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC05:00
*** armpit <armpit!~armpit@2601:202:4000:1184:9532:f483:52ba:8822> has quit IRC05:02
*** bodangly__ <bodangly__!> has joined #yocto05:07
*** bodangly_ <bodangly_!bodangly@gateway/vpn/privateinternetaccess/bodangly> has quit IRC05:10
*** armpit <armpit!~armpit@2601:202:4000:1184:812b:7018:7f36:eb21> has joined #yocto05:15
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto05:28
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC05:38
*** nrossi <nrossi!uid193926@gateway/web/> has joined #yocto06:08
*** bodangly__ <bodangly__!> has quit IRC06:37
*** rajm <rajm!> has quit IRC06:46
*** agust <agust!> has joined #yocto06:59
*** pohly <pohly!> has joined #yocto07:03
*** open-nandra <open-nandra!> has joined #yocto07:06
*** hnje <hnje!~hnje@> has quit IRC07:07
*** hnje <hnje!~hnje@> has joined #yocto07:09
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto07:24
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC07:28
*** frieder <frieder!> has joined #yocto07:31
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:32
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto07:35
*** dv_ <dv_!~dv@> has quit IRC07:37
*** colrack <colrack!~colrack@> has joined #yocto07:40
*** ant_home <ant_home!> has quit IRC07:47
*** dv_ <dv_!> has joined #yocto07:52
*** t0mmy <t0mmy!~tprrt@> has joined #yocto07:55
*** dreyna <dreyna!> has quit IRC07:58
*** fl0v0 <fl0v0!> has joined #yocto07:59
*** Kakounet <Kakounet!> has joined #yocto08:01
*** yann <yann!> has quit IRC08:10
*** Crofton <Crofton!~Crofton@> has joined #yocto08:15
*** Snert <Snert!> has quit IRC08:27
*** Snert <Snert!> has joined #yocto08:28
*** gaurang <gaurang!74c5b80b@gateway/web/freenode/ip.> has joined #yocto08:28
*** rajm <rajm!~robertmar@> has joined #yocto08:32
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto08:33
*** ant_work <ant_work!> has joined #yocto08:36
*** eduardas_m <eduardas_m!~eduardas@> has joined #yocto08:40
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC08:42
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto08:44
*** vdehors_arc <vdehors_arc!> has joined #yocto08:45
*** Bunio_FH <Bunio_FH!> has joined #yocto08:59
*** grma <grma!~gruberm@> has joined #yocto09:01
*** msvb-mob <msvb-mob!> has joined #yocto09:03
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto09:09
*** gaurang <gaurang!74c5b80b@gateway/web/freenode/ip.> has quit IRC09:10
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC09:10
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto09:12
*** yann <yann!~yann@> has joined #yocto09:12
*** Crofton <Crofton!~Crofton@> has quit IRC09:12
*** Crofton <Crofton!~Crofton@> has joined #yocto09:16
*** adelcast <adelcast!> has joined #yocto09:16
*** mdnneo <mdnneo!~umaucher@> has joined #yocto09:19
*** jomag <jomag!> has joined #yocto09:20
*** joshuagl <joshuagl!joshuagl@nat/intel/x-mhmvnfydpcusqpkn> has joined #yocto09:25
*** OpenSorc_ <OpenSorc_!~opensorce@> has joined #yocto09:39
*** t0mmy <t0mmy!~tprrt@> has quit IRC09:40
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC09:40
*** t0mmy <t0mmy!~tprrt@> has joined #yocto09:41
*** OpenSorc_ is now known as OpenSorceress09:43
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto09:43
*** vdehors_arc <vdehors_arc!> has quit IRC09:46
*** vdehors_arc <vdehors_arc!> has joined #yocto09:46
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC09:47
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto09:48
*** kaspter <kaspter!~Instantbi@> has quit IRC09:57
*** rburton <rburton!> has joined #yocto10:01
*** lazyape <lazyape!> has quit IRC10:11
*** lazyape_home <lazyape_home!> has joined #yocto10:11
*** Crofton <Crofton!~Crofton@> has quit IRC10:17
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC10:23
*** adelcast <adelcast!~adelcast@> has joined #yocto10:23
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto10:26
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC10:27
*** behanw <behanw!uid110099@gateway/web/> has quit IRC10:32
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto10:48
*** kaspter <kaspter!~Instantbi@> has joined #yocto10:52
*** kaspter <kaspter!~Instantbi@> has quit IRC10:57
*** kaspter <kaspter!~Instantbi@> has joined #yocto10:58
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC11:26
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto11:30
eduardas_mhello, is there any guide or recommendtations of what tools to use and what packages to include for proper power management (sleep, suspend-to-RAM, automated shutdown, automated wakeup from sleep) for an embedded Linux system?11:34
eduardas_mso that I may avoid some kind of handcrafted scripts that do stuff with sysfs11:35
*** nighty- <nighty-!> has quit IRC11:37
*** Martian <Martian!~martian@> has joined #yocto11:37
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto11:44
rburtoneduardas_m: you really want to clarify what hardware you're talking about11:45
*** Snert <Snert!> has quit IRC11:46
eduardas_mrburton: i.MX6 Quad, now doing a prototype on the Variscite DART-MX6 SoM11:46
*** Snert <Snert!> has joined #yocto11:46
eduardas_mrburton: handheld device with screen11:47
eduardas_mso the screen backlight is a major power draw of course11:48
eduardas_mso I should disable the screen and its backlight after some time and make the device go to sleep11:50
eduardas_mI am not sure whether this should be handled by systemd somehow or some other component should be used11:51
*** OpenSorc_ <OpenSorc_!~opensorce@> has joined #yocto11:51
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC11:51
rburtonX can handle screen for you, assuming you're using that11:52
eduardas_mrburton: I am not using X11 and am not going to... decided to go with a single Qt application with eglfs backend11:54
eduardas_mso there has to be some other way11:54
eduardas_mQt with eglfs is what my SoM vendor recommended11:55
rburtonsimple enough to monitor activity and sleep in your app11:55
rburtonpresumably qt exposes an idle timer11:55
rburtonX has an idle alarm, you tell it you want to be told after N seconds of idle, and you get a message11:56
rburtonconsidering qt is a platform to itself, presumably it has something similar11:56
eduardas_mrburton: never considered the possibility of qt having a solution for that, honestly11:58
rburtonnever used it, no idea.12:00
eduardas_mrburton: what really sounds complicated to achieve is something like the following: going into suspend to RAM for a while and if no wakeup is performed via GPIO, then the device should do an actual poweroff12:02
eduardas_mI actually have a request for this kind of feature12:02
*** msvb-mob <msvb-mob!> has quit IRC12:04
eduardas_mI am not sure whether an automatic wakeup from suspend to RAM can be done after a while because I expect an actual poweroff to only be achievable from normal state12:04
rburtonthe kernel can arrange most of that cant it?12:06
eduardas_mthen again, when I think about that kind of feature, perhaps that's entirely hardware platform - specific12:06
eduardas_mrburton: I am not aware of what can actually do an automated wakeup from Suspend-to-RAM via a specified time12:07
*** msvb-mob <msvb-mob!> has joined #yocto12:09
rburton is literally what you want12:15
*** OpenSorc_ <OpenSorc_!~opensorce@> has quit IRC12:22
eduardas_mrburton: thank you, I was not aware of that... will try to implement something similar then12:23
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto12:24
*** fray <fray!> has quit IRC12:39
*** fray <fray!> has joined #yocto12:41
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC12:51
*** linus_ <linus_!> has joined #yocto12:52
*** rburton <rburton!> has quit IRC13:02
*** rburton <rburton!> has joined #yocto13:03
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC13:03
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto13:09
*** OpenSorceress <OpenSorceress!~opensorce@> has joined #yocto13:22
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto13:22
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC13:51
*** marka <marka!~masselst@> has joined #yocto14:00
*** nighty- <nighty-!> has joined #yocto14:01
*** stephano <stephano!~stephano@> has joined #yocto14:03
*** mdnneo <mdnneo!~umaucher@> has quit IRC14:07
*** Crofton <Crofton!> has joined #yocto14:12
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto14:12
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto14:13
*** mdnneo <mdnneo!~umaucher@> has joined #yocto14:13
*** rajm <rajm!~robertmar@> has quit IRC14:26
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC14:31
*** behanw <behanw!uid110099@gateway/web/> has joined #yocto14:38
*** Crofton <Crofton!> has quit IRC14:40
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC14:41
*** luneff <luneff!~yury@> has joined #yocto14:43
*** adelcast <adelcast!~adelcast@> has quit IRC14:44
*** OpenSorceress <OpenSorceress!~opensorce@> has joined #yocto14:49
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto14:49
*** andrey_ <andrey_!> has joined #yocto14:50
*** jomag <jomag!> has quit IRC14:51
andrey_hi, folks! Can i add new recipe with newer package version to another layer? I need to update some packets without touching a layer with this packets. Is it possible?14:52
*** Crofton <Crofton!> has joined #yocto14:52
andrey_i thought it works like that: bitbake scans all layers and get newer recipe (by version). But it seems like i was wrong14:53
*** linus_ <linus_!> has left #yocto14:54
LetoThe2ndandrey_: it does, unless something explicitly selects an older version14:54
andrey_i had placed recipe with newer version in my layer, but i got my recipe SKIPPED. I even tried to use PREFERRED_VERSION, but bitbake even doesn't see my recipe. So, it just uses older version of package.14:56
LetoThe2ndandrey_: and you are sure that the name etc. matches exactly?14:56
andrey_LetoThe2nd: yep. i am.14:57
LetoThe2ndandrey_: and the layer is functional? e.g., another recipe in the same directory works?14:57
andrey_i have custom linux kernel in my layer and it does work14:58
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:59
andrey_i mean kernel recipe14:59
yoctiNew news from stackoverflow: Jenkins job hangs after big build <>14:59
*** ferruh <ferruh!~Thunderbi@> has joined #yocto15:01
rburtonandrey_: layers with higher priority win, so you probably are hitting that.  note that meta-oe has an oddly high priority.15:01
LetoThe2ndok, and which package you are trying tooverride?15:01
LetoThe2ndrburton: good point.15:01
rburtonandrey_: preferred version will still work though15:01
rburtonso maybe your layer.conf is broken15:01
rburton"bitbake-layers show-overlayed" should list both the version you don't want and the version you added15:02
rburtonif it doesn't then your layer/recipe is the problem15:02
andrey_preferred version doesn't work. I got warning like: NOTE: preferred version 4.7.0 of samba not available (for item samba-dsdb-modules)15:03
andrey_NOTE: versions of samba available: 4.6.715:03
rburtonright so it can't see your recipe15:03
rburtonso either your recipe or your layer is broken15:03
andrey_yes, i think it is a layer.conf problem15:04
rburtonthe usual problem is that BBFILES in layer.conf doesn't actually match where you put the recipe15:04
andrey_i got it. But i think there is another problem. Please, look at my local.conf:15:06
*** hnje <hnje!~hnje@> has quit IRC15:06
andrey_oh, ignore extra line numbers. it just because i copied it from vim15:07
*** hnje <hnje!~hnje@> has joined #yocto15:08
andrey_my recipe is here: LAYERNAME/recipes-connectivity/samba15:08
andrey_even more, i can use 'bitbake-layers show-recipes' to see my recipe with SKIPPED status15:10
andrey_i am out of ideas15:10
*** hnje <hnje!~hnje@> has quit IRC15:14
*** AndroUser <AndroUser!~androirc@> has joined #yocto15:14
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC15:20
*** rajm <rajm!~robertmar@> has joined #yocto15:21
*** kaspter <kaspter!~Instantbi@> has quit IRC15:23
*** kaspter <kaspter!~Instantbi@> has joined #yocto15:24
*** crawf0rd <crawf0rd!> has quit IRC15:24
*** crawf0rd <crawf0rd!> has joined #yocto15:25
*** Martian <Martian!~martian@> has quit IRC15:25
*** sgw <sgw!~swold@> has joined #yocto15:25
*** sgw <sgw!~swold@> has left #yocto15:25
*** sgw <sgw!~swold@> has joined #yocto15:26
*** rcw <rcw!~rwoolley@> has joined #yocto15:29
*** andrey_ <andrey_!> has quit IRC15:29
*** adelcast <adelcast!> has joined #yocto15:33
*** stephano <stephano!~stephano@> has quit IRC15:33
*** noway96 <noway96!> has joined #yocto15:33
*** zarzar <zarzar!> has joined #yocto15:34
*** majuk_ <majuk_!> has joined #yocto15:35
*** majuk <majuk!> has quit IRC15:35
*** WillMiles <WillMiles!> has joined #yocto15:36
*** luneff <luneff!~yury@> has quit IRC15:41
*** majuk_ is now known as majuk15:45
*** majuk <majuk!> has quit IRC15:50
*** majuk <majuk!> has joined #yocto15:50
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC15:50
*** morphis__ <morphis__!> has joined #yocto15:51
sveinseIs there any way to override a IMAGE_FEATURES_remove="package-management" in a .bbappend or a included recipe where the remove statement is present?15:52
kanavinsveinse: write a new image recipe, and set image features as you please15:53
kanavinsveinse: or fix the original file15:54
sveinsekanavin: ok. not what I hoped for. I just need a development image based on the production image that have some extra features, such as package-management15:54
*** morphis_ <morphis_!> has quit IRC15:54
kergothnope, can't undo a _remove yet, which is why you need to be careful when it's used15:55
kergothor use an intermediate varaible15:55
kanavinsveinse: you simply need to rearrange the files that define the images: has the _remove, and everything else goes to .inc15:55
kergothi.e. BAR_REMOVE = "blah"; BAR_remove = "${BAR_REMOVE}"15:55
kanavinsveinse: that .inc is also included by image-development.bb15:55
kergothyeah, that'd be one option15:55
sveinseand the production image is also layered on top of a system image, which uses package-management, hence the _remove15:55
kergothi have a prototype somewhere that uses bbclassextend to implement image variants that you might find interesting15:56
kanavinsveinse: don't base the development image on top of production image simply :)15:56
kergothie.. it adds prod and dev variants of every image15:56
sveinsekanavin: why?15:56
sveinsea dev image = a production image + a few extra packages. Otherwise same deployment15:57
kanavinsveinse: + different image features15:57
kanavinsveinse: so just put the common bits into .inc, and derive various images from that15:58
rburtonsveinse: copy/paste the system image instead of layering it15:58
rburtonthis obsession with layering images is crazy imho15:58
kergothit is strange how reluctant folks are to create their own images15:59
rburtonespecially when system image is making policy decisions you want to control15:59
sveinserburton: Yeah, I know you'd say that, but it isn't that easy in pratice. Especially when we have a vendor that is responsible for the low-level system, so we must build on top of theirs15:59
kergothi was thinking the other day it'd be nice to append to the conf-notes, so new layers could list their images without having to set TEMPLATECONF15:59
sveinseWe only want to focus on the application, not the system. But we make the image, since we layer a few things on top of it16:00
rburtonsveinse: copy/paste *and* moan at them to make them produce packagegroups so their images are just pulling a few packagegroups together16:00
*** adelcast <adelcast!> has quit IRC16:00
rburtoni have literally no idea why their image is doing IMAGE_FEATURES_remove16:00
*** xtron <xtron!~xtron@> has left #yocto16:00
rburtonthat doesn't solve anything, just causes problems16:00
sveinseThe layering is what sold us to Yocto in the first place, so I'm not that surprised that this is something that people are confused about16:00
rburtonsveinse: basically you're describing to us why their image is broken... tell them, not us. :)  they're *forcing* users of the image to not have package mangement, even if they wanted to use it.16:02
sveinsecopy/paste implies having multiple copies of essentially the same code. .inc is probably the way to go here16:02
rburtonsveinse: sure copy/paste the sane bits into an inc, or copy/paste to a base image that actually works16:03
rburtonif dev image is prod image + package-management + dev-pkgs, then that's just an include and IMAGE_FEATURES+= away from working16:03
sveinserburton: Well, being the responsible for our yocto layer, I'm also having a hard time understanding what should go where. E.g. how to make a sensible separation between machine and distro and images16:03
*** AndroUser <AndroUser!~androirc@> has quit IRC16:04
*** crawf0rd <crawf0rd!> has left #yocto16:04
sveinseso I'm often left with making the most naïve apporach, yet the wrong one :(16:04
sveinseso pardon me for sounding insistive, I'm trying as best I can16:05
kergoth not 100%, needs work, and you can ignore the user features bits, but it's a start16:05
kergothsveinse: it sounds like you just need to talk your vnedor into making a sane image :)16:05
kergothbeyond that, copy it16:05
*** LocutusOfBorg <LocutusOfBorg!LocutusOfB@ubuntu/member/locutusofborg> has quit IRC16:05
*** LocutusOfBorg <LocutusOfBorg!LocutusOfB@gateway/shell/panicbnc/x-cqzwpyegponzxrqr> has joined #yocto16:05
kergothtechnically it's possible to undo a _remove, but only through poking into bitbake internals, and I won't tell you how to do it, since it's evil16:06
sveinsekergoth: do be honest, I don't think they know either. They're a HW vendor. It's not like their upstream SoC images are any better with that respect either16:06
rburtonthe haha was actually to kergoth  but it works as a response to sveinse  too16:06
kergothhey there it is, - never did do anything with it, was just to see if it'd work16:07
*** stephano <stephano!~stephano@> has joined #yocto16:13
sveinseThere is one thing I'm curious about: Yocto encourages having separate meta and software? Why is that? What about use cases where the meta and the software is developed together? Ala. so-called native packages in Debian16:13
*** kaspter <kaspter!~Instantbi@> has quit IRC16:15
rburtonsveinse: then put the sources in the layer, if you want.  some examples of that in oe-core...16:16
*** kaspter <kaspter!~Instantbi@> has joined #yocto16:16
*** adelcast <adelcast!~adelcast@> has joined #yocto16:16
kergothI've also put the recipe for a project inside its local source tree before, and then managed fetching it outside of bitbake, the way i fetch layers. didn't do much with it, ended up being more trouble than it was worth, but it's possible.. the issue is bitbake can't fetch and then parse after the fetch, so bitbake can't fetch/unpack/patch the sources in that case16:17
*** mdnneo <mdnneo!~umaucher@> has quit IRC16:19
sveinsewe have a mono-repo for the project, which contains various software packages for various recipes. I started out having a separate meta layer for yocto, but it soon died, as I was difficult for the devs to keep this updated with the main code repo. And that the repo was used by multiple recipes created a lot of parallel checkouts16:21
kergoththere are advantages and disadvantages to having the metadata out of band16:22
kergothtradeoffs either way16:22
sveinseSo I have ended up with a construct like this:
sveinseBut some hacks were required, such as having to set SP_BASEDIR := "${LAYERDIR}/.." since the layerdir is surprisingly not available in recipes16:26
sveinsewhat is the difference from including an .inc vs using a .bbclass?16:28
rburtonclasses can do a lot more, but if an inc is enough...16:29
kergothbbclass implicitly assumes classes/<classname>.bbclass, supports EXPORT_FUNCTIONS to implement basic inheritence, etc16:29
kergothdepends on the requirements16:29
rburtonfriends don't tell friends about EXPORT_FUNCTIONS16:29
sveinseheh, I was about to say that I'm probably completely failing in Yocto 101. EXPORT_FUNCTION? Never used it on bbclass...16:31
kergothhaha. it made sense when we wrote it, but given inheritence is almost always flat, rather than nested, it's cleaner to just write custom functions and call them as needed, i.e. oe_runmake, rather than calling the base function, i.e. base_do_compile, particularly since we don't generally pass along arguments with it16:31
*** frieder <frieder!> has quit IRC16:31
*** grma <grma!~gruberm@> has quit IRC16:31
sveinseso some kind of declaration scheme then?16:31
rburtonkergoth: yeah i'm 99% sure early bitbake design was done in a pub16:32
sveinselol :D16:32
rburtonbut considering its age its done surprisingly well :)16:32
kergothit was just a way to rename a function and automatically create a wrapper, i.e. it'd create <yourclass>_<task> and define <task> to run <yourclass>_<task>, making it easier to overwrite <task> and still be able to call the original function16:32
kergothbut we have _prepend/_append, so 90% of the time it's unneeded, and the rest of the time we want to pass arguments, so..16:32
sveinsethe defacto rules to everything makes yocto and bitbake hard thou16:33
kergothbut i.e. you could do do_configure () { some_stuff; base_do_configure; some_other_stuff; } if base.bbclass did EXPORT_FUNCTIONS do_configure16:33
kergothwell, we prioritize flexibility, which has allowed for a lot of the features that made the project what it is today, but the downside is there are lots of ways of doing things16:33
kergothit's like the python vs perl philosophy, one way to do it or multiple ways to do it16:34
kergothmore tradeoffs16:34
sveinseyup, and some deliberate scope limitations. Such as that there is no CM responsibility in yocto, putting this over to the users.16:35
*** learningc <learningc!~User@> has quit IRC16:36
sveinseThere is nothing wrong with that, but it does create a spread of solutions across seemingly similar systems16:36
kergothyeah, not providing an official way to manage/fetch the layers / repositories was a bit of a mistake, i think.. upside is not every tool for managing such things meets all needs, but downside is it leads to confusion and inconsistency amongst the userbase in that regard16:36
kanavinsveinse: if you propose an official CM solution, we'll gladly take it16:37
kanavinsveinse: it's not a deliberate scope limitation, it's more of a 'only 24 hours in a day' situation16:37
*** rajm <rajm!~robertmar@> has quit IRC16:40
sveinsekanavin: yeah, *that* I do understand. Well, we do have built our own custom CM on top of Yocto. We build the same image for three machines, which in turn is aggregated into a common installer image. The latter has been somewhat a challenge, since it crosesses MACHINES (and before multiconfig)16:40
*** vdehors_arc <vdehors_arc!> has quit IRC16:41
sveinseWould it be interesting with a showdown of how it works? The flow from setting up the CM to getting the artifacts?16:41
kanavinsveinse: on the openembedded-architecture list, certainly16:42
*** eduardas_m <eduardas_m!~eduardas@> has quit IRC16:42
*** ant_work <ant_work!> has quit IRC16:42
sveinsekanavin: sure, thanks.16:43
*** gtristan_ <gtristan_!~tristanva@> has joined #yocto16:43
*** dreyna <dreyna!> has joined #yocto16:49
sveinserburton: With regards to package groups: It's not always easy: Use packagegroups, yeah? Remember the other chat the other day about not using packagegroup-base-ext2 because of it's age? Not easy being in the other end knowing what to use and what not to :D ;)16:53
*** vdehors_arc <vdehors_arc!> has joined #yocto16:54
*** peacememories <peacememories!> has joined #yocto16:55
sveinseThanks guys. I find these discussions interesting and educational16:58
*** fl0v0 <fl0v0!> has quit IRC17:04
sveinsekergoth: What is the difference between using += and _append? E.g. I see a *lot* of ROOTFS_POSTPROCESS_COMMAND_append and IMAGE_INSTALL_append_machine rather than using += ? Why is that? Bad pratice by everyone involved?17:05
kergoth+=/=+ and .=/=. are immediate, _append and _prepend are lazy17:05
kergothif a local.conf uses += on something that isn't defined until later, either that value will be overridden, or if the recipe uses ?=, it'll override that instead17:06
kergoth_append_machine is also the only way to conditionally append based on an override, +=/.=/=+/=. don't provide a conditional operation17:06
kergothbest practice is to use immediate operations wherever possible, and use the others only when necessary17:07
kergothsee also the bitbake user manual, which covers the file format17:07
sveinsekergoth: thanks. I think that has to be the most misused best pratice then :D17:08
kergothpeople like to copy and paste without understanding what it is or why they need it17:09
sveinsetell me about it. copy pasting is the only way I can really learn what I need to have to make it work, yet it not setting a good example evidently17:10
*** peacememories <peacememories!> has quit IRC17:10
*** Bunio_FH <Bunio_FH!> has quit IRC17:10
*** peacememories <peacememories!> has joined #yocto17:11
-YoctoAutoBuilder- build #821 of nightly is complete: Failure [failed] Build details are at
RPkergoth: not to be confused with immediate expansion which you should ideally never use :)17:11
kergothnothing wrong with copying stuff, especially if it's good stuff, but it's best to understand what it is17:12
sveinseRP: I use it... To set SP_BASEDIR := "${LAYERDIR}/.."17:13
kergoththat's not needed, if it's in layer.conf17:13
kergothLAYERDIR is specially handled17:13
sveinsenot in recipes17:13
kergothbitbake expands LAYERDIR after layer.conf is parsed17:13
kergothso := is redundant17:13
sveinseright. Second is this construct BASEVERSION := "${@read_baseversion(d)}" to avoid calling this function every time this variable is used17:15
kergothdealing with external files is one of the rare cases that := can be useful, but it's important to realize using := there doesn't mean it'll only be run once, depending on where it's defined17:15
sveinsekergoth: no it does not. I think it's run 3 or 4 times during a build IIRC17:16
kergothi.e. recipe files are re-parsed when the task is run, so it's actually run for each task, if it's defined in the recipe17:16
* kergoth nods17:16
kergothcan be confusing if someone adds a warning to such a function without knowing that :)17:16
RPsveinse: I didn't say never use it, I said ideally never :)17:16
RPsveinse: sadly the world isn't ideal17:17
sveinseYeah, true17:17
RPsveinse: there are some places we have to use it for various reasons but I do think we should try and minimise them and you don't see many uses in OE-Core17:17
sveinseI wanted to show to see if there are some defacto methods here too :D17:17
*** gtristan_ <gtristan_!~tristanva@> has quit IRC17:18
kergoth:= for that reason can be a case of premature optimization, depending on how often it's actually expanded17:19
kergothcan be a good thing to actually test17:19
sveinsegrepping my recipies I found FILESEXTRAPATHS_prepend := "${R}:". Probably those under the written-on-a-bar category by yours truly :P17:20
*** peacememories <peacememories!> has quit IRC17:23
kergothFILESEXTRAPATHS is a case where it's needed, as FILE/FILE_DIRNAME/THISDIR is defined based on the current file being parsed17:24
kergothif you dont' use :=, that'll be the path to the recipe rather than the bbappend17:24
sveinseWe have a central service generating corporate-wide build IDs. I quickly learned that plugging this into yocto was surpisingly hard. Either because it ran multiple times or that it was cached and just ran once.17:25
*** peacememories <peacememories!> has joined #yocto17:25
sveinseThis is how I learned that := is run multiple times :D17:25
RPsveinse: you do have to be careful how you wire in something like that17:25
kergothsometimes youer' better off doing that outside of bitbake,b efore the build stars, or with an event handler17:26
kergothcase by case17:26
sveinseSo I build the system for that outside of bitbake. We are also building multiple MACHINES (which yocto didn't support at the time)17:26
RPsveinse: BuildStarted events are usually good although even there you can get one event per multiconfig17:26
sveinseBut with the unfortunate effect that the layer on top of yocto gets thicker17:27
*** vdehors_arc <vdehors_arc!> has quit IRC17:28
* sveinse has started on a document "Things I've learned about Yocto and bitbake"17:30
sveinseAre there any syntatical rules to version numbers in OE? I counldn't find any about it in the manuals17:32
sveinseAny character class rules?17:32
*** yann <yann!~yann@> has quit IRC17:37
sveinseOne example of confusion from the bitbake manual: "An advantage of the override style operations "_append", "_prepend", and "_remove" as compared to the "+=" and "=+" operators is that the override style operators provide guaranteed operations."17:43
sveinseThe sveinse short interpretation of that is: "Use _append, _prepend and _remove" :P17:43
sveinseNot a word about why one should avoid or limit the use of them17:44
-YoctoAutoBuilder- build #757 of nightly-musl is complete: Failure [failed Running Sanity Tests] Build details are at
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC17:47
*** t0mmy <t0mmy!~tprrt@> has quit IRC17:53
*** rcw <rcw!~rwoolley@> has quit IRC17:55
*** rcw <rcw!~rwoolley@> has joined #yocto17:56
*** peacememories <peacememories!> has quit IRC17:59
yoctiNew news from stackoverflow: Disable Mender in Yocto Rocko for Beaglebone Black Install <>18:00
*** rcw <rcw!~rwoolley@> has quit IRC18:00
*** rcw <rcw!~rwoolley@> has joined #yocto18:01
*** Kakounet <Kakounet!> has quit IRC18:01
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto18:01
*** martinkelly1 <martinkelly1!> has joined #yocto18:04
*** peacememories <peacememories!> has joined #yocto18:08
*** peacememories <peacememories!> has quit IRC18:10
*** peacememories <peacememories!> has joined #yocto18:11
*** morphis__ <morphis__!> has quit IRC18:18
*** adelcast <adelcast!~adelcast@> has quit IRC18:28
*** aratiu1 <aratiu1!~adi@> has joined #yocto18:29
*** aratiu <aratiu!~adi@> has quit IRC18:30
rburtonsveinse: sharing that would be interesting!18:34
rburtonsveinse: there's a regex buried for versions but basically its rpm's rule (as they're stricter than dpkg).  or was it the other way around...18:35
*** wto <wto!> has quit IRC18:42
*** aratiu1 <aratiu1!~adi@> has quit IRC18:42
*** aratiu <aratiu!~adi@> has joined #yocto18:47
-YoctoAutoBuilder- build #745 of nightly-qa-extras is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Running Sanity Tests_1 BuildImages_2 BuildImages_3 BuildImages_4 BuildImages_5 BuildImages_6 BuildImages_7 BuildImages_8 BuildImages_9 Running Sanity Tests_2 BuildImages_10 Running Sanity Tests_3 BuildImages_11 Running Sanity Tests_4 BuildImages_12 Running Sanity Tests_5 BuildImages_13 Running Sanity Tests_6 BuildImages_14 Running Sanity Test18:48
*** aratiu <aratiu!~adi@> has quit IRC18:49
*** aratiu <aratiu!~adi@> has joined #yocto18:50
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC18:54
*** peacememories <peacememories!> has quit IRC18:56
*** peacememories <peacememories!> has joined #yocto19:00
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto19:01
*** sr105 <sr105!~sr105@> has quit IRC19:02
*** yann <yann!> has joined #yocto19:03
*** sr105 <sr105!~sr105@> has joined #yocto19:04
aehs29rburton: if youre still around, the ninja update applied cleanly on top of master to me19:05
aehs29rburton: did you want me to rebase it on master-next or something?19:05
aehs29rburton: I just saw the patchtest email but this isnt making any sense to me19:08
*** colrack <colrack!~colrack@> has quit IRC19:09
*** adelcast <adelcast!> has joined #yocto19:10
*** dreyna <dreyna!> has quit IRC19:23
*** peacememories <peacememories!> has quit IRC19:44
*** peacememories <peacememories!> has joined #yocto19:44
*** vmeson <vmeson!> has quit IRC19:53
*** vmesons <vmesons!> has joined #yocto19:53
*** khem <khem!~khem@unaffiliated/khem> has quit IRC19:55
*** adelcast <adelcast!> has quit IRC19:58
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto19:59
*** vmesons <vmesons!> has quit IRC20:01
-YoctoAutoBuilder- build #743 of nightly-no-x11 is complete: Failure [failed BuildImages] Build details are at
*** vmeson <vmeson!> has joined #yocto20:04
*** ferruh <ferruh!~Thunderbi@> has quit IRC20:10
*** adelcast <adelcast!~adelcast@> has joined #yocto20:13
*** dreyna <dreyna!> has joined #yocto20:18
*** Snert__ <Snert__!> has joined #yocto20:23
*** Snert <Snert!> has quit IRC20:26
*** Crofton <Crofton!> has quit IRC20:32
kergothoof, meta-ti, meta-fsl-ppc, and meta-oe all need to catch up on not using base_conditional20:36
kergothdidn't realize it was removed20:36
*** peacememories <peacememories!> has quit IRC20:36
zarzarhow do i open the manuals? tried opening mega-manual.xml but there is an error in the file, COPYRIGHTYEAR missing or something20:36
kergothmeta-selinux was broken by the removal of oe_filter_out too20:37
kergothzarzar: do you not want to read it in your browser, or are you trying to modify the docs?20:37
zarzarread in browser20:37
kergothall the docs are available at yoctoproject.org20:38
*** ant_home <ant_home!> has joined #yocto20:58
*** rcwoolley_ <rcwoolley_!~rwoolley@> has joined #yocto21:01
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC21:02
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto21:02
*** adelcast <adelcast!~adelcast@> has quit IRC21:03
-YoctoAutoBuilder- build #721 of nightly-arm64 is complete: Failure [failed BuildImages Running Sanity Tests Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 BuildImages_1 Running ESDK Sanity Tests] Build details are at
*** rcw <rcw!~rwoolley@> has quit IRC21:04
*** wto <wto!> has joined #yocto21:08
-YoctoAutoBuilder- build #822 of nightly is complete: Success [build successful] Build details are at
*** nrossi <nrossi!uid193926@gateway/web/> has quit IRC21:17
*** joshuagl <joshuagl!joshuagl@nat/intel/x-mhmvnfydpcusqpkn> has quit IRC21:18
-YoctoAutoBuilder- build #214 of nightly-musl-x86-64 is complete: Failure [failed BuildImages] Build details are at
*** bemo_ <bemo_!68840555@gateway/web/freenode/ip.> has joined #yocto21:25
*** bemo <bemo!68840555@gateway/web/freenode/ip.> has left #yocto21:25
*** pohly <pohly!> has quit IRC21:25
*** bemo_ is now known as bemo21:26
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC21:29
*** martinkelly1 <martinkelly1!> has quit IRC21:30
*** martinkelly1 <martinkelly1!> has joined #yocto21:31
-YoctoAutoBuilder- build #729 of nightly-world-lsb is complete: Failure [failed BuildImages] Build details are at
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto21:41
*** lazyape_home <lazyape_home!> has quit IRC21:42
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC21:49
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto21:52
*** rcwoolley_ <rcwoolley_!~rwoolley@> has quit IRC21:55
*** dave0x6d <dave0x6d!uid190567@gateway/web/> has quit IRC21:55
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC22:02
*** zarzar <zarzar!> has quit IRC22:04
*** zarzar <zarzar!> has joined #yocto22:04
*** dave0x6d <dave0x6d!uid190567@gateway/web/> has joined #yocto22:07
*** zarzar <zarzar!> has quit IRC22:09
*** WillMiles <WillMiles!> has quit IRC22:17
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto22:44
*** agust <agust!> has quit IRC22:50
*** Flow86 <Flow86!> has quit IRC23:01
*** Flow86 <Flow86!> has joined #yocto23:03
*** Willy-- <Willy--!~william@> has joined #yocto23:03
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:08
-YoctoAutoBuilder- build #730 of nightly-world is complete: Failure [failed BuildImages] Build details are at
*** noway96 <noway96!> has quit IRC23:20
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto23:23
*** martinkelly1 <martinkelly1!> has quit IRC23:28
*** martinkelly1 <martinkelly1!> has joined #yocto23:29
*** iSaul <iSaul!> has quit IRC23:29
*** brianm_ <brianm_!b8178784@gateway/web/freenode/ip.> has quit IRC23:32
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:40
*** marka <marka!~masselst@> has quit IRC23:40
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto23:51
*** iSaul <iSaul!> has joined #yocto23:51
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto23:51
*** nathani_ <nathani_!> has quit IRC23:53
*** nathani_ <nathani_!> has joined #yocto23:56
-YoctoAutoBuilder- build #823 of nightly is complete: Failure [failed CheckYoctoCompat BuildImages] Build details are at
*** iSaul <iSaul!> has quit IRC23:58

Generated by 2.11.0 by Marius Gedminas - find it at!