Friday, 2014-05-02

*** maxtothemax <maxtothemax!~maxtothem@> has quit IRC00:02
*** seebs <seebs!> has joined #yocto00:02
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC00:04
*** seebs <seebs!> has quit IRC00:06
*** seebs <seebs!> has joined #yocto00:08
*** sameo <sameo!~samuel@> has quit IRC00:16
*** Denwid <Denwid!c2cc4226@gateway/web/freenode/ip.> has quit IRC00:34
*** Squix <Squix!> has joined #yocto00:35
*** adelcast <adelcast!~adelcast@> has quit IRC00:45
*** jfkelly_ <jfkelly_!> has quit IRC01:21
*** forcev <forcev!> has joined #yocto01:36
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC01:37
*** sjolley <sjolley!sjolley@nat/intel/x-upxvdisacvmjgqyv> has joined #yocto01:55
*** sjolley <sjolley!sjolley@nat/intel/x-upxvdisacvmjgqyv> has quit IRC02:03
*** simonl <simonl!uid6729@gateway/web/> has quit IRC02:18
*** belen <belen!~Adium@> has joined #yocto02:34
*** belen <belen!~Adium@> has quit IRC02:39
*** sjolley <sjolley!~sjolley@> has joined #yocto03:23
*** lyang0 <lyang0!~lyang001@> has quit IRC04:51
*** lyang0 <lyang0!~lyang001@> has joined #yocto04:52
*** Squix <Squix!> has quit IRC04:53
*** radzy_away is now known as radzy04:53
*** behanw <behanw!~behanw@> has joined #yocto05:07
*** slex_kag <slex_kag!~kvirc@> has joined #yocto05:10
*** jvuo <jvuo!> has joined #yocto05:17
*** radzy is now known as radzy_away05:17
*** dv__ <dv__!> has joined #yocto05:46
*** dv_ <dv_!> has quit IRC05:46
*** Squix <Squix!> has joined #yocto05:47
*** agust <agust!> has joined #yocto05:58
*** forcev <forcev!> has quit IRC06:04
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has joined #yocto06:07
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto06:10
*** gmacario <gmacario!> has joined #yocto06:30
*** zeeblex <zeeblex!~apalalax@> has joined #yocto06:31
sgw_khem: if you have a chance can you look at the Autobuilder, we have across the board failures in oprofile: undefined reference to `bfd_elf64_powerpcle_vec' and bfd_elf64_powerpc_vec, I think it might be compiler related.06:32
*** gmacario <gmacario!> has quit IRC06:32
*** ant_work <ant_work!> has joined #yocto06:43
khemsgw_: ok is it 4.9 ?06:44
khemand where are links ?06:46
khemnm got it
khembuggy oprofile stupid null pointer reference06:54
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto06:58
*** jbrianceau_away is now known as jbrianceau06:58
*** eballetbo <eballetbo!> has joined #yocto07:07
*** diego_r <diego_r!> has joined #yocto07:16
*** Squix <Squix!> has quit IRC07:20
*** jukkar <jukkar!~jukka@> has joined #yocto07:22
*** behanw <behanw!~behanw@> has quit IRC07:32
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC07:34
*** roric <roric!> has quit IRC07:37
*** kroon <kroon!> has joined #yocto07:38
*** florian <florian!> has joined #yocto07:39
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:39
*** cristianiorga <cristianiorga!~cristiani@> has quit IRC07:59
RPkhem: looks like there is also an mdadm issue :/08:10
*** smartin_ <smartin_!> has joined #yocto08:16
*** sameo <sameo!~samuel@> has joined #yocto08:17
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC08:20
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto08:20
*** dlerner1 <dlerner1!~dlerner@> has joined #yocto08:22
*** jkridner|work <jkridner|work!> has joined #yocto08:23
*** slex_kag <slex_kag!~kvirc@> has quit IRC08:25
*** roric <roric!> has joined #yocto08:27
*** th_ <th_!> has joined #yocto08:29
*** lexano_ <lexano_!> has joined #yocto08:31
*** smartin__ <smartin__!> has joined #yocto08:31
*** Xz <Xz!~kmsywula@> has joined #yocto08:33
Xzhi guys08:33
*** eballetbo_ <eballetbo_!> has joined #yocto08:33
*** deuter_ <deuter_!> has joined #yocto08:34
*** dlerner1 <dlerner1!~dlerner@> has quit IRC08:34
*** smartin_ <smartin_!> has quit IRC08:34
*** jukkar <jukkar!~jukka@> has quit IRC08:34
*** seebs <seebs!> has quit IRC08:34
*** tom_say <tom_say!> has quit IRC08:34
*** zarul <zarul!~zarul@ubuntu/member/zarul> has quit IRC08:34
*** deuter <deuter!wodor@> has quit IRC08:34
*** th <th!~th@unaffiliated/th> has quit IRC08:34
*** mitz <mitz!> has quit IRC08:34
*** eballetbo <eballetbo!> has quit IRC08:34
*** reallife <reallife!> has quit IRC08:34
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC08:34
*** fray <fray!> has quit IRC08:34
*** lexano <lexano!> has quit IRC08:34
*** bluelightning <bluelightning!~paul@> has joined #yocto08:36
*** bluelightning <bluelightning!~paul@> has quit IRC08:36
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:36
*** jkridner|work <jkridner|work!> has quit IRC08:37
*** slex_kag <slex_kag!~kvirc@> has joined #yocto08:38
*** sameo <sameo!~samuel@> has quit IRC08:39
*** sameo <sameo!~samuel@> has joined #yocto08:40
*** dlerner <dlerner!~dlerner@> has joined #yocto08:45
*** jukkar <jukkar!jukka@nat/intel/x-ppdaqhtchtyhqbkb> has joined #yocto08:45
*** fray <fray!> has joined #yocto08:47
XzI am patching binutils for target board. I patched binutils (_class_target), I patched binutis-cross08:47
Xzbinutils-native is not patched - correct08:48
*** zarul <zarul!~zarul@ubuntu/member/zarul> has joined #yocto08:48
Xzbinutils-crosssdk is not patched - I think wrong08:48
Xzsince my sdk toolchain does not contain the patch (and it should)08:48
XzI'm bit puzzled what should I do next08:48
ant_workRP: blame me...I insist doing tests after 1 o'clock in the night ;)08:49
Xzso the question would be - is binutils-crosssdk target part of my sdk toolchain?08:49
*** Frank_ichoo <Frank_ichoo!> has joined #yocto08:49
*** reallife <reallife!> has joined #yocto08:50
-YoctoAutoBuilder- build #74 of eclipse-plugin-kepler is complete: Failure [failed Building Eclipse Plugin Publishing Artifacts] Build details are at
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto08:51
RPXz: perhaps you actually want cross-canadian ?08:51
RPXz: we also *hate* target specific toolchain patches08:51
XzRP: I added new flag to binutils, that flag works nice for all target binaries built by Yocto build. However when I build SDK and install it (.sh script), then my installed toolchain does not have the flag.08:52
RPXz: you're probably missing it in binutils-cross-canadian08:52
XzRP: what is binutils-crosssdk then?08:53
*** seebs <seebs!> has joined #yocto08:53
*** mitz <mitz!> has joined #yocto08:53
RPXz: that is the compiler used to build the SDK target08:53
*** mitz <mitz!> has quit IRC08:53
*** gmacario <gmacario!> has joined #yocto08:53
XzRP: I thought binutils-nativesdk did that08:53
RPXz: i.e. we use the crosssdk compiler to build binutils-cross-canadian08:53
XzRP: there are like 6 versions of binutils overall08:54
RPXz: Correct08:54
XzRP: It always takes me a bit of time to think which does what08:54
*** mitz <mitz!> has joined #yocto08:54
XzRP: :)08:55
RPXz: its easier if you think about something like a compiler on darwin08:55
RPXz: for that you need a compiler which runs on BUILD but generates code to run on SDKHOST and when run on SDKHOST builds for target08:55
RPBUILD is 64bit x86, SDKHOST is darwin and TARGET could be 32bit uclibc x8608:56
RPcrosssdk runs no BUILD and generates SDKHOST08:56
XzRP: cool, I will try binutils-cross-canadian, thanks08:56
RPcross-candadian runs on SDKHOST and generates TARGET08:56
RPXz: for some cases we substitute in things like odcctools instead of bintuils for darwin for example08:57
XzRP: is darwin officialy supported by Yocto?08:58
RPXz: we do have the meta-darwin layer which can build SDKs which run on darwin08:58
RPXz: BUILD as darwin doesn't work at this point, nor is it likely to any time soon08:58
XzRP: I thought meta-darwin was more like an experimental dev layer, not full production Yocto code08:59
RPXz: the sdk pieces seem pretty stable09:00
RPits best effort support for it09:00
XzRP:  Nothing PROVIDES 'binutils-cross-canadian'09:01
XzRP: in my case BUILD=HOST09:02
XzRP:I'm not using SDK machine09:02
RPXz: try binutils-cross-canadian-i58609:02
XzRP: that worked09:02
RPXz: you must be using dora since ${TARGET_ARCH} was appended more recently09:02
XzRP: that fix is still for dylan :(09:03
XzRP: I upgraded to dora on branch however09:04
kroonRP, do you know how well the state of meta-mingw is for generating win32 sdks ?09:04
RPXz: well, its just called binutils-cross-canadian in dylan09:04
RPkroon: it can build gcc and binutils that run on win32 ok09:05
RPkroon: it has versions for dylan, dora, daisy and master09:05
kroonRP, ah great. will give it a shot then09:06
*** smartin__ is now known as smartin_09:10
*** beaver_545 <beaver_545!> has joined #yocto09:15
*** likewise <likewise!> has joined #yocto09:20
XzRP: will binutils-cross-canadian always target only 'target' board? I used sth like 'SRC_URI_class-append-target' in normal binutils to prevent appending the patch to -native10:04
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC10:06
XzRP: answering my question - I don't use class-target for binutils-cross-canadian, since it runs on SDK machine10:10
XzI think I still don't understand where -crosssdk and -nativesdk are in my puzzle10:20
Xzwhere are they built and where do they run?10:21
*** gmacario <gmacario!> has quit IRC10:21
XzI understand as much as: BUILD runs -native, -cross; HOST runs -cross-canadian; TARGET runs -10:22
*** gmacario <gmacario!> has joined #yocto10:22
RPXz: BUILD runs -native, -cross and -crosssdk10:26
RPXz: SDK runs -cross-canadian and -nativesdk10:26
RPXz: but seriously, the toolchain patch should be well enough written to apply everywhere and only trigger on the specific target its neeed for10:27
-YoctoAutoBuilder- build #73 of build-appliance is complete: Success [build successful] Build details are at
XzRP: are you telling my that I should apply the patch to every version of binutils?10:27
RPXz: ideally that should not cause a problem10:29
bluelightningah yes I was just about to find and paste that link :)10:29
XzRP: it's is not as good right now :(10:29
XzRP: right now the patch adds the flag which is by default switched on10:30
Xzso Yocto does not even know about that flag10:30
Xzhowever if I explicitly add it to CC flags10:30
RPXz: that is rather sad. If should be off by default and we start using the flag for the specific machines that have the issue10:31
Xzthen some tools fail, since they use CC flags for -native binaries10:31
XzI think ideally that should be part of 'tune'10:31
RPXz: If you add it to TARGET_CFLAGS those should not get used for native binaries10:31
RPXz: yes10:31
XzI played with TARGET_CFLAGS and smb used them for -native10:31
RPXz: then smb is broken10:32
*** mago_ <mago_!> has quit IRC10:41
*** zeeblex <zeeblex!~apalalax@> has left #yocto10:49
*** vali_enea <vali_enea!c1ca1642@gateway/web/freenode/ip.> has quit IRC10:54
*** milan_1 <milan_1!~milan@> has joined #yocto11:02
milan_1bluelightning: is there a way to add append to DISTROOVERRIDES and DISTROFEATURES from inside my custom layer ?  This should take effect only when I am including my custom layer for creating a particular image.11:06
*** challinan <challinan!> has quit IRC11:15
-YoctoAutoBuilder- build #70 of nightly-x32 is complete: Success [build successful] Build details are at
*** jluisn <jluisn!~quassel@> has joined #yocto11:20
-YoctoAutoBuilder- build #70 of nightly-qa-pam is complete: Success [build successful] Build details are at
bluelightningmilan_1: you should have your own distro config in your layer for doing those kind of things, which you then select by setting DISTRO in your local.conf11:22
bluelightninganything else is going to be a hack11:22
milan_1bluelightning: Looks like a sound approach... going to give this a try now. Thank you :)11:24
*** ajtag <ajtag!> has quit IRC11:47
*** diego_r <diego_r!> has quit IRC11:47
-YoctoAutoBuilder- build #70 of minnow is complete: Success [build successful] Build details are at
*** diego_r <diego_r!> has joined #yocto11:49
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC11:50
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto11:51
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto11:56
-YoctoAutoBuilder- build #70 of nightly-qa-systemd is complete: Success [build successful] Build details are at
*** fusman <fusman!~fahad@> has quit IRC12:01
*** bard3307 <bard3307!40c71302@gateway/web/freenode/ip.> has joined #yocto12:03
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC12:03
*** gmacario <gmacario!> has quit IRC12:07
*** zeeblex <zeeblex!~apalalax@> has joined #yocto12:07
*** kroon <kroon!> has quit IRC12:08
-YoctoAutoBuilder- build #70 of nightly-qa-logrotate is complete: Success [build successful] Build details are at
*** reallife <reallife!> has quit IRC12:14
*** reallife <reallife!> has joined #yocto12:14
paulbarkerI've found a couple of PRINC uses in meta-raspberrypi, are PR bumps still being accepted into oe-core to keep the upgrade path clean?12:22
paulbarkerthe files are recipes-bsp/formfactor/formfactor_0.0.bbappend with PRINC = "1" and recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend with PRINC := "${@int(PRINC) + 5}"12:24
*** adelcast <adelcast!~adelcast@> has joined #yocto12:26
-YoctoAutoBuilder- build #70 of nightly-qa-skeleton is complete: Success [build successful] Build details are at
*** ajtag <ajtag!> has joined #yocto12:28
*** zeddii <zeddii!~ddez@> has quit IRC12:31
*** kscherer <kscherer!~kscherer@> has joined #yocto12:32
-YoctoAutoBuilder- build #70 of minnow-lsb is complete: Success [build successful] Build details are at
*** zeddii <zeddii!~ddez@> has joined #yocto12:43
*** sroy_ <sroy_!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has joined #yocto12:44
*** kroon <kroon!> has joined #yocto12:52
*** gmacario <gmacario!> has joined #yocto12:56
-YoctoAutoBuilder- build #50 of nightly-deb is complete: Success [build successful] Build details are at
*** reallife <reallife!> has quit IRC13:00
*** reallife <reallife!> has joined #yocto13:00
*** kroon <kroon!> has quit IRC13:00
*** eballetbo_ <eballetbo_!> has quit IRC13:04
*** zeeblex <zeeblex!~apalalax@> has left #yocto13:08
*** sameo <sameo!~samuel@> has quit IRC13:21
*** Denwid <Denwid!c2cc4226@gateway/web/freenode/ip.> has joined #yocto13:23
DenwidHi. Is there a way to get bitbake variables with newlines included? If I do d.getVar("VAR") it's all on one line :-(.13:25
-YoctoAutoBuilder- build #72 of nightly-x86-64 is complete: Success [build successful] Build details are at
*** belen <belen!Adium@nat/intel/x-fczqfqybuwfgjcez> has joined #yocto13:37
-YoctoAutoBuilder- build #69 of nightly-fsl-ppc is complete: Success [build successful] Build details are at
*** kroon <kroon!> has joined #yocto13:44
*** rcw <rcw!~rwoolley@> has joined #yocto13:48
-YoctoAutoBuilder- build #51 of nightly-ipk is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #70 of nightly-x86-lsb is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #69 of nightly-x86 is complete: Success [build successful] Build details are at
*** ant_work <ant_work!> has quit IRC14:05
*** slex_kag <slex_kag!~kvirc@> has quit IRC14:05
*** Denwid <Denwid!c2cc4226@gateway/web/freenode/ip.> has quit IRC14:21
*** th_ is now known as th14:23
*** th <th!~th@unaffiliated/th> has joined #yocto14:23
*** ddalex <ddalex!~ddalex@> has quit IRC14:25
*** mebrown <mebrown!> has quit IRC14:28
*** mebrown <mebrown!> has joined #yocto14:28
*** oneQubit <oneQubit!> has quit IRC14:31
*** oneQubit <oneQubit!> has joined #yocto14:32
-YoctoAutoBuilder- build #51 of nightly-rpm is complete: Success [build successful] Build details are at
*** nitink <nitink!nitink@nat/intel/x-qphzoiesondqviry> has joined #yocto15:04
*** belen <belen!Adium@nat/intel/x-fczqfqybuwfgjcez> has quit IRC15:05
*** sjolley <sjolley!~sjolley@> has quit IRC15:09
*** lexano_ is now known as lexano15:11
*** khem <khem!> has quit IRC15:16
*** reallife <reallife!> has quit IRC15:16
*** reallife <reallife!> has joined #yocto15:16
*** milan_1 <milan_1!~milan@> has quit IRC15:23
*** roric <roric!> has quit IRC15:27
Xzwhat's the difference between meta-toolchain and meta-toolchain-sdk?15:32
*** khem` <khem`!> has joined #yocto15:32
*** khem` is now known as khem15:33
*** radzy_away is now known as radzy15:37
*** sjolley <sjolley!~sjolley@> has joined #yocto15:37
-YoctoAutoBuilder- build #72 of nightly-arm-lsb is complete: Success [build successful] Build details are at
*** jukkar <jukkar!jukka@nat/intel/x-ppdaqhtchtyhqbkb> has quit IRC15:39
-YoctoAutoBuilder- build #71 of nightly-x86-64-lsb is complete: Success [build successful] Build details are at
bluelightningXz: I though we discussed this the other day...15:41
bluelightningmaybe my memory is faulty15:43
sgw_khem: morning15:44
-YoctoAutoBuilder- build #71 of nightly-multilib is complete: Success [build successful] Build details are at
bluelightningXz: IIRC meta-toolchain-sdk was renamed a very long time ago - where do you see a reference to it?15:47
RPbluelightning: it will be dylan15:58
XzRP: bluelightning yes, just after sourcing oe script it gives example bitbake targets15:59
bluelightningwe probably didn't remove the reference until 1.6 though16:01
RP"sdk" in that context means a gnome mobile sdk16:02
volker-I love embedded systems, you run into settings that disappeared in the real world16:06
volker-today: passwords longer as 816:06
bluelightningvolker-: that's fixed in 1.616:07
volker-bluelightning: :)16:07
*** Crofton <Crofton!> has joined #yocto16:07
bluelightningbelieve it or not the upstream default is still to use 8 chars max :(16:07
volker-nothing against yocto, but in our case I was against it. It just should go on the NUC16:07
kergothick. which upstream?16:07
volker-Now I have to deal with security updates & co16:07
bluelightningkergoth: shadow16:08
kergoththat's sad16:08
bluelightningkergoth: very :(16:09
Croftonwe are getting ready to start OEDAM16:09
bluelightninghi Crofton16:09
bluelightningCrofton: any chance of a video/audio feed? ;)16:09
CroftonI foud a camera16:09
rburtonsomeone must have a space laptop to set up a google hangout :)16:09
Croftonhang on16:10
*** belen <belen!Adium@nat/intel/x-wnexpibqchrihrgr> has joined #yocto16:10
*** beaver_545 <beaver_545!> has quit IRC16:10
sgw_rburton: space laptop?  Is that one that is floating around over everyone's shoulder?16:11
rburtonthat would be awesome16:11
sgw_autonomous quadcopter with a camera and mic, might be a little annoying buzzing around16:12
*** jackmitchell <jackmitchell!> has quit IRC16:13
RPmorning Crofton16:14
*** arky <arky!~arky@> has joined #yocto16:17
* zeddii see fray on the google hangout16:19
fraymorning RP16:21
kergothdid anyone else lose video on the oedam feed, other than a picture of jefro? audio seems fine, though16:22
* kergoth yawns16:22
sgw_I can hear but not see16:22
frayya.. jefro turned off the video, too slow16:22
sgw_ah that explains it!16:23
fraywe figured out video was lagging about 3-4 minutes from realtime16:23
*** beaver_545 <beaver_545!> has joined #yocto16:23
kergothahh, okay, audio works16:23
darknightecan you guys hear the introductions well enough?16:23
bluelightningdarknighte: unfortunately not ...16:23
*** arky <arky!~arky@> has quit IRC16:23
zeddiithere's a one second delay and repeat at the moment.16:25
zeddii(for me at least)16:25
Croftonyeah the hangout get sdelayes16:26
* zeddii hears darknighte16:26
frayI dropped off the hangout, to make sure I'm not causing any issues16:26
fraythats about a 15-20 second delay then16:26
frayDenys is now on16:26
* RP can hear denys16:26
zeddiiand Crofton.16:26
sgw_audio is kind of choppy sounding16:26
* zeddii tries to distract people talking16:27
rburtonwhats the link?16:27
RPnow Linaro16:27
frayRP, sounds like you are nearly live then..16:27
RPnice to have comcast on board! :)16:29
RPnow michael16:29
RPand belen16:29
frayintroductions of the remote people..16:30
RPRichard is here, Yocto Project Architect16:30
RPSorry couldn't be there in person16:30
sgw_Saul is here, User Space Maintainer and Richard's Sous Chefd16:31
*** HerbKuta <HerbKuta!40baace2@gateway/web/freenode/ip.> has joined #yocto16:31
*** flynn378 <flynn378!80db310d@gateway/web/freenode/ip.> has joined #yocto16:31
bluelightningPaul Eggleton here, OE TSC member & bitbake / core build sys engineer on Yocto Project @ Intel16:32
RPsgw_: you're a deamon these days? :)16:32
*** beaver_545 <beaver_545!> has quit IRC16:32
zeddiiclang, clang.16:32
sgw_slip of the finger!16:32
* zeddii thanks his spokeperson fray16:33
*** ka6sox-here <ka6sox-here!40baace2@nasadmin/ka6sox> has joined #yocto16:33
bluelightningthat's "hash" OE to you guys ;)16:34
*** esben <esben!> has joined #yocto16:34
*** mr_science <mr_science!40baace2@gateway/web/freenode/ip.> has joined #yocto16:35
* RP notes the emphasis on long :)16:35
* mr_science needs food16:35
zeddiiRP: tl;dr16:35
rburtonRoss (Intel) was hoping to be here but daughters are demanding baths.  I'll be around later this evening.16:35
sgw_fray, can you summarize the list here, it's hard to hear sometimes16:36
fraythey're going over agenda.. determining what to do today, with some people not ebing able to be here tomorrow16:36
*** mr_science <mr_science!40baace2@gateway/web/freenode/ip.> has quit IRC16:37
*** mr_science <mr_science!40baace2@gentoo/developer/nerdboy> has joined #yocto16:37
*** jbrianceau is now known as jbrianceau_away16:37
fraybug scrub, probably tomorrow morning US time16:38
darknighteRP: will you be able to make that?16:38
* fray does his best to -stop- kicking the metal backstop of the table that clangs -very- loudly.. :P16:39
RPdarknighte: I can try and be around tomorrow, yes16:39
* RP has tried to keep this evening clear too16:39
frayreview bugzilla 1.7 tagged stuff...16:40
bluelightningI might be around later as well16:40
bluelightningpossibly tomorrow16:41
*** diego_r <diego_r!> has quit IRC16:42
frayactivity of layers as a possible indication of quality or at least maintainership16:42
frayLune to possibly replace sato as the demo UI..16:43
frayLune is a WebOS/QT based layer..16:43
frayI personally find this interesting16:43
Croftonthis falls into the bin of more working stuff :)16:43
*** roric <roric!> has joined #yocto16:43
frayfor OE/YP I see two demo issues..  showing the 'build' system doesn't help..  Toaster and a "working device" (UI) is a good demo16:44
*** seebs <seebs!> has quit IRC16:44
* otavio likes the Lune move as well16:46
*** seebs <seebs!> has joined #yocto16:46
bluelightningJaMa: do you have a link to some screenshots perhaps? ;)16:47
paulbarkerfor image deployment/update best practices, if there's any suggestions for opkg, i'm around16:47
JaMadoes link to virtualbox image work for you?16:47
*** slex_kag <slex_kag!~kvirc@> has joined #yocto16:48
bluelightningJaMa: sure, I'll take it :)16:48
JaMayou probably want .zip file which includes .ovf file you can just import to virtualbox16:49
RPtoaster is not yocto specific, works with standard OE too16:51
*** roric <roric!> has quit IRC16:51
RPIts just yocto sponsored I guess16:51
Croftonrp +116:51
-YoctoAutoBuilder- build #74 of nightly-arm is complete: Success [build successful] Build details are at
frayya.. I consider it the same.. sponsored, and maintained.. but it's part of bitbake16:53
Croftonbasically it wouldn't have happened without the YP :)16:53
JaMaHerbKuta: RP's e-mail:
volker-can someone point me to a bbappend file that uses postfuncs?16:54
volker-so far I have found the postfuncs only in bbclass files16:55
frayon-going role of TSC16:55
frayRichards email topic(s)16:55
fray(plan for the morning)16:55
frayvolker-, I've seen them.. but don't remember off hand which ones..16:56
zeddiidoes the plan for the evening include beer16:56
otavioWe at O.S. Systems been trying to get LAVA working at our side16:56
otaviobeen quite hard to get it working16:56
otaviobut we have people working on it16:56
RPotavio: you should mention that on the mailing list we setup to discuss it16:57
otavioRP: I've been talking to Debian and Linaro people about it (we don't like running Ubuntu in server ;P)16:57
otavioRP: so we're still in the beggning on it16:58
bluelightningI'd be keen to see more discussion of people's progress on automated testing on the mailing list16:58
bluelightning(the one)16:58
bluelightningit's been a bit quiet16:58
otaviobluelightning: we're trying those to see what fits better for us16:58
otaviobluelightning: yes16:58
otaviobluelightning: that's why I didn't comment on it yet. I still didn't make my head on it yet16:59
frayok.. lava discussion time.. :)16:59
bluelightningmpc8315e-rdb (PPC)17:00
zeddiianyone else have the reverb/echo on the audio ? I wonder if it is just me.17:01
RPzeddii: not noticing echo, it can be hard to follow though17:02
fraytalking about tests that we may be running on the autobuilder that could be moved into the lava environment..17:02
fraymost likely Intel and ARM are the primary targets of LAVA right now17:02
zeddiiok. I'm getting brutal echo. so it might just be my box.17:02
zeddiioh crap. I just figured it out. my gmail tab AND g+ were both playing audio. on a different delay.17:03
zeddiimy head hurts WAY less now.17:03
otavioRP: zeddii agreed. hard to follow17:04
fraytalk about needing packages feeds, compiler on target, etc to faciliate testing with LAVA17:04
fray(from the Yocto autobuilder)17:05
RPCrofton: what is the question?17:05
-YoctoAutoBuilder- build #68 of nightly-mips-lsb is complete: Success [build successful] Build details are at
fraydo we have any regular autobuilder images that include the compiler on the target17:05
RPwe build the build-appliance image which contains everything needed to run a yocto build in it17:05
maxinbluelightning: otavio: Out of curiosity, Is it confirmed that we are going ahead with LAVA for testing ?17:05
RPso we know the toolchains work!17:05
fraydo we do that for all architectures?17:05
frayI know we test they work..b ut wasn't sure bout regular images17:05
RPfray: not build-appliance but we do build sdk images for all arches and run the automated tests against them17:06
RPwe do test the compilers in those17:06
fraymy understanding of the LAVA is we'd like the Linaro LAVA testing to use the output of the autobuilder for more test coverage17:06
bluelightningmaxin: several YP member organisations are adopting LAVA, so it's the direction we're heading in17:06
bluelightningmaxin: providing it can be made to work well for us17:07
otaviomaxin: About OE/YP this is not yet decided but O.S. surely will go ahead with it in our side17:07
RPdev images are built for all arches17:07
volker-I am wondering why my bbappend file is not used. when I run --debug I see virtual:native:/home/data/yocto/poky/meta/recipes-extended/shadow/;  now I am wondering if the do_configure[postfuncs] are not used because it states "virtual:native:"17:07
halsteadCrofton, i think this is a full package feed for ipk
maxinbluelightning: thanks.. time to switch to LAVA then ..17:07
bluelightningI've said this before but FYI for 1.6 we've added capabilities to export the runtime tests we've written so far in OE-Core to be run independent of the build system17:08
bluelightningso LAVA should be able to run those without too much trouble17:08
otaviomaxin: bring some coffee ... it will be complex :P17:09
*** Rootert <Rootert!> has quit IRC17:09
*** RagBal_ <RagBal_!> has joined #yocto17:09
RPautobuilder publishes to http right now17:09
*** Rootert <Rootert!> has joined #yocto17:09
JaMaotavio: are you working on integrating lava in sense of providing lava-native you can build and then just run (independently from host system)?17:10
maxinotavio: It will be a bit more complex to persuade people to switch from an existing test setup.. Anyway, guess, a common system will be nice :)17:10
kergothvolker-: is there a reason the bbclass examples don't work for you? syntactically it's exactly the same :)17:10
otavioJaMa: in which sense you mean?17:10
volker-kergoth: I want to run postfuncs in shadow_4.1.4.3.bbappend to enable SHA51217:11
otavioJaMa: you mean the peaces which need to run in the target or to build the distro to run in the LAVA server?17:11
frayI would like to see LAVA as something 'integrated'.. but immediate value of being able to just run it on a lava server would be nice17:11
frayvolker- ahh you are talking post install (package) scripts..17:11
frayI thought you were talking sysroot configuration (development time)17:11
otaviomaxin: yes17:12
frayI'll see if I can find an example17:12
JaMaotavio: "(we don't like running Ubuntu in server ;P)" this sense, can we include lava server in build-apliance?17:12
otaviomaxin: and LAVA installation is quite complex17:12
kergothi think he's talking about the flag, to run source alterations other than patches at do_unpack/do_patch time, atually17:12
otavioJaMa: yes; this would be a good solution17:12
volker-fray: no, I just want to add a function to do_install to sed one file17:12
otavioJaMa: for now we intend to use Debian as host17:13
*** RagBal <RagBal!> has quit IRC17:13
kergothvolker-: just use do_install_append17:13
fraydo_install_append() {17:13
otavioJaMa: and try to have it working and easy to install/setup17:13
fray  stuff to do in additional to do_install17:13
JaMaotavio: ok fair enough17:13
otavioJaMa: once this is doable, making a recipe for this shouldn't be hard ...17:13
frayotherwise it's pkg_postinstal_<package> () {  ....  } those are install time settings17:13
otavioJaMa: but it is far from it yet17:14
* RP notes we have easy setup instructions for the autobuilder right now17:14
RPlava is by comparison hard to setup :(17:14
volker-kergoth: thats it. just wondering why do_install[postfuncs] neither worked nor spit out an error17:15
kergothshould work fine, if you want to do that17:15
fraypostfuncs isn't what you want in this case.. you want appends IMHO17:16
kergoththough sometimes i wish _append/_prepend was backed by postfuncs/prefuncs, to avoid the appending shell to python madness ;)17:17
volker-so it works now, now I am wondering why the --debug didn't show the bbappend file (which is definitly used as I can see now): bitbake -c clean shadow-native ;bitbake -c build shadow-native --debug|grep bbappend17:17
kergothvolker-: bitbake-layers show-appends|grep shadow17:17
volker-kergoth: I would still have expected it in --debug17:17
otavioPhone! Answer it heh17:18
bluelightningvolker-: our debug output could certainly use work17:19
bluelightningI suspect that because it's not that useful, not many use it - we use other means of finding such information17:20
*** tlwoerner___ <tlwoerner___!40baace2@gateway/web/freenode/ip.> has joined #yocto17:20
frayI don't use --debug.. I use live logging (local patch to bitbake), bitbake -e <recipe>, and looking at logs/run files..17:20
sgw_Hi Khem, sounds like good discuss, wish I could be down there this week.17:26
RPfray: Worth mentioning the error reporting server?17:31
RPfray: we've talked about collecting more data with that17:31
*** codinho <codinho!> has joined #yocto17:31
*** codinho <codinho!~me@unaffiliated/codinho> has joined #yocto17:31
frayha.. I was just msging someone about that..17:31
fraythats more build errors though right?17:32
Croftonthis is collecting build errors?17:32
Croftonthis is also cool :)17:32
*** gmacario <gmacario!> has quit IRC17:32
RPfray: right now it collects those, yes17:32
RPCrofton: people can submit them, yes. new feature in 1.617:32
JaMaworld builds now do (unless the report is too big to upload)17:33
RPWe are talking about scaling that system to take extra data. Perhaps performance data?17:35
frayany type of runtime test data, yes17:35
* JaMa already has fork reporting "build matrics", I plan to show it to belen to see what she thinks about it and integration with toaster/error-report-web17:36
fraythat would be me.. :P17:36
RPit feeds into a database17:36
RPits not conencted to the bugzilla17:36
RPwe don't want to automatically connect it17:37
RPIts like a failure pastebin17:37
bluelightningit's mostly about collecting all of the information we otherwise rely upon users correctly extracting and reporting themselves17:37
Croftonthe suggestion is add a button to fiil a bug template and submit it17:37
RPfray: exactly - the statistics will be interesting17:37
RPwe need to figure out how to match up failures but we can do than once we have some data17:38
frayI'm really looking forward to statistics.. even failures due to bad configurations.. ;)17:38
RPfray: totally, I think we could learn some interesting things17:38
fraymisconfiguration is one of those things if we could "detect" via common bugs, we could then return back "this is how to correct it" info.. :)17:39
RPfray: exactly, ultimately I'd like to tag things with solutions17:39
mr_sciencei thought this idea was also somewhere on the agenda, ie, a more "formal" aproach to bug wrangling17:40
fraypeople are off looking for display equipment.. 9and taking a break.. ;)17:40
-YoctoAutoBuilder- build #70 of nightly-mips is complete: Success [build successful] Build details are at
belenRP, fray: the querying capabilities of the existing tool are very limited, though. As data comes in we might need to enhance them so that you people can get the information you need from it17:40
*** sjolley <sjolley!~sjolley@> has quit IRC17:41
fraybelen, yup..  this is future work.. :)17:42
RPbelen: totally agreed. We need some data, then we can experiment and design :)17:42
frayRP/belen this is some of the stuff that David R is trying to setup for our WR products..  it's the infrastructure to support this that we really want.. (community and commercially)17:44
frayover time I expect more community data transform/displays..17:45
sgw_fray, are we supposed to see something?17:45
fraynot yet..17:45
fraywe've figure out the projector in the room.. and jefro is figuring out how tuse to the web cam to show you17:45
sgw_I see a small icon for the slide I think, maybe make that person the speaker17:45
sgw_If I click on that icon it comes up on my screen17:46
fraynot sure17:46
-YoctoAutoBuilder- build #69 of nightly-fsl-arm is complete: Success [build successful] Build details are at
RPdoes anyone know anything? :)17:51
fraynope..  I know nothing..17:51
frayas any normal tech meeting, 1/3 of the room is playing IT.. 1/3 is typing and 1/3 is ignoring everyone else.. :)17:52
RPI am seeing video of some of you now :)17:52
* RP waves to fray17:52
* sgw_ waves back17:53
*** JimBaxter <JimBaxter!~jbaxter@> has joined #yocto17:53
*** JimBaxter <JimBaxter!~jbaxter@> has quit IRC17:53
fraycan people see the slide(s)?17:55
RPfray: from Alan? yes17:55
Croftonlava is like bitbake for testing!17:55
otaviowhere? I see nothing17:56
otavioCrofton: pertect definition lol17:57
RPfray: they're not advancing unless you're still on the title slide17:57
otavioCrofton: in the past when it were most of time broken ;-)17:57
frayit's ont eh 'Vocabulary slide'17:57
otavioRP: where is the slides?17:57
RPotavio: from Alan's video feed afaict but its just the title one17:58
frayvideo feed might be delayed17:58
bluelightningyep same here17:58
RPfray: the other video feeds look in realtime17:59
sgw_I think that we are seeing the desktop screen, not the projected screen17:59
frayso left side.. kernel source -> jenkinx -> "raw artifacts"17:59
frayother builds -> "raw artifacts"17:59
sgw_slide the jeffery camera over to the screen17:59
fray"raw artifacts" <--> laval  (job control, test and boot logs)17:59
sgw_not the one with Jefro the one looking at Alan's body!17:59
fray"raw artifacts <--> Generic board farm17:59
RPmuch better18:00
fraythat better.. 4 minutes or less.. :)18:00
sgw_thats better18:00
otaviowhere is the video link?18:02
frayshould be the google link18:02
fraywas just on the main page when I connected earlier18:02
paulbarkeri can't find it either, just got the original video link which seems to have ended18:03
otavioohhh now I see18:04
fraymaybe you have to reload?18:04
bluelightningsomeone tell jefro it's off-air18:04
fraywhat is?18:04
sgw_still on here18:04
RPstill here too18:05
bluelightningI can still see it, but it might explain why Paul isn't able to do so18:05
bluelightningfray: in the top right it says "OFF AIR" instead of earlier when it said "LIVE"18:06
frayjefro was trying ot fix18:06
fraystill having issues?18:07
bluelightningpaulbarker: ^ ?18:09
-YoctoAutoBuilder- build #70 of nightly-world is complete: Success [build successful] Build details are at
paulbarkersorry, yes, i'm still lost18:10
bluelightningit still says "OFF AIR" FWIW18:10
bluelightningsomewhere the moderator should have a switch for that18:10
volker-The latest samba recipe is 3.6.8 which is kinda old.18:11
*** jluisn <jluisn!~quassel@> has quit IRC18:11
darknightebluelightning: paulbarker: jefro is still working on it18:11
paulbarkerI just have the original google+ event invite with the video which has finished18:12
bluelightningok, now Jefro's gone so there's no audio at all18:12
paulbarkerif it's just me that's missing don't worry18:12
frayjefro is going to restart..18:12
Croftonjefro is being beaten18:12
paulbarkerback in 10 min or so, will give it another try then18:12
*** jluisn <jluisn!~quassel@> has joined #yocto18:12
bluelightningI think I'm going to have to head home in a sec18:12
fraywhat we'e said is goal is multiple systems, multiple visualizations for various components..18:13
fraybuild error reporting, toaster, runtime test, autobuilder, etc..18:13
frayover time we can work on putting those together for a visualization, but we want the 'unix' model of lots of small tools that can work together18:13
otavioSomeone is taking notes? So we discuss things in ml right?18:13
mr_sciencewiki page?18:14
fraystep 1 -- autobuilder assets to LAVA18:14
Croftonyeah we are having DarkKnight collect the  actoins18:14
RPfray: we've back now, thanks18:14
fraystep 2 -- existing lava tests to those assets18:14
RPat least audio anyway18:14
fraystep 3 -- adding 1.6+ tests to lava...18:14
fray(this is bill talking BTW)18:14
fraylow hanging fruit.. lets prove this works and is useful18:14
bluelightningFYI, we added basic capabilities in this area in master (deploy an image and run the tests) for EFI (via gummiboot), beaglebone, and edgerouter18:17
bluelightningthe idea being that gives us coverage for our QA requirements now18:18
fraywe're breaking up temporarily.. :/ sorry..18:19
bluelightningeven when we make use of LAVA for our QA, it can still be useful for running tests on a single board connected directly to a developer's machine18:19
bluelightningI don't think we have 2000 tests18:22
RPno, 2000 doesn't sound quite right :)18:23
bluelightningI'm going to have to head out in 5 mins18:25
RPbluelightning: sounds like its lunchtime there18:27
bluelightningright, good timing :)18:27
* RP should cook something...18:28
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:30
*** sjolley <sjolley!~sjolley@> has joined #yocto18:30
*** sjolley1 <sjolley1!sjolley@nat/intel/x-tytajfurmqulzrju> has joined #yocto18:31
*** sjolley <sjolley!~sjolley@> has quit IRC18:31
-YoctoAutoBuilder- build #69 of nightly-fsl-arm-lsb is complete: Success [build successful] Build details are at
*** nitink <nitink!nitink@nat/intel/x-qphzoiesondqviry> has quit IRC18:33
paulbarkerback for now, I don't have much to add on LAVA and testing but may be able to add a few comments to later items on the agenda18:34
paulbarkerjust give me a ping if theres a new link for the video or if it should be re-started18:36
darknightepaulbarker: will do18:36
rburtoni join the hangout and the first thing i hear is "i am ordering pizza"18:36
rburtonyou bastards18:36
paulbarkeri've got a segfault to debug which should keep by plenty busy in the meantime :)18:37
mr_sciencemmmm....   pizza....18:37
darknighteRP: you here?18:37
rburtonexactly.  maybe i'll go and find dinner myself, the audio quality isn't excellent.18:37
rburtonbut my 2c as the Sato "maintainer" is that proposals for replacements are welcome18:38
darknighterburton: that's on the list for discussion, but is 2 more items down the list18:38
rburtonyeah, i'll be back later to check in18:39
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto18:49
* RP is back around18:50
darknighteRP: Good news.  The OE TSC still exists.  ;)18:51
RPdarknighte: er, good, I think? :)18:52
JaMaI don't want to replace anybody, but I'm fine now with steping up if needed18:52
* RP hasn't heard anyone wanting to step away18:53
RPfray: I think most people are in that position18:53
darknighteFor context, I made a tongue-in-cheek suggestion that we do away with the TSC and fray, sorta took me seriously18:53
frayI've heard that before, not so tongue-in-cheek.. :)18:54
kergothRP: Any objection to my submitting this bbclass to oe-core for the 1.7 timeframe? I think there'd be value in providing this feature. Alternatively, could pursue bitbake or base.bbclass support for it. Thoughts?18:55
* kergoth 'll open a request in the bugzilla, just wanted to check on the overall response to the concept first18:55
RPkergoth: I'd be happy to see it in bitbake to be honest18:56
fraynot sure hwat it is.. ;)18:57
* kergoth would love to see us pare down the global exports, and this would make it a bit easier to move in that direction18:57
kergothRP: okay, I'll look in that direction. thanks18:57
RPkergoth: I was just thinking the same18:57
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has quit IRC18:57
*** slex_kag <slex_kag!~kvirc@> has quit IRC18:58
kergoththe tough ones to trim down would be CC, etc. autotools.bbclass could export them in do_configure, but do_compile/do_install are stuck with them for non-autotools/cmake/etc, since we don't have a "make" bbclass :) but there are others we could trim down too18:58
JaMaMoving to
RPkergoth: I wondered about a make class. Would be a pain to switch to but possibly worthwhile18:59
kergothmaybe we could make the -e in default EXTRA_OEMAKE die in a fire too someday :)19:00
*** nitink <nitink!nitink@nat/intel/x-yyzrxtngiivcyjwd> has joined #yocto19:02
RPkergoth: yes :)19:03
RPfray: yes, even documented those workflows as we can make them work today, that would be a good first step19:04
*** rburton <rburton!> has quit IRC19:06
denixnerdboy: so, you essentially said something similar to "we migrated from Poky to Yocto"... grrr19:07
belenwe have started an effort to document the workflow. It's still very rough, though19:09
mr_sciencedenix: i thought i said arago classic...19:09
denixmr_science: cause you keep saying "migrated from Arago Project to Yocto"19:09
denixmr_science: what you mean is "migrated from OE classic to OE core" or "from OE core to Yocto" etc19:10
mr_scienceyeah, that's more precise19:10
denixmr_science: since Arago exists in OE-core and Yocto world19:11
RPbelen: that is quite interesting. I should sit down with you and complicate that sometime :)19:11
belenRP: yes19:11
*** rburton <rburton!> has joined #yocto19:11
kergothbelen: interesting, nice start19:12
belenkergoth: we need people to pitch in, so if something doesn't look right in that diagram, let us know19:13
* kergoth nods, will take a closer look and point folks at his work at it19:13
RPfray: bitbake X S printdiff is a step forward if you've not seen it19:15
RPbitbake X -S printdiff19:15
RPtell Bill to see the locked sstate idea in the email :)19:16
kergothas long as you didn't use an sstate mirror, anyway :) need those intermediate siginfos19:16
RPkergoth: the mirrors should have those now19:16
CroftonRP, fray is doing a good job channeling you19:17
kergothRP: pstage_fetch downloads them?19:17
rburtonCrofton: that would be the intel mind meld19:17
kergothlast time i looked it didn't, it just downloads the sstate archive and associated siginfo file, which doesn't have the intermediate data, unless we started emitting depednent task info in that siginfo file19:17
* kergoth shrugs19:17
RPkergoth: I believe it should grab them now19:18
RPkergoth: I might not have covered all cases I guess19:18
fraypizza looks to be here..19:21
rburtonagain with the pizza19:22
kergothRP: I must be missing something. dump_sigtask seems to still only emit data for the one task, and sstate_setscene only runs sstate_installpkg on the one ss object, and sstate_installpkg is the only task that runs pstaging_fetch. Where can I find what you're talking about?19:22
kergothI'm sure I must just be missing it, maybe I didn't follow the code correctly19:22
RPCrofton: exactly, we document something to start with, then we can improve them19:24
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has quit IRC19:25
* kergoth gets food19:25
RPkergoth: its triggered by calling the HASHCHECK_FUNCTION (sstate_checkhashes) in sstate.bbclass iirc19:26
RPkergoth:  print_diffscenetasks() calls that checkhashes function which was intended to try and find the siginfo iirc19:27
RPkergoth: I suspect what is missing is a way to trigger the checkstatus() to actually run the download19:28
fraygoes to get food.. comes back shortly..19:28
* RP heard mention of drinks, then the noise took over19:28
kergothRP: yep, thats what i was jsut about to say after reading it. it seems to check to see if it's there, and then not do much with that information :) thanks for the pointer19:28
RPkergoth: I probably had a local patch that has gotten lost or something :/19:29
kergothheh, know how that is. I have so many branches in so many trees i'm always losing track of what's where. sometimes end up reimpementing something :)19:29
*** sjolley1 <sjolley1!sjolley@nat/intel/x-tytajfurmqulzrju> has quit IRC19:30
* rburton cooks to the dulcet tones of many people chatting, captured terribly via hangouts19:31
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:5e51:4fff:febb:401d> has joined #yocto19:34
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:5e51:4fff:febb:401d> has quit IRC19:34
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:34
*** tlwoerner___ <tlwoerner___!40baace2@gateway/web/freenode/ip.> has quit IRC19:34
*** joeythesaint <joeythesaint!~jjm@> has quit IRC19:35
*** belen <belen!Adium@nat/intel/x-wnexpibqchrihrgr> has quit IRC19:35
RPrburton: here, I have it going through the power amp with the volume up so I can understand it. The neighbours probably think I have a party going on :)19:44
* rburton dropped to watch the last of the downhill world cup19:45
rburtoni like how hangouts does a soft-mute when you press the mute button, so it can tell you if you're talking on mute19:49
*** belen <belen!~Adium@> has joined #yocto19:49
volker-does yocto provide a way to cross-execute executables? (
rburtonyes, using qemu19:58
rburtononly use if its impossible to built native tooling19:59
rburton(ie fontconfig uses it because the fontconfig cache format is target-specific)19:59
rburtonwhereas mesa builds native tools directly because the output is platform independent19:59
volker-looking into fontconfig, I only see there the line 'BBCLASSEXTEND = "native"', now ;bitbake samba4-native -c configure does not do the trick (where samba4 is the recipe name)20:09
fraywe've resumed.. "why is embedded difficult"20:13
RPvolker-: see fontcache.bbclass20:15
* RP notes we do all have various ways we can do quick hack'n'dev with OE20:16
RPe.g. bitbake X -c compile -f and then a rsync task which blasts it onto the target20:16
RPdocumenting them is key20:16
RPwhere there is commonly used functionality, we can write classes etc20:16
fraydocumenting is the first key.. like I said before, list of steps..20:17
fraythen it's look at the steps and simplify20:17
RPvolker-: or pixbufcache.bbclass20:17
volker-RP: that are all classes. I want to have it in a recipe. Right now I am looking through fontcache.bbclass and don't get the clue20:18
RPvolker-: try pixbuf and the inherit qemu20:18
*** sjolley <sjolley!sjolley@nat/intel/x-iqdisldxhrjcuzap> has joined #yocto20:19
*** challinan <challinan!> has joined #yocto20:21
*** radzy is now known as radzy_away20:21
* RP wonders what would happen if we publisised the sstate from the autobuilder by default in builds20:22
*** e8johan <e8johan!> has joined #yocto20:22
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has joined #yocto20:23
bluelightningI think there's still some work to do in optimising and making use of sstate20:23
RPfray: what was that point?20:23
RPbluelightning: agreed, very much so20:23
frayI said that shared-state was a good answer to both the integrator issue (slow builds), and for getting images built for deployment..20:23
RPfray: right, thanks20:24
fraybut it "works" now, so the next step is package feeds, for the class of users who are "using" the base OS..20:24
halsteadRP, We would need to move the autobuilder something with greater available bandwidth for that to be feasible.  (Which is something we are looking into now.)20:24
bluelightninghalstead: terabytes of output though is a problem, we shouldn't have that much to share in the first place IMO20:25
*** roric <roric!> has joined #yocto20:25
RPhalstead: or mirror the data somewhere with the bandwidth, yes20:25
RPhalstead: I'm just talking about the idea, so don't panic yet :)20:26
*** HerbKuta <HerbKuta!40baace2@gateway/web/freenode/ip.> has quit IRC20:26
RPbluelightning: this is from all the rebuilds on the AB of things like master-next and mut20:26
halsteadI'm not panicked RP. Solving infra problems is fun. :)20:26
bluelightningRP: right20:26
frayRP, i was talking about that earlier in some way.. what I see the sstate being useful for (sharing) is the "big" early blocker items.. cross-toolchain primarily20:27
RPhalstead: If the infrastructure were capable it would be interesting to try it20:27
RPfray: unfortunately that is also large20:27
frayyes, but it's one of the components I see that someone with "modern" bandwitdh (say 10 Mbit/s) on a moderate mchine can download faster then rebuild..20:27
RPfray: with the changes just landed in master we now have one toolchain for each arch which will help the size20:27
RPfray: agreed20:28
*** e8johan <e8johan!> has quit IRC20:28
fray(unrelated to this topic) for the single arch toolchain.. I was wondering if we should consider creating a custom gcc "spec" with '-t' options to specify the multilib/tune/etc with a single command instead of the long set of -march, -mtune, -m....20:28
RPfray: I'm not sure we have an issue with that but its something to think about20:30
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has quit IRC20:31
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has joined #yocto20:31
paulbarkercould consider bittorrent to help with distribution but it would depend on how many different sets of bootstrap sstate there are to share and how often it changes20:33
*** rburton <rburton!> has quit IRC20:34
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has quit IRC20:34
bluelightningRP's locked sstate patches provide the capability to do what Bill is talking about20:34
frayit would prevent the rebuild.. but it would likely error and say hey this is a dependency20:35
*** rburton <rburton!> has joined #yocto20:36
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has joined #yocto20:37
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has quit IRC20:38
bluelightningvisual dry run would be nice :)20:39
RPbitbake X -S printdiff is effectively a dry run in that it will tell you where the differences start20:40
*** e8johan <e8johan!> has joined #yocto20:42
RPexternal compilers are hard since in reality its the compiler and the libc and lingcc. When you get libc/libgcc involved, things get harder as those have to be packaged20:42
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has joined #yocto20:42
RPlocked sstate is the way forward for that IMO20:42
fraywhat I was saying was SDK compiler, and a standard way to use it.. (and validate it's the 'right' compiler)20:43
bluelightningit won't be 4TB20:44
RPit doesn't have to be 4TB of sstate20:44
RPits the size of the toolchain20:44
sgw_Saul is still here20:44
RPits say 200MB20:44
RPif that20:44
mr_sciencethat's not too bad...20:45
sgw_fray: I am in view only mode20:45
halsteadRP, Is it a matter of identifying the correct 200MB?20:45
bluelightninghalstead: yes, being selective about what we publish effectively20:46
RPhalstead: yes, we could filter the sstate directory relatively easilyt20:47
halsteadIf it is below 5GB that should be easy to distribute. In fact if it is 5GB or less and the largest file is 200MB or less I can get a grant for free CDN services to distribute.20:49
ka6sox-herefor a developer on a <10Mb connection that means overnight20:49
* sgw_ dropped I will read minutes later, sorry20:50
*** jluisn <jluisn!~quassel@> has quit IRC20:51
halsteadka6sox-here, I would think a developer with low bandwidth would choose not to use distributed sstate. But if we can get important files on a CDN that would be effectively full speed downloads for people with higher bandwidth.20:52
RPhalstead: part of the problem is the turnover. For something static like a release like dora, it wouldn't change much. master changes a lot20:55
*** challinan <challinan!> has quit IRC20:55
* halstead nods.20:56
halsteadIs sstate valuable for releases without following master?20:57
*** rcw <rcw!~rwoolley@> has quit IRC20:58
RPhalstead: for release, its in theory exactly what the user would build, so yes, it would be a valuable new user speedup20:58
volker-what is the downside of <pkg>-native builds?20:58
volker-only time?20:59
*** sroy_ <sroy_!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has quit IRC20:59
RPvolker-: pretty much21:00
kergothThat reminds me, would be nice to create a little class to set up license-filtered sstate mirror population, to cover cases where one might not have redistribution rights to binaries21:00
RPkergoth: I have worried about that, yes :/21:00
RPwe should really add something to the bugzilla for that21:00
volker-is there a way to only allow -native builds of a package without overwriting each config(), patch() etc?21:01
rburtoncall it something-native and inherit native21:02
RPThis is a screen capture of how I'm seeing this call: I'm slightly unsure if hypnosis is intended and what the message may be... :)21:02
RPvolker-: or raise a SkipPackage in the target case (and not in the native)21:03
volker-SkipPackage does not seem to be documented in 1.5.121:04
volker-code digging21:04
Croftonrp, rofl21:04
*** bard3307 <bard3307!40c71302@gateway/web/freenode/ip.> has quit IRC21:04
bluelightningTAINTED: xyz21:04
RPvolker-: try something like recipes-support/libiconv/libiconv_1.11.1.bb21:05
bluelightningI have no mirrors at work :)21:06
volker-yocto has so many hacks to accomplish things. But somehow it misses a good reference page for all of them.21:07
RPvolker-: if SkipPackage isn't in the manual, we should document it, I will make a note of thatr21:07
RPIt should also be called SkipRecipe21:08
RPCan I just say we once did try reusing the SDK toolchain21:08
bluelightningRP: that's bothered me for a while, we should alias it in 1.7 and deprecate SkipPackage21:08
Croftonrp sure :)21:08
volker-RP: maybe not in the main developer documentation. But I found good examples after grepping for it. Usage with python __anonymous()21:08
RPreusing the SDK toolchain was a complete and utter disaster21:08
CroftonI appoint fray to find out if works yet :)21:08
kergothwe should deprecate __anonymous while we're at it, just to increase metadata consistency21:09
RPCrofton: It is NEVER going to work well and we are not supporting that21:09
RPWorld of pain that still gives me nightmares21:09
volker-kergoth: great, I learn something that is broken the next time ;-)21:09
RPinstead I'd rather rewrite the SDK to be built from sstate21:09
kergothvolker-: just use python () { instead of python __anonymous (). both do the same thing, but the latter is unnecessary21:09
RPkergoth: yes21:10
volker-man, I tortured myself for hours to get samba build without success. And then I got indirectly pointed to native and it works like charm...21:13
rburtonof course a native build is no good for the target21:16
bluelightningquantity that are on github vs. actually indexed in the layer index *is* still a problem though...21:17
RPbluelightning: yes :(21:18
RPCrofton: No, we don't21:18
frayI've seen a -lot- of duplicates on github.. people seeb to copy layers into their own githubs and make their custom changes (fork?)21:18
bluelightningfray: there are a ton of original layers there too21:18
RPCrofton: The policy is that we do not support that unless someone joins the triage team to help out with the bugs21:18
kergothforks are half the point of github :) not too surprising there21:19
bluelightningit's a real shame that the people who are publishing them don't see the value of the small extra step of putting them into the index21:19
RPfray: thank you for conveying that :)21:20
belenbluelightning: you cannot expect them to. We need to make some (gentle) noise about it21:21
paulbarkera lot of people show up on the mailing list asking to find recipes which could easily be found by searching the layer index so perhaps it needs to be more publicised21:21
paulbarker(or people may just be lazy)21:21
bluelightningbelen: I do keep complaining about it on here and in the mailing list, it's not had a lot of effect21:21
RPbluelightning: we can make it a criteria for yocto project compatible21:22
RPnot that it will help this problem21:22
belenbluelightning: maybe we need to reach out further than the mailing list and the channel21:22
bluelightningRP: might not hurt at least21:22
bluelightningbelen: might be an idea yes21:22
volker-samba4 source code comes with 22 different LICENSE files21:32
bluelightningpaulbarker: I'm open to suggestions about how to better promote it21:34
bluelightningthe new website when it arrives may help21:34
volker-and there are 9 unique licenses in this 22 license bundle21:36
RPJaMa: its a hard task, you're doing a good job and I hope we can encourage some more people to help...21:37
mr_sciencebluelightning: there's no poky in the layer dep selector21:37
bluelightningmr_science: use OE-Core ;)21:37
mr_scienceshould be meta-yocto I guess?21:38
bluelightningmr_science: openembedded-core21:38
* RP is in favour of wider use of the error reporting system, we just need it opt in21:40
mr_sciencei swear i thought i did that already, so if i did it got rejected21:40
mr_sciencebluelightning: thanks for reminding me...21:41
frayRP yup21:41
Croftonneed to figure out what that lava job did :)21:42
*** radzy_away is now known as radzy21:42
Croftonakbennett, had to leave for th eairport21:42
bluelightningmr_science: I think you submitted another layer, but not this one... FWIW I've just published this one, thanks :)21:43
JaMaRP: the patch I've sent was opt-in, but it doesn't prevent distribution maintainer to flip the flag and opt-in for whole distro by default21:44
bluelightningfray: meta-selinux *is* in the layer index FWIW ;)21:44
bluelightningre perl if anyone is keen there's a ton of recipes waiting to be integrated - they just need some cleanup21:45
volker-Yocto 1.5.1, meta/files/common-licenses/PD: "This is a placeholder for the Public Domain License"21:46
fraybluelightning yup.. :)21:46
bluelightningvolker-: I think that came from SPDX21:46
RPJaMa: I think ultimately we should do this on a user by user basis, maybe something in $HOME21:46
frayre perl, I didn't know that21:46
mr_sciencebluelightning: can you prioritize "tons"?21:46
bluelightningfray: I've been holding onto them since the original submitter never finished fixiing them up for integration21:47
bluelightningmr_science: maybe tons is an exaggeration, but it's a few21:47
bluelightningone sec21:47
RPbluelightning: were these mind or some others?21:47
bluelightningRP: well there were those too21:48
bluelightningI was referring to
JaMaRP: but then it doesn't help with our use-case (not sure if it was understandable in audio)21:48
bluelightning(+ pull request of mine on that repo not yet applied)21:48
RPJaMa: the company wide one?21:48
JaMawe want to enable/disable it for *all* internal builds21:48
JaMaif it's file in $HOME then my next task will be to update "setup-scripts" to create that file for all developers21:49
RPJaMa: but I think that might be the correct way to do it21:49
bluelightningCrofton: we can auto-update the db if people start using that file - FYI already have code to read it21:49
RPJaMa: I worry about the day someone sets some distro config and all of a sudden a user leaks data they shouldn't have :/21:49
Croftonthe NSA already knows21:50
RPrunning a script that does it is quite different to bitbake doing it based on config21:50
bluelightningCrofton: ah but they know everything, it's us that needs to know :)21:50
JaMaas distro maintainer I can create recipe which will copy their whole $HOME, if they don't care what their distro do, then they cannot prevent leaking all data21:50
RPJaMa: but that doesn't mean I should take a function into the core so that all distros can do this using a common function :)21:51
RPJaMa: I'll likely end up patching our autobuilder scripts to set this up too but I do think its the right level of configuration21:52
paulbarkerMaybe a really simple sign-up for the public error reporter might help21:53
paulbarkerinternal error reporter - no sign up21:53
paulbarkerpublic error reporter - signup with an API so we can have a 'enable-error-reporting' script which does the signup21:54
paulbarkerthen dump a key somewhere which is used for submission to the public error reporter21:54
paulbarkera distro maintainer would have to distribute that key which could easily be spotted as being used from many many hosts21:55
paulbarkerjust an idea21:55
*** rburton <rburton!> has quit IRC21:55
*** e8johan <e8johan!> has quit IRC21:57
*** rburton <rburton!> has joined #yocto21:58
*** dlerner <dlerner!~dlerner@> has quit IRC21:59
*** bfederau <bfederau!> has quit IRC22:01
*** bfederau <bfederau!> has joined #yocto22:01
Croftonthanks for staying up guys22:08
RPCrofton: are things finishing there?22:08
denixRP: short break22:08
RPCrofton: when you all start talking its hard to know what is going on :)22:08
RPpaulbarker: I think I spotted the bug, I've replied to your mail22:09
denixRP: it's recess, everyone talks and stretches legs...22:09
fraywe're taking a 10 minute break22:09
RPdenix: fair enough. I gave in and went and made tea before ;-)22:09
RPIts fun the odd comments that come clearly through the noise22:10
paulbarkerRP: Cheers for that, glad I asked, I'd have never worked it out without knowing about bitbake-diffsigs. I've still got plenty to learn!22:10
RPsuch as darknighte talking about plagiarism :)22:10
RPpaulbarker: bitbake-diffsigs is invaluable when dealing with the sigs. It take one file to dump or two files to compare22:11
*** belen <belen!~Adium@> has quit IRC22:12
paulbarkerRP: Do you want to fix the codeparser or shall I change the package_ipk code to use d.getVar() where possible?22:13
RPpaulbarker: fix codeparser22:13
paulbarkerRP: ok, i'll leave that to you22:14
*** lukalease <lukalease!~lukalease@> has joined #yocto22:17
volker-whatever Intel is doing with the NUC. The only available new Atom NUCs have prices way above the retail price.22:19
RPpaulbarker: if you want to test22:21
RPexcept that misses the cache version bump22:21
*** belen <belen!Adium@nat/intel/x-vjwbrcmpzmfzfmjq> has joined #yocto22:22
paulbarkerRP: I'm building on daisy & bitbake 1.22, I'll cherry-pick it. Only immediate thought is: does .getVarFlags() matter?22:23
RPpaulbarker: No, we don't do magic on that22:24
*** ant_home <ant_home!> has joined #yocto22:30
*** rburton <rburton!> has quit IRC22:32
*** rburton <rburton!> has joined #yocto22:33
paulbarkerRP: Looks like bitbake wants to do a full rebuild. I'll check back on it in an hour22:35
kergothheh, surprised we never noticed the localdata.getVar problem before :)22:39
kergothwell spotted22:39
RPpaulbarker: a lot of checksums likely changed as a result of this22:42
*** rburton <rburton!> has quit IRC22:44
*** rburton <rburton!> has joined #yocto22:45
paulbarkerRP: Yea, sounds right. I'll let the rebuild finish and kick off another, that 2nd one should do nothing if the checksums are stable. Then change my variable, kick off a 3rd build and ensure the change is picked up22:46
RPpaulbarker: sounds like a good test22:46
*** seebs <seebs!> has quit IRC22:47
*** seebs <seebs!> has joined #yocto22:49
*** bryan_ <bryan_!~bryan@> has joined #yocto22:50
mr_sciencebluelightning:  <=  how's that?22:51
*** nitink <nitink!nitink@nat/intel/x-yyzrxtngiivcyjwd> has quit IRC22:52
bryan_Hi. I was wondering... has anyone tried to build a yocto-based image with a read-only root filesystem before?22:53
*** radzy is now known as radzy_away22:53
volker-bryan_: yes, all my builds here are ro-rootfs22:53
volker-bryan_: I have my own distro, else in local.conf:
bryan_Hi volker. I added read-only-rootfs to EXTRA_IMAGE_FEATURES. My build failed, and after digging I found multiple postinsts which needed to be run on the target on first boot, which is obviously problematic.22:55
volker-bryan_: your build fails or when you boot the build?22:55
volker-bryan_:  I mean 'boot the image'22:56
bryan_The build fails with "ERROR: Some packages could not be configured offline and rootfs is read-only."22:56
bryan_and tons of other output, but that is the important one.22:56
volker-bryan_: sorry, don't know. I have only a minimal distro here with manual cherry-picked additional packages and didn't run in such kind of problems22:57
volker-bryan_: what do you try to build?22:57
bryan_Out of curiosity, what is the reason you use a read-only FS?22:57
bryan_It is an XFCE-based desktop with a ton of multimedia packages, so I am not surprised I guess.22:58
kergothr/o has to be dealt with on a case-by-case basis. whether you support r/o fully depends on what you put in your image, and what of those things you actually need to run22:58
kergothso presumably no one has gotten xfce working for it yet :)22:58
volker-our devices will go into the field and should not run into issues due of modified rootfs. For updates we mount it read-write and after it we remount it again ro22:58
kergothdo you have any persistent state, or is everything writing to tmpfs?22:59
*** oneQubit <oneQubit!> has quit IRC22:59
kergoth(out of curiosity)22:59
volker-ro-rootfs prevents us mainly from separating the entire disk into dozen partition to avoid filesystem corruptions due of crashs22:59
volker-kergoth: for some data we use in some devices SD cards. In the new one we will have two partitions: one for customer data and one to store logfiles etc23:00
kergothah, cool. makes sense23:00
bryan_My situation is the following. I have only a small bit of data that needs to be editable after building. My plan was to put that on a separate read-write partition and mount the root FS as read-only to hopefully prevent filesystem corruption on power failure.23:00
volker-it can happen that the SD cards go corrupt or have issues when the customer has frequent power issues, but we can always easily recover because the rootfs will stay intact23:00
kergothI honestly used to hate the r/o rootfs setup on the zaurus back in the day, but nowadays I like it a great deal. less risk in the field23:00
kergothof course, bind mounts are much less ugly than symlinks all over the place :)23:01
volker-bryan_: I would recommend you to start with a really small distro and then add one package after another. Then you see where you fail (and if it is for production you don't want to have unused software installed anyway).23:01
volker-kergoth: yeah, and these days it is getting easier with the new layers. Look at docker containers, its awesome & crazy what they do23:02
volker-s/new layers/new FS layes/23:02
bryan_That is good advise. I was planning to start stripping out un-needed packages once we got our main software working. Perhaps it would be good to start that now.23:03
volker-kergoth: at my old university we had linux diskless systems, there you want to control the RW part, too. So RO makes in a lot of cases sense. The only problem is the software support23:03
volker-bryan_: if you are just starting: be aware that minimal system is really minimal. E.g. standard python modules and kernel modules (for network cards etc) are often separate pacakges that you need to manually add23:04
volker-.o( maybe I should write my experiences and what I have learnt/would have liked to known earlier down )23:04
bryan_I was imagining another option and would like to hear your thought on it. Is it possible to run entirely from RAM (like puppy linux), so the rootFS can be modified, but the changes do not persist between boots?23:04
kergothi really need to play with ostree some as an update delivery mechanism. seems promising23:04
*** roric <roric!> has quit IRC23:05
*** andhe <andhe!> has quit IRC23:05
volker-bryan_: I can't answer that. But there are union fs layers (or how they are called these days) which but a persistent file system layer over rootfs. That stores the difference between the underlaying (read only) layer and the changes you did23:05
kergothbryan_: you could either copy the entire fs into ram on boot and pivot onto it, or use a unioning filesystem, of which there are multiple. or you could use the yocto r/o mechanism, which boots the r/o rootfs, but bind mounts ramdisks over parts of the fs that need to be writable23:05
*** andhe <andhe!> has joined #yocto23:06
kergothvolker-: unioning/unionfs/aufs/etc23:06
kergothi dont think there's a standard one, even after all these years, projects come and go for doing it23:06
volker-kergoth: yes, too much different names these days :)23:06
kergothme shrugs23:06
* kergoth shrugs23:06
volker-don't know which one is the most stable/supported one these days.23:06
RPlinux-yocto carries aufs supprot23:07
*** dmoseley <dmoseley!> has quit IRC23:07
volker-ok, I have to leave. happy weekend :)23:07
bryan_Is there a reason one might choose running from RAM instead of RO filesystem?23:07
bryan_Ok. Thanks volker for the help :-)23:07
kergothRP: nice, didnt' know that23:08
volker-bryan_: oh, and just build it, run it with runqemu, test it, modify it, rebuild it, test it again :)23:08
bryan_Ok. Thanks :)23:09
ant_homeRP: scratching head...klcc is broken for the 2nd built machine of the same arch. No way to retrigger do_compile as before?23:12
bryan_It looks like if I want a R/O root FS, I need to aggressively remove unneeded packages and hope that ones I actually need aren't causing problems. Are there disadvantages to using a R/O root FS instead of a RAM-based filesystem? It would seem to me that some things might expect to be able to modify parts of the root FS (like /sys).23:13
*** rburton <rburton!> has quit IRC23:14
*** rburton <rburton!> has joined #yocto23:14
*** agust <agust!> has quit IRC23:16
RPant_home: broken how?23:21
RPant_home: the idea is the sstate relocations should solve that23:21
ant_homeporeferring to the previous built machine23:22
ant_homei.e. poodle has c7x0 in prefix23:22
ant_home2nd line is correct23:22
*** rburton <rburton!> has quit IRC23:23
*** rburton <rburton!> has joined #yocto23:24
*** bryan_ <bryan_!~bryan@> has quit IRC23:25
*** bryan <bryan!~bryan@> has joined #yocto23:25
RPant_home: do you have those lines commented out?23:25
RPant_home: are all the references unconvered or just some?23:26
*** bryan <bryan!~bryan@> has quit IRC23:27
*** bryan <bryan!~bryan@> has joined #yocto23:27
ant_homeprefix, bindir, libdir, includedir23:27
*** bryan <bryan!~bryan@> has joined #yocto23:29
*** bryan <bryan!~bryan@> has joined #yocto23:30
RPant_home: the idea was that the target mangle should take care of that :/23:31
RPant_home: have a look in the temp directory, see if there is an sstate installation log for populate_sysroot23:31
*** bryan <bryan!~bryan@> has quit IRC23:32
*** bryan <bryan!~bryan@> has joined #yocto23:32
RPant_home: can you share the log from temp/ ?23:32
ant_homesure, for poodle you mean23:33
RPant_home: there should be a log for c7x0 too23:33
ant_homewell. it is in armv5te-23:34
Croftontest results for core image sato on LAVA23:34
Croftonwith some random tests23:34
Croftonfails look like related to dpkg-query23:34
RPant_home: note the sed  -i -e  's:/oe/oe-core/build/tmp-eglibc/sysroots/c7x0:FIXMESTAGINGDIRHOST:g' -e  's:\\/oe\\/oe\-core\\/build\\/tmp\-eglibc\\/sysroots\\/c7x0:FIXME_MANGLEDSTAGINGDIRTARGET:g'  -e 's:\\/oe\\/oe\-core\\/build\\/ tmp\-eglibc\\/sysroots:FIXME_MANGLEDSTAGINGDIR:g'23:38
RPant_home: I wonder if the - escape isn't correct23:39
RPshould be //- ?23:40
paulbarkerRP: Test of the codeparser fix looks good, 2nd build did nothing other than do_rootfs, 3rd build after the variable change detected it and looks to be executing do_package_write_ipk for everything.23:40
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC23:41
RPpaulbarker: I'm finding the gcc checksums have issues after the change, am working through those23:41
RPant_home: .replace("-", "\\-") -> .replace("-", "\\\\-")23:42
RPant_home: try that23:42
RPconference burnout is a real issue :(23:46
RPpaulbarker: thanks for the feedback though, should be able to get this in once I get some other issues sorted23:47
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:47
ant_homeRP: seems last try works. testing twicw23:48
paulbarkerI'm calling it a night now that build is done, thanks all23:51
*** nitink <nitink!~nitink@> has joined #yocto23:51
RPpaulbarker: 'night!23:51
khemsgw_: I have refresh gcc-4.9 branch with fixes23:52
khemit bulds world for x86 now23:52
khembut my machine is slow takes 4-6 hrs for one build23:52
ant_homeRP: seems solved, I'll verify tomorrow. Thanks23:53
RPgreat, 'night ant_home23:53
*** ant_home <ant_home!> has quit IRC23:53
*** rburton <rburton!> has quit IRC23:57
*** flynn378 <flynn378!80db310d@gateway/web/freenode/ip.> has quit IRC23:57
*** rburton <rburton!> has joined #yocto23:58

Generated by 2.11.0 by Marius Gedminas - find it at!