Thursday, 2016-09-15

*** Jefro <Jefro!> has joined #yocto00:03
*** manuel_ <manuel_!> has quit IRC00:07
*** manuel_ <manuel_!> has joined #yocto00:09
*** smferris <smferris!~smferris@> has quit IRC00:10
*** HyP3r <HyP3r!> has quit IRC00:11
*** seebs <seebs!~seebs@2601:196:4901:ec80:f1d1:b4ad:12e2:4c03> has joined #yocto00:18
*** smferris <smferris!~smferris@> has joined #yocto00:21
*** bbarr <bbarr!~bbarr@> has quit IRC00:23
*** tripzero <tripzero!~tripzero@> has quit IRC00:26
*** tripzero <tripzero!~tripzero@> has joined #yocto00:27
*** dreyna <dreyna!> has quit IRC00:36
*** dreyna <dreyna!> has joined #yocto00:37
*** manuel_ <manuel_!> has quit IRC00:41
*** dreyna <dreyna!> has quit IRC00:50
*** manuel_ <manuel_!> has joined #yocto00:50
*** Jefro <Jefro!> has quit IRC01:09
*** manuel_ <manuel_!> has quit IRC01:10
*** t0mmy <t0mmy!> has joined #yocto01:12
*** morphis__ <morphis__!> has joined #yocto01:14
*** manuel_ <manuel_!> has joined #yocto01:16
-YoctoAutoBuilder- build #946 of nightly-multilib is complete: Failure [failed BuildImages_5 Running Sanity Tests_4 BuildImages_6 Running SDK Sanity Tests] Build details are at
*** morphis_ <morphis_!> has quit IRC01:18
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto01:22
*** fenrig_ <fenrig_!5ee32de5@gateway/web/freenode/ip.> has joined #yocto01:26
fenrig_Hi, how do i enable systemd services to run at boot from within yocto01:26
fenrig_and how do I add journalctl to the image?01:26
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC01:27
bluelightningthat's of course assuming you have already switched over from sysvinit to systemd01:31
fenrig_how do I do this from the file01:32
bluelightningyou cannot01:32
fenrig_yeah i switched to systemd already01:32
bluelightningit must be done at the configuration level or in the recipe installing the service01:32
fenrig_though I am missing systemctl and journalctl from my image01:33
bluelightningthe default is to enable the service though so if you find one that's not enabled either the recipe is disabling it or something is broken01:33
fenrig_i probably should grep for it then01:36
bluelightningit sounds a bit odd that systemctl and journalctl aren't there01:38
fenrig_its odd01:38
fenrig_but i have some messages from systemd-udevd01:39
fenrig_and I have systemd files in my sysroot01:39
bluelightningthat doesn't mean much, since that's a separate program01:39
bluelightningI suspect you're still running sysvinit in the image01:40
fenrig_I did had to switch01:40
fenrig_I did this in the local.conf01:40
*** manuel_ <manuel_!> has quit IRC01:40
bluelightningwhat exactly did you put in there?01:41
fenrig_VIRTUAL_RUNTIME_init_manager = "systemd"01:41
fenrig_DISTRO_FEATURES = "ext2 opengl usbhost ${DISTRO_FEATURES_LIBC} pulseaudio systemd"01:41
fenrig_this is the correct way?01:42
fenrig_Im building for the raspberry pi01:43
*** manuel_ <manuel_!> has joined #yocto01:46
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto01:48
*** manuel__ <manuel__!> has joined #yocto01:48
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC01:48
bluelightningfenrig_: confusingly it's VIRTUAL-RUNTIME not VIRTUAL_RUNTIME01:50
bluelightningif you have the latter in your config that may explain why it's not working01:50
*** manuel_ <manuel_!> has quit IRC01:51
*** manuel__ is now known as manuel_01:51
fenrig_okay lets rebuild01:51
fenrig_so "inherit systemd" makes the service enabled for boot01:52
fenrig_unless there is a01:52
fenrig_SYSTEMD_AUTO_ENABLE = "disable"01:52
Ulfalizerfenrig_: behind the scenes, a post-installation script is added to the package. when the package is installed, 'systemctl enable <service>' is run if SYSTEMD_AUTO_ENABLE is "enable".02:01
Ulfalizersearch for systemd_postinst in systemd.bbclass to see it02:01
Ulfalizerthe underlying mechanism is pkg_postinst. you'll find that in the reference manual.02:02
Ulfalizernot directly relevant, but it helps me to understand how it's implemented02:02
Ulfalizerurr... *in the development manual02:02
Ulfalizerfenrig_: has a note on VIRTUAL-RUNTIME btw02:06
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto02:09
*** manuel_ <manuel_!> has quit IRC02:10
*** manuel_ <manuel_!> has joined #yocto02:17
*** fenrig_ <fenrig_!5ee32de5@gateway/web/freenode/ip.> has quit IRC02:34
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto03:26
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC03:31
*** manuel_ <manuel_!> has quit IRC03:32
*** manuel_ <manuel_!> has joined #yocto03:47
*** AndersD <AndersD!> has joined #yocto04:06
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC04:11
*** manuel_ <manuel_!> has quit IRC04:15
*** dreyna <dreyna!> has joined #yocto04:23
*** gtristan <gtristan!~tristanva@> has joined #yocto04:36
*** sujith_h <sujith_h!~toaster@kde/developers/sujithh> has joined #yocto04:43
*** AndersD <AndersD!> has quit IRC04:51
*** Jefro <Jefro!> has joined #yocto04:57
*** dreyna <dreyna!> has quit IRC05:02
-YoctoAutoBuilder- build #1018 of nightly is complete: Failure [failed] Build details are at
*** optimus_ <optimus_!~optimus@> has joined #yocto05:06
*** agust <agust!> has joined #yocto05:39
*** rperier <rperier!~quassel@ubuntu/member/rperier> has quit IRC06:03
*** pohly <pohly!> has joined #yocto06:04
*** jku <jku!jku@nat/intel/x-jcceasihviubqzxs> has joined #yocto06:05
*** rperier <rperier!~quassel@2001:41d0:52:100::44a> has joined #yocto06:06
*** AndersD <AndersD!> has joined #yocto06:10
*** milindur <milindur!> has quit IRC06:10
*** jubr <jubr!57ed1b9e@gateway/web/freenode/ip.> has quit IRC06:11
*** mario-goulart <mario-goulart!> has joined #yocto06:15
*** mario-go` <mario-go`!> has quit IRC06:16
*** frsc <frsc!> has joined #yocto06:17
*** TobSnyder <TobSnyder!> has joined #yocto06:19
*** behanw <behanw!uid110099@gateway/web/> has quit IRC06:19
*** milindur <milindur!> has joined #yocto06:20
*** rob_w <rob_w!~bob@> has joined #yocto06:32
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:32
*** optimus_ <optimus_!~optimus@> has quit IRC06:39
*** hatter <hatter!> has joined #yocto06:39
*** t0mmy <t0mmy!> has quit IRC06:41
*** jonver <jonver!> has joined #yocto06:52
*** boucman_work <boucman_work!~boucman@> has joined #yocto06:53
*** eduardas_m <eduardas_m!~eduardas_@> has joined #yocto06:53
*** fl0v0 <fl0v0!> has joined #yocto06:58
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC07:04
*** Anticom <Anticom!~quassel@> has joined #yocto07:05
*** t0mmy <t0mmy!~tprrt@> has joined #yocto07:07
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto07:11
*** AndersD <AndersD!> has quit IRC07:11
*** jonver <jonver!> has left #yocto07:12
*** jonver <jonver!> has joined #yocto07:13
*** jonver <jonver!> has quit IRC07:14
*** jonver <jonver!> has joined #yocto07:16
*** toanju <toanju!~toanju@> has joined #yocto07:16
*** Jefro <Jefro!> has quit IRC07:16
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:20
*** robertmarshall <robertmarshall!> has joined #yocto07:20
*** AndersD <AndersD!> has joined #yocto07:26
*** ecdhe_ <ecdhe_!> has joined #yocto07:30
*** toscalix_ <toscalix_!~toscalix@> has joined #yocto07:31
*** mckoan|away is now known as mckoan07:32
*** obsrwr_ <obsrwr_!~otp-amois@> has joined #yocto07:32
mckoangood morning07:33
*** joshuagl <joshuagl!~joshuagl@> has joined #yocto07:41
*** frsc <frsc!> has quit IRC07:44
*** ecdhe <ecdhe!> has quit IRC07:48
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has joined #yocto07:48
*** ecdhe <ecdhe!> has joined #yocto07:49
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has joined #yocto07:49
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@> has joined #yocto07:50
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto07:50
*** zeenix <zeenix!~zeenix@> has joined #yocto07:55
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto08:00
*** seezer <seezer!quassel@quassel/developer/seezer> has quit IRC08:03
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC08:04
*** sameo <sameo!~samuel@> has joined #yocto08:04
*** shagu <shagu!> has joined #yocto08:06
*** frsc <frsc!> has joined #yocto08:07
*** grma <grma!~gruberm@> has joined #yocto08:07
*** jku <jku!jku@nat/intel/x-jcceasihviubqzxs> has quit IRC08:22
*** mortderire <mortderire!~rkinsell@> has joined #yocto08:24
*** jku <jku!~jku@2001:998:22:0:4e8d:79ff:fef2:49ba> has joined #yocto08:24
*** maxin <maxin!> has joined #yocto08:26
*** toanju <toanju!~toanju@> has quit IRC08:34
*** mortderire <mortderire!~rkinsell@> has quit IRC08:36
*** toanju <toanju!~toanju@> has joined #yocto08:38
*** falk0n <falk0n!> has joined #yocto08:48
*** sla <sla!c2fb77c5@gateway/web/freenode/ip.> has joined #yocto08:52
slahello guys, some question: lets say i have 4 targets (machines) in conf/, few tasks for building artifacts in classes/, and while executing bitbake my-image I want to build 4 targets at once. how can I achieve that? thanks for any tips08:56
*** seezer <seezer!quassel@quassel/developer/seezer> has joined #yocto08:59
*** JaMa <JaMa!> has joined #yocto09:02
*** belen <belen!~Adium@> has joined #yocto09:09
*** toanju <toanju!~toanju@> has quit IRC09:25
*** toanju <toanju!~toanju@> has joined #yocto09:25
*** mortderire <mortderire!~rkinsell@> has joined #yocto09:49
mckoansla: you can't, but you can concatenate bitbake commands using &&09:55
mckoansla: and specifying MACHINE=xxx on the commandline before each bitbake09:55
*** mortderire1 <mortderire1!~rkinsell@> has joined #yocto10:07
*** mortderire <mortderire!~rkinsell@> has quit IRC10:09
*** toscalix_ <toscalix_!~toscalix@> has quit IRC10:16
*** toscalix_ <toscalix_!~toscalix@> has joined #yocto10:18
*** toscalix <toscalix!~toscalix@> has joined #yocto10:24
*** toscalix_ <toscalix_!~toscalix@> has quit IRC10:26
*** mortderire1 <mortderire1!~rkinsell@> has quit IRC10:31
*** jku <jku!~jku@2001:998:22:0:4e8d:79ff:fef2:49ba> has quit IRC10:31
*** mortderire <mortderire!~rkinsell@> has joined #yocto10:31
*** jku <jku!~jku@2001:998:22:0:4e8d:79ff:fef2:49ba> has joined #yocto10:32
*** jku <jku!~jku@2001:998:22:0:4e8d:79ff:fef2:49ba> has quit IRC10:35
*** jku <jku!~jku@2001:998:22:0:4e8d:79ff:fef2:49ba> has joined #yocto10:35
*** Biliogadafr <Biliogadafr!~pin@> has joined #yocto10:37
*** obsrwr_ <obsrwr_!~otp-amois@> has quit IRC10:44
*** mortderire <mortderire!~rkinsell@> has quit IRC10:46
*** toscalix <toscalix!~toscalix@> has quit IRC10:48
*** toscalix <toscalix!~toscalix@> has joined #yocto10:59
*** redengin <redengin!> has quit IRC11:00
*** redengin <redengin!> has joined #yocto11:00
*** mortderire <mortderire!~rkinsell@> has joined #yocto11:08
*** mortderire1 <mortderire1!~rkinsell@> has joined #yocto11:10
*** mortderire <mortderire!~rkinsell@> has quit IRC11:13
*** mago_ <mago_!~mago@> has quit IRC11:14
*** mortderire <mortderire!~rkinsell@> has joined #yocto11:16
*** shagu <shagu!> has quit IRC11:22
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC11:24
*** nighty <nighty!> has quit IRC11:26
*** belen <belen!~Adium@> has quit IRC11:31
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto11:41
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC11:44
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto11:47
*** maxin <maxin!> has quit IRC11:48
aratiuI have a recipe which adds a new user via useradd but another recipe which depends on it fails because the user does not exist, when I go to the target sysroot I can't find the user in /etc/passwd. Can something overwrite the file in the sysroot (I don't do it intentionally)?11:50
*** falk0n <falk0n!> has quit IRC11:51
*** falk0n <falk0n!> has joined #yocto11:53
*** present <present!c2336e7b@gateway/web/freenode/ip.> has joined #yocto11:53
*** qt-x <qt-x!~Thunderbi@> has quit IRC11:56
*** gtristan <gtristan!~tristanva@> has quit IRC11:57
*** istarilucky <istarilucky!~rlucca@> has joined #yocto11:58
*** qt-x <qt-x!~Thunderbi@> has joined #yocto11:59
*** seebs <seebs!~seebs@2601:196:4901:ec80:f1d1:b4ad:12e2:4c03> has quit IRC12:02
*** seebs <seebs!> has joined #yocto12:03
*** phatina <phatina!> has joined #yocto12:03
*** maxin <maxin!~maxin@2001:998:22:0:844f:dfe2:9cc2:a409> has joined #yocto12:04
*** marka_home <marka_home!> has joined #yocto12:15
*** gtristan <gtristan!~tristanva@> has joined #yocto12:16
*** seebs <seebs!> has quit IRC12:16
*** seebs <seebs!> has joined #yocto12:17
*** berton <berton!~fabio@> has joined #yocto12:21
*** caiortp <caiortp!~inatel@> has joined #yocto12:22
*** t0mmy <t0mmy!~tprrt@> has quit IRC12:25
jkuarmpit: had a look at the Xorg failure on your krogoth-next nightly-musl: khem fixed this in master , oe-core rev e279c9a30f12:26
*** dmoseley <dmoseley!> has quit IRC12:26
*** seebs <seebs!> has quit IRC12:29
*** t0mmy <t0mmy!~tprrt@> has joined #yocto12:31
*** seebs <seebs!> has joined #yocto12:31
*** mago_ <mago_!~mago@> has joined #yocto12:34
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:35
jkuaratiu: can you share the recipe?12:36
*** seebs <seebs!> has quit IRC12:39
*** csanchezdll <csanchezdll!> has joined #yocto12:41
*** oob <oob!> has joined #yocto12:41
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC12:47
*** belen <belen!~Adium@> has joined #yocto12:53
*** nighty <nighty!> has joined #yocto12:54
*** jku <jku!~jku@2001:998:22:0:4e8d:79ff:fef2:49ba> has quit IRC13:00
*** ziggo <ziggo!~ziggo@> has quit IRC13:01
*** jku <jku!jku@nat/intel/x-clwqveboaudaxcod> has joined #yocto13:02
*** igor3 <igor3!~igor@> has joined #yocto13:02
*** Anticom <Anticom!~quassel@> has quit IRC13:03
*** 7YUAB2SWX <7YUAB2SWX!~quassel@> has joined #yocto13:04
*** jku <jku!jku@nat/intel/x-clwqveboaudaxcod> has quit IRC13:04
*** fl0v0 <fl0v0!> has quit IRC13:05
*** fl0v0 <fl0v0!> has joined #yocto13:05
*** 7YUAB2SWX is now known as Anticom13:06
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC13:07
melonipoikahas anyone seen this waring when building pulseaudio? 'WARNING: /home/josealar/poky/meta/recipes-multimedia/pulseaudio/ Getting checksum for pulseaudio SRC_URI entry : file not found except in DL_DIR'13:10
melonipoika(krogoth branch)13:10
melonipoikaI don't know how to debug what is the file that is not found...13:11
rburtonwell, is there a SRC_URI entry that doesn't exist alongside the recipe13:12
*** vmeson <vmeson!> has quit IRC13:13
melonipoikano, all are there13:13
rburtonthen do you have a layer that appends pulseaudio?13:14
rburton(bitbake pulseaudio -e | less and search for SRC_URI to check)13:14
rburtonthe message is "Getting checksum for %s SRC_URI entry %s: file not found except in DL_DIR"13:15
rburtonso the entry is ""13:15
rburtonbad whitespace causing problems?13:15
*** eduardas_m <eduardas_m!~eduardas_@> has quit IRC13:18
melonipoikaoh, yes we are appending it in our layer...13:18
*** maxin <maxin!~maxin@2001:998:22:0:844f:dfe2:9cc2:a409> has quit IRC13:19
melonipoikaand we have four SRC_URI entries that don't exist...13:20
*** Phlogistique <Phlogistique!~phlogisti@> has quit IRC13:22
melonipoikathat was it, thanks rburton!13:26
melonipoikabtw when looking into this I found this in the pulseaduio .inc file13:26
melonipoikaLIC_FILES_CHKSUM = "file://GPL;md5=4325afd396febcb659c36b49533135d4 \13:26
melonipoikashouldn't this be LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6 ?13:27
rburtonthat is relative to ${S} and refers to the GPL file in the tarball13:27
melonipoikai see13:27
rburtonLIC_FILES_CHKSUM is designed to detect license changes *in the source itself*13:27
rburtonso there's no point to pointing it at a file that isn't in the source13:27
melonipoikamakes sense13:28
rburtonit should be pointing at LICENSE as that is where the terms are, it's a fair assumption that "GPL is going to be the GPL13:28
rburtonbut if LICENSE changes then we need to be warned13:28
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto13:29
* rburton adds13:29
*** manuel_ <manuel_!> has joined #yocto13:31
JaMarburton: thanks for cmake cleanups!13:32
*** igor3 <igor3!~igor@> has quit IRC13:32
rburtonJaMa: i hate cmake13:33
rburtonJaMa: those patches took about a day of fiddling and testing.13:33
rburtonJaMa: that said, buildstats-diff is AWESOME and now queued for oe-core13:33
*** ntl <ntl!> has joined #yocto13:34
*** igor3 <igor3!~igor@> has joined #yocto13:35
*** challinan <challinan!> has quit IRC13:36
JaMarburton: that's why there was bugzilla report for that, sorry that in the end it fall on you to handle13:38
*** maxin <maxin!> has joined #yocto13:40
joshuagldon't listen to rburton, he loves hacking around buildsystems13:42
rburtonit doesn't help my case if i say i have the start of a meson recipe does it13:43
*** Phlogistique <Phlogistique!~phlogisti@> has joined #yocto13:43
joshuaglit absolutely does not13:43
*** fenrig <fenrig!5ee32de5@gateway/web/freenode/ip.> has joined #yocto13:44
joshuaglin fact I almost asked you how it was going so as to prove the point :-)13:44
fenrigHi, is it possible ffmpeg isnt building with mp3 support? I'm having a double free with mpd playing a mp3 stream using ffmpeg13:44
fenrigand apparently gst-ffmpeg is blacklisted13:45
*** behanw <behanw!uid110099@gateway/web/> has joined #yocto13:55
*** madisox <madisox!~madison@> has joined #yocto13:56
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined #yocto13:56
*** AndersD <AndersD!> has quit IRC14:02
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:07
*** fenrig <fenrig!5ee32de5@gateway/web/freenode/ip.> has quit IRC14:20
*** manuel_ <manuel_!> has quit IRC14:20
*** mckoan is now known as mckoan|away14:23
*** manuel_ <manuel_!> has joined #yocto14:23
*** manuel_ <manuel_!> has quit IRC14:27
RPrburton: I'm not convinced about the build-appliance fix btw :/14:30
*** alexlarsson <alexlarsson!> has joined #yocto14:30
RPrburton: its defeating the artefact manifest the deploy_dir changes were meant to help14:30
alexlarssonWho would i do an:Ä14:31
alexlarssonRDEPENDS_${PN} +=14:31
alexlarssonbut only for certain arches?14:31
alexlarssonI.e. I want to add libasan-staticdev14:31
alexlarssonbut its not there on arm14:31
*** caiortp <caiortp!~inatel@> has quit IRC14:32
*** manuel_ <manuel_!> has joined #yocto14:36
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@> has joined #yocto14:37
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto14:37
alexlarssonDo i use RDEPENDS_${PN}_append_x86-64 ?14:39
rburtonalexlarsson: that looks like it would work14:41
*** Anticom <Anticom!~quassel@> has quit IRC14:42
alexlarssonrburton: cool14:42
alexlarssonthis whole parsing-variable-names thing scares me to no end14:43
*** manuel_ <manuel_!> has quit IRC14:43
alexlarssonWho defines what are valid prefixes? and what about ordering, conflicts, etc14:43
* alexlarsson shudders14:43
alexlarssonI guess i don't really want to know...14:45
*** alimon1 <alimon1!~alimon@> has quit IRC14:45
alexlarssonwhat would _x86-64_append do?14:46
rburtonordering is wrong14:46
alexlarssonWhat about a package called "append"?14:46
*** manuel_ <manuel_!> has joined #yocto14:46
rburtonwell in this case the logic actually looks for a variable called "RDEPENDS_" + pkg14:46
rburtonso don't call a package append14:47
alexlarssonlittle bobby drop tables...14:47
*** yahya93 <yahya93!c525ed02@gateway/web/freenode/ip.> has joined #yocto14:48
*** alimon1 <alimon1!~alimon@> has joined #yocto14:50
*** alimon1 <alimon1!~alimon@> has left #yocto14:50
rburtonalexlarsson: yeah…14:50
*** alimon1 <alimon1!alimon@nat/intel/x-nwjwjpcdvkdcxylj> has joined #yocto14:50
yahya93hello , I have a question in Toaster. I used Toaster to make an rpi-hwup-image for raspberrypi 2 , but it didn't generate the sdimg file , does anybody know how to do that using Toaster ?14:51
*** simonl <simonl!uid6729@gateway/web/> has joined #yocto14:51
belenyahya93: you would need to add the image type to the IMAGE_FSTYPES variable. If you are using the master branch, you can do so from toaster.14:53
yahya93belen: thanks for your answer, but the sdimg is not listed in the IMAGE_FSTYPES14:55
presentyahya93: There use to be bug report/feature request about that14:56
presentyahya93: And you can directly edit the proper file which is using Toaster to add sdimg in it14:57
belenyahya93: present is correct. The bug is fixed, but only in master, not in the last stable release14:58
yahya93when I creat a new project , I don't find master listed in the options, only Jethro and Krogoth14:58
yahya93belen: when I creat a new project , I don't find master listed in the options, only Jethro and Krogoth14:59
*** present <present!c2336e7b@gateway/web/freenode/ip.> has quit IRC14:59
belenyahya93: yes, that's because you are using the Yocto Project krogoth release. When I say master, I mean the Yocto Project development branch15:00
*** manuel_ <manuel_!> has quit IRC15:00
belenyahya93: a possible workaround is to edit the poky/bitbake/lib/toaster/orm/ file. That file contains a list of image types: you can add sdimg to that list, and you will then able to select  it from the toaster web ui15:02
belenyahya93: I think the proper name is rpi-sdimg, but I am not 100% sure15:03
*** jonver <jonver!> has quit IRC15:04
*** alexlarsson <alexlarsson!> has left #yocto15:04
michaelw1yahya93: ( )15:05
*** TobSnyder <TobSnyder!> has quit IRC15:06
*** toanju <toanju!~toanju@> has quit IRC15:07
yahya93belen & michaelwl: That was great help! thank you very much15:08
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC15:08
*** jonver <jonver!> has joined #yocto15:09
*** qt-x <qt-x!~Thunderbi@> has quit IRC15:10
belenyahya93: no worries. Any other questions, let us know15:14
*** jonver <jonver!> has quit IRC15:20
*** manuel_ <manuel_!~manuel@> has joined #yocto15:24
*** zeenix <zeenix!~zeenix@> has quit IRC15:28
*** maxin <maxin!> has quit IRC15:32
*** gtristan <gtristan!~tristanva@> has quit IRC15:32
*** oob <oob!> has quit IRC15:32
*** manuel_ <manuel_!~manuel@> has quit IRC15:34
*** manuel_ <manuel_!~manuel@> has joined #yocto15:34
*** morphis_ <morphis_!> has joined #yocto15:35
*** morphis__ <morphis__!> has quit IRC15:38
*** vmeson <vmeson!> has joined #yocto15:43
*** robertmarshall <robertmarshall!> has quit IRC15:48
*** Jefro <Jefro!> has joined #yocto15:48
*** ntl <ntl!> has quit IRC15:49
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC15:57
*** aehs29 <aehs29!~aehernan@> has joined #yocto15:59
*** belen <belen!~Adium@> has quit IRC16:02
*** yahya93 <yahya93!c525ed02@gateway/web/freenode/ip.> has quit IRC16:12
*** yahya93 <yahya93!c525ed02@gateway/web/freenode/ip.> has joined #yocto16:13
*** ntl <ntl!> has joined #yocto16:14
*** maxin <maxin!> has joined #yocto16:22
*** tobiash <tobiash!~quassel@> has quit IRC16:22
*** belen <belen!Adium@nat/intel/x-fuqpznoakrsejytq> has joined #yocto16:22
*** tobiash <tobiash!~quassel@> has joined #yocto16:23
*** fl0v0 <fl0v0!> has quit IRC16:24
*** belen <belen!Adium@nat/intel/x-fuqpznoakrsejytq> has quit IRC16:31
*** belen <belen!~Adium@> has joined #yocto16:35
*** caiortp <caiortp!~inatel@> has joined #yocto16:36
*** belen <belen!~Adium@> has quit IRC16:42
*** tobiash <tobiash!~quassel@> has quit IRC16:44
*** boucman_work <boucman_work!~boucman@> has quit IRC16:44
*** tobiash <tobiash!~quassel@> has joined #yocto16:45
*** egavinc <egavinc!> has quit IRC16:49
*** gtristan <gtristan!~tristanva@> has joined #yocto16:52
*** Biliogadafr <Biliogadafr!~pin@> has quit IRC16:53
*** maxin <maxin!> has left #yocto16:53
*** mortderire <mortderire!~rkinsell@> has quit IRC16:54
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC16:57
*** frsc <frsc!> has quit IRC17:00
*** t0mmy <t0mmy!~tprrt@> has quit IRC17:03
*** darwish_ <darwish_!~darwish@> has quit IRC17:03
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto17:09
-YoctoAutoBuilder- build #326 of nightly-checkuri is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #278 of nightly-no-x11 is complete: Success [build successful] Build details are at
*** falk0n <falk0n!> has quit IRC17:18
*** toscalix <toscalix!~toscalix@> has quit IRC17:20
*** dreyna <dreyna!> has joined #yocto17:24
*** obsrwr_home <obsrwr_home!~obsrwr@> has joined #yocto17:25
khemkergoth: precisely, yes its for older gcc17:27
*** dmoseley <dmoseley!> has joined #yocto17:27
khemkergoth: or for arches where libatomic in gcc does not _yet_ support17:27
khemwhen you go back in versions then the support for atomics came in in pieces17:28
*** alimon1 <alimon1!alimon@nat/intel/x-nwjwjpcdvkdcxylj> has quit IRC17:33
*** dv_ <dv_!~quassel@> has quit IRC17:46
*** dv_ <dv_!~quassel@> has joined #yocto17:46
*** aehs29 <aehs29!~aehernan@> has left #yocto17:48
*** morphis_ <morphis_!> has quit IRC17:49
neverpanicIs there an official Yocto project leadership? Or some people working full time on Yocto? kergoth, rburton maybe?17:50
neverpanicOr is there a mail address to send offers for the project?17:50
armpitneverpanic, see
neverpanicarmpit: Thanks, that answers my question18:02
*** _markfeatherston <_markfeatherston!> has left #yocto18:02
*** joseppc <joseppc!> has joined #yocto18:15
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto18:15
*** challinan <challinan!> has joined #yocto18:18
*** Phlogistique <Phlogistique!~phlogisti@> has quit IRC18:19
*** hatter <hatter!> has quit IRC18:19
otavioIs someone using Docker to run KVM instances? We use it as a set of our test infrastructure and we are having problems to run multiple docker instances with KVM in parallel18:19
*** dmoseley <dmoseley!> has quit IRC18:26
*** aehs29 <aehs29!aehernan@nat/intel/x-mftufgvgjifckjkp> has joined #yocto18:35
lukma1Dear all,18:40
lukma1Please correct me if I'm wrong18:40
*** t0mmy <t0mmy!> has joined #yocto18:40
lukma1Is it doable to create my own core-image-XXXXXX image to be layer on top of for example core-image-minimal ?18:41
*** arkver <arkver!> has joined #yocto18:47
*** hatter <hatter!> has joined #yocto18:49
*** dmoseley <dmoseley!> has joined #yocto18:49
*** alimon1 <alimon1!~alimon@> has joined #yocto18:53
*** ntl <ntl!> has quit IRC19:01
*** marka <marka!~marka@> has joined #yocto19:01
*** hatter <hatter!> has quit IRC19:03
jmesmonlukma1: you could create a core-image-minimal_%.bbappend and append to vars in there, though I'm not sure that's really recommended practice.19:04
*** obsrwr_home <obsrwr_home!~obsrwr@> has quit IRC19:11
*** t0mmy <t0mmy!> has quit IRC19:12
*** JaMa <JaMa!> has quit IRC19:15
*** kad <kad!~kad@unaffiliated/kad> has quit IRC19:15
*** ntl <ntl!> has joined #yocto19:16
*** kad <kad!~kad@unaffiliated/kad> has joined #yocto19:17
kergothlukma1: what do you mean by layer? if you just want to use that as a starting point, your best bet is to just copy it to your own image. and core-image- isn't really appropriate naming anymore in that case19:25
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC19:25
*** poucelyne <poucelyne!> has joined #yocto19:26
*** poucelyne <poucelyne!> has left #yocto19:26
*** bluelightning <bluelightning!> has joined #yocto19:33
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:33
*** dreyna <dreyna!> has quit IRC19:37
*** yahya93 <yahya93!c525ed02@gateway/web/freenode/ip.> has quit IRC19:42
*** aehs29 <aehs29!aehernan@nat/intel/x-mftufgvgjifckjkp> has left #yocto19:49
-YoctoAutoBuilder- build #573 of nightly-mips64 is complete: Failure [failed Running Sanity Tests] Build details are at
rburtonyou can do that19:55
rburtonlukma1: easier to just copy core-image-minimal and then modify it as you want19:55
*** Crofton <Crofton!> has joined #yocto19:57
rburtonjust *how* evil is something like this in a recipe :       ${B}/*-libtool --mode install install $b ${D}${bindir}20:00
fray_should work as long as the shell properly processes the wild card -and- only matches one instance20:01
fray_problem is if there are multiple matches it can fail20:01
rburtonwell its out-of-tree autotools20:01
rburtonand i'm now getting gnu hash errors so obviously i do need to patch this makefile after all20:02
*** mortderire <mortderire!~rkinsell@> has joined #yocto20:02
fray_BTW I'm trying to avoid producing a backtrace in an event handler in case of a specific failure.. last week RP mentioned that he though it was a simple 'raise' exception (which I'm forgetting which exception) that will cause the system to clean up an exit, but no backtrace..20:02
fray_Anyone know what is needed?20:02
fray_(bb.fatal prints an exception, which causes the actual error message to be obscured)20:02
rburtonstarted looking at someone elses autotools and now i want to drink20:04
rburtonconveniently its beerbods night20:05
rburton"we don't need automake"20:05
rburtonfails to pass ldflags20:05
rburtonmissing install targets20:05
fray_that is relatively normal.. there is a reason why people use the auto* tools..20:05
fray_even though they do often get in the way20:05
kergothfray_: I don't think there's any way to avoid a traceback in all cases fro an event handler, i ran into this too. i was trying to exit out with an error from TaskStarted to prevent the ability to build in a certain case, but no exception really seemed to do the job, given what exceptions were handled where in the code20:05
*** khem <khem!~khem@unaffiliated/khem> has quit IRC20:05
kergothwe need to catch more from at various places in the code20:06
*** fray_ is now known as fray20:06
rburton300 line, 80% of which is boilerplate that automake does20:06
kergothFuncFailed -> traceback, bb.fatal -> traceback..20:06
* kergoth shrugs20:06
fraykergoth that is pretty much what I'm trying to do..20:06
kergothrburton: ugh. reinventing the wheel badly..20:07
frayI can see the event handler is parsing "SystemExit".. but that doesn't seem like necessarily a good thing to raise20:07
kergothfray: also if you use the wrong one from the wrong event, you can end up exiting the main build process without proper cleanup20:07
kergothfray: bb.fatal generates SystemExit.20:07
frayAhh didn't realize it did that..20:07
kergothbb.fatal runs sys.exit which raises SystemExit20:07
fray    try:20:07
fray        ret = handler(event)20:07
fray    except (bb.parse.SkipRecipe, bb.BBHandledException):20:07
fray    except SystemExit as exc:20:07
frayso I was expecting BBHandledException to "work".. but it doesn20:08
kergothat least, bb.fatal used to. maybe it raises handledexception now, would ahve to double check the code20:08
kergothat any rate, sys.exit() raises SystemExit, so you don't usually have to raise it explicitly20:08
frayfatal calls sys.exit(1)20:09
kergothah, okay, figued20:09
kergoththe problem is, even if the code in catches errors, prints them,a dn raises handledexception, we'd still need to catch handledexception from every call to, which we don't do, afaik20:09
*** seebs <seebs!> has joined #yocto20:09
kergothneed to add try/catch blocks to every fire() call either way20:10
frayya, I wasn't expecting bb.fatal to produce a trace20:10
fraywell, I clearly have the backtrace for the event handler.. ;)20:10
frayproblem is I don't understand what to do if I do catch the BBHandledException....20:10
bluelightningwe need a test for that apparently, because it sounds like it's regressed...20:10
fray(I'm looking for an example)..20:10
kergothfray: i think it depends where the event is fired from20:10
frayI'm also not finding where the backtrace is actually fired20:11
kergothi.e. cooker would want to initiate a shutdown20:11
frayseems like the place the backtrace is fired from is where the BBHandledException should be caught20:11
kergothwhereas a build running a function probably wants a FuncFailed to indicate the function failure to the runqueue20:11
kergothso as always with exception handling, the answer is it depends on context :)20:11
fraythe comments on BBHandledException is that anything that inherits it has already given the user enough information to fix the problem -- so not to print a backtrace. .:)20:12
frayobviously not working20:12
kergothright, but it still has to appropriately handle the failure in some cases20:12
kergothotherwise you'd just be ignoring the event handler failure, which is wrong20:12
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto20:12
kergoththe fact that a message has been printed is great, but we still need to shut down the build20:12
kergothso depends on what it means by handled, i guess :)20:12
kergothafaik that message usually indicates 'an error has been printed, silently take whatever action is appropriate'20:13
kergotherm, s/that message/that exception/20:13
* kergoth isn't a fan of BBHandledException, it was a massively brute force answer, when we should really have handled more on a case by case basis.. but bitbake is huge, so can understand why that route was taken20:14
frayproblem is something along the lines broke.. this "used to work" AFAIK..20:14
fraymaybe it still does in some cases, but I can't figure out where the actual backtrace is being dumped.. if I could, I could avoid it in the BBHANdledException, and but still do the rest of whatever the cleanup is20:14
fraylast part I get in the backtrace is:20:15
fray  File "/home/mhatle/git/oss/oe-core/bitbake/lib/bb/", line 271, in CookerDataBuilder.parseBaseConfiguration():20:15
fray    >  ,
frayso it's one level 'above' that.. whatever caught the fault in the base config processing20:16
kergothfire() does result in handlers being run, the only question is whether they run in the server or the ui, afaik20:16
kergothwould have to double check event.py20:17
*** khem <khem!~khem@unaffiliated/khem> has quit IRC20:18
frayfound the parse block in the parseBaseConfiguration20:18
kergothit sure would be nice to break up some of bitbake's functionality to reduce the tight binding between the components and modules. i.e. split out fetch into a separate standalone package or cli tool, make the runqueue generation emit scripts + metadata so you culd use make or ninja to actually run the tasks, etc20:19
fraythe three except blocks in the parseBaseConfiguration, all eventually raise bb.BBHandledException20:20
frayso why the hell is it doing a traceback20:20
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC20:21
frayis python itself doing the traceback?20:21
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto20:21
frayI'm not seeing any try / exception blocks around tinfoil and it's BBCooker, which is what eventually runs the parseBaseConfiguration20:22
Ulfalizerfray: python itself prints tracebacks for uncaught exceptions20:23
frayI'm looking at knotty and such.. and I don't see any BBHandledExceptions code either20:23
Ulfalizerthat's why you get "Traceback (most recent call last):" if you type "cduishciusdh" into the interactive interpreter :P20:23
-YoctoAutoBuilder- build #929 of nightly-mips is complete: Failure [failed Running Sanity Tests] Build details are at
frayso should hte UI be the one handling the exception to finish the shutdown?  (I don't understand this part of bitbake)20:25
*** mortderire <mortderire!~rkinsell@> has quit IRC20:27
*** khem <khem!~khem@unaffiliated/khem> has quit IRC20:28
kergothfray: yes, an uncaught exception gets a traceback, as Ulfalizer says20:34
*** marka <marka!~marka@> has quit IRC20:34
frayI added a catch in the event fire function, and suddenly the logger went away, so I saw all fo the 'debug' messages..20:34
frayreally odd20:34
*** grma <grma!~gruberm@> has quit IRC20:35
fraywait.. no it worked this time..20:36
frayI must have broken my environment.. :P20:36
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto20:37
*** khem <khem!~khem@unaffiliated/khem> has quit IRC20:43
*** caiortp <caiortp!~inatel@> has quit IRC20:43
frayAH-HA!  I figured it out!20:44
fraythe block in was not explicitly handling bb.BBHandledException..20:44
frayso it was getting caught by the 'except Exception:' block what was doing logger.exception("Error parsing configuration files")20:45
frayand logger.exception was producing a backtrace20:45
kergothah. that explains that one event, anyway :)20:45
kergothalmost none of the actually catch exceptions of any kind :(20:45
frayafter that it worked fine.. I think I have a fairly simple fix20:45
fray-        except bb.data_smart.ExpansionError as e:20:46
fray+        except (bb.data_smart.ExpansionError, bb.BBHandledException) as e:20:46
fraythat look 'reasonable'..20:46
fray             logger.error(str(e))20:46
fray             raise bb.BBHandledException20:46
fray(reset of it).. not sure if it makes sense to unconditionally print the 'e'..  since some instances of BBHandledException won't have an 'e'20:46
kergothyou shouldn't print a BBHandledException at all, by defintiion its error has already been printed20:47
frayok.. I found some examples where people were doing 'BBHandledException('some message here')' which was confusing me20:47
frayeasy enough, the line above:20:47
fray         except SyntaxError:20:47
fray             raise bb.BBHandledException20:47
fraycan just be extneded to include BBHandledException20:47
kergothare those really raising BBHandledException, not BBHandledException()?20:47
kergothraising an exception class instead of an object is a bit odd20:47
fraythats what it says20:48
fraywhat I have now:20:48
fray-        except SyntaxError:20:48
fray+        except (SyntaxError, bb.BBHandledException):20:48
fray             raise bb.BBHandledException20:48
fray         except bb.data_smart.ExpansionError as e:20:48
fray             logger.error(str(e))20:48
fraythat is  BTW20:48
kergothraising a new BBHandledException instead of the one we already have is a little odd, though admittedly minor20:49
kergothexcept bb.BBHandledException: raise; might be slightly cleaner, though at the cost of more lines of code20:49
frayI have to raise instead of letting it fall through.. but ya.. laternative is ...20:49
frayyou beat me to it, but I don't see any real advantage in this code..20:49
kergothagreed, particularly since the class isn't carrying any information, it's not even an object half the time20:49
frayI don't see any real examples either way in the bitbake code......20:49
frayI'll send up a change to the bitbake-devel20:51
Ulfalizer'raise Foo' is the same as 'raise Foo()' if Foo is a class btw. you're only allowed to raise stuff that inherits from BaseException, so raising a class object wouldn't make sense anyway, making it unambiguous.20:54
frayDAMNIT.. I think I just sent crap to the mailing list..20:54
Ulfalizerfray: git format-patch... --subject-prefix="PATH v2" ... ;)20:55
Ulfalizercould add a --cover-letter that explains what you changed since v1 too20:55
frayno.. it didn't send the commit ID I pasted.. it sent the commit ids of all of the patches AFTER the one I wanted (which are still in progress)20:55
frayat some point the git send-email changed behavior and no longer works like git log, git show, etc..20:56
kergothUlfalizer: BBHandledException does inherit from BaseException, so really don't see your point there20:56
kergothfray: also, bb.fatal() raises BBHandledException in current bitbake, but bb.msg.fatal() does a sys.exit20:56
* kergoth rolls eyes20:56
Ulfalizerkergoth: i meant at the language level. 'raise Foo()' can be shortened to 'raise Foo'.20:57
fraythere we go.. the RIGHT patch sent this time20:57
kergothUlfalizer: interesting, didn't realize that. i like the () for consistency, but didn't realize raise would instantiate for us. cool20:58
kergoth"It must be either a subclass or an instance of BaseException. If it is a class, the exception instance will be obtained when needed by instantiating the class with no arguments."20:58
*** paulg <paulg!> has quit IRC20:58
frayahh.. with that patch, you are right.. bb.fatal works again.. no more backtrace!20:58
kergothfray: thanks for the inspiration, i realized i can fix my use case pretty trivially too. i needed to be able to fail from TaskStarted, so just had to move into the try/except and add a clause for BBHandledException :)20:59
* kergoth will send a patch too20:59
frayI know some of this worked in the past (w/o dumping backtraces) so I'm guessing some code was changed around which triggered the faults (or maybe even python3 differences)21:00
kergothclearly missing test cases, as bluelightning pointed out :\21:01
fraythis is an issue, I'm not sure how to implement a test case.. :|21:02
bluelightningthat was an unsubtle hint btw ;)21:02
fraypretty easy.. run an event handler, run a bb.fatal(...) inside of it.. but do we have an existing event handler tests?21:02
bluelightningnot that I know of21:02
fray(I don't see any, but maybe I'm not looking in the right place)21:02
*** pohly <pohly!> has quit IRC21:03
bluelightningunusually this is one you could probably do in the bitbake tests comfortably21:03
frayso if someone figures out the right way to implement event handler tests, I'm happy to add one21:03
frayI'm honestly now sure how to implement it.. the other tests all run functions inside bitbake..21:03
frayI don't think that is what we want in this case21:04
bluelightningright, yeah, you won't have access to both sides21:04
bluelightningprobably easier as an oe-selftest test then21:04
fraywe'd need a small layer or something to implement the 'fatal' event handler..  again, not sure how to do that in the oe self-tests.. but overall, I think you are right it would be easier in that environment21:06
frayI think21:06
bluelightningmeta-selftest exists for that kind of thing (oe-selftest requires it to be in your config when running)21:06
kergothproblem is you have to cover all the codepaths for in bitbake. we cant' fire them ourselves, it's not being cought in the bitbake code that's the problem21:06
kergothso i.e. bitbake -p would be insufficient depending on which event handler is fatal'ing21:06
kergothI wonder if we should test the runqueue task events, too21:06
fraykergoth, I think (over time) we could built up a reasonable set of event handlers and such to capture many of the cases..21:06
kergoththose catch nothing, but any event could error out in the metadata21:07
* kergoth tried erroring out from the runqueue task started event which immediately exited the bitbake server process, not pretty :)21:07
bluelightningsome events don't make it to the task handlers, that's true21:07
frayI've only ever done this stuff on events that run on 'early'21:07
bluelightninghandlers defined in the metadata, that is21:07
bluelightning"class handlers", that's the term I meant to use21:08
*** Tenhi_ <Tenhi_!> has joined #yocto21:11
* kergoth scratches head21:13
kergothif i bb.fatal() in a TaskStarted handler, should I fire TaskFailed? technically the task never ran... though I guess if TaskStarted fired at all, one should fail to ensure the mirrored events line up, even though not all TaskStarted event handlers ran..21:14
*** Crofton <Crofton!> has quit IRC21:14
kergothi wonder if it should continue to run the other event handlers when one of them fails, and collects the various errors/exceptions and shows them all, otherwise which event handlers run is highly dependent upon event registration order.. though maybe that's okay..21:15
kergothcertain parts of bitbake really hurt my head21:16
*** Tenhi_ <Tenhi_!> has quit IRC21:16
-YoctoAutoBuilder- build #257 of nightly-musl is complete: Success [build successful] Build details are at
frayI'm not sure.. and I know eventually if the tasks and the controller are on different machines this is even more complicated21:18
*** Jefro <Jefro!> has quit IRC21:18
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto21:21
*** lukma1 <lukma1!~lukma@> has quit IRC21:21
kergothamong other things, i think we should, one of these days, adopt oe-lite's change which added addtask-style dependencies / ordering control to event handling21:22
*** dreyna <dreyna!> has joined #yocto21:23
fraykergoth, did you see the LAYERRECOMMEND patch that was sent?21:25
kergothyep. i'm a fan of the feature, haven't had a chance to review the code, though21:25
frayFrom the oe-arch conversation nobody really cared, and most were surprised there was auto priority stuff in bitbake -- but I think it should be fine21:25
* kergoth nods21:25
frayit's more or less a copy of the existing dependency checking, but stripped of 'errors'.. debugging was added.. and any miss deps are just excluded21:25
frayactually turned out easier then I thought it would be..21:26
kergothfor what its worth it has my ack for 2.3, i want to see it merged eventually21:26
fraywe're currently working on adding a 'recommends' flag to the layer index as well (for the layerDependency) data structure21:26
fraywhat we want it for is primarily our 'download layers'.. We've got special layers that are just the cached download components for a given layer, like oe-core or meta-oe, or meta-networking, etc..  we'd like those to be 'recommended' depedencies so toaster and others can optionally pull them down from our servers21:27
frayuser can basically choose to pull down everything right now -- or not do it and take the download hit 'later'21:27
fray(now also facilitates off-line building)21:27
fraybut I expect over time, we can do other recommended layers and filtering w/ bbmask and such if a collection is available or not21:29
*** arkver <arkver!> has quit IRC21:32
*** agust <agust!> has quit IRC21:33
*** lukma1 <lukma1!~lukma@> has joined #yocto21:34
*** a1cypher <a1cypher!> has joined #yocto21:36
kergothah, interesting. hadn't thought about using layers for downloads21:36
kergothwe do a lot of 'inherit this class only if this layer is available' in our distro21:36
*** dmoseley <dmoseley!> has quit IRC21:36
kergoth(and similar)21:36
fraydownloads as layers make it easy to keep pieces 'connected' at least21:37
*** ntl <ntl!> has quit IRC21:37
frayyou can also automate this by adjusting the DL_DIR to include the layer name in the generated path.. ;)21:37
fraythen do a bitbake -c fetchall universe -k21:37
a1cypherHey.  Trying to add avahi to my image.   I added  "avahi" to my IMAGE_INSTALL_append list but now I get "avahi not found in the base feeds" when I try to bitbake the image21:38
frayabout 90% of the stuff is already in the right place for you at the end21:38
a1cypheravahi definitely builds and I can see the binaries in the work folder21:38
frayavahi is not the anem of a generated package..  you will need to look at the recipe, or the package output and figure out what the name of the -package- produced is21:38
frayrecipe and package names are not always the same21:38
bluelightninga1cypher: I think you want avahi-daemon instead21:39
Ulfalizera1cypher: might be helpful21:39
fray(the 'PACKAGES' variable in the recipes helps determine the names..  and I think he's right.. avahi-daemon is likely what you want)21:39
Ulfalizeri've updated the DEPENDS and RDEPENDS glossary entries in the 2.2 reference manual to try to clear up recipe vs. package confusion too21:40
bluelightningI think perhaps the issue is the recipe lies and says it produces an ${PN} package, if it didn't do that at least you would get an error earlier21:40
a1cypherif I do bitbake -e avahi | grep ^PACKAGES=   I get "PACKAGES="libavahi-gobject avahi-daemon libavahi-common libavahi-core libavahi-client avahi-dnsconfd libavahi-glib libavahi-ui avahi-autoipd avahi-utils avahi-dbg avahi-staticdev avahi-dev avahi-doc avahi-locale  avahi"21:40
a1cypherI thought since "avahi" was at the end there that If I chose that one I would get them all21:40
fraybluelightning it is.. certainly one of the complaints I've had from customers.. why is it in the list, if it's not provided21:40
bluelightninga1cypher: right, it claims it will produce that package, it either should produce it or not claim that it does21:40
fraya1cypher that is how a few things were implemented, but not everything..21:41
*** mortderire <mortderire!~rkinsell@> has joined #yocto21:41
bluelightningmore of a frustration than an outright bug, but IMO we should correct it21:41
a1cypherok, so I'll try just including the specific ones that I want and see if that helps21:41
fraymight be a cleanup worth exploring in YP 2.3, a test that exposing things not produced, then someone can go in and cleanup the PACKAGES..  (there will always be SOME package entries that are dynamic... but most are not)21:41
*** ant_home <ant_home!> has joined #yocto21:42
a1cypheralso the specific error message is like 10 screens of red text with no linebreaks.21:42
bluelightninga1cypher: yuck - can you pastebin that?21:43
*** joshuagl <joshuagl!~joshuagl@> has quit IRC21:43
-YoctoAutoBuilder- build #947 of nightly-multilib is complete: Success [build successful] Build details are at
bluelightningI believe you can thank fray for that message ;)21:45
bluelightningI've always thought it was pretty hideous myself21:45
*** smurray <smurray!sid98062@gateway/web/> has quit IRC21:45
frayconfused.. the error you care about is at the very end..21:46
frayisn't it?21:46
*** rob-oi-ma <rob-oi-ma!sid155560@gateway/web/> has quit IRC21:46
frayahh no.. it was reorderd..21:47
bluelightningfray: "not found in the base feeds (<bleaaaaaargh massive list that's way too long to read>)"21:47
frayno idea why21:47
*** flynn378 <flynn378!sid63564@gateway/web/> has quit IRC21:47
*** zibri <zibri!~zibri@2a01:7e01::f03c:91ff:febb:9538> has quit IRC21:47
frayshould be hte other way around.. the command being run was  (long list).. error was (end)21:47
frayI don't know if that is produced in the code or in smart21:47
bluelightningin our code21:47
bluelightningthe utility of that list itself is questionable21:47
frayI suspect thiswas introduced in conversation ot the lib.oe version then21:48
fraythe lsit is needed..  it's stupid, but the number of questions I get from customers as "Why is XYZ failing, when I didn't ask for it"  (when it's explicitly in the list of packages you asked for)21:48
*** zibri <zibri!~zibri@2a01:7e01::f03c:91ff:febb:9538> has joined #yocto21:48
frayso thus, the list of explicitly asked for packages is there...21:48
*** smurray <smurray!sid98062@gateway/web/> has joined #yocto21:49
fraybut I agree, ordering is backwards..21:49
frayerror should be last21:49
fraythe rest is simply diagnostics21:49
Ulfalizerfray: maybe i'm blind, but it doesn't seem to explain what that list is either. it just dumps it out.21:49
frayit's a list of everything user asked for21:50
fraythat simple21:50
Ulfalizerdon't think that'll be obvious to people21:50
fraylast time I made any substantial changes was when this was still shell code..21:50
frayit used to have text around it to indicate just that21:50
fraya lot of things disappeared when it went to python21:50
*** rob-oi-ma <rob-oi-ma!sid155560@gateway/web/> has joined #yocto21:51
fraywith that said, I don't know if this is in smart or not.. but I don't rmember it being there..21:51
bluelightningfray: erm, the list is the list of all packages in the feeds, not the list that the user has requested for the image21:51
a1cypherlist is fine, but maybe put some line breaks in there so that its one package per line or something21:51
fraybluelighting, then the list has changed21:52
Ulfalizer"This is the set of packages that was requested to be installed into the root filesystem. Note that some of these packages might have been pulled in via dependencies between packages even if they were not explicitly requested."21:52
frayit was originally the list of the items the user asked for21:52
Ulfalizeri'd add something like that. makes it clear.21:52
Ulfalizerif that's what it is21:52
bluelightningsomeone needs to check the code21:52
fray        bb.note("Installing the following packages: %s" % ' '.join(pkgs))21:53
fraythat is the list I was referring to21:53
frayso it si still in the code21:53
bluelightningthat's not the list I'm referring to ;)21:53
frayyes, but that is what should have been printed -before- the error message21:53
bluelightningerr_msg += " ".join(self.fullpkglist)21:54
fray(which I suspect it is in the log)21:54
bluelightningthat's what makes it excessive21:54
fraymake it a '=+' instead and you'd at least get the order right21:54
bluelightningwhy do we need that list though? especially given it's not the list you're referring to21:55
frayya.. this is all from the original conversion of the shell code to the python code..21:55
frayI'm saying there are at least two problems here..21:55
bluelightningby all means write it to a file so you can look at it, if it helps debugging21:55
frayproblem 1..  the error message should be last..21:55
fray=+ would fix that21:55
frayproblem 2... there is too much crap there for most people21:55
frayas long as the error message is last, and some qualification of what that list is.. I don't care either way if it's presented or not.. but as is, nobody knows what the list is anymore21:56
*** flynn378 <flynn378!sid63564@gateway/web/> has joined #yocto21:56
Ulfalizerproblem 3: it ought to to give more details about what that list is, imo. the explicitly requested packages? all packages? what does the thing after the @ refer to?21:56
frayyes.. I consider that part of 2..21:57
fraythe log itself does list what was being attempted..21:57
frayit's only on error that is generated.. and it should be generated as "available packages" \n "error message"21:57
*** rburton <rburton!> has quit IRC21:57
fraylittlery should say something about "available packages"21:57
fray-                            err_msg += " ".join(self.fullpkglist)21:58
fray+                            err_msg =+ "List of available packages: " + " ".join(self.fullpkglist)21:58
fraythere that would be a reasonable simple change..21:58
bluelightningif we're making a change, we should drop that list21:58
*** marka_home <marka_home!> has quit IRC21:58
frayso the question is, do we have a simple way for a user to know what packages are listed in the smart database?  if not, we need to dump diagnostics "somewhere" in this type of failure21:59
frayand if it's not in the main log, then at least a message to indicate where it was dumped21:59
*** berton <berton!~fabio@> has quit IRC22:00
*** bfederau <bfederau!> has quit IRC22:01
*** fmeerkoetter <fmeerkoetter!> has quit IRC22:01
*** fmeerkoetter <fmeerkoetter!> has joined #yocto22:01
*** bfederau <bfederau!> has joined #yocto22:01
* Ulfalizer dislikes the term "base feed"22:01
bluelightningI'm not sure what that means either, if anything22:02
Ulfalizer"'avahi' not found among the packages that were built" seems much more concrete22:02
Ulfalizeror something like that22:02
frayit could have been built.. and not loaded into the feeds..22:03
fray-                    err_msg = '%s not found in the base feeds (%s).\n' % \22:04
fray+                    err_msg = '%s not found in the deploy feeds (%s).\n' % \22:04
fraythat better?22:04
Ulfalizermight be guessable that the package also needs to be copied into some common area after it's built though22:04
*** mortderire <mortderire!~rkinsell@> has quit IRC22:04
fraypackages that were built really has no meaning here..22:04
Ulfalizerand registered22:04
fraydeploy is where the stuff ends up once constructed.. the stuff in deploy is used to generate the feeds22:04
Ulfalizeri guess i just dislike the term "feed" :P22:05
frayme looks at others for that..22:05
Ulfalizerbut whatevz22:05
frayfeed is not my term22:05
frayI'd call it a package repository myself -- but that is not the OE term for that.. it's a feed.. (and apparently it has been called a feed for a very long time, much longer then the Yocto Project has been around)22:07
bluelightningfeed is really the right term here, other issues aside22:07
*** mortderire <mortderire!~rkinsell@> has joined #yocto22:07
Ulfalizeryeah, i'd go for package repository too22:07
frayother option w/ that part of the message, is just say  "%s not found in the feeds (%s).\n"22:08
frayoriginally it was expected that the user could add additional feeds (outside of the build system) for the image install.. but I don't think that was ever implemented nor will it likely be at this point22:08
bluelightningwe probably ought to add a hint for the user as to the cause, which is almost always the scenario that prompted this whole thing (recipe claimed to package somehting and didn't)22:08
Ulfalizerregardless of what the established terminology is, i suspect many of the people that would be helped the most by that message have a very vague idea of what a "feed" is22:09
frayahh I know why it said 'base'22:10
fraythere are two different error message paths:22:10
frayif you select 'lib32-bash', the message is  not found in the lib32 feeds (%s)...22:11
frayotherwise it's 'base'..22:11
fraywhat else do we call the non-multilib.. thus it was 'base'22:11
kergothI'd just say 'lib32 feeds' and 'feeds', and know that the lack of lib32 indicates not lib32, but *shrug*22:12
*** alimon1 <alimon1!~alimon@> has quit IRC22:13
Ulfalizer"'%s' not found in the package feeds (found in %s). Make sure that some recipe builds this package." would give a tiny hint at least22:13
Ulfalizerif references to the manual are okay, there's stuff to link there too22:14
Ulfalizerkergoth: yeah, that seems better22:15
Ulfalizerit's not clear what "base" means (obviously, from earlier discussion :P)22:15
frayUgh.. no sorry premature pastebin.. ;)22:19
*** a1cypher <a1cypher!> has quit IRC22:24
*** manuel_ <manuel_!~manuel@> has quit IRC22:26
fraythere we go...22:26
fraythat was what I was trying to paste before22:26
frayorder is now more logical22:26
frayand if you look at the logs it all still makes sense..22:27
Ulfalizer"'%s' not found in the package feeds (found in %s). Make sure that some recipe builds this package. Note that a package declared in PACKAGES within a recipe will not get built if it turns out empty (unless ALLOW_EMPTY_<pkg> = "1" is used)."22:27
Ulfalizerhow about that version? that also explains what the problem might be (if i've understood it correctly).22:27
*** ant_home <ant_home!> has quit IRC22:32
*** igor3 <igor3!~igor@> has quit IRC22:33
Ulfalizer"'ahavi' not found in the package feeds (qemux86 i586 x86 noarch any all - found in /.../tmp/deploy/rpm). Make sure that..."22:35
Ulfalizeri think that'd help a lot more people diagnose the issue themselves22:35
*** dreyna <dreyna!> has quit IRC22:36
Ulfalizerfray: opinions?22:38
Ulfalizeri'd add a "-" before the "in", to make it clear that it's not part of the list22:41
Ulfalizerand also the rest of the hint :P22:42
frayI'm not sure how i feel about that.. either way22:42
Ulfalizerlgtm (sans hint)22:44
fraythere sent to the oe-core list..22:47
Ulfalizerahhh... didn't notice that you added the hint :)22:48
Ulfalizermaybe it could be on the same line22:48
Ulfalizerbut too late :P22:48
frayit doesn't look good on one line, you end up with the same jumbled mess as the one line list of all packages22:49
Ulfalizeryeah, it might just be me being blind22:49
Ulfalizer(not for real)22:49
frayit's hit the list.. feel free to ack it22:50
fraydamned thunderstorm keeps knocking me offline for 2-10 minutes at a time..22:50
*** nighty <nighty!> has quit IRC22:51
*** bbhoss <bbhoss!sid18216@gateway/web/> has quit IRC22:54
*** mjl <mjl!sid16781@gateway/web/> has quit IRC22:56
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto22:56
*** bbhoss <bbhoss!sid18216@gateway/web/> has joined #yocto22:58
*** mjl <mjl!sid16781@gateway/web/> has joined #yocto22:59
frayha someone asked to have a meeting with me, I said sure.. meeting time comes and all the invite says is "Lets meet".. no dial in info, urls, etc.. ;)23:01
fraynot sure if the meeting person forgot the info, or if exchange ate it23:01
fray(I really hate exchange)23:01
Ulfalizersounds nice depending on the meeting23:03
*** istarilucky <istarilucky!~rlucca@> has left #yocto23:07
*** manuel_ <manuel_!> has joined #yocto23:10
*** sujith_h <sujith_h!~toaster@kde/developers/sujithh> has quit IRC23:17
*** behanw <behanw!uid110099@gateway/web/> has quit IRC23:19
*** sujith_h <sujith_h!~toaster@> has joined #yocto23:20
Ulfalizerfray: one more unimportant nit that i feel bad for sending a mail for: lines do not to be escaped with \ within ().23:22
Ulfalizerurr, *newlines23:23
frayI've had hit and miss experiencing not escaping it23:23
Ulfalizerthe rule is that newlines don't terminate python statements within braces23:24
Ulfalizeroutside braces, newlines need to be escaped though23:24
fraythats what I thought, but I've still had parse issues in the past.. to the point where I always just add the escapes..23:25
Ulfalizerurr, *brackets :P23:25
Ulfalizerenglish fail23:25
frayI knew what you meant.. ;)23:25
*** sameo <sameo!~samuel@> has quit IRC23:27
*** sjolley <sjolley!sjolley@nat/intel/x-blhgvsghkjakauuv> has joined #yocto23:31
*** tlab_ <tlab_!~tlab@> has joined #yocto23:32
*** tlab <tlab!~tlab@> has quit IRC23:35
-YoctoAutoBuilder- build #924 of nightly-qa-systemd is complete: Success [build successful] Build details are at
*** khem <khem!~khem@unaffiliated/khem> has quit IRC23:42
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto23:45
*** manju <manju!95c73efe@gateway/web/freenode/ip.> has joined #yocto23:45
manjui am using recipetool to generate bbappend, it always parses the recipe every single time. is there a way to store the parsing of bb file so that the second time it is faster?23:48
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC23:50
*** nighty <nighty!> has joined #yocto23:50
*** khem <khem!~khem@unaffiliated/khem> has quit IRC23:54
*** manuel_ <manuel_!> has quit IRC23:55
*** manuel_ <manuel_!> has joined #yocto23:56
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto23:57

Generated by 2.11.0 by Marius Gedminas - find it at!