Monday, 2014-10-06

*** nitink <nitink!~nitink@> has joined #yocto00:02
*** nitink <nitink!~nitink@> has quit IRC00:44
*** nitink <nitink!~nitink@> has joined #yocto00:44
*** nitink <nitink!~nitink@> has quit IRC00:58
*** sameo <sameo!~samuel@> has quit IRC00:58
*** nitink <nitink!~nitink@> has joined #yocto01:27
*** nitink <nitink!~nitink@> has quit IRC01:34
*** eicordob <eicordob!~erich@> has joined #yocto01:36
*** nitink <nitink!~nitink@> has joined #yocto01:40
*** nitink <nitink!~nitink@> has quit IRC01:48
-YoctoAutoBuilder- build #68 of nightly-qa-pam is complete: Success [build successful] Build details are at
blloydis there an easy way to get the tasks of a recipe (linux-yocto) and the execution order of the tasks?01:57
*** ddom <ddom!~ddom@> has quit IRC02:06
*** RagBal <RagBal!> has quit IRC02:18
*** RagBal <RagBal!> has joined #yocto02:19
*** RagBal <RagBal!> has quit IRC02:34
*** RagBal <RagBal!> has joined #yocto02:37
*** ddom <ddom!~ddom@> has joined #yocto02:37
*** Rootert <Rootert!> has quit IRC02:39
*** seebs <seebs!> has quit IRC02:40
*** Rootert <Rootert!> has joined #yocto02:41
*** seebs <seebs!> has joined #yocto02:43
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC02:46
*** hsychla_ <hsychla_!> has joined #yocto03:00
*** Jefro <Jefro!> has quit IRC03:03
*** hsychla__ <hsychla__!> has quit IRC03:04
*** victhor__ <victhor__!~victhor@> has quit IRC03:17
*** Nilesh_ <Nilesh_!~minda@> has joined #yocto03:28
-YoctoAutoBuilder- build #68 of nightly-x86-64-lsb is complete: Success [build successful] Build details are at
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto03:34
*** ddom <ddom!~ddom@> has quit IRC03:37
*** blloyd <blloyd!> has quit IRC03:49
-YoctoAutoBuilder- build #66 of nightly-arm-lsb is complete: Success [build successful] Build details are at
*** Jefro <Jefro!> has joined #yocto04:06
*** seebs <seebs!> has quit IRC04:18
*** seebs <seebs!> has joined #yocto04:21
*** seebs <seebs!> has quit IRC04:26
*** e8johan <e8johan!~quassel@> has joined #yocto04:31
*** seebs <seebs!> has joined #yocto04:32
-YoctoAutoBuilder- build #66 of nightly-mips-lsb is complete: Success [build successful] Build details are at
*** g1zer0 <g1zer0!> has joined #yocto04:51
*** eicordob <eicordob!~erich@> has quit IRC04:55
-YoctoAutoBuilder- build #66 of nightly-ppc-lsb is complete: Success [build successful] Build details are at
*** g1zer0 <g1zer0!> has quit IRC05:27
*** zecke <zecke!~ich@> has joined #yocto05:32
*** TobSnyder <TobSnyder!> has joined #yocto05:37
-YoctoAutoBuilder- build #66 of nightly-fsl-arm is complete: Success [build successful] Build details are at
*** Jefro <Jefro!> has quit IRC05:54
*** AndersD <AndersD!> has joined #yocto05:57
*** g1zer0 <g1zer0!> has joined #yocto06:05
*** agust <agust!> has joined #yocto06:10
*** pohly <pohly!> has joined #yocto06:15
*** stiandre <stiandre!~stiandre@> has joined #yocto06:22
-YoctoAutoBuilder- build #66 of nightly-fsl-arm-lsb is complete: Success [build successful] Build details are at
*** adelcast <adelcast!~adelcast@> has quit IRC06:26
*** b00^wk <b00^wk!> has joined #yocto06:31
b00^wkhello, how do I install that graphical tool that the app builder image uses ?06:32
b00^wkHob, or Hub06:32
b00^wkfor generating images06:32
LetoThe2ndum... bitbake hob?06:33
b00^wkyea i think so06:34
b00^wkalso, what does "sato" mean?06:34
b00^wkif i don't have hob, how do I get a list of possible image configurations ?06:34
b00^wklike , core-image-sato/minimal, etc ...06:34
LetoThe2ndsato is just the name of a generic grahical environment for demo/testing purposes.06:35
b00^wkgraphical environment inside the image ?06:35
LetoThe2ndyou can for example run a find -iname "*-image-*" through your layers (assuming all image recipes have been named properly)06:35
LetoThe2ndyes, sato is a package group that goes *into* the iamge06:36
b00^wkLetoThe2nd,  i've git 'ed it all as in quick start, and modified nothing, so06:36
b00^wkfind should work06:36
b00^wki guess06:36
LetoThe2ndor grep for "image.bbclass"06:36
b00^wkif i add dev tools, does bitbake create two images ?06:37
b00^wki want one for target, one for dev06:37
LetoThe2ndbitbake creates what you tell it to do06:37
b00^wkso obviously compiler must not go to target06:37
LetoThe2ndso you have to make two image recipes, and tell bitbake to tell each of them seperately06:38
b00^wkLetoThe2nd,  but with Hub its probably easy quick config or not .. ?06:38
LetoThe2nda) its called hob b) no idea, i don't use it06:38
b00^wkOk, Hob :)06:38
LetoThe2ndthe standard way is that you create your product image, and then a second image that extends it for demo purposes, e.g. depends on it.06:39
b00^wkI see06:39
b00^wkif i would to draw it, it would be   [ general big image with tools [ target image]  ]    .   so target is a subset of general bit one :) . So i would start with the bigger one.06:40
b00^wkLetoThe2nd,   is it possible to generate two images same time, with two recipes ?06:41
*** ant_work <ant_work!> has joined #yocto06:41
*** eballetbo <eballetbo!> has joined #yocto06:41
LetoThe2ndits easier the other way round, because if you start with the bigger one you eventually have to tear apart a long list afterwards06:41
b00^wkLetoThe2nd,  yea, ok06:42
LetoThe2nd(at least from my experience)06:42
* LetoThe2nd is gone for a sec06:42
b00^wkLetoThe2nd,  as long as I back up original 'minimal' setup06:42
*** [Sno] <[Sno]!~Sno]> has quit IRC06:55
LetoThe2ndb00^wk: just have a look at the meta/recipes-core/images/core-image-minimal{.bb,}06:57
LetoThe2ndb00^wk: they give a good idea of how a dev recipe extends the base/product image for development purposes06:58
b00^wkLetoThe2nd, yea, the minimal is where i thought, i start.  i didn't know that extends anything,  when i tried it it just had busybox in it06:58
LetoThe2ndb00^wk: the -dev extends the minimal06:58
LetoThe2ndso you can see the general mechanism06:59
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto07:01
*** jbrianceau_away is now known as jbrianceau07:02
*** olani` <olani`!user@nat/axis/x-gamdbqyyxcotkskc> has quit IRC07:03
*** TobSnyder <TobSnyder!> has quit IRC07:05
*** TobSnyder <TobSnyder!> has joined #yocto07:06
*** adelcast <adelcast!~adelcast@> has joined #yocto07:09
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has joined #yocto07:10
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has quit IRC07:10
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:10
*** mckoan|away is now known as mckoan07:12
mckoangood morning07:13
*** sameo <sameo!~samuel@> has joined #yocto07:13
b00^wkAh, so there is a dev already for core-minimal ?07:13
b00^wkme check07:13
bluelightningmorning all07:14
LetoThe2ndmourns too (UMT)07:14
*** fabo <fabo!~fabo@linaro/fabo> has quit IRC07:18
*** seiron <seiron!> has joined #yocto07:20
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has joined #yocto07:24
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:35
*** florian_kc is now known as florian07:35
*** seiron <seiron!> has quit IRC07:51
-YoctoAutoBuilder- build #67 of nightly-rpm is complete: Success [build successful] Build details are at
*** vignatti_ is now known as vignatti08:00
*** melonipoika <melonipoika!> has joined #yocto08:01
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:10
*** adelcast <adelcast!~adelcast@> has quit IRC08:14
pevHey all, anyone seen an issue building where GCC has an internal segfault? This is building an OMAP2 board under 1.5...08:47
*** phantoxe <phantoxe!> has joined #yocto08:58
*** dse <dse!~d.s.e@2001:a60:1468:d601:c924:9137:a0dc:bbea> has joined #yocto08:59
*** belen <belen!Adium@nat/intel/x-wjhihmhmvwekjflt> has joined #yocto09:03
*** pev <pev!~pev@> has left #yocto09:11
*** pev <pev!~pev@> has joined #yocto09:20
pevHm, found it. GCC needs for it not to bork. Guessing this is an ubuntu 14.04 thing...09:21
pevFor reference / google, the error it kicked up was "../../../../libgcc/../gcc/libgcc2.c:72:1: internal compiler error: Segmentation fault"09:22
*** jimBaxter <jimBaxter!> has joined #yocto09:23
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto09:27
*** belen <belen!Adium@nat/intel/x-wjhihmhmvwekjflt> has quit IRC09:32
*** belen <belen!Adium@nat/intel/x-clblzjmzuzufmbgk> has joined #yocto09:59
*** belen <belen!Adium@nat/intel/x-clblzjmzuzufmbgk> has quit IRC10:03
*** jackmitchell <jackmitchell!> has quit IRC10:04
*** belen <belen!~Adium@> has joined #yocto10:09
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:10
*** jackmitchell <jackmitchell!> has joined #yocto10:11
*** Crofton|work <Crofton|work!> has joined #yocto10:18
*** Nilesh_ <Nilesh_!~minda@> has quit IRC10:20
*** frsc <frsc!> has joined #yocto10:27
*** [Sno] <[Sno]!~Sno]> has joined #yocto10:30
*** frsc1 <frsc1!> has joined #yocto10:31
*** frsc <frsc!> has quit IRC10:33
*** tmpsantos <tmpsantos!> has joined #yocto10:35
*** Nilesh_ <Nilesh_!~minda@> has joined #yocto10:35
*** g1zer0 <g1zer0!> has quit IRC10:40
*** blitz00 <blitz00!~stefans@> has joined #yocto10:45
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto10:45
*** hsychla <hsychla!> has joined #yocto10:46
*** g1zer0 <g1zer0!> has joined #yocto11:00
*** jluisn <jluisn!~quassel@> has joined #yocto11:04
*** adelcast <adelcast!~adelcast@> has joined #yocto11:07
*** ddalex <ddalex!~ddalex@> has quit IRC11:08
*** ddalex <ddalex!~ddalex@> has joined #yocto11:10
b00^wkcan I source oe-init-build-env again ?11:11
b00^wkwon't loose anything ?   . i had to re-login11:11
LetoThe2ndwhy not, its basically jsut setting a bunch of env vars11:11
b00^wki didn't check it, thought it also creates build dir11:12
b00^wknot sure if it wipes it clean first :)11:12
bluelightningnope, if the config files already exist they won't be touched11:12
*** adelcast <adelcast!~adelcast@> has quit IRC11:12
*** victhor__ <victhor__!~victhor@> has joined #yocto11:19
*** ddom <ddom!> has joined #yocto11:22
*** michaelw <michaelw!> has quit IRC11:45
*** michaelw <michaelw!> has joined #yocto11:51
b00^wkal'right, qemu running first time on my non Build Appliance yocot ..11:52
b00^wkwhere do I modify the image size ?11:52
b00^wkwith Hob there was a nice little  menu ...11:53
*** adelcast <adelcast!~adelcast@> has joined #yocto11:53
*** kbouhara <kbouhara!> has joined #yocto12:04
kbouharaHow do we include Qt when generating sdk with "bitbake my-image -c populate_sdk" ?12:06
*** gvy <gvy!~mike@altlinux/developer/mike> has joined #yocto12:09
mckoankbouhara: does your image recipe include Qt ?12:10
*** tomz_ <tomz_!~tomz@> has quit IRC12:13
*** Siecje <Siecje!> has joined #yocto12:17
*** adelcast <adelcast!~adelcast@> has quit IRC12:17
*** challinan <challinan!> has joined #yocto12:26
*** tasslehoff <tasslehoff!> has joined #yocto12:27
kbouharamkoan: yes it does12:28
*** tomz_ <tomz_!~tomz@> has joined #yocto12:29
kbouharaI have IMAGE_INSTALL += "\  packagegroup-core-qt4e" defined12:34
*** frsc_ <frsc_!> has joined #yocto12:41
*** frsc1 <frsc1!> has quit IRC12:45
*** ntl <ntl!> has quit IRC12:47
mckoankbouhara: so -c populate_sdk does the magic12:52
*** elmi82 <elmi82!> has joined #yocto12:54
*** rwoolley <rwoolley!~rwoolley@> has joined #yocto13:08
*** olani <olani!user@nat/axis/x-amgwgtapetujspzq> has joined #yocto13:12
kbouharamkoan: no it doesn't work for me when I install the SDK and source the environment script, If I do "which qmake" it says /usr/bin/qmake not /opt/poky/...13:23
bluelightningjust having Qt in your image won't make the SDK have the tools in it13:25
bluelightningtry adding this to your image: TOOLCHAIN_HOST_TASK_append = " nativesdk-packagegroup-qte-toolchain-host"13:26
kbouharabluelightning: ok will try it and see it does the work13:27
xerentwhat could cause kernel configuration flags to disappear in the do_kernel_configcheck step?13:33
*** dmoseley <dmoseley!> has joined #yocto13:33
xerentthe only clue I have is from the log, which points to the missing_required.txt log file, which simply says "Required value for CONFIG_FOO not in final ".config"13:34
ant_workyou can read in the machine-config log the steps leading to it13:36
ant_workit is maybe reset by some other fragment/feature?13:37
*** Crofton <Crofton!> has joined #yocto13:37
xerentthanks, where's the machine-config log?13:40
ant_workin the same dir under meta where required.txt is13:41
*** ntl <ntl!> has joined #yocto13:41
ant_workit is -defconfig in my case13:41
b00^wkwhere do I get the (desired) max size of the target hdd image ?13:42
ant_work(I'm away from build machine, can't check precisely right now)13:42
b00^wki found IMAGE_ROOTFS_SIZE, but don't see hdd img size13:42
*** AndersD <AndersD!> has quit IRC13:59
*** AndersD <AndersD!> has joined #yocto13:59
xerentwhere does the bitbake binary go, I'm looking for it. I can run it through makefiles but not from the commandline :)14:12
xerentor I suppose I am running bitbake somehow because I can produce images through Yocto :P14:13
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC14:15
*** Nilesh_ <Nilesh_!~minda@> has quit IRC14:15
*** adelcast <adelcast!~adelcast@> has joined #yocto14:15
*** elmi82 <elmi82!> has quit IRC14:16
*** stiandre <stiandre!~stiandre@> has quit IRC14:20
xerentfound it, but14:21
xerentERROR: An uncaught exception occured in runqueue, please see the failure below:14:22
*** staylor <staylor!> has joined #yocto14:22
*** tasslehoff <tasslehoff!> has quit IRC14:24
*** challinan <challinan!> has quit IRC14:28
*** munch <munch!> has joined #yocto14:33
xerentbitbake can't open runqueue.py14:33
bluelightningxerent: what are you attempting to do?14:37
*** challinan <challinan!> has joined #yocto14:38
*** b00^wk <b00^wk!> has quit IRC14:39
*** sjolley <sjolley!~sjolley@> has quit IRC14:43
*** belen <belen!~Adium@> has quit IRC14:43
*** [Sno] <[Sno]!~Sno]> has quit IRC14:45
*** belen <belen!Adium@nat/intel/x-ypvszktzeuofyxkk> has joined #yocto14:45
*** adelcast <adelcast!~adelcast@> has quit IRC14:48
*** munch_ <munch_!~mark@> has joined #yocto14:50
*** munch_ is now known as Guest8342514:50
*** munch <munch!> has quit IRC14:51
*** sarahsharp <sarahsharp!~sarah@> has joined #yocto14:52
*** TobSnyder <TobSnyder!> has quit IRC14:54
*** belen <belen!Adium@nat/intel/x-ypvszktzeuofyxkk> has quit IRC14:56
*** e8johan <e8johan!~quassel@> has quit IRC14:57
*** belen <belen!Adium@nat/intel/x-iqnyihjkpdnwqmxb> has joined #yocto14:59
*** g1zer0 <g1zer0!> has quit IRC15:00
*** sjolley <sjolley!~sjolley@> has joined #yocto15:10
*** sarahsharp <sarahsharp!~sarah@> has quit IRC15:15
*** munch <munch!~mark@> has joined #yocto15:25
*** Guest83425 <Guest83425!~mark@> has quit IRC15:26
*** sarahsharp <sarahsharp!sarah@nat/intel/x-djtmcubxizlbahaz> has joined #yocto15:28
xerentbitbake linux-yocto -c kernel_configcheck -f15:32
xerentfrom build folder15:32
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has quit IRC15:33
bluelightningxerent: after sourcing oe-init-build-env ?15:33
xerentdon't know exactly, but I have built complete images using that kernel15:34
xerentbased on linux-yocto_3.10.17.bb15:35
*** armpit <armpit!~akuster@2601:c:9380:601:9047:eb81:1abf:5be> has joined #yocto15:37
bluelightningI'm confused15:39
xerentso am I, but I think I know what you're getting at15:39
xerentand yes, I'm missing something15:39
bluelightningsurely you know if you have run oe-init-build-env within the current shell or not?15:39
xerentand the answer to that question is "no" because I didn't know about it15:40
xerentbut looking at the Makefiles I can figure out what you're talking about15:40
xerentOK, now I got it working, thanks15:42
*** [Sno] <[Sno]!~Sno]> has joined #yocto15:44
*** ddom <ddom!> has quit IRC15:45
xerentthough it gave me no more useful information, I'm trying to find out why my "CONFIG_REGMAP=y" is set to "" but the logs are most unhelpful15:50
ant_workhow is the final config assembled? by which fragments?15:57
ant_workpreviously you found missing_required.txt15:59
*** belen <belen!Adium@nat/intel/x-iqnyihjkpdnwqmxb> has quit IRC15:59
ant_workcheck in the same dir, read it all ;)15:59
ant_workhere under 'meta' subdir are the artifacts produced by yocto kernel tools16:00
*** mckoan is now known as mckoan|away16:01
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto16:02
xerentI thought I had read it all, if I grep all the files for the config flag I only get the message that 1. it's included in the config going in, from my fragment, but 2. not included in my final .config16:03
xerentand inbetween, I've found no reference to the darn thing :)16:04
*** belen <belen!Adium@nat/intel/x-qlnkyzmbcsoqwblc> has joined #yocto16:14
ant_workhow did you add your fragment?16:16
xerentfrom files/ folder in recipe folder I added regmap.cfg, and16:17
xerentin recipe .bbappend file I added SRC_URI_append_machinename = " file://regmap.cfg"16:17
ant_workand is your fragment processed?16:18
kergothRP: any tips for diagnosing sstate reuse problems when neither bitbake -S printdiff nor bitbake-whatchanged show any delta whatsoever?16:18
xerentant_work: I think so, the same thing worked fine for other configuration flags, such as when I set CONFIG_INPUt_stuff16:19
ant_worksee, there are cdases where you might want to use an .scc and set i.e.   kconf hardware yourfrag.cfg16:20
ant_worksetting it as hardware fragment will preserve it16:21
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC16:22
ant_workI'm sorry but I'm away of my pc and cannot help you much16:22
ant_workhowever you should find fine examples in the manual16:22
xerentI'll look for that16:22
ant_work...or a very comples example of mine...16:22
ant_worksee this and its dir16:23
ant_workthe machines using feature-top.scc are fully composed by fragments16:24
ant_workthe ones using 'defconfig' are kept unchanged16:24
ant_work(that was explaining it in a few words...)16:24
*** munch <munch!~mark@> has quit IRC16:24
*** jluisn <jluisn!~quassel@> has quit IRC16:25
*** jluisn <jluisn!~quassel@> has joined #yocto16:26
RPkergoth: resort to bitbake-diffsigs ?16:30
kergothhmm, yeah, might be best16:33
*** Jefro <Jefro!> has joined #yocto16:34
*** victhor__ <victhor__!~victhor@> has quit IRC16:35
*** victhor__ <victhor__!~victhor@> has joined #yocto16:35
*** belen <belen!Adium@nat/intel/x-qlnkyzmbcsoqwblc> has quit IRC16:35
fraymaybe someone can help..  where [code wise] does the system compress (or create the image) from the IMAGE_ROOTFS after or part of the do_rootfs command?16:35
*** belen <belen!Adium@nat/intel/x-gxupkgggbgbrodqj> has joined #yocto16:36
*** blloyd <blloyd!> has joined #yocto16:39
bluelightningfray: definitions in meta/classes/image_types.bbclass, code that reads them in meta/lib/oe/image.py16:39
frayI've been looking through oe/ and can't figure out where the connection is between the IMAGE_ROOTFS and the output..16:39
frayI'm trying to make the system do this action against another directory (not IMAGE_ROOTFS) as part of the rootfs process...16:40
frayin the old code, [pre-python] you could do this within the IMAGE_POSTPROCESS_CMD... [still happens to work here], but I'm having to manually run the tar and such commands..16:40
frayI'd rather re-use what teh system is already doing16:40
bluelightningfray: see _get_imagecmds16:41
bluelightningthat grabs the values defined in image_types.bbclass16:42
frayso is that the for fstype_group in fstype_groups?16:42
frayok.. and then it just uses the IMAGE_ROOTFS as passed into the function..16:44
*** darknighte <darknighte!> has joined #yocto16:44
RPkergoth: when you do figure it out, can you document a test case as a bug please? Makes it great to try and improve printdiff16:45
*** darknighte is now known as Guest3887016:45
frayok.. I think I'm getting it now.. so the 'create' in, gets back a set of image cmd groups, which can then be run in paralle (provided it's allowed).. and the commands themsevles know how to read the IMAGE_ROOTFS, so it's never passed through the functions..16:45
*** Guest38870 <Guest38870!> has quit IRC16:45
bluelightningfray: right16:46
fraythat connection is what I was missing.. thanks16:46
*** victhor__ <victhor__!~victhor@> has quit IRC16:46
*** ant_work <ant_work!> has quit IRC16:46
bluelightningfray: you could cheat and use a copy of the datastore and set IMAGE_ROOTFS etc. to whatever you want it to be16:46
frayso likely the only way for me to reuse that would be t change the definition of IMAGE_ROOTFS (temporarily) and then call through at that point16:47
*** darknighte_ <darknighte_!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto16:47
bluelightningright, that's basically the same thing, except modifying a copy of the datastore is going to be less fragile16:47
fraythats what I'm trying to figure out now..  would I have to change self.d (temporarily) then?  what I don't see is what value of 'd' is used by the bb.utils.multiprocessingpool / pool.impa16:47
fray'er.. pool.imap16:47
fray(what I'm working on is a parallel 'debug filesystem' that only contains the associated -dbg package contents...)  that way you end up with a product and 'debug' filesystem.. if you want to merge them you can debug on the target..16:49
frayI have generation working (I think)16:49
fray[mhatle@msp-dhcp23 1.0-r0]$ du -s rootfs*16:49
fray6948    rootfs16:49
fray89304   rootfs-dbg16:49
*** j6V6t <j6V6t!> has left #yocto16:49
fraybut it's exporting them out thats tricky.. and due to us moving all of this into the, I'm having to actually modify it.. there aren't any hooks to do this dynamicall16:49
bluelightningfray: you would not want to set self.d, no. you'll probably have to change the structure of the code16:50
fray            pool = bb.utils.multiprocessingpool(nproc)16:50
fray            results = list(pool.imap(generate_image, image_cmds))16:50
frayit's that part that I'm trying to figure out if I can modify in some way to pass an alternative datastore..16:50
frayOR if the image_cmds were expanded earlier, if so I could do it there..16:51
fray        image_cmd_groups = self._get_imagecmds()16:51
frayahh.. yes they were expanded there.. I see now how16:52
fraybut they were expanded using 'self.d' as the origin..16:52
frayok.. I think I have a plan.. allow the system to pass an alternative datastoer into the _get_imagecmds()...  then I can set IMAGE_ROOTFS to whatever I want temproarily without messing with self.d16:53
kergoththat reminds me, it'd be lovely to implement some form of ASSUME_RPROVIDED for this, to explictly bypass certain deps without having to force bypass all dependencies. course i don tknow if all our package managers would support such a thing, or how much work it'd be..16:54
frayI agree.16:55
frayI'm working on generating and SDK as well, and it would be nice to throw out specific target dependencies I don't care about..16:55
frayi.e. I don't want bash or perl in the SDK.. :P  even if glibc says it needs them16:55
fraywe could do that before things went to python (at least for rpm) by seeding the provides file..16:55
*** phantoxe <phantoxe!> has quit IRC16:56
kergothwe hit the perl one a while back trying to add git-submodule to the buildtools-tarball (needs git-perltools)16:56
* kergoth nods16:56
kergothi figured opkg would be similar, hack the status if necessary16:56
fray(my hack, for now, is to disable all of the automatic dep generation during packaging for the special SDK builds.. but that isn't exactly 'general purpose')16:56
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC16:57
*** ntl <ntl!> has quit IRC16:58
kergothRP: I'm hitting a situation trying to share sstate between two hosts. All the signatures are the same, only the native filenames are differnet due to the different nativelsbstring, so the native setscenes can't be run. It seems it ends up rebuilding certain target recipes from scratch after the natives get built from scratch, even though all the signatures, native and target, are the same. Any ideas on that?16:59
*** smartin_ <smartin_!> has joined #yocto17:01
*** jonmasters <jonmasters!> has quit IRC17:01
kergothOf course bitbake -S and bitbake-whatchanged can't tell me why anything is building from scratch, since the signatures haven't changed. and afaik there's no detailed log of bitbake's decisions wrt sstate usage17:03
*** Jefro1 <Jefro1!> has joined #yocto17:04
*** eballetbo <eballetbo!> has quit IRC17:06
*** Jefro <Jefro!> has quit IRC17:07
RPkergoth: bitbake -DDDv does log some of its decisions about sstate iirc, at least what it looks for and did/didn't find. If the sigs are the same, it has to be something in the lsbstring matching part?17:11
kergothRP: i know the nativelsbstring doesn't match, these are two different distros. but there's no reason it couldn't reuse the target stuff, it used to, but it doesn't seem to now. Presumably after it rebuilt the natives it wanted to rebuild the bits that depended on them, but it shouldn't need to, since the checksums *and* filenames for the target sstates match up, all thats changed is some of its dependencies were built from scratch. I'll do some -DDDv17:15
kergoth builds and see if I can pick up anything useful. thanks for the assistance17:15
*** sameo <sameo!~samuel@> has quit IRC17:18
*** ntl <ntl!> has joined #yocto17:25
*** jimBaxter <jimBaxter!> has quit IRC17:33
*** gvy <gvy!~mike@altlinux/developer/mike> has quit IRC17:41
*** sgw_ <sgw_!> has quit IRC17:42
*** Jefro1 <Jefro1!> has quit IRC17:45
*** sgw_ <sgw_!> has joined #yocto17:45
*** sarahsharp <sarahsharp!sarah@nat/intel/x-djtmcubxizlbahaz> has quit IRC17:46
*** Jefro <Jefro!> has joined #yocto17:48
*** Jefro <Jefro!> has quit IRC17:51
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:01
*** sarahsharp <sarahsharp!~sarah@> has joined #yocto18:09
*** Jefro <Jefro!> has joined #yocto18:09
*** fusman <fusman!~fahad@> has joined #yocto18:09
*** behanw <behanw!> has quit IRC18:09
blloydI'm trying to get a better understanding of linux-yocto kernel configuration.   I had 3.4 working nicely for two CPUs.  A vortex86 and a Geode LX2.  But moving forward to 3.14 is driving me crazy.  How do I figure out what the baseline is on which the fragments will be applied?  More apptly, how can I choose which branch to base off of?  I used to use the atom-pc which was almost exactly what both of those needed.  No other patches nee18:15
blloydded and only a very small handful of changes via .scc18:15
*** belen <belen!Adium@nat/intel/x-gxupkgggbgbrodqj> has quit IRC18:18
kergothwe should really add a bitbake argument to exit after the runqueue is prepared and the sstates were fetched / checked18:29
kergothala -p18:29
*** behanw <behanw!> has joined #yocto18:32
*** Jefro <Jefro!> has quit IRC18:40
*** jbrianceau <jbrianceau!uid10952@gateway/web/> has quit IRC18:52
*** fusman <fusman!~fahad@> has quit IRC18:53
frayException:   File "/home/mhatle/git/oss/poky/meta/lib/oe/", line 9018:55
fray    os.rename(self.image_rootfs + '-orig', self.image_rootfs)18:55
fray     ^18:55
fraySyntaxError: invalid syntax18:55
frayany idea what is causing that (yes thats a line I wrote)..18:55
fraybut I'm getting zero context as to why the system things it's 'invalid'18:55
frayd'oh.. missing closing ) about 5 lines up18:56
*** g1zer0 <g1zer0!> has joined #yocto19:04
*** tmpsantos <tmpsantos!> has quit IRC19:18
*** Siecje <Siecje!> has left #yocto19:19
fraythats my -second- pass at the change..19:27
*** blitz00 <blitz00!~stefans@2a02:2f0a:8012:700:5d51:4da8:1886:2ed8> has joined #yocto19:28
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto19:28
*** g1zer0 <g1zer0!> has quit IRC19:31
fraysomething must still not be quite right, since the ext3 image didn't get generated.. but the tar.bz2 did19:31
*** belen <belen!> has joined #yocto19:34
*** sarahsharp <sarahsharp!~sarah@> has quit IRC19:42
*** sarahsharp <sarahsharp!~sarah@> has joined #yocto19:50
*** armpit <armpit!~akuster@2601:c:9380:601:9047:eb81:1abf:5be> has left #yocto19:53
*** belen <belen!> has quit IRC19:59
RPkergoth: thinking a bit more about it, if the natives were not available, I can see how it may then want to rebuild the targets :/20:03
RPkergoth: there is probably some fine tuning of the dependencies there that could be needed20:04
*** sullical <sullical!sullical@nat/intel/x-agpvswosrvdnoqly> has joined #yocto20:12
*** staylor <staylor!> has quit IRC20:12
*** Siecje <Siecje!> has joined #yocto20:18
blloydI'm trying to get a better understanding of linux-yocto kernel configuration.   I had 3.4 working nicely for two CPUs.  A vortex86 and a Geode LX2.  But moving forward to 3.14 is driving me crazy.  How do I figure out what the baseline is on which the fragments will be applied?  More apptly, how can I choose which branch to base off of?  I used to use the atom-pc which was almost exactly what both of those needed.20:26
rburtonblloyd: genericx86 is the new atom-pc, fwiw20:27
rburtonoh but those machines are probably too special for that bsp20:27
*** pohly <pohly!> has quit IRC20:27
*** hbruce_ <hbruce_!hbruce@nat/intel/x-ewxhgfatfliozfvz> has quit IRC20:28
blloydrburton: thanks, but figured that.  However genericx86 seems to have a lot more modules turned on than I had from atom-pc baseline.  So I'm trying to figure out how to pick my baseline without having to compile each one and just see what the .config looks like.20:44
blloydand trying to avoid doing a defconfig, but that defconfig is looking more and more promising.20:45
*** Jefro <Jefro!~jefro@> has joined #yocto20:45
blloydI also figured better understanding of the tools is never a bad thing.  I've already tried reading the code and I wasn't able to make headway on where the base config comes from.20:46
*** Crofton|work <Crofton|work!> has quit IRC20:48
rburtonblloyd: you want to speak to bruce really, zedd when he's on here.  i think i saw holiday photos on facebook though...20:51
frayI can't remember if he's back tomorrow or next week20:52
blloydoh, well.  Thanks fray.  I've got several xf86 driver maintainers interested in my use of their drivers in yocto-project.  One actually seems interested in using it himself if I can get the rest of the bugs worked out.20:53
rburtonwhat are you doing that's awesome?20:55
*** behanw <behanw!> has quit IRC20:56
rburtonfray: did you see the " ignore failed smart install with --attempt" mail you got cc'd on (oe-core)20:56
*** gizero <gizero!> has joined #yocto20:57
*** Siecje <Siecje!> has left #yocto20:57
*** rwoolley <rwoolley!~rwoolley@> has quit IRC21:05
*** Jefro <Jefro!~jefro@> has quit IRC21:07
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC21:07
*** jluisn <jluisn!~quassel@> has quit IRC21:08
*** behanw <behanw!> has joined #yocto21:10
*** sameo <sameo!~samuel@> has joined #yocto21:15
kergothfray: looks promising, quite a bit cleaner than our approach. needs a default IMAGE_FSTYPES_DEBUGFS definition, but that's minor. it's slightly odd that we pass in the -dbg suffix into _get_imagecmds, but had to append the suffix to the various vars ourselves before calling it anyway. seems like either _get_imagecmds should handle it, or it should be handled by the caller, rather than both, but that's debatable.21:18
*** gizero <gizero!> has quit IRC21:23
*** Crofton|work <Crofton|work!> has joined #yocto21:28
*** Jefro <Jefro!~jefro@> has joined #yocto21:28
*** Jefro1 <Jefro1!~jefro@> has joined #yocto21:29
kergothRP: indeed, seems to show this behavior. not ideal, means there's no reuse at all between host distros. too late in the cycle to do much about it, of course. i'll open a bug for post-1.721:29
blloydrburton: I didn't think it was very awesome.  I was kinda surprised that he was interested.  However, seems Geode LX hasn't worked well with Yocto in the past.21:30
gebreselaisihi guys21:32
gebreselaisiwho should provide ?21:32
*** frsc_ <frsc_!> has quit IRC21:32
blloydanyone know if there is a package in yocto that provides the setterm program?  Or if there is a better way to control things like screen blanking?21:32
*** Jefro <Jefro!~jefro@> has quit IRC21:33
*** RP2 <RP2!> has joined #yocto21:34
RPkergoth: ah, this does explain it. THe trouble is it can't even unpack that sstate file without pseudo since the users may get messed up :(21:34
kergothah! that makes sense21:35
kergothtime to poke at uninative, methinks :)21:35
* kergoth has that on the todo already to play with it21:35
RPkergoth: well, it kind of makes sense, if it were shadow-native rather than pseudo-native but the general idea applies...21:35
kergothi trimmed the log, it's both shadow and pseudo21:36
* kergoth nods21:36
RPor it were avahi:do_package which does need pseudp-native21:36
RPbut yes, uninative is our hope here21:36
gebreselaisiCannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so21:36
gebreselaisianybody knows what package should provide that lib?21:36
rburtongebreselaisi: is it saying it can't find that module, or that module is linking to something else that doesn't exist?21:37
gebreselaisirburton, I do not have that library in my rootfs21:38
gebreselaisiand the rror is that from above: Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so21:39
gebreselaisiso I guess it means that it cannot find the module21:39
gebreselaisiI've googled around and apparently that should come from some alsa-plugins package21:39
gebreselaisiwhich I do not find in yocto21:39
*** Crofton|work <Crofton|work!> has quit IRC21:40
rburtongebreselaisi: feel free to steal
*** sarahsharp <sarahsharp!~sarah@> has quit IRC21:44
*** Crofton|work <Crofton|work!> has joined #yocto21:45
gebreselaisirburton, thanks21:46
*** smartin_ <smartin_!> has quit IRC21:47
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC21:48
JaMa|OffRP: would it make sense to change populate-sysroot conflicts to use package_qa_handle_error function so it would be fatal QA error (by default) with option to disable it?21:51
JaMa|OffRP: I think part of this problem was that normal bb.warn messages are less visible than QA messages (which are also collected in qa.log) so easy to check after the build21:52
RPJaMa|Off: To be honest, I don't want people to turn that on off. The issues are too nasty21:54
JaMa|OffOK, fair enough, I agree it's nasty21:55
JaMa|Offit's last 6 failures in world builds (after including all my pending fixes), I've sent the list earlier today21:56
RPJaMa|Off: if it stops there and then, the issue can usually be recovered. If you continue past that you no longer know what in the sysroot is corrupted21:56
JaMa|Offthe problem is that if I go with PNBLACKLIST (to blacklist one from the conflicting duo) then I'm blacklisting something which alone is fine (unless you're building the other recipe as well)21:57
JaMa|Offe.g. Paul won't be happy if I blacklist modphp, just because it conflicts with php and vice-versa21:58
*** Jefro1 <Jefro1!~jefro@> has quit IRC21:58
*** bfederau <bfederau!> has quit IRC22:01
*** bfederau <bfederau!> has joined #yocto22:01
*** Jefro <Jefro!~jefro@> has joined #yocto22:03
*** zecke <zecke!~ich@> has quit IRC22:04
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto22:07
*** sarahsharp <sarahsharp!~sarah@> has joined #yocto22:09
rburtonJaMa|Off: blacklisting both php and modphp is clearly the answer, and improves the world22:19
JaMa|Offshould I send patch for oe-core to blacklist xz and lzma as well? :)22:21
*** agust <agust!> has quit IRC22:39
*** sjolley <sjolley!~sjolley@> has quit IRC22:47
*** hsychla <hsychla!> has quit IRC22:57
*** dse <dse!~d.s.e@2001:a60:1468:d601:c924:9137:a0dc:bbea> has quit IRC23:02
*** RP2 <RP2!> has quit IRC23:09
*** tomz_ <tomz_!~tomz@> has quit IRC23:11
*** sjolley <sjolley!sjolley@nat/intel/x-gvusmqjnpdsvyvsi> has joined #yocto23:14
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC23:42

Generated by 2.11.0 by Marius Gedminas - find it at!