Wednesday, 2014-04-09

*** trollixx <trollixx!> has left #yocto00:01
*** trollixx <trollixx!> has joined #yocto00:01
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC00:02
*** munch <munch!> has quit IRC00:04
-YoctoAutoBuilder- build #38 of nightly-fsl-ppc-lsb is complete: Success [build successful] Build details are at
*** rburton <rburton!> has quit IRC00:13
*** rburton <rburton!> has joined #yocto00:14
*** sjolley <sjolley!~sjolley@> has joined #yocto00:16
*** Hodapp <Hodapp!~hodapp@> has left #yocto00:20
*** rburton <rburton!> has quit IRC00:23
*** rburton <rburton!> has joined #yocto00:24
*** maxtothemax <maxtothemax!maxtothema@nat/intel/x-kmustbmvwlvlrehg> has quit IRC00:33
*** yenal <yenal!~yenal@unaffiliated/yenal> has quit IRC00:50
*** neabax <neabax!~neabax@> has joined #yocto00:51
*** rburton <rburton!> has quit IRC00:57
*** rburton <rburton!> has joined #yocto00:58
*** mulhern <mulhern!~mulhern@> has joined #yocto00:59
*** sameo <sameo!~samuel@> has quit IRC01:03
-YoctoAutoBuilder- build #37 of nightly-fsl-ppc is complete: Success [build successful] Build details are at
*** rburton <rburton!> has quit IRC01:33
*** rburton <rburton!> has joined #yocto01:34
*** neabax <neabax!~neabax@> has quit IRC01:37
*** rburton <rburton!> has quit IRC01:42
*** rburton <rburton!> has joined #yocto01:43
*** Squix <Squix!> has joined #yocto01:50
*** rburton <rburton!> has quit IRC01:52
*** behanw__ is now known as behanw01:53
*** Squix <Squix!> has quit IRC01:55
*** Squix <Squix!> has joined #yocto01:56
*** rburton <rburton!> has joined #yocto01:57
*** Squix <Squix!> has quit IRC02:01
*** Squix <Squix!> has joined #yocto02:02
*** tom_say <tom_say!~tom_say@2605:6000:1403:19:223:54ff:fe82:18cc> has quit IRC02:08
*** rburton <rburton!> has quit IRC02:31
*** rburton <rburton!> has joined #yocto02:32
*** Squix <Squix!> has quit IRC02:39
*** Squix <Squix!> has joined #yocto02:40
-YoctoAutoBuilder- build #38 of nightly-world is complete: Success [build successful] Build details are at
*** wgao <wgao!~wgao@> has quit IRC02:54
*** Squix <Squix!> has quit IRC02:56
*** Squix <Squix!> has joined #yocto02:56
*** rburton <rburton!> has quit IRC03:04
*** rburton <rburton!> has joined #yocto03:10
*** wgao <wgao!~wgao@> has joined #yocto03:13
*** rburton <rburton!> has quit IRC03:19
*** rburton <rburton!> has joined #yocto03:20
*** rburton <rburton!> has quit IRC03:29
*** rburton <rburton!> has joined #yocto03:30
*** rburton <rburton!> has quit IRC03:38
*** rburton <rburton!> has joined #yocto03:39
*** Jim__ <Jim__!411ad795@gateway/web/freenode/ip.> has joined #yocto03:40
*** Jim__ <Jim__!411ad795@gateway/web/freenode/ip.> has quit IRC03:44
*** rburton <rburton!> has quit IRC04:13
*** rburton <rburton!> has joined #yocto04:14
*** e8johan <e8johan!> has joined #yocto04:20
*** e8johan <e8johan!> has joined #yocto04:22
*** rburton <rburton!> has quit IRC04:23
*** rburton <rburton!> has joined #yocto04:24
*** rburton <rburton!> has quit IRC04:57
*** rburton <rburton!> has joined #yocto04:57
*** agust <agust!> has joined #yocto05:03
*** roxell <roxell!~roxell@linaro/roxell> has quit IRC05:05
*** roxell <roxell!> has joined #yocto05:06
*** roxell <roxell!~roxell@linaro/roxell> has joined #yocto05:06
*** roric <roric!> has joined #yocto05:27
*** rburton <rburton!> has quit IRC05:33
*** rburton <rburton!~rburton@> has joined #yocto05:38
*** rburton <rburton!~rburton@> has quit IRC05:47
*** rburton <rburton!> has joined #yocto05:48
*** kbart <kbart!~KBart@> has joined #yocto05:54
*** Jefro <Jefro!> has joined #yocto06:05
-YoctoAutoBuilder- build #37 of nightly-fsl-arm is complete: Success [build successful] Build details are at
*** Jefro <Jefro!> has quit IRC06:21
*** rburton <rburton!> has quit IRC06:21
*** rburton <rburton!~rburton@> has joined #yocto06:22
*** neabax <neabax!~neabax@> has joined #yocto06:23
*** Jefro <Jefro!> has joined #yocto06:24
*** roric <roric!> has quit IRC06:41
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC06:48
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto06:49
*** rburton <rburton!~rburton@> has quit IRC06:55
*** rburton <rburton!> has joined #yocto06:55
*** kroon <kroon!~kroon@> has joined #yocto06:58
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto06:59
*** jbrianceau_away is now known as jbrianceau06:59
*** zeeblex <zeeblex!~apalalax@> has joined #yocto07:00
*** eballetbo <eballetbo!> has joined #yocto07:03
*** e8johan_ <e8johan_!> has joined #yocto07:03
*** e8johan <e8johan!> has quit IRC07:04
*** arky <arky!~arky@> has joined #yocto07:06
*** lsb_tester <lsb_tester!~milan@> has joined #yocto07:07
lsb_testerI am unable to install libqtopengl4 package to roofs image even with IMAGE_INSTALL_append. the RPM is available under tmp/deploy/rpm. Any idea, what's wrong ?07:10
*** Squix <Squix!> has quit IRC07:11
*** roric <roric!> has joined #yocto07:20
*** ant_work <ant_work!> has joined #yocto07:21
*** kroon <kroon!~kroon@> has quit IRC07:26
*** kroon <kroon!~kroon@> has joined #yocto07:28
*** lsb_tester <lsb_tester!~milan@> has quit IRC07:29
*** rburton <rburton!> has quit IRC07:29
*** elmi82 <elmi82!> has joined #yocto07:30
*** AlexG <AlexG!~ageorges@> has joined #yocto07:31
*** rburton <rburton!> has joined #yocto07:31
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:37
*** florian_kc is now known as florian07:37
*** yenal <yenal!~yenal@unaffiliated/yenal> has joined #yocto07:41
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has joined #yocto07:41
*** Jefro <Jefro!> has quit IRC07:51
*** jvuo <jvuo!> has joined #yocto07:51
*** diego_r <diego_r!> has joined #yocto07:52
*** g1zer0 <g1zer0!> has quit IRC07:58
*** g1zer0 <g1zer0!> has joined #yocto07:59
*** Rootert <Rootert!> has quit IRC08:04
*** RagBal <RagBal!> has quit IRC08:04
*** rburton <rburton!> has quit IRC08:04
*** rburton <rburton!> has joined #yocto08:04
*** sameo <sameo!samuel@nat/intel/x-wvgzossohexzjcjt> has joined #yocto08:10
*** JimBaxter <JimBaxter!> has joined #yocto08:11
*** rburton <rburton!> has quit IRC08:13
*** RagBal <RagBal!> has joined #yocto08:14
*** rburton <rburton!> has joined #yocto08:14
*** Rootert <Rootert!> has joined #yocto08:14
*** tom_say <tom_say!~tom_say@2605:6000:1403:19:223:54ff:fe82:18cc> has joined #yocto08:18
*** Jin|away is now known as Jin^eLD08:27
*** beaver_545 <beaver_545!~stuart@> has joined #yocto08:28
*** dv_ <dv_!> has joined #yocto08:36
*** belen <belen!Adium@nat/intel/x-dueuhwgefmahjput> has joined #yocto08:45
*** daemonna <daemonna!3ea85ce3@gateway/web/freenode/ip.> has joined #yocto08:46
daemonnahi, anyone here working with ADT installer?08:47
*** neabax <neabax!~neabax@> has quit IRC09:07
*** akbennett <akbennett!akbennett@linaro/akbennett> has quit IRC09:09
*** neabax <neabax!~neabax@> has joined #yocto09:10
*** akbennett <akbennett!akbennett@linaro/akbennett> has joined #yocto09:21
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto09:34
*** daemonna <daemonna!3ea85ce3@gateway/web/freenode/ip.> has quit IRC09:34
*** neabax <neabax!~neabax@> has quit IRC09:37
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC09:38
*** kevin_t <kevin_t!~Thunderbi@> has quit IRC09:41
*** kevin_t <kevin_t!~Thunderbi@> has joined #yocto09:43
*** kroon <kroon!~kroon@> has quit IRC09:44
Xzare there any plans to bump openssl version in dora?09:55
XzI just spotted patch on dylan to fix heartbleed on old version (1.0.1e)09:55
rburtonXz: the dora patches were sent out last night10:02
*** kevin_t <kevin_t!~Thunderbi@> has quit IRC10:05
*** tobiash <tobiash!> has quit IRC10:08
*** tobiash <tobiash!> has joined #yocto10:09
*** bluelightning <bluelightning!~paul@> has joined #yocto10:14
*** bluelightning <bluelightning!~paul@> has quit IRC10:14
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:14
*** elmi82 <elmi82!> has quit IRC10:14
*** elmi82 <elmi82!> has joined #yocto10:14
bluelightningmorning all10:21
*** mulhern <mulhern!~mulhern@> has joined #yocto10:27
*** RP <RP!> has quit IRC10:27
*** mulhern <mulhern!~mulhern@> has quit IRC10:27
*** RP <RP!> has joined #yocto10:41
*** kroon <kroon!> has joined #yocto10:45
*** yenal <yenal!~yenal@unaffiliated/yenal> has quit IRC11:02
*** AlexG1 <AlexG1!~ageorges@> has joined #yocto11:02
*** AlexG <AlexG!~ageorges@> has quit IRC11:04
*** yenal <yenal!~yenal@unaffiliated/yenal> has joined #yocto11:15
*** g1zer0 <g1zer0!> has quit IRC11:15
*** madhu1 <madhu1!~madhu@> has joined #yocto11:16
*** kevin_t <kevin_t!~Thunderbi@> has joined #yocto11:16
*** tasslehoff <tasslehoff!~tasslehof@> has joined #yocto11:17
andheanyone got suggestion on how to write SRC_URI to download from
*** madhu1 <madhu1!~madhu@> has quit IRC11:21
*** zeeblex <zeeblex!~apalalax@> has left #yocto11:27
*** g1zer0 <g1zer0!> has joined #yocto11:28
*** AlexG1 <AlexG1!~ageorges@> has quit IRC11:31
*** AlexG <AlexG!ageorges@nat/intel/x-kxvibanblvtptben> has joined #yocto11:31
*** madhu2 <madhu2!~madhu@> has joined #yocto11:37
xerentany ideas on how to force a package to be rebuilt (don't cache it) ? I have some packages that are built in different configurations depending on platform, but when I build for another platform, the cached packages from the wrong platform are used. both platforms use the same recipe.11:39
*** madhu2 <madhu2!~madhu@> has quit IRC11:41
andhexerent: "bitbake <package> -c clean" it after build / before rebuild11:42
xerentthanks :)11:43
kroon-c cleansstate11:50
*** sameo <sameo!samuel@nat/intel/x-wvgzossohexzjcjt> has quit IRC11:50
*** sameo <sameo!~samuel@> has joined #yocto11:50
*** Denwid <Denwid!c2cc4226@gateway/web/freenode/ip.> has joined #yocto11:55
bluelightningxerent: that's an indicator that the right variables are not getting into signatures for the appropriate task11:57
bluelightningxerent: have you set PACKAGE_ARCH = "${MACHINE_ARCH}" (assuming that the recipe is machine-specific)?11:57
Denwidlol sorry :)12:01
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto12:05
DenwidI would like to submit a small patch to the yocto-docs, where should I send it preferrably?12:07
*** jvuo <jvuo!> has left #yocto12:07 ?12:08
bluelightningDenwid:, and CC Scott Rifenbark <> as well12:10
bluelightningDenwid: if you could ensure [yocto-docs] is in the subject that would be great also12:11
DenwidCool, thanks! I will do that12:11
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC12:14
*** jkridner <jkridner!> has joined #yocto12:14
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto12:14
*** arky <arky!~arky@> has quit IRC12:16
*** jackmitchell <jackmitchell!> has quit IRC12:17
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC12:19
*** mago_ <mago_!> has joined #yocto12:20
*** gmacario <gmacario!> has joined #yocto12:23
*** gmacario1 <gmacario1!> has quit IRC12:25
*** jackmitchell <jackmitchell!> has joined #yocto12:25
*** gmacario1 <gmacario1!> has joined #yocto12:26
*** gmacario <gmacario!> has quit IRC12:27
xerentbluelightning: the architecture is one and the same for both platforms. the different platforms have similar CPU's, etc, but differ in other terms12:33
*** arky <arky!~arky@> has joined #yocto12:33
xerentandhe: it sure rebuilds the packages after I cleaned them, but bitbake won't bake me a new image because it thinks the packages haven't changed.12:34
bluelightningxerent: right, but if this recipe is somewhere where those differences are taken into account then you should set PACKAGE_ARCH = "${MACHINE_ARCH}" within the recipe12:34
xerentI can't find any mention of that variable in the reference manual12:37
xerentmachine_arch that is12:37
bluelightningxerent: you're right, I made a note12:37
bluelightningthere are lots of examples where we use that within the metadata, but then there's no way for you to know where to look for those12:38
xerentI did know where to look: here, asking you ;)12:38
bluelightningwell it's true I don't mind helping people12:39
xerentand a fine job you do as well12:39
bluelightningI try12:39
xerentnow if the architectures for my different images are one and the same, how will setting the package architecture in the package recipe help?12:40
bluelightningxerent: when you say architectures, what do you mean?12:40
bluelightningis the MACHINE value different or the same?12:40
*** kevin_t <kevin_t!~Thunderbi@> has quit IRC12:40
xerent"For example, packages can exist for the i586 or qemux86 architectures" <- Both images are built for i68612:41
*** kevin_t <kevin_t!~Thunderbi@> has joined #yocto12:41
xerentmachine names are different12:41
xerentas in we get images deployed to tmp/deploy/images/foo/ and tmp/deploy/images/bar/ depending on if we build a foo or a bar image12:42
bluelightningxerent: right, but those images comprise no-architecture ("all") arch-specific ("i686") and machine-specific ("qemux86") packages12:42
bluelightningPACKAGE_ARCH is how the system knows which one the recipe should go into12:43
bluelightningand hence when the recipe needs rebuilding12:43
bluelightning(and PACKAGE_ARCH = "${MACHINE}" also means it'll go into a separate workdir for each machine)12:43
xerentdo I put it into the package recipes or into the image recipe?12:47
xerentfor each package I presume12:48
bluelightningthe package recipes that are machine-specific yes12:48
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto12:49
bluelightningthe PACKAGE_ARCH for image recipes is already "${MACHINE_ARCH}" (and wouldn't ever be anything else - assuming they're the rootfs they're always going to be machine-specific)12:49
xerentok, this seems to work now. thanks again for your insights12:50
xerentdo you get paid for this?12:50
xerentyou should12:50
bluelightningI get paid to work on the Yocto Project yes12:51
bluelightningI wouldn't say I get paid to do support, that's something I do because I think it's important ;)12:51
xerentI get paid to ask stupid questions ;)12:51
*** sroy_ <sroy_!> has joined #yocto12:51
*** tasslehoff <tasslehoff!~tasslehof@> has quit IRC12:58
*** arky <arky!~arky@> has quit IRC12:59
mago_isn't poky built on openembedded core?13:07
ndecmago_: yes it is.13:08
ndecpoky is a reference implementation distro13:08
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC13:08
mago_shouldn't there be a layer called openembedded-core somewhere in my poky dir then?13:09
ndecthe oe-core layer is called 'meta'13:09
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto13:09
*** arky <arky!~arky@> has joined #yocto13:11
mago_ah, i see13:12
*** e8johan_ <e8johan_!> has quit IRC13:14
mago_if I were to create a new distro, which shall support two custom hardware boards, should I start from yocto or base my work on openembedded-core? my two boards are based on SoCs which are supported in 2 different BSP layers already, but I need to modify the kernel and add new boards etc. Do I need to unify the kernel from both of these BSP layers and create my own kernel recipe?13:15
ndecmago_: it depends ;-) if you make your own distro as an 'end product', i would tend to recommend to use oe-core.. but it's more a personal preference.. if you simply need to build rootfs for development and the end goal is not the distro, then poky is fine.13:26
*** belen <belen!Adium@nat/intel/x-dueuhwgefmahjput> has quit IRC13:28
mago_okay. well, i would like to generate u-boot, kernel and rootfs and distribute those. I would also like to provide an SDK package and some means for users to install customized applications on their boards. In the long term, I would like to be able to distribute the whole build system so that advanced users may add custom layers etc13:30
ndecmago_: i would personnally do it with oe-core... but you might want to hear from others too..13:33
rburtonyou can easily extend poky and tweak it, but poky is really just the confi/distro/poky.conf file so its trivial to copy the bits from that which are interesting and build your own13:36
mago_ok. still, the problem with the kernel remains. how would you solve it? I guess I could create an image recipe which relies on PREFERRED_PROVIDER to select virtual/kernel provider differently for each type of board? so when I build boardX, it selects kernelX to provide virtual/kernel and kernelY when I build boardY. Or is the preferred solution to create a single kernel which is capable of supporting both boards?13:36
rburtonpoky really is just an example of building a distro from the pieces and something that QA use to test13:36
rburtonmago_: both are acceptable13:36
rburtonmago_: yocto's kernel builds for everything, but you can have preferred-providers per machine if you want13:36
mago_rburton, what do you mean "builds for everything"?13:37
*** wgao <wgao!~wgao@> has quit IRC13:37
rburtonlinux-yocto can be build for all machines that oe-core/poky support13:37
rburtonand all the ones that meta-intel builds too13:38
*** wgao <wgao!~wgao@> has joined #yocto13:38
rburtonyour choice really13:38
mago_and I can extend linux-yocto with support for my specific boards?13:39
rburtonsome consider linux-yocto to be overly complex, but it does let you manage numerous machines and configurations relatively easy13:40
mago_how does the recipe handle that? do i need to supply it with patches? or in what format do i input my changes to the yocto kernel?13:40
*** wgao_ <wgao_!~wgao@> has joined #yocto13:40
*** wgao <wgao!~wgao@> has quit IRC13:40
rburtoni suggest you look at the manual for it, on the yoctoproject site13:41
*** kroon <kroon!> has quit IRC13:43
*** oneQubit <oneQubit!> has quit IRC13:45
*** oneQubit <oneQubit!> has joined #yocto13:45
*** AlexG1 <AlexG1!~ageorges@> has joined #yocto13:50
*** AlexG <AlexG!ageorges@nat/intel/x-kxvibanblvtptben> has quit IRC13:52
*** codinho_ <codinho_!> has joined #yocto13:52
*** AlexG1 <AlexG1!~ageorges@> has quit IRC13:53
*** AlexG <AlexG!ageorges@nat/intel/x-wgihmxubeoyhdpsl> has joined #yocto13:54
*** reanguiano <reanguiano!> has quit IRC13:54
*** aragua <aragua!> has joined #yocto13:54
*** reanguiano <reanguiano!> has joined #yocto13:55
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mvbzpsmgotaayiae> has joined #yocto13:58
*** dlern <dlern!~dlerner@> has joined #yocto14:02
*** oneQubit <oneQubit!> has quit IRC14:05
AlexVaduvadid someone of you encountered a bug like this: "error: bad value (e5500) for -mtune= switch"14:07
AlexVaduvaI encounter it when trying to build the meta-fsl-ppc b4860qds-64 kernel.14:07
AlexVaduvaany suggestions?14:08
*** munch <munch!> has joined #yocto14:11
*** zeeblex <zeeblex!apalalax@nat/intel/x-txmgxeyaonmuxwyb> has joined #yocto14:17
*** belen <belen!~Adium@> has joined #yocto14:18
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC14:22
*** blloyd <blloyd!> has joined #yocto14:25
*** kbart <kbart!~KBart@> has quit IRC14:31
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto14:37
*** belen1 <belen1!~Adium@> has joined #yocto14:44
*** belen <belen!~Adium@> has quit IRC14:46
*** Denwid <Denwid!c2cc4226@gateway/web/freenode/ip.> has quit IRC14:46
*** aragua <aragua!> has quit IRC14:48
*** belen1 <belen1!~Adium@> has quit IRC15:00
*** g1zer0 <g1zer0!> has quit IRC15:00
*** roric <roric!> has quit IRC15:02
*** PlkMndy <PlkMndy!PulkoMandy@> has joined #yocto15:04
*** sjolley <sjolley!~sjolley@> has quit IRC15:09
*** seezer_ <seezer_!> has joined #yocto15:12
PlkMndyhi there, I'm having a strange problem with a yocto build, we build an ext3 and a tar.gz rootfs, the tar is good (I can boot it over NFS) but the ext3 is broken, it's missing the /etc dir, and many binaries are installed to / instead of /usr/bin, and probably there are more issues (and of course this doesn't boot)15:17
TuTizzhi all, what is the correct way to configure /etc/timezone?15:17
TuTizzadd tzdata to my image?15:17
PlkMndyI'm not sure how the archive and the ext3 fs could end up being different, any hint on how the ext3 image is built?15:17
seezer_anyone around using qttools from meta-qt5? i need "lrelease" as build time dep in my own recipe. qttools gets build without errors - but the files split into "qttools-tools" don't get installed into sysroot. calling for DEPENDS+=qttools-tools results in "nothing provides qttools-tools". any ideas?15:19
bluelightningseezer_: DEPENDS specifies build-time dependencies; I'm assuming qttools-tools is a runtime target so it's not valid there15:22
*** maxtothemax <maxtothemax!~maxtothem@> has joined #yocto15:22
bluelightningTuTizz: I believe so yes15:23
TuTizzbluelightning, ok ty15:23
bluelightningPlkMndy: which version of the build system are you using?15:23
PlkMndyI'm not sure, there are so much versions of everything. Does "yocto / poky / dora" answers this?15:25
*** yenal <yenal!~yenal@unaffiliated/yenal> has quit IRC15:26
rburtonyocto is the project, poky is a reference distribution, dora is a version :)15:26
bluelightningPlkMndy: I wonder if the filesystem is running out of space/ inodes and it's just not failing as it should15:27
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC15:28
PlkMndy[2698190.503065] EXT4-fs error (device loop0): ext4_iget:4207: inode #15236: block 1918989871: comm ls: invalid block15:29
seezer_bluelightning: ah you're right thanks.. qttools-native is what i was looking for15:29
PlkMndyI get this in the syslog if I mount the rootfs15:29
PlkMndydoesn't it recreate the rootfs from scratch at each build? do I need to clean something?15:30
*** elmi82 <elmi82!> has quit IRC15:34
bluelightningseezer_: right yes that sounds more like it15:36
*** sjolley <sjolley!~sjolley@> has joined #yocto15:37
bluelightningPlkMndy: you could try setting IMAGE_ROOTFS_EXTRA_SPACE to enlarge the image15:37
bluelightningPlkMndy: I would suggest having a look at tmp/work/<machine-arch>/<image>/1.0/temp/log.do_rootfs to see if there are any obvious errors15:38
PlkMndyI already have IMAGE_ROOTFS_EXTRA_SPACE = "50000" in the image recipe15:38
bluelightningah ok15:38
*** reallife <reallife!~reallife@> has quit IRC15:44
*** ant_work <ant_work!> has quit IRC15:44
seezer_bluelightning: yet i'm not quite sure how to use it from my application's build system.. i'm currently using $$[QT_INSTALL_BINS]/lrelease which resolves into "wrong" sysroot inside make.. do you happen to know how i could tackle that?15:45
Jin^eLDhmm, whats the correct way to provide "per machine" SRC_URIs? I thought it'd be enough to have a files/$MACHINE directory and put the stuff there15:45
*** reallife <reallife!> has joined #yocto15:45
bluelightningJin^eLD: that should work automatically, since FILESPATH gets expanded using OVERRIDES which includes ${MACHINE}15:46
bluelightningseezer_: we do have an OE_QMAKE_LRELEASE variable that points to the lrelease binary FWIW15:47
Jin^eLDbluelightning: would that also work with bbappend's? there is an original .bb which provides files/ntpd script, and in my bbappend I wanted to split that out into files/machine1/ntpd and filesl/machine2/ntpd and I ahve FILESEXTRAPATHS_prepend := "${THISDIR}/files:" set15:49
Jin^eLDbut in this constellation the original ntpd is taken, not the one from bbappend15:49
*** reallife <reallife!> has quit IRC15:50
*** JimBaxter <JimBaxter!> has quit IRC15:50
*** volker <volker!> has quit IRC15:51
*** reallife <reallife!> has joined #yocto15:51
bluelightningJin^eLD: it should, but which file is picked depends on the overrides used - if you look at log.do_fetch you can see exactly where it is looking for files15:54
seezer_bluelightning: i see.. but i don't have that in the run.do_compile.. is it something new or some kind of missconfiguration?15:54
bluelightningseezer_: are you using qmake / cmake or something else?15:55
seezer_bluelightning: qmake yes15:55
*** JimBaxter <JimBaxter!> has joined #yocto15:56
bluelightningseezer_: so there is code in meta/classes/qmake_base.bbclass which should hack the .pro file to point to at least the right executable name for lrelease15:56
bluelightningif you also patch them to not use $$[QT_INSTALL_BINS] I think it should then pick up the right binary just via PATH15:57
*** eballetbo <eballetbo!> has quit IRC15:58
kergothHmm, where's the log for postinst intercept failures?16:02
seezer_bluelightning: hm strange.. the path in run.do_compile doesn't include the qt5/ subdirectory in sysroots/x86_64/usr/bin16:02
kergothit mentions one, but doesn't say which one to look at16:02
*** AlexG <AlexG!ageorges@nat/intel/x-wgihmxubeoyhdpsl> has quit IRC16:03
*** zeeblex <zeeblex!apalalax@nat/intel/x-txmgxeyaonmuxwyb> has left #yocto16:03
*** dv_ <dv_!> has quit IRC16:06
*** kroon <kroon!> has joined #yocto16:06
Jin^eLDbluelightning: hmm, SRC_URI of the original recipe clearly mentions a file://ntpd, howver in log.do_fetch - I do not see this file, I do see some others though, that makes no sense...16:07
bluelightningseezer_: it could be that that's deliberate, I had assumed that those would be in /usr/bin16:13
bluelightningseezer_: worst case you could use sed to modify the .pro file in a do_configure_prepend() to point to ${OE_QMAKE_LRELEASE}16:14
*** belen <belen!Adium@nat/intel/x-mnugkxvjbzuefxjf> has joined #yocto16:14
bluelightningJin^eLD: that sounds strange, they should match up directly16:14
Jin^eLDbluelightning: yes... it is as if it is not in the SRC_URI at all, which makes totally no sense16:15
bluelightningJin^eLD: silly question, but you are looking at the right log.do_fetch - right?16:15
bluelightningi.e. one from the same build16:16
Jin^eLDbluelightning :) yeah I remember I had that problem once ;) I did -c devshell this time16:17
Jin^eLDand ntpd script is actually in the original recipe in the meta layers of OE, it should be there16:17
Jin^eLDlet's see what happens if I additionally add it to the SRC_URI in my bbappend16:24
*** dmoseley <dmoseley!> has joined #yocto16:27
*** dv__ <dv__!> has joined #yocto16:29
*** beaver_545 <beaver_545!~stuart@> has quit IRC16:30
seezer_bluelightning: problem is i don't have the OE_QMAKE_LRELEASE set here.. perhaps it's newer than my current head - i'll look into that, thank you very much16:30
Jin^eLDbluelightning: yep, after I added it additionally in my bbappend it worked.. really strange16:32
*** seezer_ <seezer_!> has quit IRC16:37
*** pev <pev!> has joined #yocto16:45
pevHi All, I've got a kernel recipe that *looks* like its stalling in fetch. Its supposed to just pull down a specific rev from git. I can clone the repo directly OK but when fetch looks stalled I cant see any temp download stuff under downloads. Is there any way to debug fetch better than "bitbake -v" which doesnt show anything?16:46
*** belen <belen!Adium@nat/intel/x-mnugkxvjbzuefxjf> has quit IRC16:48
*** belen <belen!~Adium@> has joined #yocto16:48
rburtonpev: use ps and see if there's a git fetch running16:49
Jin^eLDdss11 ist im yocto noch nicht wichtig16:52
Jin^eLDoops wrong window16:52
*** pidge <pidge!pidge@nat/intel/x-yzhgbhccfkpbrkpv> has joined #yocto16:56
pevrburton: Nope, none running frustratingly16:59
*** beaver_545 <beaver_545!> has joined #yocto17:02
pevrburton: No, i tell a lie...!17:03
*** e8johan <e8johan!> has joined #yocto17:09
*** Jefro <Jefro!> has joined #yocto17:11
PlkMndyhello again, regarding my fs corruptions issues, it looks like it's because I merged latest changes including
PlkMndyand this doesn't work right on an already existing image and corrupted it17:22
*** sameo <sameo!~samuel@> has quit IRC17:23
*** codinho_ <codinho_!> has quit IRC17:23
*** jbrianceau is now known as jbrianceau_away17:25
*** dv__ is now known as dv_17:25
-YoctoAutoBuilder- build #40 of buildtools is complete: Failure [failed BuildImages Publishing Artifacts] Build details are at
-YoctoAutoBuilder- build #39 of nightly-oecore is complete: Failure [failed BuildImages Running Sanity Tests Building Toolchain Images Building Toolchain Images_1] Build details are at
-YoctoAutoBuilder- build #40 of nightly-x86-64-lsb is complete: Failure [failed BuildImages BuildImages_1 Publishing Artifacts] Build details are at
-YoctoAutoBuilder- build #39 of nightly-x32 is complete: Failure [failed BuildImages Running Sanity Tests Running Sanity Tests_1] Build details are at
bluelightningPlkMndy: I wouldn't have thought the fact that there was anything existing should make a difference17:28
bluelightningPlkMndy: if you revert that patch does the problem go away?17:28
-YoctoAutoBuilder- build #39 of nightly-mips is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Building Toolchain Images Building Toolchain Images_1 Publishing Artifacts] Build details are at
PlkMndyyes, that was unexpected17:28
-YoctoAutoBuilder- build #39 of minnow-lsb is complete: Failure [failed BuildImages Publishing Artifacts] Build details are at
PlkMndywell, I found a solution, I added RM_OLD_IMAGE to my local.conf and that fixed it17:29
-YoctoAutoBuilder- build #38 of nightly-fsl-arm is complete: Failure [failed BuildImages Building Toolchain Images Building Toolchain Images_1 BuildImages_1 BuildImages_2 Publishing Artifacts] Build details are at
-YoctoAutoBuilder- build #40 of nightly-multilib is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Running Sanity Tests_1 BuildImages_2 Running Sanity Tests_2 BuildImages_3 Running Sanity Tests_3 BuildImages_4] Build details are at
PlkMndylooking at the script that generates the ext3 fs, it tries to create an empty image by dding from /dev/null to the last block of the image17:29
-YoctoAutoBuilder- build #38 of nightly-fsl-ppc is complete: Failure [failed BuildImages Building Toolchain Images Building Toolchain Images_1 Publishing Artifacts] Build details are at
PlkMndywhich creates an empty file of the right size if nothing exists, but doesn't clear an existing file17:29
-YoctoAutoBuilder- build #38 of nightly-x86 is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Building Toolchain Images Building Toolchain Images_1 Publishing Artifacts] Build details are at
PlkMndyand then, uses mkfs on that17:30
-YoctoAutoBuilder- build #20 of nightly-ipk is complete: Failure [failed BuildImages Running Sanity Tests Running Sanity Tests_1 Running Sanity Tests_2] Build details are at
-YoctoAutoBuilder- build #38 of nightly-ppc-lsb is complete: Failure [failed BuildImages BuildImages_1 Publishing Artifacts] Build details are at
-YoctoAutoBuilder- build #20 of nightly-rpm is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #20 of nightly-deb is complete: Failure [failed BuildImages Running Sanity Tests Running Sanity Tests_1 Running Sanity Tests_2] Build details are at
-YoctoAutoBuilder- build #38 of nightly-arm-lsb is complete: Failure [failed BuildImages BuildImages_1 Publishing Artifacts] Build details are at
PlkMndyso if the image is smaller than a previous version, there could still be data from the previous image at the end of the file, for example17:30
-YoctoAutoBuilder- build #38 of nightly-mips-lsb is complete: Failure [failed BuildImages BuildImages_1 Publishing Artifacts] Build details are at
bluelightningPlkMndy: I'm a little puzzled as to why it would be looking at an existing image file to be honest17:31
bluelightningPlkMndy: would you mind filing a bug for this?17:31
kergothIs Florin Sarbu on irc?17:31
PlkMndybluelightning: as far as I can tell, the filename for the image doesn't seem to use a timestamp, but I may be wrong17:32
bluelightningPlkMndy: that should just be a symlink though, created after the real image17:32
bluelightningif you mean the file in tmp/deploy anyway17:33
bluelightningor do you mean a different file?17:33
PlkMndyno, I mean that, but you're right17:35
*** e8johan <e8johan!> has quit IRC17:35
PlkMndyso I don't know how I ended up with persistent corruption on two different machines then17:36
*** belen <belen!~Adium@> has quit IRC17:36
bluelightningPlkMndy: I think the bottom line is this really shouldn't be failing anywhere17:36
bluelightningluckily the maintainer for the dora stable branch is the same person on that patch you linked, so if you can file a bug and add him (Robert Yang) on CC then he should be able to fix it17:37
* pidge kicks the autobuilder and hopes to not flood the channel again.17:38
*** diego_r <diego_r!> has quit IRC17:41
*** e8johan <e8johan!> has joined #yocto17:42
PlkMndybluelightning: I created an account at, but I'm not sure which component to put the report in?17:47
*** gmacario1 <gmacario1!> has quit IRC17:50
*** aarias <aarias!> has joined #yocto17:56
bluelightningPlkMndy: this would be OE-Core / Core17:59
*** aarias is now known as chesnut18:00
*** chesnut is now known as chestnut18:00
*** chestnut is now known as lemavo18:00
-YoctoAutoBuilder- build #41 of buildtools is complete: Success [build successful] Build details are at
*** aarias <aarias!> has joined #yocto18:01
yoctiBug 6141: normal, Undecided, Future, saul.wold, NEW , Rootfs ext3 filesystem was corrupt18:01
*** tobiash_ <tobiash_!> has joined #yocto18:03
*** tobiash <tobiash!> has quit IRC18:03
*** aarias <aarias!> has quit IRC18:08
*** neabax <neabax!~neabax@> has joined #yocto18:09
*** maxtothemax <maxtothemax!~maxtothem@> has quit IRC18:09
*** kroon <kroon!> has quit IRC18:13
kergothHmm, qemu-ppc crashes and burns trying to run the target binaries for p4080ds at do_rootfs time for the intercepts18:19
* kergoth digs18:19
*** kroon <kroon!> has joined #yocto18:22
*** seezer <seezer!quassel383@quassel/developer/seezer> has quit IRC18:24
*** seezer <seezer!~seezer@quassel/developer/seezer> has joined #yocto18:24
*** e8johan <e8johan!> has quit IRC18:24
*** daren <daren!ada07c69@gateway/web/freenode/ip.> has quit IRC18:26
*** maxtothemax <maxtothemax!maxtothema@nat/intel/x-efrmmcfevqsjakjh> has joined #yocto18:27
-YoctoAutoBuilder- build #40 of nightly-x32 is complete: Success [build successful] Build details are at
volker-yocto image without samba: 42.9M, image with samba 123.7M18:39
volker-I tried first to build samba4 myself. i gave up last night and use now 3.x from the meta-oe layer18:41
bluelightningsamba binaries are huge, yes18:41
bluelightninglast I checked it was a known problem upstream, with no plan to fix it18:42
bluelightningnot sure if samba4 fixes it, probably...18:42
volker-it looks also like the configure script in samba3 got highly modified to get it build18:42
volker-is there already a framework that cherry-picks recipes from other repositories?18:43
volker-what I do right now with samba is manually copying only the two required recipes into our internal SCM18:44
bluelightningthere's combo-layer:
bluelightningI'd be the first to admit it's a little bit fiddly though18:45
bluelightning(and I wrote the thing...)18:45
kergothi doubt that does the recipe level, though18:45
*** belen <belen!> has joined #yocto18:45
bluelightningkergoth: it's not turn-key for individual recipes, but it will at least keep a directory or a wildcard matching some files up-to-date for you18:46
bluelightningthe ideal case is just to re-use the entire layer18:46
volker-if i need more public recipes I might hack a small script, in the meantime I just do it manual. It's not complex18:46
volker-bluelightning: teh entire layer would be much more and you never know what other side effects it might have with a higher priority18:47
bluelightningvolker-: that's the other thing, if it's just a software layer it's supposed to have no side-effects other than adding recipes18:47
kergothI used to use a little class that copied a recipe and its associated files into another directory, to populate a layer that was a subset of another layer. but that's because we had no other option, pre-oe-core :)18:48
bluelightningthat's still not totally true for meta-oe unfortunately :/18:48
kergothnowadays layers should be fairly small and well behaved (one hopes)18:48
kergothindeed :\18:48
bluelightningmaybe we'll finally get the last piece tidied up in the next cycle18:48
volker-nothing wrong in how it is right now. I was just curious if someone did already something because it fit their own needs :)18:49
volker-everyone has different requirements :)18:49
kergothwe just pull in and lock down upstream layers18:49
kergothi expect htats what most do18:49
*** belen <belen!> has quit IRC18:49
bluelightningvolker-: this particular issue is one of my pet peeves, don't worry ;)18:50
kergothhey, there it is! i forgot it was in oe classic. yikes, i can't say that was the greatest code18:50
* kergoth shakes head18:50
volker-I don't know if you are familiar with Chef (deployment framework). What happend there is that every cookbook (more or less a recipe group for a single task like apache, nginx, userconf) got put into its own recipe and that a framework downloads them.18:50
volker-not what I talked about in my case, but a structure that is similar to yocto (so someone might be interested into the idea).18:51
kergothI think it'd be cool to have an apt-like tool that was backed by layer urls, which would "install" a recipe and its deps into a local project area, which could include fetch/unpack/patch, even, and then your builds would be against that18:51
kergothbut obviously such a thing doesn't exist today18:51
bluelightningkergoth: interesting idea18:54
*** belen <belen!> has joined #yocto18:54
kergothvolker-: that sounds rather painful to maintain :)18:54
bluelightningobviously something that makes maintenance harder would be a difficult sell18:55
volker-kergoth: yeah. build a tool around it that checks for differences once in a while ;-)18:55
kergothit doessound like combo-layer may be your best bet at this point, if not as is, then as a starting point18:55
volker-kergoth: I am force to use perforce and I want to have two recipes in our SCM to have it repeatable18:56
kergothI'd just import the entire layers, personally :) if the layers are well behaved, including them won't impact anything they shoudln't impact18:56
kergothand if they aren't well behaved, its a bug that should be fixed18:56
volker-on the other side, I need to keep track of our security anyway (see OpenSSL ;-)18:56
volker-The entire .git folder in meta-openembedded is 21M while I only need 1.2M from it (and ignore the missed history here)18:58
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:59
-YoctoAutoBuilder- build #21 of nightly-ipk is complete: Success [build successful] Build details are at
volker-yeah, the combo-layer looks interesting, but it really copies everything and not just a small selection19:03
kergoththat's what i said, and paul indicated that it can operate against a wildcard19:04
* kergoth shrugs19:04
kergothnever used it myself19:04
volker-the does not contain all layers from git.yoctoproject.org19:05
volker-why is that?19:05
kergothi doubt it was intentional, likely just an oversight19:06
kergothcould open a big in the yocto bugzilla about it, presumably19:06
*** PlkMndy <PlkMndy!PulkoMandy@> has left #yocto19:08
*** smartin_ <smartin_!> has joined #yocto19:15
*** kroon <kroon!> has quit IRC19:16
*** wgao_ <wgao_!~wgao@> has quit IRC19:18
*** wgao_ <wgao_!~wgao@> has joined #yocto19:18
*** wgao__ <wgao__!~wgao@> has joined #yocto19:20
*** wgao_ <wgao_!~wgao@> has quit IRC19:24
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC19:25
*** belen <belen!> has quit IRC19:25
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has quit IRC19:27
*** wgao__ <wgao__!~wgao@> has quit IRC19:28
*** AlexG <AlexG!42f95158@gateway/web/freenode/ip.> has joined #yocto19:28
*** wgao__ <wgao__!~wgao@> has joined #yocto19:28
kergothhey look, i reproduced the NameError: global name 'd' is not defined bug again19:30
kergothmaybe i can finally fix that19:30
*** sgw_ <sgw_!> has quit IRC19:30
*** wgao__ <wgao__!~wgao@> has quit IRC19:31
*** wgao__ <wgao__!~wgao@> has joined #yocto19:31
-YoctoAutoBuilder- build #21 of nightly-rpm is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #21 of nightly-deb is complete: Success [build successful] Build details are at
*** wgao__ <wgao__!~wgao@> has quit IRC19:37
*** wgao__ <wgao__!~wgao@> has joined #yocto19:37
*** wgao__ <wgao__!~wgao@> has quit IRC19:39
*** wgao__ <wgao__!~wgao@> has joined #yocto19:39
*** wgao__ <wgao__!~wgao@> has quit IRC19:41
*** wgao_ <wgao_!~wgao@> has joined #yocto19:41
*** wgao_ <wgao_!~wgao@> has quit IRC19:43
*** wgao_ <wgao_!~wgao@> has joined #yocto19:43
*** wgao__ <wgao__!~wgao@> has joined #yocto19:53
*** joeythesaint <joeythesaint!~jjm@> has quit IRC19:53
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto19:54
*** jbrianceau_away is now known as jbrianceau_home19:54
*** gmacario <gmacario!> has joined #yocto19:54
*** wgao__ <wgao__!~wgao@> has quit IRC19:55
*** wgao__ <wgao__!~wgao@> has joined #yocto19:55
*** wgao_ <wgao_!~wgao@> has quit IRC19:56
*** crazyl3gs <crazyl3gs!~AndChat52@> has joined #yocto19:59
*** AlexG <AlexG!42f95158@gateway/web/freenode/ip.> has quit IRC19:59
*** crazyl3gs <crazyl3gs!~AndChat52@> has quit IRC20:00
*** AlexG <AlexG!~AndChat52@> has joined #yocto20:00
*** wgao__ <wgao__!~wgao@> has quit IRC20:01
-YoctoAutoBuilder- build #40 of minnow-lsb is complete: Success [build successful] Build details are at
*** wgao__ <wgao__!~wgao@> has joined #yocto20:02
-YoctoAutoBuilder- build #41 of nightly-multilib is complete: Success [build successful] Build details are at
*** wgao__ <wgao__!~wgao@> has quit IRC20:03
-YoctoAutoBuilder- build #39 of nightly-fsl-ppc is complete: Success [build successful] Build details are at
*** arky <arky!~arky@> has quit IRC20:13
*** e8johan <e8johan!> has joined #yocto20:15
*** rburton <rburton!> has quit IRC20:15
*** rburton <rburton!> has joined #yocto20:16
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:19
*** sroy_ <sroy_!> has quit IRC20:25
*** crankDeric <crankDeric!~deric@> has joined #yocto20:26
crankDericI've got a question about pulseaudio, if I add pulseaudio to my build in conf/local.conf should I expect to see all the libs in the recipe?  I appear to be missing and a few others, they show up in the sysroot on the build machine, but not in the sdcard image, any idea why?20:27
volker-crankDeric: don't know how it is with pulseaudio, but the kernel does not install all the kernel modules on default it builds (at least not with the small default distro)20:28
volker-crankDeric: with e2fsprogs I saw that you have to add the packages you need, else you don't get the fsck or mkfs automatically20:30
volker-but I am not a yocto expert ;-)20:30
crankDericvolker-: So I've got IMAGE_INSTALL_append = "pulseaudio"20:30
crankDericand if I look at the recipie for pulseaudio in the poky/meta/recipies-multimedia/pulseaudio dir theres a file20:30
crankDericit seems to indicate that those libs will be built, and they are, but they aren't packaged in my .sdcard, any idea how I tell Yocto to put those on my target rootfs?20:31
kergothcrankDeric: see PACKAGES_DYNAMIC20:31
volker-crankDeric: what I do is going into tmp/deploy/deb/*/ and look there at the packages and define them extra in IMAGE_INSTALL_append (deb because I use debian packages, yours might be different like opkg or similar)20:31
kergothit breaks up into many small binary packages the way kernelm-doule- does, as volker- has pointed out20:31
kergothpulseaudio-module-*, etc20:31
kergothadd the ones you need to IMAGE_INSTALL20:31
crankDerickergoth: okay, thanks!20:31
crankDericvolker-: thanks as well20:32
*** ant_home <ant_home!> has joined #yocto20:32
volker-good on the one side, bad on the other side because if you start the default one seems to be as less packages as possible and then you boot and are confused why the kernel modules and similar are not there ;-)20:32
kergothusing granular packaging is a nice compromise solution between large images and stripping things out, since you can pull in what you need, but yeah, itd be nice if things were a little more discoverable20:33
kergothactually, this would be a good case to use toaster, in the future20:33
*** nerdboy <nerdboy!> has quit IRC20:37
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto20:37
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC20:38
CroftonRP, awesome email20:42
*** crankDeric <crankDeric!~deric@> has quit IRC20:42
Croftonwe should have a discussion at OEDAM if/how "OE" can improve YP releases20:43
kergothI think we should branch off the release sooner, and truly make it bugfix-only at that point, avoid this last minute feature submission thing20:44
kergothIMO anyway20:44
volker-kergoth: toaster?20:44
kergothvolker-: it's the new UI for examining builds being developed.
kergothpretty cool stuff20:45
kergothah yeah, thats the link i was looking for and couldn't find20:45
CroftonI am in the process of replying to the email20:46
volker-toaster is its own build system and not compatible with other build systems?20:46
kergothno, its a bitbake UI that lets you examine your bitbake builds to see how they went20:47
kergothit doesn't build, at this time anyway20:47
volker-ok, just curious :)20:47
kergothyou drop into its environment, do builds, and use toaster to look at them20:47
kergothafaik, anyway, i haven't used it much, just tried it once20:47
-YoctoAutoBuilder- build #39 of nightly-ppc-lsb is complete: Success [build successful] Build details are at
CroftonI looked a little at ELCE20:55
Croftonseems to help you get a grasp on depends20:56
kergothyeah, like a much, much prettier depexp + more20:56
Croftonbeing a hard core gui hater, I am having a hard time figuting out why a gui will help20:56
kergothits one of the most common questions, so it makes a lot of sense to answer it in a way that's nice20:56
Croftonbut I also know that many customers like this stuff20:57
kergothpersonally, i want to do more work on the sub-command based ui, with whatdepends/whatprovides/etc, to answer the same questions at a commandline20:57
kergothbut i'm anti-ui mostly too :)20:57
Croftonand if reduces my workload, I am all for it20:57
Croftonwhy do people hate rc.local now?20:58
*** mikejanzen <mikejanzen!~mikejanze@> has joined #yocto21:03
-YoctoAutoBuilder- build #39 of nightly-x86 is complete: Success [build successful] Build details are at
volker-what is the best place to drop random recipes of?21:09
volker-e.g. when I wrote a monit 5.8 recipe21:10
volker-nagios has, chef has, what does yocto have?21:12
kergothyou can post your own layers where appropriate. meta-oe tends to get random stuff that doesn't have a real place to belong21:19
kergothfolks often run their own meta-<username> layers for local bits21:19
*** rburton <rburton!> has quit IRC21:26
*** munch <munch!> has quit IRC21:26
-YoctoAutoBuilder- build #40 of nightly-mips is complete: Success [build successful] Build details are at
*** rburton <rburton!> has joined #yocto21:30
*** e8johan <e8johan!> has quit IRC21:34
*** jkridner <jkridner!> has joined #yocto21:36
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto21:36
regorianerif i have a makefile which has a echo output as make all and for the install i do need to perfomr "make install", how do i configure my recipe to do this ? acutally run.do_compile calls "make" and run.do_install has nothing to do but the install_append() tuff i added on my own.21:36
-YoctoAutoBuilder- build #39 of nightly-mips-lsb is complete: Success [build successful] Build details are at
regorianeri could patch the makefile, but this isnt a good solution i guess21:37
regorianeror do i just put a do_configure_append { make install } ??21:38
volker-kergoth: and where do I drop it off then?21:40
kergothI don't understand the question21:40
volker-kergoth: if I have something and think it might be helpful for other people, where do I drop my own meta-volker off?21:41
*** rburton <rburton!> has quit IRC21:42
volker-kergoth: sorry, I rephrase this, where do I "post" my own layer?21:42
kergothanyone can add a layer to the layer index21:43
*** rburton <rburton!> has joined #yocto21:43
volker-ok, excuse my question, I oversaw the "Submit layer" button :(21:45
*** pidge_ <pidge_!~pidge@> has joined #yocto21:45
*** jzhang1 <jzhang1!jzhang@nat/intel/x-nwcpevkzhqdrwued> has joined #yocto21:45
*** jzhang <jzhang!jzhang@nat/intel/x-xejlocicbuvnvarm> has quit IRC21:46
*** OlivierG <OlivierG!~oguiter@> has joined #yocto21:46
*** pidge <pidge!pidge@nat/intel/x-yzhgbhccfkpbrkpv> has quit IRC21:46
*** roric <roric!> has joined #yocto21:50
kergothvolker-: heh, np :)21:51
*** rburton <rburton!> has quit IRC21:51
*** rburton <rburton!> has joined #yocto21:52
*** JimBaxter <JimBaxter!> has quit IRC21:52
*** ccaione <ccaione!~ccaione@unaffiliated/ccaione> has quit IRC21:58
*** ant_home <ant_home!> has quit IRC21:59
*** bfederau <bfederau!> has quit IRC22:01
*** bfederau <bfederau!> has joined #yocto22:01
-YoctoAutoBuilder- build #39 of nightly-arm-lsb is complete: Success [build successful] Build details are at
volker-If you do a full release, what is the most important thing beside keeping the steps repeatable (by using a local mirror, using fixed repository version/hashes)?22:03
*** rburton <rburton!> has quit IRC22:03
*** ccaione <ccaione!~ccaione@unaffiliated/ccaione> has joined #yocto22:03
volker-How helpful is the buildhistory option?22:03
-YoctoAutoBuilder- build #41 of nightly-x86-64-lsb is complete: Success [build successful] Build details are at
*** pidge_ <pidge_!~pidge@> has quit IRC22:05
*** rburton <rburton!> has joined #yocto22:08
kergothbuildhistory is extremely useful. there's a ton of useful info in there. you can use it to compare output before and after a cahgne, to mamke sure your change didn't affect something other than what you expected, and so you can use it to monitor for image size changes more than you intend, can examine what packages are in your images, etc. i wouldn't build without it22:09
-YoctoAutoBuilder- build #39 of nightly-fsl-arm is complete: Success [build successful] Build details are at
*** rburton <rburton!> has quit IRC22:17
*** gmacario <gmacario!> has quit IRC22:17
*** rburton <rburton!> has joined #yocto22:18
dmoseleyDoes anyone have a feeling whether the patch being discussed at will make it through LTSI and into Yocto in time for the 1.6 release?  I'm tripping over that bug in one configuration and am consider submitting a bbappend to add it just in case it doesn't make it through.22:21
dmoseleynitink: the link above ^^ is from you.22:23
*** beaver_545 <beaver_545!> has quit IRC22:24
nitinkdmoseley: that fix is already in the Yocto kernel22:24
dmoseleyHmm.  My tree must be behind.  Thanks.  I'll repull everything.22:25
nitinkdmoseley: right, you will need to get newer SRCREVs for kernel recipes22:25
*** sameo <sameo!~samuel@> has joined #yocto22:25
*** jbrianceau_home is now known as jbrianceau_away22:47
*** smartin_ <smartin_!> has quit IRC22:49
*** rburton <rburton!> has quit IRC22:51
*** rburton <rburton!> has joined #yocto22:56
*** agust <agust!> has quit IRC22:57
*** seebs <seebs!> has quit IRC22:58
*** sjolley <sjolley!~sjolley@> has quit IRC23:05
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mvbzpsmgotaayiae> has quit IRC23:14
volker-whoever gave our build system 1GB RAM, it is not enough to handel two yocto builds at the same time...23:15
kergoth1gb is likely about what you need for one :)23:16
volker-I get out of memory errors in the one case and the other case the error message is not 100% clear23:18
CroftonI put as much ram in min eas it could hold23:25
volker-the previous sys admins where strange. newest gear but then 8GB ram in each system. And on top of that some VMs23:26
-YoctoAutoBuilder- build #39 of nightly-fsl-arm-lsb is complete: Success [build successful] Build details are at
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:32
*** rburton <rburton!> has quit IRC23:34
*** rburton <rburton!> has joined #yocto23:35
*** maxtothemax <maxtothemax!maxtothema@nat/intel/x-efrmmcfevqsjakjh> has quit IRC23:36
*** Jim___ <Jim___!411ad795@gateway/web/cgi-irc/> has joined #yocto23:45
*** Squix <Squix!> has joined #yocto23:48
*** sjolley <sjolley!sjolley@nat/intel/x-belihdajtxtfxrpe> has joined #yocto23:50
dmoseleynitink: I just pulled the latest poky and built a v3.10 kernel and it does not include that patch.  Are you expecting that it's fixed in v3.10 or just v3.14?23:51
dmoseleyI used MACHINE=genericx86.23:51
nitinkdmoseley: it is fixed in v3.10, v3.14 does not have LTSI support as of now23:52
nitinkdmoseley: how are you checking whether the patch is in or not? did you try building?23:53
dmoseleyI did "bitbake -c configure linux-yocto" with PREFERRED_VERSION_blah set in my local.conf23:54
nitinkdmoseley: looks like the poky v3.10 kernel recipe need SRCREV updates to get this fix23:55
nitinkin meta-intel we get kernel version 3.10.3523:56
nitinkin poky I am seeing version as 3.10.34 which does not have this fix23:56
dmoseleyYeah, that's what I'm seeing.23:56
nitinkzeddii: ^^^ the v3.10 kernel recipes in the poky need srcrev updates23:57
nitinkdmoseley: zeddii sends these SRCREV updates for oecore/poky layers23:57
dmoseleyOK.  Gotcha.  I'll keep an eye out for it.  Sounds like getting it in before 1.6 should not be a problem though.23:58
nitinkdmoseley: you can open a bug in for updation of SRCREVS of v3.10 kernels in poky/oecore23:59

Generated by 2.11.0 by Marius Gedminas - find it at!