Monday, 2016-10-10

*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto00:01
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC00:03
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto00:05
*** JordonWu <JordonWu!~quassel@> has joined #yocto00:24
*** rt90 <rt90!> has quit IRC00:42
*** sujith_h <sujith_h!~toaster@> has quit IRC00:43
*** seebs <seebs!~seebs@> has joined #yocto01:21
*** LetoThe2nd <LetoThe2nd!~jd@unaffiliated/letothe2nd> has quit IRC01:25
*** LetoThe2nd <LetoThe2nd!> has joined #yocto01:27
*** Tenhi_ <Tenhi_!~tenhi@> has quit IRC01:29
*** silviof1 <silviof1!> has quit IRC01:29
*** bradleyb <bradleyb!bradleyb@nat/ibm/x-hwtywfdhewvkcvdl> has quit IRC01:29
*** bradleyb <bradleyb!bradleyb@nat/ibm/x-etcboqqsuoujghsw> has joined #yocto01:29
*** seebs <seebs!~seebs@> has quit IRC01:30
*** bboozzoo_ <bboozzoo_!> has quit IRC01:30
*** JEEB <JEEB!~jeeb@unaffiliated/jeeb> has quit IRC01:30
*** Artox <Artox!~Artox@> has quit IRC01:30
*** seebs <seebs!~seebs@> has joined #yocto01:30
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC01:31
*** JEEB <JEEB!> has joined #yocto01:31
*** Tenhi_ <Tenhi_!> has joined #yocto01:36
*** Artox <Artox!~Artox@> has joined #yocto01:36
*** bboozzoo_ <bboozzoo_!> has joined #yocto01:39
*** silviof1 <silviof1!> has joined #yocto01:39
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto01:39
*** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has quit IRC02:03
*** dreyna <dreyna!~dreyna@> has joined #yocto02:04
-YoctoAutoBuilder- build #82 of nightly is complete: Failure [failed BitbakeSelftest] Build details are at http://localhost:8010/builders/nightly/builds/8202:12
*** manuel_ <manuel_!> has quit IRC03:27
*** manuel_ <manuel_!> has joined #yocto03:42
*** pohly1 <pohly1!> has joined #yocto03:44
*** sujith_h <sujith_h!~toaster@> has joined #yocto03:45
*** sujith_h <sujith_h!~toaster@kde/developers/sujithh> has joined #yocto03:45
*** pohly <pohly!> has quit IRC03:46
*** dreyna <dreyna!~dreyna@> has quit IRC04:10
*** Jefro <Jefro!~jefro@> has joined #yocto04:19
*** Jefro <Jefro!~jefro@> has quit IRC04:46
*** rt90 <rt90!> has joined #yocto04:50
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto05:08
*** armpit <armpit!~akuster@> has joined #yocto05:33
*** gtristan <gtristan!~tristanva@> has joined #yocto05:33
armpithalstead, ping05:34
halsteadHello armpit05:34
armpitoutside Riga to help setup05:34
armpitjefro said 7:3005:34
halsteadarmpit, I'm in Oregon but will be supporting today's effort as best I can. I think jefro will be there shortly.05:35
armpitoh, thought you where going to be here05:36
*** aurele <aurele!> has quit IRC05:38
halsteadarmpit, I'm not feeling well. I would have been completely worthless after a long flight.05:38
armpitah, take care of yourself05:38
*** manuel_ <manuel_!> has quit IRC05:42
*** Jefro <Jefro!~jefro@> has joined #yocto05:46
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto05:49
*** qt-x <qt-x!~Thunderbi@> has joined #yocto05:55
armpitJefro, do the rooms need help setting up?05:55
*** Jefro <Jefro!~jefro@> has quit IRC05:56
armpitsure.. run away05:56
*** Jefro <Jefro!~jefro@> has joined #yocto05:56
*** RP1 <RP1!~richard@> has quit IRC06:04
*** dreyna <dreyna!~dreyna@> has joined #yocto06:08
*** RP1 <RP1!~richard@> has joined #yocto06:16
*** RP1 is now known as RP06:16
*** gtristan <gtristan!~tristanva@> has quit IRC06:18
*** frsc <frsc!~frsc@> has joined #yocto06:19
*** rt90 <rt90!> has quit IRC06:19
*** mahesh <mahesh!~mahesh@> has joined #yocto06:20
*** Jefro <Jefro!~jefro@> has quit IRC06:22
*** sujith_h <sujith_h!~toaster@kde/developers/sujithh> has quit IRC06:24
*** TobSnyder <TobSnyder!> has joined #yocto06:29
*** sujith_h <sujith_h!~toaster@> has joined #yocto06:29
*** hamis <hamis!~irfan@> has joined #yocto06:30
*** mahesh <mahesh!~mahesh@> has quit IRC06:35
*** sujith_h_ <sujith_h_!~toaster@> has joined #yocto06:37
*** sujith_h <sujith_h!~toaster@> has quit IRC06:39
*** sujith_h_ is now known as sujith_h06:39
*** AndersD <AndersD!~anders@> has joined #yocto06:41
*** jonver <jonver!> has joined #yocto06:45
*** sjolley1 <sjolley1!~sjolley@> has quit IRC06:45
*** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has joined #yocto06:47
*** sjolley <sjolley!~sjolley@> has joined #yocto06:47
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto06:48
*** jbrianceau_away is now known as jbrianceau06:48
*** toscalix <toscalix!> has joined #yocto06:53
*** fl0v0 <fl0v0!> has joined #yocto06:58
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto06:58
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto06:58
*** gtristan <gtristan!~tristanva@> has joined #yocto07:03
*** csanchezdll <csanchezdll!> has joined #yocto07:12
*** rajm <rajm!> has joined #yocto07:13
*** fl0v0 <fl0v0!> has quit IRC07:13
sandsmarkare there any of the people working on meta-qt5 here?07:13
*** fl0v0 <fl0v0!> has joined #yocto07:14
sandsmarkin that case; are there any plans to make the sdk stuff work without having to run qtcreator from a terminal where you source the environment-setup script?07:14
*** sujith_h <sujith_h!~toaster@> has quit IRC07:16
*** sujith_h <sujith_h!~toaster@kde/developers/sujithh> has joined #yocto07:16
*** boucman_work <boucman_work!> has joined #yocto07:19
*** boucman_work <boucman_work!> has quit IRC07:20
*** boucman_work <boucman_work!> has joined #yocto07:20
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto07:21
*** toanju <toanju!~toanju@> has joined #yocto07:22
*** armpit <armpit!~akuster@> has quit IRC07:26
*** gtristan <gtristan!~tristanva@> has quit IRC07:27
*** marquiz <marquiz!~marquiz@> has joined #yocto07:27
*** marquiz <marquiz!~marquiz@> has joined #yocto07:27
*** jku <jku!~jku@2001:998:22:0:4e8d:79ff:fef2:49ba> has joined #yocto07:27
*** grma <grma!~gruberm@> has joined #yocto07:28
*** Crofton <Crofton!> has joined #yocto07:30
*** jku_ <jku_!jku@nat/intel/x-yhwvpatjuysabpph> has joined #yocto07:32
*** jku <jku!~jku@2001:998:22:0:4e8d:79ff:fef2:49ba> has quit IRC07:32
*** jku_ is now known as jku07:33
*** linulin <linulin!> has quit IRC07:37
*** linulin <linulin!> has joined #yocto07:38
*** sameo <sameo!~samuel@> has joined #yocto07:42
*** yann|work <yann|work!> has joined #yocto07:46
*** Crofton <Crofton!> has quit IRC07:46
*** ant_work <ant_work!~ant__@> has joined #yocto07:48
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC07:49
*** t0mmy <t0mmy!~tprrt@> has joined #yocto07:49
*** ant_work <ant_work!~ant__@> has joined #yocto07:49
*** zeenix <zeenix!~zeenix@> has joined #yocto07:51
*** Biliogadafr <Biliogadafr!> has joined #yocto07:52
*** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has quit IRC07:53
*** gtristan <gtristan!~tristanva@> has joined #yocto08:07
*** eduardas_m <eduardas_m!~eduardas_@> has joined #yocto08:15
*** gtristan <gtristan!~tristanva@> has quit IRC08:20
*** CTtpollard <CTtpollard!> has joined #yocto08:21
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto08:41
jkuI'm trying to make the core-image-sato build a little faster and smaller by making the vala dependency in vte optional... but it's proven to be a little tricky08:43
jkuvala.bbclass adds vala and vala-native to DEPENDS unconditionally08:44
jkuit does not seem possible to conditionally inherit a class (see my attempt at
*** seebs_ <seebs_!~seebs@> has joined #yocto08:46
*** nighty-_ <nighty-_!> has joined #yocto08:46
*** tripzero_ <tripzero_!~tripzero@> has joined #yocto08:46
*** Xz_ <Xz_!kmsywula@nat/intel/x-jdnayreqzhhxgmcf> has joined #yocto08:47
*** gtristan <gtristan!~tristanva@> has joined #yocto08:47
jkuI guess my only real option is to not depend on vala class but copy paste the useful bits to the vte recipe?08:47
*** mario-go` <mario-go`!> has joined #yocto08:47
*** kjokinie1 <kjokinie1!~kjokinie@> has joined #yocto08:48
*** dl9pf_ <dl9pf_!> has joined #yocto08:48
*** phatina_ <phatina_!> has joined #yocto08:48
*** tobiash_ <tobiash_!~quassel@> has joined #yocto08:48
*** simfir_ <simfir_!> has joined #yocto08:49
*** t0mmy_ <t0mmy_!~tprrt@> has joined #yocto08:49
*** kergoth` <kergoth`!~kergoth@> has joined #yocto08:53
*** csd- <csd-!~csd@> has joined #yocto08:53
*** el_robin_ <el_robin_!> has joined #yocto08:54
*** t0mmy <t0mmy!~tprrt@> has quit IRC08:54
*** yann|work <yann|work!> has quit IRC08:54
*** rajm <rajm!> has quit IRC08:54
*** bboozzoo_ <bboozzoo_!> has quit IRC08:54
*** seebs <seebs!~seebs@> has quit IRC08:54
*** simfir <simfir!> has quit IRC08:54
*** kjokinie <kjokinie!~kjokinie@> has quit IRC08:54
*** mario-goulart <mario-goulart!~user@> has quit IRC08:54
*** Xz <Xz!kmsywula@nat/intel/x-hvrencrxeuovliai> has quit IRC08:54
*** tobiash <tobiash!~quassel@> has quit IRC08:54
*** kergoth <kergoth!~kergoth@> has quit IRC08:54
*** gabrbedd <gabrbedd!> has quit IRC08:54
*** dl9pf <dl9pf!~quassel@opensuse/member/dl9pf> has quit IRC08:54
*** nisha <nisha!~nisha@> has quit IRC08:54
*** el_robin <el_robin!> has quit IRC08:54
*** mago_ <mago_!~mago@> has quit IRC08:54
*** RzR <RzR!~RzR@unaffiliated/rzr> has quit IRC08:54
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has quit IRC08:54
*** phatina <phatina!> has quit IRC08:54
*** csd <csd!~csd@> has quit IRC08:54
*** tripzero <tripzero!~tripzero@> has quit IRC08:54
*** nighty- <nighty-!> has quit IRC08:54
*** kergoth` is now known as kergoth08:54
*** csd- is now known as csd08:54
*** RP <RP!~richard@> has quit IRC08:55
*** sjolley <sjolley!~sjolley@> has quit IRC09:00
*** sjolley <sjolley!~sjolley@> has joined #yocto09:01
*** bboozzoo_ <bboozzoo_!> has joined #yocto09:01
*** rajm <rajm!> has joined #yocto09:01
*** yann|work <yann|work!> has joined #yocto09:01
*** mago_ <mago_!~mago@> has joined #yocto09:02
*** ecdhe <ecdhe!> has joined #yocto09:02
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has joined #yocto09:02
*** nisha <nisha!~nisha@> has joined #yocto09:02
*** florian_kc is now known as florian09:02
*** hundebol1 is now known as hundeboll09:04
*** RzR <RzR!~RzR@> has joined #yocto09:09
*** rburton <rburton!> has joined #yocto09:13
*** fl0v01 <fl0v01!> has joined #yocto09:21
*** fl0v0 <fl0v0!> has quit IRC09:23
*** Crofton <Crofton!> has joined #yocto09:23
*** mario-go` is now known as mario-goulart09:24
*** lemagoup <lemagoup!~lemagoup@> has joined #yocto09:34
ZubairLKAre Poky release and oe-core release in sync?09:57
ZubairLKi.e oe-core releases v2.2 in October. And poky v2.2 is released with v2.2 oe-core?09:57
*** mattsm <mattsm!uid128834@gateway/web/> has joined #yocto10:01
*** belen <belen!~Adium@> has joined #yocto10:06
Croftonbasically, yes10:06
Croftonwe have too many names for things, adding confusion by having out of sync releases would be madness10:07
*** Crofton <Crofton!> has quit IRC10:11
*** AndersD <AndersD!~anders@> has quit IRC10:12
ZubairLKCrofton|work: thanks10:13
*** nighty-_ <nighty-_!> has quit IRC10:19
*** psnsilva <psnsilva!> has joined #yocto10:19
*** nighty- <nighty-!> has joined #yocto10:21
*** AndersD <AndersD!~anders@> has joined #yocto10:47
*** morphis_ <morphis_!> has joined #yocto10:50
*** hyde <hyde!uid25660@gateway/web/> has joined #yocto10:51
hydels -l10:52
hydewrong window, sorry10:53
*** morphis_ <morphis_!> has quit IRC10:53
hydebut, I do have a question: I want to run ldd on target platform. How do I find out what I have to bitbake in order to have ldd built?10:53
-YoctoAutoBuilder- build #60 of nightly-checkuri is complete: Failure [failed BuildImages] Build details are at http://localhost:8010/builders/nightly-checkuri/builds/6010:54
rburtonhyde: its part of glibc, so just install the "ldd" package10:54
hydebitbake ldd says "nothing provides ldd" (note, I am oe/bitbake n00b)10:55
rburtonyou build recipes, and install packages10:56
neverpanichyde: you can also just run the loader directly with --list "$argument", e.g. /lib/ --list /bin/bash10:57
*** bilboquet <bilboquet!> has quit IRC10:57
rburtonpretty hard to not build glibc, so you've already got it built10:57
rburtonfwiw the way to look this up is $ oe-pkgdata-util  find-path /usr/bin/ldd10:57
rburtonldd: /usr/bin/ldd10:57
*** bilboquet <bilboquet!> has joined #yocto10:57
hyderburton: thanks, found it (it's built, it just wasn't in the image, worked after scp)10:59
hydeWhat I am doing is trying to get Qt X11 platform plugin to work...10:59
*** redengin <redengin!> has quit IRC11:00
*** redengin <redengin!> has joined #yocto11:00
hydeso next is figuring out why a bunch of libs are missing, and how do I get them added to the image11:00
*** JaMa <JaMa!> has joined #yocto11:09
*** JvD_ <JvD_!> has joined #yocto11:10
*** ernstp <ernstp!uid168075@gateway/web/> has joined #yocto11:16
ernstpusing externalsrc.bbclass a bit... looks like someone wanted to add support for extra SRC_URIs for externalsrc recipes11:17
ernstpthere's the local_srcuri variable in the class. however I don't think it's working...11:17
ernstpnothing is actually hooked up to process SRC_URI. do_fetch and do_unpack are empty11:18
-YoctoAutoBuilder- build #77 of nightly-wic is complete: Failure [failed BuildImages_3 BuildImages_7] Build details are at http://localhost:8010/builders/nightly-wic/builds/7711:19
hydeok, I am running this command in build dir: $ oe-pkgdata-util find-path /usr/lib/
hydeadn get output: libxcb-shape: /usr/lib/
*** belen <belen!~Adium@> has quit IRC11:21
hyde but running bitbake libxcb-shape gives error: ERROR: Nothing PROVIDES 'libxcb-shape'. Close matches: libxcb-native11:21
hydecan someone shed a tiny bit of light on this? I guess I am being mixed up between what oe-pkgdata-util does, and what bitbake does, or...?11:22
hydehmm, maybe just libxcb to have all the libxcb-XXXX...11:28
ernstpnevermind, SRC_URI and externalsrc seem to work just fine, proably just an sstate problem11:28
ernstphyde: I'm not sure about the terminology but I think a package "rule" can create many package binaries11:29
ernstpif you do "bitbake libxcb" that will create libxcb-dev and bunch of other packages11:30
*** boucman_work <boucman_work!> has quit IRC11:32
rburtonhyde: find-path tells you what *package* contains the file, not the recipe name you can pass to bitbake.11:33
rburtonnote that if pkgdata knows about it, then you've already built it11:33
rburtona recipe generally creates many packages, for example libfoo libfoo-doc libfoo-dbg libfoo-dev libfoo-locale-en-gb11:34
ernstpit's like debian source and binary packages...11:34
rburtonfor the library, the docs, the debug info, the headers, and the translations specifically11:34
hydeand what do I add to DEPENDS in a .bb file, packages or recipes?11:37
hydelooks like recipes11:37
rburtonyes, depends11:38
hydeI wonder why meta-qt5 doesn't install anything under /usr/lib/qt5/plugins in image11:39
hyde(that's where Qt looks for platform plugin .so)11:39
hyde...and what would be the proper way to have these installed (they are built, now I copied them by hand to target board, but I am missing some libraries, which the above libxcb stuff is all about)11:40
*** berton <berton!~fabio@> has joined #yocto11:41
*** Cwiiis_ is now known as Cwiiis11:41
*** Crofton <Crofton!~Crofton@> has joined #yocto11:50
*** toscalix <toscalix!> has quit IRC11:59
*** xulfer <xulfer!> has quit IRC12:06
-YoctoAutoBuilder- build #77 of nightly-x86-64-lsb is complete: Failure [failed BuildImages_1] Build details are at http://localhost:8010/builders/nightly-x86-64-lsb/builds/7712:16
rburtonoh the urls are broken, damn12:22
*** JordonWu <JordonWu!~quassel@> has quit IRC12:22
ernstprburton: depends are recipes and rdepends ar packages, right?12:23
*** JordonWu <JordonWu!~quassel@> has joined #yocto12:26
*** RzR <RzR!~RzR@> has quit IRC12:28
*** RzR <RzR!~RzR@unaffiliated/rzr> has joined #yocto12:28
*** sujith_h <sujith_h!~toaster@kde/developers/sujithh> has quit IRC12:28
*** sujith_h <sujith_h!~toaster@> has joined #yocto12:29
*** Crofton <Crofton!~Crofton@> has quit IRC12:30
*** manuel_ <manuel_!> has joined #yocto12:31
*** igor2 <igor2!~igor@> has joined #yocto12:52
-YoctoAutoBuilder- build #78 of nightly-x86-lsb is complete: Failure [failed BuildImages_1] Build details are at http://localhost:8010/builders/nightly-x86-lsb/builds/7812:53
yann|workany idea why an EFI image generated by wic would result on an sdcard not recognized as UEFI by the target BIOS ?12:55
*** seebs_ <seebs_!~seebs@> has quit IRC12:58
*** phatina_ is now known as phatina13:01
-YoctoAutoBuilder- build #78 of nightly-x86-64 is complete: Failure [failed BuildImages_1] Build details are at http://localhost:8010/builders/nightly-x86-64/builds/7813:06
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC13:09
*** lamego <lamego!jose@nat/intel/x-ikgaudsqhggfckzx> has joined #yocto13:11
*** Crofton <Crofton!~Crofton@> has joined #yocto13:16
*** seebs <seebs!~seebs@> has joined #yocto13:17
*** ecksun <ecksun!> has joined #yocto13:17
*** tlwoerner <tlwoerner!~trevor@unaffiliated/tlwoerner> has quit IRC13:21
ecksunI'm setting up a continuous deployment system with yocto and I have a hard time figuring out how to let bitbake use my previously build packages when assembling a new image. Essentially I would like to first build all changed packages, upload them into my debian repository and then from that repository build an image. How would you recommend I perform the last step? (build an image from a set of packages)13:23
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto13:23
*** eduardas_m <eduardas_m!~eduardas_@> has quit IRC13:23
*** tlwoerner <tlwoerner!~trevor@unaffiliated/tlwoerner> has joined #yocto13:27
*** egavinc <egavinc!> has joined #yocto13:32
*** toscalix <toscalix!> has joined #yocto13:35
*** ant_work <ant_work!~ant__@> has quit IRC13:48
*** toscalix <toscalix!> has quit IRC13:55
-YoctoAutoBuilder- build #80 of nightly-ppc is complete: Failure [failed Running Sanity Tests] Build details are at http://localhost:8010/builders/nightly-ppc/builds/8013:57
*** gtristan <gtristan!~tristanva@> has quit IRC13:57
*** manuel_ <manuel_!> has quit IRC13:57
*** toscalix <toscalix!> has joined #yocto13:58
rburtonecdhe: you want to persist the sstate cache between builds, not the built packages.14:00
*** qt-x <qt-x!~Thunderbi@> has quit IRC14:02
*** madisox <madisox!~madison@> has joined #yocto14:03
*** mortderire <mortderire!rkinsell@nat/intel/x-jtghwqxeuxedshnf> has joined #yocto14:04
*** mortderire <mortderire!rkinsell@nat/intel/x-tqqsgnydmeghltoa> has joined #yocto14:04
*** mortderire <mortderire!rkinsell@nat/intel/x-tqqsgnydmeghltoa> has quit IRC14:06
*** mortderire <mortderire!rkinsell@nat/intel/x-jwtvgsqemyjldwow> has joined #yocto14:06
*** mortderire <mortderire!rkinsell@nat/intel/x-jwtvgsqemyjldwow> has quit IRC14:08
*** JordonWu <JordonWu!~quassel@> has quit IRC14:10
ecksunIm assuming you miss-tabbed my nick :)14:13
*** Crofton <Crofton!~Crofton@> has quit IRC14:13
ecksunis the build from sstate cache to package deterministic? as in, will I always get the exact same packages from it?14:13
ecksunmoreover, I just had an issue when building were bitbake recommended me to clear my cache, which would mean it wouldn't work14:14
seebsI think the answer is probably "yes unless there's a bug or something incredibly unlikely happens".14:14
ecksunI would like to, once I have built my packages, use the same definition everywhere14:14
seebsBasically, it's intended to be deterministic, but sometimes we find bugs.14:15
ecksunotherwise I might get my running systems divergent from the newly produced systems14:15
seebsyeah. In theory, if you have the same configuration, you should get deterministic output, except when there's bugs. Which there sometimes are.14:15
ecksunso what happens between the sstate cache and the finished package, what steps are performed?14:16
seebsthis is a non-trivial question to ask, because sstate can cache multiple steps in a package build.14:17
seebsIn theory, I think, if you have a full build in sstate, the final package is basically just the RPM or whatever.14:18
seebsAnd if you have sstate for the filesystem, you might just unpack your previously-built filesystem? Not sure.14:18
seebsMemory vague.14:18
ecksunbut if the sstate cache is a cache, it does not solve my issue14:18
ecksunI want the packages I have on my deployed systems to be _exactly_ the same as the ones I'm using to build my package14:18
ecksunalso, if it is a cache, it caches something, but I havent understood what yet14:19
seebsOkay, so... Imagine that you have two sets of binaries, and they're byte-for-byte identical, but one set has newer timestamps in the filesystem. Is that exact enough?14:19
rburtonecksun: if you just need packages then sstate cache contains the final packages and it will just extract them14:19
seebsIt caches any and all parts of the build process.14:20
rburtonie bitbake some-image; rm tmp ; bitbake some-image14:20
ecksunseebs, yes, but I dont want anythign from the build-process, I want the final output binary14:20
seebsSo let's say you have a typical build. Unpack, apply patches, run configure, compile, install.14:20
rburtonthe second run will just extract all the packages from the build and create the image14:20
seebssstate will have a cachecd copy of the unpacked-but-not-patched files, the patched files, the configure output, the compile output, and the final image stuff created by the install.14:20
rburton(erm, extract all the packages from the sstate)14:21
seebss/ecd c/ed c/14:21
seebsAnd if you nuke sstate and rerun the build, you should get identical (except for, say, timestamps) packages every time.14:21
*** Anticom <Anticom!~quassel@> has joined #yocto14:21
ecksunshould get :D14:21
seebsIt may be that you would be better off using bitbake to build RPMs or whatever package format you want, and then assembling filesystems from those.14:21
ecksunthats what I would prefer14:21
seebsYeah. You are not required to use bitbake for your final image creation if you don't want to.14:22
ecksunwell, what I would like to is hook into the middle of it14:22
ecksunin between the "compile output" and the "final image stuff"14:22
seebsWhat do you want to do at that point?14:23
rburtonecksun: fundamentally speaking, images are built from packages, and packages can either come from an actual build, or a previous actual build going into sstate and being extracted again.  the resulting images *will* be identical.14:23
ecksunseebs, use the previously built packages14:23
ecksunrburton, alright14:24
seebsI mean, when you say you want to "hook into the middle of it", what do you want to do differently from what bitbake already does?14:25
ecksunI dont want to rebuild packages every time14:26
ecksunI want to use my repository for everything14:26
ecksunbasically, build -> upload to repo -> package from repo into image14:26
ecksunthis might be what bitbake does, and kind of sounds like to from rburton14:26
*** behanw <behanw!uid110099@gateway/web/> has joined #yocto14:27
seebsAhh, yes. That is indeed what it would usually do.14:28
ecksunbut I'm very uncomfortable with letting a cache (which is what I understand the sstate cache folder to be) be the cannonical definiton of my system14:28
seebsAhh, I see.14:29
seebsIt's not!14:29
ecksunthe sstate cache is not a cache?14:29
seebsThe *definition* is the recipes+bitbake.14:29
seebsOh, no, it is a cache. It's not the definition.14:29
ecksunIm testing my output14:29
ecksunnot my source14:29
seebsThe definition is the files used to build the cache. The cache is purely an optimization.14:29
seebsIn theory it changes nothing (except timestamps).14:29
ecksunyeah, in theory, but that assumes that all builds are reproducable14:29
ecksunwhich I do not dare to do14:29
seebsWell, in theory, theory and practice are the same!14:30
ecksunthat is why I want to use my final output packages to construct my images, because that is going to be the exact same packages I will install on my running systems14:30
*** Circuitsoft <Circuitsoft!4b92a52b@gateway/web/freenode/ip.> has joined #yocto14:31
ecksunmoreover, though that might be a separate discussion, I'm hoping I can include packages not defined with recipes into this14:31
seebsSo you want some way to ensure that the packages that don't change.14:31
seebsWell, not directly with bitbake.14:31
*** Crofton <Crofton!~Crofton@> has joined #yocto14:31
seebsHmm. So what you sort of want is a way to freeze a package and say "even if other things change that imply this package should change, keep using this version we built way back here."14:31
ecksunyes, more or less14:31
ecksunand any change to the package should consistute a new version14:32
seebsOkay so I can see a way to make this work, and it's horrible but it might work.14:32
ecksunthat doesnt sound good: D14:32
seebsYeah, you're outside the designed use cases, I think.14:32
ecksunyes, I get that feeling14:32
seebsSo, imagine a thing which takes an image spec, and makes from it a New Layer.14:32
ecksunbitbake does not feel optimized for a continuous development workflow14:32
neverpanicgiving each package a new version is basically what PRserv does14:33
seebsAnd the new layer has a single recipe which installs the sysroots and dev tree from that image, and which lists itself as PROVIDES all the things it provides, and as PREFERRED_PROVIDER for all those things.14:33
ecksunneverpanic, I dont know much about it, but was hoping it could help me figure out when to bump versions or not14:33
seebsSo if you have this layer, it will pick all that stuff up from a tarball and use it unconditionally.14:33
neverpanicIf you want to not recompile a certain package even when one of its dependencies changes, may I suggest using something else, but not bitbake? ;-)14:33
rburtonecksun: sounds like you want to use locked signatures to ensure that nothing gets rebuilt.  if the hash is the same and you pull from the same sstate cache then you're forced that the same binaries are used.14:33
ecksunneverpanic, no, I dont mind recompiling when dependencies change, then its just a new version and should be treated as such14:34
neverpanicThat being said, reproducible build results would be great, make it so! ;-)14:34
neverpanicecksun: Yes, that's what PRserv already does, I think.14:35
-YoctoAutoBuilder- build #80 of nightly-x86 is complete: Failure [failed BuildImages_1] Build details are at http://localhost:8010/builders/nightly-x86/builds/8014:35
ecksunneverpanic, yes, thats my very limited understanding as well, I will probably look in to it soon14:35
*** boucman_work <boucman_work!> has joined #yocto14:35
*** jku <jku!jku@nat/intel/x-yhwvpatjuysabpph> has quit IRC14:35
ecksunseebs, there are several things I dont grasp enough to understand your suggestion :(14:35
seebsthat's probably for the best, I suspect it's a really bad idea.14:36
ecksunrburton, hmm, could be, but once again, I dont want to use a cache for anything persistent14:37
ecksunI will check out locked signatures though, to see what they are14:37
ecksunI would like to better understand what happens when bitbake assembles the final image, how can I go about understanding that?14:38
rburtonecksun: maybe we shouldn't have used the word cache.  just a package index isn't enough to build an image.14:38
seebsThe intent is that rebuilding packages should produce identical results unless Something Changed. And if something changed, the cache would be ignored anyway.14:38
ecksunrburton, oh, thats interesting, why is that not enough?14:38
*** manuel_ <manuel_!~manuel@> has joined #yocto14:38
rburtonbecause theres lots of metadata that isn't in a rpm/deb/whatever14:38
ecksunseebs, yes, that would be awesome, however I cannot assume that, especially not for my own packages, sadly :(14:38
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC14:38
seebs... I just realized, I actually do not currently have a copy of bitbake/oe-core on this machine to look at.14:38
ecksunrburton, oh, thats worrysome, metadata like what?14:38
seebsIn that case, yeah, you need some kind of checksum thing.14:39
rburtonecksun: like what goes into an image, for a start14:39
ecksunthe list of packages basically?14:39
rburtonand all the scripts to run, and all the native dependencies required to run those scripts14:39
ecksunwhich scripts to run? I thought all such things were included in package definitoins? (pre-install scripts and such)14:39
rburtonimage-wide scripts14:39
ecksuncan you give me an example?14:40
ecksunif there are image-wide scripts thats problematic to me, because I have no way of applying changes to such scripts on my running systems (if they are not part of a package)14:41
*** hamis <hamis!~irfan@> has quit IRC14:41
seebsYeah, look at post-install scripts. They can do lots of weird stuff.14:41
seebsSo yeah, that is a problem for you!14:41
seebs... Not that I have a solution in mind, but at least you know about it.14:42
ecksunbut should they not be part of one package or another?14:42
seebsOh, I see. They are, but they can have effects on other things.14:42
seebsLike, some of the stuff that gets done for secure systems might go mess with ssh config, even though it's not part of the ssh package...14:42
ecksunas I said, my main worry is that my production systems will diverge from my newly produced systems14:42
ecksunseebs, yeah, thats an issue I dont have a really good solution to14:43
rburtonpackage postinsts are obviously in the package, its more image scripts that you may or may not have14:43
ecksundebians conf.d folders work quite fine though, in most cases, I think14:43
ecksunrburton, yes, I need to find out if I have any of those and try to remove them14:43
seebsWell, one strategy would be to just add a disclaimer in your docs.14:43
ecksunor understand how they work at the very least14:43
seebsDISCLAIMER: Images may not be reproducible or identical. SUCK IT UP PRINCESS.14:43
rburtonecksun: the default ones are just stuff like "run ldconfig" or "if debugging enabled, wipe root password"14:44
seebs... Of course, now that I'm more likely to be using than making yocto-based stuff, I should probably advise against this.14:44
ecksunrburton, okay, how can I find them?14:44
ecksunrburton, could you link me to some documentation that details that behaviour?14:45
ecksunI have been considering using as I think that might do what I want14:46
ecksunbut I would prefer to use bitbake proper if possible14:46
*** sjolley <sjolley!~sjolley@> has quit IRC14:47
*** sjolley <sjolley!~sjolley@> has joined #yocto14:48
*** dreyna <dreyna!~dreyna@> has quit IRC14:50
ecksunbtw, thank you all for your help, it has given me a lot of insight14:52
*** sjolley <sjolley!~sjolley@> has quit IRC14:56
ecksunas you guys suggested, PR service and checksum might help me figure out at least what packages to rebuild or not14:57
*** stephano <stephano!~stephano@> has joined #yocto15:01
*** frsc <frsc!~frsc@> has quit IRC15:02
*** radzy <radzy!> has quit IRC15:04
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto15:08
*** radzy <radzy!> has joined #yocto15:08
*** yann|work <yann|work!> has quit IRC15:08
*** AndersD <AndersD!~anders@> has quit IRC15:10
*** mortderire <mortderire!~rkinsell@> has joined #yocto15:10
*** mattsm <mattsm!uid128834@gateway/web/> has quit IRC15:13
*** dreyna <dreyna!~dreyna@> has joined #yocto15:13
*** mortderire1 <mortderire1!~rkinsell@> has joined #yocto15:14
*** mortderire <mortderire!~rkinsell@> has quit IRC15:14
kergothERROR: core-image-sato-1.0-r0 do_image: Taskhash mismatch 279d7fa1310f436e0058f1742627a68b versus 0fbf14dc55abb7932bb8e70145c26691 for /scratch/dogwood/minnowmax-psplash-test/poky/meta/recipes-sato/images/
* kergoth sighs15:15
*** mortderire1 <mortderire1!~rkinsell@> has quit IRC15:17
*** mortderire <mortderire!~rkinsell@> has joined #yocto15:17
*** TobSnyder <TobSnyder!> has quit IRC15:17
*** mortderire <mortderire!~rkinsell@> has quit IRC15:18
*** AndersD <AndersD!~anders@> has joined #yocto15:18
*** RP1 <RP1!~richard@> has joined #yocto15:18
*** Crofton <Crofton!~Crofton@> has quit IRC15:18
*** dreyna <dreyna!~dreyna@> has quit IRC15:20
*** mortderire <mortderire!~rkinsell@> has joined #yocto15:21
*** mortderire <mortderire!~rkinsell@> has quit IRC15:27
*** gabrbedd <gabrbedd!> has joined #yocto15:28
*** vdehors <vdehors!> has quit IRC15:31
*** vdehors <vdehors!> has joined #yocto15:32
-YoctoAutoBuilder- build #74 of nightly-oe-selftest is complete: Failure [failed Running oe-selftest] Build details are at http://localhost:8010/builders/nightly-oe-selftest/builds/7415:36
*** jonver <jonver!> has quit IRC15:39
*** zeenix <zeenix!~zeenix@> has quit IRC15:39
ecksunI would like to find the source of do_rootfs, how do you recommend I go about doing that?15:40
kergothread rootfs.bbclass.15:41
kergothor rather, image.bbclass and rootfs_*.bbclass15:41
ecksunhow do I know to search in there?15:41
kergothevery image recipe  has 'inherit image' in it15:42
kergothwhich tells you to read image.bbclass15:42
ecksunaha, okay15:42
kergothso read the recipe, and go from there :)15:42
*** sjolley <sjolley!~sjolley@> has joined #yocto15:42
ecksunmake sense :)15:42
kergothalternatively, inspect bitbake -e recipename, which has all the variables and functions, but it's not broken up, so there's a lot to go through15:42
ecksunyeah, that seems more or less equivalent with what I did: grep -irIn do_rootfs15:43
ecksunso Im guessing this is the definition:
seebsYou wanna look at bitbake -e output at least a little to be sure, because conceivably you could have an image that inherited something else that overrode that.15:46
*** AndersD <AndersD!~anders@> has quit IRC15:46
ecksungood point15:46
ecksunI'm also noticing that my local image.bbclass is very different from the one I just linked, need to figure out why that is15:46
kergothindeed, -e shows you the final results, including appends15:47
kergothdifferent branch?15:47
ecksunprobably, from which branch is yocto released?15:47
kergoththere is no generic release branch. development occurs on master until it's frozen, then it's branched off to a named branch for that release codename15:49
kergothmaster right now is 2.215:49
ecksunkergoth, I see, thanks15:50
kergothjust look at your local layers and see what branch they're on, presumably they're either on a stable branch for a previous release, or an old master15:50
ecksunjupp, Im on 2.0.2, which matches well15:51
ecksunso you were correct15:51
*** rajm <rajm!> has quit IRC15:54
*** Geoff_ <Geoff_!32bbdac4@gateway/web/freenode/session> has joined #yocto15:58
Geoff_Hi guys, I'm having an issue with useradd it doesn't seem to be compatible with package management *.deb.  Has anyone encountered this?15:59
ecksunit works for me15:59
ecksunI messed with that just the other day15:59
Geoff_are you using package management and deb files tho?15:59
Geoff_I get this error: "Unable to read tmp/work/[machine]/[image name]/[version]/apt/preferences.d - Directory exists (2: No such file or directory)16:00
ecksunhaha, awesome error16:00
Geoff_lol yeh..16:01
rburtonfwiw deb is the least-tested package format16:01
ecksunI probably can't help you more than that, sadly :(16:01
seebs... that's a very odd error.16:01
*** janco <janco!~jan@> has joined #yocto16:02
*** ernstp <ernstp!uid168075@gateway/web/> has quit IRC16:02
*** boucman_work <boucman_work!> has quit IRC16:03
*** csanchezdll <csanchezdll!> has left #yocto16:03
Geoff_thanks for the snippet.  Is your recipe named useradd?  Just curious16:05
Geoff_Mine has a custom name but inherits from useradd16:06
*** toanju <toanju!~toanju@> has quit IRC16:07
*** ftonello <ftonello!~felipe@> has joined #yocto16:07
ecksunGeoff_, no, mosquitto_%.bbappend i think (Am on phone now, so cant check)16:09
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto16:11
ecksunif you pm me in a couple of hours I can provide the rest16:11
*** ftonello <ftonello!~felipe@> has quit IRC16:14
*** Crofton <Crofton!> has joined #yocto16:14
*** ftonello <ftonello!~felipe@> has joined #yocto16:21
*** fl0v01 <fl0v01!> has quit IRC16:22
*** janco <janco!~jan@> has quit IRC16:30
*** toscalix <toscalix!> has quit IRC16:31
*** hyde <hyde!uid25660@gateway/web/> has quit IRC16:31
CTtpollardHmm, I'm having to bitbake an image inside a vbox vm with a dynamic hdd16:32
*** Snert_ <Snert_!~snert_@> has joined #yocto16:32
CTtpollardhowever bitbake is halting due to running out of space, any idea?16:32
AnticomCTtpollard: probably ran out of space in your VM?16:33
Anticomcheck with df16:33
kergothdon't use a dynamic hdd, fix virtualbox, get more space, ..16:33
CTtpollardAnticom: the hdd is dynamic so should balloon when needed16:34
AnticomCTtpollard: nope16:34
CTtpollardwhich it has been doing, but has now stopped (the media hosting the hdd has 80% space left)16:34
Anticomthere's a limit to it too (iirc 10GB by default) >>> #vbox16:34
rburtonyou can turn off the check16:35
Anticomrburton: won't help when there's no space left i suppose16:35
AnticomCTtpollard: just check how much space is *actually* left inside your vm16:35
rburtonno, if its actually full you'll get comedy errors as 20 gcc invocations all run out of space16:35
Anticominstead of making assumption16:35
rburtonbut they might be doing file system games which trip up the space detection16:35
kergothI suppose with a dynamic hdd it expects you to just blindly try writing data even if there's no space for it? seems a bit odd. it should act like it has more space than it does, instead16:35
CTtpollardAnticom: less than a gig, I know how much is left I'm just curious to why it's not expanding anymore16:35
AnticomCTtpollard: #vbox16:36
Anticombeen there, done that. Even dynamically allocated hdd's in vbox have a limit you can set. You've probably reached that very limit16:36
AnticomCTtpollard: TL;DR; shut down vm, use VBoxeManage to enlarge your vdd, boot gparted, enlarge partition to new vdd size, reboot into your OS16:36
rburtonBB_DISKMON_DIRS defaults to 1GB of space16:37
CTtpollardAnticom: ok, I'll look to resize it into a new dynamic disk with a higher threshold16:42
*** Anticom <Anticom!~quassel@> has quit IRC16:49
-YoctoAutoBuilder- build #78 of nightly-wic is complete: Success [build successful] Build details are at http://localhost:8010/builders/nightly-wic/builds/7816:50
*** jbrianceau is now known as jbrianceau_away16:58
-YoctoAutoBuilder- build #78 of nightly-x86-64-lsb is complete: Success [build successful] Build details are at http://localhost:8010/builders/nightly-x86-64-lsb/builds/7817:00
-YoctoAutoBuilder- build #79 of nightly-x86-lsb is complete: Success [build successful] Build details are at http://localhost:8010/builders/nightly-x86-lsb/builds/7917:01
*** psnsilva <psnsilva!> has quit IRC17:11
*** sujith_h <sujith_h!~toaster@> has quit IRC17:14
*** sujith_h <sujith_h!~toaster@kde/developers/sujithh> has joined #yocto17:14
*** yann|work <yann|work!> has joined #yocto17:15
*** Geoff_ <Geoff_!32bbdac4@gateway/web/freenode/session> has quit IRC17:18
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto17:21
*** mortderire <mortderire!~rkinsell@> has joined #yocto17:22
*** mortderire <mortderire!~rkinsell@> has quit IRC17:30
*** behanw <behanw!uid110099@gateway/web/> has quit IRC17:39
*** mortderire <mortderire!~rkinsell@> has joined #yocto17:44
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC17:45
*** grma <grma!~gruberm@> has quit IRC17:47
*** scottrif <scottrif!> has joined #yocto18:11
scottrifAny experts out there regarding tweaking UBoot configuration for a board (e.g. BeagleBone?).  I am working on a writing project that would show how UBoot might run some alternative code if a board fails to boot a certain number of times in a row.  I am seeking out a subject matter expert for this that I might be able to talk with... thanks.18:16
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC18:20
*** Snert_ <Snert_!~snert_@> has quit IRC18:21
*** gtristan <gtristan!~tristanva@> has joined #yocto18:34
*** toanju <toanju!~toanju@> has joined #yocto18:52
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC18:54
*** mortderire <mortderire!~rkinsell@> has quit IRC18:54
*** mortderire <mortderire!~rkinsell@> has joined #yocto18:55
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has quit IRC18:59
-YoctoAutoBuilder- build #79 of nightly-x86-64 is complete: Success [build successful] Build details are at http://localhost:8010/builders/nightly-x86-64/builds/7918:59
*** Snert_ <Snert_!~snert_@> has joined #yocto19:03
*** slips <slips!> has quit IRC19:05
*** slips <slips!> has joined #yocto19:08
-YoctoAutoBuilder- build #81 of nightly-x86 is complete: Success [build successful] Build details are at http://localhost:8010/builders/nightly-x86/builds/8119:14
-YoctoAutoBuilder- build #81 of nightly-ppc is complete: Success [build successful] Build details are at http://localhost:8010/builders/nightly-ppc/builds/8119:19
*** imuarray <imuarray!d8ab08dd@gateway/web/freenode/ip.> has joined #yocto19:20
imuarrayhi everyone19:20
imuarrayim having some trouble bitbaking an intel edison yocto image19:20
*** clsulliv <clsulliv!clsulliv@nat/intel/x-ttrdecmjrkhjprqo> has quit IRC19:21
imuarraylibwebsockets checksum mismatch19:21
*** clsulliv <clsulliv!clsulliv@nat/intel/x-mwbymijpiudaqtdp> has joined #yocto19:21
*** clsulliv <clsulliv!clsulliv@nat/intel/x-mwbymijpiudaqtdp> has quit IRC19:21
imuarrayis anyone avaiblable to help? I'm new to this and so frustrated by the process19:22
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto19:22
*** dmoseley <dmoseley!> has joined #yocto19:23
imuarrayis anyone avaiblable to help? I'm new to this and so frustrated by the process #yocto19:23
*** clsulliv <clsulliv!clsulliv@nat/intel/x-vmhmgscynxbbhomo> has joined #yocto19:29
*** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has joined #yocto19:31
seebsso, just a note, I can't help much with that, but I can let you know that IRC is pretty asynchronous, it may be an hour or five before a response shows up.19:31
*** bilboquet <bilboquet!> has quit IRC19:34
*** imuarray <imuarray!d8ab08dd@gateway/web/freenode/ip.> has quit IRC19:35
*** clsulliv <clsulliv!clsulliv@nat/intel/x-vmhmgscynxbbhomo> has quit IRC19:45
*** mrpelotazo <mrpelotazo!> has quit IRC19:45
*** clsulliv <clsulliv!~clsulliv@> has joined #yocto19:46
*** mrpelotazo <mrpelotazo!> has joined #yocto19:51
*** mortderire <mortderire!~rkinsell@> has quit IRC19:53
*** mrpelotazo <mrpelotazo!> has joined #yocto19:57
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC20:03
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto20:07
*** davis <davis!> has joined #yocto20:19
yann|workis there an predefined image type that could be built directly instead of having to install using image-live ?  hdddirect looked like it could be what I'm looking for, but it is not documented much, and does not appear to support UEFI ?20:19
daviscan I have a recipe which does do_install_class-native() {20:19
daviscan I have a recipe which does do_install_class-native() routine for native and not do make install, but for do_install_class-target() does a regular make install?20:20
yann|workin fact that hdddirect image can't even be booted in CSM mode :)20:21
yann|workdavis: at worst, you could use a different recipe for your native case ?20:25
davisi could. I'm curious though. if you have a do_install, does it simply work by calling that instead of make install or is that something which is invoked post make install?20:27
daviswhen I first started this thing, install was inherit in make, i've broken that out and made targets for install so it builds a normal system.20:28
yann|workdo_install is supposed to call "make install" when it's the way to install20:38
yann|workclasses like autotools do that for you, but for a simple Makefile-based software, you have to write do_install yourself20:39
*** tripzero_ is now known as tripzero20:49
*** gtristan <gtristan!~tristanva@> has quit IRC20:50
*** AndersD <AndersD!~anders@> has joined #yocto20:57
*** pohly1 <pohly1!> has quit IRC20:58
-YoctoAutoBuilder- build #75 of nightly-oe-selftest is complete: Success [build successful] Build details are at http://localhost:8010/builders/nightly-oe-selftest/builds/7521:01
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC21:06
*** berton <berton!~fabio@> has quit IRC21:20
*** dreyna <dreyna!~dreyna@> has joined #yocto21:21
*** toanju <toanju!~toanju@> has quit IRC21:21
*** Snert__ <Snert__!> has joined #yocto21:24
*** AndersD <AndersD!~anders@> has quit IRC21:26
*** Snert <Snert!> has quit IRC21:27
*** nickpongratz <nickpongratz!~Adium@> has joined #yocto21:32
*** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has quit IRC21:32
*** RzR is now known as rZr21:34
*** nickpongratz <nickpongratz!~Adium@> has left #yocto21:46
*** nickpongratz <nickpongratz!~Adium@> has joined #yocto21:46
*** seebs <seebs!~seebs@> has quit IRC21:48
*** rburton <rburton!> has quit IRC21:59
*** bfederau <bfederau!> has quit IRC22:01
*** fmeerkoetter <fmeerkoetter!> has quit IRC22:01
*** bfederau <bfederau!> has joined #yocto22:01
*** fmeerkoetter <fmeerkoetter!> has joined #yocto22:01
*** igor2 <igor2!~igor@> has quit IRC22:01
*** seebs <seebs!~seebs@> has joined #yocto22:11
*** lamego <lamego!jose@nat/intel/x-ikgaudsqhggfckzx> has quit IRC22:11
*** nickpongratz <nickpongratz!~Adium@> has left #yocto22:12
*** oy <oy!59f6447b@gateway/web/freenode/ip.> has joined #yocto22:14
*** Biliogadafr <Biliogadafr!> has quit IRC22:14
*** xulfer <xulfer!> has joined #yocto22:23
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC22:28
*** oy <oy!59f6447b@gateway/web/freenode/ip.> has quit IRC22:34
*** stephano <stephano!~stephano@> has quit IRC22:34
*** manuel_ <manuel_!~manuel@> has quit IRC22:34
*** sameo <sameo!~samuel@> has quit IRC22:56
*** manuel_ <manuel_!> has joined #yocto22:59
*** sjolley <sjolley!~sjolley@> has quit IRC23:06
*** sjolley <sjolley!~sjolley@> has joined #yocto23:07
*** nighty <nighty!> has quit IRC23:12
*** sjolley <sjolley!~sjolley@> has quit IRC23:13
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto23:16
*** dreyna <dreyna!~dreyna@> has quit IRC23:25
*** manuel_ <manuel_!> has quit IRC23:28
*** ka6sox is now known as zz_ka6sox23:54

Generated by 2.11.0 by Marius Gedminas - find it at!