Monday, 2015-08-24

*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto00:07
*** phantoneD <phantoneD!> has joined #yocto00:32
*** phantoxeD <phantoxeD!> has quit IRC00:36
*** Mohican <Mohican!~Doug@> has joined #yocto00:50
*** Mohican <Mohican!~Doug@> has quit IRC01:00
*** likewise <likewise!> has joined #yocto01:22
*** likewise <likewise!> has quit IRC01:26
*** phantoxeD <phantoxeD!> has joined #yocto01:32
*** phantoneD <phantoneD!> has quit IRC01:36
*** bigwyrm <bigwyrm!~wyrm@> has quit IRC01:58
*** bigwyrm <bigwyrm!~wyrm@> has joined #yocto02:10
*** phantoneD <phantoneD!> has joined #yocto02:32
*** phantoxeD <phantoxeD!> has quit IRC02:36
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC02:51
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC03:02
*** dlan <dlan!~dennis@> has joined #yocto03:03
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto03:03
*** likewise <likewise!> has joined #yocto03:23
*** likewise <likewise!> has quit IRC03:27
*** behanw <behanw!> has quit IRC04:06
*** behanw <behanw!> has joined #yocto04:08
*** Jefro <Jefro!> has joined #yocto04:13
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto04:15
*** hitlin37 <hitlin37!uid16371@gateway/web/> has joined #yocto04:27
*** [Sno] <[Sno]!> has quit IRC04:57
*** hamis <hamis!~irfan@> has joined #yocto05:09
*** grma <grma!> has quit IRC05:09
*** AndersD <AndersD!> has joined #yocto05:11
*** zecke <zecke!> has joined #yocto05:13
*** likewise <likewise!> has joined #yocto05:24
*** likewise <likewise!> has quit IRC05:28
*** LocutusOfBorg1 <LocutusOfBorg1!> has joined #yocto05:32
*** em|fb <em|fb!> has quit IRC05:45
*** sujith_h <sujith_h!~sharidas@kde/developers/sujithh> has joined #yocto06:00
*** frsc <frsc!~frsc@> has joined #yocto06:18
*** jku <jku!jku@nat/intel/x-pjhhztagohjezdcj> has joined #yocto06:28
*** LocutusOfBorg1 <LocutusOfBorg1!> has quit IRC06:30
*** nighty^ <nighty^!> has joined #yocto06:32
*** pohly <pohly!> has joined #yocto06:34
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto06:42
*** [Sno] <[Sno]!> has joined #yocto06:46
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto06:51
*** jbrianceau_away is now known as jbrianceau06:52
*** noraply <noraply!> has joined #yocto07:06
*** noraply <noraply!> has quit IRC07:08
*** noraply <noraply!> has joined #yocto07:08
*** hitlin37 <hitlin37!uid16371@gateway/web/> has quit IRC07:12
*** fredcadete <fredcadete!d4a63893@gateway/web/freenode/ip.> has joined #yocto07:17
*** egavinc <egavinc!> has joined #yocto07:17
*** Jefro <Jefro!> has quit IRC07:18
*** ant_work <ant_work!> has joined #yocto07:19
*** AzaToth <AzaToth!~AzaToth__@wikipedia/AzaToth> has joined #yocto07:20
*** egavinc <egavinc!> has quit IRC07:22
*** egavin <egavin!> has joined #yocto07:22
*** belen <belen!Adium@nat/intel/x-tylomatqeydrnfuc> has joined #yocto07:22
*** joseppc <joseppc!> has joined #yocto07:23
*** likewise <likewise!> has joined #yocto07:25
*** likewise <likewise!> has quit IRC07:29
*** sameo <sameo!~samuel@> has joined #yocto07:30
*** behanw <behanw!> has quit IRC07:39
*** psnsilva <psnsilva!> has joined #yocto07:41
*** roccof <roccof!> has joined #yocto07:41
*** TobSnyder <TobSnyder!> has joined #yocto07:47
*** topik <topik!> has joined #yocto07:55
topikhey, has anyone stumbled on a circular dependency error on
topikapparently it used to be problem with intel-iot-devkit but i'm not using that07:56
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC07:58
*** bluelightning <bluelightning!~paul@> has joined #yocto08:03
*** bluelightning <bluelightning!~paul@> has quit IRC08:03
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:03
*** sameo <sameo!~samuel@> has quit IRC08:06
*** zwerch <zwerch!> has joined #yocto08:09
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto08:15
*** jimBaxter <jimBaxter!> has joined #yocto08:18
*** malkauns <malkauns!> has quit IRC08:18
*** dieter_ <dieter_!> has joined #yocto08:20
*** dieter__ <dieter__!> has joined #yocto08:20
*** dieter_ <dieter_!> has quit IRC08:21
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-bncchaodqhkjrjvn> has joined #yocto08:22
*** jonathanmaw <jonathanmaw!> has joined #yocto08:22
*** igor <igor!~Igor_Stop@> has joined #yocto08:23
bluelightningmorning all08:29
*** florian_kc is now known as florian08:41
*** malkauns <malkauns!> has joined #yocto08:41
*** sameo <sameo!~samuel@> has joined #yocto08:42
zwerchgood morning :)08:47
*** zwerch1 <zwerch1!~Adium@> has joined #yocto08:54
*** zwerch2 <zwerch2!> has joined #yocto08:56
*** zwerch <zwerch!> has quit IRC08:56
*** zwerch1 <zwerch1!~Adium@> has quit IRC08:59
*** zwerch2 <zwerch2!> has quit IRC08:59
*** zwerch <zwerch!> has joined #yocto09:00
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-bncchaodqhkjrjvn> has left #yocto09:12
*** zecke <zecke!> has quit IRC09:12
*** malkauns <malkauns!> has quit IRC09:12
nerdboysame thing over here...09:12
*** jeremiah <jeremiah!~jeremiah@> has joined #yocto09:18
jeremiahIs there a separate IRC channel for OE?09:18
jeremiahI'm hoping to speak to the maintainer of the perl layers for OE09:18
jeremiahand I wonder if it is best to try here or somewhere else.09:19
jeremiahThe yak I wish to shave is why are there two perl versions given for perl in in yocto 1.7 (perl 5.20.0 and 5.14.2)09:20
bluelightningjeremiah: there is #oe yes09:20
*** LocutusOfBorg1 <LocutusOfBorg1!> has joined #yocto09:21
jeremiahbluelightning: Thanks, I guess I'll hop over there. :-)09:21
*** sameo_ <sameo_!samuel@nat/intel/x-ihqgwwyllggzqjez> has joined #yocto09:24
*** sameo <sameo!~samuel@> has quit IRC09:24
*** zecke <zecke!> has joined #yocto09:30
*** malkauns <malkauns!> has joined #yocto09:37
*** milan_ <milan_!~milan@> has joined #yocto10:09
*** malkauns <malkauns!> has quit IRC10:11
milan_bluelightning: I want to add "TARGET_CC_ARCH_append_pn-<package> = " -fPIC -pie " to all packages of a packagegroup. Can I do it with a bbappend for the file, instead of changing each package recipe ?10:12
bluelightningmilan_: I'm afraid not; one recipe cannot influence the build process of another in that way10:13
milan_Is it at all possible to achieve this for a particular image ? I do not want to affect other images (using the same packages) with this change. Probably that's why I am not able to add this to distro.conf file as well :(10:16
milan_bluelightning : Would appreciate any advice on the above scenario10:21
bluelightningthere are only two practical ways really - have two recipes (perhaps sharing a common inc file) that deploy differently named packages that you can select from the image; or, completely separate builds with separate distro configurations10:23
zwerchI am currently working on cleaning up my system on the machine, and I have some packages I absolutely do not need. For example "avahi-daemon". But opkg says it is depended upon by some packages: packagegroup-base-zeroconf & libnss-mdns. Is there a way to overwrite these dependencies and force bitbake to not install them at all?10:24
milan_bluelightning : thanks10:26
*** rburton <rburton!> has joined #yocto10:26
*** zecke <zecke!> has quit IRC10:29
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto10:30
bluelightningzwerch: have a look at the packagegroup-base recipe and see how those packagegroups come in - it's all based on MACHINE_FEATURES and DISTRO_FEATURES, so you should set those appropriately10:33
bluelightningzwerch: mostly it'll be about DISTRO_FEATURES10:33
*** LocutusOfBorg1 <LocutusOfBorg1!> has quit IRC10:36
*** ant__ <ant__!> has joined #yocto10:43
*** malkauns <malkauns!> has joined #yocto10:45
*** ant_work <ant_work!> has quit IRC10:46
*** LocutusOfBorg1 <LocutusOfBorg1!> has joined #yocto10:48
*** xulfer <xulfer!~xulfer@2001:41d0:2:5ee0::> has quit IRC10:49
*** erbo <erbo!> has quit IRC10:50
*** tingleby <tingleby!> has quit IRC10:51
*** rperier <rperier!~quassel@2001:41d0:52:100::44a> has quit IRC10:51
*** ndec <ndec!~ndec@linaro/ndec> has quit IRC10:51
*** rperier <rperier!~quassel@2001:41d0:52:100::44a> has joined #yocto10:53
*** ndec <ndec!~ndec@linaro/ndec> has joined #yocto10:53
*** malkauns <malkauns!> has quit IRC10:54
*** pegu` <pegu`!> has joined #yocto10:55
*** xulfer <xulfer!~xulfer@2001:41d0:2:5ee0::> has joined #yocto10:57
*** pegu <pegu!> has quit IRC10:59
*** tingleby <tingleby!> has joined #yocto10:59
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC11:02
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto11:03
zwerchbluelightning: thanks, I'll have a look11:04
*** erbo <erbo!> has joined #yocto11:06
*** mcfrisk <mcfrisk!> has joined #yocto11:07
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC11:08
*** zecke <zecke!> has joined #yocto11:10
mcfriskHi! I'm trying to do static code analysis with CodeSonar on yocto, using codesonar's compiler wrapper. Is there a way I can wrap all do_compile funcions with this compiler wrapper? I could extend base.bbclass to run oe_runmake with codesonar wrapper but that would not match custom do_compile's in various recipes.11:10
*** JaMa <JaMa!> has joined #yocto11:10
AzaTothAnyone knows where "watchdog watchdog0: watchdog did not stop!" comes from, and how to disable it spamming logs?11:11
zwerchAzaToth: obviously from some watchdog ^^ maybe have a look at your /etc/watchdog.conf (if it exists)11:12
joseppcAzaToth: probably it has the magic close feature11:14
zwerchbluelightning: the base for my image is the core-x11 image, but I can't find packagegroup-base-zeroconf anywhere :(11:15
bluelightningmcfrisk: hmm... I suspect you'd prepend CC or something like that in order to have the wrapper invoked11:15
bluelightningzwerch: packagegroup-base-zeroconf is a package produced from the packagegroup-base recipe that I mentioned earlier - meta/recipes-core/packagegroups/packagegroup-base.bb11:16
AzaTothjoseppc, what's the magic close feature?11:16
zwerchbluelightning: yeah I know, already found it's declaration, but how can I exclude this packagegroup from packagegroup-base without rewriting it?11:17
AzaTothzwerch, we've enabled the watchdog chip in the kernel config, but we've no watchdog.conf11:17
zwerchbluelightning: ooooooh never mind11:17
mcfriskbluelightning: actually I could just call "codesonar analyze bitbake image_name", but codesonar doesn't know how to split results after compiling like this. With Coverity the analysis results can be post-processed and split to recipies based on source file locations in the build tree.11:17
zwerchbluelightning: I think I got it, thanks so much11:17
joseppcAzaToth: to start the WD you open the device, normally it is disabled if you close the file descriptor. With the magic close the WD keeps ticking even after the file is closed11:18
zwerchAzaToth, then maybe this is the problem. Try installing the watchdog package and enable it's hardware-device11:18
joseppcAzaToth: at least unless you write the "magic string", which is the V character to the file, then the WD will be disabled upon closing the fd11:18
AzaTothlooking; thanks11:19
mcfriskbluelightning: ... so I'd like a way to run all do_compile's with the 'codesonar analyze ${DISTRO}_${PN} do_compile'11:19
*** raykinsella78 <raykinsella78!~rkinsell@> has joined #yocto11:20
zwerchAzaToth: one of the patches applied uses /dev/watchdog as hardware watchdog device11:20
bluelightningmcfrisk: I'm not sure you can easily do that, that I know of... I guess you could do something like do_compile_prepend() { codesonar analyse ... ( } do_compile_append() { ) }, but I really don't know that that will work or even parse for that matter11:21
bluelightningmcfrisk: another hacky way around it would perhaps to be use anonymous python to grab the value of do_compile, set that as another function, then set do_compile_prepend() to call that function within the wrapper and then exit11:23
AzaTothzwerch, ah11:24
mcfriskbluelightning: the prepend&append I could try out, maybe with a here text though it does feel really hacky too.11:24
mcfriskhow does that anonymous python thing work, any examples I could have a look at?11:25
bluelightningmcfrisk: right, and whether it works is going to be dependent on your append/prepend being applied last11:26
*** raykinsella78 <raykinsella78!~rkinsell@> has quit IRC11:27
bluelightningmcfrisk: git grep 'python \(__anonymous \)\?() {'11:29
bluelightning(the __anonymous is optional, I believe the modern convention is not to include it)11:29
mcfriskhmm, all of these depend on the order of execution, when is the anonymous python thing executed? When parsing the recipe?11:31
*** rperier <rperier!~quassel@2001:41d0:52:100::44a> has quit IRC11:42
*** rperier <rperier!~quassel@ubuntu/member/rperier> has joined #yocto11:42
*** zecke <zecke!> has quit IRC11:50
-YoctoAutoBuilder- build #454 of nightly-qa-skeleton is complete: Failure [failed Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #454 of nightly-qa-pam is complete: Failure [failed Running Sanity Tests] Build details are at
ericbutt1rshi.. i am interested in the testimage stuff.. but i do not want to boot the target and deploy stuff. i only want to get the tests generated and afterwards run them from a different machine. is there a way to get rid of the masterimage stuff.. only getting the tests?11:56
milan_bluelightning: If I add a DISTROOVERRIDES in an file, should it affect the included packages for that image this way ?11:57
*** grma <grma!> has joined #yocto11:59
*** malkauns <malkauns!> has joined #yocto11:59
milan_rburton: But when I run bitbake  -e image, I can see the DISTROOVERRIDES included in to the overrides list! Not sure why it should not reflect for the listed packages under it.12:01
*** tasslehoff <tasslehoff!~Tasslehof@> has joined #yocto12:02
rburtonmilan_: it won't rebuild the recipes though12:02
*** zecke <zecke!> has joined #yocto12:02
*** grma <grma!> has quit IRC12:06
*** fredcadete <fredcadete!d4a63893@gateway/web/freenode/ip.> has quit IRC12:06
*** grma <grma!> has joined #yocto12:07
milan_rburton: Will it make sense to add "SSTATE_DISABLE="1" as well into the image file here ?12:07
milan_Hope that should help rebuild all the packages12:07
rburtonyou can't manipulate distro-wide settings from inside an image12:09
rburtoninside the image recipe any changes you make are specific to the image recipe12:09
milan_rburton: My changes are focussed on a particular image ( meant for a specific customer). Hope I am on the right path then ?12:11
milan_I dont want it to be reflected across all images of the distro12:11
-YoctoAutoBuilder- build #455 of nightly-x32 is complete: Failure [failed Running Sanity Tests_1] Build details are at
zwerchHow can I delete some DISTRO_FEATURES without rewriting them completely?12:22
*** challinan <challinan!> has joined #yocto12:23
bluelightningmilan_: as I said earlier, you simply cannot do things the way you're trying to do them - you cannot influence the build one recipe from another - i.e. you can't make these changes from the packagegroup or the image recipe12:24
rburtonzwerch: DISTRO_FEATURES_remove, if you have a recent enough OE12:24
zwerchrburton: is 1.7 recent enough?12:24
zwerchnice, thansk12:25
zwerchCan I do this in the image / layer.conf or does it have to be done in the local.conf?12:26
bluelightningzwerch: local.conf or custom distro config (preferably the latter)12:27
bluelightningzwerch: doing things like that in the layer.conf is evil12:28
zwerchOkay, thanks12:28
zwerchI still don't get when to use which conf ^^12:29
bluelightninglocal.conf is for local settings, the less you put in there the better (it's supposed to be something you create for the specific install and completely replicable without having to put it into version control)12:30
bluelightninganything that is "policy" about how the system is built i.e. which recipes to select, what options to enable, etc. should go into the custom distro config that you point to from DISTRO12:31
zwerchokay, then we did it intuitively right :) thanks12:32
bluelightningthe layer.conf should just add the paths such that items in the layer can be found and set the priority, and that's pretty much it12:33
zwerchso, our DISTRO is by default set to "poky", where do I find the distro config (and how do I append it)?12:38
*** zecke <zecke!> has quit IRC12:39
*** AzaToth <AzaToth!~AzaToth__@wikipedia/AzaToth> has quit IRC12:40
*** AzaToth_ <AzaToth_!> has joined #yocto12:40
*** Crofton <Crofton!> has quit IRC12:42
zwerchAh, I found the poky.conf, but how can I create a new distro that inherits from poky.conf? Or just plain copy the file?12:43
zwerchCan I just use the "poky-bleeding.conf" and copy it?12:47
zwerchAnd then simply set my DISTRO in the layer.conf?12:47
milan_bluelightning: Does SSTATE_DISABLE="1" force all dependencies to be re-built ?12:52
*** lamego <lamego!lamego@nat/intel/x-yjndrqdjsbgnqdmb> has joined #yocto12:56
*** pohmelie <pohmelie!bca2400e@gateway/web/freenode/ip.> has joined #yocto12:58
bluelightningmilan_: I don't think it will no12:59
bluelightningzwerch: you can do either of those13:00
bluelightningzwerch: you may wish to read
pohmelieHi, everyone! Where can I read documentation for matchbox? Where is config files, what can I config, etc…13:00
zwerchbluelightning: thanks!13:02
*** fredcadete <fredcadete!d4a63893@gateway/web/freenode/ip.> has joined #yocto13:02
zwerchpohmelie: this is the recipe (or the one in of the branches), there is a homepage, you should be able to get some information there13:04
pohmeliezwerch: just a mirror for yocto page, which has no information I need. Recepie also have no information about configuring.13:07
*** Nilesh_ <Nilesh_!~nilesh@> has joined #yocto13:09
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto13:10
*** aehs29 <aehs29!aehernan@nat/intel/x-wwqlcmmevswkocbz> has joined #yocto13:10
zwerchpohmelie: you are right, sorry, but I could find a reference here, which was not helpful because it didn't load. But I found this, maybe it helps you:
pohmeliezwerch: thanks ;)13:15
zwerchpohmelie: but there seem not to be that many options :D13:16
*** zecke <zecke!> has joined #yocto13:18
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto13:21
*** aehs29 <aehs29!aehernan@nat/intel/x-wwqlcmmevswkocbz> has quit IRC13:21
pohmeliezwerch: Wow, it is just what I looking for! Great!13:22
*** jku <jku!jku@nat/intel/x-pjhhztagohjezdcj> has quit IRC13:23
*** milan_ <milan_!~milan@> has quit IRC13:28
*** ntl <ntl!> has joined #yocto13:35
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has joined #yocto13:40
*** smartin_ is now known as smartin13:45
*** scot <scot!~scot@> has joined #yocto13:46
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-xqokecsrvqiwfewo> has joined #yocto13:48
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-xqokecsrvqiwfewo> has left #yocto13:52
*** AndersD <AndersD!> has quit IRC13:52
CardoeI’m wondering what the proper SRCREV and PV for a package is that’s from git but I’m trying to build an RC tag?13:53
CardoeDo I use the commit-ish fully or the tag?13:53
*** behanw <behanw!> has joined #yocto13:56
zwerchCardoe: if your recipe is named it's correct14:00
zwerchCardoe: more information on fetching code is here:
bluelightningi.e. if you do use the RC version in PV, then do it in the manner described so that you don't get the version seemingly going backwards when you upgrade to the final release14:02
*** aehs29 <aehs29!~aehernan@> has joined #yocto14:03
bluelightningCardoe: also, use the full commit hash in SRCREV, and specify the branch it comes from in branch= in SRC_URI (if it's not a commit that's on master)14:03
*** tsramos <tsramos!tsramos@nat/intel/x-yiriywtczspkqrhp> has joined #yocto14:03
CardoeIt’s on master14:03
CardoeI’m trying to clean up Xen in meta-virtualization14:03
zwerchCardoe: you should not use master in production stuff14:04
CardoeThis isn’t for production.14:04
zwerchCardoe: just saying ^^14:04
Cardoemeta-virtualization has their on some random Xen 4.4 master commit.14:04
CardoeIt has as well14:04
CardoeAnd then it has pulled out “common” bits into xen.inc14:04
zwerchYou can also use ${AUTOREV} variable14:05
CardoeI’m trying to get ready for Xen 4.6.0 to drop (its only at 4.6.0-rc1 right now)14:05
bluelightningzwerch: well, SRCREV = "${AUTOREV}" in a layer you publish for others is generally frowned upon14:06
zwerchbluelightning: I know, but he said it's not for production14:06
bluelightningzwerch: even so14:07
CardoeWell I’m looking to update meta-virtualization’s to be at least 4.6.014:09
*** opennandra <opennandra!> has quit IRC14:12
Cardoebluelightning: thanks14:14
*** madisox <madisox!> has joined #yocto14:15
*** grma <grma!> has quit IRC14:16
*** alimon <alimon!~alimon@> has joined #yocto14:17
*** dcyrille18 <dcyrille18!59fb345d@gateway/web/freenode/ip.> has joined #yocto14:21
dcyrille18Hi all ! I've got a problem with Yocto. The /sys/class/gpio directory, subdirectories and files have root:root owner:group with 744/644 rights. Do you now a way to change these for a user without use sudo. Or most simply, to add the gpio sysfs subdirectories on another group ? Thanks in advance.14:29
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC14:32
zwerchdcryille18: if you know which recipe is responsible for the directory (i assume one of the following you can bbappend it and add a chroot or chmod to do_install_append()14:32
*** hamis <hamis!~irfan@> has quit IRC14:32
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC14:32
*** pohmelie <pohmelie!bca2400e@gateway/web/freenode/ip.> has quit IRC14:34
*** Nilesh_ <Nilesh_!~nilesh@> has quit IRC14:38
bluelightningzwerch: I don't think that's going to help, this will be something generated by a kernel driver14:40
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-qjwdipnzvdwrloxh> has joined #yocto14:40
dcyrille18Yes, I've configured my kernel to add gpio on sysfs. But all rights are root and unexecutable by users.14:41
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-qjwdipnzvdwrloxh> has left #yocto14:41
dcyrille18Do you known a way to add gpio sysfs directories on a dedicated group ?14:42
bluelightningI don't, if you're asking me14:43
bluelightningI suspect it's more of a generic Linux thing than specific to our system though14:43
bluelightningit's possible you might be able to do it through udev, but that's really more for /dev/ nodes even if it can match on sysfs nodes14:44
*** frsc <frsc!~frsc@> has quit IRC14:47
*** tasslehoff <tasslehoff!~Tasslehof@> has quit IRC14:47
*** ka6sox is now known as zz_ka6sox14:48
*** zz_ka6sox is now known as Guest8088514:49
dcyrille18Ok, thanks anyway :-/14:51
dcyrille18I'm regarding to use udev :)14:51
*** belen1 <belen1!~Adium@> has joined #yocto14:52
*** belen <belen!Adium@nat/intel/x-tylomatqeydrnfuc> has quit IRC14:53
*** afxez0r <afxez0r!~afxez0r@> has joined #yocto14:57
*** zwerch <zwerch!> has left #yocto14:58
*** behanw <behanw!> has quit IRC14:58
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC15:00
*** 7GHAA056D <7GHAA056D!> has joined #yocto15:04
*** armpit <armpit!~akuster@2601:202:4000:1239:e17c:4679:6483:8991> has joined #yocto15:05
*** belen1 <belen1!~Adium@> has quit IRC15:35
*** sjolley <sjolley!sjolley@nat/intel/x-ryufbsaxmkbwfuon> has quit IRC15:40
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC15:43
*** dmoseley <dmoseley!> has quit IRC15:45
*** nerdboy <nerdboy!> has joined #yocto15:45
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto15:46
*** psnsilva <psnsilva!> has quit IRC15:48
*** dmoseley <dmoseley!> has joined #yocto15:56
*** tsramos_ <tsramos_!~tsramos@> has joined #yocto15:56
*** moto_timo <moto_timo!> has quit IRC15:56
*** sameo_ <sameo_!samuel@nat/intel/x-ihqgwwyllggzqjez> has quit IRC15:56
*** moto-timo <moto-timo!~timo@fsf/member/moto-timo> has joined #yocto15:57
*** tsramos <tsramos!tsramos@nat/intel/x-yiriywtczspkqrhp> has quit IRC15:58
*** afxez0r <afxez0r!~afxez0r@> has quit IRC16:01
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC16:02
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto16:04
*** fredcadete <fredcadete!d4a63893@gateway/web/freenode/ip.> has quit IRC16:09
*** behanw <behanw!~behanw@> has joined #yocto16:09
*** sjolley <sjolley!sjolley@nat/intel/x-undyssthddcxxdbv> has joined #yocto16:10
*** afxez0r <afxez0r!~afxez0r@> has joined #yocto16:19
*** likewise <likewise!> has joined #yocto16:20
*** jonathanmaw <jonathanmaw!> has quit IRC16:22
*** grma <grma!> has joined #yocto16:25
*** dfaught <dfaught!> has joined #yocto16:26
*** TobSnyder <TobSnyder!> has quit IRC16:26
rburtonkhem: your six patch series to oe-core over the weekend appears to be missing part 2.  is it in a branch somewhere?16:31
*** madisox <madisox!> has quit IRC16:36
*** madisox <madisox!> has joined #yocto16:36
*** madisox <madisox!> has quit IRC16:43
*** roccof <roccof!> has quit IRC16:43
*** behanw <behanw!~behanw@> has quit IRC16:46
*** vdehors <vdehors!> has quit IRC16:47
*** ant__ <ant__!> has quit IRC16:52
*** afxez0r <afxez0r!~afxez0r@> has quit IRC16:54
*** afxez0r <afxez0r!~afxez0r@> has joined #yocto16:58
*** jbrianceau is now known as jbrianceau_away17:00
*** tsramos_ <tsramos_!~tsramos@> has quit IRC17:02
*** tsramos <tsramos!tsramos@nat/intel/x-aauwyjtqkpsuuysh> has joined #yocto17:03
*** Jefro <Jefro!> has joined #yocto17:04
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:05
*** challinan <challinan!> has quit IRC17:05
*** belen1 <belen1!Adium@nat/intel/x-ucqeoflnktfxmzbb> has joined #yocto17:06
*** challinan <challinan!> has joined #yocto17:07
*** Jefro <Jefro!> has quit IRC17:10
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto17:10
*** belen1 <belen1!Adium@nat/intel/x-ucqeoflnktfxmzbb> has quit IRC17:13
*** radzy <radzy!> has quit IRC17:23
*** JaMa <JaMa!> has quit IRC17:23
*** [Sno] <[Sno]!> has quit IRC17:24
*** radzy_lunch <radzy_lunch!> has joined #yocto17:27
*** radzy_lunch is now known as radzy17:27
*** Jefro <Jefro!> has joined #yocto17:29
*** paulg_ <paulg_!~paulg@> has quit IRC17:54
*** benjamirc <benjamirc!~besquive@> has joined #yocto17:59
*** sameo_ <sameo_!~samuel@> has joined #yocto18:02
*** Jefro <Jefro!> has quit IRC18:03
*** varibull <varibull!> has joined #yocto18:05
*** varibull <varibull!> has joined #yocto18:05
*** Jefro <Jefro!> has joined #yocto18:06
*** belen <belen!> has joined #yocto18:08
*** belen <belen!> has quit IRC18:11
*** Jefro <Jefro!> has quit IRC18:20
fishey1bitbake issue: I'm using the gitsm fetcher with the same URL in a number of different .bb files. Every now and then, all of the fetches of that gitsm url appear to fail in the bitbake code around where .gitmodules is retrieved18:22
fishey1It looks like a simple race: we move the git repo to grab .gitmodules, but at the same time others are trying to do similar things18:22
fishey1so the question: Is there a locking mechanism I can use in the gitsm fetcher to fix this?18:23
*** sameo_ <sameo_!~samuel@> has quit IRC18:30
*** grma <grma!> has quit IRC18:31
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC18:38
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC19:01
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto19:01
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:02
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has quit IRC19:06
*** pohly <pohly!> has quit IRC19:10
-YoctoAutoBuilder- build #10 of nightly-wic is complete: Failure [failed BuildImages CreateWicImages CreateWicImages_1 BuildImages_2 CreateWicImages_2 CreateWicImages_3] Build details are at
*** paulg <paulg!~paulg@> has joined #yocto19:16
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC19:17
*** paulg <paulg!~paulg@> has quit IRC19:20
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:20
*** paulg <paulg!~paulg@> has joined #yocto19:22
*** rburton1 <rburton1!> has joined #yocto19:22
*** rburton <rburton!> has quit IRC19:23
CardoeSo this might be a weird request but is it possible to include an image within an image?19:32
CardoeExact use case is for Xen. Building up a domU that’s then placed inside the dom0 so that I can boot the domU on startup.19:33
*** [Sno] <[Sno]!> has joined #yocto19:36
khemrburton1: hmm19:38
khemlet me push them to a  branch for ease of use19:39
*** [Sno] <[Sno]!> has quit IRC19:41
rburton1Cardoe: that's exactly what hddimgs are, so yes19:42
*** [Sno] <[Sno]!> has joined #yocto19:42
CardoeSo I’m building up 2 but I’m not sure how to include one wholesale into another one19:42
rburton1make one image depends on the other image's do_deploy task19:43
rburton1then during generation you copy the image from deploy dir into the other's image's staging directory19:43
Cardoeok that makes sense19:43
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC19:44
khemI have few more patches in there as well.19:44
rburton1thanks khem19:44
khembut thats the current list I would like to consider for master19:45
rburton1khem: can you send the new ones to the list?19:48
khemOK, I will create a pull request19:49
khemthat will be easy19:49
*** jimBaxter <jimBaxter!> has quit IRC19:53
*** likewise <likewise!> has quit IRC19:56
kergothDoes it annoy anyone else that we have a boneblack machine in three different layers?20:10
kergother, beaglebone machine, that is20:13
*** zecke <zecke!> has quit IRC20:22
* armpit should have one layer to bind them all20:27
*** jukkar2_ <jukkar2_!> has joined #yocto20:34
*** likewise <likewise!> has joined #yocto20:34
fishey1armpit: "build them all"20:35
*** jukkar2_ <jukkar2_!> has quit IRC20:37
*** likewise <likewise!> has quit IRC20:39
khemkergoth: it does21:04
khemkergoth: meta-bb is quite different it has cape support and many users still use it especially angstrom users21:05
kergothhuh, meta-ti doesnt' have cape support?21:06
khemkergoth: jason was to work on upstreaming that to kernel if it has happened then meta-bb wouldnt exist21:06
khemAFAIK no21:06
khemand meta-yocto-bsp is just trying to be BSP independent layer21:06
khemor rather vendor independent21:06
khemnot particularly pretty21:08
gholmsnerdboy: Oh, right, I was supposed to remind you about building a trimslice BSP.  Should we save that for the next hackfest/demo/whatever?21:09
khemI think it would be ideal if it picked machines that are fully supported in upstream components e.g. kernel toolchaine etc. and graphics too21:09
khemits possible for x86 only as of now reliably21:09
kergothhmm, that does seem odd, i'd think meta-yocto-bsp would be machines that are either 100% upstream, or machines whose vendors aren't directly supporting them themselves21:09
kergothotherwise it's too easy to be out of sync, and add confusion21:10
khemmay be meta-ti should just drop it21:10
khembut then binary graphics drivers :)21:10
khemideally we shouldnt even need linux-yocto as core kernel21:11
*** paulg <paulg!~paulg@> has quit IRC21:11
khemonly emulators supported upstream21:12
khemand some reference machines21:12
-YoctoAutoBuilder- build #448 of nightly-rpm is complete: Failure [failed Running Sanity Tests] Build details are at
* kergoth nods21:12
denixkergoth: correct, meta-ti doesn't have cape support - it is coming from upstream with 4.1/4.221:12
khemlinux-yocto has advantage for certain vendors which is a skew imo21:12
*** rburton1 <rburton1!> has quit IRC21:13
denixkergoth: and meta-yocto-bsp is indeed the reference bsp with everything that is already upstream, at least for beaglebone21:13
khemdenix: it adds to confusion why meta-ti should also have it21:13
denixkhem: should also have it what?21:14
*** paulg <paulg!~paulg@> has joined #yocto21:15
denixkergoth: reading a bit earlier - why do you say 3 layers? I only know 221:16
kergothmeta-ti, meta-beagleboard, and meta-yocto-bsp21:16
denixmeta-beagleboard is long since dead21:16
khemif cape support is coming to 4.1 then meta-bb might be able to drop it21:16
kergothnothing indicates this21:16
kergothnot hte readme, not the layer descriptions, nothing21:16
kergothif htey're obsolete, someone should mention it21:16
khemits still used in angstrom21:17
khemfor cape support reasons21:17
denixkergoth: this question is being raised every year and nothing changes21:17
moto-timoI have dim hope of getting meta-beagleboard up to date, but moved on to debian21:17
denixkergoth: - last commit was in 201321:18
moto-timoat least koen has been doing _some_ updates to angstrom21:19
denixthe only point of meta-bb was to carry over cape support from when it was initially developed for 3.2/3.8 until it accepted upstream.21:19
denixnobody estimated it would take that long, but it finally happened21:19
denixso, there's no reason to keep on dragging it further21:20
khemif it has landed in 4.1 upstream then I agree21:21
-YoctoAutoBuilder- build #112 of nightly-arm64 is complete: Failure [failed BuildImages Running Sanity Tests Building Toolchain Images Building Toolchain Images_1] Build details are at
*** ant_home <ant_home!> has joined #yocto21:23
denixcape support is rather very unorthodox...21:23
khemthere were large set of users of it so you just couldnt throw it out21:25
denixwell, many peripherals on modern SOCs are unusual, really, with all the accelerators, engines and other heterogeneous cores...21:25
denixbut, CircuitCo/koen picked up cape support and the rest was picked up by TI...21:27
denixsince then panto continued working to get it upstream, which is pretty much there with 4.1/4.221:28
denixand TI also contributed a lot to upstream, that's why meta-yocto-bsp can do basic BBB support from pure mainline21:28
khemyes, however, it would be good if we could really pick up ko kernel and build it21:29
khemfor ref BSP21:29
denixkhem: and why you can't?21:30
khemyou can, I am talking about recipes from meta-yocto-bsp21:30
khemsame for qemu machines in OE-Core21:31
denixkhem: meta-yocto-bsp does use pure ko kernel at least for bbb21:31
khemisnt it linux-yocto ?21:31
frayas far as I understand it, you can do that in master (or if not yet, will be able to soon)21:31
denixkhem: at least that's what I pushed back in 3.14 days - it was pure mainline21:32
khemthats good21:32
fraymaster has the metadata (config fragments) and constructed linux-yocto separated..  so they can be used independently21:32
denixkhem: linux-yocto is just a wrapper21:32
frayand linux-yocto is pretty much KO..21:32
khemI was talking to some kernel devs at plumbers and they said linux yocto was a fork21:32
frayit's like anything else.. KO + patches..21:32
fraybut the patches are targeted to boards, features, etc..21:33
khembut if its ko/linux-stable thats good to hear21:33
frayif you don't want hte patches you don't need them21:33
frayit's LTSI AFAIK21:33
denixkhem: different machines can add patches in linux-yocto, but in 1.6 there were no patches for bbb21:33
khemdenix: thats what I was eluding too21:33
fraydenix, that matches my understanding..21:33
khembuild ko kernel w/o patching21:34
khemwhich is true upstream21:34
frayyes.. and separating the metadata (kernel config) and the kernel source in (again I think master) allows that21:34
ant_homein my little experience, there is a long way to go in order to convince joe kernel developer to use linux-yocto21:34
frayit just means if you try to enable kernel configs that don't exist upstream you get stopped21:34
ant_homeI had to revert back to ko, back on popular request :/21:34
khemant_home: they dont bother unless you talk ko21:34
denixkhem: it does no patches for bbb. but linux-yocto wrapper was the requirement for oe-core/meta-yocto-bsp21:35
frayant_home, the issue is most developers don't support 1000 combinations.. so they don't see the immediate need that is solved21:35
kergothafaik linux-yocto's main advantage is maintainance of multiple bsps in a single tree with support for flowing common changes into them all. i've seen similar tools developed internally at companies. so your average developer probably *wouldnt'* see the ned21:35
fray(and I'm not kidding when I talk about 1000 or more combinations)21:35
khemfray: OE doesnt do that either21:35
ant_homehonestly I can only talk about old unsupported hw, maybe for new stuff it is different21:36
khemit enables someone to doso21:36
kergothbut for companies stuck on the bsp treadmill, such things are useful21:36
denixkhem: and due to linux-yocto complexity I had to add linux-mainline recipe, but I fail to update it regularly... :)21:36
khemdoesnt mean it should be default21:36
khemI was bantered by every dev to whomeever I said to use linux yocto21:36
fraydenix, then have a conversation with all of the board manufacturers out there and tell them to start working upstream.. :P21:36
ant_homethe risk with linux-yocto is to get stale happened to me twice...21:37
frayI don't think the KO developers understand that it's KO + patches.. what they often think is that it's a hacked up kernel..21:37
khemfray: they dont want to21:37
frayant_home, that is why the recommended method is reference clones..21:37
kergothi don't think those two are mutually exclusive. KO + patches can be pretty hacked up, dependign on what those patches are up to21:38
ant_homethe you loose the updates...21:38
fraykhem, thats fine.. and part of the reason the metadata was split form the kernel sources21:38
khemfor reference machines we should just have ko I am convinced21:38
fraykergoth, I consider the end results to be possibly hacked up.. but it's a lot cleaner way to handle it21:38
frayyou can at least see and unwind the hacks.. vs a lot of the board vendor kernels which are just tarballs of crap21:38
khemsome even did not trust out UAPIs21:38
khemwho knows how OE patches the kernel UAPIs21:39
khemwas the response21:39
fraygit log21:39
fraypart of the reason that it was done the way it was.. make things transparent to anyone who can use git21:39
frayvs .. "tarball of crap"21:39
khemkergoth: I see linux-yocto is good for OSVs or platform folks thats ok21:41
khembut ODMs dont have 1000 machines21:42
fraykhem, customers I've talked to that work with more then 1 platform on a common base.. they really like it21:42
khemthey usally have 2 to 421:42
khemfray that base could be linux-stable21:42
frayThese are customers who make common 'software' for usually 2-10 different boards... (often different architectures)21:42
khemyes I am in same boat21:42
fraybut for the guys working on a project with -1- board.. they don't like the overhead.. until they understand that the configuration patching is useful..21:42
fraybut usually they "get" it after the project is nearly done and they are down chasing problems in patches or trying to resync21:43
ant_homethe benefits of kern-tools and config checks are out of discussion. The 'dark' part are the common patches, not immediate to find (I was told so)21:45
-YoctoAutoBuilder- build #441 of nightly-deb is complete: Failure [failed Running Sanity Tests Running Sanity Tests_1 Running Sanity Tests_2] Build details are at
fraywell the common base is KO for all..  but with that said, the split of meta-data and source should be making it easier to see..21:46
fraybefore being intermingled had the effect of confusing people cause they saw a branch and thought it was the whole tree.. where it was just a fragment21:46
ant_homeso in the end I don't dare to send patches upstream based on linux-yocto...21:47
frayI don't think anyone has ever said linux-yocto should be the basis of KO work21:47
ant_homenot only for linux-next, even for stable21:48
seebsSo I have new-pseudo probably ready for more thorough testing. I am sort of going to recommend that we NOT enable the extended attribute database code by default yet, but it might be a good bet for autobuilds. I'd want a lot more burn-in time before using it in production.21:48
khemwith raspbian's success on rpi I still think cross compiling is still a voodoo and no matter how slow the machine is people still like feed based distros21:50
fraywell I don't think it's voodoo, but I know some people do..21:50
frayand feed based distros can easily be done with OE21:50
ant_homefray, in the case of new devices, with more than 1-2 active developers, it probably does make sense to invest in linux-yocto :)21:50
khemfray: it should be possible for upstream work21:50
fray(if my talk had been accepted, I'd have talked about it at ELC)21:50
khemOE is at that point where it should start fixing packages upstream21:51
*** Jefro <Jefro!> has joined #yocto21:51
fraykhem, that was the point of the upstream-status.. but frankly the resources to "force" it up is not there..21:51
frayand often the stuff is ignored by upstream (still) because they just don't care21:51
kergothor it's not even maintained anymore21:52
frayya that too21:52
fraybut reality is that people try.. but once you 'try' once.. things fall away quickly21:52
frayit's the laziness factor.. it's easier to contribute to OE then 1000 upstream projects..21:52
frayand with there being realistically only about a dozen maintainers within the OE world.. it's hard to convince people to contribute back to the 1000 upstreams21:53
kergothI should do a better job of it. I can't push stuff during crunch time, but when we work on a new release and i start pushing my backlog up to oe-core, i should push more direct to upstream at that time21:53
frayI don't mean for that to be an excuse, just reality.. something we need to keep working to improve.. (yocto project and OE)21:53
fraykergoth, thats what our guys are told to do..21:53
khemif we really have to improve on quality then this should be must, sometimes upstreams fixes the issues properly for things which we carry patches which may be workarounds etc.21:54
fray-everything- goes to OE, no exceptions..  upstream (above OE) when there is time.. exceptions being bintuils/gcc/kernel.. those always go back (if applicable)21:54
ant_homehappily now and then it just happens upstream devs are lured by some OE patches and get interested in OE21:54
kergothwe occasionally carry something through multiple releases, but it's usually when we know it belongs in oe-core, but it has to be completely reworked to be suitable there, so the hack stays local for a while21:55
khemI think devtool will help in component development and upstreaming effort21:55
kergothdevtool modify -x is pretty sweet21:55
fraydevtool stuff is still on my TODO list.. :/21:55
* kergoth devtool create-workspace; recipetool kernel_set_configs workspace CONFIG_USB_G_MULTI_CDC=y; bitbake virtual/kernel21:55
khemkergoth: why recipetool is not a subsystem of devtool ?21:56
kergothnot sure, paul would be the one to ask about the separation21:57
*** dfaught <dfaught!> has quit IRC21:58
*** Jefro <Jefro!> has quit IRC22:00
*** bfederau <bfederau!> has quit IRC22:01
*** fmeerkoetter <fmeerkoetter!> has quit IRC22:01
*** bfederau <bfederau!> has joined #yocto22:01
*** fmeerkoetter <fmeerkoetter!> has joined #yocto22:01
ant_homekhem: btw, about glibc, it seems buildroot carries some mips patches (not upstreamed) so that the two fine developers I'm trying to convert to OE/Yocto are still hesitating22:01
khemOK which ones22:03
khemwe can convert them22:03
ant_homeMXU simd22:03
ant_homealso binutils iirc22:04
frayI think the real question is what do the patches do, what cores do they affect.. :)22:04
ant_homebest would be someone from Imgtek jump in...22:04
frayI've seen some really nasty glibc patches in some other systems I'd hesitate to generically include22:04
*** sameo_ <sameo_!samuel@nat/intel/x-txmmqtrdwrfidbvw> has joined #yocto22:05
fray(I'm thinking of some "not to be named" vendor who makes a certain SDK... <shudder>)  breaking gcc behavior to eek out a slightly better artificial benchmark is a BAD way to go about life22:05
fraywhat you want predictable sign extensions?!  na..22:06
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto22:11
*** dmoseley <dmoseley!> has quit IRC22:12
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has quit IRC22:12
*** Jefro <Jefro!> has joined #yocto22:13
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC22:19
*** nighty^ <nighty^!> has quit IRC22:21
*** tsramos_ <tsramos_!tsramos@nat/intel/x-zutjointknbvskki> has joined #yocto22:25
*** tsramos <tsramos!tsramos@nat/intel/x-aauwyjtqkpsuuysh> has quit IRC22:28
*** lamego <lamego!lamego@nat/intel/x-yjndrqdjsbgnqdmb> has quit IRC22:29
*** tsramos_ <tsramos_!tsramos@nat/intel/x-zutjointknbvskki> has quit IRC22:30
*** likewise <likewise!> has joined #yocto22:31
*** paulg <paulg!~paulg@> has quit IRC22:31
kergothAnyone feel like poking at ? I could use testers other than myself to check sanity22:33
*** paulg <paulg!~paulg@> has joined #yocto22:35
*** aehs29 <aehs29!~aehernan@> has quit IRC22:37
-YoctoAutoBuilder- build #450 of nightly-qa-extras is complete: Failure [failed Running Sanity Tests BuildImages_1 Running Sanity Tests_1] Build details are at
*** aehs29 <aehs29!~aehernan@> has joined #yocto22:39
*** adelcast <adelcast!~adelcast@> has quit IRC22:41
*** adelcast <adelcast!~adelcast@> has joined #yocto22:44
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto22:50
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto22:52
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC22:53
kergothhmm, i should probably split the general bb.fetch bugfixes from the git shallow support for easier review22:57
* armpit knows Frey's SDK woes too well22:57
*** sgw_ <sgw_!> has quit IRC23:03
ntl$ git diff --shortstat v4.1.6...linux-yocto-4.1/standard/base23:03
ntl 271 files changed, 61963 insertions(+), 96 deletions(-)23:03
ntlthat's a fork :)23:04
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has joined #yocto23:15
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has quit IRC23:21
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has joined #yocto23:22
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto23:27
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC23:28
kergothntl: heh, indeed, that does seem substantial23:30
kergothHmm, wonder if we should switch to tar.xz or something for the git mirror tarballs eventually, though we'd need my multiple-mirror-tarball-support patch for compatibility23:31
-YoctoAutoBuilder- build #449 of nightly-intel-gpl is complete: Failure [failed BuildImages BuildImages_1] Build details are at
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC23:32
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has quit IRC23:33
*** sgw_ <sgw_!> has joined #yocto23:40
*** paulg <paulg!~paulg@> has quit IRC23:42
kergoththoughts on ?23:46
-YoctoAutoBuilder- build #456 of nightly-qa-pam is complete: Success [build successful] Build details are at
*** sjolley <sjolley!sjolley@nat/intel/x-undyssthddcxxdbv> has quit IRC23:49
-YoctoAutoBuilder- build #451 of nightly-qa-extras is complete: Success [build successful] Build details are at
kergothhmm, afaict bitbake-whatchanged no longer works, at least it's not very effective. it changes STAMPS_DIR, but STAMPS_DIR is in some task signatures now.23:54
* kergoth looks into what's pulling it in23:54
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto23:55 is pretty neat,23:56
kergothruntaskdeps changed from [''] to [''] ... seriously, bitbake?23:57
kergothRP: runtaskdeps changed from [''] to [''] in -S printdiff.23:57
-YoctoAutoBuilder- build #11 of nightly-wic is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #454 of nightly-qa-logrotate is complete: Success [build successful] Build details are at

Generated by 2.11.0 by Marius Gedminas - find it at!